OpenTelemetry: Stable Logs for Complete Telemetry
Actualizado: 2026-05-03
OpenTelemetry (OTel) has moved at two speeds for years. Distributed traces matured first, inheriting work from OpenTracing and OpenCensus and solving a problem nobody else was solving well. Metrics arrived next with their own data model. Logs, however, wore the “in development” label for too long, and the community got used to an uncomfortable sentence: “OTel for traces and metrics, Fluent Bit or Filebeat for logs.” That sentence stopped being true in July 2024. The project’s technical committee declared both the Logs Data Model 1.0 and the OTLP logs protocol stable, and the core SDKs (Java, Go, Python, .NET) marked their logs API as GA.
Key takeaways
- OTel Logs GA means a frozen data model and backward-compatibility guarantees: instrumenting logs with OTel is no longer a technical bet.
- Automatic correlation (trace_id and span_id injected into the LogRecord) turns a fifteen-minute investigation into a hyperlink.
- The OTel Collector as hub enables fan-out: the same log can go to Loki for search and to a SIEM for compliance without duplicating instrumentation.
- Migration from Fluent Bit or Filebeat can be gradual and non-disruptive thanks to Fluent Forward and Filelog receivers.
- If your stack already works well with Fluent Bit + Loki, there is no urgency to migrate: OTel Logs GA is an invitation, not an ultimatum.
What “stable” means here
The CNCF applies a strict bar: a stable signal means a frozen data model, a protocol with backward-compatibility guarantees, and SDKs with public APIs that will not change without a formal deprecation cycle. For platform teams this translates into something concrete: instrumenting logs with OTel is no longer betting on an evolving technology. The collector has supported log pipelines in production for months, and exporters into Loki, Elasticsearch, Splunk, Datadog, AWS CloudWatch and GCP Cloud Logging no longer carry alpha labels. Bridge APIs for existing loggers (Log4j, java.util.logging, Python’s logging module, Go’s log/slog in 1.21+) allow adoption without rewriting application code.
Why unifying the three signals matters
Modern observability rests on three telemetry types with distinct purposes:
- Metrics: what is happening? Low cardinality, predictable cost.
- Traces: why is it happening in this specific request? Causal context, sampled.
- Logs: what exactly happened, with which values, on which line? High fidelity, heavy volume.
The historical problem is that the three signals travelled through separate pipelines, with separate agents and separate formats. Correlating a log with the trace that produced it required extracting a trace_id from the message body with a regex, pasting it into a Jaeger UI, and crossing fingers that clocks were in sync.
OTel solves this by design. When an application emits a log inside an active span, the SDK automatically injects trace_id and span_id into the LogRecord. Once that record reaches Grafana, Kibana or any compatible frontend, the log appears with a direct link to the parent trace. That “click and jump” changes the debugging experience radically: the question “which request caused this error?” turns from a fifteen-minute investigation into a hyperlink.
Architecture and migration
The typical architecture places an OTel Collector as a DaemonSet on Kubernetes or a systemd service on VMs. Applications send logs to it over OTLP, either gRPC (port 4317) or HTTP (port 4318), and the collector applies processors before exporting:
receivers:
otlp:
protocols:
grpc:
http:
processors:
batch:
attributes:
actions:
- key: deployment.environment
value: prod
action: insert
exporters:
loki:
endpoint: http://loki:3100/loki/api/v1/push
service:
pipelines:
logs:
receivers: [otlp]
processors: [batch, attributes]
exporters: [loki]A strength of the collector is fan-out: the same log can simultaneously go to Loki for cheap search and to a SIEM for compliance, with no duplicated instrumentation in the application.
For teams already running Fluent Bit or Filebeat, migration can be gradual and non-disruptive. The collector accepts fluent_forward and filelog receivers, letting existing agents keep running while new applications start speaking OTLP directly. First the collector becomes the shared destination; then applications migrate one by one; finally legacy agents retire once coverage is complete.
The payoff appears when the stack converges: one binary handling traces, metrics and logs, with identical resource attributes (service.name, service.version, deployment.environment, k8s.pod.name) across all three signals. Cross-signal queries stop being an archaeology exercise. This convergence is especially valuable alongside Parca for the fourth signal: CPU profiles.
Practical considerations
Storage cost does not vanish by using OTel; logs still consume space in whichever backend you pick. What changes is the ability to act on that cost from a single chokepoint: the collector supports sampling (head-based at source, tail-based after buffering), noisy-attribute filtering and sensitive-data redaction before anything leaves the host.
Cardinality remains the old enemy: attributes with highly variable values (request_id, user_id) are just as problematic in logs as in metrics. Treating high-cardinality identifiers as part of the message body rather than as indexed attributes is the correct practice.
The learning curve is real. OTel introduces its own vocabulary (signal, resource, instrumentation scope, log record) that overlaps classic logging concepts. Time invested in reading the project’s semantic conventions[1] pays back quickly: they are the glue that makes a dashboard built by one team reusable by another.
When not to migrate yet
If the current Fluent Bit + Loki stack works well, with mature alerts and controlled cost, there is no imperative to migrate. The clear case for OTel Logs is greenfield: any new service gets instrumented directly with the OTel SDK. The middle case is hybrid: collector as hub, Fluent Bit still alive for legacy applications nobody will re-instrument. The ambitious case is a full migration, which only makes sense when the value of automatic trace correlation outweighs the per-application integration cost.
What is undeniable is that the ecosystem’s direction is now fixed. Observability vendors are aligning their agents with OTLP, frameworks are starting to ship native bridges, and teams picking tooling for the next five years are doing so knowing telemetry will speak OTel.
Conclusion
OpenTelemetry Logs GA closes the modern observability stack under a single protocol, a single data model and a single processing layer. Automatic trace correlation is the feature that irreversibly changes the debugging flow. Migration from Fluent Bit or Filebeat can be gradual without breaking anything. For new projects, OTel is the unambiguous default. For existing stacks that work, the transition can wait until the value of correlation justifies the integration effort.
