Opentelemetry 調(diào)研實踐二（OpenTelemetry 架構(gòu)及名詞介紹）

上文^[1]簡單說了下可觀測性，然后引出了主角: opentelemetry。

可觀測性一個很重要的領(lǐng)域Trace有兩個業(yè)界標(biāo)桿: 一個是OpenTracing^[2]，另一個OpenCensus^[3]，OpenTracing 其實是一個規(guī)范，jeager 就是基于 opentracing 實現(xiàn)的開源工具，而 OpenCensus 則是由 google 開源的度量工具，簡單來說，這兩者在可觀測性領(lǐng)域功能高度重合，因此，在 CNCF 主導(dǎo)下進(jìn)行了合并形成 opentelemetry 項目，OpenTracing 跟 penCensus 共同推進(jìn) opentelemetry，兩者的官網(wǎng)也赫赫表達(dá)基本不再維護(hù)，同時 opentelemetry 也致力于 trace、logging、metrics 間的關(guān)聯(lián)性。

OpenTelemetry 核心工作

• 1.規(guī)范的制定和協(xié)議的統(tǒng)一，規(guī)范包含數(shù)據(jù)傳輸、API 的規(guī)范，協(xié)議的統(tǒng)一包含：HTTP W3C 的標(biāo)準(zhǔn)支持及 GRPC 等框架的協(xié)議標(biāo)準(zhǔn)
• 2.多語言 SDK 的實現(xiàn)和集成，用戶可以使用 SDK 進(jìn)行代碼自動注入和手動埋點，同時對其他三方庫（Log4j、LogBack 等）進(jìn)行集成支持
• 3.數(shù)據(jù)收集系統(tǒng)的實現(xiàn)，當(dāng)前是基于 OpenCensus Service 的收集系統(tǒng)，包括 Agent 和 Collector。

由此可見，OpenTelemetry 的自身定位很明確：數(shù)據(jù)采集和標(biāo)準(zhǔn)規(guī)范的統(tǒng)一，對于數(shù)據(jù)如何去使用、存儲、展示、告警，官方是不涉及的。

OpenTelemetry 狀態(tài)

OpenTelemetry 要解決的是對可觀測性的大一統(tǒng)，它提供了一組 API 和 SDK 來標(biāo)準(zhǔn)化遙測數(shù)據(jù)的采集和傳輸，opentelemetry 并不想對所有的組件都進(jìn)行重寫，而是最大程度復(fù)用目前業(yè)界在各大領(lǐng)域常用工具，通過提供了一個安全，廠商中立的能用協(xié)議、組件，這樣就可以按照需要形成 pipeline 將數(shù)據(jù)發(fā)往不同的后端。

由于 opentelemetry 提出時間并不長，大家可以從status^[4]中可以看到最新的狀態(tài)，可以看到，目前只有 Tracing 實現(xiàn)了 1.0 的 release，而 Metrics 處于feature-freeze^[5]，這個狀態(tài)說的是 metrics 目前暫不接受在 metrics 中添加新的功能，以便技術(shù)委員會優(yōu)先實現(xiàn)其它功能，還未達(dá)到 stable 狀態(tài)，而在 Logging 則還處于草案階段，opentelemetry 官方的解釋是日志相對存在體量大，延時高的問題，相對棘手且優(yōu)先級對比另兩者不高。

tracing 已經(jīng)在 2021 上半年實現(xiàn)了 stable,目前官方給出的時間線是在 2021 下半年實現(xiàn) metrics 的 stable，在 2022 實現(xiàn) logging 的 stable。

為什么 tracing 是首先 stable 的，作者個人感覺可能是 tracing 目前在業(yè)界普及度還不夠吧，而像 metrics 方面，prometheus 早已成了業(yè)務(wù)標(biāo)準(zhǔn)。

OpenTelemetry 架構(gòu)

這里作者還要重點說明的是，就算是 Service Mesh 中對于鏈路追蹤也普遍有一個問題: 就是無論你在數(shù)據(jù)平面如何做流量劫持，如何透傳信息，以及如何生成或者繼承 Span，入口流量和出口流量之間的鏈路都存在無法串聯(lián)的問題， 這個問題要解決還是需要服務(wù)來埋點透傳，將鏈路信息透傳到下一次請求當(dāng)中去，這個問題是無法避免的，而 OpenTelemetry 的后續(xù)推行，可以解決這方面的標(biāo)準(zhǔn)化問題。

來看一張圖:

注: 由于 logging 還處于草案狀態(tài)，這里沒有描述出來。

opentelemetry 也是個插件式的架構(gòu)，針對不同的開發(fā)語言會有相應(yīng)的 Client 組件，叫Instrumenttation，也就是在代碼中埋點調(diào)用的 api/sdk 采集 telemetry 數(shù)據(jù)。

將獲取到的數(shù)據(jù) pull/push 到上圖中定義好的pipeline中,這部分是可高度定制的, opentelemetry 提供統(tǒng)一的Specification^[6]。

pipeline就是Collection的實現(xiàn)，大概分為 3 部分，這里簡單介紹一下，后期在詳解 collection 的配置文件時再進(jìn)行展開:

• receivers(接收者): 定義從 client 端的數(shù)據(jù)要以何種數(shù)據(jù)模型進(jìn)行接收, 支持很多種數(shù)據(jù)模型.
• processors: 將 receivers 的數(shù)據(jù)進(jìn)行某些處理，比如批量、性能分析等.
• exporters: 將 processors 后的數(shù)據(jù)導(dǎo)出到特定的后端，比如 metrics 數(shù)據(jù)存儲到 prometheus 中.

整個流程是 pipeline 式的,可以根據(jù)實際情況自定義 pipeline,所以說 collector 定制性很高。

