這篇文章旨在讓您對 OpenTelemetry 有基本的了解。將涵蓋的主題有：

• 分布式追蹤
• OpenTelemetry 是什么？
• OpenTelemetry 檢測（自動(dòng)和手動(dòng)）
• OpenTelemetry 協(xié)議（OTLP）
• OpenTelemetry Collectors
• OpenTelemetry Collectors 部署模式
• OpenTelemetry 后端
• OpenTelemetry on Kubernetes
• OpenTelemetry Operator
• OpenTelemetry 示例應(yīng)用程序

在本文結(jié)束時(shí)，您將了解如何使用 OpenTelemetry Operator 在應(yīng)用程序中實(shí)現(xiàn)跟蹤，而無需更改任何代碼。

分布式追蹤

讓我們首先了解一下什么是分布式跟蹤以及我們?yōu)槭裁葱枰?/p>

為什么我們需要追蹤？

我們需要為什么分布式追蹤？為什么我們不能只使用指標(biāo)和日志呢？假設(shè)你有一個(gè)如下所示的微服務(wù)架構(gòu)。

現(xiàn)在想象一下來自客戶端的請求。

從上面的架構(gòu)圖中我們可以看出，一個(gè)請求可能要經(jīng)過幾十個(gè)或幾百個(gè)網(wǎng)絡(luò)調(diào)用。這使得我們很難知道請求所經(jīng)過的整個(gè)路徑，如果只有日志和指標(biāo)，那么故障排查會(huì)非常復(fù)雜。

當(dāng)我們的應(yīng)用出現(xiàn)問題時(shí)，我們需要解決很多問題。

• 我們?nèi)绾握页龈驹颍?/li>
• 我們?nèi)绾伪O(jiān)視它所經(jīng)過的所有服務(wù)？

分布式跟蹤可以幫助查看整個(gè)請求過程中服務(wù)之間的交互，并可以讓我們深入了解系統(tǒng)中請求的整個(gè)生命周期。它幫助我們發(fā)現(xiàn)應(yīng)用程序中的錯(cuò)誤、瓶頸和性能問題。

追蹤從用戶與應(yīng)用程序進(jìn)行交互的一刻開始，我們應(yīng)該能夠看到整個(gè)請求直到最后一層。

跟蹤數(shù)據(jù)（以 span 的形式）生成信息（元數(shù)據(jù)），可以幫助了解請求延遲或錯(cuò)誤是如何發(fā)生的，以及它們對整個(gè)請求會(huì)產(chǎn)生什么樣的影響。

如果你想了解有關(guān)分布式跟蹤的更多信息，請閱讀分布式跟蹤初學(xué)者指南，了解如何監(jiān)控微服務(wù)架構(gòu)。

如何實(shí)現(xiàn)追蹤？

為了實(shí)現(xiàn)追蹤，我們需要做以下幾件事：

• 檢測我們的應(yīng)用程序。
• 收集和處理數(shù)據(jù)。
• 存儲(chǔ)和可視化數(shù)據(jù)，以便我們可以查詢它。

為此我們可以使用兩個(gè)開源項(xiàng)目：OpenTelemetry 和 Jaeger。

OpenTelemetry 是什么？

OpenTelemetry 可以用于從應(yīng)用程序收集數(shù)據(jù)。它是一組工具、API 和 SDK 集合，我們可以使用它們來檢測、生成、收集和導(dǎo)出遙測數(shù)據(jù)（指標(biāo)、日志和追蹤），以幫助分析應(yīng)用的性能和行為。

OpenTelemetry 是：

• 開源的
• 受到可觀測領(lǐng)域行業(yè)領(lǐng)導(dǎo)者的采用和支持
• 一個(gè) CNCF 項(xiàng)目
• 與供應(yīng)商無關(guān)的

OpenTelemetry 包括可觀測性的三個(gè)支柱：追蹤、指標(biāo)和日志。（本文將重點(diǎn)關(guān)注追蹤）

• 分布式追蹤是一種跟蹤服務(wù)請求在分布式系統(tǒng)中從開始到結(jié)束的方法。
• 指標(biāo)是對一段時(shí)間內(nèi)活動(dòng)的測量，以便了解系統(tǒng)或應(yīng)用程序的性能。
• 日志是系統(tǒng)或應(yīng)用程序在特定時(shí)間點(diǎn)發(fā)生的事件的文本記錄。

