為什麼OpenTelemetry正在将雲原生帶到新的高度？

運作雲原生應用程式時，可觀測性（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

航天雲網，國家工業網際網路平台