Describe the OpenTelemetry log record as a data structure: what fields it carries, why it has two timestamps, and how its 1-24 severity numbering is meant to be used.

## A log is a typed record, not a line In OpenTelemetry a log is a record with a fixed schema, carried over OTLP in the same envelope shape as the other signals. Knowing the schema field by field is what tells you what survives a pipeline, what a backend can index, and what a query can compare across services written by different teams in different languages. ## The two timestamps - **`time_unix_nano`** (spec name: Timestamp) — when the event actually occurred. It is **optional**, because plenty of sources genuinely do not record one: a bare line of text, a device that emits no clock reading, a subsystem whose format has no time field. - **`observed_time_unix_nano`** (ObservedTimestamp) — when the collection system first saw the record. It is **always present**; when event time is missing, this is what a consumer falls back to for ordering. They answer different questions and can differ by a long way. A file tailed hours after a partition, or a batch flushed after a queue drains, produces records whose event time orders the story and whose observed time explains delivery. Keeping both means a late-arriving record can still be placed correctly in the narrative while you can still see that it arrived late. ## Severity: a number and the original text Severity is two fields on purpose. `severity_number` is an integer 1-24, arranged as **six bands of four**: TRACE 1-4, DEBUG 5-8, INFO 9-12, WARN 13-16, ERROR 17-20, FATAL 21-24 (0/unset means unspecified). The banding is the whole point. Source libraries disagree about how many gradations they offer and what they call them — one has a level between DEBUG and INFO, another has two flavours of warning, another lets you define your own. A single flat enum would force those into lossy collisions. Four slots per band give a mapper room to place a richer scheme inside the right band while preserving relative order within it. The consequence is the thing to say in an interview: because the *number* is banded the same way everywhere, `severity_number >= 13` means "WARN or worse" for **every** source in a heterogeneous fleet, without the query having to know which library emitted the record or what string it used. Filtering on `severity_text` cannot do that — the text is free-form and differs per library ("warn", "warning", "WARNING", "W"). `severity_text` exists so the mapping is not destructive: the original label is preserved verbatim for display and for anyone who needs the source's own vocabulary back. ## Body versus attributes `body` is an **`AnyValue`**: a string, a number, a boolean, a byte array, an array, or a nested key/value map. That typing is deliberate — a structured event can be carried as structure, with nested maps and arrays intact, instead of being serialised into a string that a backend then has to substring-search or re-parse. `attributes` are typed key/values governed by the semantic conventions, and they are what you filter, group and aggregate on. The practical split: **body = the payload of the event; attributes = the dimensions of the event**. Two habits cause pain. Formatting everything into a string body pushes backends into substring matching, which is slow and imprecise. Duplicating every attribute inside the body doubles storage and buys nothing. A small set of well-named attributes plus a structured body indexes well and reads well. When attribute count or value length limits truncate, `dropped_attributes_count` records how many were lost, so a consumer can tell a sparse record from a truncated one rather than silently believing what it received is complete. ## `event_name` Newer revisions of the record carry an `event_name` field, used when the record represents a *named* event rather than free-form text — the name identifies the event's shape, and the body/attributes carry its payload. Earlier tooling expressed the same idea as an `event.name` attribute, so both shapes appear in real pipelines. ## The envelope Records do not travel alone. The structure is **Resource -> InstrumentationScope -> LogRecord**, the same nesting spans use. The resource carries the identity of the emitting entity (service name, instance, host, deployment attributes) and is attached once for many records rather than repeated per record; the instrumentation scope records which library or module emitted them. So a log inherits producer identity for free, and "all logs from this service instance" is a resource-level filter rather than a string convention someone had to remember to include. ## Correlation fields, and one caveat `trace_id`, `span_id` and `trace_flags` are **fields of the record**, not attributes bolted on by convention. That is what lets a backend offer symmetric navigation: from a span to the records emitted during it, and from a record back to its trace. The caveat worth knowing: `trace_flags` carries the sampled bit of the trace that was active when the record was created. If traces are sampled at a low rate, most records will point at traces that were **never exported** — the ids are correct, but the trace they name does not exist in the backend. That is not a defect in the record; it means "jump to trace" fails most of the time unless you keep an unsampled slice or bias sampling toward interesting requests. ## Log record versus span event Both are timestamped, attributed points in time with trace correlation, so the schemas look similar. The difference that matters is lifecycle and indexing. A span event is *part of* a span: it is sampled away with the span, retained with it, and reachable only through it. A log record is its own signal with its own retention, its own volume controls and its own index, searchable across all requests without going through a trace at all. That difference — plus the record's independence from trace sampling — is why event semantics have been converging onto the log-record schema.