OpenTelemetry calls its Logs API a bridge API rather than something application developers should call directly. What does that mean in practice, how does a log record acquire a trace id, and what are the ways of getting an existing application's logs into OTLP?

## Why logs are the odd signal With traces and metrics OpenTelemetry could define a fresh API because most applications had no strongly entrenched alternative. Logging is the opposite: every language has one or two dominant libraries, wired into every file of every codebase, with configuration people rely on. Replacing them was never realistic, so the design goal became *interoperation*: define a log **data model** and a transport, and let existing libraries feed it. Hence the phrasing in the specification: the Logs API is a **bridge API**, intended for authors of appenders/handlers, not for application code. You keep calling your logger; someone attaches a bridge. ## The pipeline Structurally it mirrors tracing: - **LoggerProvider** — configured once by the application (or an agent), carrying the same resource that identifies the service. - **Logger** — obtained per instrumentation scope, as with tracers. - **LogRecordProcessor** — batching in production; a simple pass-through exists for debugging. - **Exporter** — OTLP to a collector or backend. The log record itself has a defined shape: timestamp and observed timestamp, severity number plus severity text, body, attributes, resource, instrumentation scope, and trace context fields (trace id, span id, trace flags). The separation of severity *number* from *text* matters: the number is the normalised, comparable value across libraries whose level names differ. ## How correlation happens When the bridge emits a record it reads the active context. If a span is current on that execution, its trace id and span id are written into the record's dedicated fields. That is what makes 'show the logs for this trace' a query rather than a manual timestamp hunt, and it is why the bridge must run where the context is live — a record handed to an async queue and bridged later on another thread loses the association unless the context travelled with it. If you are not exporting logs via OTLP at all, the same correlation is achievable by injecting the ids into the structured fields of the log line and letting your collection pipeline index them. Less integrated, equally effective for pivoting. ## Two deployment shapes **In-process bridge → OTLP.** Records leave the process directly, keeping full structure and typed attributes with no parsing. The costs: telemetry now shares the application's fate (records buffered in the batch processor are lost if it is killed) and its network dependencies, and you must ensure shutdown flushes. **Write to stdout or a file, collect out-of-process.** The classic container pattern: the application writes structured JSON, an agent or sidecar tails it and converts to OTLP. Survives process death, decouples telemetry from the application's networking, and is often mandated by platform logging. The costs are a parsing step, potential fidelity loss (types flattened to strings), and dependence on the collection layer being present. Many fleets run both: OTLP for services where structure matters, file collection as the baseline everywhere. ## Practical cautions - **Do not double-ship.** Bridging to OTLP while also writing the same records to a file that gets collected doubles cost and creates two slightly different copies. - **Severity mapping is a translation.** Check how your library's levels map onto severity numbers before writing alerts on them. - **Watch feedback loops.** If the exporter itself logs errors through the bridged logger, a backend outage can produce a log storm about failing to send logs. Bridges normally suppress their own output; verify it. - **Volume dominates.** Logs are usually the largest signal by bytes; the batching processor's queue and the collection pipeline, not the application, are where that has to be managed.