OpenTelemetry Collector 2025 用户调查：65% 用户已部署超 10 个实例
2026 年 1 月，OpenTelemetry 官方博客发布了一份 2025 年 Collector 用户跟踪调查分析，由 Datadog 和 Grafana Labs 的社区成员联合执笔。这份调查是对 2024 年初次调查的年度回访，覆盖部署规模、环境分布、自定义模式、组件流行度和运维痛点。数据相当扎实——毕竟，OpenTelemetry Collector（下称 OTel Collector）如今是云原生可观测性领域最主流的遥测数据接入组件，它的用户怎么用它，直接反映整个行业的实践水位。
部署规模持续膨胀：65% 用户跑着超过 10 个 Collector
先看规模。2025 年调查显示，65% 的用户在生产环境运行着超过 10 个 Collector，比 2024 年高出 10 个百分点；2~5 个的占比降到 15%。部署环境也明显”混合化”：Kubernetes 依旧占据绝对主导（81%，与去年持平），但虚拟机（VM）使用率从 33% 猛增到 51%，裸金属也升到 18%。更值得注意的是，小规模用户（Collector 数小于 100）中有四分之一、大规模用户（大于 100）中约有半数同时使用 K8s 和 VM——”云原生加传统环境”共存，远比文档里的理想场景普遍。
K8s 里的两大经典姿势：网关与 DaemonSet
在 Kubernetes 场景里，部署模式已经趋于稳定：58% 的用户把 Collector 作为网关（集中式接入层）部署，50% 采用 DaemonSet（每节点一个，常用于日志与节点指标采集），23% 是 sidecar，14% 用 StatefulSet。各项数字与去年相比变化都在 1~7 个百分点以内，说明这些姿势已经沉淀为社区共识。
46% 的用户在”自造” Collector
变化最值得关注的是自定义趋势。46% 的用户会构建自己的 Collector 发行版，同比提升 13 个百分点；其中 86% 使用官方 Collector Builder（OCB）来生成。但体验评价并不乐观：只有 39% 的受访者有信心地说 Builder 好用，21% 明确表示难用——而去年这个数字是 2。自造的意愿在涨，工具的体验却没跟上，这中间存在明显的落差。
谁在看”看门人”？Collector 的自我监控
Collector 负责汇聚全公司的遥测数据，但它自己被监控了吗？调查显示约 23% 的用户完全不监控自己的 Collector（较去年下降 6 个百分点，算进步）。在监控它的用户中，83% 采集其内部指标，61% 采集日志，仅 25% 采集链路。交叉分析还有一个有意思的结论：运行 100 个以上 Collector 的大规模用户几乎都会采集指标，但很少采集链路——规模越大，越倾向于”看数字”而非”看调用链”。
组件流行度此消彼长
组件层面的变化同样有信息量：接收器端，filelogreceiver、k8sclusterreceiver 和 filereceiver 使用率上升，说明日志采集与 K8s 集群指标是当前最活跃的方向；处理器端，attributesprocessor 和 transformprocessor 上升，memorylimiterprocessor 下降；导出器端，otlphttpexporter 和 datadogexporter 上升，lokiexporter 下降；连接器端，routingconnector 和 datadogconnector 上升；扩展端，Storage、zpages 和 filestorage 使用增加。整体看，”先本地落盘、再按需路由”的管道设计正在成为主流思路。
用户最想要什么改进
在”希望改进什么”的开放题中，前三大诉求非常集中：63% 的用户点名配置管理与动态重配置——最高频的吐槽是”改一条 pipeline 不该重启整个 Collector”；52% 要求提升稳定性；43% 希望 Collector 自身的可观测性做得更好。此外，用户还反复提到文档质量（包括非英语社区的资源）、自定义 exporter 的学习曲线过于陡峭、生态组件缺口（比如 awscloudwatchmetricsreceiver 没有维护者）、以及需要更强的健康检查与向后兼容保证。
小夏点评
第一，Collector 已经从”工具”毕业成”基础设施”了。65% 的用户跑着 10 个以上实例，大规模部署占比逐年提高——它不再是随便塞个 sidecar 就行的遥测组件，而是需要容量规划、版本升级策略和故障演练的生产系统，运维投入要按基础设施的标准来配。
第二，混合部署才是真实主战场，不是纯云原生。K8s 占 81%、VM 冲到 51%，且大量公司两者都有。可观测性架构设计必须兼容新旧栈共存，把 VM 上的采集路径（filelog、filereceiver）当一等公民来设计，而不是 K8s 的附属品。
第三，”自造热情”与”工具体验”的落差是社区最大的债。46% 的用户在构建自定义发行版，可 61% 的人无法肯定 Builder 好用。这个缺口对使用者是直接的运维成本——选型自定义方案时，建议先评估团队写 Go 插件和跟进社区变更的能力。
对中国 IT 运维者的启示：国内企业普遍是”K8s + 传统机房/VM”的混合架构，这份调查的样本结构其实非常贴近我们的现实。三点可操作建议：一是遥测管道现在就按 OTel 标准建设，用 Collector 做统一接入，避免被单一厂商的专有 agent 锁死；二是直接借鉴网关 + DaemonSet 的双层部署模式，集中链路、分布采日志；三是务必给 Collector 自己配监控——至少采集内部指标、配好健康检查与告警，别让”看门人”自己变成盲区。
