Logs are not just a pile of timestamps. Read in sequence, they describe what a system believed happened, what it tried to do, and where that story changed.
Start with a small question
Instead of searching for everything unusual, begin with a narrow question:
Which request first became slower than the user’s patience?
That question gives us a useful path through a large event stream:
- Find the request ID.
- Follow it across the edge, application, and database.
- Compare the timestamps at each boundary.
- Look for the first unexpected gap.
A compact example
10:41:02.118 edge GET /reports/weekly 200 184ms request=9f2a
10:41:02.126 app report.started request=9f2a
10:41:02.289 database query.finished 163ms request=9f2a
10:41:02.302 app report.finished request=9f2aThe edge reports 184 ms, while the database accounts for 163 ms. That leaves only a small amount of time for routing, application work, and serialization. The numbers are consistent enough to investigate the query first.
| Signal | What it tells us | Useful next step |
|---|---|---|
request |
Which events belong together | Trace the request end to end |
status |
How the caller experienced the request | Group errors separately |
duration |
Where time was spent | Compare p50, p95, and p99 |
user-agent |
Which client made the request | Check browser or bot patterns |
A short checklist
- Normalize timestamps to one timezone.
- Keep request IDs in every service.
- Add a link from each alert to a representative trace.
- Record the query shape, not sensitive values.
The goal is not to log more. It is to make the important path easy to follow.