OpenTelemetry 與供應(yīng)商無關(guān)

OpenTelemetry 提供了一個(gè)與供應(yīng)商無關(guān)的可觀測性標(biāo)準(zhǔn)，因?yàn)樗荚跇?biāo)準(zhǔn)化跟蹤的生成。通過 OpenTelemetry，我們可以將檢測埋點(diǎn)與后端分離。這意味著我們不依賴于任何工具（或供應(yīng)商）。

我們不僅可以使用任何我們想要的編程語言，還可以挑選任何兼容的存儲(chǔ)后端，從而避免被綁定在特定的商業(yè)供應(yīng)商上面。

開發(fā)人員可以檢測他們的應(yīng)用程序，而無需知道數(shù)據(jù)將存儲(chǔ)在哪里。

OpenTelemetry 為我們提供了創(chuàng)建跟蹤數(shù)據(jù)的工具，為了獲取這些數(shù)據(jù)，我們首先需要檢測應(yīng)用程序來收集數(shù)據(jù)。為此，我們需要使用 OpenTelemetry SDK。

檢測（埋點(diǎn)）

應(yīng)用程序的檢測數(shù)據(jù)可以使用自動(dòng)或手動(dòng)（或混合）方式生成。 要使用 OpenTelemetry 檢測應(yīng)用程序，可以前往訪問 OpenTelemetry 存儲(chǔ)庫，選擇適用于的應(yīng)用程序的語言，然后按照說明進(jìn)行操作。

自動(dòng)檢測

使用自動(dòng)檢測是一個(gè)很好的方式，因?yàn)樗唵?、容易，不需要進(jìn)行很多代碼更改。

如果你沒有必要的知識(shí)（或時(shí)間）來創(chuàng)建適合你應(yīng)用程序量身的追蹤代碼，那么這種方法就非常合適。

當(dāng)使用自動(dòng)檢測時(shí)，將創(chuàng)建一組預(yù)定義的 spans，并填充相關(guān)屬性。

手動(dòng)檢測

手動(dòng)檢測是指為應(yīng)用程序編寫特定的埋點(diǎn)代碼。這是向應(yīng)用程序添加可觀測性代碼的過程。這樣做可以更有效地滿足你的需求，因?yàn)榭梢宰约禾砑訉傩院褪录?。這樣做的缺點(diǎn)是需要導(dǎo)入庫并自己完成所有工作。

傳播器

可以將 W3C tracecontext、baggage 和b3 等傳播器（Propagators）添加到配置中。

不同的傳播器定義特定的行為規(guī)范，以便跨進(jìn)程邊界傳播帶上上下文數(shù)據(jù)。

• Trace Context：用于在 HTTP headers 中編碼 trace 數(shù)據(jù)，以便在不同的服務(wù)間傳遞這些數(shù)據(jù)。
• Baggage：用于在 span 之間傳遞鍵值對數(shù)據(jù)，例如用戶 ID、請求 ID 等。
• B3：用于在 HTTP headers 中編碼 trace 數(shù)據(jù)，以便在不同的服務(wù)間傳遞這些數(shù)據(jù)（主要用于 Zipkin 或其兼容的系統(tǒng)）。

采樣

采樣是一種通過減少收集和發(fā)送到后端的追蹤樣本數(shù)量來控制 OpenTelemetry 引入的噪聲和開銷的機(jī)制。

可以告訴 OpenTelemetry 根據(jù)要發(fā)送的追蹤/流量的數(shù)量執(zhí)行采樣。（比如只采樣 10% 的追蹤數(shù)據(jù)）。

兩種常見的采樣技術(shù)是頭采樣和尾采樣。

OpenTelemetry 協(xié)議（OTLP）

OpenTelemetry 協(xié)議（OTLP）規(guī)范描述了遙測數(shù)據(jù)在遙測源、收集器和遙測后端之間的編碼、傳輸和傳遞機(jī)制。

每種語言的 SDK 都提供了一個(gè) OTLP 導(dǎo)出器，可以配置該導(dǎo)出器來通過 OTLP 導(dǎo)出數(shù)據(jù)。然后，OpenTelemetry SDK 會(huì)將事件轉(zhuǎn)換為 OTLP 數(shù)據(jù)。

