blog.6admin.io
guest@6admin.io:~$
observability, opentelemetry, tracing, devops, logs

Trace-first: when observability wants to take us back to logs

Can traces replace a large part of application logs? And if so, why is OpenTelemetry now proposing to deprecate its span events API in favor of the Logs API?

Between simpler APIs, signal correlation and architecture choices, the question deserves better than a turf war. Behind this change lies a very concrete issue: how do you quickly understand why an operation failed, without having to rebuild the context yourself from scattered data?

From metrics to traces: a logical evolution

Metrics are essential to track a system’s state: CPU load, memory, latency, error rate or saturation, they detect a degradation and track its evolution. But they are not always enough to explain what happened during a particular operation.

Logs provide more detail, they describe events, errors and situations encountered by the application. The problem is that this information can be heterogeneous, scattered across several services and difficult to correlate when it does not share a common context.

Distributed tracing offers another way to organize this information: a trace represents the path of an operation across one or more components. It groups spans, which describe steps of that path, their duration, status and attributes. Timestamped events can also be attached to a span.

The word deserves a pause, because no single French translation captures it and each of its senses sheds light on what it designates. A span is first a bay, the section of a bridge between two piers or of a frame between two supports, and it is also a reach, the distance an element crosses without support, or a wingspan, like that of a wing or a sail from one end to the other. It is also a duration, a lapse of time bounded by a beginning and an end, as in “time span” or “life span”, and as a verb, “to span” means to cover, extend over, cross, straddle or bridge. All these senses meet in the span of a trace, which is at once a bounded time interval, a step that straddles part of the path, and a bay among others in the bridge formed by the complete trace, with its child spans nesting there like so many shorter reaches. For lack of an equivalent that renders all of this, I will keep the English term, which the French OpenTelemetry documentation also keeps.

This organization makes it possible to place an error back within the flow of an operation instead of treating it as an isolated message.

In his August 2023 article, “Tracing avec OpenTelemetry : pourquoi c’est le futur (et pourquoi ça remplacera les logs)” , Michaël Corbin presents this approach and its possibilities. That article is what introduced me to OpenTelemetry and led me to think about the place traces could take in an observability architecture.

The idea is not simply to add another signal to an existing stack: it is to ask whether the context provided by a trace can make part of traditional logging less necessary.

From Linux monitoring to modern observability

My interest in monitoring took concrete form in 2012, when I joined the Linux team of a university data center, where I was in charge of monitoring and automation, among other things.

At the time, monitoring relied mainly on Zabbix, while system logging with syslog and rsyslog was another part of operations. These mechanisms served complementary needs: watching the state of machines, detecting anomalies and examining recorded events to dig deeper into diagnostics.

These tools need to be put back in their historical context. I am not talking here about modern distributed tracing, with trace and span context propagation between services: this was first and foremost system monitoring, log collection and operational automation, and the first attempts to correlate all of it.

That is also when people at university started talking seriously about ELK: Elasticsearch, Logstash and Kibana promised to finally centralize logs previously scattered across hundreds of servers and to query them other than through grep. That is where I ran my first experiments (ELK <3). I only really used it later, first in managed hosting of high-traffic web platforms for media companies, then in banking and market environments, where volume, retention and the ability to quickly pick up the thread of an incident across heterogeneous systems were no longer a comfort. In hindsight, that is probably where I felt the limit of the exercise most: centralizing logs is not enough to connect them, and we often ended up rebuilding by hand, from timestamps and more or less well-propagated identifiers, the path of a request that nobody had thought to describe.

But the fundamental question was already there: how do you go from noticing an incident to understanding its cause, without multiplying manual operations?

Tools and architectures have evolved since. Nagios and Centreon belonged to another period of my career, before the university merger. I later crossed paths with OMD, Shinken and Icinga over the course of my professional wanderings, coming back to Zabbix many times and eventually adopting Prometheus, Loki and Grafana in my environment.

In 2023, reading Michaël Corbin’s article gave me a new point of comparison for approaching this problem. I was then led to adopt OpenTelemetry in the context of Traefik’s evolution.

With Traefik v3, whose first stable release came out on April 30, 2024, tracing moved to a standardized approach around OpenTelemetry and OTLP, instead of relying on direct integrations with specific vendors such as Jaeger. That evolution was a concrete trigger for moving to OpenTelemetry in this environment.

Around 2025, my observability environment evolved toward a stack combining VictoriaMetrics, VictoriaLogs, Fluent Bit, OpenTelemetry and Grafana.

This journey does not mean that all these building blocks serve the same need, nor that one technology mechanically replaces the previous one: it illustrates continuity, that of making systems observable and diagnosis easier, while evolving the technical means used to get there.

Can a trace replace application logs?

In his January 2026 article, “Un exemple d’observability trace-first” , Michaël Corbin pushes the reasoning further by making traces the preferred entry point for investigation, since a properly instrumented application lets you find in its spans much of what used to be written to logs, whether execution context, technical or business attributes, errors or timestamped events.

Imagine an API that refuses an operation because the user lacks the necessary permissions: a conventional log would probably contain something like Authorization denied for user 123 on resource 456, which is useful but leaves many questions open. What operation was the user trying to perform, which service made the decision, how long did the request take, did other calls fail along the same path, and was the failure caused by a failing dependency or a business rule?

With suitable instrumentation, the trace provides some of these answers in a single context, since it can carry the relevant business attributes, the operation status, the steps traversed and the events that occurred during its execution, which avoids producing logs that would only repeat what the spans already contain.

Still, we must not fall into the opposite excess, because trace-first does not mean putting everything in traces! An overly chatty instrumentation inflates data volume, storage cost and query complexity. High-cardinality attributes weigh down some analyses, and business data such as personal identifiers brings its own confidentiality and retention constraints.

The real challenge is therefore to decide which information should be attached to an operation’s context, which belongs to independent events, and which would benefit from being aggregated as metrics.

March 2026, OpenTelemetry wants to unify event representation

On March 17, 2026, OpenTelemetry published a post announcing its intention to deprecate its span events API, “Deprecating Span Events API” , in order to favor the Logs API for representing events rather than keeping two distinct mechanisms capable of emitting similar information.

At first glance, the change seems reasonable, since span events and log records both carry structured data, timestamps and attributes, and maintaining two ways to represent comparable information always ends up producing differences in instrumentation, conventions and processing depending on SDKs or backends. The goal is therefore to reduce that duplication by standardizing events as logs, while keeping the ability to correlate them with traces.

It is nevertheless necessary to distinguish the data model, that is, the way an event is represented and produced by the application, from the investigation experience, in other words the way an operator will find that event in the context of a trace. A more uniform model can simplify APIs without making investigation simpler for all that.

That is precisely where my reservation lies.

The problem is not the format, but the investigation path

Take an authorization.denied event associated with an HTTP request: as long as it remains attached to a span, its context is immediate and the trace is enough to find the relevant step and the rest of the path.

If it becomes a log record exported separately, several questions arise. Does the log keep the trace and span context, can the backend find it automatically from the trace, does the event appear in the operation timeline, can it be filtered by attributes without losing the call context, and does correlation still hold when data is spread across several storage systems?

These questions do not challenge the value of the Logs API: they simply remind us that the quality of an observability architecture does not depend only on how data is emitted. If you have to leave the trace, open another tool, rebuild your filters, find the identifiers and then reconcile events by hand, a good part of the sought-after simplicity will have disappeared along the way, and complexity, rather than disappearing, will have moved from instrumentation to the collection pipeline, storage, queries and the investigation interface.

The deprecation of the Span Events API does not mean that events will stop being visible in a trace. Everything will depend on how SDKs, pipelines and backends handle their correlation and presentation, and the migration should therefore be judged on its operational result rather than on API consistency alone.

