有人对Nagios使用check_mk吗？在考虑之前，我应该知道什么？

http://mathias-kettner.de/check_mk.html

我已经在几个开发机器上对其进行了测试，这似乎很不错。但是，我找不到有关它的部署的很多信息。有人积极运行吗？有人出于某种原因将其排除在外吗？

免责声明：我曾经从事该项目，因为我觉得它非常强大。（我仍然这么认为）

我从2009ish开始使用它，除了旧版设置外，再也没有接触过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设置的效率，如果不得不使用oldskool Nagios设置，我会感到非常恼火。即使他们使用了不错的模板框架，或是从Puppet手中抢夺了它，但与我相比，它仍然感到年事已高，无助。

免责声明：见上文；）

有人用吗？是。

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