Distributed tracing vs Metrics

Observability

Following one user request as it passes through many services, timing each step, to see where it slowed down or failed.

Formal

A method where each request gets a shared ID that is passed from service to service, and every service records a timed step, called a span, under that ID, so the full path can be put back together as a trace.

In plain English

Like the tracking page for a parcel, showing each depot it passed and how long it sat there, so you can see it was stuck three days in one place.

In practice

A trace of a slow page in a region's patient portal shows the web service answered almost at once but waited four seconds for the appointment booking service, so the team knows where to look.

Why it matters

When one click touches dozens of services, logs from each one alone cannot show the chain of cause; traces link them into one story, which also helps follow an attacker's steps.

Metrics

Observability

Numbers a system records at regular times, such as requests per second or memory used, so trends can be charted and compared.

Formal

Measurements stored as a name, a number and a time, often with labels such as server or region, that are cheap to keep for long periods and can be added up, averaged and compared across many systems.

In plain English

Like the readings on your electricity meter taken every hour; one number on its own says little, but the curve over a week shows when something unusual happened.

In practice

At a municipality, a chart of failed logins to the staff portal usually shows about twenty a minute; one night it jumps to four thousand, pointing to someone guessing passwords.

Why it matters

Because they are small and fast to search, metrics are what most alarms and service targets are built on; they show that something changed, while logs and traces help show why.

Shared connections

Observability Telemetry