monitoring - Bosun HA 和可扩展性

Question

我有一个小型的水手长设置，它从众多服务中收集指标，我们计划在云上扩展这些服务。 这将意味着更多的数据进入bosun，因此bosun的负载/效率/规模会受到影响。

我担心由于网络开销以及发生故障而丢失数据。

我正在寻找 bosun 的任何性能基准报告，或有关规模和 HA 的基准测试/测试 bosun 的任何输入。

此外，任何有关扩大水手长规模的良好实践的意见都会有所帮助。

我目前的想法是运行大量的 bosun 二进制文件作为一个集群，由分布式 opentsdb 设置支持。 另外，我在想是否值得运行一些 bosun 执行器作为 scollector 数据的普通“收集器”(使用 bosun -n 命令)，以及一些仅计算警报的执行器。

这种方法的问题是，多个 bosun 实例可能会触发相同的警报(不带选项 -n 运行)。有没有更好的方法来消除重复的警报？

Answer 1

当前的最佳实践是:

1. 使用https://godoc.org/bosun.org/cmd/tsdbrelay将指标转发到 opentsdb。这使得水手长二进制文件脱离了“关键路径”。它还应该将指标转发给 bosun 进行索引，并且可以将指标流复制到多个数据中心以进行灾难恢复/备份。
2. 确保您的 hadoop/opentsdb 集群至少有 5 个节点。您无法在 3 节点集群上进行实时维护，并且 hadoop 通常运行在十几个或更多节点上。我们使用Cloudera Manager来管理hadoop集群，其他人推荐了Apache Ambari。
3. 使用 HAProxy 等负载均衡器以主动/被动模式在 tsdbrelay 的多个实例之间拆分/api/put 写入流量。我们在每个节点上运行一个实例(tsdbrelay 转发到本地 opentsdb 实例)，并将所有写入流量定向到主写入节点(具有多个辅助/备份节点)。
4. 以主动/主动模式(也称为循环或基于哈希的路由)将/api/query 流量拆分到直接指向 opentsdb 的其余节点(无需通过中继)。这通过在非写入节点之间平衡查询来提高查询性能。
5. 我们只在每个数据中心运行一个 bosun 实例，灾难恢复站点使用只读标志(任何故障转移都是手动的)。它实际上还不是为 HA 设计的，但将来可能允许两个节点共享一个 Redis 实例并允许主动/主动或主动/被动 HA。

通过使用 tsdbrelay 复制指标流，您不必处理 opentsdb/hbase 复制，而是可以在每个数据中心设置多个独立的监控系统，并将指标复制到任何合适的站点。我们有一个主站点和一个灾难恢复站点，并选择将所有指标复制到两个数据中心。实际上，我每天都使用 DR 站点进行 Grafana 查询，因为它离我住的地方更近。

您可以在http://bosun.org/resources找到有关生产设置的更多详细信息。包括我们在 Stack Overflow 上使用的所有 haproxy/tsdbrelay/etc 配置文件的副本。