What is observability and how do logs, metrics, and traces differ?
Published on 2026-10-20 by frfrand
Observabilidad explicada: qué cuentan logs, métricas y trazas, cómo investigar errores y cuándo conviene combinarlas.
Observability is the ability to understand the internal state of a system based on information it produces while running. In software, three types of signals appear constantly: logs, metrics, and traces.
The word sounds sophisticated, but it tries to solve a very concrete question: "Why is my application failing if apparently everything is turned on?".
The car example
When you drive, the speedometer shows you the speed and the temperature indicates if the engine is overheating: they are similar to metrics.
If the vehicle records "sensor failed at 10:42", that is similar to a log.
If you could follow the entire path of an order from the accelerator to the components that react, you would have something similar to a trace.
No signal, by itself, always tells the whole story.
What are logs?
They are records of events. They can indicate that a user logged in, that a query failed, or that a process restarted.
Good logs have enough information to investigate without exposing passwords, tokens, or unnecessary private data. The message "Unexpected error" repeated a thousand times is much less useful than a clear event with time, component, and secure context.
What are metrics?
They are values you can measure over time: CPU consumption, memory, requests per second, latency, or error rate.
A metric helps you detect trends. For example, if request duration increases after a deployment, it's a clue to investigate.
But knowing that there are more errors doesn't mean knowing which line of code produced them.
What are traces?
A trace represents the path of an operation through components. In an architecture with frontend, API, database, and an external service, it allows observing which part consumes more time or where it fails.
It is composed of operations called spans. Each one can record duration and context, depending on how it is instrumented.
This is especially useful in distributed systems, where an error visible to the user may originate in a remote service.
A practical case
A store starts responding slowly. The metric shows that response time increased. The logs indicate that there are slow queries. The trace of a specific purchase indicates that almost all the time is consumed in a database operation.
With that combination you can investigate the index, query, or lock that corresponds, instead of restarting servers without reason.
Observability does not mean storing absolutely everything
Recording information without limits can cost money, consume storage, and expose data. It is convenient to decide which events are useful, how long they are kept, and what information should be anonymized or deleted.
Cardinality of metrics also matters. If you create a different series for each user identifier, volume can grow uncontrollably.
What should a small application measure?
Start with availability, errors, request duration, resource usage, and logs useful for diagnosing failures. If there are multiple applications communicating, distributed traces can add a lot of value.
You don't need to install a massive platform before having a first website running. What matters is being able to answer what changed, when, and with what impact.
How to apply it in ArduMaker?
Applications deployed on ArduMaker VPS can produce logs, metrics, and, if instrumented, traces. Organizing those signals allows differentiating a network problem from a slow query or a deployment failure.
In one sentence: metrics show trends, logs tell events, and traces connect operations. Observability appears when you can relate those signals to understand real behavior.
Sources: OpenTelemetry Observability Primer · Google SRE: Monitoring Distributed Systems.