這里要說明的是 receivers、processors、exporters 有官方的定義opentelemetry-collector^[7]

但是也有很多開源產(chǎn)品基于 opentelemetry-collector 提供相應(yīng)的實現(xiàn),詳細(xì)列表參考opentelemetry-collector-contrib^[8]

總結(jié)一下，opentelemetry 按功能分層來說,可以分為：采集器（Instrument）、發(fā)送器（TransPort）、收集器（Collector）、存儲（Srotage）、展示（API&UI）,這跟其它 APM 系統(tǒng)是類似的，只是 opentelemetry 在很多組件上選擇了利用而不是重新造輪子。

在 opentelemetry 里面的名詞也是非常多的，有必要把一些常用的名詞給大家解釋一下。

建議大家多多閱讀官方文檔，也可參考[OpenTelemetry 規(guī)范閱讀](https://jckling.github.io/2021/04/02/Jaeger/OpenTelemetry 規(guī)范閱讀/ "OpenTelemetry 規(guī)范閱讀")，里面詳細(xì)介紹了各個名詞的含義，對大家理解有幫助。

OpenTelemetry 核心概念

以下名詞引用官方文檔components^[9]的翻譯。

Proto

語言無關(guān)的接口類型。描述很多下文組件的定義。

####Client

其實就是 client, 應(yīng)用調(diào)用 OpenTelemetry API 的 client, 語言相關(guān)的代碼封裝庫，引入 trace、metrics、log 等。

API/SDK

API 包由用于檢測的橫切公共接口組成，導(dǎo)入到第三方庫和應(yīng)用程序代碼的 OpenTelemetry 客戶端的任何部分都被認(rèn)為是 API 的一部分。

而 SDK 是 API 的具體實現(xiàn)，這部分是語言相關(guān)的。

Specification

Specification 則是定義了 API/SDK 及數(shù)據(jù)模型，所有包含第三方實現(xiàn)的都需要遵循 spec 定義的規(guī)范。

Semantic Conventions

OpenTelemetry 項目保證所有的 instrumentation(不論任何語言)都包含相同的語義信息。

Resource

resource 附加于某個 process 產(chǎn)生的所有 trace 的鍵值對，在初始化階段指定并傳遞到 collector 中。

Baggage

為添加在 metrics、log、traces 中的注解信息，鍵值對需要唯一，無法更改。

Propagators

傳播器，比如在多進(jìn)程的調(diào)用中，開啟傳播器用于跨服務(wù)傳播 spanContext。

Attributes

其實就是 tag, 可以給 span 添加 metadata 數(shù)據(jù),SetAttributes屬性可以多次添加，不存在就添加，存在就覆蓋。

Events

類似于日志, 比如在 trace 中嵌入請求體跟響應(yīng)體。

Collector

雖然 Collector 翻譯過來叫接收，但它負(fù)責(zé)遙測數(shù)據(jù)源的接收、處理和導(dǎo)出三部分，提供了與供應(yīng)商無關(guān)的實現(xiàn)。

collector 是個實體組件，有兩個部署方案，可以 ds 進(jìn)行部署，各個 host 負(fù)責(zé)該 host 上的遙測數(shù)據(jù)。

或者以 deployment 的方式部署，接收所有遙測數(shù)據(jù)。

其中，Metrics、Logging、Trace、Baggage 叫Signal,以上的對象中除了Collector,其它幾個由于沒有具體部署對象，名詞一多理解起來還是比較費勁，需要多翻官方文檔。

這里重點介紹 Collector，在介紹 Collector 前，先來介紹一個協(xié)議。

OpenTelemetry 協(xié)議-OTLP

OTLP(OpenTelemetry Protocol)^[10]是一種協(xié)議，該此協(xié)議用于將應(yīng)用產(chǎn)生的遙感數(shù)據(jù)發(fā)送到 OpenTelemetry Collector。

otlp 是 opentelemetry 中比較核心的存在，在遙測數(shù)據(jù)及 Collector 之間制定了包括編碼(encoding)、傳輸(transport)、傳遞(delivery)等協(xié)議。

目前 OTLP 協(xié)議在數(shù)據(jù)源的狀態(tài)也是不一樣的。

• Tracing: Stable
• Metrics: Stable
• Logs: Beta

otlp 也對 http、grpc 進(jìn)行了較好的開箱即用的封裝。

另外，OTEP(OpenTelemetry Enhancement Proposal)是加強版的 otlp, 目前處于不穩(wěn)定狀態(tài)，這里不展開。

參考文章:

• https://codingnote.cc/p/246692^[11]
• https://opentelemetry.io/registry^[12]
• https://opentelemetry.io/docs/concepts/components^[13]
• https://signoz.io/blog/opentelemetry-kubernetes^[14]
• https://www.infoq.cn/article/pky4szfhbvifxrcriqcr^[15]
• https://github.com/open-telemetry/opentelemetry-collector^[16]
• https://github.com/open-telemetry/opentelemetry-collector-contrib^[17]
• https://tech.ipalfish.com/blog/2020/12/29/design-dimensions-of-tracing-systems^[18]
• https://github.com/open-telemetry/opentelemetry-specification/tree/main/specification/protocol^[19]
• https://jckling.github.io/2021/04/02/Jaeger/OpenTelemetry%20%E8%A7%84%E8%8C%83%E9%98%85%E8%AF%BB^[20]

引用鏈接

你可能還喜歡

點擊下方圖片即可閱讀

云原生是一種信仰???

關(guān)注公眾號

后臺回復(fù)?k8s?獲取史上最方便快捷的 Kubernetes 高可用部署工具，只需一條命令，連 ssh 都不需要！