DEV Community

Cover image for Full-Link Monitoring Tools: OTLP Ingest and Unified APM in Practice
logan zhang
logan zhang

Posted on • Originally published at blog.csdn.net

Full-Link Monitoring Tools: OTLP Ingest and Unified APM in Practice

#opentelemetry #opensource #devops #apm

When teams evaluate full-link monitoring tools, the same questions keep coming up: Is Jaeger enough? Do we need SkyWalking? How do we assemble the LGTM stack? This guide maps the spectrum from trace-only backends to unified APM, then walks through a four-step acceptance path — topology → aggregate stats → single trace → dependency contribution — using OTLP ingest on ports 4317 (gRPC) and 4318 (HTTP).

Topics: distributed tracing · OTLP APM · open source observability · OpenTelemetry

The monitoring tool spectrum

Rather than a feature matrix (Dev.to and many MD renderers break on tables), here is how categories differ in practice:

  • Trace-only — Jaeger, Zipkin: distributed call chains; metrics and alerting usually live elsewhere.
  • Unified APM — SkyWalking, DataBuff: traces + metrics + topology + alerting in one platform.
  • Cloud-native assembly — Tempo + Prometheus + Loki + Grafana (LGTM): flexible, but you operate and wire dashboards yourself.

If your requirement explicitly says OpenTelemetry and full-link monitoring, prioritize an OTLP-native backend instead of a system that only supports legacy proprietary agents.

OpenTelemetry ingest essentials

Typical production path:

App (OTel SDK) → OTLP gRPC 4317 or HTTP 4318 → Ingest/Collector → Storage → Web topology & trace UI
Enter fullscreen mode Exit fullscreen mode

A common migration pattern is a dual-export Collector: one receiver forwards to an existing Jaeger while you parallel-run a new APM backend, then compare trace fields and topology consistency (Collector configuration).

Quick env vars for a demo service:

export OTEL_EXPORTER_OTLP_ENDPOINT=http://<ingest-host>:4318
export OTEL_SERVICE_NAME=demo-service
Enter fullscreen mode Exit fullscreen mode

Tool comparison (2026)

  • Jaeger — OTLP native; topology and span waterfall yes; best when you want a lightweight trace backend.
  • SkyWalking — OTLP supported; strong topology; mature Java microservice community.
  • LGTM — Tempo-native OTLP; topology via Grafana; familiar if your team already lives in Grafana.
  • DataBuff — OTLP as the primary path; auto topology; multi-protocol spans; unified service-flow contribution metrics.

Demo acceptance: topology to a single trace

The four screenshots below come from a DataBuff Demo (last 24 hours). They show the full drill-down loop teams should expect from a modern distributed tracing platform.

1. Architecture-level full-link view

Global service topology

Figure 1 · Global topology — Auto-drawn service-a → service-b edges across MySQL, Redis, Kafka, Elasticsearch, and remote HTTP. Node colors reflect health/alerts. First acceptance test for any full-link tool: can it show cross-service dependencies with zero manual CMDB?

2. Trace aggregate statistics

Trace overview dashboard

Figure 2 · Trace aggregates — Trace volume bars (~30 traces per 15 minutes in this demo), error counts (none here), and P50–P99 latency (P95 ~240 ms). Click a bar to jump into that window’s trace list — the bridge from SLA dashboards to individual requests.

3. Single-request span waterfall

Span waterfall for one checkout trace

Figure 3 · Span waterfall — TraceID 4b2a0a4c…, GET /demo/checkout, 240 ms total. Spans include Redis GET/SET, remote HTTP fraud check, service-b Dubbo/HTTP, MySQL SELECT, Elasticsearch search, Kafka publish — colored by Web/DB/Cache/MQ. This answers which segment or SQL slowed the request.

4. Service flow and response contribution

Service flow contribution chart

Figure 4 · Service flow — Entry service-a (240 ms / 2.9k calls) with downstream contribution: service-b 58%, Elasticsearch and MySQL ~8% each. Useful for on-call and capacity planning without opening every trace.

Install and POC 

curl -fsSL https://databuff.ai/databuff/ai-apm-install.sh | bash
Enter fullscreen mode Exit fullscreen mode
  • Web console defaults to port 27403
  • After ingest, validate the four views above in order: topology → trace stats → waterfall → service flow
  • If the Collector dual-writes to Jaeger, compare interface names and latency fields side by side

Quick selection guide

  • Trace only, minimal ops → Jaeger
  • Java microservices + mature OSS community → SkyWalking
  • Team already standardized on Grafana → LGTM
  • OTLP-native unified topology + waterfall + contribution → DataBuff

Takeaways

  • Full-link monitoring is not just trace search — you need topology, aggregates, span detail, and dependency contribution in one loop.
  • OTLP 4317/4318 should be the default ingest path in 2026 evaluations.
  • Run the same four-screenshot acceptance script on every shortlisted backend before you commit to retention and storage sizing.

References: OpenTelemetry Collector config · OTLP spec · Jaeger docs · DataBuff on GitHub · Install script

Top comments (0)