科技改變生活 · 科技引領(lǐng)未來
科技改變生活 · 科技引領(lǐng)未來
一形形色色的監(jiān)控系統(tǒng)監(jiān)控一直是IT系統(tǒng)中的核心組成部分，負(fù)責(zé)問題的發(fā)現(xiàn)以及輔助性的定位。無論是傳統(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)
一 形形色色的監(jiān)控系統(tǒng)
監(jiān)控一直是IT系統(tǒng)中的核心組成部分，負(fù)責(zé)問題的發(fā)現(xiàn)以及輔助性的定位。無論是傳統(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)不下于上百種，按照不同類別也有非常多的劃分方式，例如：
二 Pull or Push
對(duì)于建設(shè)一套公司內(nèi)部使用的監(jiān)控系統(tǒng)平臺(tái)，相對(duì)來說可選的方案還是非常多的，無論是用開源方案自建還是使用商業(yè)的SaaS化產(chǎn)品，都有比較多的可選項(xiàng)。但無論是開源方案還是商業(yè)的SaaS產(chǎn)品，真正實(shí)施起來都需要考慮如何將數(shù)據(jù)給到監(jiān)控平臺(tái)，或者說監(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)端訪問的能力；基于Push類型的監(jiān)控系統(tǒng)不主動(dòng)獲取數(shù)據(jù)，而是由監(jiān)控對(duì)象主動(dòng)推送指標(biāo)。兩種方式在非常多的地方都有區(qū)別，對(duì)于監(jiān)控系統(tǒng)的建設(shè)和選型來說，一定要事先了解這兩種方式各自的優(yōu)劣，選擇合適的方案來實(shí)施，否則如果盲目實(shí)施，后續(xù)對(duì)監(jiān)控系統(tǒng)的穩(wěn)定性和部署運(yùn)維代價(jià)來說將是災(zāi)難性的。
三 Pull vs Push概覽
下面將從幾個(gè)方面來展開介紹，為了節(jié)約讀者時(shí)間，這里先用一個(gè)表格來做概要性的論述，細(xì)節(jié)在后面會(huì)展開：
四 原理與架構(gòu)對(duì)比
如上圖所示，Pull模型數(shù)據(jù)獲取的核心是Pull模塊，一般和監(jiān)控的后端一起部署，例如Prometheus，核心組成包括：
Push模型相對(duì)比較簡(jiǎn)單：
小結(jié)：純粹從部署復(fù)雜性上而言，在中間件/其他系統(tǒng)的監(jiān)控上，Pull模型的部署方式太過復(fù)雜，維護(hù)代價(jià)較高，使用Push模式較為便捷；應(yīng)用提供Metrics端口或主動(dòng)Push部署代價(jià)相差不大。
五 Pull的分布式解決方案
在擴(kuò)展性上，Push方式的數(shù)據(jù)采集天然就是分布式的，在監(jiān)控后端能力可以跟上的時(shí)候，可以無限的橫向擴(kuò)展。相比之下Pull方式擴(kuò)展較為麻煩，需要：
相信反應(yīng)快的同學(xué)已經(jīng)看出來，這種分布式的方式還是有一些問題：
六 監(jiān)控能力對(duì)比
1 監(jiān)控目標(biāo)存活性
存活性是監(jiān)控所需要做的第一件也是最基礎(chǔ)的工作，Pull模式監(jiān)控目標(biāo)存活性相對(duì)來說非常簡(jiǎn)單，直接在Pull的中心端就知道能否請(qǐng)求到目標(biāo)端的指標(biāo)，如果失敗也能知道一些簡(jiǎn)單的錯(cuò)誤，比如網(wǎng)絡(luò)超時(shí)、對(duì)端拒絕連接等。
Push方式相對(duì)來說就比較麻煩，應(yīng)用沒有上報(bào)可能是應(yīng)用掛了，也可能是網(wǎng)絡(luò)問題，也可能是遷移到了其他的節(jié)點(diǎn)上了，因?yàn)镻ull模塊可以和服務(wù)發(fā)現(xiàn)實(shí)時(shí)聯(lián)動(dòng)，但Push沒有，所以只有服務(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)行疊加，如果沒有數(shù)據(jù)齊全度的概念，若配置QPS相比降低2%告警，由于網(wǎng)絡(luò)波動(dòng)，超過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ù)應(yīng)用等，例如渲染型的任務(wù)到達(dá)后啟動(dòng)一個(gè)彈性的計(jì)算實(shí)例，執(zhí)行完畢后立馬銷毀釋放；機(jī)器學(xué)習(xí)的訓(xùn)練Job、事件驅(qū)動(dòng)的無服務(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 靈活性與耦合度
從靈活性上來講，Pull模式稍微有一些優(yōu)勢(shì)，可以在Pull模塊配置到底想要哪些指標(biāo)，對(duì)指標(biāo)做一些簡(jiǎn)單的計(jì)算/二次加工；但這個(gè)優(yōu)勢(shì)也是相對(duì)的，Push SDK/Agent也可以去配置這些參數(shù)，借助于配置中心的存在，配置管理起來也是很簡(jiǎn)單的。
從耦合度上講，Pull模型和后端的耦合度要低很多，只需要提供一個(gè)后端可以理解的接口即可，具體連接哪個(gè)后端，后端需要哪些指標(biāo)等不用關(guān)心，相對(duì)分工比較明確，應(yīng)用開發(fā)者只需要暴露應(yīng)用自己的指標(biāo)即可，由SRE（監(jiān)控系統(tǒng)管理者）來獲取這些指標(biāo)；Push模型相對(duì)來說耦合度要高一些，應(yīng)用需要配置后端的地址以及鑒權(quán)信息等，但如果借助于本地的Push Agent，應(yīng)用只需要Push本地地址，相對(duì)來說代價(jià)也并不大。
七 運(yùn)維與成本對(duì)比
1 資源成本
從整體成本上講，兩種方式總體的差別不大，但從歸屬方角度來看：
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)控后端一起）。
八 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一直沒有一個(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)來說，應(yīng)該同時(shí)具備Pull和Push的能力才是最優(yōu)解：
九 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來對(duì)應(yīng)所有客戶需求。因此SLS在Pull和Push的選型上SLS并沒有走單一路線，而是兼容Pull和Push模型。此外對(duì)于開源社區(qū)和Agent，SLS的策略是完全兼容開源生態(tài)，而非自己去造一個(gè)閉合生態(tài)：
相比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)單：
十 總結(jié)
本文主要介紹了監(jiān)控系統(tǒng)中最糾結(jié)的Pull or Push選擇問題，筆者結(jié)合數(shù)年的實(shí)際經(jīng)驗(yàn)以及遇到的各類客戶場(chǎng)景對(duì)Pull和Push的各類方向進(jìn)行了比對(duì)，僅供大家在監(jiān)控系統(tǒng)建設(shè)過程中參考，也歡迎大家留言和討論。
作者 | 元乙
原文鏈接：http://click.aliyun.com/m/1000292537/
本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。
高悅林