【Prometheus】監控系統概述

</header>

現在開始一個新的系列，【Prometheus】，主要參考《深入淺出Prometheus》，基本為其讀書筆記加上部分自己的理解

概覽

在本系列中，監控系統特指對數據中心的監控，包括硬件和軟件的監控和告警

監控系統的作用：

1. 實時監控。提供硬件和軟件的運行狀態展示
2. 告警。符合預設告警閾值則通過多種方式發送告警信息
3. 輔助決策。大數據監控不僅提供實時狀態展現，更能幫助故障回溯和預測風險

根據程序設計的角度來分類，監控的種類如下，每種監控都涉及不同的監控指標，不同的收集方式，具體在下文分析

 

image

基礎資源監控

網絡

1. 網絡性能監控。涉及網絡監測、網絡實時流量監控（網絡延遲、訪問量、成功率等）和歷史數據統計、匯總和歷史數據分析
2. 網絡攻擊檢查。針對內網或者外網的網絡攻擊如 DDoS 攻擊等，通過分析異常流量來確定網絡攻擊行為
3. 設備監控。對數據中心的網絡設備監控，如路由器、防火牆、交換機，通過SNMP協議收集

服務器

監控分類：

1. 主機監控。服務器硬件來源於不同廠商，需要獲取不同廠商的服務器硬件信息
2. 虛擬機監控。不同的操作系統如 Windows、Linux，采集軟件需要做到跨平台運行以獲取對應的指標
3. 容器監控。兼容各種虛擬化環境如虛擬機（KVM、VMware、Xen）及容器（Docker、rkt）

采集方式有兩種：

1. 主機監控。IPMI（Intelligent Platform Management Interface，智能平台管理接口）實現。IPMI是一種標准開放的硬件管理接口，不依賴於操作系統，可以提供服務器的風扇、溫度、電壓等信息
2. 虛擬機監控。一是內置客戶端。在每台機器上安裝采集客戶端。二是在虛擬機環境下通過Xen API、VMware Vcenter API獲取監控數據
3. 容器監控。Docker API或針對不同服務/中間件開發的采集器exporter作為一個運行容器進行導出

采集指標：

1. CPU。CPU使用量、用戶態百分比、內核態百分比、每個CPU的使用量、等待隊列長度、I/O等待百分比、CPU消耗最多的進程、上下文切換次數、緩存命中率
2. 內存。使用量、剩余量、內存占用最高的進程、交換分區大小、缺頁異常數
3. 網絡I/O。涉及每個網卡的上行流量、下行流量、網絡延遲、丟包率
4. 磁盤I/O。涉及硬盤的讀寫速率、IOPS、磁盤用量、讀寫延遲

中間件監控

中間件監控需要針對不同中間件的特點和屬性分別監控，目前並沒有統一的標准和規范

例如，針對 Kafka 的性能監控通常需要采集 Kafka 集群的 Topic 個數、Broker 數據分區數量、日志 Offset值和生產消費流量等指標

針對 Redis的性能監控通常需要采集 Redis 的內存使用量、連接數和緩存命中率等指標

解決方案通常是分別開發一個數據收集 Agent，該 Agent 將采集中間件的性能指標並將其統一轉化成 JSON、文本或者其他監控系統能識別的數據格式，然后匯總到監控中心

Prometheus針對不同的中間件開發了對應的監控代理，例如Kafka exporter、MySQL server exporter、Apache exporter、Redis exporter等exporter，它們負責采集這些中間件的特定指標，並提供HTTP查詢接口

應用程序監控（APM）

采集的方法是將采集器運行在容器內，導出所有容器運行的數據

1. 調用鏈跟蹤。從用戶發送請求到后端API服務，以及API服務和關聯的中間件或者其他組件之間的調用，構建出一個完整的調用拓撲結構
2. 性能監控。監控組件內部方法的調用層次（Controller→Service→DAO），獲取每個函數的執行耗時，從而為性能調優提供數據支撐。還能截獲TCP、HTTP網絡請求，從而獲得執行耗時最長的方法和SQL語句、延遲最大的API等信息
3. 運行狀態監控。根據業務指標、日志指標、調用鏈指標、應用環境指標、應用集群指標、服務組件指標、線程棧和客戶端體驗數據等，形成全維度的指標，展示為服務運行狀態

日志監控

日志監控采集日志數據（文本類型），並將這些數據匯總到日志存儲和搜索引擎中，提供日志檢索的 Web 接入。指標監控的對象通常都是數字，而日志監控的對象是文本數據，這就要求存儲系統具備文本檢索功能

下面是流行的日志監控黃金組合：

 

image

1. Fluentd：日志采集，還有Filebeat、Flume、Fluent Bit，也有一些應用集成Log4g等日志組件直接輸出日志
2. Kafka：數據整流合並，避免突發日志流量直接沖擊Logstash
3. Logstash：日志整理，完成日志過濾、日志修改等功能
4. Elasticsearch：日志存儲和日志檢索，自帶分布式存儲，可以將采集的日志進行分片存儲
5. Kibana：日志查詢組件，負責日志展現，主要通過Elasticsearch的HTTP接口展現日志

監控系統實現

總體架構

• 指標采集子系統。負責信息采集、過濾、匯總和存儲
• 數據處理子系統。負責數據分析、展現、預警、告警動作觸發和告警

 

image

指標采集子系統

數據采集

