graphite의 Carbon aggregator가 동일한 작업을 수행 할 수 있는데 왜 statsd를 사용합니까?

graphite의 Carbon aggregator가 동일한 작업을 수행 할 수 있는데 왜 statsd를 사용합니까?

---

여러 서버의 메트릭을 표시하기 위해 Graphite 그래프 도구를 탐색 해 왔으며 '권장되는'방법은 먼저 모든 메트릭 데이터를 StatsD에 보내는 것 같습니다. StatsD는 데이터를 집계하여 흑연 (또는 탄소)으로 보냅니다.

제 경우에는 서버 전체의 메트릭에 대한 합계 및 평균과 같은 간단한 집계를 수행하고이를 흑연으로 표시하고 싶습니다. 흑연에는이를 수행 할 수있는 탄소 응집 기가 함께 제공됩니다.

StatsD는 내가 말하는 종류의 집계조차 제공하지 않습니다.

내 질문은-내 사용 사례에 statsd를 전혀 사용해야합니까? 내가 여기에 빠진 것이 있습니까?

---

1. StatsD는 UDP를 통해 작동하므로 carbon-aggregator.py가 응답 속도가 느려지고 애플리케이션에 지연이 발생할 위험이 없습니다. 즉, 느슨한 결합입니다.

2. StatsD는 인바운드 메트릭의 샘플링을 지원하므로 집계자가 설명 통계를 계산하기 위해 모든 데이터 포인트의 100 %를 차지하지 않도록하려는 경우에 유용합니다. 대용량 코드 섹션의 경우 StatsD에 과부하가 걸리지 않도록 0.5 % -1 % 샘플 속도를 사용하는 것이 일반적입니다.

3. StatsD는 광범위한 클라이언트 측 지원을 제공합니다.

---

tldr : 서버 별 합계 또는 평균을보고 싶다면 statsd (또는 carbon-c-relay )를 원할 것입니다.

탄소 집계 기는 일반적으로 그래프 렌더링 성능을 높이기 위해 여러 메트릭의 값을 단일 출력 메트릭으로 집계하도록 설계되었습니다 . statsd 는 단일 메트릭에서 여러 데이터 포인트 를 집계하도록 설계되었습니다. 그렇지 않으면 흑연은 최소 저장 해상도로보고 된 마지막 값만 저장하기 때문입니다.

statsd 예 : graphite storage-schemas.conf 파일의 최소 보존 기간이 10 초 (기본값)이고 애플리케이션이 10 초마다 약 100 개의 데이터 포인트를 services.login.server1.count 에 값 1 로 전송한다고 가정합니다 . statsd가 없으면 graphite는 각 10 초 버킷에서받은 마지막 카운트 만 저장합니다. 100 번째 메시지가 수신 된 후 다른 99 개의 데이터 포인트는 버려집니다. 그러나 애플리케이션과 그래파이트 사이에 statsd를 넣으면 전체 100 개 데이터 포인트를 합산 한 다음 그래파이트로 총계를 보냅니다. 따라서 통계가 없으면 그래프 는 로그인이 10 초 간격 동안 발생했는지 여부 만 나타냅니다 . statsd으로, 그것은 표시 얼마나 많은해당 간격 동안 로그인이 발생했습니다. ( 예 :)

탄소 집 계기 예 : 200 개의 개별 메트릭을보고하는 200 개의 서로 다른 서버가 있다고 가정합니다 ( services.login.server1.response.time , services.login.server2.response.time 등). 운영 대시 보드에 weightedAverage (services.login.server * .response.time, services.login.server * .response.count, 2)와 같은 흑연 쿼리를 사용하여 모든 서버의 평균 그래프를 표시합니다. 안타깝게도이 그래프를 렌더링하는 데 10 초가 걸립니다. 이 문제를 해결하기 위해 탄소 집계 규칙을 추가하여 모든 서버의 평균을 미리 계산하고 값을 새 메트릭에 저장할 수 있습니다. 이제 대시 보드를 업데이트하여 단일 지표 (예 : services.login.response.time ) 를 간단히 가져올 수 있습니다 . 새로운 메트릭은 거의 즉시 렌더링됩니다.

참고 :

1. 스토리지 aggregation.conf에서 집계 규칙은 스토리지 schemas.conf의 모든 스토리지 간격 적용 제외각 보존 문자열에 대한 첫 번째 (가장 작은) 보존 기간. 탄소 집계기를 사용하여 첫 번째 보존 기간 동안 메트릭 내에서 데이터 포인트를 집계 할 수 있습니다. 불행히도 aggregate-rules.conf는 정규식 패턴이 아닌 "blob"패턴을 사용합니다. 따라서 모든 경로 깊이 및 집계 유형에 대해 별도의 aggregation-rules.conf 파일 항목을 추가해야합니다. statsd의 장점은 메트릭을 전송하는 클라이언트가 메트릭 경로에서 인코딩하는 대신 집계 유형을 지정할 수 있다는 것입니다. 메트릭 경로 깊이에 관계없이 새 메트릭을 즉시 추가 할 수있는 유연성을 제공합니다. 새 메트릭을 추가 할 때 자동으로 statsd와 유사한 집계를 수행하도록 carbon-aggregator를 구성하려는 경우 aggregate-rules.conf 파일은 다음과 같습니다.

   <n1>.avg (10)= avg <n1>.avg$
   <n1>.count (10)= sum <n1>.count$
   <n1>.<n2>.avg (10)= avg <n1>.<n2>.avg$
   <n1>.<n2>.count (10)= sum <n1>.<n2>.count$
   <n1>.<n2>.<n3>.avg (10)= avg <n1>.<n2>.<n3>.avg$
   <n1>.<n2>.<n3>.count (10)= sum <n1>.<n2>.<n3>.count$
   ...
   <n1>.<n2>.<n3> ... <n99>.count (10)= sum <n1>.<n2>.<n3> ... <n99>.count$
   

   참고 : graphite 0.10+ (현재 시험판)에서는 후행 "$"가 필요하지 않습니다. 여기에 github의 관련 패치 가 있으며 집계 규칙 에 대한 표준 문서가 있습니다.

