文章出自：阿里巴巴十億級并發(fā)系統(tǒng)設計（2021版）

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

目錄

監(jiān)控指標如何選擇

如何采集數(shù)據(jù)指標

監(jiān)控數(shù)據(jù)的處理和存儲

課程小結

---

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

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

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

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

這些問題，一環(huán)扣一環(huán)，關乎著系統(tǒng)的穩(wěn)定性和可用性，而本節(jié)課，我就帶你解決這些問 題，搭建一套服務端監(jiān)控體系。

監(jiān)控指標如何選擇

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

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

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

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

如何采集數(shù)據(jù)指標

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

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

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

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

?

編號命令?

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	//?當前連接數(shù)
5	STAT bytes?3738857307	//?當前內(nèi)存占用量
6	STAT evictions?11008640149	//?當前被?memcached?服務器剔除的?item?數(shù)量，如果這個數(shù)量過大?(比如例子中的這個數(shù)值)，那么代表當前?Memcached?容量不足或者?Memcache

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

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

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

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

3）最后，日志也是你監(jiān)控數(shù)據(jù)的重要來源之一。

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

監(jiān)控數(shù)據(jù)的處理和存儲

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

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

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

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

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

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

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

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

課程小結

本節(jié)課，我?guī)懔私饬?#xff0c;服務端監(jiān)控搭建的過程，在這里，你需要了解以下幾個重點:

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

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

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

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

總結

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。