OTLP 是代理（配置為導(dǎo)出器）和收集器（配置為接收器）之間的通信。

OpenTelemetry Collectors

應(yīng)用程序的遙測數(shù)據(jù)可以發(fā)送到 OpenTelemetry Collectors 收集器。

收集器是 OpenTelemetry 的一個(gè)組件，它接收遙測數(shù)據(jù)（span、metrics、logs 等），處理（預(yù)處理數(shù)據(jù)）并導(dǎo)出數(shù)據(jù)（將其發(fā)送到想要的通信后端）。

Receivers

接收器 Receivers 是數(shù)據(jù)進(jìn)入收集器的方式，可以是推送或拉取。OpenTelemetry 收集器可以以多種格式接收遙測數(shù)據(jù)。

以下是接收器在端口 4317(gRPC) 和 4318(http) 上接受 OTLP 數(shù)據(jù)的配置示例：

otlp:
  protocols:
    http:
    grpc:
      endpoint: "0.0.0.0:4317"

同樣下面的示例，它可以以 Jaeger Thrift HTTP 協(xié)議方式接收遙測數(shù)據(jù)。

jaeger: # Jaeger 協(xié)議接收器
  protocols: # 定義接收器支持的協(xié)議
    thrift_http: # 通過 Jaeger Thrift HTTP 協(xié)議接收數(shù)據(jù)
      endpoint: "0.0.0.0:14278"

Processors

一旦接收到數(shù)據(jù)，收集器就可以處理數(shù)據(jù)。處理器在接收和導(dǎo)出之間處理數(shù)據(jù)。處理器是可選的，但有些是推薦的。

比如 batch 處理器是非常推薦的。批處理器接收跨度、指標(biāo)或日志，并將它們放入批次中。批處理有助于更好地壓縮數(shù)據(jù)，減少傳輸數(shù)據(jù)所需的傳出連接數(shù)量。該處理器支持基于大小和時(shí)間的批處理。

processors:
  batch:

需要注意的是配置處理器并不會(huì)啟用它。需要通過 service 部分的 pipelines 啟用。

service:
  pipelines:
    traces:
      receivers: [jaeger]
      processors: [batch]
      exporters: [zipkin]

Exporters

為了可視化和分析遙測數(shù)據(jù)，我們還需要使用導(dǎo)出器。導(dǎo)出器是 OpenTelemetry 的一個(gè)組件，也是數(shù)據(jù)發(fā)送到不同系統(tǒng)/后端的方式。

比如 console exporter 是一種常見的導(dǎo)出器，對于開發(fā)和調(diào)試任務(wù)非常有用，他會(huì)將數(shù)據(jù)打印到控制臺(tái)。

在 exporters 部分，可以添加更多目的地。例如，如果想將追蹤數(shù)據(jù)發(fā)送到 Grafana Tempo，只需添加如下所示的配置：

exporters:
  logging:
  otlp:
    endpoint: "<tempo_endpoint>"
    headers:
      authorization: Basic <api_token>

當(dāng)然最終要生效也需要在 service 部分的 pipelines 中啟用。

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: []
      exporters: [logging, otlp]

OpenTelemetry 附帶了各種導(dǎo)出器，在 OpenTelemetry 收集器 Contrib 存儲(chǔ)庫中可以找到。

Extensions

擴(kuò)展主要適用于不涉及處理遙測數(shù)據(jù)的任務(wù)。擴(kuò)展的示例包括健康監(jiān)控、服務(wù)發(fā)現(xiàn)和數(shù)據(jù)轉(zhuǎn)發(fā)。擴(kuò)展是可選的。

擴(kuò)展主要用于不涉及處理遙測數(shù)據(jù)的任務(wù)。比如健康監(jiān)控、服務(wù)發(fā)現(xiàn)和數(shù)據(jù)轉(zhuǎn)發(fā)等。擴(kuò)展是可選的。

extensions:
  health_check:
  pprof:
  zpages:
  memory_ballast:
    size_mib: 512

OpenTelemetry Collector 部署模式/策略

OpenTelemetry 收集器可以通過不同的方式進(jìn)行部署，所以我們要考慮下如何部署它。具體選擇哪種策略取決于你的團(tuán)隊(duì)和組織情況。

