可觀測性代理在執行時可能會消耗大量資源。 為避免Agent占用過多資源導致不必要的額外成本，您可以監控Agent的資源使用情況，確保其資源消耗在合理範圍內。
從衡量可觀測性代理開銷到成本，按 bCameron Gain是Revecom Media的創始人兼首席分析師。 他對電腦的痴迷始於 80 年代初，當時他入侵了 Space Invaders 遊戲機，在當地的遊戲廳每天只玩 25 美分。 然後。 我們最近研究了如何將 OpenTelemetry Collector 用作監視遙測的篩選器。 它適用於多個應用程式或微服務，尤其是出於安全原因。 因此，OpenTelemetry Collector 屬於可觀測性代理的範疇。 可觀測性代理（如 OpenTelemetry Collector）包括 Fluent bit、vector 等。 可觀測性代理在可觀測性的工作機制中起著關鍵作用。 它們處理資料傳輸，以確保準確傳輸遙測資料。 代理通常提供資料收集、資料處理和資料傳輸，並在監視系統效能方面發揮關鍵作用。 它們有助於識別未知問題，以便在效能問題發生之前對其進行故障排除和緩解。 這是可觀測性功能的標準。 這樣，當用於資料收集時，可觀測性代理會收集從乙個或多個源傳送給它的資料。 除了接收資料外，它還將資料傳送到端點，例如 grafana 面板的視覺化效果。 有了它，您可以配置某些型別的日誌、跟蹤和指標的集合，以實現可觀測性。 最初，如果已部署將遙測資料直接傳送到可觀測性平台的檢測應用程式，則可以選擇不使用可觀測性代理。 收集器在監視無法檢測到的應用程式時非常有用。 由於這也是乙個非常常見的用例，因此在監控無法檢測到的應用程式時，收集器也很有用，谷歌軟體開發人員Braydon Kains告訴The New Stack。
Google Cloud 在可觀測性日@ragecage64@kubecon @cloudnativefdn @nybooks可觀測性代理圖片twitter.com/wgacudsxxf如果沒有可觀測性收集器功能，則需要為這些功能單獨配置每個後端或使用者監控，這可能會很麻煩。 相反，可觀測性收集器充當所有微服務的單個端點，通過收集器促進的統一點簡化對應用程式和微服務的訪問。 使用 Observability Agent 作為收集器，您可以集中檢視和管理微服務，從而在 Grafana 等平台上提供統一的檢視。 雖然 Grafana 提供了某些不使用 OpenTelemetry 收集器的替代方法，但收集器大大簡化了此過程。 但是，可觀測性代理可能會消耗大量資源。 為了解決這個問題，它們本身也可以或正在被監控，以確保它們不會過度消耗資源，從而避免不必要的成本。 換句話說，OpenTelemetry Collector、Fluent Bit、Vector 等都表現出了強大的魯棒性和執行各種任務的能力，同時實現了卓越的結果，但它們的相對效能可能有所不同。bc gain (@bcamerongain) november 6， 2023
大多數最流行的代理都有 Kubernetes 過濾器和處理器，它們從 Kubernetes API 獲取元資料以豐富日誌和資料。 正如 Google 軟體開發人員 Braydon Kains 在他自己的 KubeCon + CloudNativeCon 演講中所說的那樣，“開銷有多大：如何評估可觀測性代理效能”，除了 OpenTelemetry，Fluent Bits 和 Vectors 也越來越受歡迎。 “如果可用的預設值不能滿足您的需求，每個代理也有辦法構建自定義處理，”凱恩斯在會後告訴 The New Stack。 “這樣做的最大挑戰是，在每秒處理數 TB 資料的管道上執行任何操作都會對您的開銷產生倍增效應。 特別是對於正規表示式日誌或 JSON 日誌解析，其影響可能會迅速增長，“Kains 說。 “如果你不能足夠快地傳送資料，我強烈建議增加工作執行緒的數量，或者盡可能利用代理的執行緒實現。 根據 Kains 的說法，匯出是管道中唯一可以輕鬆並行化的步驟。 大多數後端可以處理稍微無序的時間戳，例如，Fluent Bit 提供的一項功能是設定 8 個工作執行緒，以建立乙個包含 8 個工作執行緒的執行緒池，這些執行緒池同時傳送資料。 Kains 說，這可以通過將資料排程到執行緒池並讓其中乙個工作執行緒處理較慢的部分來顯著提高管道的效率，以防預設程序執行不足。 Kains 說，組織通常需要獨立確定哪個代理最適合他們以及預期的開銷。 “做到這一點的唯一方法是嘗試執行它。 如果可以複製生產環境，請安裝代理，對其進行配置並監控指標，“凱恩斯說。 “這是獲得答案的最佳方式。 ”
如果複製生產環境具有挑戰性，Kains 建議考慮使用日誌生成器或抓取測試工作負載，例如 Prometheus。 AWS 的 Logbench 是用於測試日誌管道的良好日誌生成器。 對於 prometheus 抓取，請設定乙個帶有文字抓取副本的模擬伺服器。 “如果您期望使用高基數方案，尤其是對於資料庫指標，請強制使用高基數方案來對代理的效能進行壓力測試。 如果對評估結果不滿意，請考慮減少工作或解除安裝工作以減少資源使用。 聚合節點和後端處理還可以幫助管理資源使用情況，“Kains 說。 “如果您遇到不可接受的效能或發現回歸，請向維護人員提出問題，並提供複製問題的詳細資訊和相關的效能資料，例如圖表、CSV、Linux 效能報告或 pprof 配置檔案。 “Kains 在 Google 的團隊使用 Google Cloud Operations，它合併了兩個代理，使用 Fluent Bit 進行日誌收集，使用 OpenTelemetry 進行指標和跟蹤。 在後台，該團隊維護乙個配置層，用於為 OpenTelemetry 和 Fluent Bit 生成配置。 這些配置主要針對虛擬機器（如普通虛擬機器）上的使用者進行優化，並使用 OpenTelemetry 確保高效的指標收集。
Kains 說，前段時間，我們有興趣看看 OpenTelemetry 日誌是否可以用作 Ops 代理而不是 Fluent Bits。 “這將使我們能夠在OpenTelemetry Collector上完全統一，”Kains說。 “當時，OpenTelemetry 日誌還不夠成熟，無法處理 Fluent Bit 的吞吐量和記憶體使用，因此我們選擇不繼續前進，”Kains 說。 “我們還沒有更新這些基準，所以很難說今天的情況會怎樣。 ”
但是，對於大多數普通使用者來說，依靠 Google 基礎架構對代理進行基準測試將非常昂貴且對終端使用者來說過於複雜。 “我運營的基準社群無法複製，”凱恩斯說。 “這是我打算在新的一年裡承諾的事情，修改我們的基準測試和效能評估策略和技術，使它們是開源的，不依賴於任何谷歌的專業知識或基礎設施。 但是，使用 AWS Log Bench 甚至 Kains 團隊建立的指令碼，可以手動為代理生成日誌負載，並直接通過 VM 上的工具（如 HTOP）觀察和比較指標，並使用可以從 PROC 或類似內容收集資訊的指令碼收集指標，Kains 說。 “我想建立可以開源的指南或工具，使這種基準測試更容易被技術水平較低的使用者使用，”凱恩斯說。 “我還沒有確切的計畫，但我希望在未來幾個月內有更多的話要說。 ”