1 Reading Logs Strategically
Beginners often try reading a log file line by line from the start. That's rarely practical — production systems can generate thousands of events per minute, millions per day, terabytes across an enterprise. Instead, start with what you already know:
User: alice@example.com
Incident time: approximately 14:30
Application: Customer Portal
Source IP: 192.168.20.51Search specifically for those values, and start with a narrow time window. If a customer reports "login failed at approximately 14:32," don't investigate the entire day — start with something like 14:25–14:40, then widen the search only if that turns up nothing. This alone eliminates the vast majority of irrelevant noise before you've read a single unrelated line.
2 Read Before and After the Error
Never investigate only the error line itself. Consider:
14:32:10 INFO Starting authentication
14:32:10 INFO Looking up user alice
14:32:10 INFO User found
14:32:11 DEBUG Contacting LDAP server 10.1.5.20
14:32:41 ERROR LDAP connection timeout
14:32:41 ERROR Authentication failedSearching only for Authentication failed might convince you the user's password was wrong. The actual problem was LDAP connection timeout, thirty seconds earlier — visible only because you read the surrounding context instead of jumping straight to the last line. Always read a window around any error, not just the error itself.
3 Cause and Effect
Consider two lines appearing together:
09:12:01 ERROR Database query failed
09:12:01 ERROR User authentication failed🔮 Predict first
Which of these two errors caused the other, and how would you confirm it?
Reveal the reasoning
The authentication failure is very likely a consequence of the database failure, not an independent problem — authentication almost certainly needed that database query to complete. Experienced engineers deliberately look for the first meaningful failure rather than stopping at the final visible symptom, since fixing the symptom (a login error) without fixing the cause (the database) leaves the real problem untouched.
4 Correlation Across Systems
Correlation means connecting related events across different systems — one of the most important skills in enterprise troubleshooting. Imagine a cloud application: User → Browser → Corporate Proxy → WAF → Load Balancer → Application Server → Authentication Service → Database. A user reports "login failed at 10:42" — you may need browser, proxy, WAF, load balancer, application, authentication and database logs, and each one may only show part of the transaction.
One value — request_id=abc123 — appears in all three systems' logs, letting the same transaction be followed end to end.
Concretely: the application logs 10:42:12.100 INFO request_id=abc123 Login request received; the authentication service logs 10:42:12.173 INFO request_id=abc123 Authenticating user alice; the database logs 10:42:12.202 ERROR request_id=abc123 DB connection unavailable; the authentication service then logs 10:42:12.205 ERROR request_id=abc123 Authentication backend failure; and the application logs 10:42:12.210 INFO request_id=abc123 HTTP 500 returned. The common value request_id=abc123 lets you follow the transaction across all five log lines, across three completely different systems, without guessing based on timestamps alone.
5 Correlation IDs
You'll see this idea called a correlation ID, request ID, transaction ID, trace ID, or activity ID depending on the product — the terminology varies, but the purpose is identical. Modern distributed applications depend on correlation IDs heavily, since a single request might travel through dozens of microservices (API Gateway → Application → Authentication Service → Payment Service → Database). Without a shared identifier threading through every system's logs, reconstructing what actually happened to one user's one request becomes close to impossible — Module 13's Lesson 2 introduced correlation IDs from the API side; this is the same concept from the log-reading side.
Lesson Outcome
You should now be able to narrow a log search using a time window before reading anything, read the events surrounding an error instead of just the error line, distinguish a root cause from a downstream symptom, and follow a correlation ID across multiple systems to reconstruct one transaction. Lesson 2 tackles the thing that trips up almost everyone doing this for the first time: timestamps, timezones, and why "the times don't match" is rarely as suspicious as it looks.