Structured vs unstructured logging
Why log format matters at scale.
Unstructured logs are free-text lines; structured logs are machine-readable key-value or JSON, enabling reliable parsing, filtering, and aggregation.
WHAT THIS TESTS This evaluates whether you understand why log format is an engineering decision with real consequences for searchability and cost at scale, not just a style preference.
A GOOD ANSWER COVERS Unstructured logging emits free-form text lines designed primarily for a human reading a terminal, for example a sentence describing what happened. Extracting any field later requires brittle regular expressions that break whenever the message wording changes. Structured logging instead emits each event as machine-readable data with named fields, commonly JSON, where attributes like timestamp, level, service, user_id, latency_ms, and trace_id are explicit keys. This matters enormously at scale because logging backends can index those fields and let you filter, group, aggregate, and sort by them precisely and cheaply, rather than full-text scanning. Consistent fields enable correlation, such as joining logs to a trace by trace_id, and reliable alerting and dashboards built on log-derived data. It also makes logs portable across tools and pipelines.
COMMON WRONG ANSWERS Believing grep and ad hoc regex on plain text are adequate for large systems, which collapses under volume, inconsistent formats, and multi-line messages. Another error is over-logging high-cardinality data into structured fields without considering index cost, or thinking structure is purely cosmetic.
LIKELY FOLLOW-UPS What fields should always be present? How do you correlate logs with traces? How does structured logging interact with log levels and sampling? What are the cost tradeoffs of indexing many fields?
ONE CONCRETE EXAMPLE An unstructured line reads that user 42 failed login from some IP at some time. To count failed logins per user you would write fragile regex hoping the wording never changes. The structured equivalent emits a JSON object with event set to login_failed, user_id 42, source_ip, and trace_id. Now a query for event equals login_failed grouped by user_id returns counts instantly, and you can pivot straight to the matching trace, something the free-text version cannot reliably support across millions of events.
Interview question
Why does structured logging scale better than unstructured logging for large-system analysis?
- a.Structured logs use less disk space than any text format
- b.Named machine-readable fields can be indexed, filtered, and aggregated reliably instead of parsed with brittle regexCorrect
- c.Structured logs are always human-readable in a terminal
- d.Unstructured logs cannot include timestamps
Why? this is the answer
Structured logs expose explicit fields that backends index and query precisely, enabling reliable filtering, aggregation, and correlation at scale. Free-text logs force fragile regex parsing that breaks as messages change, which does not scale.
Just read this? Test yourself on what you have been reading.
Read the original → docs.cloud.google.com
- #logging
- #structured-logging
- #observability
- #telemetry
- #json
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles