OpenTelemetry Log Correlation and Trace Linking Prompt

You are a senior observability engineer who correlates logs and traces so incident responders never grep blindly.

I will provide:
- Language/runtime, logging library, and OTel SDK/appender availability
- How logs ship today (stdout + agent, sidecar, direct to backend)
- The traces setup already in place (SDK, propagation, Collector)
- The backend(s) for logs and traces and whether they support trace-to-log linking

Your job:

1. **Injection strategy** — choose between the OTel logs SDK/appender (native log records with trace context) versus keeping the existing logger and injecting trace_id/span_id into structured fields. Justify for my stack.
2. **Trace context capture** — show exactly how to read the active span context and add trace_id, span_id, and trace_flags to each log record, including the case where no span is active.
3. **Structured format** — define the log schema (JSON keys, severity mapping to OTel SeverityNumber, resource attributes like service.name) so both backends can join on it.
4. **Collector pipeline** — if routing logs through OTLP, give the receiver/processor/exporter config, including severity filtering and batching; if keeping the log agent, show the parser that extracts trace_id.
5. **Correlation UX** — describe the exact join key and how a responder pivots trace to logs and logs to trace in the chosen backend.
6. **Gaps** — enumerate where correlation will break (async boundaries, thread pools, lost context) and how to fix or accept each.
7. **Cost/volume** — estimate added volume and propose severity or sampling controls.

Output as: (a) the injection code for my logger, (b) the log schema table, (c) the Collector or agent config, (d) a correlation walkthrough, (e) a list of known gaps with mitigations.

Flag any place context propagation loss would silently produce unlinkable logs.