In OpenTelemetry, when should something be recorded as a span event, as a span link, or as a separate child span? Give the rule for each and an example.

## The decision, stated once - **Has its own duration and deserves independent timing/searching → child span.** - **Is a moment in time inside a span's life → event.** - **Relates this span to another span that is not its parent → link.** Everything below is why. ## Child spans A child span is a full span: its own id, its own start and end, its own attributes, events, status. It costs a record in the backend, it participates in the trace tree, and it is the only one of the three that can be timed on its own. Use it for outbound calls, database queries, queue publishes, and internal work whose latency you want to attribute. The failure mode is over-instrumentation: a span per loop iteration or per tiny helper produces traces of thousands of spans that are expensive to store and unreadable to a human. When you find yourself wanting a span for something instantaneous or trivially fast, you probably want an event or an attribute. ## Events An event is `{ name, timestamp, attributes }` attached to a span. It has no duration and no identity, and it cannot be found without finding its parent span first. It is the right shape for: an exception being recorded, a cache hit or miss, a retry attempt starting, a lock being acquired, a state transition. The most important standard case is the exception event, whose conventional name is `exception` with attributes `exception.type`, `exception.message`, `exception.stacktrace` and `exception.escaped`. Note the separation that catches people out: **recording the exception event does not set the span's status**. Handling an exception and continuing is an event on a span whose status stays UNSET; a genuine failure needs the status set to ERROR as a separate act. Events are cheap relative to spans but not free — they are bounded by per-span limits, and once exceeded the model records a `dropped_events_count` rather than growing without bound. Their real weakness is queryability: backends generally index spans far better than events, so something you will want to search across all traces is often better as a span attribute or a log record. ## Links A link holds another span's context (trace id, span id, trace flags, tracestate) plus its own attributes. It says "this span is related to that one" and deliberately says nothing about causality direction, nesting or timing. A span may have many links; they are set at span creation in most SDKs. Why the model needs them: parenthood is single-valued and implies containment. Some real relationships are neither. Three concrete cases: - **Batch consumption.** A consumer pulls a hundred messages produced by many different requests. Parenting the processing span to one of them would be arbitrary and would silently attach ninety-nine unrelated traces' worth of meaning to one. Instead the consumer starts a new trace and links to each producer's span context. - **Fan-in / join.** Several independent operations converge; the joining span links to all contributors. - **Deferred or replayed work.** Something reprocessed hours later from a dead-letter queue should not be nested inside a trace that ended long ago — a new trace with a link preserves the association without producing a trace with an eight-hour root span. The practical caveat is that backend support for links is uneven: many UIs render them as a secondary "related traces" affordance rather than in the waterfall, so do not rely on links being as discoverable as parenthood. ## Events versus log records There is a genuine overlap: an OpenTelemetry log record correlated to the active span carries roughly the same information as a span event — a timestamp, a body/name, attributes, and trace context. The differences in practice are that log records are stored and indexed as their own signal (searchable without the trace, retained on their own schedule, subject to their own volume controls), whereas events are inseparable from their span and vanish with it. If a 1% trace sampler drops the span, its events are gone; a log record survives. The specification has been converging these — event semantics are increasingly expressed on top of the log record schema — so treat "which one" as partly a question of what your backend indexes well. ## Sampling interaction One last consequence worth voicing in an interview: child spans are sampled with their trace, so nothing about them survives a dropped trace either; events likewise. Links are just fields, so a linked-to trace being dropped leaves you holding a reference to a trace that no longer exists. None of this is a defect, but it explains why critical, must-not-lose information belongs in metrics or logs rather than exclusively in trace-attached data.