How do you read application logs and dashboards when something breaks?

What do the log levels mean?

DEBUG is detail for developers, INFO records normal events, WARN flags something unusual that did not fail, and ERROR records a failure. In production, ERROR and WARN entries are usually the first place to look.

What should you check first on a dashboard?

Look at the four golden signals from the Google SRE book: latency, traffic, errors and saturation. Compare them with normal. A jump in errors that starts exactly when a release went out points to the release.

How do you find the right log lines?

1. Pin down the time window of the problem.
2. Filter by service and by level.
3. Search for the request, user or correlation ID from a failing example.
4. Follow that ID through every service it touched.

Why do structured logs and correlation IDs help?

Structured logs, written as key-value fields instead of free text, can be filtered and counted. A correlation ID carried through every service lets you reconstruct one request across the whole system. See observability versus monitoring.

What should never appear in logs?

Passwords, tokens, full card numbers and other personal data. Logs are copied to many places and kept for a long time, so sensitive values become a second leak. Mask or leave them out.

Go deeper: CTP™ credential · the TPBOK™ standard · Check your experience

IICTP is an independent technical credentialing body.