科技改變生活 · 科技引領未來
科技改變生活 · 科技引領未來
一形形色色的監控系統監控一直是IT系統中的核心組成部分，負責問題的發現以及輔助性的定位。無論是傳統運維、SRE、DevOps、開發者都需要關注監控系統并參與到監控系統的建設和優化。從最開始大型機的作業系統、Linux基礎指標，監控系統就已經
一 形形色色的監控系統
監控一直是IT系統中的核心組成部分，負責問題的發現以及輔助性的定位。無論是傳統運維、SRE、DevOps、開發者都需要關注監控系統并參與到監控系統的建設和優化。從最開始大型機的作業系統、Linux基礎指標，監控系統就已經開始出現并逐漸演進，現階段能夠搜索到的監控系統不下于上百種，按照不同類別也有非常多的劃分方式，例如：
二 Pull or Push
對于建設一套公司內部使用的監控系統平臺，相對來說可選的方案還是非常多的，無論是用開源方案自建還是使用商業的SaaS化產品，都有比較多的可選項。但無論是開源方案還是商業的SaaS產品，真正實施起來都需要考慮如何將數據給到監控平臺，或者說監控平臺如何獲取到這些數據。這里就涉及到數據獲取方式的選型：Pull（拉）還是Push（推）模式？
基于Pull類型的監控系統顧名思義是由監控系統主動去獲取指標，需要被監控的對象能夠具備被遠端訪問的能力；基于Push類型的監控系統不主動獲取數據，而是由監控對象主動推送指標。兩種方式在非常多的地方都有區別，對于監控系統的建設和選型來說，一定要事先了解這兩種方式各自的優劣，選擇合適的方案來實施，否則如果盲目實施，后續對監控系統的穩定性和部署運維代價來說將是災難性的。
三 Pull vs Push概覽
下面將從幾個方面來展開介紹，為了節約讀者時間，這里先用一個表格來做概要性的論述，細節在后面會展開：
四 原理與架構對比
如上圖所示，Pull模型數據獲取的核心是Pull模塊，一般和監控的后端一起部署，例如Prometheus，核心組成包括：
Push模型相對比較簡單：
小結：純粹從部署復雜性上而言，在中間件/其他系統的監控上，Pull模型的部署方式太過復雜，維護代價較高，使用Push模式較為便捷；應用提供Metrics端口或主動Push部署代價相差不大。
五 Pull的分布式解決方案
在擴展性上，Push方式的數據采集天然就是分布式的，在監控后端能力可以跟上的時候，可以無限的橫向擴展。相比之下Pull方式擴展較為麻煩，需要：
相信反應快的同學已經看出來，這種分布式的方式還是有一些問題：
六 監控能力對比
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 資源成本
從整體成本上講，兩種方式總體的差別不大，但從歸屬方角度來看：
2 運維成本
從運維角度上講，相對而言Pull模式的代價要稍高，Pull模式需要運維的組件包括：各類Exporter、服務發現、PullAgent、監控后端；而Push模式只需要運維：Push Agent、監控后端、配置中心（可選，部署方式一般是和監控后端一起）。
八 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的能力才是最優解：
九 SLS在Pull和Push上的策略
SLS目前支持日志（Log）、時序監控（Metric）、分布式鏈路追蹤（Trace）的統一存儲和分析。對于時序監控方案是兼容Prometheus的格式標準，提供的也是標準的PromQL語法。面對數十萬SLS的用戶，應用場景可能會千差萬別，不可能用單一的Pull或Push來對應所有客戶需求。因此SLS在Pull和Push的選型上SLS并沒有走單一路線，而是兼容Pull和Push模型。此外對于開源社區和Agent，SLS的策略是完全兼容開源生態，而非自己去造一個閉合生態：
相比VMAgent、Prometheus這類Pull Agent以及原生Telegraf，SLS額外提供了最迫切的Agent配置中心和Agent監控能力，可以在服務端去管理每個Agent的采集配置以及監控這些Agent的運行狀態，盡可能降低運維管理代價。
因此實際使用SLS進行監控方案的搭建會非常簡單：
十 總結
本文主要介紹了監控系統中最糾結的Pull or Push選擇問題，筆者結合數年的實際經驗以及遇到的各類客戶場景對Pull和Push的各類方向進行了比對，僅供大家在監控系統建設過程中參考，也歡迎大家留言和討論。
作者 | 元乙
原文鏈接：http://click.aliyun.com/m/1000292537/
本文為阿里云原創內容，未經允許不得轉載。
高悅林