我正在布置一个架构，在该架构中我们将使用statsd和 Graphite 。我了解 Graphite 是如何工作的，以及单个statsd服务器如何与之通信。我想知道用于扩展statsd服务器的体系结构和设置如何工作。您将有多个节点statsd服务器，然后再有一个中央statsd服务器推送到 Graphite 吗？我似乎找不到有关扩展statsd的任何内容，并且对任何具有多个statsd服务器的想法都将不胜感激。
我现在正在处理相同的问题。在多个statsds之间进行幼稚的负载平衡显然是行不通的，因为具有相同名称的键将以不同的statsds结尾，因此将被错误地聚合。
但是，在需要扩展的环境中使用statsd有两种选择:
如statsd文档中所述，将客户端采样用于计数器指标(即，不是将每个事件发送到statsd，而是仅发送第10个事件并将statsd乘以10)。缺点是您需要为每个指标手动设置适当的采样率。如果采样的值太少，则结果将不准确。如果采样过多，您将杀死您的(单个)statsd实例。
构建了一个自定义的负载均衡器，该负载均衡器按度量标准名称分片为不同的statsds，从而规避了聚合中断的问题。每一个都可以直接写入Graphite。
构建一个statsd客户端，该客户端在本地对事件进行计数，并且仅将事件汇总发送到statsd。这样可以大大减少进入statsd的流量，并使流量保持恒定(只要您不添加更多服务器)。只要将数据发送到statsd的周期比statsd自己的刷新周期小得多，您就应该获得类似的准确结果。
我在生产中成功实现的最后一点的变体:使用第一层多个statsd(在我的情况下为本地)statsds，它们依次汇总为一个中央statsd，然后与Graphite进行对话。 statsds的第一层将需要比第二层少得多的刷新时间。为此，您将需要一个statsd到statsd后端。由于我恰好遇到了这个问题，所以我写了一个试图使网络尽可能高效的问题:https://github.com/juliusv/ne-statsd-backend
实际上，不幸的是statsd并非旨在以可管理的方式进行扩展(不，我不认为手动调整采样率是“可管理的”)。但是，如果您坚持使用上述变通办法，应该会有所帮助。
