在最近一次的伦敦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尚有不足”的思路：
|
对运营方面来说，我们需要的是读取系统遥测信息，并针对其行为提供深入的洞见。这是一个宽泛的任务，必须对收集到的数据进行分析。然而，Nagios以及其他类似设计的五花八门的产品，都不支持这种做法。 |
