監(jiān)控器一套多少錢（Pull）

一形形色色的監(jiān)控系統(tǒng)監(jiān)控一直是IT系統(tǒng)中的核心組成部分，負(fù)責(zé)問題的發(fā)現(xiàn)以及輔助性的定位。無論是傳統(tǒng)運維、SRE、DevOps、開發(fā)者都需要關(guān)注監(jiān)控系統(tǒng)并參與到監(jiān)控系統(tǒng)的建設(shè)和優(yōu)化。從最開始大型機(jī)的作業(yè)系統(tǒng)、Linux基礎(chǔ)指標(biāo)，監(jiān)控系統(tǒng)就已經(jīng)

一 形形色色的監(jiān)控系統(tǒng)

監(jiān)控一直是IT系統(tǒng)中的核心組成部分，負(fù)責(zé)問題的發(fā)現(xiàn)以及輔助性的定位。無論是傳統(tǒng)運維、SRE、DevOps、開發(fā)者都需要關(guān)注監(jiān)控系統(tǒng)并參與到監(jiān)控系統(tǒng)的建設(shè)和優(yōu)化。從最開始大型機(jī)的作業(yè)系統(tǒng)、Linux基礎(chǔ)指標(biāo)，監(jiān)控系統(tǒng)就已經(jīng)開始出現(xiàn)并逐漸演進(jìn)，現(xiàn)階段能夠搜索到的監(jiān)控系統(tǒng)不下于上百種，按照不同類別也有非常多的劃分方式，例如：

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

二 Pull or Push

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

基于Pull類型的監(jiān)控系統(tǒng)顧名思義是由監(jiān)控系統(tǒng)主動去獲取指標(biāo)，需要被監(jiān)控的對象能夠具備被遠(yuǎn)端訪問的能力；基于Push類型的監(jiān)控系統(tǒng)不主動獲取數(shù)據(jù)，而是由監(jiān)控對象主動推送指標(biāo)。兩種方式在非常多的地方都有區(qū)別，對于監(jiān)控系統(tǒng)的建設(shè)和選型來說，一定要事先了解這兩種方式各自的優(yōu)劣，選擇合適的方案來實施，否則如果盲目實施，后續(xù)對監(jiān)控系統(tǒng)的穩(wěn)定性和部署運維代價來說將是災(zāi)難性的。

三 Pull vs Push概覽

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

四 原理與架構(gòu)對比

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

1. 服務(wù)發(fā)現(xiàn)系統(tǒng)，包括主機(jī)的服務(wù)發(fā)現(xiàn)（一般依賴于公司內(nèi)部自己的CMDB系統(tǒng)）、應(yīng)用服務(wù)發(fā)現(xiàn)（例如Consul）、PaaS服務(wù)發(fā)現(xiàn)（例如Kubernetes）；Pull模塊需要具備對這些服務(wù)發(fā)現(xiàn)系統(tǒng)的對接能力
2. Pull核心模塊，除了服務(wù)發(fā)現(xiàn)部分外，一般使用通用協(xié)議去遠(yuǎn)端拉取數(shù)據(jù)，一般支持配置拉取間隔、超時間隔、指標(biāo)過濾/Rename/簡單的Process能力
3. 應(yīng)用側(cè)SDK，支持監(jiān)聽某個固定端口來提供被Pull的能力
4. 由于各類中間件/其他系統(tǒng)不兼容Pull協(xié)議，因此需要開發(fā)對應(yīng)的Exporter的Agent，支持拉取這些系統(tǒng)的指標(biāo)并提供標(biāo)準(zhǔn)的Pull接口

Push模型相對比較簡單：

1. Push Agent，支持拉取各類被監(jiān)控對象的指標(biāo)數(shù)據(jù)，并推送到服務(wù)端，可以和被監(jiān)控系統(tǒng)耦合部署，也可以單獨部署
2. ConfigCenter（可選），用來提供中心化的動態(tài)配置能力，例如監(jiān)控目標(biāo)、采集間隔、指標(biāo)過濾、指標(biāo)處理、遠(yuǎn)端目標(biāo)等
3. 應(yīng)用側(cè)SDK，支持發(fā)送數(shù)據(jù)到監(jiān)控后端，或者發(fā)送到本地Agent（通常是本地Agent也實現(xiàn)一套后端的接口）

小結(jié)：純粹從部署復(fù)雜性上而言，在中間件/其他系統(tǒng)的監(jiān)控上，Pull模型的部署方式太過復(fù)雜，維護(hù)代價較高，使用Push模式較為便捷；應(yīng)用提供Metrics端口或主動Push部署代價相差不大。

五 Pull的分布式解決方案

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

