【2013年2月22日 51CTO外電頭條】自從加入37Signals公司以來，我一直在努力改善企業(yè)的監(jiān)控基礎設施。

我們的主要監(jiān)控方案采用的是Nagios，它與老款沃爾沃倒有幾分神似——也許外觀不夠漂亮、也許速度不夠驚人，但它易于使用、而且絕不會讓人束手無策。

下面聊幾句背景信息。2009年1月時，我們擁有350項Nagios服務。而到了2010年9月，我們所使用的服務數(shù)量上升至797項，目前則已經(jīng)達到7566項之巨。

在數(shù)字迅猛增長的同時，我們還大幅降低了故障警報的出現(xiàn)頻率，現(xiàn)在幾乎很少會有管理員會被大半夜拉起來處理緊急情況。

當然，整個過程也出現(xiàn)過一些波折，但這一切都是為了實現(xiàn)更好的監(jiān)控效果。在本文中，我希望與大家分享一些在使用Nagios過程中總結出的實用提示，進而幫助各位在擴展及改進監(jiān)控系統(tǒng)時獲得一些引導。

與37signals公司中的大多數(shù)方案一樣，我們的Nagios環(huán)境也由Chef平臺牢牢掌控。當新的主機配置完成后，它們會被自動添加到監(jiān)控系統(tǒng)當中。一年多之前，我們只能以自動化方式監(jiān)控主機上的少數(shù)事務：磁盤使用率、負載以及內(nèi)存等。

擴大監(jiān)控范圍

為了扭轉(zhuǎn)局面，我們做的第一件事就是安裝Check_MK。Check_MK是一款Nagios插件，能夠自動清查主機、收集性能數(shù)據(jù)，并且提供了一套更友善的UI。在Check_MK的幫助下，我們現(xiàn)在能夠以自動化方式在每臺主機上監(jiān)控20項指標；由Postfix隊列發(fā)往開放TCP連接的所有信息都能受到監(jiān)控。Check_MK還提供了一套非常實用的后端，即mk_livestatus，允許我們向Nagios查詢實時主機、服務信息以及即將發(fā)送的處理指令。舉例來說，我們利用Livestatus來訓練Campfire機器人接收警報并設定停機時間。通過Tally，現(xiàn)在我們幾乎可以通過Campfire完成全部Nagios交互工作。

我們還逐步在Nagios中添加了大量針對特定應用程序的監(jiān)控方案——我們利用statsd追蹤響應時間、錯誤代碼及其它各種有助于衡量應用程序性能的指標，此外MySQL、Redis以及Memcached統(tǒng)計數(shù)字也被納入了進來。要想在客戶發(fā)現(xiàn)問題前將其消滅在萌芽階段，這些監(jiān)控手段是必不可少的。額外檢查項目的加入使我們對系統(tǒng)運行狀態(tài)有了更為直觀的了解，但凡事有利就有弊：由于監(jiān)控方案的大幅加強，我們安裝并運行Nagios的主機在性能方面承受著很大壓力。

存在的問題

對于中小型使用環(huán)境而言，Nagios的開箱即用效果非常突出；但我們很快發(fā)現(xiàn)了一些局限性，而這給我們帶來不小的麻煩。首先，由于Nagios常常拿不出足夠的資源執(zhí)行檢查工作，因此在設定檢查與執(zhí)行檢查之間往往存在45秒的延遲。為了降低這種延遲，我們對安裝配置做出了大量調(diào)整，其中一項效果明顯，直接將平均延遲時間壓縮至0.3秒以內(nèi)。遺憾的是由此帶來的主機負載也同樣明顯——Nagios在給定時段中的檢查活動數(shù)量受到影響，延遲檢查出于資源節(jié)約考慮而被自動忽略掉了。在放開這一性能瓶頸后，我們的負載強度由5%上升到30%左右（我們的主監(jiān)控服務器采用兩塊至強E5530處理器）。

