有很多文章都提到過(guò)白盒監(jiān)控和黑盒監(jiān)控，以及監(jiān)控的四個(gè)黃金指標(biāo)。關(guān)于白盒與黑盒監(jiān)控的定義，這里不再贅述。一般來(lái)說(shuō)，白盒與黑盒分別從內(nèi)部和外部來(lái)監(jiān)控系統(tǒng)的運(yùn)行狀況，例如機(jī)器存活、CPU 內(nèi)存使用率、業(yè)務(wù)日志、JMX 等監(jiān)控都屬于白盒監(jiān)控，而外部端口探活、HTTP 探測(cè)以及端到端功能監(jiān)控等則屬于黑盒監(jiān)控的范疇。

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

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

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

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

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

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

日志：日志可以包含服務(wù)運(yùn)行的方方面面，是重要的監(jiān)控?cái)?shù)據(jù)來(lái)源。例如，通過(guò) 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 開(kāi)發(fā)的服務(wù)均可由 JMX 接口輸出監(jiān)控指標(biāo)。不少監(jiān)控系統(tǒng)也有集成 JMX 采集插件，除此之外我們也可通過(guò) jmxtrans、jmxcmd 工具進(jìn)行采集。

REST：提供 REST API 來(lái)進(jìn)行監(jiān)控?cái)?shù)據(jù)的采集，如 Hadoop、ElasticSearch。

OpenMetrics：得益于 Prometheus 的流行，作為 Prometheus 的監(jiān)控?cái)?shù)據(jù)采集方案，OpenMetrics 可能很快會(huì)成為未來(lái)監(jiān)控的業(yè)界標(biāo)準(zhǔn)。目前絕大部分熱門(mén)開(kāi)源服務(wù)均有官方或非官方的 exporter 可供使用。

命令行：一些服務(wù)提供本地的命令來(lái)輸出監(jiān)控指標(biāo)。

主動(dòng)上報(bào)：對(duì)于采用 PUSH 模型的監(jiān)控系統(tǒng)來(lái)說(shuō)，服務(wù)可以采取主動(dòng)上報(bào)的方式把監(jiān)控指標(biāo) push 到監(jiān)控系統(tǒng)，如 Java 服務(wù)可使用 Metrics 接口自定義 sink 輸出。另外，運(yùn)維也可以使用自定義的監(jiān)控插件來(lái)完成監(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)的監(jiān)控指標(biāo)采集方法，在實(shí)際工作，如果沒(méi)有現(xiàn)成的監(jiān)控采集插件，則需要我們自行開(kāi)發(fā)采集腳本。

監(jiān)控的四個(gè)黃金指標(biāo)

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

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

錯(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ī)、磁盤(pán)（壞盤(pán)或文件系統(tǒng)錯(cuò)誤）、進(jìn)程或端口掛掉、網(wǎng)絡(luò)丟包等故障。

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

核心功能處理錯(cuò)誤，每種系統(tǒng)都有特定的核心功能，比如 HDFS 的文件塊讀寫(xiě)、Zookeeper 對(duì) Key 的讀寫(xiě)和修改操作。

基礎(chǔ)功能單元丟失或異常，這里的基礎(chǔ)功能單元是指一個(gè)系統(tǒng)功能上的基本單位，例如 HDFS 的 Block、Kafka 的 Message，這種基礎(chǔ)數(shù)據(jù)的丟失一般都會(huì)對(duì)業(yè)務(wù)功能造成直接的影響。

Master 故障，對(duì)于中心化的分布式系統(tǒng)來(lái)說(shuō)，Master 的健康狀況都是重中之重。例如 HDFS 的 NameNode、Zookeeper 的 Leader，ElasticSearch 的 MasterNode。

可用節(jié)點(diǎn)數(shù)，對(duì)于分布式系統(tǒng)來(lái)說(shuō)，可用節(jié)點(diǎn)數(shù)也是非常重要的，比如 Zookeeper、ETCD 等系統(tǒng)需要滿(mǎn)足可用節(jié)點(diǎn)數(shù)大于不可用節(jié)點(diǎn)數(shù)才能保證功能的正常。

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

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

服務(wù)延遲的上升不僅僅體現(xiàn)在用戶(hù)體驗(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í)長(zhǎng)。比如 Zookeeper 的延遲指標(biāo) zk_avg_latency，ElasticSearch 的索引、搜索延遲和慢查詢(xún)。

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

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

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

基礎(chǔ)監(jiān)控：磁盤(pán)和網(wǎng)卡 IO；

業(yè)務(wù)監(jiān)控：核心功能流量，例如通過(guò) 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ì)列長(zhǎng)度是一個(gè)比較重要的飽和度指標(biāo)，除此之外 CPU、內(nèi)存、磁盤(pán)、網(wǎng)絡(luò)等系統(tǒng)資源利用率也可以作為飽和度的一種體現(xiàn)方式。

基礎(chǔ)監(jiān)控：CPU、內(nèi)存、磁盤(pán)和網(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ì)列長(zhǎng)度，不少系統(tǒng)采用消息隊(duì)列存放待處理數(shù)據(jù)，所以消息隊(duì)列長(zhǎng)度在一定程度上可以代表系統(tǒng)的繁忙程度。如 ElasticSearch、HDFS 等都有隊(duì)列長(zhǎng)度相關(guān)指標(biāo)可供采集。

總結(jié)   

以上總結(jié)了常見(jiàn)的監(jiān)控指標(biāo)采集方法，以及四個(gè)黃金指標(biāo)所包含的常見(jiàn)內(nèi)容。在實(shí)際工作中，不同的監(jiān)控系統(tǒng)的設(shè)計(jì)多種多樣，沒(méi)有統(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ì)。