網站運維之道 監控與報警機制
51CTO編輯注：本文是馮大輝（Fenng）的一個系列博文，《網站運維之道》。本文是系列的第二篇。
監控機制
定義了網站可用性指標，如何獲取網站的可用值? 監控工具該粉墨登場了。
多數網站都會傾向于利用開源軟件自行搭建監控平臺。筆者一向認為，即使網站有一臺服務器，也應該搭建監控工具，這是保障網站能持續改進的基石。常見的開源監控工具有Nagios（www.nagios.org）、monit（www.tildeslash.com/monit）等。Nagios也可能是當前國內最被廣泛采用的監控軟件了，根據官方描述，Nagios 是開源的主機、網絡、服務監控程序，從這個描述能看出，Nagios 的設計目標是很龐大的。依賴其強大的擴展性，通過分布式監控模式，管理上千臺甚至更多的服務器也不在話下。而對于大型集群環境，Ganglia (http://ganglia.info/) 是個不錯的選擇。
另外商業化運作的比較好的開源監控工具或框架還有 Zenoss (http://www.zenoss.com/)、Zabbix (http://www.zabbix.com/)、Hyperic (http://www.hyperic.com/)、 OpenNMS(http://opennms.org/) 等。這幾個的定位都是"企業級"監控平臺。當然，功能的確不比 Nagios 差，也有的彌補了 Nagios 的一些不足之處(比如 Zenoss 增強了對 Windows 服務器的監控能力)。但出于種種原因，在國內的流行程度并不廣泛。
(圖2: Nagios 分布監控示意圖
圖片來源: http://images.51cto.com/files/uploadimg/20100812/1729110.png)
如果要滿足日趨靈活的 Web 監控需要就不得不提 Nagios 靈活的插件機制，最簡單只需要幾行 Shell 代碼就能實現基本的插件功能。多數情況下，腳本捕獲系統日志中的特定事件，通過 NSCA Client 發送給中心監控服務器即可。靈活性是衡量監控軟件的一個重要標準，從這一點說，多數傳統的商業網管軟件怕是都不如 Nagios 這樣勝任現在日趨復雜的網站環境。
提到網管監控，必然要談到 SNMP?？缙脚_或者針對專有設備的監控離不開SNMP，但有的時候 SNMP 的安全性也的確會帶來嚴重問題。這就需要運維團隊中的安全專家對監控系統機制的安全性做整體評估，或是提升運維團隊的安全意識以避免在監控過程中引入更多的安全問題。
有些公司的運維團隊喜歡自己寫監控工具而不是利用已有的第三方開源工具。這種重復發明輪子的做法筆者認為是不可取的。這樣做最明顯的一個缺點是軟件本身的維護成本可能會更高，而且團隊人員變動的時候后續代碼維護也是個潛在的問題。至于商業工具的選擇，這里不作評價。
報警機制
光有監控而報警機制跟不上，不能及時把緊急情況下的信息傳遞給運維技術人員，那么監控形同虛設。現在報警信息發送途徑主要有郵件、IM、SMS 三種(過去書籍中提到的傳呼方式已是明日黃花)。
這幾個途徑中，郵件告警可能是最簡單的，實現起來容易，一行命令即可做到，但因為郵件本身的異步屬性和郵件服務器的延時問題，很難讓運維人員及時得知信息。所以，如果比較嚴重的告警信息必須考慮其它實時性比較高的方法。至于發送到 IM，如果 IM 是支持 Jabber 的，實現起來并不難，可靠性也會有一定保障，而如果 IM 比較封閉，那么可行性就不大了，除非 IM 公司對你開放 API ，否則任何取巧的技巧來發送消息的方法其可信賴性都不強、SMS 是大家都比較傾向的一種方式，只是有很多人不知道具體如何實現，說白了也就是一層窗戶紙。如果有電信服務提供商(SP)能夠提供基于 Web 的調用接口給你，那么直接利用 Wget 或是 cURL 工具模擬瀏覽器處理表單信息即可，幾行命令即可搞定。如果不具備這樣的條件，不妨考慮一下短信 Modem，現在市場上這樣的短信 Modem 很多，價格不貴，大多都提供二次開發的功能，簡單的寫點腳本即可實現目的。至于網上有人推薦的免費短信服務，因為實時性比較差，筆者是不推薦的。天下沒有免費的午餐，這樣的服務往往信息發送優先級很低，而且，短信到達率很難保障。
值得一提的是，報警服務器本身也需要監控的。建議定期發送測試郵件、測試短信來驗證告警功能處于正常狀態。尤其是在節假日來臨前更要反復確保該功能是正?？捎玫?。
原文：http://www.dbanotes.net/web/web_operations_monitoring_and_alert.html
【網站運維之道全系列】
