自從加入37Signals公司以來，我一直在努力改善企業的監控基礎設施。我們的主要監控方案采用的是Nagios，它與老款沃爾沃倒有幾分神似——也許外觀不夠漂亮、也許速度不夠驚人，但它易于使用、而且絕不會讓人束手無策。
下面聊幾句背景信息。2009年1月時，我們擁有350項Nagios服務。而到了2010年9月，我們所使用的服務數量上升至797項，目前則已經達到7566項之巨。在數字迅猛增長的同時，我們還大幅降低了故障警報的出現頻率，現在幾乎很少會有管理員會被大半夜拉起來處理緊急情況。當然，整個過程也出現過一些波折，但這一切都是為了實現更好的監控效果。在本文中，我希望與大家分享一些在使用Nagios過程中總結出的實用提示，進而幫助各位在擴展及改進監控系統時獲得一些引導。
與37signals公司中的大多數方案一樣，我們的Nagios環境也由Chef平臺牢牢掌控。當新的主機配置完成后，它們會被自動添加到監控系統當中。一年多之前，我們只能以自動化方式監控主機上的少數事務：磁盤使用率、負載以及內存等。
擴大監控范圍
為了扭轉局面，我們做的第一件事就是安裝Check_MK。Check_MK是一款Nagios插件，能夠自動清查主機、收集性能數據，并且提供了一套更友善的UI。在Check_MK的幫助下，我們現在能夠以自動化方式在每臺主機上監控20項指標；由Postfix隊列發往開放TCP連接的所有信息都能受到監控。Check_MK還提供了一套非常實用的后端，即mk_livestatus，允許我們向Nagios查詢實時主機、服務信息以及即將發送的處理指令。舉例來說，我們利用Livestatus來訓練Campfire機器人接收警報并設定停機時間。通過Tally，現在我們幾乎可以通過Campfire完成全部Nagios交互工作。
我們還逐步在Nagios中添加了大量針對特定應用程序的監控方案——我們利用statsd追蹤響應時間、錯誤代碼及其它各種有助于衡量應用程序性能的指標，此外MySQL、Redis以及Memcached統計數字也被納入了進來。要想在客戶發現問題前將其消滅在萌芽階段，這些監控手段是必不可少的。額外檢查項目的加入使我們對系統運行狀態有了更為直觀的了解，但凡事有利就有弊：由于監控方案的大幅加強，我們安裝并運行Nagios的主機在性能方面承受著很大壓力。
存在的問題
對于中小型使用環境而言，Nagios的開箱即用效果非常突出；但我們很快發現了一些局限性，而這給我們帶來不小的麻煩。首先，由于Nagios常常拿不出足夠的資源執行檢查工作，因此在設定檢查與執行檢查之間往往存在45秒的延遲。為了降低這種延遲，我們對安裝配置做出了大量調整，其中一項效果明顯，直接將平均延遲時間壓縮至0.3秒以內。遺憾的是由此帶來的主機負載也同樣明顯——Nagios在給定時段中的檢查活動數量受到影響，延遲檢查出于資源節約考慮而被自動忽略掉了。在放開這一性能瓶頸后，我們的負載強度由5%上升到30%左右（我們的主監控服務器采用兩塊至強E5530處理器）。
最后，我決定在負載失控之前進行檢查數量縮減。經過實踐，我們發現縮減使用頻率最高的check_mk代理檢查對于負載的影響微乎其微，但將其它幾項活動檢查的執行頻繁降低一半則大大減輕了主機負載——由30%下降至10%以下。由此我們可以看出，主動服務才是節約性能的最大敵人，必須不惜一切代價予以消除。
Nagios服務上手指南
● 主動服務是指那些由可執行shell腳本所定義、能夠由Nagios直接執行的檢查項目。這項服務需要進行時間間隔設定，進入調度程序后會根據進程啟用情況自動執行。Nagios必須進行shell釋放、執行檢查腳本、等待結果、分析結果、將結果添加到命令緩沖區然后處理結果等一系列工作，且在整個檢查過程中該線程會保持運行并不能用于任何其它工作。
● 被動服務是指那些由Nagios（例如check_mk代理檢查）或其它機制所觸發、但不會被Nagios服務器主動啟用的檢查項目。在存在被動檢查結果時，外部進程會直接將結果添加至命令緩沖區中，并由Nagios將其作為主動檢查結果進行處理。Nagios并不會對此類檢查進行調度或者利用資源加以執行，因此這些檢查所占用的資源也少得多。
我們的大多數主動服務都會向內部儀表板應用發送HTTP請求，旨在獲取前文提到過的應用及數據庫指標。由于Nagios主動檢查指標的方案會占用過多硬件資源，我們決定定期通過網頁接口推送來自Statsd的更新信息（這一機制由Slanger庫實現）。要做到這一點，我們在Chef上創建一個配置文件，其中包含我們所需要的指標、相關閾值以及簡潔的后臺訂閱描述。這樣檢查結果數據就會定期被發送至Livestatus處，并被添加到命令緩沖區中進行處理。我們還將這些來自儀表板的推送檢查與其它腳本檢查加以整合。
結果匯總
與我們的預期一致，將服務轉為被動屬性大大降低了Nagios的CPU使用率，具體情況如下圖所示：
總而言之，我們將主動服務的數量由1900降低到745。幸存下來的檢查項目大多必須采取主動狀態——例如ping檢查、Check_MK代理以及應用程序HTTP檢查等。因為只有這樣我們才能在項目出現問題時及時得到警告。
從某種程度來說，這只是種負載轉移過程——某些負載被轉嫁到其它主機當中，并通過檢查腳本或者后臺推送程序將結果傳遞給Nagios。不過這種收益還是相當顯著且順理成章的（將負載分攤到服務器閑置資源中），我們還通過對檢查腳本的重新編寫改裝最系統全局執行效率、消除了成千上萬HTTP請求所帶來的資源占用。更重要的是，我們在恢復原有檢查間隔的同時還添加了一些新的監控項目，并且始終將負載控制在3%、延遲控制在0.5秒以下。
希望我在打理監控基礎設施方面的經驗能幫助大家找到實際問題的解決辦法。過去那種“添加其它可執行腳本”的方式實在太過狹隘，其實我們完全能以其它方式更好地搞定難題。從某種意義上說，即使各位的監控系統并沒有出問題，這篇文章也能在進一步提升性能表現方面有所借鑒。