如果第二次看到我的文章，歡迎右側掃碼訂閱我喲~ 👉
每週五早8點 按時送達。當然了，也會時不時加個餐～
這篇是「分佈式系統理論」系列的第22篇，也是最後一篇。我們來聊聊分佈式系統中的最後一道保障——監控。
監控這個事情，有點像我們平時對人的健康體檢。想要效果好、結果靠譜，就得“全面體檢”，每一項都做，否則哪怕檢查報告都是正常，也不代表沒有問題。下面這個景象是不是很熟悉？
運營小姐姐問：現在系統好卡啊。
程序員小哥哥答：我這裏不卡啊，而且從數據來看很正常。
運營小姐姐問：[一張截圖]，你看一直在加載。
程序員小哥哥答：你的本地網絡不好吧，打開別的網站試試。
……
監控裏的“全面體檢”有個高大上的叫法，「立體化監控」。
但是，越全面，成本越高。所以，根據所處的時期從中挑選合適的監控方式更加重要。
接下去，Z哥來和你一起梳理一下那些有必要做監控的地方。最後再給你一個普適性的建議。
監控的三個層次
從監控的目標來看，監控可以分爲三個層次。分別是「環境指標」、「程序指標」、「業務指標」。
環境指標
環境指標主要是網絡I/O、網絡延遲、磁盤I/O、磁盤佔用大小、CPU使用率、內存使用率、交換分區等等。
它們的目的是觀測程序所在的環境，是不是穩定。就好比「水培綠籮」，再怎麼好養的植物，你把下面的水煮一會，都得掛。
做環境指標的監控很簡單。Z哥建議你二選一就好了。
無腦用的話，就Zabbix吧。非常成熟的企業級監控產品。網上安裝教程有很多，隨便搜一下就是。
如果服務器多的話，將Zabbix打包到進操作系統，做成一個鏡像。這樣一來，一臺新服務器只要是從鏡像安裝的，就會自動加入到監控中。
如果願意折騰，想二次開發的話可以使用小米開源的open-falcon。項目的活躍度還不錯，可以瞭解一下：https://github.com/open-falcon/falcon-plus。
雖然功能的豐富度上比Zabbix差一些，但是畢竟是國人的產品，更加符合中國國情。國內有不少互聯網企業也在用，或者基於它進行了二次開發，最有名的是美團二次開發的mt-falcon的。如果決定進行二次開發的話，可以借鑑一些mt-falcon在網上的公開信息。
程序指標
程序指標除了和環境指標一樣的CPU使用率、內存使用率這種“外部“表現的指標之外，還有應用程序錯誤數、應用程序請求量、應用平均響應時間這種”內部“表現的指標。
其實做監控的時候有一個痛點，是不是「無侵入」的？
因爲一旦需要侵入到具體的程序中去編寫「埋點」代碼，就很麻煩，畢竟涉及到更多的人一起配合嘛，推進更困難。
CPU使用率、內存使用率的監控比較簡單，可以直接通過shell或者cmd調用系統API獲取，和前面的環境指標一樣。
但對於應用程序錯誤數、應用程序請求量、應用平均響應時間的監控，這裏是一個分水嶺，因爲這裏想要做到「無侵入」的效果，需要做一些額外的工作，否則只能編寫大量的“埋點”代碼。
比如，是不是有一個網關來統一進行流量分發？是不是有一個統一的RPC框架、數據庫訪問框架等等。如果有這樣的統一模塊就好辦了，直接在這些模塊裏增加監控功能。
舉個例子，你的rpc框架是統一的，那麼只要在每次方法調用前和調用後記錄好相應的數據，就可用於後續統計出結果。
關於採集到的數據如何存儲，主流的選擇是將數據寫入到一個「時序數據庫」中。比如Prometheus，這是一個專門做監控報警的開源框架，在全球都比較火，github上有23K的star。當然你也可以選擇其他的時序數據庫，如InfluxDB、OpenTSDB之類。
再配合以一個可視化框架，比如grafana，將其中的數據展示出來，就完成了整個監控系統的搭建。網上的搭建教程也有很多，就不多說了。
如果沒有統一框架的話，可以優先考慮通過AOP的方式，以此儘量降低埋點代碼的編寫量。
數據採集就在AOP切入的位置進行。
特別注意一點，由於監控產生的日誌數量龐大，不建議直接與遠程數據庫交互。所以需要藉助一些專門的日誌採集和傳輸框架。比如flume、logstash。
怎麼感覺一下子引入了好多新框架～，沒辦法，真要做好監控是挺繁瑣的。
業務指標
在典型的程序員思維裏，認爲業務指標關我什麼事。其實恰恰業務指標的監控更加的“有效”。因爲業務指標出問題了，說明必然哪出問題了，不會像前面聊的兩個層面的指標，可能看着好好的，但是實際業務卻出了問題。
最近這2年在運營圈裏被“爆炒”的「增長黑客」概念，本質上就是通過數據驅動的方式來做運營工作。而這背後依賴的就是一個業務指標監控系統。
每一個業務會經過的關鍵狀態，都可以作爲「業務指標」來監控。但是由於業務指標往往不具有「通用性」，所以，需要手動在程序裏「埋點」。
因此，對業務指標的監控必然是「侵入性」的。
能不能不要埋點？也不是沒有辦法。
如果在一個系統的初期，比如日PV在百萬以下的，直接通過業務數據庫拉數據也不失爲一個取巧的辦法。這樣就不用寫什麼埋點代碼，簡單粗暴。
到了成長期，直接拉業務數據庫行不通了，因爲會對正常的業務處理產生顯著的性能影響。不過，此時還可以通過數據庫層面做二次分發，將數據實時地複製到一個單獨的庫中，從這個庫拉數據也能“撐”一段時間。
當然了，這些辦法只能解決一部分問題。如果需要監控的業務指標不存在於業務流轉的數據中（比如用戶行爲數據），那就沒辦法了，只能老老實實的寫「埋點」代碼。
總體來看，這三層指標恰好構成一個金字塔結構。從監控價值來看 業務指標 > 程序指標 > 環境指標。從實施的一個成本來看，也是 業務指標 > 程序指標 > 環境指標。
Z哥給你的普適性建議是，不管怎麼樣，環境指標先做了，畢竟投入的成本非常小，聊勝於無嘛。
其次，先通過直接拉db的方式監控部分重點業務指標。
然後，再把程序指標監控補充上。
最後，再查漏補缺完成所謂的全方位「立體化監控」。
告警策略
可能你會覺得文章到這裏結束了，其實還沒，前面主要聊了監控體系的“看”。但是監控體系還有另外一個重點是“叫”。缺少了「告警機制」的監控體系更像是個“面子工程”，實際的用處比較有限。
當你的系統還比較小的時候，告警怎麼弄都行，哪怕每一次異常都觸發告警。但是隨着系統的發展，告警次數一多，就麻煩了，完全被“淹沒”在了告警信息的”海洋“中，特別是那種專門有個“告警羣”的情況下。
想象一下，告警羣裏每分鐘都在彈出新的告警，哪怕你有“三頭六臂”也處理不過來……
所以這裏需要引入一個告警策略，使得告警更加的人性化。這個機制的核心就是4點。
-
梳理不同的告警級別
-
制定告警頻率以及做好「收斂」（主要是去重、合併數量）
-
決定不同的告警級別通過什麼形式發出通知（短信、手機通知、郵件等）
-
發給誰（比如，是不是需要“輪轉”或者“逐級上報”這樣）
當然了，現在越來越多的大型開發團隊開始引入AI來使得告警更加的智能化，但是離我們大多數人所處的工作場景還是有一定距離的，不用急，一步一步來。
總結
好了，來一起總結一下。
這次呢，Z哥主要和你聊了在三個層次上的監控做法，並且給出了個人認爲相對平滑的演進路線，供你參考。
然後，再聊了下告警策略的制定方式。告警需要更加的人性化，如此才能讓人重視。
希望對你有所幫助。
推薦閱讀：
作者：Zachary
出處：https://www.cnblogs.com/Zachary-Fan/p/monitor.html
如果你喜歡這篇文章，可以點一下右下角的「推薦」。
這樣可以給我一點反饋。: )
謝謝你的舉手之勞。
既然看到這了，送我一個「贊同」吧，支持我的創作。
想更進一步和我一起玩耍，歡迎「搜索微信公號：跨界架構師」或者在「右側掃描」。
內容包括：架構設計丨分佈式系統丨產品丨運營丨個人深度思考。