2014-04-04 1 views
0

메트릭 이름에 빌드 번호가있는 메트릭을 저장합니다. 흑연의 미터법 형식은 다음과 같습니다.여러 메트릭을 흑연에서 정규 표현식으로 집계하는 보존 정책

latency.<host>.<request>.<buildNumber>.average 

위 형식의 문제는 buildNumber가 값을 변경한다는 것이며, 우리의 경우 릴리스 주기로 인해 매주 변경된다는 것입니다. 매주 새로운 저장 파일 (.wsp)이 생성되고 속삭임이 공간을 미리 할당하므로 빌드 번호가 변경되어 공간을 충분히 활용하지 못했습니다.

나는 디스크 공간이 값이 싼 자원이지만 아직도 어떤 시점에서는 사용하지 않은 공간이 많을 것으로 생각한다.

예를 들어 각 메트릭 파일의 크기가 10MB이고 대기 시간에 대해 5000 가지 메트릭을 전송하는 경우 특정 빌드 번호에 대해 50GB를 사용합니다. 이제 매주 새로운 빌드 번호를 보내면 1TB의 디스크 공간이 약 5 개월 인 20 주 내에 채워집니다. (1TB = 1000GB)/(주당 50GB) = 20 주

위의 문제는 다음과 같을 수 있습니다. 지난 한 달 동안 여러 측정 항목을 통합 할 수 있다면 해결할 수 있습니다. 일부 메트릭을 사용하여 여러 메트릭을 병합하는 보존 정책을 지정하는 방법이 있습니까?

흑연에서 이런 종류의 문제를 해결할 방법이 있습니까?

답변

1

Whisper를 사용하는 대신 Graphite 용 Ceres 스토리지 엔진을 사용하면 공간을 사전 할당하는 문제를 피할 수 있습니다. https://github.com/graphite-project/ceres

다운 샘플링 중에 여러 메트릭을 지정된 집계로 병합 할 수 있다고 생각하지 않습니다. 그러나 aggregation-rules.conf를 통해 수집 시점에이 작업을 수행 할 수 있습니다. 문서는 여기에서 찾을 수 있습니다. http://graphite.readthedocs.org/en/latest/config-carbon.html#aggregation-rules-conf

+0

답장을 보내 주셔서 감사합니다. Ceres는 좋은 옵션이지만 지금은 좋은 롤업 기능이 아닌 것 같습니다. –