一般來說，白盒與黑盒分別從內(nèi)部和外部來監(jiān)控系統(tǒng)的運(yùn)行狀況，例如機(jī)器存活、CPU內(nèi)存使用率、業(yè)務(wù)日志、JMX等監(jiān)控都屬于白盒監(jiān)控，而外部端口探活、HTTP探測以及端到端功能監(jiān)控等則屬于黑盒監(jiān)控的范疇。

下面將主要從白盒監(jiān)控的采集入手，解答上面關(guān)于新系統(tǒng)如何添加監(jiān)控的問題。

圖 1 黑盒與白盒監(jiān)控

監(jiān)控指標(biāo)的采集

配置監(jiān)控時(shí)，我們首要面對(duì)的是監(jiān)控?cái)?shù)據(jù)如何采集的問題。一般我們可以把監(jiān)控指標(biāo)分為兩類：基礎(chǔ)監(jiān)控和業(yè)務(wù)監(jiān)控。

基礎(chǔ)監(jiān)控

包括CPU、內(nèi)存、磁盤、端口和進(jìn)程等機(jī)器、網(wǎng)絡(luò)的操作系統(tǒng)級(jí)別的信息。通常情況下，成熟的監(jiān)控系統(tǒng)（例如開源的Prometheus、Zabbix等）均會(huì)提供基礎(chǔ)監(jiān)控項(xiàng)的采集能力，這里不做過多介紹。但需要注意的一點(diǎn)，機(jī)器級(jí)別的基礎(chǔ)監(jiān)控指標(biāo)一般并不能代表服務(wù)的真實(shí)運(yùn)行狀況，例如單臺(tái)實(shí)例的故障對(duì)一個(gè)設(shè)計(jì)合理的分布式系統(tǒng)來說并不會(huì)帶來嚴(yán)重后果。所以只有結(jié)合業(yè)務(wù)相關(guān)監(jiān)控指標(biāo)，基礎(chǔ)監(jiān)控指標(biāo)才有意義。

業(yè)務(wù)監(jiān)控

業(yè)務(wù)監(jiān)控指標(biāo)由業(yè)務(wù)系統(tǒng)內(nèi)部的服務(wù)產(chǎn)生，一般能夠真實(shí)反應(yīng)業(yè)務(wù)運(yùn)行狀態(tài)。設(shè)計(jì)合理的系統(tǒng)一般都會(huì)提供相關(guān)監(jiān)控指標(biāo)供監(jiān)控系統(tǒng)采集。監(jiān)控?cái)?shù)據(jù)的采集方法一般可以分為以下幾大類：

• 日志：日志可以包含服務(wù)運(yùn)行的方方面面，是重要的監(jiān)控?cái)?shù)據(jù)來源。例如，通過Nginx access日志可以統(tǒng)計(jì)出錯(cuò)誤（5xx）、延遲（響應(yīng)時(shí)間）和流量，結(jié)合已知的容量上限就可以計(jì)算出飽和度。一般除監(jiān)控系統(tǒng)提供的日志采集插件外，如Rsyslog、Logstash、Filebeat、Flume等都是比較優(yōu)秀的日志采集軟件
• JMX：多數(shù)Java開發(fā)的服務(wù)均可由JMX接口輸出監(jiān)控指標(biāo)。不少監(jiān)控系統(tǒng)也有集成JMX采集插件，除此之外我們也可通過jmxtrans、jmxcmd工具進(jìn)行采集
• REST：提供REST API來進(jìn)行監(jiān)控?cái)?shù)據(jù)的采集，如Hadoop、ElasticSearch
• OpenMetrics：得益于Prometheus的流行，作為Prometheus的監(jiān)控?cái)?shù)據(jù)采集方案，OpenMetrics可能很快會(huì)成為未來監(jiān)控的業(yè)界標(biāo)準(zhǔn)。目前絕大部分熱門開源服務(wù)均有官方或非官方的exporter可供使用
• 命令行：一些服務(wù)提供本地的命令來輸出監(jiān)控指標(biāo)
• 主動(dòng)上報(bào)：對(duì)于采用PUSH模型的監(jiān)控系統(tǒng)來說，服務(wù)可以采取主動(dòng)上報(bào)的方式把監(jiān)控指標(biāo)push到監(jiān)控系統(tǒng)，如Java服務(wù)可使用Metrics接口自定義sink輸出。另外，運(yùn)維也可以使用自定義的監(jiān)控插件來完成監(jiān)控的采集
• 埋點(diǎn)：埋點(diǎn)是侵入式的監(jiān)控?cái)?shù)據(jù)采集方式，其優(yōu)點(diǎn)是其可以更靈活地為我們提供業(yè)務(wù)內(nèi)部的監(jiān)控指標(biāo)，當(dāng)然缺點(diǎn)也很明顯：需要在代碼層面動(dòng)手腳（常常需要研發(fā)支持，成本較高）
• 其它方式：以上未涵蓋的監(jiān)控指標(biāo)采集方式，例如Zookeeper的四字命令，MySQL的show status命令

