[[421126]]

一 形形色色的監控系統

監控一直是IT系統中的核心組成部分，負責問題的發現以及輔助性的定位。無論是傳統運維、SRE、DevOps、開發者都需要關注監控系統并參與到監控系統的建設和優化。從最開始大型機的作業系統、Linux基礎指標，監控系統就已經開始出現并逐漸演進，現階段能夠搜索到的監控系統不下于上百種，按照不同類別也有非常多的劃分方式，例如：

監控對象：通用型（通用的監控方式，適應于大部分的監控對象），專一型（為某一功能定制，例如Java的JMX系統、CPU的高溫保護、硬盤的斷電保護、UPS切換系統、交換機監控系統、專線監控等）；
數據獲取方式：Push（CollectD、Zabbix、InfluxDB）；Pull（Prometheus、SNMP、JMX）；
部署方式：耦合式（和被監控系統在一起部署）；單機（單機單實例部署）；分布式（可以橫向擴展）；SaaS化（很多商業的公司提供SaaS的方式，無需部署）；
數據獲取方式：接口型（只能通過某些API拿去）；DSL（可以有一些計算，例如PromQL、GraphQL）；SQL（標準SQL、類SQL）；
商業屬性：開源免費（例如Prometheus、InfluxDB單機版）；開源商業型（例如InfluxDB集群版、Elastic Search X-Pack）；閉源商業型（例如DataDog、Splunk、AWS Cloud Watch）；

二 Pull or Push

對于建設一套公司內部使用的監控系統平臺，相對來說可選的方案還是非常多的，無論是用開源方案自建還是使用商業的SaaS化產品，都有比較多的可選項。但無論是開源方案還是商業的SaaS產品，真正實施起來都需要考慮如何將數據給到監控平臺，或者說監控平臺如何獲取到這些數據。這里就涉及到數據獲取方式的選型：Pull（拉）還是Push（推）模式？

基于Pull類型的監控系統顧名思義是由監控系統主動去獲取指標，需要被監控的對象能夠具備被遠端訪問的能力；基于Push類型的監控系統不主動獲取數據，而是由監控對象主動推送指標。兩種方式在非常多的地方都有區別，對于監控系統的建設和選型來說，一定要事先了解這兩種方式各自的優劣，選擇合適的方案來實施，否則如果盲目實施，后續對監控系統的穩定性和部署運維代價來說將是災難性的。

三 Pull vs Push概覽

下面將從幾個方面來展開介紹，為了節約讀者時間，這里先用一個表格來做概要性的論述，細節在后面會展開：

四 原理與架構對比

如上圖所示，Pull模型數據獲取的核心是Pull模塊，一般和監控的后端一起部署，例如Prometheus，核心組成包括：

服務發現系統，包括主機的服務發現（一般依賴于公司內部自己的CMDB系統）、應用服務發現（例如Consul）、PaaS服務發現（例如Kubernetes）；Pull模塊需要具備對這些服務發現系統的對接能力
Pull核心模塊，除了服務發現部分外，一般使用通用協議去遠端拉取數據，一般支持配置拉取間隔、超時間隔、指標過濾/Rename/簡單的Process能力
應用側SDK，支持監聽某個固定端口來提供被Pull的能力
由于各類中間件/其他系統不兼容Pull協議，因此需要開發對應的Exporter的Agent，支持拉取這些系統的指標并提供標準的Pull接口
Push模型相對比較簡單：

Push Agent，支持拉取各類被監控對象的指標數據，并推送到服務端，可以和被監控系統耦合部署，也可以單獨部署
ConfigCenter（可選），用來提供中心化的動態配置能力，例如監控目標、采集間隔、指標過濾、指標處理、遠端目標等
應用側SDK，支持發送數據到監控后端，或者發送到本地Agent（通常是本地Agent也實現一套后端的接口）
小結：純粹從部署復雜性上而言，在中間件/其他系統的監控上，Pull模型的部署方式太過復雜，維護代價較高，使用Push模式較為便捷；應用提供Metrics端口或主動Push部署代價相差不大。

五 Pull的分布式解決方案

