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
InfluxDB allow metric submission with what they call "fields" which are merely a bunch of key=value pairs.
Would it make sense to support this as an optional property (Map<String, String>) on Metric or some derived class? I'm struggling to think it makes sense on a derived class myself.
Clearly writers can then support the sending of these as they see fit.
The text was updated successfully, but these errors were encountered:
The "standard" way to do this up to now is to decompose the metric names into field values. Some metrics lend themselves to that more than others, it has to be said, but if you control the namespace of your own metrics, you always have that option. Also, many of the use cases for those tags are to represent metadata about the sender (app, instance, cluster id etc.) so those are basically static and can always be added on top of the Boot metrics without parsing or changing the metric name. Some of the existing exporters already do that (e.g. the Redis one or the Atlas one in Spring Cloud Netflix).
It's pretty common practice amongst users of graphite for instance, and the metric metadata in Spring Boot was chosen intentionally as a "lowest common denominator" in the same spirit. Having said that, Spring Boot 2.0 gives us an opportunity to add "dimensional" metrics, and we have discussed moving metrics out to their own project as part of that effort.
InfluxDB allow metric submission with what they call "fields" which are merely a bunch of key=value pairs.
Would it make sense to support this as an optional property (
Map<String, String>
) onMetric
or some derived class? I'm struggling to think it makes sense on a derived class myself.Clearly writers can then support the sending of these as they see fit.
The text was updated successfully, but these errors were encountered: