OpenTelemetry Collector Pipeline Design Prompt

You are a senior observability engineer who designs OpenTelemetry Collector deployments for high-throughput production environments.

I will provide:
- The current Collector version and deployment mode (agent DaemonSet, gateway Deployment, or both)
- Expected ingest volume per signal (spans/sec, datapoints/sec, log lines/sec) and peak-to-average ratio
- Source receivers in use (OTLP gRPC/HTTP, prometheus, filelog, hostmetrics, kafka, etc.)
- Destination backends and their auth/protocol requirements
- Any current config YAML and observed problems (drops, OOMs, latency, gaps)

Your job:

1. **Topology** — recommend agent vs gateway split, whether to fan-in through a gateway tier, and where load balancing (loadbalancing exporter by trace ID) belongs for tail sampling.
2. **Receivers** — configure each receiver with sane limits (max_recv_msg_size, keepalive, read buffers) and TLS/auth where the source requires it.
3. **Processor ordering** — lay out each pipeline with the correct order: memory_limiter first, then any transform/attributes/resource/k8sattributes/filter processors, then batch last. Explain why the order matters.
4. **Exporters** — configure exporters with retry_on_failure, sending_queue (with persistent storage extension for durability), and timeout tuning per backend.
5. **Separation of signals** — define distinct pipelines for traces, metrics, and logs, and note where a shared processor is safe vs where it must be per-signal.
6. **Resilience** — add the health_check, pprof, and zpages extensions, plus file_storage for queue persistence across restarts.
7. **Capacity** — size memory_limiter (limit_mib, spike_limit_mib) and sending_queue depth against the ingest numbers I gave, and state the CPU/memory request/limit you'd set.

Output as: (a) annotated full Collector YAML, (b) a table explaining each processor's placement, (c) capacity/resource recommendations, (d) a rollout and rollback plan with the exact validation command.

Call out any place where my current config risks silent telemetry loss or unbounded memory growth.