在擴展性上，Push方式的數據采集天然就是分布式的，在監控后端能力可以跟上的時候，可以無限的橫向擴展。相比之下Pull方式擴展較為麻煩，需要：

Pull模塊與監控后端解耦，Pull作為Agent單獨部署
Pull Agent需要做分布式的協同，一般最簡單是做Sharding，例如從服務發現系統處獲取被監控的機器列表，對這些機器進行Hash后取模Sharding來決定由哪個Agent來負責Pull。
新增一個配置中心（可選）用來管理各個PullAgent
相信反應快的同學已經看出來，這種分布式的方式還是有一些問題：

單點瓶頸還是存在，所有的Agent都需要去請求服務發現模塊
Agent擴容后，監控目標會變化，容易產生數據重復或缺失

六 監控能力對比

1 監控目標存活性

存活性是監控所需要做的第一件也是最基礎的工作，Pull模式監控目標存活性相對來說非常簡單，直接在Pull的中心端就知道能否請求到目標端的指標，如果失敗也能知道一些簡單的錯誤，比如網絡超時、對端拒絕連接等。

Push方式相對來說就比較麻煩，應用沒有上報可能是應用掛了，也可能是網絡問題，也可能是遷移到了其他的節點上了，因為Pull模塊可以和服務發現實時聯動，但Push沒有，所以只有服務端再和服務發現交互才能知道具體失敗的原因。

2 數據齊全度計算

數據齊全度這個概念在大型的監控系統中還是非常重要的，比如監控一千個副本的交易應用的QPS，這個指標需要結合一千個數據進行疊加，如果沒有數據齊全度的概念，若配置QPS相比降低2%告警，由于網絡波動，超過20個副本上報的數據延遲幾秒，那就會觸發誤報。因此在配置告警的時候還需要結合數據齊全度數據進行綜合考慮。

數據齊全度的計算也一樣是依賴于服務發現模塊，Pull方式是按照一輪一輪的方式進行拉取，所以一輪拉取完畢后數據就是齊全的，即使部分拉取失敗也知道數據不全的百分比是多少；

而Push方式由每個Agent、應用主動Push，每個客戶端的Push間隔、網絡延遲都不一樣，需要服務端去根據歷史情況計算數據齊全度，相對代價比較大。

3 短生命周期/Serverless應用監控

在實際場景中，短生命周期/Serverless的應用也有很多，尤其是對成本友好的情況下，我們會大量使用Job、彈性實例、無服務應用等，例如渲染型的任務到達后啟動一個彈性的計算實例，執行完畢后立馬銷毀釋放；機器學習的訓練Job、事件驅動的無服務工作流、定期執行的Job（例如資源清理、容量檢查、安全掃描）等。這些應用通常生命周期極短（可能在秒級或毫秒級），Pull的定期模型極難去監控，一般都需要使用Push的方式，由應用主動推送監控數據。

為了應對這種短生命周期的應用，純Pull的系統都會提供一個中間層（例如Prometheus的Push Gateway）：接受應用主動Push，再提供Pull的端口給監控系統。但這就需要額外多個中間層的管理和運維成本，而且由于是Pull模擬Push，上報的延遲會升高而且還需要即使清理這些立即消失的指標。

4 靈活性與耦合度

從靈活性上來講，Pull模式稍微有一些優勢，可以在Pull模塊配置到底想要哪些指標，對指標做一些簡單的計算/二次加工；但這個優勢也是相對的，Push SDK/Agent也可以去配置這些參數，借助于配置中心的存在，配置管理起來也是很簡單的。

從耦合度上講，Pull模型和后端的耦合度要低很多，只需要提供一個后端可以理解的接口即可，具體連接哪個后端，后端需要哪些指標等不用關心，相對分工比較明確，應用開發者只需要暴露應用自己的指標即可，由SRE（監控系統管理者）來獲取這些指標；Push模型相對來說耦合度要高一些，應用需要配置后端的地址以及鑒權信息等，但如果借助于本地的Push Agent，應用只需要Push本地地址，相對來說代價也并不大。

七 運維與成本對比

1 資源成本

