Same-host lab: DataBuff (OTLP :4318) and SigNoz (OTLP :24318) side by side on the same Demo (service-a / service-b). Host: 192.168.50.140 · DataBuff v0.1.4 · SigNoz v0.133.0. Marks: ✅ verified in this lab · △ present but limited · ❌ no equivalent. Green bold cells are clear DataBuff leads.
Seven AI capabilities (v0.1.4: See → Squad → Inspect → Diagnose → Repair → Predict → Answer)
| Capability | SigNoz v0.133.0 | DataBuff v0.1.4 |
|---|---|---|
| ① See · natural-language questions | ❌ | ✅ Ask about services / topology / trends; AI reads telemetry |
| ② Squad · multi-agent collaboration | ❌ | ✅ Parallel evidence gathering; reusable task orchestration |
| ③ Inspect · service inspection + report | ❌ | ✅ One-shot inspection with evidence and actions |
| ④ Diagnose · bottleneck / RCA evidence | ❌ | ✅ Trace / metrics / topology evidence (not a black-box “root cause”) |
| ⑤ Repair · Ops Expert actions | ❌ | ✅ Repair under policy + human approval; dangerous-command denylist |
| ⑥ Predict · capacity / trends | ❌ | ✅ Capacity and trend analysis — from after-the-fact to ahead-of-time |
| ⑦ Answer · product Q&A | ❌ | ✅ Answers deploy / ingest / config from docs and code |
| Extend · MCP / Skill / custom experts | ❌ | ✅ External MCP / Skill and custom digital experts |
Largest gap: SigNoz has no equivalent AI platform; DataBuff exposes the seven capabilities as configurable home entries with APM as AI context.
APM
| Capability | SigNoz v0.133.0 | DataBuff v0.1.4 |
|---|---|---|
| 1. Global topology | ✅ Service Map (incl. middleware nodes) | ✅ Topology + health colors + drill-down |
| 2. Service list & golden metrics | ✅ Services (P99 / Error / OPS) | ✅ Service list + charts; same demo shows service-a / b |
| 3. Service-level topology | △ Via Service Map only; no dedicated page | ✅ Dedicated service topology |
| 4. Service call analysis (up/downstream + Trace) | ❌ | ✅ Upstream/downstream structure, latency/contribution; drill to Trace |
| 5. Instance golden metrics | ❌ | ✅ Instance golden-metric charts / list |
| 6. Instance topology | ❌ | ✅ Dedicated instance topology |
| 7. Instance call analysis (up/downstream + Trace) | ❌ | ✅ Per-instance up/downstream + Trace |
| 8. Endpoint topology | ❌ | ✅ Dedicated endpoint topology |
| 9. Endpoint call analysis (up/downstream + Trace) | ❌ Mostly Traces filters | ✅ Per-endpoint caller/callee + Trace |
| 10. Service flow (service / endpoint Trace contribution) | ❌ Service Map answers “who connects” | ✅ Response contribution from entry |
| 11. Middleware / external pages (DB / cache / MQ / external) | ❌ Nodes only, no dedicated depth | ✅ Dedicated pages: DB / cache / MQ / external |
| 12. Error analysis (stats + endpoint) | ❌ Mostly Traces filters | ✅ Error stats + endpoint drill-down |
| 13. Trace list / search | ✅ Traces Explorer | ✅ Charts + list, multi-dimension filters |
| 14. Trace detail | ✅ Span timeline / attributes | ✅ Call-order waterfall + Span attributes |
| 15. Trace Span → logs | ✅ From Trace detail | ✅ Top “Log analysis” + Span Logs / Logs tab |
| 16. Log list / search | ✅ Logs Explorer | ✅ Log analysis |
| 17. Log detail | ✅ | ✅ |
| 18. Log → Trace | ✅ Log → Trace | ✅ Log → Trace, down to Span |
| 19. Custom dashboards | ✅ Dashboards V2 (Perses / PromQL) | ❌ Not yet |
Basics (incl. Span↔logs) exist on both sides; DataBuff leads on call analysis, service flow, dedicated pages, error depth, and Log→Trace down to Span. SigNoz’s clear strength is custom dashboards.
Alerting
| Capability | SigNoz v0.133.0 | DataBuff v0.1.4 |
|---|---|---|
| How rules are configured | ✅ Alert Rules UI | ✅ Alert center |
| Threshold alerts | ✅ | ✅ Managed in platform |
| Period-over-period (WoW/MoM) alerts | ❌ | ✅ Period-over-period entry linked with APM metrics |
| Alert event list | ✅ Triggered Alerts; firing in this lab | ✅ Non-empty in this lab |
| Alerts linked to service / middleware | △ Notifications; stitch APM yourself | ✅ List links back into APM |
Both sides have alerting; this lab has a SigNoz threshold rule firing. Gaps remain on period-over-period alerts and alerts that carry service / middleware APM context.
When to pick which
| Scenario | Better fit | Note |
|---|---|---|
| Same OTel data, want AI / APM pages first | DataBuff (side-by-side) | Point OTLP at DataBuff |
| Need the seven AI capabilities | DataBuff | No SigNoz AI platform |
| MCP / Skill / custom experts | DataBuff | No such layer in SigNoz |
| See who slows the entry response | DataBuff | Service flow + contribution |
| Call analysis → Trace (service / instance / endpoint) | DataBuff | No SigNoz path |
| Slow SQL / cache / MQ pages | DataBuff | SigNoz mostly map nodes |
| Custom dashboards / PromQL boards | SigNoz | Dashboards V2; DataBuff not yet |
| Mature Trace / Logs Explorer only | Either / lean SigNoz | No need to migrate for brand |
Boundary: Deep SigNoz Dashboard / PromQL workflows → stay on SigNoz. DataBuff fits same OTel data + AI + APM depth, side-by-side or gradual switch.
2. Screenshot evidence (explains the tables)Screenshots from 192.168.50.140. Captions map to capability rows.
Seven AI capabilities
Services & topology
Fact check: SigNoz Service Map also draws middleware nodes. The gap is dedicated-page depth plus call analysis / service flow.
Call analysis & service flow
Trace
Log
Dashboards (SigNoz strength)
DataBuff dedicated pages
Alerting
GitHub: https://github.com/databufflabs/databuff