主要分系統監控和業務監控兩類
系統監控就是每臺主機的CPU,內存網絡帶寬等使用情況以及Mysql, Redis, Nginx等服務的核心指標等這是比較基本的監控必須得有如果這塊監控做的好生產環境可以提前發現很多問題防患於未然。
業務監控就是業務相關的指標如某API每秒調用次數每分鐘該API的平均響應時間服務的在線人數甚至一些運營相關的數據如七日留存率啦每日新增用戶每日流失用戶等。這些數據也很重要他是你整個業務的晴雨表爲你做一些重要決策提供依據。
對於系統監控有很多開源軟件可以拿來用如比較出名的nagios,cacti,zabbix等部署都比較複雜客戶端要部agent還得裝一個center用來收集存儲展現數據還有好多插件需要維護。通過隊列把信息發送給主服務,如果是同機房當然還是寫nagios的插件會比較好,這樣是統一管理,而只需要寫插件如果是機房是分佈的,可以考慮nagios之間的消息傳遞寫一些腳本完成,自己寫的話是時間問題和管理上不統一的麻煩。但有一個比較簡單的東西是collectd它自帶了各種插件如系統CPU磁盤利用率mysql,nginx,redix等常用服務都可以進行監控而且自動給你推薦了要監控哪些指標。安裝很方便基本上./configuration && make && make install就可以了。
對於業務監控肯定是需要自己寫代碼上報業務數據的現在比較流行的方案是statsd+graphite比較輕量級而且有很多語言的sdk可以很輕鬆把各種指標監控起來。
監控的選擇 一般要看你的服務器分佈:
如果是分佈式的機房, 機房很多, 那麼對集中監控和處理要求比較高, ganglia本身就有分佈式特性, 是第一選擇; nagios需要再做些插件的優化和結構調整才能更好的支持分佈式的需求. 因爲分佈式面臨的問題是集中管理和可靠性, 可靠性: 網絡傳輸可能出現的問題都要避免監控才能讓監控準確; 集中管理: 纔可以減少工作量
如果是集中的, 在量很大的情況下還是建議使用ganglia, 如果小其它的很多監控都可以選擇, 報警監控還是用nagios, 好像很少有他這樣靈活的工具, 但一定要將配置改成最適合自己環境的, 並且最簡單和快速的配置 需要自己制定一些規則會比較好。
大多監控體系都差不多如下
每臺機器上安裝一個agent用來採集本機的性能數據服務數據
每臺機器部署的業務根據一個sdk向center提交本業務相關的數據
每個agent可以動態的按需求加載一些插件以便監控新的指標
一般一個機房內有一個center用來收集各agent和各業務上報的指標
center要把採集到的指標數據進行存儲歸檔壓縮一般用rrd database
center還得有一個web界面來查看各個指標的歷史圖表甚至要有各種視圖和dashborad來顯示一組相關的指標。
center還要每天把用戶自定義的幾個關鍵的指標生產報表發給運維或者相關人員。
center還需要保存各種告警規則如某個指標連續幾次超過某個閾值產生告警或者波動超過某個範圍產生告警或者某個指標超過多長時間沒有上報數據產生告警
center還要進行各種告警的收斂如同類告警的合併臨時屏蔽某類告警防止因爲網絡抖動引起大量告警等沒有這些運維人員會淹沒在各種告警聲中。
center要以各種方式將告警發送給運維人員如短信郵件微信語音等。
center還要對每次告警進行回顧統計分析得出每個系統的薄弱點可用率在線時間穩定性等。
所以說自己搭建一套完善可靠的監控體系挺不容易的需要投入大量的人力和精力去開發和維護。
現在國外也有一些專門做運維外包的廠商center託管在給他們免去了很大的工作量剩下的agent和plugin還是得自己安裝但這就簡單了反正有很多可以做批量部署的運維工具。
比較出名的有NewRelic,StatHat,hostedgraphite可以去了解一下基本上就是安裝個agent就可以向它們的center上報數據了或者是利用他們的Sdk提交一些自定義數據他們負責存儲展現告警方面的事情節省很多人力。
國內的話也有人做類似的事情如DNSPod的D監控最近推出了自定義監控的功能兼容graphite的上報接口你自己部署個collectd就可以把各種系統監控指標監控起來了如果要做業務監控graphite也有各種語言的sdk。graphite本身開源周邊工具和軟件也特別多能滿足很多的需求。
服務器數量不太大時，比如小於200臺，建議試試Nagios Nagios監控系統的CPU、內存、硬盤等各個基本面都很方便。監控自己的服務也很容易，組合些插件、寫點簡單的腳本啥的就能做到。
如果服務器數量很多，超過1000臺。高效採集這些信息就是個複雜的事情，想想每秒鐘要有多少數據往你的監控服務器傳送就有點頭疼了。這就需要自己精心設計下拓撲結構、寫不少代碼。當然，也能利用已有的開源框架做到這些信息採集。