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

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

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

分布式追蹤

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

為什么我們需要追蹤？

我們需要為什么分布式追蹤？為什么我們不能只使用指標和日志呢？假設你有一個如下所示的微服務架構。

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

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

當我們的應用出現(xiàn)問題時，我們需要解決很多問題。

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

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

追蹤從用戶與應用程序進行交互的一刻開始，我們應該能夠看到整個請求直到最后一層。

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

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

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

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

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

為此我們可以使用兩個開源項目：OpenTelemetry 和 Jaeger。

OpenTelemetry 是什么？

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

OpenTelemetry 是：

• 開源的
• 受到可觀測領域行業(yè)領導者的采用和支持
• 一個 CNCF 項目
• 與供應商無關的

OpenTelemetry 包括可觀測性的三個支柱：追蹤、指標和日志。（本文將重點關注追蹤）

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

OpenTelemetry 與供應商無關

OpenTelemetry 提供了一個與供應商無關的可觀測性標準，因為它旨在標準化跟蹤的生成。通過 OpenTelemetry，我們可以將檢測埋點與后端分離。這意味著我們不依賴于任何工具（或供應商）。

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

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

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

檢測（埋點）

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

自動檢測

使用自動檢測是一個很好的方式，因為它簡單、容易，不需要進行很多代碼更改。

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

當使用自動檢測時，將創(chuàng)建一組預定義的 spans，并填充相關屬性。

手動檢測

手動檢測是指為應用程序編寫特定的埋點代碼。這是向應用程序添加可觀測性代碼的過程。這樣做可以更有效地滿足你的需求，因為可以自己添加屬性和事件。這樣做的缺點是需要導入庫并自己完成所有工作。

傳播器

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

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

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

采樣

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

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

兩種常見的采樣技術是頭采樣和尾采樣。

OpenTelemetry 協(xié)議（OTLP）

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

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

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

OpenTelemetry Collectors

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

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

Receivers

接收器 Receivers 是數(shù)據(jù)進入收集器的方式，可以是推送或拉取。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ù)。處理器在接收和導出之間處理數(shù)據(jù)。處理器是可選的，但有些是推薦的。

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

processors:
  batch:

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

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

Exporters

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

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

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

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

當然最終要生效也需要在 service 部分的 pipelines 中啟用。

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

OpenTelemetry 附帶了各種導出器，在 OpenTelemetry 收集器 Contrib 存儲庫中可以找到。

Extensions

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

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

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

OpenTelemetry Collector 部署模式/策略

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

Agent 模式

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

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

Gateway 模式

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

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

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

部署模式總結

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

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

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

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

sidecar 模式：

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

daemonset 模式：

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

負載均衡 - 基于 trace id 的負載均衡：

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

多租戶模式

兩個租戶，每個租戶都有自己的 Jaeger。

信號模式

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

OpenTelemetry 后端

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

盡管 OpenTelemetry 不提供自己的后端，但通過使用它，我們不會依賴于任何工具或供應商，因為它與供應商無關。我們不僅可以使用我們想要的任何編程語言，而且還可以選擇存儲后端，并且只需配置另一個導出器即可輕松切換到另一個后端/供應商。

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

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

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

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

OpenTelemetry on Kubernetes

在 Kubernetes 上使用 OpenTelemetry，主要就是部署 OpenTelemetry 收集器。我們建議使用 OpenTelemetry Operator 來部署，因為它可以幫助我們輕松部署和管理 OpenTelemetry 收集器，還可以自動檢測應用程序。

部署

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

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

默認情況下會部署一個準入控制器，用于驗證 OpenTelemetry Operator 的配置是否正確，為了使 APIServer 能夠與 Webhook 組件進行通信，Webhook 需要一個由 APIServer 配置為可信任的 TLS 證書。

為了簡單我們這里直接使用自動生成簽名證書的方式，使用下面的命令一鍵安裝 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

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

$ 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

此外還會自動為我們添加兩個 OpenTelemetry 相關的 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ù)將在此收集器上進行處理，并通過導出器發(fā)送到存儲后端。整個工作流如下圖所示：

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

# 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ù)，并通過日志記錄導出和 Grafana Tempo 來記錄這些 Span，這會將 Span 寫入接收 Span 的 OpenTelemetry Collector 實例的控制臺和 Grafana Tempo 后端去。

然后我們將使用 Sidecar 模式部署 OpenTelemetry 代理。該代理會將應用程序的追蹤發(fā)送到我們的中心（網(wǎng)關）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]

自動檢測

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

要使用自動檢測，需要為 SDK 和檢測配置添加一個 Instrumentation 資源。比如對于 Java 應用程序，配置如下。

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

如果是 Python 應用程序，配置如下：

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

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

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

示例應用

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

對于 Java 應用，我們可以通過下載 OpenTelemetry 提供的 opentelemetry-javaagent 這個 jar 包來使用 OpenTelemetry 自動檢測應用程序。

只需要將這個 jar 包添加到應用程序的啟動命令中即可，比如：

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

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

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

我們首先部署 Petclinic 應用程序。

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 應用程序添加一個 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

為了啟用自動檢測，我們需要更新部署文件并向其添加注解。這樣我們可以告訴 OpenTelemetry Operator 將 sidecar 和 java-instrumentation 注入到我們的應用程序中。修改 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)建一個 NodePort 類型的 Service 服務來暴露應用程序。

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

直接應用上面的資源清單即可：

$ 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

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

$ 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 應用程序了。

當我們訪問應用程序時，應用程序就將生成追蹤數(shù)據(jù)，并將其發(fā)送到我們的中心收集器。我們可以通過訪問 Grafana Tempo 來查看追蹤數(shù)據(jù)，同時也可以通過訪問中心收集器的控制臺來查看追蹤數(shù)據(jù)。因為我們在中心收集器中配置了日志記錄導出器和 Grafana Tempo 兩個導出器，當然也可以配置其他導出器。

$ 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 中也可以看到對應的追蹤數(shù)據(jù)：

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

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

總結

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

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

參考文檔

• 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。