How to structure a log

Summary

Logging arbitrary JSON objects often produces unstable messages and deeply nested data that complicate searching, aggregating, and debugging production incidents. Structured logging treats log output as real application data by establishing predictable, consistent schemas across services. Engineers should define stable event names using a domain.action pattern and capture dynamic dimensions with flattened, snake_case attributes formatted in dot notation. Attribute payloads must contain only primitive values or primitive arrays rather than arbitrary objects, utilizing low-cardinality result identifiers and explicit units for numeric measurements. Teams can enforce these structural conventions automatically with linting tools such as ESLint, while routing execution durations and timing measurements to tracing spans.

Takeaways

1. 1

   Event names should follow a stable domain.action pattern without dynamic strings in the message, placing dynamic variables into scoped attributes instead.

2. 2

   Attributes must use flattened dot-notation keys with snake_case segments and restrict values to primitive types or arrays of primitives rather than raw nested objects.

3. 3

   Numeric attributes should explicitly specify units within their key names, and execution duration measurements should be recorded in tracing spans rather than log attributes.