Thank you for the great library. We are using through OpenTelemetry Collector.
We are using a cloud plan and are only sending one gauge metric and now the cardinality is so high that we are using the full plan. Upon investigation, it appears to be due to the creation of lots of tags.
Since most of them are indeed not treated as search filters (for dashboard rendering purposes), we thought it would be nice to be able to send them as fields to improve the situation.
We are using MetricsSchemaTelegrafPrometheusV2 and are sending key values using Resource.attributes. I have consulted the documentation and it seems that it only supports treating them as tags.
As a suggestion, I was wondering if it would be possible to modify the logic to treat a key as a field if its prefix is "field_", for example, while maintaining backward compatibility.
We would appreciate it if you could support treating some of them as fields.
Thank you for the great library. We are using through OpenTelemetry Collector.
We are using a cloud plan and are only sending one gauge metric and now the cardinality is so high that we are using the full plan. Upon investigation, it appears to be due to the creation of lots of tags.
Since most of them are indeed not treated as search filters (for dashboard rendering purposes), we thought it would be nice to be able to send them as fields to improve the situation.
We are using
MetricsSchemaTelegrafPrometheusV2and are sending key values usingResource.attributes. I have consulted the documentation and it seems that it only supports treating them as tags.As a suggestion, I was wondering if it would be possible to modify the logic to treat a key as a field if its prefix is
"field_", for example, while maintaining backward compatibility.We would appreciate it if you could support treating some of them as fields.