我一直在探索Graphite图形工具，它可以显示来自多个服务器的指标，而"推荐"的方法似乎是先将所有指标数据发送到StatsD。 StatsD会聚合数据并将其发送到graphite（或更确切地说是Carbon）。
在我的案例中，我想对跨服务器的指标执行简单的汇总（例如求和和平均值），并在Graphite中绘制它们。Graphite带有一个Carbon聚合器，可以做到这一点。
但是，StatsD甚至不提供我所讲述的类型的聚合功能。
我的问题是-对于我的用例，我是否应该使用StatsD？我是否遗漏了什么重要信息？
StatsD操作的是UDP协议，这消除了carbon-aggregator.py响应缓慢并在应用程序中引入延迟的风险。换句话说，实现了松散耦合。
StatsD支持传入指标数据的抽样，当您不希望聚合器获取所有数据点并计算描述性统计信息时，它非常有用。在高负载的代码段中，通常使用0.5％-1％的采样率以避免StatsD过载。
StatsD拥有广泛的客户端支持，请参见此处。
the aggregation rules in storage-aggregation.conf apply to all storage intervals in storage-schemas.conf except the first (smallest) retention period for each retention string. it is possible to use carbon-aggregator to aggregate data points within a metric for that first retention period. unfortunately, aggregation-rules.conf uses "blob" patterns rather than regex patterns. so you need to add a separate aggregation-rules.conf file entry for every path depth and aggregation type. the advantage of statsd is that the client sending the metric can specify the aggregation type rather than encoding it in the metric path. that gives you the flexibility to add a new metric on the fly regardless of metric path depth. if you wanted to configure carbon-aggregator to do statsd-like aggregation automatically when you add a new metric, your aggregation-rules.conf file would look something like this:
<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$
notes: the trailing "$" is not needed in graphite 0.10+ (currently pre-release) here is the relevant patch on github and here is the standard documentation on aggregation rules
the weightedAverage function is new in graphite 0.10, but generally the averageSeries function will give a very similar number as long as your load is evenly balanced. if you have some servers that are both slower and service fewer requests or you are just a stickler for precision, then you can still calculate a weighted average with graphite 0.9. you just need to build a more complex query like this:
divideSeries(sumSeries(multiplySeries(a.time,a.count), multiplySeries(b.time,b.count)),sumSeries(a.count, b.count))
if statsd is run on the client box this also reduces network load. although, in theory, you could run carbon-aggregator on the client side too. however, if you use one of the statsd client libraries, you can also use sampling to reduce the load on your application machine's cpu (e.g. creating loopback udp packets). furthermore, statsd can automatically perform multiple different aggregations on a single input metric (sum, mean, min, max, etcetera)
if you use statsd on each app server to aggregate response times, and then re-aggregate those values on the graphite server using carbon aggregator, you end up with an average response time weighted by app server rather than request. obviously, this only matters for aggregating using a mean or top_90 aggregation rule, and not min, max or sum. also, it only matters for mean if your load is unbalanced. as an example: assume you have a cluster of 100 servers, and suddenly 1 server is sent 99% of the traffic. consequentially, the response times quadruple on that 1 server, but remain steady on the other 99 servers. if you use client side aggregation, your overall metric would only go up about 3%. but if you do all your aggregation in a single server-side carbon aggregator, then your overall metric would go up by about 300%.
carbon-c-relay is essentially a drop-in replacement for carbon-aggregator written in c. it has improved performance and regex-based matching rules. the upshot being that you can do both statsd-style datapoint aggregation and carbon-relay style metric aggregation and other neat stuff like multi-layered aggregation all in the same simple regex-based config file.
if you use the cyanite back-end instead of carbon-cache, then cyanite will do the intra-metric averaging for you in memory (as of version 0.5.1) or at read time (in the version <0.1.3 architecture).
StatsD通过添加额外的聚合值来支持不同的指标类型（例如，对于计时器：平均值、下限、上限和上X个百分位数等）。我喜欢它们，但如果您不需要它们，Carbon聚合器也是一个不错的选择。
我一直在查看Carbon聚合器和StatsD（以及Python中的Bucky，它是一个StatsD实现）的源代码，它们都非常简单，所以我不会担心任何一种选择的资源使用或性能问题。
看起来 carbon aggregator 和 statsd 支持不同的功能集：
由于Graphite具有最小分辨率，因此在定义的时间间隔内无法为同一指标保存两个不同的值。 StatsD通过预先聚合它们来解决此问题，而不是说“现在注册了1个用户”和“现在注册了1个用户”，它会说“已注册2个用户”。
另一个原因是性能，因为：