Structured Logging

An operations team had a monitoring rule that parsed log lines using a regex to extract response times. It worked perfectly, until a developer changed the log format slightly. The log used to say Response time: 234ms and now it said response_time=234ms. The regex broke silently. For three days, the latency dashboard showed nothing while production response times climbed to 5 seconds.

Unstructured logs, free-form text strings, are a liability at scale. They look fine when you're reading them manually. But the moment you try to parse, search, filter, or aggregate them programmatically, you're building on quicksand. Every log format change, every developer's personal style preference, every service's slightly different timestamp format becomes a parsing landmine.

Structured logging means emitting logs as key-value data (usually JSON) instead of human-readable strings. The machine doesn't have to guess where the response time is, it's in a field called response_time_ms with a numeric value.

Unstructured (text):

[2026-04-04 10:30:12.456] INFO PaymentService - Processing payment for user alice@example.com, order #8834, amount $49.99, gateway=stripe

Structured (JSON):

{
 "timestamp": "2026-04-04T10:30:12.456Z",
 "level": "INFO",
 "service": "payment-service",
 "message": "Processing payment",
 "user_email": "alice@example.com",
 "order_id": 8834,
 "amount": 49.99,
 "currency": "USD",
 "gateway": "stripe",
 "request_id": "req_abc123",
 "trace_id": "trace_xyz789"
}

The structured version is longer, sure. But look at what you gain:

Every modern log aggregation system (Elasticsearch, Datadog, Splunk, Loki) works dramatically better with structured logs. They can auto-detect fields, build indexes, and let you slice and dice without writing a single regex.