如果第二次看到我的文章，歡迎「文末」掃碼訂閱我個人的公眾號（跨界架構師）喲~ 

每週五早8點 按時送達到公眾號。當然了，也會時不時加個餐～

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

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

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

程式設計師小哥哥答：我這裡不卡啊，而且從資料來看很正常。

運營小姐姐問：[一張截圖]，你看一直在載入。

程式設計師小哥哥答：你的本地網路不好吧，開啟別的網站試試。

 ……

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

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

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

監控的三個層次

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

環境指標

環境指標主要是網路I/O、網路延遲、磁碟I/O、磁碟佔用大小、CPU使用率、記憶體使用率、交換分割槽等等。

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

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

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

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

如果願意折騰，想二次開發的話可以使用小米開源的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

出處： https://www.cnblogs.com/Zachary-Fan/p/monitor.html

如果你喜歡這篇文章，可以點一下下方的「 大拇指 」。

這樣可以給我一點反饋。: )

謝謝你的舉手之勞。

▶關於作者：張帆（Zachary， 個人微訊號：Zachary-ZF ）。堅持用心打磨每一篇高質量原創。歡迎 掃描下方 的二維碼~。

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

如果你是初級程式設計師，想提升但不知道如何下手。又或者做程式設計師多年，陷入了一些瓶頸想拓寬一下視野。歡迎關注我的公眾號「 跨界架構師 」，回覆「 技術 」，送你一份我長期收集和整理的思維導圖。

如果你是運營，面對不斷變化的市場束手無策。又或者想了解主流的運營策略，以豐富自己的“倉庫”。歡迎關注我的公眾號「 跨界架構師 」，回覆「 運營 」，送你一份我長期收集和整理的思維導圖。