• 通過客戶端進行數據采集。針對特定的設備和系統開發的采集器。客戶端會將采集到的數據上報到監控中心節點進行匯聚存儲。這種方式比較靈活，在理論上任何對象都是可以被監控的。但客戶端本身需要一定的開發工作，采用侵入的方式安裝客戶端也存在安全和性能風險
• 通過標准協議進行數據采集。優點是數據規范統一、普適性更廣，所有Java應用都可以實現 JMX 協議，從而完成應用指標監控。但目前數據中心內的軟硬件各異，設備和軟件對協議的支持也不完善，在很大程度上限制了通過協議進行數據采集的能力

數據傳輸和過濾

• HTTP、Socket連接進行點對點傳輸。如果 Agent（采集器）是一個 HTTP 服務端，那么采集中心節點會周期性調用 Agent 的接口獲取數據，這種方式被稱為 Pull（拉取）；相反，如果 Agent是一個 HTTP客戶端，它就會調用中心節點的 HTTP服務，將數據發送到中心節點，這種方式被稱為Push（推送）
• RabbitMQ、Kafka等消息中間件進行傳輸。使用消息中間件傳輸的方式在結構上充分解耦。消息中間件不僅可以將監控數據進行一定程度的持久化，而且可以對監控數據進行整流，避免突發流量沖擊數據收集組件。但會造成整個系統對中間件的強依賴，如果中間件發生故障，則可能導致整個系統發生故障，並且消息中間件在安裝部署及后期的運維中都比較復雜。

HTTP 傳輸的方式雖然有一定的耦合度，但系統可以足夠簡單，易於擴展和維護，大部分開源監控系統都采用這種方式

在持久化之前，通常還需要對收集的數據進行簡單去重和過濾，主要有以下幾個場景：

1. 客戶端重復上報數據。網絡不穩定等因素
2. 去除無用指標。客戶端上報的指標通常是全集，而有些指標是系統並不關注的

數據存儲

對監控數據的存儲通常借助於時序數據庫。監控數據的最大特點是有時間屬性，每個監控數據都有一個時間維度（屬性），被稱為時序數據，展現了一個物體的某些特征在一段時間內的變化情況

時序數據的特點：

• 一次性寫入多次讀取。時序數據通常不會修改更新，一旦存入，則后期只會對數據進行查詢操作
• 數據流持續平穩且量大。時序數據量往往和采集點的數據量成正比，不會出現業務系統流量突增的情況，並且數據流是持續穩定的，通常間隔一個穩定的采集周期來獲取數據。但存儲的數據量會慢慢變得非常大。
• 查詢方式以時間為維度，數據查詢通常會指定一段時間，並且熱數據通常都是最新采集的數據。在實際場景中通常查詢最近幾個小時的監控數據

所以，與關系型數據庫采用B+樹不同，時序數據庫通常采用LSM樹，提供更好的寫性能。因為LSM樹存儲框架實現的思路較簡單，其先在內存中保存數據，再定時刷到磁盤，實現順序IO操作，通過定期合並文件減少數據冗余；文件有序，保證讀取操作相對快速。適用於寫多、讀相對少(或較多讀取最新寫入的數據，該部分數據存在內存中，不需要磁盤IO操作)的業務場景

數據處理子系統

數據查詢

通過展現層（瀏覽器或者客戶端）多維度展現實時數據和歷史數據。實時數據查詢嚴格要求數據的准確性和實時性，查詢接口需要迅速響應

另外，可以通過一些Web工具，把后端分析的數據以可視化的方式展現。比如：

• 折線圖能夠很好地展現數據變化的趨勢
• 餅狀圖能更好地展現系統中各個子模塊的占比
• 柱狀圖的優勢在於對數據的對比

數據分析

• 性能分析：分析某個應用在特定時間段內的資源消耗情況，可以將應用按照資源消耗的特點分類。當應用程序出現性能問題時，要能夠通過性能分析確定故障點，並在故障發生后回溯故障發生的原因
• 關聯分析：每個監控數據都存在多個維度，通過關聯分析可以找出數據之間的關聯。在 APM 監控中，通過相同 TraceId 的關聯，可以構建出程序的調用鏈信息，這樣不僅可以分析出組件之間的調用關系，還可以分析出每個調用的耗時，從而優化系統性能
• 趨勢分析：對采集數據指標進行分析，再結合平均數算法、指數平滑算法、Holt線性趨勢算法或其他機器學習模型如自回歸積分滑動平均，分析時序數據內在的周期性，得出未來的變化趨勢。可以用於實時資源調度、預分配資源，還可以輔助數據中心的硬件采購

基於規則告警

利用已經采集的監控數據，匹配用戶自定義的多維度告警規則，如果滿足，則觸發相應規則的告警。例如，性能告警規則一般是設定某個閾值、觸發次數和告警行為

還有一些告警屬於異常告警，例如服務器宕機、網絡不通等情況，通常不需要設定告警規則。如果某個告警規則被觸發，則在接下來的一段時間內，為避免相同的告警被多次觸發，需要進行告警抑制

對告警的處理，會按照用戶預先設定的告警動作執行對應的操作，通常會發送短信、郵件或者觸發用戶定義的 webhook。高級的告警處理可以執行告警的恢復腳本，先在系統中預先設定一些常用的恢復腳本，系統能夠根據發生的不同事件，判斷並使用不同的腳本處理告警事故

作者：fish_man
鏈接：https://www.jianshu.com/p/e603b95c49a9
來源：簡書
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。