The three pillars of observability
Knowing each telemetry type's strength.
Metrics show what and when via cheap aggregates, logs give detailed per-event context, traces show where across services.
WHAT THIS TESTS This checks whether you understand the complementary roles of telemetry types and can reach for the right one during an incident rather than treating them as interchangeable.
A GOOD ANSWER COVERS Metrics are numeric measurements aggregated over time, such as request rate, error rate, and latency percentiles. They are cheap to store and query, so they power dashboards and alerts and answer what is happening and when, but they lack per-event detail. Logs are discrete, timestamped, ideally structured records of individual events, carrying rich context like error messages, stack traces, and identifiers. They answer why a specific event happened once you know where to look, but at high volume they are expensive and noisy. Traces follow a single request end to end across services, decomposing it into timed spans, and answer where in a distributed system the time went or the failure occurred. The typical debugging flow uses all three: a metric alert tells you something is wrong, a trace localizes which service or hop is responsible, and logs from that service explain the specific cause.
COMMON WRONG ANSWERS Treating the three as redundant, or claiming any one suffices for everything. Believing metrics can pinpoint a root cause they have no per-event detail to explain, or trying to alert directly on raw logs at scale instead of metrics.
LIKELY FOLLOW-UPS How do the three connect, for example via trace and span IDs in logs? Which is most expensive at scale and why? How does high cardinality push detail from metrics into logs and traces? What is exemplars linking metrics to traces?
ONE CONCRETE EXAMPLE At 2 a.m. a metric alert fires: the checkout error rate jumped to five percent. You open traces for failing checkout requests and see they all fail at the payment service span with elevated latency. You then pull the payment service logs for those trace IDs and find repeated connection timeouts to the card processor. Metrics caught it, the trace localized it, and the logs explained it, illustrating why all three pillars matter together.
Read the original → ibm.com
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.