Structured vs unstructured logging: why it matters
understanding of log formats and their impact on observability at scale.
unstructured logs are free-text lines hard to parse; structured logs are machine-readable key-value or JSON records; structure enables reliable querying…
WHAT THIS TESTS This checks whether you understand that the format of logs, not just their existence, governs how effectively they support debugging and observability once you have many services producing high log volume.
A GOOD ANSWER COVERS Contrast the two. Unstructured logging emits free-form text lines meant for humans to read, for example a sentence describing what happened; parsing it programmatically requires fragile regular expressions, and formats drift between services and developers. Structured logging emits records in a consistent, machine-parseable shape, commonly JSON or key-value pairs, where each piece of information lives in a named field such as timestamp, level, service, user_id, latency_ms, and trace_id. Then explain why structure is foundational at scale. It allows reliable querying and filtering on fields rather than text matching, enables aggregation and metrics derived from logs, supports correlation by joining logs to traces and requests through shared identifiers, and makes ingestion into log platforms efficient and consistent. At millions of lines across many services, free-text logging becomes nearly unsearchable and unparseable, so structure is the prerequisite for everything an observability pipeline does with logs.
COMMON WRONG ANSWERS Treating logging as merely printing strings and format as cosmetic. Assuming regex parsing scales fine. Conflating structured logging with simply having log levels. Ignoring correlation IDs. Logging huge unbounded fields that bloat storage.
LIKELY FOLLOW-UPS How do you add a trace ID to correlate logs and traces? What are the cost and cardinality tradeoffs? How do you migrate a legacy app to structured logs? Where does sampling fit?
ONE CONCRETE EXAMPLE With unstructured logs, finding all slow requests for one user means grepping text and hoping the format is consistent. With structured JSON logs, you query where user_id equals X and latency_ms greater than 500 and service equals checkout, then join on trace_id to the corresponding traces. The same investigation that was guesswork over free text becomes a precise, fast query, which is exactly why structure underpins large-scale observability.
Read the original → newrelic.com
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.