KubeCon+CloudNativeCon 2023 的兩場演講展示了可觀測性領域的各種工具和服務。
翻譯自 How The OpenTelemetry Collector Scales Observability，作者：BCameron Gain是Revecom Media的創始人兼首席分析師。 他對電腦的痴迷始於 80 年代初，當時他入侵了當地一家街機廳的《太空入侵者》遊戲機，並以 25 美分的價格整天玩遊戲。 然後。 你可以不使用 OpenTelemetry Collector（乙個開源可觀測性框架），但你可能不想這樣做，尤其是在部署和監視大型應用程式時。 你可能想要使用 OpenTelemetry Collector，尤其是在你有多個應用程式或微服務的情況下，尤其是出於安全原因。
隨著 OpenTelemetry 範圍的擴大，並被廣泛接受為使用您最喜歡的可觀察統一介面或元件的一種方式，隨著供應商尋求滿足 OpenTelemetry 標準，這一點變得顯而易見。
OpenTelemetry Collector 是乙個可觀測性管道中介軟體，可大規模引入、處理和匯出資料。 Dynatrace 的高階軟體工程師 Evan Bradley 接受了 Honeycomb 的採訪。 在上個月的 KubeCon + CloudnativeCon 上IO 的高階軟體工程師兼開源專家 Tyler Helmuth 在題為“Ottl Me Why Transforming Telemetry in the OpenTelemetry Collector”的演講中解釋了這一點。 “那麼，為什麼要使用 Collector 呢？嗯，有很多原因，但第乙個重要原因是你可以在邊緣處理——邊緣處理允許你在多台機器上分配這項工作，這有助於提高管道中的資料吞吐量，“布拉德利說。 “您可以在邊緣或管道中的其他任何位置執行 Collector，因為它可以部署在任何地方、容器化、虛擬化，甚至作為服務。 此外，還可以在源附近或遠處處理資料，例如在管道中的關鍵點，例如在安全網路邊界的入口點。 ”
Bradley 說，由於 Collector 速度快且用途廣泛，因此它的設計可以很好地適應不同的用例。 “它在設計時考慮了高吞吐量和低延遲，因此不會減慢您的管道速度。 此外，它還具有較低的 CPU、記憶體和磁碟空間要求，“Bradley 說。
OpenTelemetry Collector 用於收集從乙個或多個源傳送給它的資料。 除了接收資料外，它還將資料傳送到端點，例如使用 grafana 面板進行視覺化。
通過配置，它可用於收集特定型別的日誌、跟蹤和指標，以實現可觀測性。
最初，您可以選擇不使用它，尤其是在使用監視應用程式時，該應用程式收集所有資料並將其直接傳輸到可觀測性平台，或者通過 OpenTelemetry 收集指標、日誌、跟蹤等。
但是，在監視多個應用程式或微服務時，這種方法變得具有挑戰性。 如果沒有 OpenTelemetry Collector，則需要為每個後端或使用者監視單獨配置它，這可能很麻煩。
相反，OpenTelemetry Collector 充當所有微服務的單個端點，通過 Collector 提供的統一點簡化對應用程式和微服務的訪問。
使用此收集器，您可以集中檢視和管理它們，從而在 Grafana 等平台上提供統一的檢視。 雖然 Grafana 提供了一些沒有 OpenTelemetry Collector 的替代方案，但 Collector 大大簡化了該過程。
Bradley 說，根據具體情況，可以通過選擇您需要的元件來定製除塵器以適應這種情況。 在現有選項不可用的情況下，所有 Collector 元件都使用相同的核心 API 編寫，允許您使用這些元件新增自己的 ** 來完成任務，“Bradley 說。
Bradley說，資料通過Collector的管道進行組織，由單獨的元件組成，每個元件處理乙個特定的任務。 Collector 有五類元件，但在他的演示中，涵蓋了接收器、處理器和匯出器。 Bradley說，上圖顯示了乙個示例管道，該管道從左側的某個點進入收集器，在右側通過管道傳輸並發射。
通過 OpenTelemetry 轉換語言 （OTTL），OpenTelemetry Collector 的篩選器或處理程式可用於篩選它接收和傳送的遙測資料的種類。 Helmuth 展示了 OTTL 如何支援過濾。 在他的演講中，Helmuth展示了何時通過刪除被歸類為已完成的事件來降低攝入量是有意義的，因為它們被認為是不必要的，他說。
在上圖中，目的是通過過濾處理器（在 OTTL 條件下執行）實現有關丟棄哪些資料的決策。 這些條件與基礎遙測資料互動，而不對其進行更改。 過濾處理器使用 OTTL 條件來選擇要丟棄的資料Helmuth說，當滿足條件時，處理器會刪除資料。
對於 Kubernetes 物件接收器，它以日誌的形式發出 Kubernetes 事件，這些事件存在於日誌正文的巢狀對映中。
helmuth 描述說，任何未按預期結構排列的主體（即那些與 k8s 事件不相似的主體）都將被丟棄。 在上圖的頂部框中，正文是包含物件鍵內聯對映的對映，因此不滿足條件並保留資料。 相反，在上圖的第二個框中，主體是乙個字串，這不符合預期的對映結構，Helmuth說。
遙測資料收集有不同的替代方法。 因此，OpenTelemetry Collector 屬於可觀測性類別。 可觀測性**，如OpenTelemetry Collector、Fluentbit、Vector等，“表現出高度的健壯性，並執行各種任務來實現其顯著的結果，”谷歌軟體開發人員Braydon Kains在他的KubeCon + CloudNativeCon演講中談到了可觀測性代理的效能。在演講的最後，有人問到哪個收藏家是最好的。 Kains 將 Google Cloud Ops 描述為兩者的融合。 他說，在幕後，它使用Fluent Bit進行日誌收集，使用OpenTelemetry進行指標和跟蹤資料收集。
該團隊管理乙個配置層，該層負責為基礎 OpenTelemetry 和 Fluent Bit 生成配置。 他說，這些配置包括為主要在虛擬機器上執行的使用者（如普通虛擬機器）量身定製的推薦優化，以便使用OpenTelemetry有效地收集指標。
有很多旋鈕需要跟蹤，新手可能很難跟蹤所有這些旋鈕，“凱恩斯說。 “我們承擔了跟蹤這些旋鈕的責任，並試圖提出在大多數一般情況下最佳的設定。 ”