Question

我一直在探索Graphite图表工具，用于显示来自多个服务器的指标，似乎“推荐”方式是首先将所有指标数据发送到StatsD。 StatsD聚合数据并将其发送到石墨（或更确切地说，碳）。

就我而言，我希望对服务器上的指标进行简单的聚合，例如求和和平均值，并用石墨绘制。石墨带有碳聚合器，可以做到这一点。

StatsD甚至没有提供我所说的那种聚合。

我的问题是 - 我应该根据我的用例使用statsd吗？我在这里缺少什么？

Answer 1

StatsD通过UDP运行，消除了carbon-aggregator.py响应缓慢和在应用程序中引入延迟的风险。换句话说，松耦合。
StatsD支持对入站指标进行抽样，这在您不希望聚合器占用所有数据点的100％来计算描述性统计数据时非常有用。对于大批量代码段，通常使用0.5％-1％的采样率，以免超载StatsD。
StatsD有broad client-side支持。

Answer 2

tldr：如果您想要查看特定于服务器的总和或平均值，您可能需要statsd（或carbon-c-relay）。

碳聚合器旨在将多个指标中的值聚合到一个输出指标中，通常用于提高图表呈现效果。 statsd 旨在在单个指标中聚合多个数据点，因为否则，graphite仅存储以最小存储分辨率报告的最后一个值。

statsd示例： 假设您的graphite storage-schemas.conf文件的最小保留时间为10秒（默认值），并且您的应用程序每10秒向 services.login.server1.count 发送大约100个数据点如果没有statsd，则石墨只会存储每个10秒桶中收到的最后一次计数。收到第100条消息后，其他99个数据点将被丢弃。但是，如果你在应用程序和石墨之间放置statsd，那么在将总数发送到石墨之前，它会将所有100个数据点加在一起。因此，如果没有statsd，您的图表仅指示如果在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 ）。新指标几乎立即呈现。

旁注：

storage-aggregation.conf中的聚合规则适用于storage-schemas.conf 中的所有存储间隔，但是每个保留字符串的第一个（最小）保留期。可以使用碳聚合器来聚合第一个保留期的度量标准内的数据点。不幸的是，aggregation-rules.conf使用＆＃34; blob＆＃34;模式而不是正则表达式模式。因此，您需要为每个路径深度和聚合类型添加单独的aggregation-rules.conf文件条目。 statsd的优点是发送度量的客户端可以指定聚合类型，而不是在度量标准路径中对其进行编码。这使您可以灵活地随时添加新指标，而不管指标路径深度如何。如果您想在添加新指标时自动配置carbon-aggregator以执行类似statsd的聚合，那么您的aggregation-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$
```
注意：尾随＆＃34; $＆＃34;石墨0.10+（目前预发布）here is the relevant patch on github不需要，这里是aggregation rules的标准文档
weightedAverage函数是石墨0.10中的新功能，但通常只要您的负载均衡，averageSeries函数就会给出一个非常相似的数字。如果你有一些速度较慢且服务较少的服务器，或者你只是精确度较高的服务器，那么你仍然可以用石墨0.9计算加权平均值。你只需要构建一个更复杂的查询：
```
divideSeries(sumSeries(multiplySeries(a.time,a.count), multiplySeries(b.time,b.count)),sumSeries(a.count, b.count))
```
如果在客户端框上运行statsd，这也会减少网络负载。虽然从理论上讲，你也可以在客户端运行碳聚合器。但是，如果您使用其中一个statsd客户端库，您还可以使用抽样来减少应用程序计算机的CPU负载（例如，创建环回udp数据包）。此外，statsd可以在单个输入度量（sum，mean，min，max等）上自动执行多个不同的聚合
如果您在每个应用服务器上使用statsd来聚合响应时间，然后使用碳聚合器在石墨服务器上重新聚合这些值，则最终会得到应用服务器而不是请求加权的平均响应时间。显然，这仅适用于使用mean或top_90聚合规则进行聚合，而不是min，max或sum。此外，如果您的负载不平衡，它只对意味着重要。例如：假设您有一个包含100个服务器的集群，突然有1个服务器被发送99％的流量。因此，该服务器的响应时间翻了两番，但在其他99台服务器上保持稳定。如果您使用客户端聚合，您的整体指标只会上涨约3％。但是，如果您在单个服务器端碳聚合器中进行所有聚合，那么您的总体指标将上升约300％。
carbon-c-relay基本上是用c编写的碳聚合器的直接替代品。它改进了性能和基于正则表达式的匹配规则。结果是你可以在同一个简单的基于正则表达式的配置文件中同时执行statsd风格的数据点聚合和碳中继风格度量聚合以及其他整洁的东西，例如多层聚合。
如果您使用cyanite后端而不是碳缓存，那么氰基将在内存中进行度量内平均（从version 0.5.1起）或在读取时（在版本＆lt; 0.1.3架构中）。

Answer 3

如果Carbon聚合器提供您需要的一切，则没有理由不使用它。它有两个基本的聚合函数（总和和平均值），实际上StatsD不包含这些函数。（我不确定历史，但也许Carbon聚合器已经存在且StatsD作者不想复制功能？）Carbon也支持通过UDP接收数据，所以你唯一会想到的就是采样，如果你通过平均汇总无关紧要。

StatsD通过添加额外的聚合值来支持不同的度量标准类型（例如，对于计时器：平均值，下限，上部和上部第X百分位数，......）。我喜欢它们，但如果你不需要它们，碳聚合器也是一种很好的方式。

我一直在查看Carbon聚合器和StatsD的源代码（和Bucky，Python中的StatsD实现），它们都非常简单，我不担心资源使用或性能要么选择。

Answer 4

看起来碳聚合器和statsd支持不相交的一组功能：

statsd支持费率计算和求和，但不支持平均值
碳聚合器支持平均，但不支持费率计算。

Answer 5

由于石墨具有最小分辨率，因此您无法在定义的间隔期间为同一指标保存两个不同的值。 StatsD通过预先聚合它们来解决这个问题，而不是说“1个用户现在注册”和“1个用户现在注册”，它说“2个用户注册”。

另一个原因是表现因为：

您通过UDP向StatsD发送数据，这是一种即发即弃的协议，无状态，更快
StatsD etsy在NodeJS中的实现也大大提高了性能。

当石墨的碳聚合器可以做同样的工作时，为什么要使用statsd？

5 个答案: