Question bank — Logging and monitoring — structured logging, metrics, alerting

False. Beyond a point volume hides signal — a firehose of DEBUG lines buries the single ERROR that matters, and it costs storage/ingestion money. The right fields beat more lines.

False. A metric deliberately throws away per-event detail to keep only cheap aggregatable numbers; a log keeps the rich per-event context. They trade detail for cheapness in opposite directions.

False. The average hides the tail: 99% at 10 ms and 1% at 7 s still averages ~80 ms, yet 1 in 100 users suffers. See Percentiles and Distributions — track p95/p99, not the mean.

False (the premise is right but the conclusion is wrong). The raw value is uninteresting, but its slope gives requests/sec, which is exactly what you want and survives restarts.

False. Logging and metrics describe the system; alerting is a decision layer on top of metrics that answers one question — should a human act right now?

False. Over 30 days that "three nines" still permits $(1-0.999)\times 43200\approx 43$ minutes of downtime — a real, spendable budget, not perfection.

False. It is the opposite: alert on symptoms users feel (error rate, high p99). Causes are infinite; symptoms are few and actionable.

False. It makes detection slightly slower on purpose, trading a few minutes of delay for a huge cut in false pages from noisy one-scrape spikes.

False. Its whole point is to be attached to every log line a request touches across every service, so one ID reconstructs the entire distributed journey. This is the seed of Distributed Tracing.

False. That fraction is the SLO. The error budget is the allowed failure, $1-\text{SLO}$ — the part you are permitted to spend.

This logs PII / secrets — a security and compliance breach. Never log credentials or card data; redact or omit them regardless of debugging convenience. See PII and Data Privacy.

With tiny $n$ a single slow sample dominates the tail, so the percentile is statistically meaningless. Tail percentiles need lots of data to be trustworthy — Percentiles and Distributions.

A total-served count only goes up, so it should be a counter. A gauge is for values that rise and fall (memory in use, queue depth).

This causes alert fatigue — constant pages get ignored, so the one real page is missed. Alert on sustained/high-enough failure (burn rate), not on each error.

Free-form sentences break the moment someone reword the message; that is why you emit structured key–value events and query event=login_failed AND attempts>2 instead.

That is a count of events over the interval, not a rate. You must divide by $\Delta t=t_2-t_1$ to get per-second units.

A 100% SLO leaves a zero error budget, so any single failure is a breach and every risky deploy is forbidden — an unworkable target. Real SLOs leave budget to spend. See SLI SLO SLA.

Saturation measures how full a resource is (CPU, memory, queue depth), not errors. Errors are a separate golden signal.

A counter's rate (slope) is comparable across machines and survives process restarts, whereas a raw gauge snapshot of "current requests" is fragile and non-additive. Rates, not totals, are what you compare.

Logging has a cost (storage + ingestion). A field you will never query is pure overhead and noise, so the discipline is: if you'd never slice by it, reconsider logging it.

Burn rate tells you whether you are consuming the error budget fast enough to matter — it pages you for a 14×-too-fast burn, not for a slow trickle you can absorb, cutting false pages while still catching real outages.

On a page that fires 100 backend requests, a p99 tail means almost every page hits at least one slow request, so the tail defines the felt experience even though it is "only 1%".

They are symptom-level signals users actually feel, and symptoms are few while internal causes are infinite — so a handful of signals covers almost every real problem without chasing every cause.

Without a shared ID, each service's lines are unrelated scraps; the ID links every line one request produced across services into a single ordered narrative you can reconstruct.

Metrics are cheap numeric samples optimised for aggregation over time; a time-series DB compresses and queries these far more efficiently than a high-cardinality log store built for discrete events.

The naive $C(t_2)-C(t_1)$ goes negative or wrong, because the derivation assumed no reset. Rate functions must detect the drop and treat the reset as a fresh start.

$k=\lceil 0.95\times 10\rceil =\lceil 9.5\rceil =10$, the 10th rank — the maximum. With small $n$ the tail dominates, which is precisely why tail percentiles demand large samples.

You suppress noise but also delay paging until the outage has hurt users for hours — the duration is a tunable trade-off between false pages and detection speed, not "bigger is always better".

$(1-1.0)\times 43200=0$ minutes — zero tolerance, so the very first blip is a violation. This shows why sane SLOs are set below 100%.

$(1-0)\times \text{total}=$ every request may fail — the degenerate opposite: nothing can ever violate it, so the SLO carries no meaning. Both 0% and 100% are useless extremes.

No — an unactionable alert is noise that trains humans to ignore the alert channel, so it actively lowers reliability by masking real pages. If nobody can act, it shouldn't page.

Usually no — that is a cause, not a user symptom, and full disks may never hurt anyone. Prefer alerting on the symptom it might cause (errors/latency) and let the cause inform the investigation.