This is required in order to be able to route sink-type integrations to logs-<service.name>-<namespace>, as this will match the logs-*-* index template instead of the one from the integration.

We should be able to re-use this mapping: https://github.com/elastic/elastic-package/blob/main/internal/builder/_static/ecs_mappings.yaml and convert it to a component template that is imported by the logs-*-* index template. With #95558, we can simplify the dynamic template.

An open question is how to keep the upstream ECS mappings, the elastic-package ECS mappings and the ECS mappings in Elasticsearch in sync.

Considerations

• Should we only include field definitions from ECS core? Some logging fields wouldn't fall into this, however.
• Split core and extended into different component templates?
• Exclude fields with the nested field type from the component templates so that they'll work with subobjects: false?
• Avoid mapping field types that are the default types, such as keyword for string fields
• As much as possible, map on common naming patterns, such as name, message, *_ip, ip, etc.
• Minimize the possibility of breaking changes where a new version of the mapping would change the field type

Related:

• Using ECS fields in Elasticsearch indices / data streams ecs#1869
• Optionally use ECS conventions for dynamic mappings #85692