如果第二次看到我的文章，歡迎訂閱z哥的公眾號（跨界架構師）哦~

每週五早8點 按時送達。當然了，也會時不時加個餐～我的第「74」篇原創敬上

這篇是「分散式系統理論」系列的第22篇，也是最後一篇。我們來聊聊分散式系統中的最後一道保障——監控。

監控這個事情，有點像我們平時對人的健康體檢。想要效果好、結果靠譜，就得「全面體檢」，每一項都做，否則哪怕檢查報告都是正常，也不代表沒有問題。下面這個景象是不是很熟悉？

運營小姐姐問：現在系統好卡啊。

程序員小哥哥答：我這裡不卡啊，而且從數據來看很正常。 運營小姐姐問：[一張截圖]，你看一直在載入。 程序員小哥哥答：你的本地網路不好吧，打開別的網站試試。 ……

監控裏的「全面體檢」有個高大上的叫法，「立體化監控」。

但是，越全面，成本越高。所以，根據所處的時期從中挑選合適的監控方式更加重要。

接下去，Z哥來和你一起梳理一下那些有必要做監控的地方。最後再給你一個普適性的建議。

監控的三個層次

從監控的目標來看，監控可以分為三個層次。分別是「環境指標」、「程序指標」、「業務指標」。

環境指標

環境指標主要是網路I/O、網路延遲、磁碟I/O、磁碟佔用大小、CPU使用率、內存使用率、交換分區等等。

它們的目的是觀測程序所在的環境，是不是穩定。就好比「水培綠籮」，再怎麼好養的植物，你把下面的水煮一會，都得掛。

做環境指標的監控很簡單。Z哥建議你二選一就好了。

無腦用的話，就Zabbix吧。非常成熟的企業級監控產品。網上安裝教程有很多，隨便搜一下就是。

如果伺服器多的話，將Zabbix打包到進操作系統，做成一個鏡像。這樣一來，一臺新伺服器只要是從鏡像安裝的，就會自動加入到監控中。

如果願意折騰，想二次開發的話可以使用小米開源的open-falcon。項目的活躍度還不錯，可以瞭解一下：github.com/open-falcon/。

雖然功能的豐富度上比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）。堅持用心打磨每一篇高質量原創。

想更進一步和我一起玩耍，歡迎「搜索微信公號：跨界架構師」

定期發表原創內容：架構設計丨分散式系統丨產品丨運營丨一些思考。

推薦閱讀：

相關文章