1.6 監控系統實現

1.6.1 總體架構

監控系統的實現各有不同，如下所述。

◎ 在數據采集方面，有的監控系統采用主動采集方式，有的監控系統采用被動上報方式，有的監控系統采用上述兩者兼備的方式。

◎ 在數據傳輸方面，有的監控系統采用Socket傳輸，有的監控系統采用HTTP傳輸。

◎ 在數據存儲方面，有的監控系統將監控數據保存在MySQL中，有的監控系統將監控數據保存在MongoDB、OpenTSDB、InfluxDB等時序數據庫中。

但是，所有監控系統的核心都是采集和處理數據，總體架構如圖1-7所示。

監控系統通常由指標采集子系統和數據處理子系統這兩大子系統組成，對這兩種子系統說明如下。

◎ 指標采集子系統主要負責信息采集、過濾、匯總和存儲。

◎ 數據處理子系統主要負責數據分析、展現、預警、告警動作觸發和告警等。

1.6.2 指標采集

指標采集包括數據采集、數據傳輸和過濾，以及數據存儲。

1.數據采集

數據采集有兩種方式：通過客戶端進行數據采集；通過標準協議（如 SNMP、JMX、IPMI等）進行數據采集。

1）通過客戶端進行數據采集

客戶端通常是針對特定的設備和系統開發的采集器，在部署時也和監控對象綁定部署?？蛻舳藭⒉杉降臄祿蠄蟮奖O控中心節點進行匯聚存儲，如果是大規模集群部署的情況，或受限于多機房網絡連通，則通常還需要中繼節點完成數據清洗、過濾和轉發。這種方式比較靈活，在理論上任何對象都是可以被監控的。Prometheus 借助各種 exporter 可以采集各種指標，這些 exporter 都屬于客戶端，并且可以在客戶端對數據進行簡單處理、緩存和超時重試等。但客戶端本身需要一定的開發工作，采用侵入的方式安裝客戶端也存在安全和性能風險，因此管理很多客戶端對于運維人員來說是個很大的挑戰。

2）通過標準協議進行數據采集

通過標準協議進行數據采集的優點是數據規范統一、普適性更廣，所有Java應用都可以實現 JMX 協議，從而完成應用指標監控。SNMP 也定義了一套完整規范，例如將系統磁盤的信息用OID“1.3.6.1.4.1.2021.9”表示，只需遵循SNMP的協議規范就可以通過SNMP進行統一管理和監控。但目前數據中心內的軟硬件各異，設備和軟件對協議的支持也不完善，在很大程度上限制了通過協議進行數據采集的能力。

所以目前監控系統通常將上面兩種方式結合使用，并且客戶端也可以借助標準協議獲取監控數據。

2.數據傳輸和過濾

我們還需要將采集的數據傳輸到數據存儲節點，這時可以通過 HTTP、Socket連接進行點對點傳輸，還可以通過 RabbitMQ、Kafka等消息中間件進行傳輸。

HTTP 是目前互聯網最流行的協議，通過 HTTP 方式傳輸需要一個 HTTP 客戶端和一個 HTTP 服務端。如果 Agent（采集器）是一個 HTTP 服務端，那么采集中心節點會周期性調用 Agent 的接口獲取數據，這種方式被稱為 Pull（拉?。?；相反，如果 Agent是一個 HTTP客戶端，它就會調用中心節點的 HTTP服務，將數據發送到中心節點，這種方式被稱為Push（推送）。Socket方式是指直接建立TCP/IP的傳輸通道，在傳輸上會更加高效，但對Socket連接的維護額外增加開發維護成本，對于開發人員的要求也更高。

使用消息中間件傳輸的方式在結構上充分解耦，數據采集組件只需要將采集的數據放到消息中間件中，數據收集組件只需要從消息中間件中獲取數據。消息中間件不僅可以將監控數據進行一定程度的持久化，而且可以對監控數據進行整流，避免突發流量沖擊數據收集組件。數據收集組件可以部署多個接收消息，均衡流量。采用消息中間件傳輸的方式也有一定的弊端，即會造成整個系統對中間件的強依賴，如果中間件發生故障，則可能導致整個系統發生故障，并且消息中間件在安裝部署及后期的運維中都比較復雜。采用 HTTP 傳輸的方式雖然有一定的耦合度，但系統可以足夠簡單，易于擴展和維護，大部分開源監控系統都采用這種方式。

在持久化之前，通常還需要對收集的數據進行簡單去重和過濾，主要有以下幾個場景：網絡不穩定等因素可能會導致客戶端重復上報數據，此時需要根據監控對象和時間點去重；客戶端上報的指標通常是全集，而有些指標是系統并不關注的，所以需要進行數據過濾，去除一些無用的指標；監控系統采用分區設計，每個監控系統只負責對一部分對象進行監控，此時需要過濾不屬于自己的監控對象的指標。

3.數據存儲

對監控數據的存儲通常借助于時序數據庫（TSDB）。監控數據的最大特點是有時間屬性，每個監控數據都有一個時間維度（屬性），被稱為時序數據，展現了一個物體的某些特征在一段時間內的變化情況。例如，股市數據就是典型的時序數據，在開盤的時候，每個時間點都對應一個股價，并且股價隨著時間的推移不斷改變。

時序數據的特點如下。

◎ 一次性寫入多次讀取，時序數據通常不會修改更新，一旦存入，則后期只會對數據進行查詢操作。

◎ 數據流持續平穩，時序數據量往往和采集點的數據量成正比，不會出現業務系統流量突增的情況，并且數據流是持續穩定的，通常間隔一個穩定的采集周期來獲取數據；相應地，隨著時間的推移，存儲的數據量會變得非常大。