Agent 模式

在這種情況下，OpenTelemetry 檢測的應(yīng)用程序?qū)?shù)據(jù)發(fā)送到與應(yīng)用程序一起駐留的（收集器）代理。然后，該代理程序?qū)⒔庸懿⑻幚硭衼碜詰?yīng)用程序的追蹤數(shù)據(jù)。

收集器可以通過 sidecar 方式部署為代理，sidecar 可以配置為直接將數(shù)據(jù)發(fā)送到存儲(chǔ)后端。

Gateway 模式

還可以決定將數(shù)據(jù)發(fā)送到另一個(gè) OpenTelemetry 收集器，然后從（中心）收集器進(jìn)一步將數(shù)據(jù)發(fā)送到存儲(chǔ)后端。在這種配置中，我們有一個(gè)中心的 OpenTelemetry 收集器，它使用 deployment 模式部署，具有許多優(yōu)勢，如自動(dòng)擴(kuò)展。

使用中心收集器的一些優(yōu)點(diǎn)是：

• 消除對團(tuán)隊(duì)的依賴
• 強(qiáng)制執(zhí)行批處理、重試、加密、壓縮的配置/策略
• 在中心位置進(jìn)行身份驗(yàn)證
• 豐富的元數(shù)據(jù)信息
• 進(jìn)行抽樣決策
• 通過 HPA 進(jìn)行擴(kuò)展

部署模式總結(jié)

下面我們總結(jié)下常見的一些部署策略。

基本版 - 客戶端使用 OTLP 進(jìn)行檢測，將數(shù)據(jù)發(fā)送到一組收集器。

可以將數(shù)據(jù)發(fā)送到多個(gè)導(dǎo)出器。

在 Kubernetes 上部署 OpenTelemetry Collector 時(shí)可以使用的模式。

sidecar 模式：

代理作為 sidecar，其中使用 OpenTelemetry Collector 將容器添加到工作負(fù)載 Pod。然后，該實(shí)例被配置為將數(shù)據(jù)發(fā)送到可能位于不同命名空間或集群中的外部收集器。

daemonset 模式：

Agent 作為 DaemonSet，這樣我們每個(gè) Kubernetes 節(jié)點(diǎn)就有一個(gè)代理 pod。

負(fù)載均衡 - 基于 trace id 的負(fù)載均衡：

多集群 - 代理、工作負(fù)載和控制平面收集器：

多租戶模式

兩個(gè)租戶，每個(gè)租戶都有自己的 Jaeger。

信號(hào)模式

兩個(gè)收集器，每個(gè)收集器對應(yīng)一種遙測數(shù)據(jù)類型。

OpenTelemetry 后端

OpenTelemetry 收集器并不提供自己的后端，所以可以使用任何供應(yīng)商或開源產(chǎn)品！

盡管 OpenTelemetry 不提供自己的后端，但通過使用它，我們不會(huì)依賴于任何工具或供應(yīng)商，因?yàn)樗c供應(yīng)商無關(guān)。我們不僅可以使用我們想要的任何編程語言，而且還可以選擇存儲(chǔ)后端，并且只需配置另一個(gè)導(dǎo)出器即可輕松切換到另一個(gè)后端/供應(yīng)商。

為了可視化和分析遙測數(shù)據(jù)，我們只需要在 OpenTelemetry 采集器種配置一個(gè)導(dǎo)出器。

比如 Jaeger 就是一個(gè)非常流行的用于分析和查詢數(shù)據(jù)的開源產(chǎn)品。

我們可以在 OpenTelemetry 收集器中配置 Jaeger 導(dǎo)出器，以便將數(shù)據(jù)發(fā)送到 Jaeger。

exporters:
  jaeger:
    endpoint: "http://localhost:14250"

OpenTelemetry on Kubernetes

在 Kubernetes 上使用 OpenTelemetry，主要就是部署 OpenTelemetry 收集器。我們建議使用 OpenTelemetry Operator 來部署，因?yàn)樗梢詭椭覀冚p松部署和管理 OpenTelemetry 收集器，還可以自動(dòng)檢測應(yīng)用程序。

部署

這里我們使用 Helm Chart 來部署 OpenTelemetry Operator，首先添加 Helm Chart 倉庫：

$ helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
$ helm repo update

默認(rèn)情況下會(huì)部署一個(gè)準(zhǔn)入控制器，用于驗(yàn)證 OpenTelemetry Operator 的配置是否正確，為了使 APIServer 能夠與 Webhook 組件進(jìn)行通信，Webhook 需要一個(gè)由 APIServer 配置為可信任的 TLS 證書。

為了簡單我們這里直接使用自動(dòng)生成簽名證書的方式，使用下面的命令一鍵安裝 OpenTelemetry Operator：

$ helm upgrade --install --set admissionWebhooks.certManager.enabled=false --set admissionWebhooks.certManager.autoGenerateCert=true opentelemetry-operator open-telemetry/opentelemetry-operator --namespace kube-otel --create-namespace

正常部署完成后可以看到對應(yīng)的 Pod 已經(jīng)正常運(yùn)行：

$ kubectl get pods -n kube-otel -l app.kubernetes.io/name=opentelemetry-operator
NAME                                      READY   STATUS    RESTARTS   AGE
opentelemetry-operator-6f77dc895c-4wn8z   2/2     Running   0          33s

此外還會(huì)自動(dòng)為我們添加兩個(gè) OpenTelemetry 相關(guān)的 CRD：

$ kubectl get crd |grep opentelemetry
instrumentations.opentelemetry.io           2023-09-05T03:23:28Z
opentelemetrycollectors.opentelemetry.io    2023-09-05T03:23:28Z

到這里 OpenTelemetry Operator 就部署完成了。

然后我們這里選擇使用中心 OpenTelemetry 收集器，并讓其他 OpenTelemetry 代理將數(shù)據(jù)發(fā)送到該收集器。從代理接收的數(shù)據(jù)將在此收集器上進(jìn)行處理，并通過導(dǎo)出器發(fā)送到存儲(chǔ)后端。整個(gè)工作流如下圖所示：

創(chuàng)建一個(gè)如下所示的 OpenTelemetryCollector 實(shí)例對象：

# central-collector.yaml
apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
  name: simplest
spec:
  config: |
    receivers:
      otlp:
        protocols:
          grpc:
          http:
    processors:
      memory_limiter:
        check_interval: 1s
        limit_percentage: 75
        spike_limit_percentage: 15
      batch:
        send_batch_size: 10000
        timeout: 10s

    exporters:
      logging:
      otlp:
        endpoint: "<tempo_endpoint>"
        headers:
          authorization: Basic <api_token> # echo -n "<your user id>:<your api key>" | base64

    service:
      pipelines:
        traces:
          receivers: [otlp]
          processors: [memory_limiter, batch]
          exporters: [logging, otlp]

在這里 OpenTelemetry Collector 通過 grpc 和 http 兩種協(xié)議來接收遙測數(shù)據(jù)，并通過日志記錄導(dǎo)出和 Grafana Tempo 來記錄這些 Span，這會(huì)將 Span 寫入接收 Span 的 OpenTelemetry Collector 實(shí)例的控制臺(tái)和 Grafana Tempo 后端去。

然后我們將使用 Sidecar 模式部署 OpenTelemetry 代理。該代理會(huì)將應(yīng)用程序的追蹤發(fā)送到我們的中心（網(wǎng)關(guān)）OpenTelemetry 收集器。

# sidecar.yaml
apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
  name: sidecar
spec:
  mode: sidecar
  config: |
    receivers:
      otlp:
        protocols:
          grpc:
          http:
    processors:
      batch:
    exporters:
      logging:
      otlp:
        endpoint: "<path_to_central_collector>.<namespace>:4317"
    service:
      telemetry:
        logs:
          level: "debug"
      pipelines:
        traces:
          receivers: [otlp]
          processors: []
          exporters: [logging, otlp]

自動(dòng)檢測

OpenTelemetry Operator 可以注入和配置 OpenTelemetry 自動(dòng)檢測庫。目前支持 DotNet、Java、NodeJS、Python 和 Golang（需要手動(dòng)開啟）。

要使用自動(dòng)檢測，需要為 SDK 和檢測配置添加一個(gè) Instrumentation 資源。比如對于 Java 應(yīng)用程序，配置如下。

apiVersion: opentelemetry.io/v1alpha1
kind: Instrumentation
metadata:
  name: java-instrumentation
