-
日誌:日誌可以包含服務執行的方方面面,是重要的監控資料來源。例如,透過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命令
-
核心功能處理錯誤,每種系統都有特定的核心功能,比如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等通常能夠代表Web服務的流量,而ElasticSearch的流量可用索引建立速率、搜尋速率表示
-
基礎功能單元使用率,大多數系統對其基礎的功能單元都有其處理能力的上限,接近或達到該上限時可能會導致服務的錯誤、延遲增大。例如HDFS的Block數量上升會導致NameNode堆記憶體使用率上升,Kafka的Topics和Partitions的數量、Zookeeper的node數的上升都會對系統產生壓力
-
訊息佇列長度,不少系統採用訊息佇列存放待處理資料,所以訊息佇列長度在一定程度上可以代表系統的繁忙程度。如ElasticSearch、HDFS等都有佇列長度相關指標可供採集