Observability with OpenTelemetry: Metrics, Logs and Distributed Tracing

OpenTelemetry unifies the collection of metrics, logs and traces in a single SDK, facilitating end-to-end observability of distributed systems. By 2025, adoption of this standard will allow teams to monitor cloud, edge, and on-premises applications with a consistent pipeline.

Why choose OpenTelemetry?

Standardization, unified APIs for different languages (Java, Node.js, Go, Python).
Flexibility, configurable exporters for Prometheus, Jaeger, Grafana Loki, etc.
Scalability, high frequency collection without impacting performance.
Integration with Cloud Providers, native support for AWS X-Ray, GCP Cloud Trace, Azure Monitor.

Main components

Collector, agent that receives instrumentation signals and forwards them to back-ends.
SDK, libraries that instrument code (self-instrumentation or manual).
Exporters, adapters that send data to storage/visualization systems.

How signals flow

Each service instrumented with the OpenTelemetry SDK sends its signals to a central Collector. Collector works as a single collection point and routes data to the appropriate back-ends: metrics go to Prometheus, traces to Jaeger and logs to Grafana Loki. Prometheus, in turn, powers Grafana dashboards. This design decouples instrumentation from storage tools, allowing you to swap or add back-ends without touching application code.

Automatic vs manual instrumentation

Self-instrumentation, just enable the agent (OTEL_EXPORTER_OTLP_ENDPOINT) and the SDK captures HTTP, DB, gRPC.
Manual instrumentation, creates customized spans for critical business logic.

In the case of manual instrumentation, the logic is simple: the application obtains a named tracer, opens a span at the beginning of the business operation that you want to observe and closes it at the end, even in the case of an error. This span captures the execution time and any relevant custom attributes, giving granular visibility into critical points in the flow.

Configuring the Collector

The Collector configuration is organized into three blocks. First, receivers define how signals arrive, typically via OTLP, accepting both gRPC and HTTP. Then, the exporters point to the destinations: an endpoint for Prometheus to expose metrics and another for Jaeger to receive traces. Finally, the service block ties everything into pipelines, declaring that the metrics go from the OTLP receiver to the Prometheus exporter and the traces, from the same receiver to Jaeger. This separation between reception, processing and export is what makes Collector flexible.

Observability best practices

Context propagation, keep traceparent in HTTP headers.
Sampling, adjust sampling rate to avoid overload (e.g. 10% in production).
Attribute enrichment, include service.name, environment, version.
Alerts based on SLIs/SLOs, use latency and error rate metrics.

Implementation checklist

Install SDK in applications (Node, Java, Go, Python).
OpenTelemetry Collector deployment (Kubernetes DaemonSet or sidecar).
Configure exporters for Prometheus, Jaeger and Loki.
Define sampling and retention policies.
Create dashboards in Grafana (latency, throughput, errors).
Configure alerts in Alertmanager.
Document trace patterns and attributes.

Conclusion

OpenTelemetry offers a unified solution for observing complex systems, reducing tool fragmentation and enabling correlation between metrics, logs and traces. By implementing the practices described, your team gains complete visibility and can act proactively on incidents.

Do you already use OpenTelemetry? Share your experiences in the comments!