快连VPN:速度和安全性最佳的VPN服务
在與prometheus長期維護者goutham veeramachaneni的問答中，他剖析了opentelemetry (otel) 對可觀察性領域的影響。otel促進了遙測數據的標準化，推動了數據收集器和工作流程的創新，彌合了應用程序和基礎設施監控之間的鴻溝。veeramachaneni深入分析了不斷發展的生態系統、未來的挑戰以及開發人員通過otel構建更高效遙測數據管道的可能性。
在這次富有洞察力的問答中，長期擔任Prometheus維護者和Grafana Labs產品經理的Goutham Veeramachaneni分享了他對OpenTelemetry (OTel) 在可觀察性領域的變革性影響的獨特見解 。Veeramachaneni 討論了 OTel 如何標準化遙測數據並啓發新的開源數據收集器和工作流程，以彌合應用程序和基礎設施監控之間的差距。他對不斷發展的生態系統、未來的挑戰以及開發人員在編寫更有效的遙測數據管道方面的激動人心的可能性提供了寶貴的見解。
問：作爲 Prometheus 的長期維護者，您如何看待 OpenTelemetry 對市場產生的整體影響？
答： 它讓開發人員和平臺團隊對其數據擁有了更大的所有權。它爲他們提供了前所未有的靈活性和自由。以前，由於沒有遙測數據的通用開放標準，專有供應商的捕鼠器被設計成使遷移到其他解決方案變得極其困難，這太瘋狂了。這些供應商沒有太多的創新或競爭動力，因爲他們已經設計瞭如此有效的捕鼠器來鎖定用戶。他們說出自己的協議並收集自己的指標，但沒有標準化。OpenTelemetry 已經迫使整個市場在 OTLP 協議及其 SDK 和 API 生態系統上實現標準化。這剝奪了供應商的權力，並創建了一個動態、開放的標準，每個人都可以合作——這正在推動大量創新。
問：過去一年中，您看到 OTel 最令人興奮的新進展是什麼？
答：我很高興看到 Prometheus 和 OTel 的合作，以及將應用程序可觀察性提升到與基礎設施可觀察性相同的標準化和一致性水平的所有勢頭。Prometheus 是基礎設施可觀察性中的一個重要組成部分——每個人都直接使用它，或者從供應商那裏使用 Prometheus 的某個版本。Prometheus 如此受歡迎的原因之一是幾乎每個基礎設施組件都有一個導出器，並且有如此龐大的社區支持它。然而，在 OTel 出現之前，應用程序可觀察性中不存在這樣的標準化和創新速度，因爲您需要花費大量精力來創建自動檢測代理，並且只有擁有 20 人團隊開發這些檢測代理的知名供應商才具備這種技能。因此，應用程序可觀察性擁有所有這些用於指標收集的專有協議和方法，並且沒有標準化。但現在 OTel 通過引入一個可以監控應用程序的標準創造了立足點，並且同樣爲所有流行語言實施了該標準。
問：應用程序和基礎設施可觀察性結合在一起意味着什麼？我們需要做些什麼才能實現這一目標？
答： 嗯，我們已經有一個標準，就像Prometheus及其導出器一樣，現在在應用程序可觀察性世界中，您擁有所有這些 SDK 和自動儀表代理來生成 OpenTelemetry。Prometheus 在過去一年中取得了很大進展，開始提取 OTel 數據，因此基礎設施和應用程序指標現在並排位於同一系統中。Prometheus 3.0 將於今年晚些時候推出，其主要功能和重點領域之一就是對 OpenTelemetry 的支持。
然而，故事並沒有結束。您需要能夠輕鬆地將指標關聯在一起。例如，您需要能夠將 RED 指標中的錯誤峯值與應用程序正在運行的節點上的 CPU 飽和度聯繫起來。這很棘手，因爲 Prometheus 和 OpenTelemetry 的約定尚未對齊。我相信這是社區明年將關注的重點：確保您能夠無縫關聯和導航使用 OTel 進行應用程序監控和使用 Prometheus 進行基礎設施監控這兩個世界之間的數據。
最後，還有一個“收集”這些數據的癥結。雖然您可以使用 OpenTelmetry Collector 收集 Prometheus 指標，但您需要將 Prometheus 轉換爲 OTLP，然後再轉換回 Prometheus 數據（因爲數據存儲是 Prometheus）。這在當今具有很高的 CPU 開銷，這是我們想要優化的。這也是我對 Grafana 的新開源收集器 Alloy 感到興奮的原因。Alloy 來自 Prometheus 優先的傳統，並嵌入了多個基礎 Prometheus 導出器。它也是一個 OTel Collector 發行版，支持高效收集和處理 OTel 數據。它之所以出彩，是因爲如果您正在收集 Prometheus 數據並且您的最終目的地也是 Prometheus，那麼它可以避免在管道中轉換爲 OTLP 的 CPU 成本。
這是開放標準的優點之一，也是構建的穩定基礎 — 您可以直接使用 OTel 收集器，也可以使用經過優化的新收集器（如 Alloy），它使 Prometheus 和 OTLP 能夠更無縫地協同工作，或者您可以嘗試任何其他收集器。OTel 創造了這個買方市場，開發人員可以自由選擇使用哪些可觀察性工具，同時知道他們擁有自己的遙測數據，並且 OTel 本身正在承擔語言支持的重任。
問：您能描述一下應用程序和基礎設施可觀察性之間的歷史脫節嗎？
答：今天，如果您查看要調試的系統，就會發現它有基礎設施——MySQL 、 Postgres、數據庫、節點級數據（例如我正在運行的主機以及它所運行的內存和 CPU），然後您正在其上運行應用程序 / 容器。當您打開一個頁面時，用戶會看到錯誤——突然間，您就會擁有一組儀表板，其中顯示了應用程序列表以及每個應用程序的執行情況。很容易看到錯誤發生在哪裏（例如，在 MySQL 中），但從那裏找出 MySQL 的問題並不容易。因爲應用程序使用的是 OpenTelemetry 指標，而 MySQL 使用的是 Prometheus 指標——兩者之間沒有標準化。需要大量的專業知識才能找到正在運行的服務的正確實例並進行這些類型的關聯，而隨着我們看到 Prometheus 和 OpenTelemetry 之間更深層次的原生集成，這將變得更加容易。
問：您認爲 OTel 未來將重點解決哪些遙測數據方面尚未解決的問題領域？
答：要實現標準化的目標，你必須在許多人和團體之間達成共識——這是 OTel 所取得的成就中令人矚目的一點。一旦規範確定，執行和創新就會變得容易。我看到一些領域，OpenTelemetry 不可避免地會對遙測數據標準化產生類似的影響，但事情還處於早期階段，達成共識仍是一條出路。前端監控用戶監控就是一個例子。在日誌記錄方面，我們需要看到更多數據庫和日誌記錄系統採用 OTel 規範。LLM 的語義約定仍然主要是專有的。觀察消息隊列和構建在其上的應用程序仍處於早期階段。CI/CD 領域有大量創新，需要更好的指標來了解構建需要多長時間——這是 OTel 的另一個令人興奮的機會領域。
以上就是OpenTelemetry：統一應用程序和基礎設施的可觀察性的詳細內容，更多請關注本站其它相關文章！
