什么是OpenTelemetry？

OpenTelemetry合并了OpenTracing和OpenCensus項目，提供了一組API和庫來標準化遙測數(shù)據(jù)的采集和傳輸。OpenTelemetry提供了一個安全，廠商中立的工具，這樣就可以按照需要將數(shù)據(jù)發(fā)往不同的后端。

OpenTelemetry項目由如下組件構(gòu)成：

• 推動在所有項目中使用一致的規(guī)范
• 基于規(guī)范的，包含接口和實現(xiàn)的APIs
• 不同語言的SDK(APIs的實現(xiàn))，如 Java, Python, Go, Erlang等
• Exporters：可以將數(shù)據(jù)發(fā)往一個選擇的后端
• Collectors：廠商中立的實現(xiàn)，用于處理和導出遙測數(shù)據(jù)

術(shù)語

如果剛接觸Opentelemetry，那么需要了解如下術(shù)語：

• Traces：記錄經(jīng)過分布式系統(tǒng)的請求活動，一個trace是spans的有向無環(huán)圖

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

• Metrics：在運行時捕獲的關(guān)于服務(wù)的原始度量數(shù)據(jù)。Opentelemetry定義的metric instruments(指標工具)如下。Observer支持通過異步API來采集數(shù)據(jù)，每個采集間隔采集一個數(shù)據(jù)。

  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所屬的唯一的請求，以及跨服務(wù)邊界轉(zhuǎn)移trace信息所需的數(shù)據(jù)。OpenTelemetry 也支持correlation context，它可以包含用戶定義的屬性。correlation context不是必要的，組件可以選擇不攜帶和存儲該信息。

• Context propagation：表示在不同的服務(wù)之間傳遞上下文信息，通常通過HTTP首部。 Context propagation是Opentelemetry系統(tǒng)的關(guān)鍵功能之一。除了tracing之外，還有一些有趣的用法，如，執(zhí)行A/B測試。OpenTelemetry支持通過多個協(xié)議的Context propagation來避免可能發(fā)生的問題，但需要注意的是，在自己的應(yīng)用中最好使用單一的方法。

OpenTelemetry的好處

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

• 選擇簡單：不必在兩個標準之間進行選擇，OpenTelemetry可以同時兼容 OpenTracing和OpenCensus。
• 跨平臺：OpenTelemetry 支持各種語言和后端。它代表了一種廠商中立的方式，可以在不改變現(xiàn)有工具的情況下捕獲并將遙測數(shù)據(jù)傳輸?shù)胶蠖恕?/li>
• 簡化可觀測性：正如OpenTelemetry所說的"高質(zhì)量的觀測下要求高質(zhì)量的遙測"。希望看到更多的廠商轉(zhuǎn)向OpenTelemetry，因為它更方便，且僅需測試單一標準。

如何使用OpenTelemetry

OpenTelemetry APIs 和SDKs有很多快速使用指南和文檔幫助快速入門，如Java快速指南展示了如何獲取跟蹤程序、創(chuàng)建spans、添加屬性，以及跨不同spans傳遞context。

將OpenTelemetry trace APIs插裝到應(yīng)用程序后，就可以使用預(yù)先編譯好的OpenTelemetry 庫中的exporters 將trace數(shù)據(jù)發(fā)送到觀測平臺，如New Relic或其他后端。

metrics和logs的規(guī)范仍在開發(fā)階段，但一旦完成，它們將在實現(xiàn)OpenTelemetry的主要目標中發(fā)揮重要作用：確保庫和框架包含所有內(nèi)置的遙測數(shù)據(jù)類型，使開發(fā)人員無需進行檢測即可提取遙測數(shù)據(jù)。

OpenTelemetry 架構(gòu)組件

由于OpenTelemetry旨在成為一個為廠商和可觀察性后端提供的跨語言框架，因此它非常靈活且可擴展，但同時也很復雜。OpenTelemetry的默認實現(xiàn)中，其架構(gòu)可以分為如下三部分：

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

image.png

OpenTelemetry API

應(yīng)用開發(fā)者會使用 Open Telemetry API對其代碼進行插樁，庫作者會用它(在庫中)直接編寫樁功能。API不處理操作問題，也不關(guān)心如何將數(shù)據(jù)發(fā)送到廠商后端。

API分為四個部分：

1. A Tracer API
2. A Metrics API
3. A Context API
4. 語義規(guī)范

image.png

Tracer API

Tracer API 支持生成spans，可以給span分配一個traceId，也可以選擇性地加上時間戳。一個Tracer會給spans打上名稱和版本。當查看數(shù)據(jù)時，名稱和版本會與一個Tracer關(guān)聯(lián)，通過這種方式可以追蹤生成sapan的插裝庫。

