高可用性、可Web访问和可伸缩的statsd和石墨部署

Question

我想要设置statsd/石墨，以便我可以记录运行在HTML设备上的JS应用程序(即。不在包含的LAN环境中，而且可能有大量我无法直接控制的传入数据)。

我的制约因素：

• 入口点必须使用HTTP:这是通过一个简单的statsd代理来解决的。(github上的httpstatsd )
• 必须抵抗单个服务器的失败(对抗墨菲定律:)
• 必须是水平可伸缩的: webscale，宝贝！:)
• 架构应尽可能简单(且便宜)。
• 我的服务器是虚拟机
• 数据文件将存储在filer设备上(使用NFS)。
• 我有tcp/udp硬件负载均衡器。

简而言之，数据路径：客户端 -(http)-> http2statsd -(udp)-> 状态%d -(tcp)-> 石墨 -(nfs)-> 滤片器

到目前为止，我的发现是：

• 缩放http2statsd部件很容易(无状态守护进程)
• 缩放statsd部分看起来并不简单(我想我最终会得到聚合数据的非相干值，如sum、avg、min、max .)。除非HTTP守护进程执行一致的散列以分割密钥。也许是个主意..。(但还有医管局的问题)
• 缩放石墨部分可以通过切分(使用碳继电器)(但这也解决不了HA问题)。显然，有几个窃窃私语实例不应该编写相同的NFS文件。
• 缩放filer部分并不是问题的一部分(但是IO越少，越好:)
• 扩展webapp似乎很明显(尽管我还没有测试)，因为他们只读取共享的NFS数据

因此，我想知道是否有人有经验和最佳实践来分享一个坚实的状态/石墨部署？

Answer 1

有一个具有一致散列的statsd代理，这使得在多个statsd聚合器之间传播statsd通信成为可能，每个聚合器使用自己的一组度量名称。它是体系结构中的一个关键的可伸缩性元素，允许您扩展statsd进程。

石墨也是棘手的，但希望你不会需要无限的规模，只需通过服务或其他静态参数进行精细分片。

最困难的部分是缩放webapp，这在很大程度上取决于您最大的图形查询是什么。但是，对于最困难的图，您总是可以预先聚合数据，并摆脱大部分负载。

为了避免这些痛苦，我已经使用HostedGraphite很长一段时间了，这些家伙已经实现了他们自己的Riak后端的碳，并做了所有的缩放。