OpenTelemetry入门看这一篇就够了( 三 ) _OpenTelemetry

Exporters为了可视化和分析遥测数据，我们还需要使用导出器。导出器是 OpenTelemetry 的一个组件，也是数据发送到不同系统/后端的方式。
比如 console exporter 是一种常见的导出器，对于开发和调试任务非常有用，他会将数据打印到控制台。
在 exporters 部分，可以添加更多目的地。例如，如果想将追踪数据发送到 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扩展主要适用于不涉及处理遥测数据的任务。扩展的示例包括健康监控、服务发现和数据转发。扩展是可选的。
扩展主要用于不涉及处理遥测数据的任务。比如健康监控、服务发现和数据转发等。扩展是可选的。
extensions:health_check:pprof:zpages:memory_ballast:size_mib: 512OpenTelemetry Collector 部署模式/策略OpenTelemetry 收集器可以通过不同的方式进行部署，所以我们要考虑下如何部署它。具体选择哪种策略取决于你的团队和组织情况。
Agent 模式在这种情况下，OpenTelemetry 检测的应用程序将数据发送到与应用程序一起驻留的（收集器）代理。然后，该代理程序将接管并处理所有来自应用程序的追踪数据。
收集器可以通过 sidecar 方式部署为代理，sidecar 可以配置为直接将数据发送到存储后端。

文章插图
Gateway 模式还可以决定将数据发送到另一个 OpenTelemetry 收集器，然后从（中心）收集器进一步将数据发送到存储后端。在这种配置中，我们有一个中心的 OpenTelemetry 收集器，它使用 deployment 模式部署，具有许多优势，如自动扩展。

文章插图
使用中心收集器的一些优点是：

消除对团队的依赖
强制执行批处理、重试、加密、压缩的配置/策略
在中心位置进行身份验证
丰富的元数据信息
进行抽样决策
通过 HPA 进行扩展

部署模式总结下面我们总结下常见的一些部署策略。
基本版 - 客户端使用 OTLP 进行检测，将数据发送到一组收集器。

文章插图
可以将数据发送到多个导出器。

文章插图
在 Kubernetes 上部署 OpenTelemetry Collector 时可以使用的模式。
sidecar 模式：

文章插图
代理作为 sidecar，其中使用 OpenTelemetry Collector 将容器添加到工作负载 Pod 。然后，该实例被配置为将数据发送到可能位于不同命名空间或集群中的外部收集器。
【OpenTelemetry入门看这一篇就够了】daemonset 模式：
Agent 作为 DaemonSet，这样我们每个 Kubernetes 节点就有一个代理 pod 。