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

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

我的约束:

  • 入口点必须说HTTP:这是通过一个简单的HTTP-to-UDP-statsd代理(例如github上的httpstatsd)
  • 必须抵制单一服务器的失败(与墨菲定律对抗:)
  • 必须横向扩展:webscale,宝贝! 🙂
  • 架构应尽可能保持简单(和便宜)
  • 我的服务器是虚拟机
  • 数据文件将存储在Filer设备上(使用NFS)
  • 我有tcp / udp硬件负载平衡器处置

总之,数据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后端,并在那里进行所有扩展。