OpenTelemetry架構介紹

charlieroro發表於2020-10-27
架構

OpenTelemetry: 經得起考驗的工具

摘自：https://blog.newrelic.com/product-news/what-is-opentelemetry/

目錄

什麼是OpenTelemetry？

OpenTelemetry合併了OpenTracing和OpenCensus專案，提供了一組API和庫來標準化遙測資料的採集和傳輸。OpenTelemetry提供了一個安全，廠商中立的工具，這樣就可以按照需要將資料發往不同的後端。

OpenTelemetry專案由如下元件構成：

  • 推動在所有專案中使用一致的規範
  • 基於規範的，包含介面和實現的APIs
  • 不同語言的SDK(APIs的實現)，如 Java, Python, Go, Erlang等
  • Exporters：可以將資料發往一個選擇的後端
  • Collectors：廠商中立的實現，用於處理和匯出遙測資料

術語

如果剛接觸Opentelemetry，那麼需要了解如下術語：

  • Traces：記錄經過分散式系統的請求活動，一個trace是spans的有向無環圖

  • Spans：一個trace中表示一個命名的，基於時間的操作。Spans巢狀形成trace樹。每個trace包含一個根span，描述了端到端的延遲，其子操作也可能擁有一個或多個子spans。

  • Metrics：在執行時捕獲的關於服務的原始度量資料。Opentelemetry定義的metric instruments(指標工具)如下。Observer支援通過非同步API來採集資料，每個採集間隔採集一個資料。

    ame Synchronous Adding Monotonic
    Counter Yes Yes Yes
    UpDownCounter Yes Yes No
    ValueRecorder Yes No No
    SumObserver No Yes Yes
    UpDownSumObserver No Yes No
    ValueObserver No No No

  • Context：一個span包含一個span context，它是一個全域性唯一的標識，表示每個span所屬的唯一的請求，以及跨服務邊界轉移trace資訊所需的資料。OpenTelemetry 也支援correlation context，它可以包含使用者定義的屬性。correlation context不是必要的，元件可以選擇不攜帶和儲存該資訊。

  • Context propagation：表示在不同的服務之間傳遞上下文資訊，通常通過HTTP首部。 Context propagation是Opentelemetry系統的關鍵功能之一。除了tracing之外，還有一些有趣的用法，如，執行A/B測試。OpenTelemetry支援通過多個協議的Context propagation來避免可能發生的問題，但需要注意的是，在自己的應用中最好使用單一的方法。

OpenTelemetry的好處

通過將OpenTracing 和OpenCensus 合併為一個開放的標準，OpenTelemetry提供瞭如下便利：

  • 選擇簡單：不必在兩個標準之間進行選擇，OpenTelemetry可以同時相容 OpenTracing和OpenCensus。
  • 跨平臺：OpenTelemetry 支援各種語言和後端。它代表了一種廠商中立的方式，可以在不改變現有工具的情況下捕獲並將遙測資料傳輸到後端。
  • 簡化可觀測性：正如OpenTelemetry所說的"高質量的觀測下要求高質量的遙測"。希望看到更多的廠商轉向OpenTelemetry，因為它更方便，且僅需測試單一標準。

如何使用OpenTelemetry

OpenTelemetry APIs 和SDKs有很多快速使用指南和文件幫助快速入門，如Java快速指南展示瞭如何獲取跟蹤程式、建立spans、新增屬性，以及跨不同spans傳遞context。

將OpenTelemetry trace APIs插裝到應用程式後，就可以使用預先編譯好的OpenTelemetry 庫中的exporters 將trace資料傳送到觀測平臺，如New Relic或其他後端。

metrics和logs的規範仍在開發階段，但一旦完成，它們將在實現OpenTelemetry的主要目標中發揮重要作用：確保庫和框架包含所有內建的遙測資料型別，使開發人員無需進行檢測即可提取遙測資料。

OpenTelemetry 架構元件

由於OpenTelemetry旨在成為一個為廠商和可觀察性後端提供的跨語言框架，因此它非常靈活且可擴充套件，但同時也很複雜。OpenTelemetry的預設實現中，其架構可以分為如下三部分：

  1. OpenTelemetry API
  2. OpenTelemetry SDK，包括
    • Tracer pipeline
    • Meter pipeline
    • shared Context layer
  3. Collector

OpenTelemetry API

應用開發者會使用 Open Telemetry API對其程式碼進行插樁，庫作者會用它(在庫中)直接編寫樁功能。API不處理操作問題，也不關心如何將資料傳送到廠商後端。

API分為四個部分：

  1. A Tracer API
  2. A Metrics API
  3. A Context API
  4. 語義規範

Tracer API

