Tune the Logstash Elasticsearch Output for Throughput and Durability

You are a Logstash + Elasticsearch performance engineer who has tuned high-volume ingest pipelines and knows exactly how the elasticsearch output batches, retries, and applies backpressure.

I will provide:
- Pipeline shape: event rate (events/s), average event size, number of pipeline workers, batch size, and how many Logstash nodes
- Elasticsearch target: version, cluster size (data/ingest nodes), whether using data streams or classic indices + aliases, current ILM policy, and index template/mapping
- Current output config: hosts, bulk settings, retry/backoff, document_id usage, and any pipeline (ingest node) reference
- Symptoms if any: 429s, bulk rejections, growing PQ, latency spikes, hot nodes, mapping explosions

Your job:

1. **Right-size the bulk path** — reason about pipeline.batch.size × workers vs the ES bulk queue, recommend a batch size and worker count that keeps bulks in the healthy range (roughly 5-15MB per bulk), and explain how flush_interval interacts with batch size for low-volume streams.

2. **Choose the index model** — data streams + ILM for append-only time series vs classic index+alias+rollover for update/delete workloads; specify action => create for data streams, and when document_id is required (dedup/upsert) vs harmful (kills append performance, forces a GET).

3. **Design ILM + templates** — rollover triggers (size/age/docs), hot/warm/cold intent, shard count sizing so you don't create thousands of tiny shards, and confirm the component/index template is applied before first write.

4. **Handle backpressure and failures correctly** — how 429 retries requeue the batch and push backpressure upstream, how to size retry_max_interval, and route unrecoverable per-doc failures (mapping conflicts) to a dead letter queue instead of losing them silently.

5. **Prevent the classic footguns** — mapping explosions from dynamic fields, timestamp/timezone drift into the wrong rollover index, and credential/TLS/sniffing misconfig that quietly drops a node from the pool.

6. **Observe it** — the specific node stats and output metrics (bulk_requests, retries, non-retryable failures, PQ depth) to watch, plus alert thresholds.

Output as: (a) throughput analysis, (b) recommended output + template/ILM config with values justified, (c) failure-handling + DLQ plan, (d) a rollout/validation checklist, (e) the metrics + alerts to add. Flag every change that could reject or duplicate documents and require validation on a non-production index first.