一(yī)： 形形色色的監控系統

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

1. 監控對象：通用型（通用的監控方式，适應于大部分(fēn)的監控對象），專一(yī)型（為(wèi)某一(yī)功能(néng)定制，例如(rú)Java的JMX系統、CPU的高溫保護、硬盤的斷電保護、UPS切換系統、交換機監控系統、專線監控等）；

2. 數據獲取方式：Push（CollectD、Zabbix、InfluxDB）；Pull（Prometheus、SNMP、JMX）；

3. 部署方式：耦合式（和被監控系統在一(yī)起部署）；單機（單機單實例部署）；分(fēn)布式（可以橫向擴展）；SaaS化(huà)（很多商(shāng)業的公司提供SaaS的方式，無需部署）；

4. 數據獲取方式：接口型（隻能(néng)通過某些(xiē)API拿去）；DSL（可以有一(yī)些(xiē)計算(suàn)，例如(rú)PromQL、GraphQL）；SQL（标準SQL、類SQL）；

5. 商(shāng)業屬性：開源免費（例如(rú)Prometheus、InfluxDB單機版）；開源商(shāng)業型（例如(rú)InfluxDB集群版、Elastic Search X-Pack）；閉源商(shāng)業型（例如(rú)DataDog、Splunk、AWS Cloud Watch）；

二 Pull or Push

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

基于Pull類型的監控系統顧名思義是由監控系統主動去獲取指标，需要被監控的對象能(néng)夠具備被遠(yuǎn)端訪問的能(néng)力；基于Push類型的監控系統不主動獲取數據，而是由安裝監控對象主動推送指标。兩種方式在非常多的地方都有區别，對于監控系統的建設和選型來(lái)說(shuō)，一(yī)定要事(shì)先了(le)解這(zhè)兩種方式各自的優劣，選擇合适的方案來(lái)實施，否則如(rú)果盲目實施，後續對監控系統的穩定性和部署運維代價來(lái)說(shuō)将是災難性的。

三 Pull vs Push概覽

下(xià)面将從幾個(gè)方面來(lái)展開介紹，為(wèi)了(le)節約讀者時(shí)間(jiān)，這(zhè)裏先用一(yī)個(gè)表格來(lái)做概要性的論述，細節在後面會展開：

四 原理(lǐ)與架構對比

如(rú)上(shàng)圖所示，Pull模型數據獲取的核心是Pull模塊，一(yī)般和監控的後端一(yī)起部署，例如(rú)Prometheus，核心組成包括：

1. 服務(wù)發現(xiàn)系統，包括主機的服務(wù)發現(xiàn)（一(yī)般依賴于公司内部自己的CMDB系統）、應用服務(wù)發現(xiàn)（例如(rú)Consul）、PaaS服務(wù)發現(xiàn)（例如(rú)Kubernetes）；Pull模塊需要具備對這(zhè)些(xiē)服務(wù)發現(xiàn)系統的對接能(néng)力

2. Pull核心模塊，除了(le)服務(wù)發現(xiàn)部分(fēn)外，一(yī)般使用通用協議(yì)去遠(yuǎn)端拉取數據，一(yī)般支持配置拉取間(jiān)隔、超時(shí)間(jiān)隔、指标過濾/Rename/簡單的Process能(néng)力

3. 應用側SDK，支持監聽(tīng)某個(gè)固定端口來(lái)提供被Pull的能(néng)力

4. 由于各類中間(jiān)件/其他系統不兼容Pull協議(yì)，因此需要開發對應的Exporter的Agent，支持拉取這(zhè)些(xiē)系統的指标并提供标準的Pull接口

Push模型相對比較簡單：

1. Push Agent，支持拉取各類被監控對象的指标數據，并推送到服務(wù)端，可以和被監控系統耦合部署，也(yě)可以單獨部署

2. ConfigCenter（可選），用來(lái)提供中心化(huà)的動态配置能(néng)力，例如(rú)監控目标、采集間(jiān)隔、指标過濾、指标處理(lǐ)、遠(yuǎn)端目标等

3. 應用側SDK，支持發送數據到監控後端，或者發送到本地Agent（通常是本地Agent也(yě)實現(xiàn)一(yī)套後端的接口）

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

五 Pull的分(fēn)布式解決方案

在擴展性上(shàng)，Push方式的數據采集天然就(jiù)是分(fēn)布式的，在監控後端能(néng)力可以跟上(shàng)的時(shí)候，可以無限的橫向擴展。相比之下(xià)Pull方式擴展較為(wèi)麻煩，需要：

1. Pull模塊與監控後端解耦，Pull作(zuò)為(wèi)Agent單獨部署

