Observability Fundamentals: Traces, Metrics, Logs, and Events: CNPA practice questions

Observability is the ability to understand a system from the outside by asking questions about it, including questions nobody anticipated. The OpenTelemetry primer frames it around unknown unknowns and the question of why something is happening. A system counts as observable when its code is instrumented well enough that engineers do not need to add more instrumentation to troubleshoot an issue. For a platform team, observability is both a capability it offers to every service and the way it watches the platform itself.

The signals answer different questions. Metrics are aggregations of numeric data over time, such as error rate, CPU utilization or request rate; they are cheap to store and suit dashboards, alerts and objectives. OpenTelemetry's metric instruments include counters that only accumulate, up-down counters that can also decrease, gauges for a current value and histograms for distributions such as request latency. Logs are timestamped messages emitted by services or components, and unlike traces they are not necessarily tied to a particular request. Traces follow one request through a distributed system. A trace is made of spans, each representing a unit of work with a start and end time; the root span has no parent, child spans share its trace ID, and the span context with the trace and span IDs is propagated between services, by default using the W3C TraceContext format. OpenTelemetry also supports baggage for passing key-value context along a request, while events, a specific type of log, and profiles are still listed as in development.

Kubernetes adds its own signals. Events are API objects with high-level information about what is happening in the cluster, such as scheduling failures or image pull errors, and kubectl describe shows the related ones at the end of its output. Container output written to stdout and stderr can be read with kubectl logs, but the logging documentation says logs need storage and a lifecycle independent of nodes, Pods and containers, which is why clusters run node-level logging agents or sidecars that ship them to a backend. Kubernetes components also emit their own metrics in Prometheus format.

OpenTelemetry is the framework for generating, collecting and exporting this telemetry in a vendor- and tool-agnostic way. It is explicitly not an observability backend: storage and visualization are left to tools such as Prometheus, Jaeger or commercial products. The OpenTelemetry Collector receives, processes and exports telemetry through pipelines of receivers, processors and exporters, so a platform can collect once and route data to whichever backend it chooses.

Service level indicators and objectives tie the signals to users. An SLI measures behavior from the user's point of view, such as page load time, and an SLO attaches it to business value as a target.

Misconceptions include treating observability as watching a fixed list of known failure modes, expecting logs alone to explain latency across many services, and assuming OpenTelemetry stores data. At associate level, expect questions that match a problem to the right signal, explain what a span or trace ID is, and identify the role of the Collector.