最近在伦敦举行的DevOps会议上，AndySykes引发了关于是否应该有更好的解决方案取代Nagios（一种提供监控和警报服务的知名应用程序）的争论。Andy承认Nagios有一个简单的插件模型，并且在概念上简单可靠。但其缺点更为显着。他认为Nagios很难扩展，因为它不支持任何类型的集群。而且配置起来比较麻烦，会涉及到服务器和客户端之间的大量复制。此外，另一个痛点是缺乏一套API来简化系统集成和自定义仪表板创建的过程。在这个弹性和云时代，需要通知主机新客户也将被视为一个主要缺点。针对Nagios的不足，Andy给出了一些建议。他推荐Sensu用于监控，Graphite用于图形需求，Flapjack用于警报。不过，在检测异常和用户界面方面，安迪认为目前还没有合适的产品。对此，LaurieDenness持不同意见，并解释了为什么Etsy会继续使用Nagios。劳里驳斥了安迪提出的每一个观点。对于Etsy，“我们在主数据中心进行了10,000次检查。通常每两到三分钟，就有一组30秒的检查，”Laurie说。为此，必须进行一些优化调整。该团队启用了Nagios的use_large_installation_tweaks标志以减少延迟，并禁用了惠普和戴尔服务器上的缩放设置——因为Nagios似乎与这些设备使用的电源管理算法不太兼容。当Etsy开始使用两个数据中心时，他们选择在每个数据中心中放置一个Nagios实例，并使用Nagdash来汇总状态和报告。在配置方面，Laurie宣称：如果您花时间挑选Nagios配置文件，那么也许您无论如何都会喜欢它并且正在对旧配置进行大量重写；或者也许你走错了路。很容易实现自动化。Etsy还使用nagios-api——Nagios的第三方项目，它提供类似REST的JSON接口来实现自动化。对于目前Nagios在Andy眼中的不足之处，Laurie给出了更宽泛的解释。他认为Unix哲学适用于与Nagios一起工作：“基于许多小组件和应用程序，所有这些组件和应用程序都负责特定的小规模问题，用户使用管道将它们连接在一起。”事实上，Nagios拥有强大的Ecosystem，在Laurie看来，这是一个强大的优势。TheoSchlossnagle在谈到Laurie的洞察时延续了“Nagiosisnotenough”的思路：对于运维，我们需要的是读取系统遥测数据并提供对其行为的深刻洞察。这是一项广泛的任务，必须对收集到的数据进行分析。但是，Nagios和其他各种类似设计的产品不支持这种方法。查看英文原文：讨论NagiosFitnessforPurpose
