我想设置 statsd/graphite，以便我可以记录在 HTML 设备上运行的 JS 应用程序（即不在包含的 LAN 环境中，并且可能有大量我无法直接控制的传入数据）。
我的限制：
- 入口点必须使用 HTTP：这可以通过简单的 HTTP-to-UDP-statsd 代理解决（例如 github 上的 httpstatsd）
- 必须抵抗单个服务器的故障（对抗墨菲定律:)
- 必须是水平可扩展的：网络规模，宝贝！:)
- 架构应该尽可能保持简单（且便宜）
- 我的服务器是虚拟机
- 数据文件将存储在文件设备（带有 NFS）上
- 我有 tcp/udp 硬件负载平衡器可供使用
简而言之，数据路径：[client] -(http)-> [http2statsd] -(udp)-> [statsd] -(tcp)-> [graphite] -(nfs)-> [filer]
我目前的发现：
- 扩展 http2statsd 部分很容易（无状态守护进程）
- 扩展 statsd 部分似乎并不简单（我猜我最终会在 graphite 中得到不一致的值，例如 sum、avg、min、max 等聚合数据）。除非 HTTP 守护进程执行一致性哈希以分片密钥。也许这是一个好主意……（但接下来是 HA 问题）
- 可以通过分片（使用 carbon-relay）来扩展 graphite 部分（但这也不能解决 HA 问题）。显然，多个 whisper 实例不应该写入同一个 NFS 文件。
- 扩展文件部分不是问题的一部分（但 IO 越少越好:)
- 扩展 Web 应用似乎很明显（尽管我还没有测试过），因为它们只读取共享的 NFS 数据
所以我想知道是否有人有关于可靠的 statsd/graphite 部署的经验和最佳实践可以分享？
答案1
有一个具有一致性哈希的 statsd 代理，可以将 statsd 流量分散到多个 statsd 聚合器之间，每个聚合器都使用自己的一组指标名称。它是架构中至关重要的可扩展性元素，可让您扩展 statsd 进程。
石墨也很棘手，但希望你不需要无限的规模，并且可以通过服务或其他静态参数进行良好的分片。
最难的部分是扩展 Web 应用，这很大程度上取决于您最繁重的图形查询。不过，您始终可以预先聚合最难的图形的数据，并消除大部分负载。
我已经使用 HostedGraphite 很长一段时间来避免所有这些痛苦，这些家伙为 Carbon 实现了他们自己的 Riak 后端并在那里进行所有的扩展。