Searching for an open source observability stack often lands you between two camps — assemble Grafana LGTM piece by piece, or adopt a unified observability platform open source teams can run themselves. This guide explains the Metrics / Logs / Traces pillars, compares modular vs all-in-one architectures with neutral examples, and offers a team-size selection matrix. You will see what a unified OpenTelemetry data plane looks like in practice so you can decide which pattern fits before committing storage and on-call workflows.
Modern production systems rarely fail with a single red light on a CPU chart. Incidents surface as slow checkout flows, partial outages in one region, or a dependency that looks healthy in isolation but breaks a critical path. That is why opensource observability discussions moved beyond “install Prometheus” toward full stacks that correlate signals. Below we walk the three pillars, contrast the LGTM modular path with unified APM platforms, map choices to team size, and examine one compact OTel-native design you can validate in an afternoon.
The three pillars: Metrics, Logs, and Traces
Observability rests on three complementary signal types, each answering a different question during an incident:
- Metrics — Which service is slow? Error rate spike? (RED: rate, errors, duration)
- Logs — What did the process print at failure time? Stack traces and business context
- Traces — Which hop in a distributed call caused latency? Narrow scope from service to span
They work best together: metrics raise the alarm, traces point to the subsystem, logs fill in details. OpenTelemetry standardizes how applications emit all three via OTLP — typically gRPC on 4317 or HTTP on 4318 — so instrumentation stays portable even when backends change.
In LGTM deployments, logs often land in Loki with label selectors tied to Kubernetes namespaces. Traces live in Tempo, keyed by trace ID. Metrics sit in Prometheus or Mimir with optional exemplars linking histogram buckets back to traces. The hard part is not ingestion — it is making an on-call engineer follow one identifier across three UIs at 2 a.m. Unified platforms try to collapse that navigation into service context: pick a red service, open its traces, pivot to errors — without re-entering queries in three places.
APM (application performance monitoring) is the application-centric slice of observability: service health, call chains, dependency maps, and error analytics. A mature observability platform open source deployment usually includes APM plus infrastructure and alerting views.
Two architecture patterns in 2026
Pattern A — Modular LGTM (Grafana ecosystem)
the Grafana LGTM stack combines Loki (logs), Grafana (visualization), Tempo (traces), and Mimir or Prometheus (metrics). It is the default mental model for Kubernetes-native teams that already run Prometheus and want maximum flexibility.
Strengths: deep ecosystem, pluggable storage, familiar dashboards.
Trade-offs: multiple stateful services, DIY correlation (trace ID in logs, exemplars in metrics), Grafana expertise for dashboard maintenance. Jaeger paired with Prometheus remains a lighter trace-plus-metrics variant when logs live in Loki separately.
Pattern B — Unified open source APM platform
All-in-one platforms ingest OTLP into a single storage and UI layer. Examples teams commonly evaluate include SigNoz (OpenTelemetry + columnar storage), Apache SkyWalking (mature community APM with strong Java and topology features), and newer OTel-native stacks that collapse ingest, storage, and web into a small footprint.
Strengths: faster time-to-value, correlated troubleshooting in one UI, fewer moving parts for small platform teams.
Trade-offs: less granular swap-out of individual databases; verify OTLP fidelity and exit strategy before standardizing retention.
LGTM modularity vs unified platform
- Components to operate — LGTM: 4+ (Loki, Grafana, Tempo, Mimir/Prometheus, often Collector). Unified: often 2–4 (ingest, storage, UI, optional AI layer).
- Correlation — LGTM: DIY trace IDs and dashboard links. Unified: built-in service → trace → error navigation.
- Customization — LGTM: high (pick storage per signal). Unified: moderate (opinionated data model).
- Best fit — LGTM: platform orgs with SRE/Grafana practice. Unified: product teams self-hosting with limited ops headcount.
- OTel alignment — Both can be OTel-native; prefer backends listed with Native OTLP on the OpenTelemetry Vendors page.
Neither pattern is universally “better.” Large enterprises often run LGTM at the infrastructure layer and a unified APM for application squads. Startups frequently want one install script and a single on-call UI.
Selection guide by team size
- 1–5 engineers, no dedicated SRE — Unified observability platform open source; validate OTLP ingest + service RED in one session.
- 5–20 engineers, part-time platform — LGTM if Grafana already standard; otherwise unified APM + external Prometheus for infra metrics.
- 20+ engineers, platform team — LGTM or hybrid; unified APM for app tiers; strict sampling/retention policies.
- Java-heavy legacy + greenfield OTel — Keep mature community APM for legacy; OTLP for new services; compare traces during parallel run.
Run the same acceptance script before you commit: point a demo app at OTLP, generate five minutes of traffic, confirm service list and topology render, search a slow trace, and document ports and RAM on your target VM.
What unified observability looks like in the UI
After OTLT ingest, you should see service-level RED and dependency topology derived from traces — not a separate manual CMDB.
Service RED overview
Figure 1 · Service health overview (Rate, Errors, Duration)
Global topology from traces
Figure 2 · Auto-drawn dependency map
Trace search
Figure 3 · Trace-derived service flow and dependencies
These views are table stakes for any open source observability evaluation: if you cannot get here in one working session, the stack will fight you in production.
Example: unified OpenTelemetry data plane (DataBuff)
DataBuff is one illustration of a compact opensource observability stack built on OpenTelemetry. It appears on the OpenTelemetry Vendors page as Pure OSS with Native OTLP Yes — meaning it consumes OTLP for end-user APM workflows, not only as a collector distribution.
Architecturally it uses three runtime components:
- Ingest — OTLP gRPC/HTTP intake and trace assembly
- Apache Doris — unified columnar storage for traces and minute-level service metrics
- Web platform — dashboards, topology, alerting, and AI-assisted investigation on the same telemetry
Figure 4 · Ingest → Doris → Web — minimal moving parts
Design choices worth verifying in any unified backend:
- Metrics derived from traces — one ingestion path, lower agent overhead
- Minute-level pre-aggregation — faster RED queries and alert evaluation
- AI on live telemetry — natural-language queries against the same trace store (not a disconnected chat window)
Capabilities still on the public roadmap include full OTLP logs ingestion, eBPF zero-instrumentation collection, and expanded agent observability — treat those as planned until shipped in your target version.
Quick validation checklist
For any shortlisted observability platform open source candidate:
- Install via published script or compose manifest; note exposed ports (DataBuff documents web UI on 27403 and OTLP on 4317/4318).
- Point OpenTelemetry SDKs at
http://YOUR_HOST:4318/v1/traces. - Confirm services, topology, and trace search within one working session.
- Check alert rules and a global dashboard if on-call is in scope.
- Record retention, sampling, and RAM on an 8 GB VM if that matches your target footprint.
The project publishes a one-line Docker install from its homepage; Kubernetes manifests follow the same three-component model. Your instrumentation stays standard OTel — swapping backends should not require re-writing application code.
FAQ
Is Grafana LGTM still the default for Kubernetes?
For infrastructure-centric teams, yes — Prometheus scraping and Grafana dashboards remain the lingua franca of cluster monitoring. Application-centric observability often adds Tempo and Loki, or a unified APM layer when trace-to-log correlation becomes a daily workflow.
What makes an observability platform “open source” in practice?
You can inspect code, self-host without vendor lock-in, and extend ingest or storage. Compare operability: component count, documented ports, and whether Native OTLP is first-class for your language SDKs.
How does SigNoz or SkyWalking fit this picture?
Both are widely referenced community options — SigNoz as an OTel-native unified backend, SkyWalking as a mature APM with rich topology in Java-heavy environments. Neutral evaluation should focus on OTLP coverage, storage ops, and whether your team wants modular LGTM alongside or instead of an all-in-one UI.
Where do AI features belong?
Treat AI-assisted triage as valuable only when it queries the same telemetry store your engineers trust. Generic chat on top of static dashboards adds little during incidents; grounded answers tied to spans and RED metrics can shorten mean time to innocence.
Takeaways
- Open source observability starts with Metrics, Logs, and Traces — know which pillar answers which question during incidents.
- LGTM maximizes modularity for teams with Grafana depth; unified APM minimizes moving parts for smaller ops budgets.
- Match architecture to team size and existing skills — not to a generic feature matrix.
- Validate Native OTLP ingest, correlated UI, and operable storage with a repeatable POC before locking retention.
- For a three-component OTel-native example with dashboard, RED services, topology, and trace search on one data plane, evaluate DataBuff alongside SigNoz, SkyWalking, and your current LGTM pieces.
References: OpenTelemetry observability primer · OTLP spec · Grafana application observability · Vendors list · DataBuff on GitHub · Public demo
Top comments (0)