Reading production logs
40 min · Advanced
In production you cannot attach a debugger or watch a console; the logs are your record of what happened. They become useful when every line is easy to search: one JSON object per line, a level, a time, and a request id that ties all lines of one request together.
Topics in this lesson
- Logs go to stdout; the platform collects them
- Structured JSON logs
- A JSON log writer and filter you can run
- Searching: time window, level and request id
- Reading a stack trace and matching it to the deploy
Key points
- Containers log to stdout; the platform or
docker compose logscollects them, and they are kept only for a while. logging.structured.format.console: ecs(orlogstash) writes one JSON object per line with level, logger, time and MDC fields.- Search by time window (logs are in UTC), then level, then one
requestIdtaken from the error or theX-Request-Idheader. - Read stack traces from the last
Caused by:and compare the first error time with the deploy time.
Interview questions this lesson answers
- Where do your application logs go in production?
- Why use structured JSON logs?
- How do you trace one failed request through the logs?
- What is the MDC and what is the common mistake with it?
- How do you read a long production stack trace?
- Errors started in production this afternoon. What is your first question?
- Should you log request bodies to make debugging easier?
Sign in to continue this lesson
Create an account to read every lesson, practise with the exercises and keep track of your progress.