爲什麼使用statsd時石墨的碳聚合器可以做同樣的工作？

Question

我一直在探索用於顯示來自多個服務器的指標的Graphite繪圖工具，而且似乎'推薦'的方法是首先將所有指標數據發送到StatsD。 StatsD彙總數據並將其發送給石墨（或碳）。

就我而言，我想對整個服務器上的指標進行簡單聚合，例如總和和平均值，並繪製石墨圖。石墨帶有一個碳聚合器可以做到這一點。

StatsD甚至不提供我正在談論的那種聚合。

我的問題是 - 我應該使用statsd嗎？我在這裏失蹤的任何東西？

Answer 1

1. StatsD通過UDP運行，它消除了carbon-aggregator.py響應速度慢並且在您的應用程序中引入延遲的風險。換句話說，鬆耦合。

2. StatsD支持入站度量的採樣，當您不希望您的聚合器採用所有數據點的100％來計算描述性統計時，這很有用。對於大批量代碼段，通常使用0.5％-1％的採樣率，以免超載StatsD。

3. StatsD有broad client-side的支持。

Answer 2

由於石墨具有最小分辨率，所以在定義的時間間隔內不能爲同一指標保存兩個不同的值。 StatsD通過預先彙總它們解決了這個問題，而不是說「現在註冊1個用戶」和「現在註冊1個用戶」，而是說「註冊了2個用戶」。

另一個原因是性能，因爲：

1. 你可以通過UDP，這是一個火將數據發送到StatsD忘記協議，無狀態的，更快的
2. StatsD的Etsy的實現是的NodeJS這也增加了表現很多。

Answer 3

如果碳聚合器提供您需要的一切，沒有理由不使用它。它有兩個基本的聚合函數（總和和平均值），實際上StatsD並不包含這些函數。 （我對歷史不太確定，但Carbon聚合器可能已經存在，StatsD作者也不想複製特徵？）Carbon也支持通過UDP接收數據，因此唯一會遺漏的是採樣，如果通過平均來聚合，這並不重要。

StatsD通過添加額外的聚合值（例如，對於定時器：平均值，下限，上限和上限第X百分位，...）來支持不同的度量標準類型。我喜歡它們，但如果你不需要它們，碳聚合器也是一個很好的選擇。

我一直在尋找Carbon aggregator和StatsD的源代碼（和Bucky，Python中的StatsD實現），它們都非常簡單，我不會擔心資源使用或性能的任何選擇。

Answer 4

看起來碳和聚合statsd支持分離的特徵集合：

• statsd支持速率計算和求和，但不支持平均值
• 碳聚合支持平均，但不支持率計算。

Answer 5

tldr：，你可能會想statsd（或carbon-c-relay）如果你想看看服務器專用款項或平均數。

碳聚合被設計成聚合值從多個指標在一起成爲一個單一的輸出度量，通常以提高圖形渲染性能。 statsd旨在將多個數據點彙總爲一個度量標準，因爲否則石墨僅存儲以最小存儲分辨率報告的最後一個值。

statsd例如： 假設你的石墨存儲schemas.conf文件具有10秒（默認值）的最小保留和應用程序正在大約每10秒100個數據點發送給services.login.server1 。count爲，值爲1.如果沒有statsd，石墨將只存儲每個10秒桶中接收到的最後一個計數。收到第100條消息後，其他99個數據點將被拋出。但是，如果您將應用程序和石墨之間的數據進行統計，那麼在將總數發送到石墨之前，它會將所有100個數據點相加在一起。因此，如果沒有統計信息，您的圖表僅指示，如果在10秒間隔內發生登錄。與statsd，它表示在該時間間隔內發生了多少次登錄。 （for example）

碳聚合器例如：假設你有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 所有存儲的時間間隔除第一（最小）的保留期間每個保留串。可以使用碳彙集器來彙總該第一保留期間內的指標內的數據點。不幸的是，aggregation-rules.conf使用「blob」模式而不是正則表達式模式。所以您需要爲每個路徑深度和聚合類型添加單獨的aggregation-rules.conf文件條目。statsd的優勢在於，發送度量標準的客戶端可以指定聚合類型，而不是在度量標準路徑中對其進行編碼。這使您可以靈活地隨時添加新度量標準，而不受公制路徑深度的影響。如果你想配置碳聚合器自動執行statsd般聚集，當你添加一個新的指標，你的聚集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$ 
   

   筆記：尾隨「$」是不需要在石墨0.10+ here is the relevant patch on github和這裏（目前的預發行版）是aggregation rules

2. 的weightedAverage功能的標準文檔中新的石墨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來聚合響應時間，然後重新聚合這些值，則statsd可以自動在單個輸入度量標準（總和，平均值，最小值，最大值等等）上執行多個不同的聚合（

4. ）在使用碳聚合器的石墨服務器上，您最終的平均響應時間將由應用服務器而非請求加權。顯然，這隻適用於使用均值或top_90聚合規則進行彙總，而不是最小值，最大值或總和。而且，如果你的負載不平衡，它只是意義重大。作爲一個例子：假設你有一個由100個服務器組成的羣集，突然有1個服務器被髮送99％的流量。因此，該服務器的響應時間增加了四倍，但在其他99臺服務器上保持穩定。如果你使用客戶端聚合，你的整體指標只會上漲3％左右。但如果您在單個服務器端碳集合器中完成所有聚合，那麼您的總體指標將提高約300％。

5. carbon-c-relay本質上是用c寫成的碳集合體的直接替代品。它提高了性能和基於正則表達式的匹配規則。結果就是您可以在同一個簡單的基於regex的配置文件中同時執行statsd樣式的數據點聚合和碳中繼樣式度量聚合以及其他整潔的東西，如多層聚合。

6. 如果使用cyanite後端，而不是碳緩存，那麼藍晶石會做內部指標平均爲您在內存中（截至version 0.5.1），或在讀取時（在版本0.1.3 <架構）。