avuru obs vs. the alternatives
Most teams already run something for telemetry. This section is an honest look at how avuru obs compares to the tools you're most likely replacing — and how to migrate from each without a rewrite.
The short version of the pitch:
- One engine, not four. Traces, logs, metrics and continuous profiling land in the same ClickHouse store, so cross-signal correlation is just another query. See Architecture.
- eBPF auto-discovery. The
sensorruns upstream OBI for zero-code traces, and your service map is derived from those trace spans — no SDKs and no code changes. OBI'snetworkfeature covers un-instrumented edges; install the chart and the map lights up. - OpenTelemetry-native. Standard OTLP in and out. Whatever you run today almost certainly already speaks OTLP, so migration is usually a one-line exporter change. See the OTLP bridge.
- Self-hosted, fully open source (AGPL-3.0). Your telemetry never leaves your infrastructure, and cost tracks your cluster — not per-host or per-GB billing.
- Energy & carbon in the same engine. The opt-in green module attributes per-service Wh and gCO₂e (CNCF Kepler, RAPL) and correlates them with the telemetry you already collect — carbon budgets and a CSRD-ready export, computed on your own cluster. No mainstream APM — Datadog included — attributes carbon per service with zero code changes and no SaaS. See Green.
:::note Where avuru obs is today avuru obs is at v0.2. Traces, logs, RED metrics, continuous profiling, the service map, error tracking, service health, alerting, network health and the green module (per-service energy & carbon, opt-in) are live. The comparisons below say plainly what's shipping versus planned — see Feature status. :::
At a glance
| You run today | Category | What avuru obs changes | Read |
|---|---|---|---|
| Jaeger | Distributed tracing | Adds logs (+ metrics/profiling) in one store; eBPF map with no SDK | vs Jaeger |
| Grafana stack (Loki/Tempo/Mimir) | Assembled OSS stack | One engine and one UI instead of four systems to operate | vs the Grafana stack |
| Prometheus | Metrics | Auto RED metrics correlated with traces & logs | vs Prometheus |
| Datadog / New Relic | Commercial SaaS APM | Self-hosted, no proprietary agents, no per-host bill — plus per-service energy & gCO₂e | vs Datadog |
| Sentry | Error tracking | Issues derived from the OTLP you already send, plus a drop-in Sentry SDK DSN — no per-event bill | vs Sentry |
| GlitchTip | Error tracking | Same Sentry ingest protocol, but errors unified with traces, logs & an eBPF map | vs GlitchTip |
| DeepFlow | eBPF + ClickHouse platform | Complete first-party UI and native error tracking on the same eBPF/ClickHouse base | vs DeepFlow |
| Coroot | eBPF + ClickHouse platform | Single ClickHouse for every signal, plus error tracking as a first-class module | vs Coroot |
| SigNoz | OTel + ClickHouse platform | Same OTel/ClickHouse base, plus a zero-code eBPF map, continuous profiling and no open-core gating | vs SigNoz |
| Apache SkyWalking | Language-agent APM | One ClickHouse and universal SQL instead of BanyanDB, plus a zero-code eBPF map | vs SkyWalking |
How migration works, in general
Because avuru obs is a drop-in OTLP backend, migrating from any OpenTelemetry-compatible source is the same three moves:
- Install avuru obs (
helm install) alongside what you run today. - Repoint your OTLP exporter (or OTel Collector / Grafana Alloy) at the avuru
gateway—:4318(HTTP) or:4317(gRPC). You can dual-export and run both in parallel while you validate. - Once the data looks right, cut over and decommission the old backend.
Full steps live in the OTLP bridge guide. Each page below adds the specifics for that tool.
:::tip Ready to try it? The fastest way to compare is side by side — install in 30 seconds and point one service at it. :::