分佈式系統關注點(22)——360°的全方位監控

若是第二次看到個人文章，歡迎關注個人我的原創公衆號「跨界架構師」哦～

每週五11：45 按時送達。 固然了，也會時不時加個餐～

這篇是「分佈式系統理論」系列的第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點。

1. 梳理不一樣的告警級別

2. 制定告警頻率以及作好「收斂」（主要是去重、合併數量）

3. 決定不一樣的告警級別經過什麼形式發出通知（短信、手機通知、郵件等）

4. 發給誰（好比，是否是須要「輪轉」或者「逐級上報」這樣）

固然了，如今愈來愈多的大型開發團隊開始引入AI來使得告警更加的智能化，可是離咱們大多數人所處的工做場景仍是有必定距離的，不用急，一步一步來。

總結

好了，來一塊兒總結一下。

此次呢，Z哥主要和你聊了在三個層次上的監控作法，而且給出了我的認爲相對平滑的演進路線，供你參考。

而後，再聊了下告警策略的制定方式。告警須要更加的人性化，如此才能讓人重視。

但願對你有所幫助。

推薦閱讀：

• 分佈式系統關注點——緩存背後的「毀滅種子」

• 分佈式系統關注點——深刻淺出「異步」

若是你喜歡這篇文章，能夠點一下左側的「大拇指」哦～。

這樣能夠給我一點反饋。: )

謝謝你的舉手之勞。

▶關於做者：張帆（Zachary，我的微信號：Zachary-ZF）。堅持用心打磨每一篇高質量原創。本文首發於公衆號：「 跨界架構師」（ID：Zachary_ZF）。 <-- 點擊後閱讀熱門文章
按期發表原創內容：架構設計丨分佈式系統丨產品丨運營丨一些思考。

若是你是初級程序員，想提高但不知道如何下手。又或者作程序員多年，陷入了一些瓶頸想拓寬一下視野。歡迎關注個人公衆號「跨界架構師」，回覆「技術」，送你一份我長期收集和整理的思惟導圖。

若是你是運營，面對不斷變化的市場一籌莫展。又或者想了解主流的運營策略，以豐富本身的「倉庫」。歡迎關注個人公衆號「跨界架構師」，回覆「運營」，送你一份我長期收集和整理的思惟導圖。