DataBuff is an AI-native APM backend built on OpenTelemetry that ingests traces, metrics and logs over OTLP and ships with multi-agent AI troubleshooting out of the box, aimed at teams that self-host observability for microservices.

What it is

DataBuff is an application performance monitoring backend written in Java and released under the AGPL-3.0 licence. It ingests telemetry through OTLP — gRPC on 4317 and HTTP on 4318 — covering traces, metrics and logs, and supports dual-protocol ingestion with SkyWalking native gRPC on 11800, so an existing exporter can be pointed at DataBuff by changing the exporter address. On top of that ingestion layer it provides full-stack monitoring, service call-graph topology, RED metrics, threshold alerting with scheduled evaluation and alert event history, and an eBPF APM collection path that gathers call chains and performance data at kernel level without code changes. The repository is listed on the OpenTelemetry official Vendors page as a Native OTLP backend and on the CNCF Landscape, and the project's stated mission is to build the strongest OpenTelemetry APM backend rather than another observability UI.

The concrete problem it solves is the separation between telemetry storage and AI assistance. DataBuff puts the model on the live telemetry path: LLMs query traces, metrics, topology and alerts directly, so the flow from natural-language query through multi-agent inspection to root-cause analysis and operations remediation sits inside the same deployment. The README is explicit that this is not a chat box bolted onto a dashboard, and that the AI answers from real telemetry rather than generated content. Because it is OTLP-native, existing instrumentation is used as-is, and the SkyWalking compatibility path gives teams a migration route off an existing SkyWalking deployment rather than a parallel stack.

Key capabilities

• OTLP-native ingestion for traces, metrics and logs on gRPC 4317 and HTTP 4318, with SkyWalking native gRPC on 11800 as a second protocol.
• Multi-agent collaboration out of the box, where an AI Brain orchestrates query, inspection, ops and Q&A experts, dispatching complex tasks in parallel and synthesising an incident report.
• Bring-your-own-model support for Kimi, DeepSeek, GLM, Ollama and other OpenAI-compatible APIs, configured by adding an API key after installation.
• MCP in both directions: DataBuff exposes its capabilities to Cursor and Claude, and can ingest external MCPs such as Prometheus.
• eBPF APM collection at kernel level, producing call chains and performance data without code changes.
• Alerting loop with threshold detection, scheduled evaluation and alert event history.
• Skill extensibility for custom digital experts without modifying core code.

Who uses it and how

• Platform and SRE teams running microservices that already emit OTLP and want a self-hosted APM backend rather than a hosted vendor.
• Teams migrating from SkyWalking, which can switch export to DataBuff's gRPC endpoint on 11800 without reinstrumenting services.
• Incident responders who need a forwardable report: topology pulled, metrics ranked, bottlenecks attributed by share for the post-mortem.
• Engineering organisations that want AI troubleshooting but cannot send telemetry to a separate AI platform, since the model is configured in-place with an API key.
• Teams tracking AI application observability, for whom LLM call chains, token analytics, agent topology and skill/tool/model tracing are documented as a roadmap direction rather than a shipped feature.

Getting started

The stack is three components — Ingest, Doris and Web — with no middleware sprawl, and the README states that one Docker command runs it. A live demo is available at demo.databuff.ai, and setup is documented in docs/README_en.md.

How it compares

Among the tools named in the facts, the closest comparison is Apache SkyWalking, which DataBuff supports as a native gRPC ingestion protocol on 11800, positioning itself as a compatible destination for a SkyWalking migration rather than a replacement that requires new instrumentation. Beyond that, DataBuff distinguishes itself from a plain OpenTelemetry backend by treating natural-language querying and multi-agent inspection as part of the product instead of an external AI platform.

When to use it — and when not to

A self-hoster operates three components — Ingest, Doris and Web — and supplies an API key and budget for an OpenAI-compatible model provider, so the operational surface includes a database (Doris) alongside the application. Teams that cannot run a stateful analytical database, or that require a fully hosted, managed service, should look elsewhere, and organisations that would embed the code in a closed-source product need to weigh the AGPL-3.0 licence. The honest constraints in the current facts are the roadmap status of AI application observability and the small contributor base implied by 683 stars, 136 forks and 11 open issues.

curl -fsSL https://databuff.ai/databuff/ai-apm-install.sh | bash

curl -fsSL https://databuff.ai/databuff/ai-apm-demo-install.sh | bash

tar -zxvf databuff-ai-apm-offline-<version>-<arch>.tar.gz
cd databuff-ai-apm-offline-<version>-<arch> && sudo ./install.sh

curl -fsSL https://databuff.ai/databuff/ai-apm-k8s-install.sh | bash
curl -fsSL https://databuff.ai/databuff/ai-apm-demo-k8s-install.sh | bash  # demo optional