地理分布式、容错和“智能”应用/主机监控系统

Question

你好，

我想问一下集体对分布式监控系统的看法和看法，您使用什么以及您知道哪些可能符合我的要求？

要求相当复杂；

• 没有单点故障。真的。我是认真的！需要能够容忍单/多节点故障，包括“主节点”和“工作节点”，您可以假设没有监控位置（“站点”）中有多个节点，或者位于同一网络上。因此，这可能排除了传统的 HA 技术，例如 DRBD 或 Keepalive。

• 分布式逻辑，我想在多个网络、多个数据中心和多个大陆上部署 5 个以上的节点。我希望从我的客户的角度来看我的网络和应用程序的“鸟瞰”视图，当你有 50 多个节点，甚至 500 多个节点时，监控逻辑的加分不会陷入困境。

• 需要能够处理相当合理数量的主机/服务检查，就像 Nagios，一般假设有 1500-2500 个主机和 30 个服务每个主机。如果添加更多监控节点允许您相对线性地扩展，那就太好了，也许在 5 年内我可能希望监控 5000 台主机和每台主机 40 个服务！从我上面关于“分布式逻辑”的注释中添加，很高兴地说：

  • 在正常情况下，这些检查必须在 $n 或 n% 的监控节点上运行。
  • 如果检测到故障，则对另一个 $n 或 n% 的节点运行检查，关联结果，然后使用它们来确定是否满足标准以发出警报。

• 图形和管理友好的功能。我们需要跟踪我们的 SLA，了解我们的“高可用”应用程序是否 24x7 都在一定程度上有用。理想情况下，您提出的解决方案应该以最少的方式进行“开箱即用”的报告。

• 必须有一个可靠的 API 或插件系统来开发定制检查。

• 需要了解警报。我不想知道（通过 SMS，凌晨 3 点！）一个监控节点认为我的核心路由器已关闭。我确实想知道他们中是否有一定比例的人同意正在发生一些时髦的事情；) 基本上我在这里谈论的是“法定人数”逻辑，或者将理智应用于分布式疯狂！

我愿意同时考虑商业和开源选项，尽管我更愿意避开价值数百万英镑的软件:-) 我也愿意接受可能没有任何东西可以满足所有这些要求，但是想问问集体那个。

在考虑监控节点及其位置时，请记住其中大部分将是随机 ISP 网络上的专用服务器，因此在很大程度上超出了我的控制范围。依赖 BGP 馈送和其他复杂网络操作的解决方案可能不适合。

我还应该指出，过去我已经评估、部署或大量使用/定制了大多数开源风格，包括 Nagios、Zabbix 和朋友——它们确实不是坏工具，但总体上还是平庸的。”分布式”方面，特别是关于我的问题和“智能”警报中讨论的逻辑。

很高兴澄清所需的任何要点。欢呼吧伙计们和女孩们:-)

Answer 1

不是真正的答案，而是一些指示：

• 一定要看看有关nagios 的演示@goldman sachs。他们面临着你提到的问题——冗余、可扩展性：数千台主机，还有自动配置生成。

• 我有冗余的 nagios 设置，但规模要小得多 - 80 台服务器，总共约 1k 服务。一台专用主服务器，一台从服务器每天定期几次从主服务器拉取配置。两台服务器都监控同一台机器，它们之间进行健康交叉检查。我主要使用 nagios 作为调用自定义产品特定检查的框架 [一堆 cron 作业执行执行“人工流程控制”的脚本，结果软件记录到 sql，nrpe 插件软件检查过去 x 分钟内成功/失败的执行情况]。一切都工作得很好。

• 你的仲裁逻辑听起来不错 - 有点类似于我的“人工流程” - 基本上继续，实现你自己；-]。并让 nrpe 只是检查某种标志[或带有时间戳状态的 sql db] 事情的进展情况。

• 您可能想要构建一些可扩展的层次结构 - 您将有一些节点收集其他节点的概述，请从第一点开始查看演示。在受监控服务数量较多的情况下，每次检查的默认 nagios 分叉都显得过分了。

回答一些问题：

• 在我的例子中，监控的环境是典型的主从设置[主sql或应用程序服务器+热备用]，没有主从。
• 我的设置涉及“人为过滤因素” - 解析器组是短信通知的“备份”。已经有一组受薪技术人员由于其他原因进行 24/5 轮班，他们将“检查 nagios 邮件”作为额外任务，不会给他们带来太多负担。他们负责确保 db-admins / it-ops / app-admins ware 真正启动并解决问题；-]
• 我听说过很多关于zabbix的好消息——用于警报和绘制趋势，但从未使用过它。对我来说， munin可以解决这个问题，我已经破解了简单的 nagios 插件，检查 munin 服务器列表上是否有“任何红色”[关键]颜色 - 只是一个额外的检查。您还可以从 munin rrd 文件读取值，以减少发送到受监控计算机的查询数量。