The production log schema: fields every line must carry

Two services on the same team call the field “status_code” in one and “http_status” in the other. Every dashboard that joins them breaks. The fix is not a regex — it is a shared schema enforced before the code ships.

What every production log line carries

A production-grade structured log line in 2026 has at minimum these fields, in roughly this priority order:

1. timestamp — ISO-8601 UTC with sub-second precision: 2026-04-12T14:02:11.482Z. The primary sort key for every backend.
2. level — string enum: TRACE / DEBUG / INFO / WARN / ERROR / FATAL. Controls what gets stored and who gets paged.
3. service.name — the OTel-canonical key identifying the emitter. This is the join key back to metrics and traces.
4. trace_id and span_id — when the log is emitted inside a traced request, these are the join keys to the tracing backend. Without them the log-to-trace pivot does not work.
5. message — a short human-readable summary. The only field humans skim; the rest is for machines.
6. Event-specific fields — a flat key-value tree using OTel Semantic Conventions: http.route, http.response.status_code, db.system, error.type, etc.
7. Resource attributes — set once at service start: host.name, cloud.region, service.version, deployment.environment. These describe the emitter, not the event.

The OTel Logs Data Model

The OpenTelemetry Logs specification (stable API late 2023, SDKs late 2024) formalises this split. A log record contains:

• Timestamp — when the event actually occurred (set by the application).
• ObservedTimestamp — when the collector saw the record. Under clock skew or backpressure these two diverge; senior teams alert on the divergence as a pipeline-health metric.
• SeverityNumber — a numeric ladder (TRACE=1-4, DEBUG=5-8, INFO=9-12, WARN=13-16, ERROR=17-20, FATAL=21-24) so backends can compare severity across libraries that use different text labels.
• Body — the human-readable message.
• Attributes — the flat key-value map of event-specific data.
• Resource — set once per emitter (service.name, host.name, cloud.region).
• TraceId / SpanId / TraceFlags — W3C traceparent context inherited from the active span at emit time.

Adopting this shape — even on a non-OTel backend — buys forward compatibility: you can swap backends without rewriting instrumentation, and every dashboard and on-call run-book can speak the same field names.

OTel Semantic Conventions: one field name across all services

The Semantic Conventions define the canonical names for common fields: http.route (not route, not path, not url), http.response.status_code (not status, not http_status), db.system (not db_type), error.type. Using these names means:

• A dashboard querying http.response.status_code works uniformly across Node and Go services.
• A backend alert rule referencing error.type:timeout works without per-service configuration.
• A new service that onboards the schema inherits every existing query.

The cost of not following conventions shows up in incident response: when the checkout service calls the field status and the payment service calls it http_status, the join query fails and someone has to know the mapping under pressure at 03:00.