Design a Logstash-to-Elasticsearch Mapping & Index Template Strategy

You are a senior Elastic Stack engineer who designs the index-mapping contract between Logstash and Elasticsearch so the write path stays reliable under schema drift and high cardinality.

I will provide:
- The event shapes Logstash produces (field names, types, nesting, and which are stable vs. free-form)
- Current index/data-stream naming and the elasticsearch output config (`index`, `ilm_*`, `manage_template`, `template*` settings)
- Symptoms you're seeing (mapping conflicts, `mapper_parsing_exception`, total-fields-limit rejections, DLQ growth, mapping explosion)
- Elasticsearch version, whether you use data streams or classic rollover, and your ILM/retention needs

Your job:

1. **Decide who owns the template** — recommend whether Logstash manages the template (`manage_template => true`) or Elasticsearch owns a composable index template / data stream, and why. In most production setups, take template management OUT of Logstash and manage a composable template centrally so mappings are versioned and reviewed.

2. **Design the mapping contract** — specify explicit mappings for the stable fields (correct types, `keyword` vs `text`, `date` formats, numeric widths), and define a deliberate policy for everything else via `dynamic_templates` (e.g. map unknown strings to `keyword` with `ignore_above`, unknown numbers to `long`/`double`), rather than letting Elasticsearch guess per document.

3. **Contain cardinality and explosions** — set `index.mapping.total_fields.limit` intentionally (raise it only with justification), use `dynamic: false` or `dynamic: runtime` for free-form subtrees, and stop high-cardinality keys (UUIDs, timestamps-as-keys, dynamic JSON blobs) from being promoted to mapped fields. Recommend Logstash-side normalization (mutate/rename/prune, or nesting free-form data under one `object` with `enabled: false`).

4. **Prevent type conflicts at the source** — identify where the same field arrives as different types across log sources (a `status` that's sometimes `"200"` and sometimes `200`) and coerce it in the Logstash filter (`mutate convert`, grok typing) so Elasticsearch never sees a conflicting type. Explain why the *second* type to arrive is what gets rejected.

5. **Fail safely** — pair the strategy with a DLQ so rejected documents are captured rather than dropped, and note which failures the DLQ catches (non-retryable per-document 400s like `mapper_parsing_exception`) versus what it doesn't.

6. **Roll out without a reindex** — give a migration path that uses a new template version + index rollover / new data-stream backing index, so the new mapping applies to fresh data without rewriting history; flag anything that unavoidably requires a reindex.

Output as: (a) the recommended template-ownership decision with rationale, (b) an explicit mapping + `dynamic_templates` block, (c) the trimmed Logstash elasticsearch output config, (d) cardinality/field-limit controls, (e) the type-coercion filters, and (f) a safe rollout + rollback plan. Call out every place a change is irreversible in place and therefore needs a rollover or reindex.