天天看點

Adobe 如何使用 OpenTelemetry Collector

翻譯自 How Adobe Uses OpenTelemetry Collector 。

作為開源可觀測性工具的一部分,它充當 Adobe 大量跟蹤和名額資料的中心樞紐,也是緩解開發人員摩擦的一種方式。

Adobe 如何使用 OpenTelemetry Collector

Adobe 的 Chris Featherstone 和 Shubhanshu Surana 在北美開源峰會的演講中稱贊 OpenTelemetry Collector 是可觀測性的瑞士軍刀。

他們繼續解釋如何使用它來跟蹤公司收集的大量可觀測性資料,包括名額,每天 3.3 億個獨特的 series ;每天 3.6 TB 的 span 資料;每天超過 1 PB 的日志資料。

Adobe 如何使用 OpenTelemetry Collector

Adobe 的 Chris Featherstone 和 Shubhanshu Surana

軟體開發進階經理 Featherstone 解釋說,并非所有這些資料都流經他的團隊或 OTel collector ,但“這是一個相當不錯的部分”。分布式跟蹤将他的團隊帶到了 OpenTelemetry 。他解釋說, Adobe 主要由收購組成,随着每家新公司的引入,人們對最好的雲、這個工具、那個文本編輯器等都有自己的看法。

“特别是分布式跟蹤,這成為一個巨大的挑戰,”他說。“想象一下,試圖在雲供應商之間拼接一條線索,開源。是以最終,這就是我們找到這個 collector 的原因。但我們試圖建立一個基于 Jaeger 代理的分布式跟蹤平台。那是在 2019 年。

于 2020 年 4 月開始推出 OTel Collector ,以取代 Jaeger 代理。最初, Collector 隻是攝取跟蹤,但在 2021 年 9 月,引入了名額,他們也希望引入日志。

Adobe 如何使用 OpenTelemetry Collector

團隊使用 Open Telemetry 庫(主要是自動 instrumentation )和主要的 Java 來 instrument 應用程式。它執行一些應用程式增強,引入 Adobe 特定的資料并在資料流向 collector 的過程中豐富其管道。它有一些自定義 extensions 和 processors,團隊在可能的情況下通過 GitOps 進行配置。

Featherstone 表示:" collector 非常動态的,可以使用一組資料擴充到多個目的地,這對我們來說是巨大的。......有時我們會将收集器的資料發送到其他收集器以進行進一步處理。是以它是可觀測性的瑞士軍刀。"

他在 Adobe 的團隊被稱為開發人員生産力,其章程旨在幫助開發人員更快地編寫更好的代碼。

尤其對于 Java 服務,它有一個基本容器,“如果您使用 Java 鏡像,您應該使用這個......它已經內建了許多提高生活品質的功能,包括 OpenTelemetry Java instrumentation 的 jar 包。[配置]來自我們的文檔,這正是我們為Java配置的方式。”

他說:"是以我們将 Jaeger 端點設定為本地 DaemonSet collector 。我們将名額 exporter 設定為 Prometheus ,我們設定了 propagators,我們設定了一些額外的資源屬性,我們設定了 tracer ,将 exporter 設定為 Jaeger 。我們将跟蹤采樣設定為基于父級的總是關閉狀态。"他指出這一切都融入了 Java 鏡像。

是以,通過這些配置,任何在 Adobe 的 Kubernetes 中啟動的 Java 服務都已經參與了跟蹤。以這種方式設定的所有内容都通過 collector 。

他說:"是以每個人隻要啟動這個應用程式就可以參與跟蹤。"他說道:" metrics ,我們努力降低摩擦,人們仍然需要以某種方式從該 exporter 中擷取這些 metrics 。我們已經使這個過程變得相當簡單,但它不是自動的。"他說,他們運作的大約 75% 是 Java ,但他們正試圖将同樣的概念應用于 Node.js 、 Python 和其他鏡像。

管理資料

他們做了很多擴充,并確定沒有 secrets 作為我們的跟蹤或名額資料的一部分發送,Adobe的雲營運站點可靠性工程師 Surana 說。

它使用多個程序,包括縮減處理器以及 OpenTelemetry Collector 中的自定義 processor,後者允許他們消除某些不想發送到後端的字段,這些字段可能是個人身份資訊或其他敏感資料。他們還用于豐富資料,因為添加更多字段,如服務辨別符、 Kubernetes 叢集和地區可以改善搜尋。

“ Adobe 是在積極收購的基礎上建立起來的,我們在不同的生态系統中運作多種不同的産品。服務名稱很有可能在不同的産品下或類似的微服務名稱下發生沖突,是以我們希望確定這種情況不會發生,“他說。

它還使用 Adobe 特定的服務系統資料庫,其中每個服務都有一個附加到服務名稱的唯一 ID 。它允許 Adobe 的任何工程師在單個跟蹤後端中唯一辨別服務。

“它也允許工程師快速搜尋事物,即使他們不知道該服務,或者他們不知道誰擁有該服務,他們也可以檢視我們的服務系統資料庫,找出該特定産品或團隊的工程聯系人,并打電話解決他們的問題,” Surana 說。

