Observability: Logs, Metrics, and Traces

Monitoring tells you something broke; observability tells you why

Observability is the difference between a pager that says the checkout is failing and the ability to answer, in minutes, which dependency, for which customers, starting when. Traditional monitoring answers known questions you set up dashboards for in advance. Observability is about answering questions you did not anticipate, by interrogating data the system emits as it runs. The vocabulary has settled on three pillars — logs, metrics, and traces — and the common mistake is treating them as interchangeable. They are not; each answers a different question, and a healthy system uses all three deliberately.

Logs: the detailed account of a single event

A log is a timestamped record of something that happened. Logs are where you go when you already know roughly where the problem is and need the specifics — the exact error, the request that triggered it, the values in play. The discipline that separates useful logs from noise is structure:

• Log structured data, not prose. A log line as key-value fields or JSON is queryable; a hand-written sentence is not.
• Attach a correlation ID to every log in a request's path, so you can reconstruct one user's journey out of millions of interleaved lines.
• Be deliberate about levels. If everything is an error, nothing is. Reserve the high levels for things a human should actually look at.

The trap with logs is volume and cost. Logging every detail of every request is expensive to store and slow to search. Sample the routine, keep the exceptional.

Metrics: cheap numbers you can watch over time

A metric is a number measured over time — request rate, error rate, latency, queue depth, memory in use. Metrics are inexpensive to store and fast to aggregate, which makes them the right tool for dashboards and alerts. Where a log describes one event, a metric describes a population: the ninety-fifth percentile latency over the last five minutes, the error rate per endpoint. Lead with the handful that reflect user experience rather than machine internals — latency, traffic, errors, and saturation tell you how the service feels to the people using it, which is what actually matters.

Alert on symptoms your users feel, not on causes only your servers care about. A high CPU number is not an incident; a slow checkout is.

Traces: the path of one request across many services

In a system of more than a couple of services, the hardest question is where the time went. A distributed trace answers it by following a single request across every service it touches and recording how long each hop took. The trace is what turns this is slow into this is slow because the third call out of seven is waiting on a database query. Without tracing, a team facing a latency regression in a distributed system is reduced to guesswork across a dozen logs; with it, the slow span is visible at a glance. Adopt a vendor-neutral instrumentation standard so the data is portable and you are not locked to one backend.

Instrument deliberately, not exhaustively

The pillars overlap by design, and the goal is not maximum data — it is the ability to answer real questions without bankrupting the storage budget or burying the signal. A practical baseline: metrics on every service for the user-facing signals, structured logs with correlation IDs for the detail, and traces across service boundaries where latency is hard to attribute. Add depth where incidents have actually hurt you, and resist instrumenting everything to the same fidelity just because you can. More telemetry that nobody queries is cost, not insight.

Tie the pillars together with shared context

Three streams of telemetry are far more than three times as useful when they share identifiers. The connective tissue is context propagated across the whole request: a trace identifier carried into every log line and stamped onto the metrics for that path. Get this right and an investigation flows instead of stalling. You see a latency spike on a metric, click into the slow trace behind it, and jump straight to the logs for that exact request — one continuous thread instead of three disconnected searches you have to manually line up by timestamp.

• Propagate a trace context through every hop so logs, metrics, and traces can be joined after the fact.
• Stamp the same request identifier on logs and spans, so one click moves you between them.
• Standardise field names across services — a user identifier called five different things cannot be correlated.

The value of observability is not in any one pillar. It is in being able to pivot from a metric to a trace to a log without losing the thread.

This is also where a vendor-neutral instrumentation standard earns its place: emit the data once in a portable format and you can correlate it in whatever backend you choose, rather than re-instrumenting every time the tooling changes.

How BSH can help

BSH Technologies instruments systems so that the next incident is diagnosable instead of mysterious — structured logging with correlation, metrics that track what users feel, and distributed tracing across your services. We have stood up observability for teams who were flying blind and cut their time-to-diagnose dramatically. If your outages turn into guessing games, let us help you build the visibility to answer the questions you have not thought of yet.