以上列出了幾種常見的監(jiān)控指標(biāo)采集方法，在實(shí)際工作，如果沒有現(xiàn)成的監(jiān)控采集插件，則需要我們自行開發(fā)采集腳本。

四個(gè)黃金指標(biāo)

圖 2 四個(gè)黃金指標(biāo)

無論業(yè)務(wù)系統(tǒng)如何復(fù)雜，監(jiān)控指標(biāo)如何眼花繚亂，但萬變不離其宗，監(jiān)控的目的無非是為了解服務(wù)運(yùn)行狀況、發(fā)現(xiàn)服務(wù)故障和幫助定位故障原因。為了達(dá)成這個(gè)目的，Google SRE總結(jié)的監(jiān)控四個(gè)黃金指標(biāo)對(duì)我們添加監(jiān)控具有非常重要的指導(dǎo)意義。圖 2給出四個(gè)黃金指標(biāo)所包含的主要監(jiān)控指標(biāo)，下面我們就這四個(gè)黃金指標(biāo)分別展開說明，并給出一些監(jiān)控項(xiàng)的采集實(shí)例。

錯(cuò)誤：錯(cuò)誤是指當(dāng)前系統(tǒng)發(fā)生的錯(cuò)誤請(qǐng)求

和錯(cuò)誤率

說明：

錯(cuò)誤是需要在添加監(jiān)控時(shí)首要關(guān)注的指標(biāo)。在添加錯(cuò)誤相關(guān)監(jiān)控時(shí)，我們應(yīng)該關(guān)注以下幾個(gè)方面：

基礎(chǔ)監(jiān)控：宕機(jī)、磁盤（壞盤或文件系統(tǒng)錯(cuò)誤）、進(jìn)程或端口掛掉、網(wǎng)絡(luò)丟包等故障

業(yè)務(wù)監(jiān)控：

• 核心功能處理錯(cuò)誤，每種系統(tǒng)都有特定的核心功能，比如HDFS的文件塊讀寫、Zookeeper對(duì)Key的讀寫和修改操作
• 基礎(chǔ)功能單元丟失或異常，這里的基礎(chǔ)功能單元是指一個(gè)系統(tǒng)功能上的基本單位，例如HDFS的Block、Kafka的Message，這種基礎(chǔ)數(shù)據(jù)的丟失一般都會(huì)對(duì)業(yè)務(wù)功能造成直接的影響
• Master故障，對(duì)于中心化的分布式系統(tǒng)來說，Master的健康狀況都是重中之重。例如HDFS的NameNode、Zookeeper的Leader，ElasticSearch的MasterNode
• 可用節(jié)點(diǎn)數(shù)，對(duì)于分布式系統(tǒng)來說，可用節(jié)點(diǎn)數(shù)也是非常重要的，比如Zookeeper、ETCD等系統(tǒng)需要滿足可用節(jié)點(diǎn)數(shù)大于不可用節(jié)點(diǎn)數(shù)才能保證功能的正常

注意：除白盒監(jiān)控外，主要功能或接口、以及內(nèi)部存在明顯邊界的功能模塊和上游依賴模塊，都應(yīng)該添加黑盒端到端監(jiān)控。

延遲：服務(wù)請(qǐng)求所需時(shí)間

說明：

服務(wù)延遲的上升不僅僅體現(xiàn)在用戶體驗(yàn)的下降，也有可能會(huì)導(dǎo)致請(qǐng)求堆積并最終演變?yōu)檎麄€(gè)業(yè)務(wù)系統(tǒng)的雪崩。以下為延遲指標(biāo)的主要關(guān)注點(diǎn)：

• 基礎(chǔ)監(jiān)控：IO等待、網(wǎng)絡(luò)延遲
• 業(yè)務(wù)監(jiān)控：業(yè)務(wù)相關(guān)指標(biāo)主要需要關(guān)注核心功能的響應(yīng)時(shí)長。比如Zookeeper的延遲指標(biāo)zk_avg_latency，ElasticSearch的索引、搜索延遲和慢查詢

