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
~~it might be desirable to have some implementation of a Prometheus Gauge metric that's actually the current rolling average of measurements over some time window.
this would be intended for use cases where, for example, you read data from a sensor every second, but Prometheus only scrapes the device's metrics every ten seconds. in this case, the scrape is going to see just the data from the most recent read of the sensor, which may not accurately reflect the state of the world --- data from the other 9 reads of the sensor in that time window is completely discarded.
in this case, it might be desirable to expose a metric value that is actually an aggregate of multiple reads, so that the value seen by prometheus is less susceptible to random spikiness in the measurement?~~
EDIT: lol, this is basically how a prometheus Summary metric is supposed to be used. we should just add support for that...
The text was updated successfully, but these errors were encountered:
hawkw
changed the title
add a rolling average gauge
add summary metrics
Mar 4, 2023
~~it might be desirable to have some implementation of a Prometheus Gauge metric that's actually the current rolling average of measurements over some time window.
this would be intended for use cases where, for example, you read data from a sensor every second, but Prometheus only scrapes the device's metrics every ten seconds. in this case, the scrape is going to see just the data from the most recent read of the sensor, which may not accurately reflect the state of the world --- data from the other 9 reads of the sensor in that time window is completely discarded.
in this case, it might be desirable to expose a metric value that is actually an aggregate of multiple reads, so that the value seen by prometheus is less susceptible to random spikiness in the measurement?~~
EDIT: lol, this is basically how a prometheus Summary metric is supposed to be used. we should just add support for that...
The text was updated successfully, but these errors were encountered: