Learning Objectives
By the end of this lesson you will be able to:
- Identify the components of a structured log entry
- Order the standard severity levels from lowest to highest
- Explain what each severity level signals about the system's state
- Filter logs effectively to locate errors related to a specific bug
The Anatomy of a Log Entry
A typical server log entry contains several predictable fields:
2024-11-14T14:32:11.842Z WARN [http-thread-3] c.example.BookingService Booking end date is in the past: 2024-11-01
Breaking this down:
| Field | Example | Meaning |
|---|---|---|
| Timestamp | 2024-11-14T14:32:11.842Z |
When the event occurred (ISO 8601 UTC) |
| Severity | WARN |
How serious this event is |
| Thread | [http-thread-3] |
Which execution thread produced the entry |
| Logger class | c.example.BookingService |
The Java/Python class that logged the message |
| Message | Booking end date is in the past... |
Human-readable description of the event |
Some systems add a correlation ID or request ID field, which links all log entries from a single HTTP request across multiple classes and services.
Severity Levels: Low to High
The standard severity order from least to most serious is:
TRACE < DEBUG < INFO < WARN < ERROR < FATAL
TRACE — extremely detailed execution steps; used only during active debugging. Usually disabled in production because the volume would overwhelm the logging system.
DEBUG — internal state information useful for diagnosing a problem. Also typically disabled in production but may be temporarily enabled for a specific incident investigation.
INFO — normal operational events: "Server started on port 8080," "User logged in," "Booking created successfully." The default level for healthy production systems.
WARN — an unexpected condition that the system handled, but which may indicate a problem developing. Examples: "Date format fallback used," "Retry 2 of 3 for external API call," "Response time exceeded 2s threshold." A WARN does not mean the request failed, but it warrants investigation if it appears frequently.
ERROR — an operation failed. The system caught the exception and returned an error response, but a user-visible failure occurred. Example: "Failed to parse date '31-13-2024': DateTimeParseException." Every ERROR should be investigated.
FATAL — the system is unable to continue operating. Often accompanies a crash or an unrecoverable state. In many frameworks this is equivalent to ERROR but signals that the process may be terminating.
What Each Level Signals to a QA Engineer
| Level | What it means for you |
|---|---|
| TRACE/DEBUG | Ignore in production logs; check only if specifically enabled for debugging |
| INFO | Background context; confirms normal operations during the time window of interest |
| WARN | A yellow flag — investigate if it appears unexpectedly or repeatedly |
| ERROR | A confirmed failure — always document and link to any corresponding bug report |
| FATAL | Critical — escalate immediately |
Filtering Logs to Find a Bug
When investigating a specific failure, the workflow is:
- Know the approximate time of the failure (from a bug report, user complaint, or alert timestamp).
- Filter by time window: look at ±5 minutes around the failure time.
- Filter by severity: start with
ERRORandWARN. In most logging systems:grep -E "ERROR|WARN" app.logor use the log UI's severity filter. - Filter by correlation ID if available:
grep "req-abc123" app.logshows all entries from that specific request. - Read backwards from the error: the ERROR line tells you what failed; the lines immediately preceding it tell you the sequence of events that led there.
Summary
A log entry is a timestamped, severity-labeled record of what the system was doing at a given moment. Reading logs requires knowing the severity ladder — TRACE through FATAL — and filtering strategically rather than reading every line. When investigating a bug, always start with ERROR and WARN entries in the time window surrounding the failure.