注意：與錯(cuò)誤指標(biāo)類似，白盒延遲指標(biāo)通常僅能代表系統(tǒng)內(nèi)部延遲，建議為主要功能或接口添加黑盒監(jiān)控來采集端到端的延遲指標(biāo)。

流量：當(dāng)前系統(tǒng)的流量

說明：

流量指標(biāo)可以指系統(tǒng)層面的網(wǎng)絡(luò)和磁盤IO，服務(wù)層面的QpS、PV和UV等數(shù)據(jù)。流量和突增或突減都可能預(yù)示著系統(tǒng)可能出現(xiàn)問題（攻擊事件、系統(tǒng)故障…）。

• 基礎(chǔ)監(jiān)控：磁盤和網(wǎng)卡IO
• 業(yè)務(wù)監(jiān)控：核心功能流量，例如通過QpS/PV/UV等通常能夠代表Web服務(wù)的流量，而ElasticSearch的流量可用索引創(chuàng)建速率、搜索速率表示

飽和度：用于衡量當(dāng)前服務(wù)的利用率

說明：

更為通俗的講，飽和度可以理解為服務(wù)的利用率，可以代表系統(tǒng)承受的壓力。所以飽和度與流量息息相關(guān)，流量的上升一般也會(huì)導(dǎo)致飽和度的上升。通常情況下，每種業(yè)務(wù)系統(tǒng)都應(yīng)該有各自的飽和度指標(biāo)。在很多業(yè)務(wù)系統(tǒng)中，消息隊(duì)列長度是一個(gè)比較重要的飽和度指標(biāo)，除此之外CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)等系統(tǒng)資源利用率也可以作為飽和度的一種體現(xiàn)方式。

基礎(chǔ)監(jiān)控：CPU、內(nèi)存、磁盤和網(wǎng)絡(luò)利用率、內(nèi)存堆棧利用率、文件句柄數(shù)、TCP連接數(shù)等

業(yè)務(wù)監(jiān)控：

• 基礎(chǔ)功能單元使用率，大多數(shù)系統(tǒng)對(duì)其基礎(chǔ)的功能單元都有其處理能力的上限，接近或達(dá)到該上限時(shí)可能會(huì)導(dǎo)致服務(wù)的錯(cuò)誤、延遲增大。例如HDFS的Block數(shù)量上升會(huì)導(dǎo)致NameNode堆內(nèi)存使用率上升，Kafka的Topics和Partitions的數(shù)量、Zookeeper的node數(shù)的上升都會(huì)對(duì)系統(tǒng)產(chǎn)生壓力
• 消息隊(duì)列長度，不少系統(tǒng)采用消息隊(duì)列存放待處理數(shù)據(jù)，所以消息隊(duì)列長度在一定程度上可以代表系統(tǒng)的繁忙程度。如ElasticSearch、HDFS等都有隊(duì)列長度相關(guān)指標(biāo)可供采集

總結(jié)

以上總結(jié)了常見的監(jiān)控指標(biāo)采集方法，以及四個(gè)黃金指標(biāo)所包含的常見內(nèi)容。在實(shí)際工作中，不同的監(jiān)控系統(tǒng)的設(shè)計(jì)多種多樣，沒有統(tǒng)一標(biāo)準(zhǔn)，并且不同的業(yè)務(wù)系統(tǒng)通常也有著特定的監(jiān)控采集方法和不同的黃金指標(biāo)定義，具體如何采集監(jiān)控指標(biāo)和添加告警都需要我們針對(duì)不同系統(tǒng)特點(diǎn)靈活應(yīng)對(duì)。

在前面的監(jiān)控系列文章中，我們介紹了Kafka、Zookeeper、ElasticSearch、Hadoop以及電商商城平臺(tái)等一系列開源軟件和業(yè)務(wù)系統(tǒng)的監(jiān)控實(shí)踐。但通常情況下，線上業(yè)務(wù)一般是由眾多開源或自研中間件加上層業(yè)務(wù)系統(tǒng)組成。而業(yè)務(wù)系統(tǒng)的復(fù)雜度會(huì)隨著系統(tǒng)變更和新業(yè)務(wù)上線而發(fā)生快速增長。不斷變化的業(yè)務(wù)環(huán)境下，新業(yè)務(wù)層出不窮。當(dāng)面臨一個(gè)新系統(tǒng)時(shí)，監(jiān)控工作應(yīng)該如何開展?