Celebrating! This Open-Source CN Project Is Now an Official OpenTelemetry Vendor

OpenTelemetry · Vendors Ecosystem · AI Native · DataBuff

DataBuff is the second China-built open-source professional APM — after SkyWalking — to appear on the OpenTelemetry official Vendors page, marked as Native OTLP. Why did the community list it? What does it mean for teams still choosing an OTel backend? This article includes demo screenshots and walks through standards, architecture, and AI-powered troubleshooting.

OpenTelemetry (OTel or OTLP) is a CNCF-hosted, vendor-neutral observability standard. CNCF's 2025 project velocity report shows OTel commits up 39% year over year, contributors +35% — making it the second-largest CNCF project after Kubernetes. Contributors include AWS, Microsoft, Google, Splunk, Dynatrace, New Relic, and other industry leaders.

The OpenTelemetry website maintains a Vendors ecosystem list — observability backends that natively consume OTLP telemetry for end users. Think of it as a publicly verifiable whitelist.

In the Pure OSS group, DataBuff is marked Open Source Yes, Commercial No, Native OTLP Yes, with Learn more linking to OTLP integration docs.

DataBuff Tagline: AI Native OpenTelemetry APM

The project's goal is to help enterprises move from application performance observation to performance governance, and ultimately to autonomous operations — emphasizing the technical value of AI-native capabilities in SRE workflows.

3.1 Minimal Architecture

DataBuff uses a minimal three-component design: Ingest → Doris (storage) → Web (platform).

No traditional Elasticsearch + Kafka + microservices stack. One Docker command gets the demo running. The direct payoff: fewer ops components, runs on 8 GB RAM, and a single storage entry point for AI queries — the engineering foundation for an AI-native OpenTelemetry APM.

3.2 OpenTelemetry-Native Capabilities

Fig. 1 · Service List & RED Dashboard

The Application Performance module directly consumes Traces and Metrics reported via OTLP from the OTel SDK, aggregating RED metrics and visualizing service dependencies on the platform — no proprietary agent protocol required. It shows request volume, response time, and error rate for each service, with trend curves for health comparison — the core troubleshooting entry point after OTel Metrics land in storage.

Fig. 2 · Global Topology

Automatically draws service and middleware dependency graphs from Span parent-child relationships in Traces. Node colors indicate health status — get a full system view without manually maintaining a CMDB.

3.3 AI-Native Capabilities

Many tools treat AI as a generic chat window. The DataBuff AI Platform is different: Skills invoke platform tools to directly query OTel data stored in Doris. Below is a fault-diagnosis example of its AI-native capabilities.

Fig. 3-1 · Ask About a Service Failure

Fig. 3-2 · AI Fault Deduction Tree

Fig. 3-3 · AI Root Cause Analysis

Fig. 3-4 · AI Remediation Advice & Summary

Describe an anomaly in natural language in the AI chat (e.g., "A topology node turned red — help me diagnose the cause") to trigger multi-expert collaborative analysis. The AI brain automatically dispatches inspection and data-query experts, pulls service latency trends, cross-validates topology and traces, and outputs a structured diagnostic report with remediation advice — translating distributed tracing data into actionable troubleshooting paths.

[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/