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
After implementing #67 to conform to prometheus best practices, I'd like to apply that PR to the other exporters. I want:
One type to represent number of bytes. SmallData (2^20) and Data (2^30) should just become bytes, so that one doesn't need to lookup source code to figure out how to convert them to bytes.
One type to represent frequency (Hz). Frequency (Hz) and Clock (MHz) should be consolidated into hertz. Clock is annoying in grafana as there isn't a native MHz unit, so one has to multiply values by 1000000 before mapping to Hz.
All exporters to be consistent in the data they are exporting
I haven't decided yet if the other exporters should adopt the more descriptive names like prometheus (eg: prefer "bytes_per_second" over "Throughput"), so I'm unlikely to act on this issue immediately.
I think any solution will require the use of a config field like normalize_units that will be enabled by default. That way new installations will, by default, use the improved units and values, while ongoing installations can opt into preserving their desired behavior
The text was updated successfully, but these errors were encountered:
After implementing #67 to conform to prometheus best practices, I'd like to apply that PR to the other exporters. I want:
I haven't decided yet if the other exporters should adopt the more descriptive names like prometheus (eg: prefer "bytes_per_second" over "Throughput"), so I'm unlikely to act on this issue immediately.
I think any solution will require the use of a config field like
normalize_units
that will be enabled by default. That way new installations will, by default, use the improved units and values, while ongoing installations can opt into preserving their desired behaviorThe text was updated successfully, but these errors were encountered: