歡迎光臨
每天分享高質量文章

運維監控的終極秘籍

 

有很多文章多次提到白盒監控和黑盒監控,以及監控的四個黃金指標。關於白盒與黑盒監控的定義,在之前的文章中已有說明,這裡不再贅述。一般來說,白盒與黑盒分別從內部和外部來監控系統的執行狀況,例如機器存活、CPU記憶體使用率、業務日誌、JMX等監控都屬於白盒監控,而外部埠探活、HTTP探測以及端到端功能監控等則屬於黑盒監控的範疇。
本文將主要從白盒監控的採集入手,解答關於新系統如何新增監控的問題。
圖 1 黑盒與白盒監控

 

監控指標的採集

 

配置監控時,我們首要面對的是監控資料如何採集的問題。一般我們可以把監控指標分為兩類:基礎監控和業務監控。
基礎監控
包括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命令

以上列出了幾種常見的監控指標採集方法,在實際工作,如果沒有現成的監控採集外掛,則需要我們自行開發採集指令碼。

 

四個黃金指標

 

圖 2 四個黃金指標
無論業務系統如何複雜,監控指標如何眼花繚亂,但萬變不離其宗,監控的目的無非是為瞭解服務執行狀況、發現服務故障和幫助定位故障原因。為了達成這個目的,Google SRE總結的監控四個黃金指標對我們新增監控具有非常重要的指導意義。圖 2給出四個黃金指標所包含的主要監控指標,下麵我們就這四個黃金指標分別展開說明,並給出一些監控項的採集實體。
錯誤:錯誤是指當前系統發生的錯誤請求和錯誤率
錯誤是需要在新增監控時首要關註的指標。
在新增錯誤相關監控時,我們應該關註以下幾個方面:
基礎監控:宕機、磁碟(壞盤或檔案系統錯誤)、行程或埠掛掉、網路丟包等故障
業務監控:
  • 核心功能處理錯誤,每種系統都有特定的核心功能,比如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等都有佇列長度相關指標可供採集

總結

 

以上總結了常見的監控指標採集方法,以及四個黃金指標所包含的常見內容。在實際工作中,不同的監控系統的設計多種多樣,沒有統一標準,並且不同的業務系統通常也有著特定的監控採集方法和不同的黃金指標定義,具體如何採集監控指標和新增告警都需要我們針對不同系統特點靈活應對。
本文轉載自公眾號:京東雲,點選檢視原文

 

Kubernetes實戰培訓

 

Kubernetes實戰培訓將於2019年3月8日在深圳開課,3天時間帶你係統掌握Kubernetes,學習效果不好可以繼續學習本次培訓包括:雲原生介紹、微服務;Docker基礎、Docker工作原理、映象、網路、儲存、資料捲、安全;Kubernetes架構、核心元件、常用物件、網路、儲存、認證、服務發現、排程和服務質量保證、日誌、監控、告警、Helm、實踐案例等。
    閱讀原文

    贊(0)

    分享創造快樂