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

這篇是「分布式系統理論」系列的第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哥主要和你聊了在三個層次上的監控做法，并且給出了個人認為相對平滑的演進路線，供你參考。

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

希望對你有所幫助。

分布式

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。