2. weightedAverage 함수는 graphite 0.10의 새로운 기능이지만 일반적으로 averageSeries 함수는 부하가 균등하게 균형을 유지하는 한 매우 유사한 숫자를 제공합니다. 더 느리고 더 적은 요청을 처리하는 서버가 있거나 정밀도가 더 까다 롭다면 그래파이트 0.9로 가중 평균을 계산할 수 있습니다. 다음과 같이 더 복잡한 쿼리를 작성하면됩니다.

   divideSeries(sumSeries(multiplySeries(a.time,a.count), multiplySeries(b.time,b.count)),sumSeries(a.count, b.count))
   

3. statsd가 클라이언트 상자에서 실행되면 네트워크 부하도 감소합니다. 이론적으로는 클라이언트 측에서도 탄소 집계기를 실행할 수 있습니다. 그러나 statsd 클라이언트 라이브러리 중 하나를 사용하는 경우 샘플링을 사용하여 애플리케이션 시스템의 CPU에 대한 부하를 줄일 수도 있습니다 (예 : 루프백 udp 패킷 생성). 또한 statsd는 단일 입력 메트릭 (합계, 평균, 최소, 최대 등)에 대해 여러 다른 집계를 자동으로 수행 할 수 있습니다.

4. 각 앱 서버에서 statsd를 사용하여 응답 시간을 집계 한 다음 탄소 집계기를 사용하여 그래파이트 서버에서 해당 값을 다시 집계하면 요청이 아닌 앱 서버에 가중치를 둔 평균 응답 시간이됩니다. 분명히 이것은 min, max 또는 sum이 아닌 mean 또는 top_90 집계 규칙을 사용하여 집계하는 경우에만 중요합니다. 또한 부하가 불균형 한 경우 평균에만 중요합니다. 예를 들어, 100 개의 서버 클러스터가 있고 갑자기 1 개의 서버가 트래픽의 99 %를 전송한다고 가정합니다. 결과적으로 응답 시간은 해당 서버 1 대에서 4 배가되지만 나머지 99 개 서버에서는 일정하게 유지됩니다. 클라이언트 측 집계를 사용하는 경우 전체 메트릭은 약 3 % 만 증가합니다. 그러나 단일 서버 측 탄소 집 계기에서 모든 집계를 수행하면 전체 메트릭이 약 300 %까지 올라갑니다.

5. carbon-c-relay 는 본질적으로 c로 작성된 탄소 응집체의 드롭 인 대체품입니다. 성능 및 정규식 기반 일치 규칙이 향상되었습니다. 결론은 statsd 스타일 데이터 포인트 집계와 탄소 릴레이 스타일 메트릭 집계 및 다층 집계와 같은 기타 깔끔한 작업을 모두 동일한 간단한 정규식 기반 구성 파일에서 모두 수행 할 수 있다는 것입니다.

6. carbon-cache 대신 cyanite 백엔드 를 사용하는 경우 cyanite는 메모리 ( 버전 0.5.1 기준 ) 또는 읽기 시간 (버전 <0.1.3 아키텍처에서) 에서 인트라 메트릭 평균을 수행합니다 .

---

If the Carbon aggregator offers everything you need, there is no reason not to use it. It has two basic aggregation functions (sum and average), and indeed these are not covered by StatsD. (I'm not sure about the history, but maybe the Carbon aggregator already existed and the StatsD authors did not want to duplicate features?) Receiving data via UDP is also supported by Carbon, so the only thing you would miss would be the sampling, which does not matter if you aggregate by averaging.

StatsD supports different metric types by adding extra aggregate values (e.g. for timers: mean, lower, upper and upper Xth percentile, ...). I like them, but if you don't need them, the Carbon aggregator is a good way to go too.

I have been looking at the source code of the Carbon aggregator and StatsD (and Bucky, a StatsD implementation in Python), and they are all so simple, that I would not worry about resource usage or performance for either choice.

---

Looks like carbon aggregator and statsd support disjoint set of features:

• statsd supports rate calculation and summation but does not support averaging values
• carbon aggregator supports averaging but does not support rate calculation.

---

Because graphite has a minimum resolution, so you cannot save two different values for the same metric during defined interval. StatsD solves this problem by pre-aggregating them, and instead of saying "1 user registered now" and "1 user registered now" it says "2 users registered".

The other reason is performance because:

1. You send data to StatsD via UDP, which is a fire and forget protocol, stateless, much faster
2. StatsD etsy's implementation is in NodeJS which also increases the performance a lot.

참고URL : https://stackoverflow.com/questions/13697553/why-use-statsd-when-graphites-carbon-aggregator-can-do-the-same-job