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

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

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

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

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

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

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

二 Pull or Push

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

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

三 Pull vs Push概覽

下(xià)面将從幾個方面來展開(kāi)介紹，為了節約讀者時間，這裡先用一(yī)個表格來做概要性的論述，細節在後面會展開(kāi)：

四 原理與架構對比

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

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

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

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

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

Push模型相對比較簡單：

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

2. ConfigCenter（可選），用來提供中(zhōng)心化的動态配置能力，例如監控目标、采集間隔、指标過濾、指标處理、遠端目标等

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

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

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

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

1. Pull模塊與監控後端解耦，Pull作為Agent單獨部署

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

3. 新增一(yī)個配置中(zhōng)心（可選）用來管理各個PullAgent

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

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

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

六 監控能力對比

1 監控目标存活性

存活性是監控所需要做的第一(yī)件也是最基礎的工(gōng)作，Pull模式監控目标存活性相對來說非常簡單，直接在Pull的中(zhōng)心端就知(zhī)道能否請求到目标端的指标，如果失敗也能知(zhī)道一(yī)些簡單的錯誤，比如網絡超時、對端拒絕連接等。

Push方式相對來說就比較麻煩，應用沒有上報可能是應用挂了，也可能是網絡問題，也可能是遷移到了其他的節點上了，因為Pull模塊可以和服務發現實時聯動，但Push沒有，所以隻有服務端再和服務發現交互才能知(zhī)道具體(tǐ)失敗的原因。

2 數據齊全度計算

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

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

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

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

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

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

4 靈活性與耦合度

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

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

七 運維與成本對比

1 資(zī)源成本

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

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

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

2 運維成本

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

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

八 Pull or Push如何選型

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

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

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

1. 主機、進程、中(zhōng)間件監控使用Push Agent；

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

3. 應用根據實際場景選擇Pull or Push；

九 SLS在Pull和Push上的策略

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

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

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

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

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

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

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

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