1. Pull模塊與監(jiān)控后端解耦，Pull作為Agent單獨部署
2. Pull Agent需要做分布式的協(xié)同，一般最簡單是做Sharding，例如從服務(wù)發(fā)現(xiàn)系統(tǒng)處獲取被監(jiān)控的機(jī)器列表，對這些機(jī)器進(jìn)行Hash后取模Sharding來決定由哪個Agent來負(fù)責(zé)Pull。
3. 新增一個配置中心（可選）用來管理各個PullAgent

相信反應(yīng)快的同學(xué)已經(jīng)看出來，這種分布式的方式還是有一些問題：

1. 單點瓶頸還是存在，所有的Agent都需要去請求服務(wù)發(fā)現(xiàn)模塊
2. Agent擴(kuò)容后，監(jiān)控目標(biāo)會變化，容易產(chǎn)生數(shù)據(jù)重復(fù)或缺失

六 監(jiān)控能力對比

1 監(jiān)控目標(biāo)存活性

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

Push方式相對來說就比較麻煩，應(yīng)用沒有上報可能是應(yīng)用掛了，也可能是網(wǎng)絡(luò)問題，也可能是遷移到了其他的節(jié)點上了，因為Pull模塊可以和服務(wù)發(fā)現(xiàn)實時聯(lián)動，但Push沒有，所以只有服務(wù)端再和服務(wù)發(fā)現(xiàn)交互才能知道具體失敗的原因。

2 數(shù)據(jù)齊全度計算

數(shù)據(jù)齊全度這個概念在大型的監(jiān)控系統(tǒng)中還是非常重要的，比如監(jiān)控一千個副本的交易應(yīng)用的QPS，這個指標(biāo)需要結(jié)合一千個數(shù)據(jù)進(jìn)行疊加，如果沒有數(shù)據(jù)齊全度的概念，若配置QPS相比降低2%告警，由于網(wǎng)絡(luò)波動，超過20個副本上報的數(shù)據(jù)延遲幾秒，那就會觸發(fā)誤報。因此在配置告警的時候還需要結(jié)合數(shù)據(jù)齊全度數(shù)據(jù)進(jìn)行綜合考慮。

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

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

3 短生命周期/Serverless應(yīng)用監(jiān)控

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

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

4 靈活性與耦合度

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

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

七 運維與成本對比

1 資源成本

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

1. Pull模式核心消耗在監(jiān)控系統(tǒng)側(cè)，應(yīng)用側(cè)的代價較低
2. Push模式核心消耗在推送和Push Agent端，監(jiān)控系統(tǒng)側(cè)的消耗相比Pull要小很多

2 運維成本

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

• 這里需要注意的一點是，Pull模式由于是服務(wù)端向客戶端主動發(fā)起請求，網(wǎng)絡(luò)上需要考慮跨集群連通性、應(yīng)用側(cè)的網(wǎng)絡(luò)防護(hù)ACL等，相比Push的網(wǎng)絡(luò)連通性比較簡單，只需要服務(wù)端提供一個可供各節(jié)點訪問的域名/VIP即可。

八 Pull or Push如何選型

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

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

所以綜合考慮情況下對于公司內(nèi)部的監(jiān)控系統(tǒng)來說，應(yīng)該同時具備Pull和Push的能力才是最優(yōu)解：

1. 主機(jī)、進(jìn)程、中間件監(jiān)控使用Push Agent；
2. Kubernetes等直接暴露Pull端口的使用Pull模式；
3. 應(yīng)用根據(jù)實際場景選擇Pull or Push；

九 SLS在Pull和Push上的策略

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

1. Pull模型：完全兼容Prometheus的Pull Scrap能力。可以使用Prometheus的Remote Write，讓Prometheus來做Pull的Agent；和Prometheus Scrap一樣能力的VMAgent也可以這樣使用；SLS自己的Agent Logtail也可以實現(xiàn)Prometheus的Scrap能力
2. Push模型：目前業(yè)界的監(jiān)控PushAgent生態(tài)最完善的當(dāng)屬Telegraf，SLS的Logtail內(nèi)置了Telegraf，可以支持所有的Telegraf的上百種監(jiān)控插件

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

因此實際使用SLS進(jìn)行監(jiān)控方案的搭建會非常簡單：

1. 在SLS的控制臺（Web頁面）去創(chuàng)建一個存儲監(jiān)控數(shù)據(jù)的MetricStore；
2. 部署Logtail的Agent（一行命令）；
3. 在控制臺上配置監(jiān)控數(shù)據(jù)的采集配置（Pull、Push都可以）；

十 總結(jié)

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

作者 | 元乙

原文鏈接：http://click.aliyun.com/m/1000292537/

本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。