[[421126]]

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

監(jiān)控一直是IT系統(tǒng)中的核心組成部分，負(fù)責(zé)問(wèn)題的發(fā)現(xiàn)以及輔助性的定位。無(wú)論是傳統(tǒng)運(yùn)維、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)不下于上百種，按照不同類別也有非常多的劃分方式，例如：

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

二 Pull or Push

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

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

三 Pull vs Push概覽

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

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

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

服務(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模塊需要具備對(duì)這些服務(wù)發(fā)現(xiàn)系統(tǒng)的對(duì)接能力
Pull核心模塊，除了服務(wù)發(fā)現(xiàn)部分外，一般使用通用協(xié)議去遠(yuǎn)端拉取數(shù)據(jù)，一般支持配置拉取間隔、超時(shí)間隔、指標(biāo)過(guò)濾/Rename/簡(jiǎn)單的Process能力
應(yīng)用側(cè)SDK，支持監(jiān)聽某個(gè)固定端口來(lái)提供被Pull的能力
由于各類中間件/其他系統(tǒng)不兼容Pull協(xié)議，因此需要開發(fā)對(duì)應(yīng)的Exporter的Agent，支持拉取這些系統(tǒng)的指標(biāo)并提供標(biāo)準(zhǔn)的Pull接口
Push模型相對(duì)比較簡(jiǎn)單：

Push Agent，支持拉取各類被監(jiān)控對(duì)象的指標(biāo)數(shù)據(jù)，并推送到服務(wù)端，可以和被監(jiān)控系統(tǒng)耦合部署，也可以單獨(dú)部署
ConfigCenter（可選），用來(lái)提供中心化的動(dòng)態(tài)配置能力，例如監(jiān)控目標(biāo)、采集間隔、指標(biāo)過(guò)濾、指標(biāo)處理、遠(yuǎn)端目標(biāo)等
應(yīng)用側(cè)SDK，支持發(fā)送數(shù)據(jù)到監(jiān)控后端，或者發(fā)送到本地Agent（通常是本地Agent也實(shí)現(xiàn)一套后端的接口）
小結(jié)：純粹從部署復(fù)雜性上而言，在中間件/其他系統(tǒng)的監(jiān)控上，Pull模型的部署方式太過(guò)復(fù)雜，維護(hù)代價(jià)較高，使用Push模式較為便捷；應(yīng)用提供Metrics端口或主動(dòng)Push部署代價(jià)相差不大。

五 Pull的分布式解決方案

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

Pull模塊與監(jiān)控后端解耦，Pull作為Agent單獨(dú)部署
Pull Agent需要做分布式的協(xié)同，一般最簡(jiǎn)單是做Sharding，例如從服務(wù)發(fā)現(xiàn)系統(tǒng)處獲取被監(jiān)控的機(jī)器列表，對(duì)這些機(jī)器進(jìn)行Hash后取模Sharding來(lái)決定由哪個(gè)Agent來(lái)負(fù)責(zé)Pull。
新增一個(gè)配置中心（可選）用來(lái)管理各個(gè)PullAgent
相信反應(yīng)快的同學(xué)已經(jīng)看出來(lái)，這種分布式的方式還是有一些問(wèn)題：

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

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

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

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

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

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

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

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

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

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

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

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

4 靈活性與耦合度

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

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

七 運(yùn)維與成本對(duì)比

1 資源成本

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

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

2 運(yùn)維成本

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

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

八 Pull or Push如何選型

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

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

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

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

九 SLS在Pull和Push上的策略

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

Pull模型：完全兼容Prometheus的Pull Scrap能力。可以使用Prometheus的Remote Write，讓Prometheus來(lái)做Pull的Agent；和Prometheus Scrap一樣能力的VMAgent也可以這樣使用；SLS自己的Agent Logtail也可以實(shí)現(xiàn)Prometheus的Scrap能力
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ù)端去管理每個(gè)Agent的采集配置以及監(jiān)控這些Agent的運(yùn)行狀態(tài)，盡可能降低運(yùn)維管理代價(jià)。

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

在SLS的控制臺(tái)（Web頁(yè)面）去創(chuàng)建一個(gè)存儲(chǔ)監(jiān)控?cái)?shù)據(jù)的MetricStore；
部署Logtail的Agent（一行命令）；
在控制臺(tái)上配置監(jiān)控?cái)?shù)據(jù)的采集配置（Pull、Push都可以）；

十 總結(jié)

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