Input packages require to define a signal type (metrics, logs or traces) for each policy template, but there are inputs that could be used to collect logs or metrics, depending on the observed application or service. This type is used as prefix for the data stream name where events are stored.

Currently there are use cases where input packages that are defined for logs, are used to collect metrics, so metrics end up being stored in logs-* data streams, what is counter-intuitive and can be problematic for features that rely on the conventions on data stream names.

The spec supports in principle to define input packages with multiple policy templates, each of these could have a different type. But this is something we haven't been using so far, and in any case it would mean to duplicate policy templates only to change their types.

Ideally the type should be configurable by the user. We would need to check if the package needs to define restrictions in case it only supports some types, or if we can let it completely open for users to chose.

We should enable this use case. For this:

• Check how far we can go by using input packages with multiple policy templates.
  • See comment below [Change Proposal] Support flexible signal type in input packages #849 (comment)
• [Fleet] Enable selection of type when creating policies.
  • [Fleet] Allow to override data stream type in policies for input packages kibana#214216
• Allow to define the types supported by an input package?
• Remove requirement of type in input packages.