文章出自：阿里巴巴十億級并發系統設計（2021版）

鏈接：https://pan.baidu.com/s/1lbqQhDWjdZe1CBU-6U4jhA?提取碼：8888?

目錄

監控指標如何選擇

如何采集數據指標

監控數據的處理和存儲

課程小結

---

在一個項目的生命周期里，運行維護占據著很大的比重，在重要性上，它幾乎與項目研發并駕齊驅。而在系統運維過程中，能夠及時地發現問題并解決問題，是每一個團隊的本職工 作。所以，你的垂直電商系統在搭建之初，運維團隊肯定完成了對于機器 CPU、內存、磁盤、網絡等基礎監控，期望能在出現問題時，及時地發現并且處理。你本以為萬事大吉，卻沒想到系統在運行過程中，頻頻得到用戶的投訴，原因是:

• 使用的數據庫主從延遲變長，導致業務功能上出現了問題;
• 接口的響應時間變長，用戶反饋商品頁面出現空白頁;
• 系統中出現大量錯誤，影響了用戶的正常使用。

這些問題，你本應該及時發現并處理的。但現實是，你只能被動地在問題被用戶反饋后，手忙腳亂地修復。這時，你的團隊才意識到，要想快速地發現和定位業務系統中出現的問題， 必須搭建一套完善的服務端監控體系。正所謂“道路千萬條，監控第一條，監控不到位，領導兩行淚”。不過，在搭建的過程中，你的團隊又陷入了困境:

• 首先，監控的指標要如何選擇呢?
• 采集這些指標可以有哪些方法和途徑呢?
• 指標采集到之后又要如何處理和展示呢?

這些問題，一環扣一環，關乎著系統的穩定性和可用性，而本節課，我就帶你解決這些問 題，搭建一套服務端監控體系。

監控指標如何選擇

你在搭建監控系統時，所面臨的第一個問題就是，選擇什么樣的監控指標，也就是監控什 么。有些同學在給一個新的系統，設定監控指標的時候，會比較迷茫，不知道從哪方面入 手。其實，有一些成熟的理論和套路，你可以直接拿來使用。比如，谷歌針對分布式系統監控的經驗總結，四個黃金信號(Four Golden Signals)。它指的是，在服務層面一般需要監控四個指標，分別是延遲、通信量、錯誤和飽和度。

