有没有人使用Nagios的check_mk？ 在考虑之前，我应该注意什么？

免责声明：我曾经在这个项目上工作，因为我觉得它非常强大。 （我仍然这么认为）

我自2009年以来一直使用它，除了传统设置从未触及“正常”（可以说遗留）Nagios再次设置。 这会浪费时间。

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

现在已经在相当多的地方使用了，而不是像OpenView这样的大规模networkingpipe理系统，而是对普通的Nagios不满意，并且改变了他们的想法。

关键的区别不在于可扩展性（因为37信号看起来非常喜欢），或者在远程系统中自动检测可监测的事物，这使得这些都成为恶作剧，甚至在新的事物被添加但没有被监控时发出警报。

不，从长远来看真正重要的是configuration，这是严格的规则为基础（并写成python）。 几行100行的Check_MKconfiguration就足以让它产生200K行旧的无聊的nagios语法，你永远不会回头看。

• 它也有一个基于Web的configuration编辑器。 inheritance。 并validation。
• 除此之外，GUI还针对WAN链路进行了优化。 而且它实际上是一个完整的Web框架，这就是为什么还有仪表板和一个日志分类引擎，可以采用syslog或snmp来处理Nagios，并使用灵活的规则集。
• 所有的检查都是按照高质量标准书写的，并且为用户节省时间。

虽然没有小马

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

还有更多的优点和缺点，但我想我已经performance出了双方的良好。 就我个人而言，我喜欢Check_MK设置的效率，如果我必须使用oldskool Nagios设置，我真的很烦恼。 即使他们使用了漂亮的模板框架，或者从Puppet中获取了它，仍然感到石头老化，无奈与我比较。

免责声明：见上文;）

有人使用它吗？ 是。

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