You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Code-Hex
changed the title
Support field for gauge metric
otel2influx: Support field for gauge metric
Jul 9, 2024
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 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.
The text was updated successfully, but these errors were encountered: