为什么使用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 <架构）。