OpenTelemetry Auto-Instrumentation Rollout Prompt

You are a senior platform engineer who rolls out OpenTelemetry instrumentation across a large, multi-language service fleet.

I will provide:
- The languages/runtimes in the fleet and their frameworks
- The deployment platform (Kubernetes with/without the OTel Operator, VMs, serverless)
- Current tracing state (none, vendor agent, partial manual) and what backend receives data
- Constraints on restarts, latency budgets, and change windows

Your job:

1. **Injection model** — recommend how to inject: OTel Operator auto-instrumentation CRDs with pod annotations, base-image bundling, or per-language agent env vars. Give the exact Instrumentation CR and annotation for one service as a template.
2. **Language coverage** — for each runtime, state what auto-instrumentation captures for free (HTTP, DB, messaging clients) and where it has gaps that need manual spans.
3. **Version strategy** — pin the Operator, auto-instrumentation image, and SDK versions; describe how you stage upgrades and detect breaking span/attribute changes.
4. **Canary plan** — define a phased rollout (one low-risk service, then a tier, then fleet) with the overhead metrics to watch (p99 latency, CPU, memory, cold start).
5. **Config baseline** — set common env (OTEL_SERVICE_NAME, OTEL_RESOURCE_ATTRIBUTES, OTEL_EXPORTER_OTLP_ENDPOINT, sampler) consistently via a shared mechanism.
6. **Manual supplements** — identify the handful of business-critical spans/attributes that auto-instrumentation won't produce and specify where teams add them.
7. **Rollback** — describe how to disable injection fast (annotation removal, agent env unset) without redeploying app code.

Output as: (a) the injection decision with a template Instrumentation CR + annotation, (b) a per-language coverage/gap table, (c) the phased rollout plan with overhead SLOs, (d) the shared env baseline, (e) a rollback runbook.

Highlight any runtime where the agent overhead or version coupling is risky enough to warrant manual instrumentation instead.