statsd 和 Graphite 的高可用、Web 可访问和可扩展部署

Question

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

我的限制：

• 入口点必须说 HTTP：这是通过一个简单的 HTTP-to-UDP-statsd 代理解决的（例如 github 上的 httpstatsd）
• 必须抵抗单个服务器的故障（与墨菲定律作斗争：）
• 必须是水平可扩展的：webscale，宝贝！:)
• 架构应该尽可能简单（和便宜）
• 我的服务器是虚拟机
• 数据文件将存储在文件管理器设备上（使用 NFS）
• 我可以使用 tcp/udp 硬件负载平衡器

总之，数据路径：[client] -(http)-> [http2statsd] -(udp)-> [statsd] -(tcp)-> [graphite] -(nfs)-> [filer]

到目前为止我的发现：

• 扩展 http2statsd 部分很容易（无状态守护进程）
• 缩放 statsd 部分似乎并不简单（我想我最终会在石墨中得到不连贯的值，例如 sum、avg、min、max ...）。除非 HTTP 守护进程进行一致的散列以对密钥进行分片。也许是一个想法......（但接下来是 HA 问题）
• 缩放石墨部分可以通过分片（使用碳继电器）来完成（但这也不能解决 HA 问题）。显然，多个耳语实例不应写入相同的 NFS 文件。
• 缩放文件管理器部分不是问题的一部分（但 IO 越少越好:)
• 扩展 webapp 似乎很明显（虽然我没有测试过），因为它们只读取共享的 NFS 数据

所以我想知道是否有人有经验和最佳实践可以分享一个可靠的 statsd/graphite 部署？

Answer 1

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

石墨也很棘手，但希望您不需要无限的规模，并且可以通过服务或其他一些静态参数进行精细的分片。

最难的部分是扩展 Web 应用程序，这在很大程度上取决于您最重的图形查询是什么。但是，您始终可以预先聚合最难的图表的数据并消除大部分负载。

我已经使用 HostedGraphite 很长一段时间了，以避免所有这些痛苦，这些人已经为 Carbon 实现了自己的 Riak 后端，并在那里完成了所有的扩展。