我正在布局我们将使用statsd和graphite的架构.我理解石墨的工作原理以及单个统计服务器如何与之通信.我想知道架构和设置如何用于扩展statsd服务器.你有多个节点statsd服务器,然后一个中央statsd服务器推送到石墨？我似乎无法找到有关扩展statsd的任何信息,任何有关如何拥有多个statsd服务器的想法都将受到赞赏.
解决方法
我现在正处理同样的问题.在多个statsds之间进行天真的负载平衡显然不起作用,因为具有相同名称的密钥最终会出现在不同的statsds中,因此会被错误地聚合.
但是在需要扩展的环境中使用statsd有几种选择：
>使用客户端抽样计数器指标,如statsd文档中所述(即,不是将每个事件发送到statsd,只发送每10个事件并使statsd乘以10).缺点是您需要为每个指标手动设置适当的采样率.如果您采样的值太少,则结果将不准确.如果你采样太多,你就会杀死你的(单个)statsd实例.
>构建一个自定义负载均衡器,按度量标准名称分片到不同的统计信息,从而避免了聚合损坏的问题.其中每一个都可以直接写入Graphite.
>构建一个statsd客户端,在本地计算事件,并仅将它们汇总发送到statsd.这大大减少了流向statsd的流量,并使其保持不变(只要您不添加更多服务器).只要您将数据发送到statsd的时间段比statsd自己的刷新时间段小得多,您也应该获得类似的准确结果.
>我在生产中取得巨大成功的最后一点的变化：使用第一层多重(在我的情况下为本地)statsds,然后将所有数据聚合成一个中央statsd,然后与Graphite进行对话.第一层statsds需要比第二层更短的刷新时间.为此,您需要一个statsd-to-statsd后端.由于我遇到了这个问题,我写了一个试图尽可能提高网络效率的问题：https://github.com/juliusv/ne-statsd-backend
事实上,不幸的是,statsd并未设计为以可管理的方式扩展(不,我不认为手动调整采样率是“可管理的”).但是如果你坚持下去,上面的解决方法应该会有所帮助.
