系統(tǒng)度量數(shù)據(jù)的收集方式通常分為拉動(dòng)式（Pull）和推動(dòng)式（Push）。這兩種方式在數(shù)據(jù)采集和傳輸?shù)倪^程中具有不同的特點(diǎn)和適用場(chǎng)景。

圖片

1.拉動(dòng)式

拉動(dòng)式是指數(shù)據(jù)收集系統(tǒng)定期向目標(biāo)設(shè)備或系統(tǒng)發(fā)送請(qǐng)求，以獲取數(shù)據(jù)。這種方式的關(guān)鍵在于，數(shù)據(jù)收集方主動(dòng)發(fā)起請(qǐng)求，目標(biāo)系統(tǒng)被動(dòng)響應(yīng)。

圖 1 顯示了通過 HTTP 拉動(dòng)模式收集數(shù)據(jù)的情況。我們有專門的指標(biāo)收集器，定期從運(yùn)行的應(yīng)用程序中提取指標(biāo)值。

在這種方法中，指標(biāo)收集器（Metrics Collector）需要知道要從哪些服務(wù)端點(diǎn)獲取數(shù)據(jù)。一種簡(jiǎn)單的方法是使用一個(gè)文件來保存 “指標(biāo)收集器 ”服務(wù)器上每個(gè)服務(wù)端點(diǎn)的 DNS/IP 信息。雖然想法很簡(jiǎn)單，但這種方法在大規(guī)模環(huán)境中很難維護(hù)，因?yàn)榉?wù)器會(huì)經(jīng)常添加或移除，而且我們要確保度量收集器不會(huì)錯(cuò)過從任何新服務(wù)器收集度量數(shù)據(jù)。

優(yōu)點(diǎn)

• 控制靈活性：拉動(dòng)式系統(tǒng)可以根據(jù)需求定期或按需請(qǐng)求數(shù)據(jù)，因此具有較高的控制靈活性。用戶可以指定數(shù)據(jù)采集的時(shí)間或條件。
• 減少不必要的數(shù)據(jù)傳輸：只有在請(qǐng)求時(shí)才會(huì)收集數(shù)據(jù)，這意味著如果沒有實(shí)際的需求或事件，數(shù)據(jù)不會(huì)被頻繁地傳輸，從而避免了不必要的網(wǎng)絡(luò)流量和存儲(chǔ)。
• 簡(jiǎn)化處理：拉動(dòng)式方式可以在數(shù)據(jù)請(qǐng)求時(shí)就進(jìn)行數(shù)據(jù)處理，因此系統(tǒng)接收到的數(shù)據(jù)通常已被篩選或加工過。

缺點(diǎn)

• 延遲問題：因?yàn)閿?shù)據(jù)是按需收集的，如果請(qǐng)求頻率較低，可能會(huì)存在一定的延遲，不能即時(shí)獲取最新的數(shù)據(jù)。
• 請(qǐng)求開銷：每次數(shù)據(jù)請(qǐng)求都需要一定的系統(tǒng)資源和時(shí)間，特別是在數(shù)據(jù)量較大的時(shí)候，頻繁請(qǐng)求可能會(huì)導(dǎo)致性能瓶頸。
• 系統(tǒng)負(fù)擔(dān)：當(dāng)多個(gè)設(shè)備或系統(tǒng)都使用拉動(dòng)方式時(shí)，服務(wù)器可能需要處理大量的請(qǐng)求，從而導(dǎo)致壓力增加。

我們可以通過 Kubernetes、Zookeeper 等提供的服務(wù)發(fā)現(xiàn)（Service Discovery）獲得可靠、可擴(kuò)展和可維護(hù)的解決方案，其中服務(wù)會(huì)注冊(cè)其可用性，每當(dāng)服務(wù)端點(diǎn)列表發(fā)生變化時(shí)，度量收集器就會(huì)收到服務(wù)發(fā)現(xiàn)組件的通知。服務(wù)發(fā)現(xiàn)包含有關(guān)何時(shí)何地收集度量的配置規(guī)則，如圖 2 所示。

2.推動(dòng)式

推動(dòng)式是指數(shù)據(jù)源主動(dòng)向數(shù)據(jù)收集系統(tǒng)發(fā)送數(shù)據(jù)。數(shù)據(jù)生成方（如設(shè)備、系統(tǒng)）在事件發(fā)生或數(shù)據(jù)更新時(shí)，主動(dòng)將數(shù)據(jù)推送到接收方。

第一步

指標(biāo)收集器從服務(wù)發(fā)現(xiàn)獲取服務(wù)端點(diǎn)的配置元數(shù)據(jù)。元數(shù)據(jù)包括拉取間隔、IP 地址、超時(shí)和重試參數(shù)等。

第二步

指標(biāo)收集器通過預(yù)定義的 HTTP 端點(diǎn)（例如 /metrics）獲取指標(biāo)數(shù)據(jù)。要公開該端點(diǎn)，通常需要在服務(wù)中添加客戶端庫。在圖 3 中，服務(wù)是 Web 服務(wù)器。

第三步

另外，度量收集器還可以向服務(wù)發(fā)現(xiàn)（Service Discovery）注冊(cè)變更事件通知，以便在服務(wù)端點(diǎn)變更時(shí)接收更新?；蛘撸攘渴占骺梢远ㄆ谳喸兌它c(diǎn)變化。

優(yōu)點(diǎn)

• 實(shí)時(shí)性強(qiáng)：數(shù)據(jù)能夠在生成或變化的瞬間被推送到接收方，這種方式適合需要高實(shí)時(shí)性的數(shù)據(jù)場(chǎng)景，如監(jiān)控系統(tǒng)或?qū)崟r(shí)分析。
• 減少請(qǐng)求開銷：由于數(shù)據(jù)是被主動(dòng)推送的，收集系統(tǒng)不需要周期性地發(fā)送請(qǐng)求，減少了系統(tǒng)間的通信開銷。
• 靈活的事件驅(qū)動(dòng)：可以根據(jù)特定的事件或條件觸發(fā)數(shù)據(jù)推送，而不是基于時(shí)間，這使得數(shù)據(jù)采集更加精確和高效。

缺點(diǎn)

• 數(shù)據(jù)過載：如果推送過于頻繁，可能會(huì)導(dǎo)致數(shù)據(jù)過載，尤其是在高頻變化的場(chǎng)景下，接收方可能難以處理過多的數(shù)據(jù)。
• 管理復(fù)雜性：在推送式數(shù)據(jù)收集模式下，數(shù)據(jù)源需要管理發(fā)送的頻率和觸發(fā)條件，系統(tǒng)間需要保持較強(qiáng)的同步和協(xié)調(diào)，否則可能會(huì)發(fā)生數(shù)據(jù)丟失或重復(fù)傳輸。
• 網(wǎng)絡(luò)負(fù)擔(dān)：如果數(shù)據(jù)推送過于頻繁或數(shù)據(jù)量較大，可能會(huì)給網(wǎng)絡(luò)帶來負(fù)擔(dān)，尤其在網(wǎng)絡(luò)帶寬有限的情況下。