系統監控數據該用推還是拉？
系統度量數據的收集方式通常分為拉動式（Pull）和推動式（Push）。這兩種方式在數據采集和傳輸的過程中具有不同的特點和適用場景。
圖片
1.拉動式
拉動式是指數據收集系統定期向目標設備或系統發送請求，以獲取數據。這種方式的關鍵在于，數據收集方主動發起請求，目標系統被動響應。
圖 1 顯示了通過 HTTP 拉動模式收集數據的情況。我們有專門的指標收集器，定期從運行的應用程序中提取指標值。
在這種方法中，指標收集器（Metrics Collector）需要知道要從哪些服務端點獲取數據。一種簡單的方法是使用一個文件來保存 “指標收集器 ”服務器上每個服務端點的 DNS/IP 信息。雖然想法很簡單，但這種方法在大規模環境中很難維護，因為服務器會經常添加或移除，而且我們要確保度量收集器不會錯過從任何新服務器收集度量數據。
優點
- 控制靈活性：拉動式系統可以根據需求定期或按需請求數據，因此具有較高的控制靈活性。用戶可以指定數據采集的時間或條件。
- 減少不必要的數據傳輸：只有在請求時才會收集數據，這意味著如果沒有實際的需求或事件，數據不會被頻繁地傳輸，從而避免了不必要的網絡流量和存儲。
- 簡化處理：拉動式方式可以在數據請求時就進行數據處理，因此系統接收到的數據通常已被篩選或加工過。
缺點
- 延遲問題：因為數據是按需收集的，如果請求頻率較低，可能會存在一定的延遲，不能即時獲取最新的數據。
- 請求開銷：每次數據請求都需要一定的系統資源和時間，特別是在數據量較大的時候，頻繁請求可能會導致性能瓶頸。
- 系統負擔：當多個設備或系統都使用拉動方式時，服務器可能需要處理大量的請求，從而導致壓力增加。
我們可以通過 Kubernetes、Zookeeper 等提供的服務發現（Service Discovery）獲得可靠、可擴展和可維護的解決方案，其中服務會注冊其可用性，每當服務端點列表發生變化時，度量收集器就會收到服務發現組件的通知。服務發現包含有關何時何地收集度量的配置規則，如圖 2 所示。
2.推動式
推動式是指數據源主動向數據收集系統發送數據。數據生成方（如設備、系統）在事件發生或數據更新時，主動將數據推送到接收方。
第一步
指標收集器從服務發現獲取服務端點的配置元數據。元數據包括拉取間隔、IP 地址、超時和重試參數等。
第二步
指標收集器通過預定義的 HTTP 端點（例如 /metrics）獲取指標數據。要公開該端點，通常需要在服務中添加客戶端庫。在圖 3 中，服務是 Web 服務器。
第三步
另外，度量收集器還可以向服務發現（Service Discovery）注冊變更事件通知，以便在服務端點變更時接收更新。或者，度量收集器可以定期輪詢端點變化。
優點
- 實時性強：數據能夠在生成或變化的瞬間被推送到接收方，這種方式適合需要高實時性的數據場景，如監控系統或實時分析。
- 減少請求開銷：由于數據是被主動推送的，收集系統不需要周期性地發送請求，減少了系統間的通信開銷。
- 靈活的事件驅動：可以根據特定的事件或條件觸發數據推送，而不是基于時間，這使得數據采集更加精確和高效。
缺點
- 數據過載：如果推送過于頻繁，可能會導致數據過載，尤其是在高頻變化的場景下，接收方可能難以處理過多的數據。
- 管理復雜性：在推送式數據收集模式下，數據源需要管理發送的頻率和觸發條件，系統間需要保持較強的同步和協調，否則可能會發生數據丟失或重復傳輸。
- 網絡負擔：如果數據推送過于頻繁或數據量較大，可能會給網絡帶來負擔，尤其在網絡帶寬有限的情況下。
