当石墨的碳聚集器可以完成相同的工作时，为什么要使用statsd? [英] Why use statsd when graphite's Carbon aggregator can do the same job?

问题描述

我一直在研究Graphite图形工具来显示来自多个服务器的指标，看来推荐"的方式是首先将所有指标数据发送到StatsD. StatsD汇总数据并将其发送到石墨(或更确切地说，碳).

I have been exploring the Graphite graphing tool for showing metrics from multiple servers, and it seems that the 'recommended' way is to send all metrics data to StatsD first. StatsD aggregates the data and sends it to graphite (or rather, Carbon).

就我而言，我想对各种服务器上的指标进行简单的汇总，例如求和和平均值，并在石墨中绘制出来.石墨带有碳聚集器，可以做到这一点.

In my case, I want to do simple aggregations like sum and average on metrics across servers and plot that in graphite. Graphite comes with a Carbon aggregator which can do this.

StatsD甚至不提供我正在谈论的那种聚合.

StatsD does not even provide aggregation of the kind I am talking about.

我的问题是-我的用例应该完全使用statsd吗?我在这里想念什么吗?

My question is - should I use statsd at all for my use case? Anything I am missing here?

推荐答案

1. StatsD通过UDP运行，从而消除了carbon-aggregator.py响应缓慢并在应用程序中引入延迟的风险.换句话说，松耦合.

1. StatsD operates over UDP, which removes the risk of carbon-aggregator.py being slow to respond and introducing latency in your application. In other words, loose coupling.

StatsD支持入站指标的采样，当您不希望聚合器使用所有数据点的100％来计算描述性统计信息时，此功能很有用.对于高容量代码段，通常使用0.5％-1％的采样率，以免StatsD超载.

StatsD supports sampling of inbound metrics, which is useful when you don't want your aggregator to take 100% of all data points to compute descriptive statistics. For high-volume code sections, it is common to use 0.5%-1% sample rates so as to not overload StatsD.

StatsD具有广泛的客户端支持.

StatsD has broad client-side support.

这篇关于当石墨的碳聚集器可以完成相同的工作时，为什么要使用statsd?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！