歷史發(fā)展

早在 OpenTelemetry 誕生之前可觀測性這個(gè)概念就一直存在了，我記得我最早接觸到這個(gè)概念是在 16 年當(dāng)時(shí)的公司所使用的一個(gè)產(chǎn)品：pinpoint

現(xiàn)如今這個(gè)項(xiàng)目依然比較活躍。

圖片

依然還記得當(dāng)時(shí)通過它可以直接看到項(xiàng)目調(diào)用的拓?fù)鋱D，在時(shí)間坐標(biāo)上框出高延遲的點(diǎn)就能列出這些請求，同時(shí)還能查看此時(shí)的運(yùn)行日志。

這樣強(qiáng)大的功能對于一個(gè)剛工作一年的小白來說沖擊力實(shí)屬太大了一點(diǎn)。

后來才了解到 pinpoint 屬于 APM 這類產(chǎn)品，類似的產(chǎn)品還有：

• Apache SkyWalking
• 美團(tuán)的 CAT 等

他們都是可以用于性能分析和鏈路追蹤的產(chǎn)品，到后來公司的運(yùn)維層面也接入過 Zabbix、open-falcon 之類的產(chǎn)品：

圖片

17之后全面切換到 spring boot 時(shí)，也用過社區(qū)提供的 spring-boot-admin 項(xiàng)目：

圖片

這就是一個(gè)簡單的可以監(jiān)控 spring boot 應(yīng)用的產(chǎn)品，用于展示 JVM 指標(biāo)，或者自己也可以定義一些健康指標(biāo)。

再之后進(jìn)入云原生體系后可觀測性的技術(shù)棧稍有變化。

圖片

日志使用 Sidecar 代理的方式通過 Agent 將數(shù)據(jù)寫入 ElasticSearch 中。 具體日志采集方式可以參考之前的文章：

• 在 kubernetes 環(huán)境下如何采集日志

而鏈路追蹤則是使用的 skywalking，在 trace 這個(gè)領(lǐng)域 skywalking 還是非常受大家喜愛的。

不過最近也從 skywalking 切換到了我們本文所講到的 OpenTelemetry，具體可以看之前的文章：

• 實(shí)戰(zhàn)：如何優(yōu)雅的從 Skywalking 切換到 OpenTelemetry

指標(biāo)采集使用的是自然也是 Prometheus 的那一套技術(shù)棧，只是 Prometheus 換為了與它完全兼容的 VictoriaMetric 目前是為了更省資源。

客戶端使用則是直接使用 Prometheus 的庫進(jìn)行指標(biāo)暴露：

<dependency>
    <groupId>io.prometheus</groupId>
    <artifactId>prometheus-metrics-core</artifactId>
    <version>1.0.0</version>
</dependency>
<dependency>
    <groupId>io.prometheus</groupId>
    <artifactId>prometheus-metrics-instrumentation-jvm</artifactId>
    <version>1.0.0</version>
</dependency>
<dependency>
    <groupId>io.prometheus</groupId>
    <artifactId>prometheus-metrics-exporter-httpserver</artifactId>
    <version>1.0.0</version>
</dependency>

最終通過配置抓取策略，由 VictoriaMetrics 的 scrape 程序來抓取指標(biāo)最終寫入到它自己的存儲中：

apiVersion: operator.victoriametrics.com/v1beta1  
kind: VMPodScrape  
metadata:  
  name: kubernetes-pod-scrape  
  namespace: monitoring  
spec:  
  podMetricsEndpoints:  
    - scheme: http  
      scrape_interval: "30s"  
      path: /metrics  
      relabelConfigs:  
        - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]  
          separator: ;  
          regex: "true"  
          replacement: $1  
          action: keep  
        # 端口相同  
        - action: keep_if_equal  
          source_labels: [ __meta_kubernetes_pod_annotation_prometheus_io_port, __meta_kubernetes_pod_container_port_number ]  
        # 過濾INIT容器  
        - action: drop  
          source_labels: [ __meta_kubernetes_pod_container_init ]  
          regex: "true"  
        - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]  
          separator: ;  
          regex: (.+)  
          target_label: __metrics_path__  
          replacement: $1  
          action: replace  
        - source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]  
          separator: ;  
          regex: ([^:]+)(?::\d+)?;(\d+)  
          target_label: __address__  
          replacement: $1:$2  
          action: replace  
        - separator: ;  
          regex: __meta_kubernetes_pod_label_(.+)  
          replacement: $1  
          action: labelmap  
        - source_labels: [__meta_kubernetes_namespace]  
          separator: ;  
          regex: (.*)  
          target_label: kubernetes_namespace  
          replacement: $1  
          action: replace  
        - source_labels: [__meta_kubernetes_pod_name]  
          separator: ;  
          regex: (.*)  
          target_label: kubernetes_pod_name  
          replacement: $1  
          action: replace  
      vm_scrape_params:  
        stream_parse: true  
  namespaceSelector:  
    any: true

