log-analysis

Topics in the source

• Log analysis
• 1. Ask one answerable question
• 2. Anchor on time and identity
• 3. Cut volume before reading
• 4. Read the boundaries of the incident
• 5. Correlate before concluding
• 6. Report what the logs support, and no more
• Improving what you found

Logs are a haystack that grows faster than you can read it. The skill is not reading logs — it is constructing a query narrow enough to answer one question, then widening only as far as needed. The failure this prevents: scrolling. Scrolling through logs feels like work and finds only what happens to be near the cursor. Before opening anything, write the question down. "What went wrong?" is not answerable. These are: Did request abc-123 reach the payment service? How many 500s between 14:00 and 14:30, and on which endpoint? What is the first error after the deploy at 13:47? Which tenant accounts for the spike? Done when: you have a question with a checkable answer. Two anchors make everything else tractable: A time window: bound it tightly, then widen. Start a few minutes before the first known symptom, because the cause usually precedes it. An identifier: request ID, trace ID, user, order, tenant. One identifier that threads through services turns a search into a story. If there is no correlating ID, that is your most important finding. Nothing else you do here will be reliable, and adding one should be the follow-up action. Done when: you have a window and, ideally, an ID to foll

This is an excerpt. Refer to the complete source and its current requirements.