Adobe 如何使用 OpenTelemetry Collector

它們還将資料發送到多個導出目标。

他說:"這可能是最常見的用例。"在引入 OpenTelemetry Collector 之前, Adobe 的工程團隊一直使用不同的流程、不同格式的不同庫。他們将其發送到供應商産品、開源項目,對我們來說很難讓工程團隊改變他們的後端,或隻在後端代碼或他們的應用程式代碼中進行任何小的變更,因為工程師有自己的産品特征和産品需求,他們正在努力實作。

“随着 OpenTelemetry Collector 的引入,以及 OTLP [OpenTelemetry協定] 格式,這對我們來說變得非常容易;我們能夠将他們的資料發送給多個供應商,多個工具,隻需進行少量更改。

去年,他們能夠同時将跟蹤資料發送到三個不同的後端,以測試一個特定于工程的用例。

他們現在将資料發送到邊緣的另一組 OTel 收集器,在那裡他們可以進行轉換,包括反向采樣,基于規則的采樣和基于吞吐量的采樣。

他說,他們一直在尋找其他方法來獲得更豐富的見解,同時向後端發送更少的資料。

“整個配置由 git 管理。我們主要将 OpenTelemetry Operator Helm Chart 用于我們的基礎設施用例。...它剝奪了工程師成為主題專家的責任......并使配置變得超級簡單,“他說。

使用 OpenTelemetry Operator 的自動 instrumentation 允許工程師隻需傳入幾個注釋,即可自動檢測所有不同信号的服務,而無需編寫任何代碼。

“這對我們來說是巨大的,”他說。這将開發人員的工作效率提升到一個新的水準。

Adobe 如何使用 OpenTelemetry Collector

他們還使用自定義身份驗證器接口在 OpenTelemetry Collector 之上建構了一個自定義擴充。他們對這個身份驗證系統有兩個關鍵要求:能夠使用單個系統安全地将資料發送到不同的後端,并能夠為開源和供應商工具保護資料。

OpenTelemetry Collector 附帶了一組豐富的流程,用于建構資料流程,包括一個屬性處理器,它允許您在日志資料和矩陣資料之上添加屬性。它允許您轉換、豐富或修改傳輸中的資料,而無需應用程式工程師執行任何操作。Adobe 還使用它來改進其後端的搜尋功能。

記憶體限制器處理器有助于確定 OTel 永遠不會耗盡記憶體,并檢查保持狀态所需的存儲量。他們還使用 span 到矩陣處理器和 service graph 處理器從跟蹤中生成資料,并動态建構名額儀表闆。

那麼下一步是什麼?

根據 Featherstone 的說法,有兩件事:提高資料品質,即擺脫沒有人會看的資料,以及在邊緣限制 spans 。

collector 在邊緣提供建立規則和删除某些資料的功能。

“對于名額,想象一下我們有能力在收集器本身中進行聚合。你知道,也許我們不需要15秒的粒度,讓我們把它簡化為五分鐘,然後發送出去,“ Featherstone 說。

“另一個例子可能是發送一些名額進行長期存儲,并将一些名額發送出去以在某個營運資料湖或類似系統中進一步處理。我們有能力在 collector 中直接調整方向,做各種各樣的事情。”

第二件事是邊緣的 span 速率限制。

他說:"我們的邊緣之一每天有大約 60 億次點選量,我們正試圖對此進行跟蹤。當您談論将所有這些資料一直傳送到某個地方進行存儲時,這将産生大量資料。是以,我們正試圖弄清楚在哪些 collectors 中以及在什麼級别實作速率限制的正确位置......隻是為了防止未知的流量突發,這種情況。"

他們還試圖更多地轉向跟蹤優先故障排除。

他說:"我們有許多東西向服務,試圖通過日志來完成此操作,并試圖為任何團隊拉起正确的日志索引,甚至是否有權通路它或其他什麼。這是如此緩慢和難以完成,以至于我們正努力改變 Adobe 内部故障排除的方式,改為像這樣的方式,我們已經付出了很多努力來使這些跟蹤變得相當完整。"

他們還研究了人們如何進行故障排除,以及他們擁有的工具是否提供了最好的方法。

他們期待将 OpenTelemetry 日志記錄庫與核心應用程式庫內建,并将 OTel 收集器作為邊車來發送名額,跟蹤和日志。他們探索新的連接配接器元件,并在邊緣建構跟蹤采樣擴充,以提高資料品質。

最後,他稱贊了收集器基于插件的架構以及使用單個二進制檔案将資料發送到不同目的地的能力。他說,有一組豐富的 extensions 和 processors ,可以為你的資料提供很大的靈活性。

“總的來說, OpenTelemetry 對我來說感覺很多,就像 Kubernetes 的早期一樣,每個人都在談論它,它開始就像我們現在走在曲棍球棒的道路上一樣,”他說。“社群很棒。這個項目很棒。如果你還沒有用 collector ,你一定要去看看。

繼續閱讀