spec:
  propagators:
    - tracecontext
    - baggage
    - b3
  sampler:
    type: always_on
  java:

如果是 Python 應(yīng)用程序，配置如下：

apiVersion: opentelemetry.io/v1alpha1
kind: Instrumentation
metadata:
  name: python-instrumentation
spec:
  propagators:
    - tracecontext
    - baggage
    - b3
  sampler:
    type: always_on
  python:

要啟用檢測，我們需要更新部署文件并向其添加注解。通過這種方式，我們告訴 OpenTelemetry Operator 將 sidecar 和 java 工具注入到我們的應(yīng)用程序中。

annotations:
  instrumentation.opentelemetry.io/inject-java: "true"
  sidecar.opentelemetry.io/inject: "true"

示例應(yīng)用

這里我們將使用一個(gè)名為 Petclinic 的 Java 應(yīng)用程序，這是一個(gè)使用 Maven 或 Gradle 構(gòu)建的 Spring Boot 應(yīng)用程序。該應(yīng)用程序?qū)⑹褂?OpenTelemetry 生成數(shù)據(jù)。

對于 Java 應(yīng)用，我們可以通過下載 OpenTelemetry 提供的 opentelemetry-javaagent 這個(gè) jar 包來使用 OpenTelemetry 自動(dòng)檢測應(yīng)用程序。

只需要將這個(gè) jar 包添加到應(yīng)用程序的啟動(dòng)命令中即可，比如：

