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

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

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

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

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

基礎監(jiān)控

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

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

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

日志：日志可以包含服務運行的方方面面，是重要的監(jiān)控數(shù)據(jù)來源。例如，通過 Nginx access 日志可以統(tǒng)計出錯誤（5xx）、延遲（響應時間）和流量，結合已知的容量上限就可以計算出飽和度。一般除監(jiān)控系統(tǒng)提供的日志采集插件外，如 Rsyslog、Logstash、Filebeat、Flume 等都是比較優(yōu)秀的日志采集軟件。

JMX：多數(shù) Java 開發(fā)的服務均可由 JMX 接口輸出監(jiān)控指標。不少監(jiān)控系統(tǒng)也有集成 JMX 采集插件，除此之外我們也可通過 jmxtrans、jmxcmd 工具進行采集。

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

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

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

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

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

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

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

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

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

四個黃金指標

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

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

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

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

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

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

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

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)部存在明顯邊界的功能模塊和上游依賴模塊，都應該添加黑盒端到端監(jiān)控。

延遲：服務請求所需時間

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

以下為延遲指標的主要關注點：

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

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

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

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

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

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

業(yè)務監(jiān)控：核心功能流量，例如通過 QpS/PV/UV 等通常能夠代表 Web 服務的流量，而 ElasticSearch 的流量可用索引創(chuàng)建速率、搜索速率表示。

飽和度：用于衡量當前服務的利用率

更為通俗的講，飽和度可以理解為服務的利用率，可以代表系統(tǒng)承受的壓力。所以飽和度與流量息息相關，流量的上升一般也會導致飽和度的上升。通常情況下，每種業(yè)務系統(tǒng)都應該有各自的飽和度指標。

在很多業(yè)務系統(tǒng)中，消息隊列長度是一個比較重要的飽和度指標，除此之外 CPU、內(nèi)存、磁盤、網(wǎng)絡等系統(tǒng)資源利用率也可以作為飽和度的一種體現(xiàn)方式。

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

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

基礎功能單元使用率，大多數(shù)系統(tǒng)對其基礎的功能單元都有其處理能力的上限，接近或達到該上限時可能會導致服務的錯誤、延遲增大。例如 HDFS 的 Block 數(shù)量上升會導致 NameNode 堆內(nèi)存使用率上升，Kafka 的 Topics 和 Partitions 的數(shù)量、Zookeeper 的 node 數(shù)的上升都會對系統(tǒng)產(chǎn)生壓力。

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

總結   

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