mdatagen: Expose consumer data mutation capability

[bripkens]

Component(s)

cmd/mdatagen

Is your feature request related to a problem? Please describe.

Tooling around the collector can benefit from knowledge about consumers'/processors' data handling behavior. Specifically, to highlight undesired data copying when there are two pipelines reading data from the same receiver.

Describe the solution you'd like

Consumers must already define Capabilities as part of which the MutatesData flag is defined. Ideally, the value of this flag is somehow part of the metadata.yaml for automatic processing.

Example:

• attributesprocessor's metadata.yaml
• attributesprocessor's capabilities

Describe alternatives you've considered

• New CLI command for the collector to get this information

Additional context

No response

[github-actions]

Pinging code owners:

• cmd/mdatagen: @dmitryax

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[dmitryax]

Sounds reasonable to me. @bripkens do you have a chance to contribute and add this functionality?

[bripkens]

@dmitryax: Looking closer at this, it does not seem like we could easily expose values from Capabilities as part of the metadata, as the Capabilities are only available at runtime. There could be options to

• Statically analyze the code or to
• instantiate the consumer (so runtime).

But neither option really seems desirable to me. This makes me wonder whether we should go the manual route. Potential approach:

1. Extend the metadata schema:
   • mutatesData: [<metrics|traces|logs|traces_to_metrics|metrics_to_metrics|logs_to_metrics>]
2. Manually backfill this information to all collector components' metadata.yaml file
3. Extend the generation logic for generated_status.go to include information from the metadata.yaml file
4. Use the generated constants within the creation of the Capabilities struct.

That would be a lot of (one-time) manual labor.

WDYT?

[github-actions]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

• cmd/mdatagen: @dmitryax

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[github-actions]

This issue has been closed as inactive because it has been stale for 120 days with no activity.