隨著可觀測性領域對 AI ML 的炒作，公司比以往任何時候都更有可能獲得將資料儲存在乙個系統中以在另乙個系統中檢視和訓練 ML 模型的好處。
作者 Andy Hoffman 翻譯自《為什麼 OpenTelemetry 的最新進展很重要》，擁有超過 16 年的技術經驗，並為獨角獸初創公司和成熟組織構建並領導了多個 DevOps 專案、雲遷移和架構改革。 他從深入的技術工作和團隊建設中找到了樂趣。 今年的雲原生計算**最受歡迎的專案之一是 OpenTelemetry 和 OpenTelemetry Collector。 這個專案在可觀測性領域是乙個非常令人興奮的發展，因為它是一項跨行業的合作，旨在標準化可觀測性和遙測的資料格式。 這本身就很重要，因為它允許從多個可觀察物件收集資料，而以前，如果團隊想要乙個事件的單張圖片，他們就被迫多次轉換資料。 隨著 AI ML 在可觀測性方面的熱潮，公司比以往任何時候都更有可能從乙個系統中儲存和檢視資料以及在另乙個系統中訓練 ML 模型中受益。
最棒的是，由於行業領導者和個人與 OpenTelemetry Collector 的合作，這個專案正在向前推進，OpenTelemetry Collector 是一種提供高吞吐量遙測收集的標準化遙測收集器。 下面，我將分享該項目的一些新功能，以及為什麼它們對社群很重要。
我發現許多語法使得如果不使用一些奇怪的 yaml 或 toml 就很難進行有意義的轉換。 OpenTelemetry Collector 仍然依賴於 YAML 格式，但其新的轉換語言允許基於函式的語句執行得相當快，並允許管理複雜性。 檢視該語法的一些示例。 經過大約一年的開發，日誌收集現已正式發布。 有幾種方法可以收集此實現的日誌：
首先，它作為獨立執行**，並從檔案系統收集日誌。 它可以直接傳送到最終目標，也可以傳送到在收集器模式下執行的 OpenTelemetry Collector，在該模式下可以動態計算日誌指標。
其次，有許多日誌 SDK 可以直接在應用程式中實現併發送到中央收集器或直接傳送到最終目標，這有助於將磁碟 IO 的影響降至最低。
自動檢測是指自動連線應用程式以發出跟蹤和指標的能力，而很少或沒有更改。 j**a 和 .完全支援 .net，其他語言正在各個階段開發和發布。 該專有解決方案一直將這種能力展示為差異化優勢，因為它通過最大限度地減少開發人員時間來降低部署的複雜性，現在這為 OpenTelemetry 生態系統帶來了同樣強大的功能。
這是巨大的，並且受益於 Elasticsearch 向 OpenTelemetry 專案捐贈的 ECS（彈性通用架構）。 標準化遙測結構具有挑戰性，因為似乎幾乎每個人都在以略有不同的格式生成遙測資料; 但是，為了能夠以人性化的方式進行分析、建立警報和呈現資料，需要以某種方式對映所有遙測字段。
如果每個人和每個系統都略有不同，那麼製作可重用的儀表板和元件就帶來了挑戰。 軟體供應商現在可以負責在許多平台上建立儀表板，並有理由相信資料將在多個平台上以正確的格式顯示。
同時，我們這些管理大量遙測資料的人可以提高引入和查詢效率，並且如果大多數客戶傳送的內容依賴於已知欄位名稱，我們可以以更少的計算資源和記憶體開銷提供更高階的功能。
完整的模型距離最終確定還有一段路要走，但公約正在逐步獲得批准。 例如，在 Kubecon 上，他們宣布了 HTTP 模式的最終確定。
生態系統正在成熟。 擴充套件性框架允許自定義引入管道的任何階段。 越來越多的接收器適用於各種系統，處理器具有越來越多的高階功能，以及目的地。 我對新版本的 OpenSearch 擴充套件感到特別興奮，它以簡化的可觀測性模式或 ECS 格式預先打包了日誌資料的傳送。
從開發人員的角度來看，我發現架構的結構和內部的“p”訊息架構經過深思熟慮，並內建到 protobuf 中。 它在功能自由度和最小複雜性之間取得了良好的平衡。
這對 CNCF 社群來說並不新鮮，但該項目的速度和影響力體現了 CNCF 社群理念的精神。 相互競爭的公司正在共同努力，為我們其他人提供更好、更輕鬆的計算機。 有些人可能擔心取消供應商鎖定會導致客戶流失，或者共享可能會洩露專有智財權。
然而，在遙測領域，收集器的核心架構往往是乙個已解決的問題。 那麼，為什麼不做一些遵循慣例並跨平台工作的東西，這樣公司就不再需要維護***，其中 80% 是重複的呢？ 這允許公司開發共享外掛程式以實現互操作性和專有處理器，其中可以通過該框架提供創新。
*企業和所有運營商也從中受益。 使用標準化的 OpenTelemetry Collector SDK，供應商可以建立乙個整合來檢測其應用程式中的遙測資料，並大大簡化收集過程，並嘗試讓所有主要的可觀測性提供商實現對應用程式的支援。
承運商還受益於“隨處取貨”和“隨處傳送”的心態。 標準配置檔案格式簡化了設定，同時最大限度地減少了新系統的複雜性。 我還懷疑，由於該專案對可觀測性資料的語義約定，許多日誌系統操作員將看到此問題的字段對映問題的基數顯著減少。
向所有專案貢獻者和社群成員表示衷心的“感謝”！ ”!我無法在這裡一一列出，但你可以在 GitHub 上的 OpenTelemetry 專案中跟蹤它們。 OpenTelemetry 和 OpenTelemetry Collector 的功能和發展道路正在迅速發展，過去的一年是 CNCF 產品組合中僅次於 Kubernetes 的第二大貢獻專案。 由於有如此多的貢獻者保持井井有條並一起工作，成熟度將繼續加速。 希望這將通過提高互操作性和提高遙測收集檢測系統的能力來解鎖可觀測性的創新。
編者注：本文已經過修訂，以闡明 OpenTelemetry 的作用。 )