Unified signals or a return to silos?

OpenTelemetry is not trying to abandon traces in favor of logs: the proposal concerns how events are produced and does not require giving up their association with a distributed operation. The distinction matters, because traces and logs can be stored, sampled and retained according to different policies, so a sampled trace can leave orphan logs behind, while a poorly aligned collection or retention policy can make the events needed to understand a trace that is still present disappear. In both cases, correlation identifiers guarantee nothing about whether the useful data is actually available.

A coherent architecture should therefore explicitly define trace sampling rules, event and log retention conditions, retention periods for each signal, the attributes and identifiers needed for correlation, and the expected behavior when one of them is missing.

It is also necessary to distinguish standardization of instrumentation from storage unification, since traces and logs can comply with OpenTelemetry conventions while living in separate systems, which can be a perfectly relevant choice, provided we do not assume that a common API is enough to guarantee a unified investigation experience.

What I would like to preserve

In my view, a trace-first architecture must preserve a few properties.

1. A clear unit of investigation

The trace must make it possible to understand the flow of an operation, its steps, errors and dependencies, without the operator having to rebuild that context from independent messages.

2. Native correlation

Trace and span identifiers must be propagated and preserved correctly, and separately exported events must remain accessible from the operation context.

3. Coherent sampling policies

Reducing trace volume should not create unexpected blind spots, which means designing event retention around diagnostic needs.

4. Reasonable instrumentation

The point is not to turn every variable, every code branch and every log message into a span attribute, but to retain the information that brings real value to investigation, taking into account cardinality, sensitivity and cost.

5. A degree of backend independence

The value of a standard also lies in not tying all instrumentation to a vendor. That independence still has to be evaluated in practice, in light of supported conventions, available features, query quality and navigation between signals.

Standardization should not force us to sacrifice what made the architecture useful.

What if the real subject is observability architecture?

Metrics, logs and traces play complementary roles: the former detect degradation at the scale of a service or infrastructure, logs remain useful for events unrelated to a request, whether it is a process start, a scheduled task or an error that occurred before a trace could even be created. Traces make it possible to follow an operation by placing each event back in its flow.

A trace-first approach makes the trace the starting point of investigation without claiming that all signals must merge into a single format. In a well-designed architecture, a metrics alert leads to the relevant traces, which give access to associated logs when needed, each signal keeps its usefulness but bringing them together becomes a feature of the architecture rather than manual work for the operator.

Storage and visualization choices remain decisive: Grafana Tempo, architectures built on ClickHouse or platforms that offer integrated exploration of several signals meet different constraints, and none guarantees a good experience merely because it accepts several types of data.

Before replacing a stack or changing instrumentation conventions, I would therefore look to measure a few very concrete things, such as ingestion and retention cost, query quality and speed, the ease of going from an alert to a trace and then to associated events, the fidelity of context preserved during exports, and the ability to diagnose an incident when part of the data has been sampled or is missing.

The right choice is not necessarily the one that reduces the number of components the most: it is the one that gives access to useful information with the least friction, without opening new blind spots.

Conclusion: do not confuse standardization with simplification

OpenTelemetry’s desire to reduce duplication between the span events API and the Logs API is understandable: more coherent instrumentation can facilitate adoption of the standard and limit differences between implementations. However, the simplicity of an API and that of an observability architecture are not the same thing.

Trace-first is above all an operational choice, that of taking an operation’s context as the starting point for understanding what happened, with events and logs keeping their full usefulness as long as they enrich that context without forcing the operator to rebuild it.

If OpenTelemetry’s evolution preserves that experience, it will have been an improvement. If it forces people to reconstitute elsewhere what was until then directly accessible in the trace, it will only have moved the complexity around.

Ultimately, the criterion that matters remains simple: when an operation fails, can you understand why starting from its trace, without having to become the integrator of your own observability chain?

That is the question architecture, pipelines and tools will have to answer.

References