?譯者 | 布加迪

審校 | 孫淑娟

運行云原生應用程序時，可觀測性（observability）很關鍵。在云原生領域，應用程序功能來自在多個位置運行的眾多微服務之間的交互。微服務應用程序具有松散耦合性，可能意味著每個微服務都以各自的方式報告其活動。如果沒有一種工具來匯總和關聯這些遙測數據，自始至終跟蹤請求的處理就算并非沒有可能，也是非常困難的。

這種細粒度、循序漸進的跟蹤對于故障排除和性能調優而言至關重要。在物色一種多功能的可觀測性工具時，NGINX現代應用程序參考架構（MARA）項目背后的團隊選擇了OpenTelemetry。這篇博文解釋了為什么OpenTelemetry對微服務架構而言如此重要，以及它在如何改變云原生應用程序格局。

OpenTelemetry驅動可觀測性2.0

OpenTelemetry在2019年巴塞羅那KubeCon大會上首次宣布，此后就吸引了一批狂熱的貢獻者。今天，它仍然是云原生計算基金會（CNCF）的一個高人氣項目。越來越多的貢獻者表明OpenTelemetry已趨成熟，開始跨越愿意嘗新的早期采用者和渴望成熟產品的實用主義者之間的這條鴻溝。

OpenTelemetry專注于數據，具體說來是最有效地了解、檢測和改進應用程序所需要的數據和數據流（遙測）。數據只有在可以大規模聚合、分析和可視化后才有用。雖然OpenTelemetry并不提供可視化數據方面的指導，但它讓我們從此不必操心我們獲得什么數據，而是專注于我們可以用數據做什么。

OpenTelemetry簡化了跨數據源和應用程序關聯事件的工作。這由此帶來了可觀測性2.0，這是用于測量云端應用程序活動的新基準。由于數據自動關聯，我們不再局限于僅僅知道應用程序是否在運行。現在我們可以了解任何請求通過我們的應用程序所經過的確切數據路徑。

為了實現這一點，OpenTelemetry的兩個功能方面非常關鍵：分布式跟蹤和應用程序智能。

為何現代應用程序架構需要分布式跟蹤？

雖然分布式跟蹤已經存在多年了（可以追溯到Solaris中的DTrace），但過去十年發生的許多變化加大了用戶對它的需求。使用Cynefin框架，我們可以著重表明如今在現代應用程序方面面臨的一些變化和挑戰：

Cynefin框架表明了從簡單向復雜變化時，我們的實踐或做法會發生怎樣的變化。面臨的挑戰是，我們沿兩條不同的路徑前進，每條路徑有其特點；從簡單變成復雜后，試圖直接抄捷徑常常會造成混亂和不完整的進展。

不妨看看哪些要素構建了現代應用程序和云原生旅程中的路徑。在第一條路徑（Cynefin圖中的Y軸）中，我們有現代應用程序，它們通常是微服務架構，每個應用程序都做特定的工作。在第二條路徑（X軸）中，復雜的環境是短暫的，因為微服務實例根據需求來創建和關閉，并根據網絡問題移動到不同的主機上。

我們還必須考慮云環境的出現和迅猛增長，比如亞馬遜網絡服務（AWS）、微軟Azure和谷歌云平臺（GCP）等云環境。這種云的一個優點是彈性響應——可以靈活擴展或收縮資源，以匹配當前的需求量。加上容器編排（最常使用Kubernetes）的影響，隨著資源的數量和位置在一段時間后出現變化，我們開始看到混亂的行為。（連這種相對受限的視圖也很混亂，而無服務器函數等要素可能也會使其更混亂。）

在現代架構中，有許多獨立的部分生成我們監控和維護應用程序所需的遙測數據，數據負載龐大而復雜。由于我們無法完全控制基礎設施和通信路徑，問題可能不會可靠地重復或容易引發。我們需要能夠讓我們一直跟蹤所有活動和相關要素的技術，這樣我們可以理解和分析不斷變化的環境，不僅可以識別反復出現的問題，還可以識別異常情況以及相關的應用程序和網絡情況。

這時候OpenTelemetry應運而生。

OpenTelemetry在分布式跟蹤方面的未來

分布式跟蹤支持跟蹤許多類型的新指標，但最常見的指標是與每個時間單位的請求數量、每個時間單位的錯誤數量以及聚合請求在該時間單位中占多長時間有關的指標。