java -javaagent:opentelemetry-javaagent.jar -jar target/*.jar

Java 自動(dòng)檢測使用可附加到任何 Java 8+ 應(yīng)用程序的 Java 代理 JAR。它動(dòng)態(tài)注入字節(jié)碼以從許多流行的庫和框架捕獲遙測數(shù)據(jù)。它可用于捕獲應(yīng)用程序或服務(wù)“邊緣”的遙測數(shù)據(jù)，例如入站請求、出站 HTTP 調(diào)用、數(shù)據(jù)庫調(diào)用等。通過運(yùn)行以上命令，我們可以對應(yīng)用程序進(jìn)行插樁，并生成鏈路數(shù)據(jù)，而對我們的應(yīng)用程序沒有任何修改。

尤其是在 Kubernetes 環(huán)境中，我們可以使用 OpenTelemetry Operator 來注入和配置 OpenTelemetry 自動(dòng)檢測庫，這樣連 javaagent 我們都不需要去手動(dòng)注入了。

我們首先部署 Petclinic 應(yīng)用程序。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: petclinic
spec:
  selector:
    matchLabels:
      app: petclinic
  template:
    metadata:
      labels:
        app: petclinic
    spec:
      containers:
        - name: app
          image: cnych/spring-petclinic:latest

然后我們?yōu)?Java 應(yīng)用程序添加一個(gè) Instrumentation 資源。

# java-instrumentation.yaml
apiVersion: opentelemetry.io/v1alpha1
kind: Instrumentation
metadata:
  name: java-instrumentation
spec:
  propagators:
    - tracecontext
    - baggage
    - b3
  sampler:
    type: always_on
  java:
    image: ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-java:latest

為了啟用自動(dòng)檢測，我們需要更新部署文件并向其添加注解。這樣我們可以告訴 OpenTelemetry Operator 將 sidecar 和 java-instrumentation 注入到我們的應(yīng)用程序中。修改 Deployment 配置如下：

# petclinic.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: petclinic
spec:
  selector:
    matchLabels:
      app: petclinic
  template:
    metadata:
      labels:
        app: petclinic
      annotations:
        instrumentation.opentelemetry.io/inject-java: "true"
        sidecar.opentelemetry.io/inject: "sidecar"
    spec:
      containers:
        - name: app
          image: cnych/spring-petclinic:latest

然后再創(chuàng)建一個(gè) NodePort 類型的 Service 服務(wù)來暴露應(yīng)用程序。

# petclinic-svc.yaml
apiVersion: v1
kind: Service
metadata:
  name: petclinic
spec:
  selector:
    app: petclinic
  type: NodePort
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

直接應(yīng)用上面的資源清單即可：

$ kubectl apply -f central-collector.yaml
$ kubectl apply -f sidecar.yaml
$ kubectl apply -f java-instrumentation.yaml
$ kubectl apply -f petclinic.yaml
$ kubectl apply -f petclinic-svc.yaml

正常部署完成后可以看到對應(yīng)的 Pod 已經(jīng)正常運(yùn)行：

$ kubectl get pods
NAME                                 READY   STATUS    RESTARTS   AGE
petclinic-6fdd56f4d7-qfff7           2/2     Running   0          62s
simplest-collector-87d8bf9bf-dh8pl   1/1     Running   0          36m
$ kubectl get svc
NAME                            TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                        AGE
petclinic                       NodePort    10.103.6.52      <none>        80:30941/TCP                   46s
simplest-collector              ClusterIP   10.102.131.126   <none>        4317/TCP,4318/TCP              17m
simplest-collector-headless     ClusterIP   None             <none>        4317/TCP,4318/TCP              17m
simplest-collector-monitoring   ClusterIP   10.98.65.171     <none>        8888/TCP                       17m

然后我們就可以通過 http://<node_ip>:30941 來訪問 Petclinic 應(yīng)用程序了。

當(dāng)我們訪問應(yīng)用程序時(shí)，應(yīng)用程序就將生成追蹤數(shù)據(jù)，并將其發(fā)送到我們的中心收集器。我們可以通過訪問 Grafana Tempo 來查看追蹤數(shù)據(jù)，同時(shí)也可以通過訪問中心收集器的控制臺(tái)來查看追蹤數(shù)據(jù)。因?yàn)槲覀冊谥行氖占髦信渲昧巳罩居涗泴?dǎo)出器和 Grafana Tempo 兩個(gè)導(dǎo)出器，當(dāng)然也可以配置其他導(dǎo)出器。

$ kubectl logs -f petclinic-6fdd56f4d7-qfff7 -c otc-container
# ......
2023-09-10T04:11:41.164Z        info    TracesExporter  {"kind": "exporter", "data_type": "traces", "name": "logging", "resource spans": 1, "spans": 76}
2023-09-10T04:12:11.012Z        info    TracesExporter  {"kind": "exporter", "data_type": "traces", "name": "logging", "resource spans": 1, "spans": 3}
2023-09-10T04:12:16.221Z        info    TracesExporter  {"kind": "exporter", "data_type": "traces", "name": "logging", "resource spans": 1, "spans": 23}
^C
$ kubectl logs -f simplest-collector-677f4779ff-x8h2m
# ......
2023-09-10T04:11:09.221Z        info    service/service.go:161  Everything is ready. Begin running and processing data.
2023-09-10T04:11:49.222Z        info    TracesExporter  {"kind": "exporter", "data_type": "traces", "name": "logging", "resource spans": 1, "spans": 76}
2023-09-10T04:12:19.224Z        info    TracesExporter  {"kind": "exporter", "data_type": "traces", "name": "logging", "resource spans": 2, "spans": 26}

所以在 Grafana Tempo 中也可以看到對應(yīng)的追蹤數(shù)據(jù)：

同樣如果你再添加一個(gè) Jaeger 的導(dǎo)出器，那么你也可以在 Jaeger 中看到對應(yīng)的追蹤數(shù)據(jù)。

如果在部署中遇到任何問題，我們可以通過查看應(yīng)用程序和容器的日志來進(jìn)行排查。

總結(jié)

在這篇文章中，我們演示了如何使用 OpenTelemetry Operator 在應(yīng)用程序中實(shí)現(xiàn)追蹤，而無需更改任何代碼。

當(dāng)然其中還有很多其他內(nèi)容沒有涉及到，比如如何在 OpenTelemetry 中使用 Prometheus 來收集指標(biāo)數(shù)據(jù)，如何在 OpenTelemetry 中使用 Loki 來收集日志數(shù)據(jù)等等，也包括一些采樣策略、傳播器、批處理器、手動(dòng)檢測等等。

參考文檔

• https://medium.com/@magstherdev/opentelemetry-up-and-running-b4c58eaf8c05。
• https://medium.com/@magstherdev/opentelemetry-on-kubernetes-c167f024b35f。
• https://medium.com/@magstherdev/opentelemetry-in-action-fc61263c852。
• https://github.com/open-telemetry/opentelemetry-go-instrumentation。