有很多文章都提到過白盒監控和黑盒監控，以及監控的四個黃金指標。關於白盒與黑盒監控的定義，這裡不再贅述。一般來說，白盒與黑盒分別從內部和外部來監控系統的運行狀況，例如機器存活、CPU 內存使用率、業務日誌、JMX 等監控都屬於白盒監控，而外部端口探活、HTTP 探測以及端到端功能監控等則屬於黑盒監控的範疇。
本文將主要從白盒監控的採集入手，解答關於新系統如何添加監控的問題。
監控指標的採集
配置監控時，我們首要面對的是監控數據如果採集的問題。一般我們可以把監控指標分為兩類：基礎監控和業務監控。
基礎監控
包括 CPU、內存、磁盤、端口和進程等機器、網絡的操作系統級別的信息。通常情況下，成熟的監控系統（例如開源的 Prometheus、Zabbix 等）均會提供基礎監控項的採集能力，這裡不做過多介紹。但需要注意的一點，機器級別的基礎監控指標一般並不能代表服務的真實運行狀況，例如單臺實例的故障對一個設計合理的分佈式系統來說並不會帶來嚴重後果。所以只有結合業務相關監控指標，基礎監控指標才有意義。
業務監控
業務監控指標由業務系統內部的服務產生，一般能夠真實反應業務運行狀態。設計合理的系統一般都會提供相關監控指標供監控系統採集。監控數據的採集方法一般可以分為以下幾大類。
日誌：日誌可以包含服務運行的方方面面，是重要的監控數據來源。例如，通過 Nginx access 日誌可以統計出錯誤（5xx）、延遲（響應時間）和流量，結合已知的容量上限就可以計算出飽和度。一般除監控系統提供的日誌採集插件外，如 Rsyslog、Logstash、Filebeat、Flume 等都是比較優秀的日誌採集軟件。
JMX：多數 Java 開發的服務均可由 JMX 接口輸出監控指標。不少監控系統也有集成 JMX 採集插件，除此之外我們也可通過 jmxtrans、jmxcmd 工具進行採集。
REST：提供 REST API 來進行監控數據的採集，如 Hadoop、ElasticSearch。
OpenMetrics：得益於 Prometheus 的流行，作為 Prometheus 的監控數據採集方案，OpenMetrics 可能很快會成為未來監控的業界標準。目前絕大部分熱門開源服務均有官方或非官方的 exporter 可供使用。
命令行：一些服務提供本地的命令來輸出監控指標。
主動上報：對於採用 PUSH 模型的監控系統來說，服務可以採取主動上報的方式把監控指標 push 到監控系統，如 Java 服務可使用 Metrics 接口自定義 sink 輸出。另外，運維也可以使用自定義的監控插件來完成監控的採集。
埋點：埋點是侵入式的監控數據採集方式，其優點是其可以更靈活地為我們提供業務內部的監控指標，當然缺點也很明顯：需要在代碼層面動手腳（常常需要研發支持，成本較高）。
其它方式：以上未涵蓋的監控指標採集方式，例如 Zookeeper 的四字命令，MySQL 的 show status 命令。
以上列出了幾種常見的監控指標採集方法，在實際工作，如果沒有現成的監控採集插件，則需要我們自行開發採集腳本。
監控的四個黃金指標
無論業務系統如何複雜，監控指標如何眼花繚亂，但萬變不離其宗，監控的目的無非是為了解服務運行狀況、發現服務故障和幫助定位故障原因。為了達成這個目的，Google SRE 總結的監控四個黃金指標對我們添加監控具有非常重要的指導意義。下圖給出四個黃金指標所包含的主要監控指標，下面我們就這四個黃金指標分別展開說明，並給出一些監控項的採集實例。
錯誤：錯誤是指當前系統發生的錯誤請求和錯誤率
錯誤是需要在添加監控時首要關注的指標。在添加錯誤相關監控時，我們應該關注以下幾個方面：
基礎監控：宕機、磁盤（壞盤或文件系統錯誤）、進程或端口掛掉、網絡丟包等故障。
業務監控：
核心功能處理錯誤，每種系統都有特定的核心功能，比如 HDFS 的文件塊讀寫、Zookeeper 對 Key 的讀寫和修改操作。
基礎功能單元丟失或異常，這裡的基礎功能單元是指一個系統功能上的基本單位，例如 HDFS 的 Block、Kafka 的 Message，這種基礎數據的丟失一般都會對業務功能造成直接的影響。
Master 故障，對於中心化的分佈式系統來說，Master 的健康狀況都是重中之重。例如 HDFS 的 NameNode、Zookeeper 的 Leader，ElasticSearch 的 MasterNode。
可用節點數，對於分佈式系統來說，可用節點數也是非常重要的，比如 Zookeeper、ETCD 等系統需要滿足可用節點數大於不可用節點數才能保證功能的正常。
注意：除白盒監控外，主要功能或接口、以及內部存在明顯邊界的功能模塊和上游依賴模塊，都應該添加黑盒端到端監控。
延遲：服務請求所需時間
服務延遲的上升不僅僅體現在用戶體驗的下降，也有可能會導致請求堆積並最終演變為整個業務系統的雪崩。
以下為延遲指標的主要關注點：
基礎監控：IO 等待、網絡延遲；
業務監控：業務相關指標主要需要關注核心功能的響應時長。比如 Zookeeper 的延遲指標 zk_avg_latency，ElasticSearch 的索引、搜索延遲和慢查詢。
注意：與錯誤指標類似，白盒延遲指標通常僅能代表系統內部延遲，建議為主要功能或接口添加黑盒監控來採集端到端的延遲指標。
流量：當前系統的流量
流量指標可以指系統層面的網絡和磁盤 IO，服務層面的 QpS、PV 和 UV 等數據。流量和突增或突減都可能預示著系統可能出現問題（攻擊事件、系統故障…）。一下為流量主要關注的方面：
基礎監控：磁盤和網卡 IO；
業務監控：核心功能流量，例如通過 QpS/PV/UV 等通常能夠代表 Web 服務的流量，而 ElasticSearch 的流量可用索引創建速率、搜索速率表示。
飽和度：用於衡量當前服務的利用率
更為通俗的講，飽和度可以理解為服務的利用率，可以代表系統承受的壓力。所以飽和度與流量息息相關，流量的上升一般也會導致飽和度的上升。通常情況下，每種業務系統都應該有各自的飽和度指標。
在很多業務系統中，消息隊列長度是一個比較重要的飽和度指標，除此之外 CPU、內存、磁盤、網絡等系統資源利用率也可以作為飽和度的一種體現方式。
基礎監控：CPU、內存、磁盤和網絡利用率、內存堆棧利用率、文件句柄數、TCP 連接數等；
業務監控：
基礎功能單元使用率，大多數系統對其基礎的功能單元都有其處理能力的上限，接近或達到該上限時可能會導致服務的錯誤、延遲增大。例如 HDFS 的 Block 數量上升會導致 NameNode 堆內存使用率上升，Kafka 的 Topics 和 Partitions 的數量、Zookeeper 的 node 數的上升都會對系統產生壓力。
消息隊列長度，不少系統採用消息隊列存放待處理數據，所以消息隊列長度在一定程度上可以代表系統的繁忙程度。如 ElasticSearch、HDFS 等都有隊列長度相關指標可供採集。
總結
以上總結了常見的監控指標採集方法，以及四個黃金指標所包含的常見內容。在實際工作中，不同的監控系統的設計多種多樣，沒有統一標準，並且不同的業務系統通常也有著特定的監控採集方法和不同的黃金指標定義，具體如何採集監控指標和添加告警都需要我們針對不同系統特點靈活應對。
閱讀更多 運維猿 的文章