以上是 VM 提供的 CRD

OpenTelemetry 誕生

到此鋪墊完成，不知道有沒有發(fā)現(xiàn)在可觀測性中關(guān)鍵的三個(gè)部分：日志、指標(biāo)、trace 都是使用不同的開源產(chǎn)品，從而會導(dǎo)致技術(shù)棧較多，維護(hù)起來自然也是比較麻煩的。

這么一個(gè)軟件領(lǐng)域的核心能力自然需要提供一個(gè)完整方案的，將以上的不同技術(shù)棧都整合在一起，更加的方便開發(fā)者使用。

在這之前也有兩個(gè)社區(qū)想要做類似的事情：

• OpenTracing
• OpenCensus

不過他們并沒有統(tǒng)一整個(gè)可觀測領(lǐng)域，直到 2019 年 CNCF 社區(qū)宣布成立 OpenTelemetry，并且將上述兩個(gè)社區(qū)進(jìn)行合并共同開發(fā) OpenTelemetry。

背靠 CNCF 云原生社區(qū)加上許多知名廠商的支持（Google、Amazon、Redhat 等），現(xiàn)在已經(jīng)正式成為 CNCF 的頂級項(xiàng)目了。

OpenTelemetry 架構(gòu)介紹

圖片

但我們打開 OpenTelemetry 社區(qū)的 GitHub 首頁時(shí)，會看到有許多項(xiàng)目；第一反應(yīng)應(yīng)該是比較蒙的，下面我會著重介紹一些比較重要的項(xiàng)目。

在開始之前還是先簡單介紹下 OpenTelemetry 的一些基礎(chǔ)組件和概念：

圖片

整個(gè) OpenTelemetry 系統(tǒng)其實(shí)可以簡單分為三個(gè)部分：

• 客戶端
• OTel collector
• 數(shù)據(jù)存儲

第一個(gè)客戶端很好理解，也就是我們的業(yè)務(wù)應(yīng)用；如果是 Java 應(yīng)用只需要掛載一個(gè) agent 就可以自動(dòng)采集系統(tǒng)的指標(biāo)、鏈路信息、日志等上傳到 Collector 中。

也就是上圖的左邊部分。

之后就是非常關(guān)鍵的組件 collector，它可以通過 OTLP 協(xié)議接收剛才提到的客戶端上傳的數(shù)據(jù)，然后再內(nèi)部進(jìn)行處理，最終輸出到后續(xù)的存儲系統(tǒng)中。

Collector

collector 的架構(gòu)圖

由于 OpenTelemetry 設(shè)計(jì)之初就是要做到廠商無關(guān)，所以它就得做出更高層級的設(shè)計(jì)。

關(guān)鍵點(diǎn)就是這里的 Receiver 和 Exporter 都是模塊化的設(shè)計(jì)，第三方開發(fā)者可以基于它的標(biāo)準(zhǔn)開發(fā)不同組件從而兼容不同的產(chǎn)品。

Receiver：用于接收客戶端上報(bào)的數(shù)據(jù)，不止是自己 agent 上報(bào)的數(shù)據(jù)，也可能會來自不同的廠商，比如 kubernetes、Kafka 等。

Exporter：同理，可以將 receiver 收到的數(shù)據(jù)進(jìn)行處理之后輸出到不同的組件中；比如 Kafka/Pulsar/Promethus/Jaeger 等。

比如我們可以使用 Nginx Receiver接收來著 Nginx 上報(bào)的數(shù)據(jù)。

使用 MySQL Receiver接收來自 MySQL 的數(shù)據(jù)。

當(dāng)然通常我們使用最多的還是 OTLP Receiver，這是官方的 OTLP 協(xié)議的接收器，可以接受官方的一些指標(biāo)，比如我們只使用了 Java Agent 進(jìn)行數(shù)據(jù)上報(bào)時(shí)。

圖片

https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver

在這里是可以看到目前支持的所有第三方的 Receiver。

圖片

OpenTelemetry 所支持的 Exporter 也很多，比如一些常見的存儲：

• clickhouse exporter
• elasticsearch exporter
• pulsar exporter
• prometheus exporter
• otlp http exporter

Exporter 的使用場景很多：如果是指標(biāo)相關(guān)的數(shù)據(jù)可以直接寫入 Prometheus，如果是日志數(shù)據(jù)也可以直接寫入 ElasticSearch。

如果還有其他的特殊需求（刪減屬性等）則可以寫入消息隊(duì)列，自行處理完之后再發(fā)往 collector 進(jìn)行后續(xù)的處理。

