對Nagios適用性的爭論
在最近一次的倫敦DevOps集會上，Andy Sykes引發(fā)了一場是否應該使用更好的解決方案來替代Nagios的爭論（Nagios是提供監(jiān)控和告警服務的知名應用）。
Andy承認，Nagios擁有簡單的插件模型，并且從概念上說具有簡單性和可靠性。但是其缺點更為顯著。他認為，Nagios難以擴展，因為它不支持任何類型的集群。而且配置起來也比較麻煩，會涉及到大量服務器與客戶端之間的復制。此外，另一個痛點則是缺乏一套簡化系統(tǒng)整合與自定義儀表盤創(chuàng)建過程的API。在這個彈性和云的時代里，需要將新客戶端告知主機，也將被視作一項重大缺陷。
針對Nagios的不足之處，Andy給出了一些應對建議。他推薦采用Sensu 應對監(jiān)控問題，使用Graphite滿足圖形繪制需求，以及將Flapjack 用于告警服務。不過對于探測異常和用戶界面方面，Andy認為目前還沒有什么合適的產(chǎn)品。
對此，Laurie Denness則持有不同意見，并闡述了為何Etsy將繼續(xù)使用Nagios。針對Andy提出的每條觀點，Laurie都進行了辯駁。
Laurie表示，對Etsy來說，“我們的主數(shù)據(jù)中心有1萬項檢查。一般而言每隔2到3分鐘，就進行一組30秒的檢查”。對此，必須進行一些優(yōu)化調整。團隊啟用了Nagios的use_large_installation_tweaks標志以降低延遲，并且在惠普和戴爾服務器上禁用了擴展設置——因為Nagios似乎與這些設備使用的電源管理算法并不十分兼容。當Etsy開始使用兩個數(shù)據(jù)中心時，他們選擇在每個數(shù)據(jù)中心里安置一個Nagios實例，并使用Nagdash將狀態(tài)和報告聚合在一起。
在配置方面，Laurie宣稱：
| 如果你花費時間來挑選Nagios配置文件，那么或許你無論如何都會喜歡它，并且正在大規(guī)模重寫舊有的配置；要么或許走在了錯誤的路上。將之自動化是很容易的事情。 Etsy同時也在使用nagios-api——這個第三方項目面向Nagios，提供了類REST的JSON接口以將其自動化。 |
針對Andy眼中Nagios目前的不足之處，Laurie給出了更為廣泛的闡述。他認為，Unix哲學適用于使用Nagios的工作：“以許多小型部件和應用為基礎，它們都負責應對特定的小規(guī)模問題，而用戶使用管線將它們關聯(lián)為一體。”事實上，Nagios擁有強大的生態(tài)系統(tǒng)，在Laurie看來這是一項強有力的優(yōu)勢。
在談到Laurie的見解時，Theo Schlossnagle延續(xù)了“Nagios尚有不足”的思路：
|
對運營方面來說，我們需要的是讀取系統(tǒng)遙測信息，并針對其行為提供深入的洞見。這是一個寬泛的任務，必須對收集到的數(shù)據(jù)進行分析。然而，Nagios以及其他類似設計的五花八門的產(chǎn)品，都不支持這種做法。 |
