http://mathias-kettner.de/check_mk.html
我已经在几台开发机器上测试过它，它看起来很不错。但是我找不到太多关于它的部署信息。有人在积极运行它吗？是否有人出于某种原因排除了这个选项？
答案1
免责声明：我曾经从事该项目是因为我觉得它非常强大。（我现在仍然这么认为）
我从 2009 年开始使用它，除了旧版设置外，我再也没有接触过“正常”（也可以说是旧版）Nagios 设置。感觉就像是在浪费时间。
我所知道的最大设置是~1200 个监控服务器。（不是：受监控的服务器）那个也发布了，但是原始问题早于它。
现在，很多地方都开始使用它，这些地方对简单的 nagios 不太满意，而对于像 OpenView 这样的更大规模的 NMS，他们改变了主意。
主要的区别不是可扩展性（37signals 似乎非常喜欢），也不是对远程系统中可监控事物的自动检测，这使得一切都变得轻而易举，甚至在添加了新的东西但未被监控时也会提醒您。
不，真的是一件大事从长远来看，配置是严格基于规则的（并以 python 写出）。几百行 Check_MK 配置足以让它生成 200K 行您永远不会回头的无聊的 nagios 语法。
- 它还具有基于 Web 的配置编辑器。具有继承和验证功能。
- 除了其他功能外，GUI 还针对 WAN 链接进行了优化。它实际上是一个完整的 Web 框架，因此还配备了仪表板和日志分类引擎，可以使用灵活的规则集接收 syslog 或 snmp 以供 Nagios 处理。
- 所有支票均按照高质量标准书写，并为用户节省了时间。
虽然没有小马。
- 人们常常对 Check_MK 和 Nagios 之间的交互感到困惑，其实它们并不简单，但实际上很好地分开了：它编写配置，Nagios 使用该配置运行并调用 Check_MK 来监控系统。
- 如果有人不是使用图形配置编辑器“WATO”，他们被认为具有 Nagios 专家级别。
- 没有 GUI Ops 手册！（但可以随时启用内联帮助）
- 完美运行的 IPv6 支持补丁已经发布多年，但却没有任何进展。
还有许多优点和缺点需要提出，但我认为我已经很好地展示了双方的观点。就我个人而言，我喜欢 Check_MK 设置的效率，如果必须使用老式的 Nagios 设置，我会非常恼火。即使它们使用了不错的模板框架或从 Puppet 中征用，在我看来，它仍然显得陈旧和无助。
免责声明：见上文；）
答案2
有人用过吗？有的。
37signals（一家软件公司）刚刚发布了一份概述，介绍了他们如何使用 nagios 监控他们的系统，以及他们开始使用 check_mk 时看到的主要好处。http://37signals.com/svn/posts/3178-nagios-monitoring-performance
答案3
我目前正在生产服务器中使用 CheckMk，它的表现确实相当不错。感谢 check_mk 的经验。您可以在这里找到官方指南https://checkmk.com/cms.html