누구나 데이터 포인트 당 흑연이 사용할 디스크 공간을 추정하는 데 도움이되는 수식이나 환경의 일부 샘플 데이터가 있습니까?
답변:
whisper-info.py 파일 크기를 포함하여 각 파일이 어떻게, 어떻게 집계되는지에 대한 많은 통찰력을 제공합니다.
그러나 기존 속삭임 파일에만 유용합니다.
스키마를 배치하기 전에 스키마의 예측 크기 조정을 보려면 https://gist.github.com/jjmaestro/5774063에 있는 것과 같은 Whisper Calculator를 사용해보십시오.
편집하다:
예를 물었을 때 ...
storage_schema :
{
:catchall => {
:priority => "100",
:pattern => "^\.*",
:retentions => "1m:31d,15m:1y,1h:5y"
}
}
내 파일을 보면 applied-in-last-hour.wsp, ls -l수율
-rwxr-xr-x 1 root root 4415092 Sep 16 08:26 applied-in-last-hour.wsp
및 whisper-info.py ./applied-in-last-hour.wsp수율
maxRetention: 157680000
xFilesFactor: 0.300000011921
aggregationMethod: average
fileSize: 4415092
Archive 0
retention: 604800
secondsPerPoint: 10
points: 60480
size: 725760
offset: 52
Archive 1
retention: 2678400
secondsPerPoint: 60
points: 44640
size: 535680
offset: 725812
Archive 2
retention: 157680000
secondsPerPoint: 600
points: 262800
size: 3153600
offset: 1261492
따라서 기본적으로 통계 당 보존 기간 세그먼트 당 보존 기간 일치 호스트를이 시스템에 적용하려는 시스템 요소를 곱하여 추적하려는 새 통계 수를 고려하십시오. 그런 다음 저장 용량을 구매하고 적어도 두 배의 용량을 차지합니다 (스토리지를 구매하고 있기 때문에 사용할 것이므로 ...)
ls -l하므로 바이트로 간주합니다. .wsp 파일 내에서 아카이브의 크기를 합하면 (로보고 됨 whisper-info.py) 전체 .wsp 파일 크기에 가깝습니다 (나머지는 메타 데이터라고 가정합니다. 모두의 파일 크기 여야 함). 시간이 지남에 따라 데이터가 더 낮은 데이터 해상도로 떨어지고 오래된 데이터 포인트가 삭제됩니다.
ServerCount * MetricCount * 4.5MBytes
statsd 문서 에서 데이터 보존 정책에 대한 예 를 제공합니다 .
보유 10s:6h,1min:7d,10min:5y는 2160 + 10080 + 262800 = 275040 데이터 포인트 이며 아카이브 크기는 3.2 MiB 입니다.
선형 관계를 가정하면 데이터 포인트 당 약 12.2 바이트입니다 .
Graphite에 대한 직접적인 경험은 없지만 Cacti에 사용 된 것과 동일한 논리 또는 RRD 또는 타임 롤오버 기반의 다른 적용이 적용될 것이라고 생각합니다 (Graphite는 더 이상 내부적으로 RRD를 사용하지 않지만 스토리지 논리는 비슷해 보입니다).
빠른 대답은 "아마도 필요한만큼의 공간이 아닐 것입니다."
긴 대답은 일부 사이트 별 수학과 관련이 있습니다. 모니터링 시스템 (InterMapper)의 경우, 보존 기간, 해상도 및 데이터 포인트 크기를 파악하고 곱셈을 수행하고 오버 헤드를 추가합니다.
예를 들어 디스크 공간을 사용하겠습니다. 30 일 동안 5 분 정밀도, 60 일 동안 15 분 정밀도, 추가 300 일 동안 시간별 정밀도로 그림을 저장하고 64를 사용합니다. -비트 (8 바이트) 정수로 저장합니다.
샘플 당 8 바이트에서 약 173KB이고 스토리지 인덱싱 등의 건전한 오버 헤드로 인해 하나의 파티션의 디스크 사용량 데이터에 대해 약 200KB가됩니다 (과대 평가 경향이있는 오류).
기본 메트릭에서 평균 "컴퓨터 당"크기 (10 개의 디스크 파티션, 스왑 공간, RAM,로드 평균, 네트워크 전송 및 기타 몇 가지)를 해결할 수 있습니다. 머신 당 약 5MB까지 작동합니다.
또한 최종 숫자 위에 10 %를 추가하고 반올림하므로 머신 당 6MB로 크기를 조정합니다.
그런 다음 차트 용 메트릭 데이터를 저장하기 위해 배치 한 1TB의 공간을보고 "그렇습니다. 우리가 많이 성장하지 않으면 평생 저장 공간이 부족하지 않을 것입니다!"라고 말합니다. :-)
많은 데이터를 생성하는 70 개의 노드가 있습니다. Carbon / Whisper를 사용하여 하나의 노드가 91k 파일 만 작성했습니다 (노드는 여러 개의 카운터 및 변수 필드가있는 여러 스키마를 생성합니다 (예 : (nodename). (schema). (counter). (subcounter)). )....등등).
이것은 내가 원하는 그래프를 그리는 데 필요한 세분성을 제공했습니다. 나머지 69 개 노드를 채우기 위해 스크립트를 실행 한 후 디스크에 1.3Tb의 데이터가있었습니다. 그리고 그것은 단지 6 시간 분량의 데이터 / 노드입니다. 6hrs의 데이터에 대한 실제 플랫 csv 파일은 약 230Mb / 노드입니다. 70 개 노드는 ~ 16Gb의 데이터입니다. 내 스토리지 스키마는 120 : 365d였습니다.
데이터베이스에 익숙하지 않아서 잘못된 일이있을 수 있지만 각 샘플의 오버 헤드 인 것 같습니다.
재미있는 실험 이었지만 저장하는 데이터 종류에 속삭임을 사용하는 것이 이치에 맞지 않다고 생각합니다. MongoDB는 더 나은 솔루션처럼 보이지만 Grafana의 백엔드로 사용하는 방법을 알아야합니다.