对Nagios适用性的争论-InfoQ



 写点什么

在最近一次的伦敦DevOps 集会上， Andy Sykes 引发了一场是否应该使用更好的解决方案来替代 Nagios 的争论（Nagios 是提供监控和告警服务的知名应用）。

Andy 承认，Nagios 拥有简单的插件模型，并且从概念上说具有简单性和可靠性。但是其缺点更为显著。他认为，Nagios 难以扩展，因为它不支持任何类型的集群。而且配置起来也比较麻烦，会涉及到大量服务器与客户端之间的复制。此外，另一个痛点则是缺乏一套简化系统整合与自定义仪表盘创建过程的 API。在这个弹性和云的时代里，需要将新客户端告知主机，也将被视作一项重大缺陷。

针对 Nagios 的不足之处，Andy 给出了一些应对建议。他推荐采用 Sensu 应对监控问题，使用 Graphite 满足图形绘制需求，以及将 Flapjack 用于告警服务。不过对于探测异常和用户界面方面，Andy 认为目前还没有什么合适的产品。

对此， Laurie Denness 则持有不同意见，并阐述了为何Etsy 将继续使用Nagios。针对Andy 提出的每条观点，Laurie 都进行了辩驳。

Laurie 表示，对 Etsy 来说，“我们的主数据中心有 1 万项检查。一般而言每隔 2 到 3 分钟，就进行一组 30 秒的检查”。对此，必须进行一些优化调整。团队启用了 Nagios 的 use_large_installation_tweaks 标志以降低延迟，并且在惠普和戴尔服务器上禁用了扩展设置——因为 Nagios 似乎与这些设备使用的电源管理算法并不十分兼容。当 Etsy 开始使用两个数据中心时，他们选择在每个数据中心里安置一个 Nagios 实例，并使用 Nagdash 将状态和报告聚合在一起。

在配置方面，Laurie 宣称：

如果你花费时间来挑选 Nagios 配置文件，那么或许你无论如何都会喜欢它，并且正在大规模重写旧有的配置；要么或许走在了错误的路上。将之自动化是很容易的事情。

Etsy 同时也在使用 nagios-api ——这个第三方项目面向 Nagios，提供了类 REST 的 JSON 接口以将其自动化。

针对 Andy 眼中 Nagios 目前的不足之处，Laurie 给出了更为广泛的阐述。他认为，Unix 哲学适用于使用 Nagios 的工作：“以许多小型部件和应用为基础，它们都负责应对特定的小规模问题，而用户使用管线将它们关联为一体。”事实上，Nagios 拥有强大的生态系统，在 Laurie 看来这是一项强有力的优势。

在谈到 Laurie 的见解时， Theo Schlossnagle 延续了“Nagios 尚有不足”的思路：