在OpenTelemetry中，所有生成指標的應用程序都可以通過遙測（傳輸）層將它們發送到一個通用收集點，這有助于對齊和關聯來自生成數據的松散耦合服務的數據。這包括與底層基礎設施保持一致。簡而言之，有了OpenTelemetry，獲取和發送高度詳細的指標變得更輕松了。

OpenTelemetry還有助于解決時間戳漂移和傾斜問題，這個問題使事件關聯起來變得很難。OpenTelemetry為每個請求分配一個跟蹤編號（TraceId），但數據仍然可能受到漂移和傾斜的影響，這個問題常常出現在云原生架構中。漂移和傾斜可能是持續時間不一的報告路徑或各個主機上時鐘之間缺乏緊密同步造成的。通過在流量處理期間跟蹤組件之間的通信，分布式跟蹤允許OpenTelemetry測量單個跨度（跟蹤的工作單位和基本模塊），不需要對相關應用程序進行深入的檢測。

結合這三種信號（遙測的類別），我們就可以糾正問題，讓應用程序恢復到生產級質量：

• 指標——“存在問題？”
• 跟蹤——“問題在哪里？”
• 日志——“出了什么問題？”

這時候我們又回到了可觀測性2.0。能夠獲得跟蹤并立即查看哪些指標對應哪些跟蹤為我們賦予了強大的功能。比如說，當指標表明有問題時，分布式跟蹤讓您可以一路追溯到導致初始問題的那個特定請求，并跟蹤請求實現的每個步驟的進度。由于我們的跟蹤是由跨度按照它們發生的順序組成的，所以我們可以在請求旅程的每一步跟蹤請求。了解發生了什么，以什么順序發生（從初始事件到表明的問題，直到最終結果），讓我們能夠聚焦于應用程序中具體的部位，集中注意力。

盡管聽起來很簡單，OpenTelemetry的分布式跟蹤方面可以讓我們深入了解用戶所遇到的一切，作為請求成功和執行時間的代理。作為用戶，我關心我的請求。作為站點可靠性工程師（SRE），我關心聚合的請求。作為應用程序所有者，我還關心尾部延遲：在某些條件下，對于少量重要的用戶群體而言，尾部延遲可能演變成糟糕的性能。OpenTelemetry為我提供了這三個功能，以及從聚合內容中提煉細節的能力，因為它本身旨在讓所有應用程序上的所有數據能夠為用戶所用。

借助AI和ML的應用程序智能

來自OpenTelemetry的這種新數據流還讓我們在開發和操作響應方面可以實現自適應和自動化。有了所有這些積累的數據，我們可以使應用程序更加智能和自適應。而自適應應用程序恰如其名：自動智能地調整其行為以應對環境變化的應用程序。

通過實現遙測數據的可訪問性和標準化，OpenTelemetry使通向自適應應用程序的旅程變得更順坦。隨著不同類型的產品開始輸出類似的指標，如果利用OpenTelemetry中已確立的語義約定，我們更容易在請求處理期間將它們的操作關聯起來，并將這些信息饋送給人工智能（AI）和機器學習（ML）算法，從而使應用程序和基礎設施能夠動態適應。

總結

對OpenTelemetry的用戶和使用它作為遙測通道的應用程序來說，規范遙測是明顯的舉措。可以從多個數據源收集數據，并轉發給任何兼容的聚合和分析工具。此外，OpenTelemetry Collector使供應商不必自行實施收集器。相反，它們可以致力于改善代碼，以執行有意義的分析，并采取明智的操作，可以構建新的工具來幫助理解這個復雜而混亂的新世界。實際上，OpenTelemetry Collector（基于開源創新）在讓這項技術順應未來的同時，能夠處理幾乎所有的現有格式。

OpenTelemetry專注于我們理解應用程序所需的主要數據類別，使我們的應用程序可以為復雜的現代應用程序環境的性能和問題提供更深入的見解。通過關聯我們的數據、遵守語義和標準慣例，OpenTelemetry使通向現代應用程序的旅程變得更順坦。

隨著OpenTelemetry項目不斷成熟，采用率不斷提高，它顯然是我們加深了解的方法。我們還希望OpenTelemetry有助于運用AI和ML技術來解決復雜問題、實現自動化補救，并表明如何使云原生應用程序變得更具適應性、性能更好。

原文標題：??Why OpenTelemetry Is Taking Cloud Native to New Heights??，作者：Dave McAllister?