Structured Logs, Metrics, and Traces

Observability uses externally visible signals to investigate system state. Logs, metrics, and traces answer different questions and are strongest when correlated through supported context propagation.

Signal	Best suited to	Common misuse
Structured log	A discrete event with diagnostic context	Logging every event or sensitive payload
Metric	Aggregate rate, level, error, latency, or saturation	Unbounded labels and averages alone
Trace	Causal path and latency across boundaries	Sampling without understanding missing traces

Structured logs

Emit stable fields rather than encoding all context in prose: timestamp, level, event name, service, safe request or trace identifier, outcome, and relevant bounded dimensions. Log an exception once at the boundary that can act on it. Never log credentials, tokens, raw authorization headers, or unnecessary personal data; redaction must be tested.

Metrics and cardinality

Counters measure cumulative events, gauges current sampled levels, and histograms distributions such as latency or payload size. Rates are derived from counters. Histograms support aggregation and tail analysis; an average conceals the slowest requests.

Metric labels create a time series for every combination. Route templates and bounded outcomes are useful; user IDs, request IDs, raw URLs, and exception messages are usually unbounded. High cardinality can make monitoring itself a reliability problem.

Traces and context

A trace connects spans representing operations across process and asynchronous boundaries. Propagate context through supported HTTP, messaging, and executor instrumentation. Sampling reduces cost but means an absent trace is not evidence that an event did not occur. Avoid attaching sensitive or unbounded attributes.

Start from user-visible behavior

Measure request or job rate, errors, latency distributions, and saturation. Define service-level indicators from semantics meaningful to users, then link an alert to an actionable investigation. Dashboard abundance is not observability if nobody can explain a failure from it.

In Spring Boot, Actuator and Micrometer provide observations that can produce metrics and traces. Instrument custom operations at meaningful boundaries and keep names and low-cardinality tags stable.

Test context propagation, redaction, failure outcomes, cardinality bounds, and telemetry-backend failure. Monitoring must not be allowed to block the primary operation indefinitely.

See the official Spring Boot observability and Micrometer concepts.