Bosun HA和可扩展性

Question

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

我害怕由于网络开销而丢失数据，以及在出现故障的情况下。

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

此外，任何关于良好实践的输入都将有助于扩展bosun。

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

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

Answer 1

当前的最佳实践是：

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

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

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