從整體成本上講，兩種方式總體的差別不大，但從歸屬方角度來看：

Pull模式核心消耗在監控系統側，應用側的代價較低
Push模式核心消耗在推送和Push Agent端，監控系統側的消耗相比Pull要小很多

2 運維成本

從運維角度上講，相對而言Pull模式的代價要稍高，Pull模式需要運維的組件包括：各類Exporter、服務發現、PullAgent、監控后端；而Push模式只需要運維：Push Agent、監控后端、配置中心（可選，部署方式一般是和監控后端一起）。

這里需要注意的一點是，Pull模式由于是服務端向客戶端主動發起請求，網絡上需要考慮跨集群連通性、應用側的網絡防護ACL等，相比Push的網絡連通性比較簡單，只需要服務端提供一個可供各節點訪問的域名/VIP即可。

八 Pull or Push如何選型

目前開源方案，Pull模式的代表Prometheus的家族方案（之所以稱之為家族，主要是默認單點的Prometheus擴展性受限，社區有非常多Prometheus的分布式方案，比如Thanos、VictoriaMetrics、Cortex等），Push模式的代表InfluxDB的TICK（Telegraf, InfluxDB, Chronograf, Kapacitor）方案。這兩種方案都有各自的優缺點，在云原生的大背景下，隨著Prometheus在CNCF、Kubernetes帶領下的大火，很多開源軟件都開始提供Prometheus模式的Pull端口；但同時還有很多系統本身設計之初就難以提供Pull端口，這些系統的監控相比而言使用Push Agent方式更為合理。

而應用本身到底該使用Pull還是Push一直沒有一個很好的定論，具體的選型還需要根據公司內部的實際場景，例如如果公司集群的網絡很復雜，使用Push方式較為簡單；有很多短生命周期的應用，需要使用Push方式；移動端應用只能用Push方式；系統本身就用Consul做服務發現，只需要暴露Pull端口就可以很容易實施。

所以綜合考慮情況下對于公司內部的監控系統來說，應該同時具備Pull和Push的能力才是最優解：

主機、進程、中間件監控使用Push Agent；
Kubernetes等直接暴露Pull端口的使用Pull模式；
應用根據實際場景選擇Pull or Push；

九 SLS在Pull和Push上的策略

SLS目前支持日志（Log）、時序監控（Metric）、分布式鏈路追蹤（Trace）的統一存儲和分析。對于時序監控方案是兼容Prometheus的格式標準，提供的也是標準的PromQL語法。面對數十萬SLS的用戶，應用場景可能會千差萬別，不可能用單一的Pull或Push來對應所有客戶需求。因此SLS在Pull和Push的選型上SLS并沒有走單一路線，而是兼容Pull和Push模型。此外對于開源社區和Agent，SLS的策略是完全兼容開源生態，而非自己去造一個閉合生態：

Pull模型：完全兼容Prometheus的Pull Scrap能力?？梢允褂肞rometheus的Remote Write，讓Prometheus來做Pull的Agent；和Prometheus Scrap一樣能力的VMAgent也可以這樣使用；SLS自己的Agent Logtail也可以實現Prometheus的Scrap能力
Push模型：目前業界的監控PushAgent生態最完善的當屬Telegraf，SLS的Logtail內置了Telegraf，可以支持所有的Telegraf的上百種監控插件

相比VMAgent、Prometheus這類Pull Agent以及原生Telegraf，SLS額外提供了最迫切的Agent配置中心和Agent監控能力，可以在服務端去管理每個Agent的采集配置以及監控這些Agent的運行狀態，盡可能降低運維管理代價。

因此實際使用SLS進行監控方案的搭建會非常簡單：

在SLS的控制臺（Web頁面）去創建一個存儲監控數據的MetricStore；
部署Logtail的Agent（一行命令）；
在控制臺上配置監控數據的采集配置（Pull、Push都可以）；

十 總結

本文主要介紹了監控系統中最糾結的Pull or Push選擇問題，筆者結合數年的實際經驗以及遇到的各類客戶場景對Pull和Push的各類方向進行了比對，僅供大家在監控系統建設過程中參考，也歡迎大家留言和討論。