2. Pull Agent需要做分(fēn)布式的協同，一(yī)般最簡單是做Sharding，例如(rú)從服務(wù)發現(xiàn)系統處獲取被監控的機器(qì)列表，對這(zhè)些(xiē)機器(qì)進行Hash後取模Sharding來(lái)決定由哪個(gè)Agent來(lái)負責Pull。

3. 新(xīn)增一(yī)個(gè)配置中心（可選）用來(lái)管理(lǐ)各個(gè)PullAgent

相信反應快(kuài)的同學已經看出來(lái)，這(zhè)種分(fēn)布式的方式還是有一(yī)些(xiē)問題：

1. 單點瓶頸還是存在，所有的Agent都需要去請求服務(wù)發現(xiàn)模塊

2. Agent擴容後，監控目标會變化(huà)，容易産生(shēng)數據重複或缺失

六 監控能(néng)力對比

1 監控目标存活性

存活性是監控所需要做的第一(yī)件也(yě)是最基礎的工作(zuò)，Pull模式監控目标存活性相對來(lái)說(shuō)非常簡單，直接在Pull的中心端就(jiù)知道能(néng)否請求到目标端的指标，如(rú)果失敗也(yě)能(néng)知道一(yī)些(xiē)簡單的錯誤，比如(rú)網絡超時(shí)、對端拒絕連接等。

Push方式相對來(lái)說(shuō)就(jiù)比較麻煩，應用沒有上(shàng)報(bào)可能(néng)是應用挂了(le)，也(yě)可能(néng)是網絡問題，也(yě)可能(néng)是遷移到了(le)其他的節點上(shàng)了(le)，因為(wèi)Pull模塊可以和服務(wù)發現(xiàn)實時(shí)聯動，但(dàn)Push沒有，所以隻有服務(wù)端再和服務(wù)發現(xiàn)交互才能(néng)知道具體(tǐ)失敗的原因。

2 數據齊全度計算(suàn)

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

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

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

3 短生(shēng)命周期/Serverless應用監控

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

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

4 靈活性與耦合度

從靈活性上(shàng)來(lái)講，Pull模式稍微有一(yī)些(xiē)優勢，可以在Pull模塊配置到底想要哪些(xiē)指标，對指标做一(yī)些(xiē)簡單的計算(suàn)/二次加工；但(dàn)這(zhè)個(gè)優勢也(yě)是相對的，Push SDK/Agent也(yě)可以去配置這(zhè)些(xiē)參數，借助于配置中心的存在，配置管理(lǐ)起來(lái)也(yě)是很簡單的。

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

七 運維與成本對比

1 資源成本

從整體(tǐ)成本上(shàng)講，兩種方式總體(tǐ)的差别不大，但(dàn)從歸屬方角度來(lái)看：

1. Pull模式核心消耗在監控系統側，應用側的代價較低(dī)

2. Push模式核心消耗在推送和Push Agent端，監控系統側的消耗相比Pull要小很多

2 運維成本

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

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

八 Pull or Push如(rú)何選型

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

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

所以綜合考慮情況下(xià)對于公司内部的監控系統來(lái)說(shuō)，應該同時(shí)具備Pull和Push的能(néng)力才是最優解：

1. 主機、進程、中間(jiān)件監控使用Push Agent；

2. Kubernetes等直接暴露Pull端口的使用Pull模式；

3. 應用根據實際場(chǎng)景選擇Pull or Push；

九 SLS在Pull和Push上(shàng)的策略

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

1. Pull模型：完全兼容Prometheus的Pull Scrap能(néng)力。可以使用Prometheus的Remote Write，讓Prometheus來(lái)做Pull的Agent；和Prometheus Scrap一(yī)樣能(néng)力的VMAgent也(yě)可以這(zhè)樣使用；SLS自己的Agent Logtail也(yě)可以實現(xiàn)Prometheus的Scrap能(néng)力

2. Push模型：目前業界的監控PushAgent生(shēng)态最完善的當屬Telegraf，SLS的Logtail内置了(le)Telegraf，可以支持所有的Telegraf的上(shàng)百種監控插件

相比VMAgent、Prometheus這(zhè)類Pull Agent以及原生(shēng)Telegraf，SLS額外提供了(le)最迫切的Agent配置中心和Agent監控能(néng)力，可以在服務(wù)端去管理(lǐ)每個(gè)Agent的采集配置以及監控這(zhè)些(xiē)Agent的運行狀态，盡可能(néng)降低(dī)運維管理(lǐ)代價。

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

1. 在SLS的控制台（Web頁面）去創建一(yī)個(gè)存儲監控數據的MetricStore；

2. 部署Logtail的Agent（一(yī)行命令）；

3. 在控制台上(shàng)配置監控數據的采集配置（Pull、Push都可以）；