最后，我決定在負載失控之前進行檢查數(shù)量縮減。經(jīng)過實踐，我們發(fā)現(xiàn)縮減使用頻率最高的check_mk代理檢查對于負載的影響微乎其微，但將其它幾項活動檢查的執(zhí)行頻繁降低一半則大大減輕了主機負載——由30%下降至10%以下。由此我們可以看出，主動服務才是節(jié)約性能的最大敵人，必須不惜一切代價予以消除。

Nagios服務上手指南

• 主動服務是指那些由可執(zhí)行shell腳本所定義、能夠由Nagios直接執(zhí)行的檢查項目。這項服務需要進行時間間隔設定，進入調(diào)度程序后會根據(jù)進程啟用情況自動執(zhí)行。Nagios必須進行shell釋放、執(zhí)行檢查腳本、等待結果、分析結果、將結果添加到命令緩沖區(qū)然后處理結果等一系列工作，且在整個檢查過程中該線程會保持運行并不能用于任何其它工作。
• 被動服務是指那些由Nagios（例如check_mk代理檢查）或其它機制所觸發(fā)、但不會被Nagios服務器主動啟用的檢查項目。在存在被動檢查結果時，外部進程會直接將結果添加至命令緩沖區(qū)中，并由Nagios將其作為主動檢查結果進行處理。Nagios并不會對此類檢查進行調(diào)度或者利用資源加以執(zhí)行，因此這些檢查所占用的資源也少得多。

我們的大多數(shù)主動服務都會向內(nèi)部儀表板應用發(fā)送HTTP請求，旨在獲取前文提到過的應用及數(shù)據(jù)庫指標。由于Nagios主動檢查指標的方案會占用過多硬件資源，我們決定定期通過網(wǎng)頁接口推送來自Statsd的更新信息（這一機制由Slanger庫實現(xiàn)）。要做到這一點，我們在Chef上創(chuàng)建一個配置文件，其中包含我們所需要的指標、相關閾值以及簡潔的后臺訂閱描述。這樣檢查結果數(shù)據(jù)就會定期被發(fā)送至Livestatus處，并被添加到命令緩沖區(qū)中進行處理。我們還將這些來自儀表板的推送檢查與其它腳本檢查加以整合。

結果匯總

與我們的預期一致，將服務轉(zhuǎn)為被動屬性大大降低了Nagios的CPU使用率，具體情況如下圖所示：

總而言之，我們將主動服務的數(shù)量由1900降低到745。幸存下來的檢查項目大多必須采取主動狀態(tài)——例如ping檢查、Check_MK代理以及應用程序HTTP檢查等。因為只有這樣我們才能在項目出現(xiàn)問題時及時得到警告。

從某種程度來說，這只是種負載轉(zhuǎn)移過程——某些負載被轉(zhuǎn)嫁到其它主機當中，并通過檢查腳本或者后臺推送程序?qū)⒔Y果傳遞給Nagios。不過這種收益還是相當顯著且順理成章的（將負載分攤到服務器閑置資源中），我們還通過對檢查腳本的重新編寫改裝最系統(tǒng)全局執(zhí)行效率、消除了成千上萬HTTP請求所帶來的資源占用。更重要的是，我們在恢復原有檢查間隔的同時還添加了一些新的監(jiān)控項目，并且始終將負載控制在3%、延遲控制在0.5秒以下。

希望我在打理監(jiān)控基礎設施方面的經(jīng)驗能幫助大家找到實際問題的解決辦法。過去那種“添加其它可執(zhí)行腳本”的方式實在太過狹隘，其實我們完全能以其它方式更好地搞定難題。從某種意義上說，即使各位的監(jiān)控系統(tǒng)并沒有出問題，這篇文章也能在進一步提升性能表現(xiàn)方面有所借鑒。

原文鏈接：http://37signals.com/svn/posts/3178-nagios-monitoring-performance