• 延遲：指的是請求的響應時間比如，接口的響應時間、訪問數據庫和緩存的響應時間。
• 通信量：可以理解為吞吐量，也就是單位時間內，請求量的大小。比如，訪問第三方服務 的請求量，訪問消息隊列的請求量。
• 錯誤：表示當前系統發生的錯誤數量。這里需要注意的是，?我們需要監控的錯誤既有顯示 的，比如在監控 Web 服務時，出現 4 * * 和 5 * * 的響應碼;也有隱示的，比如，Web 服務雖然返回的響應碼是 200，但是卻發生了一些和業務相關的錯誤(出現了數組越界 的異?；蛘呖罩羔槷惓５?，這些都是錯誤的范疇。
• 飽和度：指的是服務或者資源到達上限的程度(也可以說是服務或者資源的利用率)，比 如說 CPU 的使用率、內存使用率、磁盤使用率、緩存數據庫的連接數等等。

這四個黃金信號提供了通用的監控指標，除此之外，你還可以借鑒 RED 指標體系。這個體系，是四個黃金信號中衍生出來的，其中，R 代表請求量(Request rate)，E 代表錯誤 (Error)，D 代表延遲(Duration)，少了飽和度的指標。你可以把它當作一種簡化版的通用監控指標體系。當然，一些組件或者服務還有獨特的指標，這些指標也是需要你特殊關注的。比如，課程中提到的數據庫主從延遲數據、消息隊列的堆積情況、緩存的命中率等等。我把高并發系統中常見組件的監控指標，整理成了一張表格，其中沒有包含諸如 CPU、內存、網絡、磁盤等基礎監控指標，只是業務上監控指標，主要方便你在實際工作中參考使用。

選擇好了監控指標之后，你接下來要考慮的，是如何從組件或者服務中，采集到這些指標， 也就是指標數據采集的問題。

如何采集數據指標

說到監控指標的采集，我們一般會依據采集數據源的不同，選用不同的采集方式，總結起來，大概有以下幾種類型:

1）首先，Agent 是一種比較常見的，采集數據指標的方式。

我們通過在數據源的服務器上，部署自研或者開源的 Agent，來收集收據，發送給監控系統，實現數據的采集。在采集數據源上的信息時，Agent 會依據數據源上，提供的一些接 口獲取數據，我給你舉兩個典型的例子。

比如，你要從 Memcached 服務器上，獲取它的性能數據，那么，你就可以在 Agent 中， 連接這個 Memcached 服務器，并且發送一個 stats 命令，獲取服務器的統計信息。然后，你就可以從返回的信息中，挑選重要的監控指標，發送給監控服務器，形成 Memcached 服務的監控報表。你也可以從這些統計信息中，看出當前 Memcached 服務 器，是否存在潛在的問題。下面是我推薦的，一些重要的狀態項，你可以參考使用。

?

編號命令?

1	STAT cmd_get?201809037423	//?計算查詢的?QPS
2	STAT cmd_set?16174920166	//?計算寫入的?QPS
3	STAT get_hits?175226700643	//?用來計算命中率，命中率?= get_hits/cmd_get
4	STAT curr_connections?1416	//?當前連接數
5	STAT bytes?3738857307	//?當前內存占用量
6	STAT evictions?11008640149	//?當前被?memcached?服務器剔除的?item?數量，如果這個數量過大?(比如例子中的這個數值)，那么代表當前?Memcached?容量不足或者?Memcache

另外，如果你是 Java 的開發者，那么一般使用 Java 語言開發的中間件，或者組件，都可以通過 JMX 獲取統計或者監控信息。比如，在19 講中，我提到可以使用JMX，監控 Kafka 隊列的堆積數，再比如，你也可以通過 JMX 監控 JVM 內存信息和 GC 相關的信息。

2）另一種很重要的數據獲取方式，是在代碼中埋點。

這個方式與 Agent 的不同之處在于，Agent 主要收集的是組件服務端的信息，而埋點則是從客戶端的角度，來描述所使用的組件，和服務的性能和可用性。那么埋點的方式怎么選擇呢?你可以使用25 講分布式 Trace 組件中，提到的面向切面編程的方式;也可以在資源客戶端中，直接計算調用資源或者服務的耗時、調用量、慢請求數，并且發送給監控服務器。

這里你需要注意一點，由于調用緩存、數據庫的請求量會比較高，一般會單機也會達到每秒萬次，如果不經過任何優化，把每次請求耗時都發送給監控服務器，那么，監控服務器會不堪重負。所以，我們一般會在埋點時，先做一些匯總。比如，每隔 10 秒匯總這 10 秒內， 對同一個資源的請求量總和、響應時間分位值、錯誤數等，然后發送給監控服務器。這樣， 就可以大大減少發往監控服務器的請求量了。

3）最后，日志也是你監控數據的重要來源之一。

你所熟知的 Tomcat 和 Nginx 的訪問日志，都是重要的監控日志。你可以通過開源的日志采集工具，將這些日志中的數據發送給監控服務器。目前，常用的日志采集工具有很多，比 如，Apache Flume、Fluentd和Filebeat，你可以選擇一種熟悉的使用。比如在?的項目中，我會傾向于使用 Filebeat 來收集監控日志數據。

監控數據的處理和存儲

在采集到監控數據之后，你就可以對它們進行處理和存儲了，在此之前，我們一般會先用消息隊列來承接數據，主要的作用是削峰填谷，防止寫入過多的監控數據，讓監控服務產生影響。 與此同時，我們一般會部署兩個隊列處理程序，來消費消息隊列中的數據。

一個處理程序接收到數據后，把數據寫入到 Elasticsearch，然后通過 Kibana 展示數據， 這份數據主要是用來做原始數據的查詢;

另一個處理程序是一些流式處理的中間件，比如，Spark、Storm。它們從消息隊列里，接收數據后會做一些處理，這些處理包括:

• 解析數據格式，尤其是日志格式。從里面提取諸如請求量、響應時間、請求 URL 等數據;
• 對數據做一些聚合運算。?比如，針對 Tomcat 訪問日志，可以計算同一個 URL 一段時間 之內的請求量、響應時間分位值、非 200 請求量的大小等等。
• 將數據存儲在時間序列數據庫中。這類數據庫的特點是，可以對帶有時間標簽的數據，做更有效的存儲，而我們的監控數據恰恰帶有時間標簽，并且按照時間遞增，非常適合存儲在 時間序列數據庫中。目前業界比較常用的時序數據庫有 InfluxDB、OpenTSDB、 Graphite，各大廠的選擇均有不同，你可以選擇一種熟悉的來使用。
• 最后，?你就可以通過 Grafana 來連接時序數據庫，將監控數據繪制成報表，呈現給開發和運維的同學了。

至此，你和你的團隊，也就完成了垂直電商系統，服務端監控系統搭建的全過程。這里我想再多說一點，我們從不同的數據源中采集了很多的指標，最終在監控系統中一般會形成以下幾個報表，你在實際的工作中可以參考借鑒:

訪問趨勢報表：這類報表接入的是 Web 服務器，和應用服務器的訪問日志，展示了服務整體的訪問量、響應時間情況、錯誤數量、帶寬等信息。它主要反映的是，服務的整體運行情況，幫助你來發現問題。

性能報表：?這類報表對接的是資源和依賴服務的埋點數據，展示了被埋點資源的訪問量 和響應時間情況。它反映了資源的整體運行情況，當你從訪問趨勢報表發現問題后，可以先從性能報表中，找到究竟是哪一個資源或者服務出現了問題。

資源報表：?這類報表主要對接的是，使用 Agent 采集的，資源的運行情況數據。當你從 性能報表中，發現某一個資源出現了問題，那么就可以進一步從這個報表中，發現資源究竟 出現了什么問題，是連接數異常增高，還是緩存命中率下降。這樣可以進一步幫你分析問題 的根源，找到解決問題的方案。

課程小結

本節課，我帶你了解了，服務端監控搭建的過程，在這里，你需要了解以下幾個重點:

耗時、請求量和錯誤數是三種最通用的監控指標，不同的組件還有一些特殊的監控指標，你在搭建自己的監控系統的時候可以直接使用;

Agent、埋點和日志是三種最常見的數據采集方式;

訪問趨勢報表用來展示服務的整體運行情況，性能報表用來分析資源或者依賴的服務是 否出現問題，資源報表用來追查資源問題的根本原因。這三個報表共同構成了你的服務端監控體系。

總之，監控系統是你發現問題，排查問題的重要工具，你應該重視它，并且投入足夠的精力來不斷地完善它。只有這樣，才能不斷地提高對系統運維的掌控力，降低故障發生的風險。

總結

以上是生活随笔為你收集整理的服务端监控要怎么做?的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。