Quiz

D — Both logs and traces are needed.

The trace shows which service in the call chain caused the error and how long each hop took, narrowing the investigation to a single span. The logs inside that service then reveal the exact exception class, message, and stack trace. Neither pillar alone gives the full picture: traces without logs tell you where but not why; logs without traces make it hard to identify which service among many produced the matching log line.

C — Histograms are aggregatable; summaries are not.

A Summary calculates quantiles inside the application process — once exported, the p99 value of instance A and instance B cannot be meaningfully combined. A Histogram exports raw bucket counts, so histogram_quantile(0.99, sum(rate(http_duration_bucket[5m]))) correctly computes the p99 across all instances and across any chosen time window. In a horizontally-scaled microservice this distinction is critical.

B — Per-second average rate of increase over the 5-minute window.

rate() divides the total increase in the counter over the window by the window duration in seconds. A counter that increased by 300 in 5 minutes returns 1.0 (one error per second). Because rate() operates on the raw counter, it handles counter resets (service restarts) correctly, which increase() also does but as an absolute count rather than a per-second rate.

B — Attaches key-value pairs to every log line on the current thread.

MDC stores a thread-local map that the logging framework (Logback, Log4j2) automatically appends to every log statement using a pattern like %X{traceId}. When OpenTelemetry propagates the traceId into MDC at the entry point of a request, every subsequent log line — across all called methods in that thread — carries the same ID, making it trivial to filter an entire request's log history with a single query.

B — The traceId is generated once and propagated via traceparent.

When the first service (e.g., the API gateway) receives a request with no traceparent header, it generates a 128-bit traceId and creates the root span. Every outgoing HTTP call includes traceparent: 00-<traceId>-<currentSpanId>-01. Each downstream service reads this header, keeps the traceId unchanged, generates a new spanId, and sets parentSpanId to the received spanId. The result is a tree of spans that all share the same traceId, which the tracing backend uses to assemble the full trace view.

C — Same traceId, new spanId equal to the current span's ID.

The traceId (abc123...) never changes across the entire request — that is the invariant that links all spans together. The parentSpanId field in the new header is set to the current span's ID (999888...), so the downstream service knows exactly which span triggered the call. The received def456... becomes the parentSpanId of the current span (stored in the span record), not forwarded further.

B — Decision timing is the core difference.

Head sampling must commit to record or drop a trace at the moment the root span is created, with no knowledge of what will happen downstream. This is fast and has near-zero overhead but will randomly discard some error traces. Tail sampling buffers spans until the trace is complete, then applies rules — for example, keep all traces where any span has status=ERROR. The tradeoff is higher memory and latency in the collector.

C — The OTel Collector.

The Collector is a vendor-agnostic proxy deployed as a sidecar or as a cluster-level gateway. Its pipeline has three stages: receivers (accept OTLP, Jaeger, Zipkin, etc.), processors (filter, sample, batch, add attributes), and exporters (send to Prometheus, Jaeger, Loki, Datadog, etc. simultaneously). Centralising telemetry routing in the Collector means changing backends requires only a Collector config change, not a redeployment of every application.

D — Mean Time to Recovery (MTTR).

MTTR is defined as the time from when an incident is detected (typically when an alert fires) to when the service is restored to normal operation. It directly captures incident response effectiveness — including detection speed, diagnosis time, fix deployment, and verification. The other three metrics measure delivery throughput and reliability, not recovery speed. Elite teams achieve MTTR under one hour.

B — Java bytecode instrumentation via java.lang.instrument.

The JVM's java.lang.instrument API, combined with a ClassFileTransformer, allows a -javaagent JAR to intercept every class as it is loaded and rewrite its bytecode before it reaches the application. The OTel Java agent uses this mechanism to inject span creation, HTTP header propagation, and JDBC tracing into Spring MVC, RestTemplate, WebClient, Hibernate, and dozens of other libraries — all without touching the application source code.