有人在 Nagios 上使用 check_mk 吗？在考虑之前我应该注意什么？

Question

我一直在几台开发机器上测试它，它看起来很漂亮。但是，我找不到有关它的部署的太多信息。有没有人积极运行这个？有没有人出于某种原因将其排除在外？

Answer 1

免责声明：我曾经参与过那个项目，因为我觉得它非常强大。（我仍然这么认为）

我从 2009 年开始使用它，除了遗留设置之外，从未再次触及“正常”（有人可能会说遗留）Nagios 设置。感觉就像是在浪费时间。

我所知道的最大设置是大约 1200 个监控服务器。（不是：受监控的服务器）那个也已发布，但原始问题早于它。

它现在被用在很多地方，这些地方对普通的 nagios 不满意，而不是像 OpenView 这样的更大规模的 NMS，并改变了主意。

关键的区别不在于可扩展性（因为 37signals 似乎非常喜欢），或者在远程系统中自动检测可监控的东西，这使得这一切变得轻而易举，甚至在添加了新的但未被监控的东西时也会提醒您。

不，从长远来看，真正重要的是配置，它严格基于规则（并写成 python）。仅仅 100 行 Check_MK 配置就足以让它生成 200K 行你永远不会回头看的老旧 nagios 语法。

它还具有基于 Web 的配置编辑器。与继承。和验证。
除其他外，GUI 还针对 WAN 链接进行了优化。它实际上是一个完整的 Web 框架，这就是为什么还有仪表板和日志分类引擎，可以接收 syslog 或 snmp 以使用灵活的规则集进行 Nagios 处理。
所有检查均按照高质量标准编写，并及时显示为用户节省时间。

不过没有小马。

人们经常对 Check_MK 和 Nagios 之间的交互感到困惑，这不是微不足道的，但实际上很好地分开：它编写配置，Nagios 使用该配置运行并调用 Check_MK 来监视系统。
如果有人没有使用图形配置编辑器“WATO”，那么他们被认为是 Nagios 的专家级别。
没有 GUI 操作手册！（但是：可以即时启用的内联帮助）
完美工作的 IPv6 支持补丁已经浮动多年，但无处可去。

还有更多的优点和缺点要提出，但我认为我已经很好地展示了双方。我个人喜欢 Check_MK 设置的效率，如果我必须使用 oldskool Nagios 设置，我真的很生气。即使他们使用了不错的模板框架，或者是从 Puppet 那里征用的，但在我看来，它仍然感到石化和无助。

免责声明：见上文;)

Answer 2

有人用吗？是的。

37signals（一家软件公司）刚刚发布了他们如何使用 nagios 监控系统的概述，以及他们开始使用 check_mk 时看到的主要好处。http://37signals.com/svn/posts/3178-nagios-monitoring-performance

有人在 Nagios 上使用 check_mk 吗？在考虑之前我应该​​注意什么？