Observability
Structured logging: free-recall review
Retrieval beats re-reading. For each prompt, say or write a full answer from memory before you open the model answer — the effort of recall is what makes the material stick at 03:00 when you need it.
Reconstruct the unit’s spine — what makes a log structured, the level-to-routing contract, the sampling and cost levers, source-and-collector PII defence, trace correlation, and the audit subsystem — without looking back at the lessons.
- 01What makes a log line structured rather than free-text, and where does the payback show up?
- 02Name the core fields of a production log schema and explain why OTel Semantic Convention field names matter.
- 03What does each rung of the level ladder mean, and how does it drive alert routing? Why is misclassification dangerous?
- 04Describe the three sampling strategies and why sampling belongs at the collector, not the application.
- 05Explain the two layers of PII defence and the structural prevention for log injection (CWE-117).
- 06How does trace_id reach a log line automatically, what is the failure mode, and how do you detect it?
If you could reconstruct each answer from memory, you hold the unit’s spine: structured means addressable typed fields that pay back at query time; the OTel schema and convention names make logs joinable across services; the level ladder is a routing contract where misclassification causes alert fatigue or invisible failure; sampling keeps cost proportional to incidents while retaining all WARN/ERROR at the collector; PII is defended at source and collector and injection is prevented structurally by passing input as typed fields; trace_id is auto-injected from the execution context and breaks at async boundaries; and audit logs need their own pipeline, retention, immutability, and access. The log line is an API contract for both your on-call and your auditor.