statsd和石墨的高可用性，Web访问和可扩展的部署

我想设置statsd / graphite，这样我就可以logging在HTML设备上运行的JS应用程序（即不在包含的LAN环境中，并且可能有大量不直接控制的传入数据）。

我的约束：

总之，数据path：[client] – （http） – > [http2statsd] – （udp） – > [statsd] – （tcp） – > [graphite] – （nfs） – > [filer]

我的发现迄今为止：

缩放http2statsd部分很简单（无状态的守护进程）
缩放statsd部分似乎并不简单（我想我最终会得到非整数值的石墨集合数据，如sum，avg，min，max …）。除非HTTP守护进程为了分割密钥而执行一致性散列。也许是一个想法…（但那是医pipe局的问题）
缩放石墨部分可以通过分解（使用碳中继）完成（但是这也不能解决HA问题）。显然几个耳语实例不应该写入相同的NFS文件。
缩放文件pipe理器部分不是问题的一部分（但IO越less越好:)
缩放webapp似乎很明显（虽然我没有testing），因为他们只读取共享的NFS数据

所以我想知道是否有人有经验和最佳做法，分享一个坚实statsd /石墨部署？

有一个统一的散列代理，可以在多个statsd聚合器之间传播statsdstream量，每个聚合器使用自己的一组度量名称。这是您的架构中至关重要的可扩展性元素，允许您扩展statsd进程。

石墨也是棘手的，但希望你不会需要无限的规模，可以做服务或其他一些静态参数的细分。

最难的部分是缩放web应用程序，这很大程度上取决于什么是最重的graphics查询。但是，您总是可以预先聚合最难的graphics数据，摆脱大部分负载。

我已经使用HostedGraphite相当长一段时间来避免所有这些痛苦，这些家伙已经为Carbon实现了自己的Riak后端，并在那里进行所有扩展。