2

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

由于网络开销以及发生故障，我害怕丢失数据。

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

此外，任何有关扩大 bosun 规模的良好做法的投入都会有所帮助。

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

这种方法的问题在于，可能会从多个 bosun 实例触发相同的警报（在没有选项的情况下运行-n）。有没有更好的方法来重复警报？

4

1 回答 1

2

当前的最佳实践是：

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

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

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

于 2016-09-02T16:31:18.143 回答