◎ 查詢方式以時間為維度，數據查詢通常會指定一段時間，并且熱數據通常都是最新采集的數據。在實際場景中通常查詢最近幾個小時的監控數據，很少會查詢一周之前的監控數據。

所以，與關系型數據庫采用B+樹不同，時序數據庫通常采用 LSM樹。

時序數據庫的特點是存儲容量大、數據只讀及數據壓縮比很高，同時需要完成每秒千萬級別以上的數據存儲，有著高吞吐量及高并發的特點。開源的時序數據庫有OpenTSDB、InfluxDB等。從DB-Engines在2018年10月發布的各種時序數據庫使用排名可以看出，目前最流行的時序數據庫當屬InfluxDB，但遺憾的是InfluxDB的集群功能只在商業版本中提供；OpenTSDB是基于 HBase的開源時序數據庫，充分發揮了HBase分布式列存儲的特性，支持每秒數百萬次的讀寫，容易擴展且擁有靈活的標簽屬性，所以一直名列前茅；Prometheus 自帶的時序數據庫是使用量增長速度最快的時序數據庫，目前已經超越了OpenTSDB，在未來大有趕超InfluxDB的趨勢，但Prometheus自帶的時序數據庫對大容量數據存儲支持的不足將會限制其發展。

1.6.3 數據處理

數據處理分為數據查詢、數據分析和基于規則告警等，下面一一進行講解。

1.數據查詢

數據查詢指通過展現層（瀏覽器或者客戶端）多維度展現實時數據和歷史數據。實時數據查詢嚴格要求數據的準確性和實時性，查詢接口需要迅速響應。歷史數據查詢則要求數據的時間跨度長，并且可以生成對應的監控報表。為了提高對歷史數據的查詢速度，需要對監控數據降準存儲，例如在每天24點對當天每隔5min采集的樣本數據進行降準匯聚，得到每天的平均值并存儲。若需要查詢一年內的監控指標的變化，則只需要從每天的數據中進一步匯聚。

另外，可以通過一些Web工具，把后端分析的數據以可視化的方式展現。折線圖能夠很好地展現數據變化的趨勢；餅狀圖能更好地展現系統中各個子模塊的占比；柱狀圖的優勢在于對數據的對比。這些圖像化的展現讓數據“動起來”，使其更加直觀。

目前開源的工具有 Grafana、Kibana等，它們都允許用戶自定義監控視圖。如圖1-8所示是一個Grafana官網的樣例，可通過豐富的圖表展現監控數據。

2.數據分析

數據分析是指為用戶或者其他系統提供對監控數據的性能分析、關聯分析和趨勢分析。

◎ 性能分析：分析某個應用在特定時間段內的資源消耗情況，可以將應用按照資源消耗的特點分類，例如對磁盤讀寫頻繁的高I/O類型、CPU消耗突出的高計算類型。在資源調度和分配中，要避免將相同類型的應用部署到同一臺服務器上。當應用程序出現性能問題時，要能夠通過性能分析確定故障點，并在故障發生后回溯故障發生的原因。

◎ 關聯分析：每個監控數據都存在多個維度，通過關聯分析可以找出數據之間的關聯。在網絡監控中，通過將源IP和目的IP的地址進行關聯，可以構建網絡的連接拓撲；在 APM 監控中，通過相同 TraceId 的關聯，可以構建出程序的調用鏈信息，這樣不僅可以分析出組件之間的調用關系，還可以分析出每個調用的耗時，從而優化系統性能。

◎ 趨勢分析：指通過對采集數據指標進行分析，再結合平均數算法、指數平滑算法、Holt線性趨勢算法或其他機器學習模型如自回歸積分滑動平均，分析時序數據內在的周期性，得出未來的變化趨勢。趨勢分析不僅可以用于實時資源調度、預分配資源，還可以輔助數據中心的硬件采購。數據中心是否需要采購機器，不能全靠運維人員的主觀判斷，而應該靠數據說話。用數據驅動決策的理念越來越被大眾熟知。

3.基于規則告警

基于規則告警是指利用已經采集的監控數據，匹配用戶自定義的多維度告警規則，如果滿足，則觸發相應規則的告警。例如，性能告警規則一般是設定某個閾值、觸發次數和告警行為，對于 CPU利用率、內存使用量、QPS等性能指標，如果在某個時間段內多次觸發該閾值，則將其視為滿足告警條件；如果是站點告警，則一般設置請求的返回碼或者正則匹配消息體的內容、觸發次數和告警動作；還有一些告警屬于異常告警，例如服務器宕機、網絡不通等情況，通常不需要設定告警規則。如果某個告警規則被觸發，則在接下來的一段時間內，為避免相同的告警被多次觸發，需要進行告警抑制；如果是由一個“根問題”觸發的一系列子問題的告警，則都需要收斂到這次“根問題”上面。筆者經歷過某銀行的一次網絡故障告警，因為一臺交換機的故障，觸發了幾百條后續相關的告警，嚴重影響了故障排查。

對告警的處理，會按照用戶預先設定的告警動作執行對應的操作，通常會發送短信、郵件或者觸發用戶定義的 webhook（通常是一個 POST 請求，請求體包含此時告警的監控對象、觸發時間及次數，以及監控指標等信息）。高級的告警處理可以執行告警的恢復腳本，先在系統中預先設定一些常用的恢復腳本，系統能夠根據發生的不同事件，判斷并使用不同的腳本處理告警事故。