Closed srclosson closed 11 months ago
@srclosson would you be contributing the implementation of this component?
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.
@srclosson would you please answer my earlier comment?
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.
I just confirmed with @srclosson that we can close this one for now. If there are people interested in contributing code for this component, feel free to open a new issue or reopen this one.
The purpose and use-cases of the new component
The new receiver would allow OTEL to collect netflow/IPFix data. Use cases cover
Example configuration for the component
I'm wondering if it would make sense to do something equivalent to telegraph?
Telemetry data types supported
Given the example from the telegraf input plugin, I would expect lots of metadata?
The actual data would be heavily labelled. The preference would be to capture the data in the most usable and informative way possible. Given that this may result in high cardinality, it's suggested that the appropriate processor be used to translate metadata give the users unique use case.
Is this a vendor-specific component?
Sponsor (optional)
No response
Additional context
Thank-you for considering this!