This is the multi-page printable view of this section. Click here to print.
代码跟踪
1 - 分布式追踪概述
Dapr 通过 Open Telemetry (OTEL) 和 Zipkin 协议来实现分布式追踪。OTEL 是行业标准，并且是推荐使用的追踪协议。
大多数可观测性工具支持 OTEL，包括：
下图展示了 Dapr（使用 OTEL 和 Zipkin 协议）如何与多个可观测性工具集成。
场景
追踪用于服务调用和发布/订阅（pubsub）API。您可以在使用这些 API 的服务之间传递追踪上下文。追踪的使用有两种场景：
- Dapr 生成追踪上下文，您将追踪上下文传递到另一个服务。
- 您生成追踪上下文，Dapr 将追踪上下文传递到服务。
场景 1：Dapr 生成追踪上下文头
顺序服务调用的传递
Dapr 负责创建追踪头。然而，当有两个以上的服务时，您需要负责在它们之间传递追踪头。让我们通过示例来了解这些场景：
单一服务调用
例如，服务 A -> 服务 B。
Dapr 在 服务 A 中生成追踪头，然后从 服务 A 传递到 服务 B。不需要进一步的传递。
多个顺序服务调用
例如，服务 A -> 服务 B -> 传递追踪头到 -> 服务 C，以及其他启用 Dapr 的服务。
Dapr 在请求开始时在 服务 A 中生成追踪头，然后传递到 服务 B。您现在需要负责获取头并将其传递到 服务 C，因为这与您的应用程序特定相关。
换句话说，如果应用程序调用 Dapr 并希望使用现有的追踪头（span）进行追踪，它必须始终传递到 Dapr（在此示例中，从 服务 B 到 服务 C）。Dapr 始终将追踪 span 传递到应用程序。
注意
Dapr SDK 中没有公开的辅助方法来传递和检索追踪上下文。您需要使用 HTTP/gRPC 客户端通过 HTTP 头和 gRPC 元数据传递和检索追踪头。请求来自外部端点
例如，从网关服务到启用 Dapr 的服务 A。
外部网关入口调用 Dapr，Dapr 生成追踪头并调用 服务 A。服务 A 然后调用 服务 B 和其他启用 Dapr 的服务。
您必须从 服务 A 传递头到 服务 B。例如：入口 -> 服务 A -> 传递追踪头 -> 服务 B。这类似于案例 2。
发布/订阅消息
Dapr 在发布的消息主题中生成追踪头。对于 rawPayload 消息，可以指定 traceparent 头以传递追踪信息。这些追踪头会传递到任何监听该主题的服务。
多个不同服务调用的传递
在以下场景中，Dapr 为您完成了一些工作，您需要创建或传递追踪头。
从单个服务调用多个不同的服务
当您从单个服务调用多个服务时，您需要传递追踪头。例如：
服务 A -> 服务 B
[ .. 一些代码逻辑 ..]
服务 A -> 服务 C
[ .. 一些代码逻辑 ..]
服务 A -> 服务 D
[ .. 一些代码逻辑 ..]
在这种情况下：
- 当
服务 A首次调用服务 B时，Dapr 在服务 A中生成追踪头。 服务 A中的追踪头被传递到服务 B。- 这些追踪头作为响应头的一部分在
服务 B的响应中返回。 - 然后，您需要将返回的追踪上下文传递到下一个服务，如
服务 C和服务 D，因为 Dapr 不知道您想要重用相同的头。
场景 2：您从非 Dapr 化应用程序生成自己的追踪上下文头
生成您自己的追踪上下文头较为少见，并且在调用 Dapr 时通常不需要。
然而，在某些场景中，您可能会特别选择在服务调用中添加 W3C 追踪头。例如，您有一个不使用 Dapr 的现有应用程序。在这种情况下，Dapr 仍然为您传递追踪上下文头。
如果您决定自己生成追踪头，可以通过三种方式完成：
标准 OpenTelemetry SDK
您可以使用行业标准的 OpenTelemetry SDKs 生成追踪头，并将这些追踪头传递到启用 Dapr 的服务。这是首选方法。
供应商 SDK
您可以使用提供生成 W3C 追踪头的方法的供应商 SDK，并将其传递到启用 Dapr 的服务。
W3C 追踪上下文
您可以根据 W3C 追踪上下文规范 手工制作追踪上下文，并将其传递到启用 Dapr 的服务。
阅读 追踪上下文概述 以获取有关 W3C 追踪上下文和头的更多背景和示例。
相关链接
2 - W3C 跟踪上下文概述
Dapr 采用 Open Telemetry 协议，该协议利用 W3C 跟踪上下文 来实现服务调用和发布/订阅消息的分布式跟踪。Dapr 生成并传播跟踪上下文信息，可以将其发送到可观测性工具进行可视化和查询。
背景
分布式跟踪是一种由跟踪工具实现的方法，用于跟踪、分析和调试跨多个软件组件的事务。
通常，分布式跟踪会跨越多个服务，因此需要一个唯一的标识符来标识每个事务。跟踪上下文传播就是传递这种唯一标识符的过程。
过去，不同的跟踪供应商各自实现自己的跟踪上下文传播方式。在多供应商环境中，这会导致互操作性的问题，例如：
- 不同供应商收集的跟踪数据无法关联，因为没有共享的唯一标识符。
- 跨越不同供应商边界的跟踪无法传播，因为没有统一的标识符集。
- 中间商可能会丢弃供应商特定的元数据。
- 云平台供应商、中间商和服务提供商无法保证支持跟踪上下文传播，因为没有标准可循。
以前，大多数应用程序由单一的跟踪供应商监控，并保持在单一平台提供商的边界内，因此这些问题没有显著影响。
如今，越来越多的应用程序是分布式的，并利用多个中间件服务和云平台。这种现代应用程序的转变需要一个分布式跟踪上下文传播标准。
W3C 跟踪上下文规范 定义了一种通用格式，用于交换跟踪上下文数据（称为跟踪上下文）。通过提供以下内容，跟踪上下文解决了上述问题：
- 为单个跟踪和请求提供唯一标识符，允许将多个供应商的跟踪数据链接在一起。
- 提供一种机制来转发供应商特定的跟踪数据，避免在单个事务中多个跟踪工具参与时出现断裂的跟踪。
- 一个中间商、平台和硬件供应商可以支持的行业标准。
这种统一的跟踪数据传播方法提高了对分布式应用程序行为的可见性，促进了问题和性能分析。
W3C 跟踪上下文和头格式
W3C 跟踪上下文
Dapr 使用标准的 W3C 跟踪上下文头。
- 对于 HTTP 请求，Dapr 使用
traceparent头。 - 对于 gRPC 请求，Dapr 使用
grpc-trace-bin头。
当请求到达时没有跟踪 ID，Dapr 会创建一个新的。否则，它会沿调用链传递跟踪 ID。
W3C 跟踪头
这些是 Dapr 为 HTTP 和 gRPC 生成和传播的特定跟踪上下文头。
在从 HTTP 响应传播跟踪上下文头到 HTTP 请求时复制这些头：
Traceparent 头
Traceparent 头以所有供应商都能理解的通用格式表示跟踪系统中的传入请求：
traceparent: 00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01
Tracestate 头
Tracestate 头以可能是供应商特定的格式包含父级：
tracestate: congo=t61rcWkgMzE
在 gRPC API 调用中，跟踪上下文通过 grpc-trace-bin 头传递。
相关链接
3 - 配置 Dapr 发送分布式追踪数据
注意
建议在任何生产环境中启用 Dapr 的追踪功能。您可以根据运行环境配置 Dapr，将追踪和遥测数据发送到多种可观测性工具，无论是在云端还是本地。配置
在 Configuration 规范中的 tracing 部分包含以下属性：
spec:
tracing:
samplingRate: "1"
otel:
endpointAddress: "myendpoint.cluster.local:4317"
zipkin:
endpointAddress: "https://..."
下表列出了追踪的属性：
| 属性 | 类型 | 描述 |
|---|---|---|
samplingRate | string | 设置追踪的采样率来启用或禁用追踪。 |
stdout | bool | 如果为真，则会将更详细的信息写入追踪。 |
otel.endpointAddress | string | 设置 Open Telemetry (OTEL) 目标主机名和可选端口。如果使用此项，则无需指定 ‘zipkin’ 部分。 |
otel.isSecure | bool | 指定连接到端点地址的连接是否加密。 |
otel.protocol | string | 设置为 http 或 grpc 协议。 |
zipkin.endpointAddress | string | 设置 Zipkin 服务器 URL。如果使用此项，则无需指定 otel 部分。 |
要启用追踪，请使用配置文件（在 selfhost 模式下）或 Kubernetes 配置对象（在 Kubernetes 模式下）。例如，以下配置对象将采样率设置为 1（每个 span 都被采样），并使用 OTEL 协议将追踪发送到本地的 OTEL 服务器 localhost:4317。
apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
name: tracing
spec:
tracing:
samplingRate: "1"
otel:
endpointAddress: "localhost:4317"
isSecure: false
protocol: grpc
采样率
Dapr 使用概率采样。采样率定义了追踪 span 被采样的概率，值可以在 0 到 1 之间（包括 0 和 1）。默认采样率为 0.0001（即每 10,000 个 span 中采样 1 个）。
将 samplingRate 设置为 0 将完全禁用追踪。
环境变量
OpenTelemetry (otel) 端点也可以通过环境变量进行配置。设置 OTEL_EXPORTER_OTLP_ENDPOINT 环境变量将为 sidecar 启用追踪。
| 环境变量 | 描述 |
|---|---|
OTEL_EXPORTER_OTLP_ENDPOINT | 设置 Open Telemetry (OTEL) 服务器主机名和可选端口，启用追踪 |
OTEL_EXPORTER_OTLP_INSECURE | 将连接设置为未加密（true/false） |
OTEL_EXPORTER_OTLP_PROTOCOL | 传输协议（grpc、http/protobuf、http/json） |
下一步
了解如何使用以下工具之一设置追踪：
4 - Open Telemetry Collector
4.1 - 使用 OpenTelemetry Collector 收集追踪
Dapr 推荐使用 OpenTelemetry (OTLP) 协议来写入追踪数据。对于直接支持 OTLP 的可观测性工具，建议使用 OpenTelemetry Collector，因为它可以快速卸载数据，并提供重试、批处理和加密等功能。更多信息请参阅 Open Telemetry Collector 的文档。
Dapr 也支持使用 Zipkin 协议来写入追踪数据。在 OTLP 协议支持之前，Zipkin 协议与 OpenTelemetry Collector 一起使用，以将追踪数据发送到 AWS X-Ray、Google Cloud Operations Suite 和 Azure Monitor 等可观测性工具。虽然两种协议都有效，但推荐使用 OpenTelemetry 协议。
先决条件
- 在 Kubernetes 上安装 Dapr
- 确保您的追踪后端已准备好接收追踪数据
- 查看 OTEL Collector 导出器所需的参数：
配置 OTEL Collector 推送追踪数据到您的后端
将
<your-exporter-here>替换为您的追踪导出器的实际配置。- 请参考先决条件部分中的 OTEL Collector 链接以获取正确的配置。
使用以下命令应用配置：
kubectl apply -f open-telemetry-collector-generic.yaml
配置 Dapr 发送追踪数据到 OTEL Collector
创建一个 Dapr 配置文件以启用追踪，并部署一个使用 OpenTelemetry Collector 的追踪导出器组件。
使用此
collector-config.yaml文件创建您的配置。使用以下命令应用配置：
kubectl apply -f collector-config.yaml
部署应用程序并启用追踪
在需要参与分布式追踪的容器中添加 dapr.io/config 注解以应用 appconfig 配置，如下所示：
apiVersion: apps/v1
kind: Deployment
metadata:
...
spec:
...
template:
metadata:
...
annotations:
dapr.io/enabled: "true"
dapr.io/app-id: "MyApp"
dapr.io/app-port: "8080"
dapr.io/config: "appconfig"
您可以同时注册多个追踪导出器，追踪数据将被转发到所有注册的导出器。
就是这样！无需包含任何 SDK 或对您的应用程序代码进行修改。Dapr 会自动为您处理分布式追踪。
查看追踪
部署并运行一些应用程序。等待追踪数据传播到您的追踪后端并在那里查看它们。
相关链接
4.2 - 使用 OpenTelemetry Collector 将跟踪信息发送到应用程序洞察
Dapr 使用 Zipkin API 集成了 OpenTelemetry (OTEL) Collector。本指南演示了如何通过 Dapr 使用 OpenTelemetry Collector 将跟踪事件推送到 Azure 应用程序洞察。
前提条件
- 在 Kubernetes 上安装 Dapr
- 设置一个应用程序洞察资源并记录下你的应用程序洞察仪器密钥。
配置 OTEL Collector 以推送数据到应用程序洞察
要将事件推送到你的应用程序洞察实例，请在 Kubernetes 集群中安装 OTEL Collector。
用你的应用程序洞察仪器密钥替换
<INSTRUMENTATION-KEY>占位符。使用以下命令应用配置：
kubectl apply -f open-telemetry-collector-appinsights.yaml
配置 Dapr 以发送跟踪数据到 OTEL Collector
创建一个 Dapr 配置文件以启用跟踪，并部署一个使用 OpenTelemetry Collector 的跟踪导出组件。
使用此
collector-config.yaml文件创建你自己的配置。使用以下命令应用配置：
kubectl apply -f collector-config.yaml
部署应用程序并启用跟踪
在你希望参与分布式跟踪的容器中添加 dapr.io/config 注解以应用 appconfig 配置，如下例所示：
apiVersion: apps/v1
kind: Deployment
metadata:
...
spec:
...
template:
metadata:
...
annotations:
dapr.io/enabled: "true"
dapr.io/app-id: "MyApp"
dapr.io/app-port: "8080"
dapr.io/config: "appconfig"
你可以同时注册多个跟踪导出器，跟踪日志会被转发到所有注册的导出器。
就是这样！无需包含任何 SDK 或对你的应用程序代码进行额外的修改。Dapr 会自动为你处理分布式跟踪。
查看跟踪
部署并运行一些应用程序。几分钟后，你应该会在你的应用程序洞察资源中看到跟踪日志。你还可以使用 应用程序地图 来检查你的服务拓扑，如下所示：
注意
只有通过 Dapr sidecar 暴露的 Dapr API（例如，服务调用或事件发布）的操作会显示在应用程序地图拓扑中。相关链接
4.3 - 使用 OpenTelemetry Collector 收集追踪信息并发送到 Jaeger
Dapr 支持通过 OpenTelemetry (OTLP) 和 Zipkin 协议进行追踪信息的写入。然而，由于 Jaeger 对 Zipkin 的支持已被弃用，建议使用 OTLP。虽然 Jaeger 可以直接支持 OTLP，但在生产环境中，推荐使用 OpenTelemetry Collector 从 Dapr 收集追踪信息并发送到 Jaeger。这样可以让您的应用程序更高效地处理数据，并利用重试、批处理和加密等功能。更多信息请阅读 Open Telemetry Collector 文档。
在自托管模式下配置 Jaeger
本地设置
启动 Jaeger 的最简单方法是运行发布到 DockerHub 的预构建的 all-in-one Jaeger 镜像，并暴露 OTLP 端口：
docker run -d --name jaeger \
-p 4317:4317 \
-p 16686:16686 \
jaegertracing/all-in-one:1.49
接下来，在本地创建以下 config.yaml 文件：
注意： 因为您使用 Open Telemetry 协议与 Jaeger 通信，您需要填写追踪配置的
otel部分，并将endpointAddress设置为 Jaeger 容器的地址。
apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
name: tracing
namespace: default
spec:
tracing:
samplingRate: "1"
stdout: true
otel:
endpointAddress: "localhost:4317"
isSecure: false
protocol: grpc
要启动引用新 YAML 配置文件的应用程序，请使用 --config 选项。例如：
dapr run --app-id myapp --app-port 3000 node app.js --config config.yaml
查看追踪信息
要在浏览器中查看追踪信息，请访问 http://localhost:16686 查看 Jaeger UI。
在 Kubernetes 上使用 OpenTelemetry Collector 配置 Jaeger
以下步骤展示了如何配置 Dapr 以将分布式追踪数据发送到 OpenTelemetry Collector，然后将追踪信息发送到 Jaeger。
前提条件
- 在 Kubernetes 上安装 Dapr
- 使用 Jaeger Kubernetes Operator 设置 Jaeger
设置 OpenTelemetry Collector 推送到 Jaeger
要将追踪信息推送到您的 Jaeger 实例，请在您的 Kubernetes 集群上安装 OpenTelemetry Collector。
下载并检查
open-telemetry-collector-jaeger.yaml文件。在
otel-collector-confConfigMap 的数据部分，更新otlp/jaeger.endpoint值以匹配您的 Jaeger collector Kubernetes 服务对象的端点。将 OpenTelemetry Collector 部署到运行 Dapr 应用程序的相同命名空间中：
kubectl apply -f open-telemetry-collector-jaeger.yaml
设置 Dapr 发送追踪信息到 OpenTelemetryCollector
创建一个 Dapr 配置文件以启用追踪，并将 sidecar 追踪信息导出到 OpenTelemetry Collector。
使用
collector-config-otel.yaml文件创建您自己的 Dapr 配置。更新
namespace和otel.endpointAddress值以与部署 Dapr 应用程序和 OpenTelemetry Collector 的命名空间对齐。应用配置：
kubectl apply -f collector-config.yaml
部署启用追踪的应用程序
通过在您希望启用分布式追踪的应用程序部署中添加 dapr.io/config 注释来应用 tracing Dapr 配置，如下例所示：
apiVersion: apps/v1
kind: Deployment
metadata:
...
spec:
...
template:
metadata:
...
annotations:
dapr.io/enabled: "true"
dapr.io/app-id: "MyApp"
dapr.io/app-port: "8080"
dapr.io/config: "tracing"
您可以同时注册多个追踪导出器，追踪日志将被转发到所有注册的导出器。
就是这样！无需包含 OpenTelemetry SDK 或对您的应用程序代码进行检测。Dapr 会自动为您处理分布式追踪。
查看追踪信息
要查看 Dapr sidecar 追踪信息，请端口转发 Jaeger 服务并打开 UI：
kubectl port-forward svc/jaeger-query 16686 -n observability
在您的浏览器中，访问 http://localhost:16686，您将看到 Jaeger UI。
参考资料
5 - 操作指南：配置 New Relic 进行分布式追踪
前提条件
- 需要一个 New Relic 账户，该账户永久免费，每月可免费处理 100 GB 的数据，包含 1 个完全访问用户和无限数量的基本用户。
配置 Dapr 追踪
Dapr 可以直接将其捕获的指标和追踪数据发送到 New Relic。最简单的方式是通过配置 Dapr，将追踪数据以 Zipkin 格式发送到 New Relic 的 Trace API。
为了将数据集成到 New Relic 的 Telemetry Data Platform，您需要一个 New Relic Insights Insert API key。
apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
name: appconfig
namespace: default
spec:
tracing:
samplingRate: "1"
zipkin:
endpointAddress: "https://trace-api.newrelic.com/trace/v1?Api-Key=<NR-INSIGHTS-INSERT-API-KEY>&Data-Format=zipkin&Data-Format-Version=2"
查看追踪
New Relic 分布式追踪概览
New Relic 分布式追踪详情
（选择性）New Relic 仪器化
为了将数据集成到 New Relic Telemetry Data Platform，您需要一个 New Relic license key 或 New Relic Insights Insert API key。
OpenTelemetry 仪器化
您可以使用不同语言的 OpenTelemetry 实现，例如 New Relic Telemetry SDK 和 .NET 的 OpenTelemetry 支持。在这种情况下，使用 OpenTelemetry Trace Exporter。示例请参见此处。
New Relic 语言代理
类似于 OpenTelemetry 仪器化，您也可以使用 New Relic 语言代理。例如，.NET Core 的 New Relic 代理仪器化 是 Dockerfile 的一部分。示例请参见此处。
（选择性）启用 New Relic Kubernetes 集成
如果 Dapr 和您的应用程序在 Kubernetes 环境中运行，您可以启用额外的指标和日志。
安装 New Relic Kubernetes 集成的最简单方法是使用 自动安装程序 生成清单。它不仅包含集成 DaemonSets，还包括其他 New Relic Kubernetes 配置，如 Kubernetes 事件、Prometheus OpenMetrics 和 New Relic 日志监控。
New Relic Kubernetes 集群浏览器
New Relic Kubernetes 集群浏览器 提供了一个独特的可视化界面，展示了 Kubernetes 集成收集的所有数据和部署。
这是观察所有数据并深入了解应用程序或微服务内部发生的任何性能问题或事件的良好起点。
自动关联是 New Relic 可视化功能的一部分。
Pod 级别详情
上下文中的日志
New Relic 仪表板
Kubernetes 概览
Dapr 系统服务
Dapr 指标
New Relic Grafana 集成
New Relic 与 Grafana Labs 合作，您可以使用 Telemetry Data Platform 作为 Prometheus 指标的数据源，并在现有仪表板中查看它们，轻松利用 New Relic 提供的可靠性、规模和安全性。
用于监控 Dapr 系统服务和 sidecar 的 Grafana 仪表板模板 可以轻松使用，无需任何更改。New Relic 提供了一个 Prometheus 指标的本地端点 到 Grafana。可以轻松设置数据源：
并且可以导入来自 Dapr 的完全相同的仪表板模板，以可视化 Dapr 系统服务和 sidecar。
New Relic 警报
从 Dapr、Kubernetes 或任何在其上运行的服务收集的所有数据都可以用于设置警报和通知到您选择的首选渠道。请参见 Alerts and Applied Intelligence。
相关链接/参考
6 - 操作指南：设置 Zipkin 进行分布式追踪
配置自托管模式
在自托管模式下，运行 dapr init 时：
- 系统会默认创建一个 YAML 文件，路径为
$HOME/.dapr/config.yaml（Linux/Mac）或%USERPROFILE%\.dapr\config.yaml（Windows）。在执行dapr run时，系统会默认引用该文件，除非您指定了其他配置：
- config.yaml
apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
name: daprConfig
namespace: default
spec:
tracing:
samplingRate: "1"
zipkin:
endpointAddress: "http://localhost:9411/api/v2/spans"
- 运行
dapr init时，openzipkin/zipkin 的 Docker 容器会自动启动。您也可以手动启动：
使用 Docker 启动 Zipkin：
docker run -d -p 9411:9411 openzipkin/zipkin
- 使用
dapr run启动应用程序时，默认会引用$HOME/.dapr/config.yaml或%USERPROFILE%\.dapr\config.yaml中的配置文件。您可以通过 Dapr CLI 的--config参数来指定其他配置：
dapr run --app-id mynode --app-port 3000 node app.js
查看追踪
要查看追踪数据，请在浏览器中访问 http://localhost:9411，您将看到 Zipkin 的用户界面。
配置 Kubernetes
以下步骤将指导您如何配置 Dapr，将分布式追踪数据发送到 Kubernetes 集群中的 Zipkin 容器，并查看这些数据。
设置
首先，部署 Zipkin：
kubectl create deployment zipkin --image openzipkin/zipkin
为 Zipkin pod 创建一个 Kubernetes 服务：
kubectl expose deployment zipkin --type ClusterIP --port 9411
接下来，在本地创建以下 YAML 文件：
- tracing.yaml 配置
apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
name: tracing
namespace: default
spec:
tracing:
samplingRate: "1"
zipkin:
endpointAddress: "http://zipkin.default.svc.cluster.local:9411/api/v2/spans"
现在，部署 Dapr 配置文件：
kubectl apply -f tracing.yaml
要在 Dapr sidecar 中启用此配置，请在 pod 规范模板中添加以下注释：
annotations:
dapr.io/config: "tracing"
完成！您的 sidecar 现在已配置为将追踪数据发送到 Zipkin。
查看追踪数据
要查看追踪数据，请连接到 Zipkin 服务并打开用户界面：
kubectl port-forward svc/zipkin 9411:9411
在浏览器中，访问 http://localhost:9411，您将看到 Zipkin 的用户界面。
参考资料
7 - 操作指南：为分布式追踪设置 Datadog
Dapr 捕获的指标和追踪信息可以通过 OpenTelemetry Collector 的 Datadog 导出器直接发送到 Datadog。
使用 OpenTelemetry Collector 和 Datadog 配置 Dapr 追踪
您可以使用 OpenTelemetry Collector 的 Datadog 导出器来配置 Dapr，为 Kubernetes 集群中的每个应用程序创建追踪，并将这些追踪信息收集到 Datadog 中。
在开始之前，请先设置 OpenTelemetry Collector。
在
datadog导出器的配置部分，将您的 Datadog API 密钥添加到./deploy/opentelemetry-collector-generic-datadog.yaml文件中：data: otel-collector-config: ... exporters: ... datadog: api: key: <YOUR_API_KEY>运行以下命令以应用
opentelemetry-collector的配置。kubectl apply -f ./deploy/open-telemetry-collector-generic-datadog.yaml设置一个 Dapr 配置文件以启用追踪，并部署一个使用 OpenTelemetry Collector 的追踪导出器组件。
kubectl apply -f ./deploy/collector-config.yaml在您希望参与分布式追踪的容器中添加
dapr.io/config注解，以应用appconfig配置。annotations: dapr.io/config: "appconfig"创建并配置应用程序。应用程序运行后，遥测数据将被发送到 Datadog，并可以在 Datadog APM 中查看。
