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

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

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

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

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

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

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

日志：日志可以包含服務(wù)運行的方方面面，是重要的監(jiān)控數(shù)據(jù)來源。例如，通過 Nginx access 日志可以統(tǒng)計出錯誤（5xx）、延遲（響應(yīng)時間）和流量，結(jié)合已知的容量上限就可以計算出飽和度。一般除監(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)控數(shù)據(jù)的采集，如 Hadoop、ElasticSearch。

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

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

主動上報：對于采用 PUSH 模型的監(jiān)控系統(tǒng)來說，服務(wù)可以采取主動上報的方式把監(jiān)控指標(biāo) push 到監(jiān)控系統(tǒng)，如 Java 服務(wù)可使用 Metrics 接口自定義 sink 輸出。另外，運維也可以使用自定義的監(jiān)控插件來完成監(jiān)控的采集。

埋點：埋點是侵入式的監(jiān)控數(shù)據(jù)采集方式，其優(yōu)點是其可以更靈活地為我們提供業(yè)務(wù)內(nèi)部的監(jiān)控指標(biāo)，當(dāng)然缺點也很明顯：需要在代碼層面動手腳（常常需要研發(fā)支持，成本較高）。

其它方式：以上未涵蓋的監(jiān)控指標(biāo)采集方式，例如 Zookeeper 的四字命令，MySQL 的 show status 命令。

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

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

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

四個黃金指標(biāo)

錯誤：錯誤是指當(dāng)前系統(tǒng)發(fā)生的錯誤請求和錯誤率

錯誤是需要在添加監(jiān)控時首要關(guān)注的指標(biāo)。

在添加錯誤相關(guān)監(jiān)控時，我們應(yīng)該關(guān)注以下幾個方面：

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

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

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

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

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

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

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

延遲：服務(wù)請求所需時間

服務(wù)延遲的上升不僅僅體現(xiàn)在用戶體驗的下降，也有可能會導(dǎo)致請求堆積并最終演變?yōu)檎麄�業(yè)務(wù)系統(tǒng)的雪崩。

以下為延遲指標(biāo)的主要關(guān)注點：

基礎(chǔ)監(jiān)控：IO 等待、網(wǎng)絡(luò)延遲；

業(yè)務(wù)監(jiān)控：業(yè)務(wù)相關(guān)指標(biāo)主要需要關(guān)注核心功能的響應(yīng)時長。比如 Zookeeper 的延遲指標(biāo) zk_avg_latency，ElasticSearch 的索引、搜索延遲和慢查詢。

注意：與錯誤指標(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)故障…）。一下為流量主要關(guān)注的方面：

基礎(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)，流量的上升一般也會導(dǎo)致飽和度的上升。通常情況下，每種業(yè)務(wù)系統(tǒng)都應(yīng)該有各自的飽和度指標(biāo)。

在很多業(yè)務(wù)系統(tǒng)中，消息隊列長度是一個比較重要的飽和度指標(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)對其基礎(chǔ)的功能單元都有其處理能力的上限，接近或達(dá)到該上限時可能會導(dǎo)致服務(wù)的錯誤、延遲增大。例如 HDFS 的 Block 數(shù)量上升會導(dǎo)致 NameNode 堆內(nèi)存使用率上升，Kafka 的 Topics 和 Partitions 的數(shù)量、Zookeeper 的 node 數(shù)的上升都會對系統(tǒng)產(chǎn)生壓力。

消息隊列長度，不少系統(tǒng)采用消息隊列存放待處理數(shù)據(jù)，所以消息隊列長度在一定程度上可以代表系統(tǒng)的繁忙程度。如 ElasticSearch、HDFS 等都有隊列長度相關(guān)指標(biāo)可供采集。

總結(jié)   

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