组合 OpenTelemetry 参考架构

作者来自 Elastic Miguel Luna用于构建 OpenTelemetry Collection 架构的概念框架 —— 包括 edge、processing 和 resilience 层将它们组合成适合你环境的正确 pipeline。大多数 OpenTelemetry 教程都会在同一个地方结束应用通过 SDK 完成 instrumentation将 traces 导出到单个 collector再转发到后端。这可以工作。然后生产环境出现了。流量增长。团队希望从 traces 派生 metrics。后端因维护宕机你丢失了一小时的 telemetry。合规要求规定在数据离开集群之前必须去除 PII。突然之间单个 collector 已经不够用了 —— 问题变成架构实际上应该是什么样OpenTelemetry Collector 被设计为可组合的。它可以以多种部署模式运行被串联成 pipelines并且可以在每个阶段独立扩展。但文档描述的是各个独立组件而不是如何思考将它们组装在一起。本文正是关于这种思考方式。接下来介绍的是一个用于理解 collector 架构的概念框架 —— 而不是一组固定模板。这里描述的构建块是参考点。在实际中它们会组合、重叠并根据你的约束进行调整。例如一个 tail sampling 层可能还需要基于 Kafka 的 resilience。一个 gateway 在低流量时可能会承担 sampling 层的角色。目标是充分理解这些概念从而为你的场景组合出合适的架构而不是从现成方案中直接选择。三个概念层将 collector 架构分为三个层次来理解会很有帮助edge、processing和resilience。这些并不是必须作为独立部署存在的物理层 —— 它们是关注点的分类。一个 collector 可以覆盖多个层。一个复杂部署在同一层中也可能包含多个组件。这些层是思考工具而不是部署图。边缘层telemetry 如何进入 pipeline边缘层关注的是第一跳 —— telemetry 如何从你的应用和基础设施进入 pipeline。在这个阶段collector 以两种根本不同的方式收集数据。像 filelog 和 hostmetrics 这样的pull 型 receivers会主动获取数据 —— 从磁盘 tail 日志文件或从主机抓取系统级 metrics。像 otlp 这样的push 型 receivers会监听发送给它们的数据 —— 通过 OpenTelemetry SDK 完成 instrumentation 的应用会将 traces、metrics 和 logs 直接导出到 collector 的 OTLP endpoint。一个典型的边缘 collector 通常同时运行两者pull receivers 用于收集应用本身不了解的基础设施 telemetrypush receivers 用于接收 SDK 生成的应用 telemetry。常见的部署模式有多种具体选择取决于你的环境以及需要收集的数据。DaemonSet Agent—— 每个 Kubernetes 节点运行一个 OpenTelemetry Collector以 DaemonSet 方式部署。应用将数据导出到同一节点上的 agent通常通过 Kubernetes Downward API 使用 status.hostIP:4317。该 agent 还会通过 filelog receiver 从磁盘 tail 容器日志文件并通过 hostmetrics receiver 抓取主机级 metrics。这是最常见的 Kubernetes 模式因为它通过一次部署同时处理应用和基础设施 telemetry并且应用只需要知道 localhost。Sidecar Agent—— 每个 pod 运行一个 OpenTelemetry Collector作为 sidecar 容器部署。每个服务都有自己的 collector并使用自定义配置。在像 AWS Fargate 或 Azure Container Apps 这样的托管容器平台上这些平台不支持 DaemonSets这是必需的当不同服务有不同处理需求时这种方式也很有用。当与 DaemonSet 一起运行时sidecar 负责处理应用 telemetry而 DaemonSet 独立收集节点级 telemetry —— 应用不会同时向两者发送数据。Host Agent—— 在裸机或 VM 主机上以 systemd 服务运行的独立 OpenTelemetry Collector。它与 DaemonSet agent 的作用相同但在 Kubernetes 之外收集主机 metrics、tail 日志文件并接收来自本地应用的 OTLP 数据。Direct SDK Export—— 应用直接将数据导出到下一阶段gateway 或后端不经过本地 collector。这是最简单的方式但仅在不需要收集基础设施数据时适用。对于日志收集推荐模式仍然是写入 stdout 并使用带有 filelog receiver 的 collector —— 即使 SDK 已直接导出 traces 和 metrics。这些模式并不是互斥的。一个 Kubernetes 集群可能同时运行 DaemonSet agents 来收集基础设施数据并为需要自定义处理的服务运行 sidecars。一个 VM 环境可能对部分服务使用 host agents对其他服务使用 direct SDK export。边缘层的关键在于根据工作负载匹配合适的采集方式而不是为所有场景选择单一模式。处理层集中策略、采样和转换并非所有架构都需要处理层。如果你的边缘 collectors 可以直接导出到后端并且你不需要集中策略可以跳过该层以保持简单性。但有些场景会推动你采用集中处理 —— 实现方式可以从单个 gateway 到多阶段 pipeline。集中策略Gateway—— 一组位于边缘 collectors 与后端之间的 OpenTelemetry Collectors。在这里你可以为所有服务统一执行过滤、转换和 PII 脱敏。同时这里也是管理后端凭证的地方 —— 边缘 collectors 通过 OTLP 将数据发送到 gateway只有 gateway 持有 API keys。凭证隔离通常是团队引入 gateway 的主要原因。副本数量根据数据量进行扩展。在低流量低于 1K events/sec时2 个副本并与工作负载共置即可。在中等流量时使用 3–5 个副本并部署在专用节点池。在高流量时使用 5–20 个副本甚至可能部署在单独的集群中。这是一个通用经验法则你应根据具体需求进行调整因为不同负载类型之间的流量差异可能很大。基于尾部的采样—— 需要考虑完整 trace 的采样决策例如“保留所有包含错误的 traces对成功的 traces 采样 10%”要求同一 trace 的所有 spans 都到达同一个 collector 实例。这可以通过使用loadbalancingexporter并设置routing_key: traceID来实现从而将同一 trace 的 spans 一致地路由到同一个下游 collector。这里有一个关键的细微点如果你使用 spanmetrics connector 从 traces 派生 span metricsRED metrics派生必须在采样之前完成。否则你的 metrics 只反映被采样的子集而不是实际流量。正确的模式是在采样阶段使用两步 pipeline接收 traces从 100% 流量中派生 spanmetrics并通过forwardconnector 转发。对转发后的 traces 应用 tail_sampling仅导出被保留的 traces。一个独立的 metrics pipeline 用于导出派生的 RED metrics。这样可以确保无论采样率如何metrics 都是准确的。关于 processing 的关键点是这些能力 —— gateway 策略、尾部采样、span metrics 派生 —— 并不是独立的产品或固定模块。它们都是同一个 OpenTelemetry Collector 的不同配置。在低流量情况下一个 gateway 部署可以同时处理策略执行、采样和 metrics 派生。在高流量情况下你可能会将它们拆分为独立阶段以实现独立扩展。架构应适应你的规模而不是反过来。韧性层当后端不可用时会发生什么韧性层决定了在后端故障或 collector 重启期间你可以接受多少数据丢失。这不是一个单独附加的层 —— 而是可以应用于 pipeline 任意阶段的一种属性。内存队列—— 默认方式。collector 的sending_queue会使用指数退避重试失败的导出。如果 collector 进程崩溃或重启队列中的数据会丢失。这适用于开发环境或可以容忍部分数据丢失的工作负载。持久化队列WAL——file_storage扩展会在导出前将排队数据写入磁盘。如果 collector 崩溃重启后会从中断处继续。在 Kubernetes 中这需要 PersistentVolumeClaim。这是大多数生产工作负载的合适选择 —— 在不引入外部消息总线复杂性的情况下可以应对 collector 重启和短暂的后端故障。Kafka 缓冲—— 在 collectors 和后端之间引入外部 Kafka 集群。生产者 collector 写入 Kafka topics消费者 collector 从 Kafka 读取并导出到后端。这提供了最强的数据持久性保障 —— Kafka 可以在长时间故障期间缓冲数小时的 telemetry并支持重放。但这也带来了显著的运维复杂性。需要理解的关键点是resilience 与其他层是正交的。你可以在 edge agent、gateway 或 sampling 层中添加持久化队列。你可以在 gateway 前、sampling 层前或后端前引入 Kafka。一个需要在长时间故障中保持可用的 tail sampling 部署可能会使用基于 Kafka 的摄取 —— 将看似两个独立“模块”的能力组合到同一个阶段中。这些构建块可以根据你需要防护的场景自由组合。从哪里开始构建你的架构Agent Gateway 的两层模式是事实上的生产标准被绝大多数在规模化运行 OpenTelemetry 的组织采用。每个节点上的 DaemonSet agents 负责本地采集 —— 通过 filelog 和 hostmetrics 拉取基础设施 telemetry通过 OTLP 接收应用 telemetry —— 而集中式 gateway 集群负责执行策略、管理凭证并将数据导出到后端。在 gateway 上使用持久化队列WAL可以在不依赖外部系统的情况下防护后端故障。其他所有配置要么是对这种模式的简化要么是在其基础上的扩展。较小的环境可能会去掉 gateway直接从 agents 导出。较大的环境可能会增加一个带有基于 traceID 负载均衡的 tail sampling 层、用于增强韧性的 Kafka 缓冲或者在采样前进行 span metrics 派生。前面章节中描述的构建块 —— edge、processing、resilience —— 就是你在这个基础上添加或移除的模块。关键是从两层模式开始并逐步演进需要凭证隔离或集中式 PII 脱敏你已经有 gateway。需要基于尾部的采样在 agents 和 gateway 之间添加 load-balancing exporter 和 sampling 层。需要在长时间故障期间提供数小时缓冲在 agents 和 processing 层之间插入 Kafka。运行在 Fargate 或 Azure Container Apps 上将 DaemonSet agents 替换为 sidecars —— pipeline 的其余部分保持不变。从这里开始。随着需求增长逐步添加模块。架构应适应你的规模而不是反过来。决定架构走向的关键问题在设计 collector 架构时以下问题决定了你需要哪些模式问题影响我需要基础设施 telemetry主机指标、磁盘日志吗决定你是否需要本地 collector 或可以使用直接 SDK 导出我运行在托管容器平台上吗Fargate、ACA必须使用 sidecar 模式而不是 DaemonSet我需要集中式过滤、PII 脱敏或凭证隔离吗增加一个 gateway 阶段我需要基于尾部的采样吗增加一个带 load-balancing exporter 和 traceID 路由的采样阶段我想要 span 派生的 metricsRED metrics吗在两步 pipeline 中采样前需要 spanmetrics在故障期间可接受多少数据丢失决定使用内存队列、持久化队列还是 Kafka —— 应用于需要保护的阶段我预计的数据量是多少决定功能能否共置于单个部署还是需要独立阶段这些问题的答案并不对应单一的“正确”架构。它们只是约束了设计空间在这些约束内你需要在简化和功能之间进行权衡。交互式探索这些模式如果你希望探索这些构建块如何组合而不是手动组装它们OpenTelemetry Blueprints 是一个开源工具可以根据你的需求生成参考架构。切换你的环境、信号类型、数据量、韧性和处理需求 —— 即可获得一个组合好的图表包含动画数据流、交互式提示以及可以直接在 OTelBin 中打开验证的参考 collector 配置。生成的配置通过 OTLP 导出因此它们可与任何 OTLP 兼容的后端一起使用 —— 包括 Elastic Observability它原生接收并存储 OTLP traces、metrics 和 logs。Blueprints 生成的架构是参考组合 —— 用于理解构建块如何配合而不是现成可用的部署。每个架构都应根据你组织的规模、安全、网络和合规要求进行调整。在你的环境中这些模式可能组合或重叠的方式与其他人的不同这正是重点所在。开始使用这里描述的架构通过 OTLP 导出因此可与任何兼容后端一起使用。如果你还没有后端最快看到 telemetry 全流程的方法是使用 Elastic Observability —— 它原生接收 OTLP traces、metrics 和 logs无需额外配置。在 Elastic Cloud Serverless 上开始免费试用 —— 无需信用卡。将你的 collector 的 OTLP exporter 指向托管 OTLP endpoint。在几分钟内在 Kibana 中探索你的 traces、metrics 和 logs。深入学习资源Elastic 的托管 OTLP endpoint 文档EDOT Collector —— Elastic 版本的 OpenTelemetry CollectorOpenTelemetry Blueprints —— 交互式生成参考架构原文https://www.elastic.co/observability-labs/blog/opentelemetry-collector-reference-architectures