可喜可贺！这款国产开源成为 CNCF 顶级项目官宣Vendor

OpenTelemetry · Vendors 生态 · AI 原生 · DataBuff

DataBuff 成为 SkyWalking 之后，第二款登上 OpenTelemetry 官网 Vendors 的国产开源专业 APM —— 标注 Native OTLP。它凭什么获得社区收录？对还在纠结 OTel 后端选型的团队意味着什么？本文附 Demo 实拍，从标准、架构到 AI 排障三条线说清。

OpenTelemetry（简称 OTel 或 OTLP）是 CNCF 托管的厂商中立可观测标准。CNCF 2025 项目增速报告显示，OTel commit 一年增 39%，贡献者 +35%，已是仅次于 Kubernetes 的第二大 CNCF 项目。项目贡献者包括 AWS、微软、谷歌、Splunk、Dynatrace、New Relic 等一众行业头部厂商。

OpenTelemetry 官网维护 Vendors 生态名单——收录通过 OTLP 原生消费遥测、面向终端用户的可观测后端，相当于一份可公开验证的白名单。

Pure OSS 组里，DataBuff 标注开源 Yes、商业 No、Native OTLP Yes，Learn more 指向 OTLP 接入文档。

DataBuff 的口号：AI Native OpenTelemetry APM

项目的目标是帮助企业从应用性能观测，走向应用性能治理，最终实现应用的自主化运维，强调 AI 原生能力在 SRE 作业中发挥的技术价值。

3.1 极简架构

DataBuff 采用极简三组件设计：Ingest（接入）→ Doris（存储）→ Web（平台）。

没有 Elasticsearch + Kafka + 多微服务的传统堆砌，Docker 一条命令即可跑通 Demo。架构极简的直接收益是：运维组件少、单机 8G 可跑、AI 查询也只需一个存储入口，这是「AI 原生 OpenTelemetry APM」的工程底座。

3.2 OpenTelemetry 原生能力

图 1 · 服务列表与 RED 大盘

应用性能模块直接消费 OTel SDK 经 OTLP 上报的 Trace 与 Metrics，在平台侧完成 RED 指标聚合与服务依赖可视化，不依赖私有探针协议。集中展示各服务的请求量、响应时间与错误率，并附趋势曲线对比健康度——这是 OTel Metrics 入库后的核心排障入口。

图 2 · 全局拓扑

依据 Trace 中的 Span 父子关系自动绘制服务与中间件依赖图，节点颜色标示健康状态，无需手工维护 CMDB 即可把握系统全貌。

3.3 AI 原生能力

许多工具的 AI 只是通用聊天窗；DataBuff AI 平台的差异在于：通过 Skill 调用平台工具，直接查询 Doris 里已入库的 OTel 数据，下面以故障诊断为例来说明它的 AI 原生能力。

图 3-1 · 询问服务故障原因

图 3-2 · AI 给出故障推导树

图 3-3 · AI 给出根因分析

图 3-4 · AI 给出处理意见及总结

在 AI 对话中用自然语言描述异常（如「拓扑节点变红，帮我诊断原因」），即可触发多专家协同分析。AI 大脑自动派发巡检与问数专家，拉取服务耗时趋势、交叉验证拓扑与链路，输出结构化诊断报告与处置建议——将分布式追踪数据翻译为可执行的排障路径。

[1] https://www.cncf.io/blog/2026/02/09/what-cncf-project-velocity-in-2025-reveals-about-cloud-natives-future/

[2] https://opentelemetry.io/ecosystem/vendors/

[3] https://github.com/databufflabs/databuff

[4] https://github.com/databufflabs/databuff/blob/master/deploy/docker/README.md

[5] https://databuff.ai/databuff/ai-apm-install.sh

[6] https://github.com/databufflabs/databuff/blob/master/docs/产品介绍.md

[7] https://github.com/databufflabs/databuff/blob/master/docs/Roadmap.md

[8] https://demo.databuff.ai/