可能你已經(jīng)發(fā)現(xiàn)了，由于 collector 非常的靈活，所以我們可以像搭積木一樣組裝我們的 receiver 和 exporter，它會以我們配置的流水線的方式進(jìn)行調(diào)用，這樣我們就可以實(shí)現(xiàn)任意可定制的處理邏輯。

而這些流水線的組裝對于客戶端來說都是透明的，也就是說 collector 的更改完全不會影響到業(yè)務(wù)；業(yè)務(wù)只需要按照 OTLP 的格式上報(bào)數(shù)據(jù)即可。

在之前的從 Skywalking 切換到 OpenTelemetry 的文章中有人問為什么要切換到 OpenTelemetry？

從這里也能看得出來，OpenTelemetry 的靈活度非常高，借助于 Exporter 可以任意的更換后端存儲，或者增加/刪減一些不需要的指標(biāo)數(shù)據(jù)等。

當(dāng)然我們也可以統(tǒng)一的在這里進(jìn)行搜索，可以列出所有的第三方集成的組件： https://opentelemetry.io/ecosystem/registry/。

圖片

OpenTelemetry 項(xiàng)目介紹

opentelemetry-java

介紹完基本的概念后，我們可以看看  OTel 社區(qū)的一些主要開源項(xiàng)目。

圖片

這里我們還是以剛才的那個(gè)架構(gòu)圖從作往右講起，也就是主要分為客戶端和 collector 端。

圖片

目前官方支持的客戶端語言已經(jīng)非常齊全了，大部分的版本都已經(jīng)是 Stable 穩(wěn)定版，意味著可以進(jìn)入生產(chǎn)環(huán)境。

這里我們以 Java 客戶端為例：

圖片

其中我們重點(diǎn)關(guān)注下 opentelemetry-java 和 opentelemetry-java-instrumentation 這兩個(gè)項(xiàng)目。

我們用的最多的會是 opentelemetry-java-instrumentation，它會給我們提供一個(gè) java agent 的 JAR 包：

java -javaagent:path/to/opentelemetry-javaagent.jar \
     -jar myapp.jar

我們只需要在 Java 應(yīng)用中加上該  agent 就可以實(shí)現(xiàn)日志、指標(biāo)、trace 的自動(dòng)上報(bào)。

而且它還實(shí)現(xiàn)了不同框架、庫的指標(biāo)采集與 trace。

在這里可以查到支持的庫與框架列表：

圖片

https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/docs/supported-libraries.md#libraries--frameworks

總之幾乎就是你能想到和不能想到的都支持了。

而 opentelemetry-java 我們直接使用的幾率會小一些，opentelemetry-java-instrumentation 本身也是基于它創(chuàng)建的，可以理解為是 Java 版本的核心基礎(chǔ)庫，一些社區(qū)支持的組件就可以移動(dòng)到 instrumentation 這個(gè)庫中。

比如我在上篇文章：從一個(gè) JDK21+OpenTelemetry 不兼容的問題講起中涉及到的 HostResourceProvider 資源加載就是從 opentelemetry-java 中移動(dòng)到了 opentelemetry-java-instrumentation。

具體可以參考：https://github.com/open-telemetry/opentelemetry-java/issues/4701

collector

之后就是 collector 的組件了，它同樣的也有兩個(gè)庫：OpenTelemetry Collector 和 OpenTelemetry Collector Contrib

其實(shí)通過他們的名字也可以看得出來，他們的作用與剛才的 Java 庫類似：

• opentelemetry-collector：由官方社區(qū)維護(hù)，提供了一些核心能力；比如只包含了最基本的 otlp 的 receiver 和 exporter。
• opentelemetry-collector-contrib：包含了官方的 collector，同時(shí)更多的維護(hù)了社區(qū)提供的各種 receiver 和 exporter；就如上文提到的，一些社區(qū)組件（pulsar、MySQL、Kafka）等都維護(hù)在這個(gè)倉庫。

而我們生產(chǎn)使用時(shí)通常也是直接使用 opentelemetry-collector-contrib，畢竟它所支持的社區(qū)組件更多。

總結(jié)

因?yàn)?OpenTelemetry 想要解決的是整個(gè)可觀測領(lǐng)域的所有需求，所以倉庫非常多，社區(qū)也很開放，感興趣的朋友可以直接參與貢獻(xiàn)，這么多 repo 總有一個(gè)適合你的。

后續(xù)會繼續(xù)講解如何安裝以及配置我們的 OpenTelemetry。

參考鏈接：

• https://github.com/pinpoint-apm/pinpoint
• https://github.com/codecentric/spring-boot-admin
• https://github.com/open-telemetry/opentelemetry-java
• https://github.com/open-telemetry/opentelemetry-java-instrumentation
• https://github.com/open-telemetry/opentelemetry-java/issues/4701