Metric API

Metric API提供了多種類型的Metric instruments(樁功能)，如Counters 和Observers。Counters 允許對度量進行計算，Observers允許獲取離散時間點上的測量值。例如，可以使用Observers 觀察不在Span上下文中出現(xiàn)的數(shù)值，如當前CPU負載或磁盤上空閑的字節(jié)數(shù)。

Context API

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

語義規(guī)范

OpenTelemetry API包含一組語義規(guī)范，該規(guī)范包含了命名spans，屬性以及與spans相關(guān)的錯誤。通過將該規(guī)范編碼到API接口規(guī)范中，OpenTelemetry 項目保證所有的instrumentation(不論任何語言)都包含相同的語義信息。對于希望為所有用戶提供一致的APM體驗的廠商來說，該功能非常有價值。

OpenTelemetry SDK

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

image.png

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

Tracer pipeline

image.png

當配置SDK時，需要將一個或多個SpanProcessors與Tracer pipeline的實現(xiàn)進行關(guān)聯(lián)。SpanProcessors會查看spans的生命周期，然后在合適的時機將spans傳送到一個SpanExporter。SDK中內(nèi)置了一個簡單的SpanProcessor，可以將完成的spans直接轉(zhuǎn)發(fā)給exporter 。

SDK還包含一個批處理實現(xiàn)，按照可配置的間隔分批次轉(zhuǎn)發(fā)已完成的spans。但由于SpanProcessor的實現(xiàn)可以接受插件，因此可以在完成自己的實現(xiàn)后賦予其自定義的行為。例如，如果遙測后端支持觀測"正在進行的"spans，那么可以創(chuàng)建一個SpanProcessor實現(xiàn)，將所有span狀態(tài)變更涉及的spans轉(zhuǎn)發(fā)出去。

Tracer pipeline的最后是SpanExporter。一個exporter的工作很簡單：將OpenTelemetry 的spans轉(zhuǎn)換為遙測后端要求的表達格式，然后轉(zhuǎn)發(fā)給該后端即可。提供定制化的SpanExporter是遙測廠商參與OpenTelemetry生態(tài)系統(tǒng)的最簡單方式。

Meter pipeline

image.png

Meter pipeline

Meter pipeline要遠比Tracer pipeline負載，而metrics也遠比span復雜。下面的描述基于java SDK實現(xiàn)，可能跨語言會有所不同。

Meter pipeline會創(chuàng)建和維護多種類型的metric工具，包括Counters 和Observers。每個工具的實例都需要以某種方式聚合。默認情況下，Counters通過累加數(shù)值進行聚合，而Observers通過采集記錄到的最后一個數(shù)值進行聚合。所有的工具默認都有一個聚合。

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

不同語言的Meter pipeline的實現(xiàn)會有所不同，但所有場景下，metric的聚合結(jié)果都會被傳遞到MetricExporter。與spans類似，供應(yīng)商可以提供自己的exporter，將由metric aggregators生成的聚合數(shù)據(jù)轉(zhuǎn)換為遙測后端所需的類型。

OpenTelemetry支持兩種類型的exporter：基于exporters的"push"，即exporter按照時間間隔將數(shù)據(jù)發(fā)送到后端；基于exporters的"pull"，即后端按照需要請求數(shù)據(jù)。New Relic 是一個基于push的后端，而Prometheus是一個基于push的后端。

shared Context layer

shared Context layer位于Tracer和Meter pipeline之間，允許在一個執(zhí)行的span的上下文中記錄所有非observer的metric?？梢允褂?em>propagators自定義Context，在系統(tǒng)內(nèi)外傳遞span上下文。OpenTelemetry SDK提供了一個基于W3C Trace Context規(guī)范的實現(xiàn)，但也可以根據(jù)需要來包含 Zipkin B3 propagation等。

Collector

image.png

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

OpenTelemetry Collector提供了一種廠商中立的實現(xiàn)，無縫地接收，處理和導出遙測數(shù)據(jù)。此外，它移除了為支持發(fā)送到多個開源或商業(yè)后端而使用的開源可觀察性數(shù)據(jù)格式(如Jaeger，Prometheus等)的運行，操作和維護。

OpenTelemetry collector可以擴展或嵌入其他應(yīng)用中。下面應(yīng)用擴展了collector：

• opentelemetry-collector-contrib
• jaeger

如果要創(chuàng)建自己的collector發(fā)行版，可以參見這篇blog： Building your own OpenTelemetry Collector distribution。

如果要構(gòu)建自己的發(fā)行版，可以使用OpenTelemetry Collector Builder 。