Tracer API 支援生成spans，可以給span分配一個traceId，也可以選擇性地加上時間戳。一個Tracer會給spans打上名稱和版本。當檢視資料時，名稱和版本會與一個Tracer關聯，通過這種方式可以追蹤生成sapan的插裝庫。

Metric API

Metric API提供了多種型別的Metric instruments(樁功能)，如Counters 和Observers。Counters 允許對度量進行計算，Observers允許獲取離散時間點上的測量值。例如，可以使用Observers 觀察不在Span上下文中出現的數值，如當前CPU負載或磁碟上空閒的位元組數。

Context API

Context API 會在使用相同"context"的spans和traces中新增上下文資訊，如W3C Trace Context, Zipkin B3首部, 或 New Relic distributed tracing 首部。此外該API允許跟蹤spans是如何在一個系統中傳遞的。當一個trace從一個處理傳遞到下一個處理時會更新上下文資訊。Metric instruments可以訪問當前上下文。

語義規範

OpenTelemetry API包含一組語義規範，該規範包含了命名spans，屬性以及與spans相關的錯誤。通過將該規範編碼到API介面規範中，OpenTelemetry 專案保證所有的instrumentation(不論任何語言)都包含相同的語義資訊。對於希望為所有使用者提供一致的APM體驗的廠商來說，該功能非常有價值。

OpenTelemetry SDK

OpenTelemetry SDK是OpenTelemetry API的實現。該SDK包含三個部分，與上面的API類似：Tracer, 一個Meter, 和一個shared Context layer

理想情況下，SDK應該滿足99%的標準使用場景，但如果有必要，可以自定義SDK。例如，可以在Tracer pipeline實現中自定義除核心實現(如何與共享上下文層互動)外的其他任何內容，如Tracer pipeline使用的取樣演算法。

Tracer pipeline

當配置SDK時，需要將一個或多個SpanProcessors與Tracer pipeline的實現進行關聯。SpanProcessors會檢視spans的生命週期，然後在合適的時機將spans傳送到一個SpanExporter。SDK中內建了一個簡單的SpanProcessor，可以將完成的spans直接轉發給exporter 。

SDK還包含一個批處理實現，按照可配置的間隔分批次轉發已完成的spans。但由於SpanProcessor的實現可以接受外掛，因此可以在完成自己的實現後賦予其自定義的行為。例如，如果遙測後端支援觀測"正在進行的"spans，那麼可以建立一個SpanProcessor實現，將所有span狀態變更涉及的spans轉發出去。

Tracer pipeline的最後是SpanExporter。一個exporter的工作很簡單：將OpenTelemetry 的spans轉換為遙測後端要求的表達格式，然後轉發給該後端即可。提供定製化的SpanExporter是遙測廠商參與OpenTelemetry生態系統的最簡單方式。

Meter pipeline

Meter pipeline

Meter pipeline要遠比Tracer pipeline負載，而metrics也遠比span複雜。下面的描述基於java SDK實現，可能跨語言會有所不同。

Meter pipeline會建立和維護多種型別的metric工具，包括Counters 和Observers。每個工具的例項都需要以某種方式聚合。預設情況下，Counters通過累加數值進行聚合，而Observers通過採集記錄到的最後一個數值進行聚合。所有的工具預設都有一個聚合。

(在本文編寫之際，metric工具的自定義聚合配置仍然在起草階段)。

不同語言的Meter pipeline的實現會有所不同，但所有場景下，metric的聚合結果都會被傳遞到MetricExporter。與spans類似，供應商可以提供自己的exporter，將由metric aggregators生成的聚合資料轉換為遙測後端所需的型別。

OpenTelemetry支援兩種型別的exporter：基於exporters的"push"，即exporter按照時間間隔將資料傳送到後端；基於exporters的"pull"，即後端按照需要請求資料。New Relic 是一個基於push的後端，而Prometheus是一個基於push的後端。

shared Context layer

shared Context layer位於Tracer和Meter pipeline之間，允許在一個執行的span的上下文中記錄所有非observer的metric。可以使用propagators自定義Context，在系統內外傳遞span上下文。OpenTelemetry SDK提供了一個基於W3C Trace Context規範的實現，但也可以根據需要來包含 Zipkin B3 propagation等。

Collector

下面對collector的描述來自官方文件

OpenTelemetry Collector提供了一種廠商中立的實現，無縫地接收，處理和匯出遙測資料。此外，它移除了為支援傳送到多個開源或商業後端而使用的開源可觀察性資料格式(如Jaeger，Prometheus等)的執行，操作和維護。

OpenTelemetry collector可以擴充套件或嵌入其他應用中。下面應用擴充套件了collector：

如果要建立自己的collector發行版，可以參見這篇blog： Building your own OpenTelemetry Collector distribution。

如果要構建自己的發行版，可以使用OpenTelemetry Collector Builder 。

相關文章