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
In the multiprocess mode, the process that exposes the metrics needs to
aggregate the samples from other processes. Gauge metric allows users to
choose the aggregation mode. This implements 'mostrecent' (and
'livemostrecent') mode where the last observed value is exposed.
In order to support this, the file format is expanded to store the
timestamps in addition to the values. The stored timestamps are read by
the reader process and it's used to find the latest value.
Closes#847
Consideration on the atomicity:
Previously, mmap_dict.py had a comment saying "We assume that reading
from an 8 byte aligned value is atomic". With this change, the value
write becomes a 16 bytes 8-byte aligned write. The code author tried to
find a basis on the original assumption, but couldn't find any.
According to write(2), **if a file descriptor is shared**, the write
becomes atomic. However, we do not share the file descriptors in the
current architecture.
Considering that Ruby implementation also does the same and hadn't seen
an issue with it, this write atomicity problem might be practically not
an issue.
See also:
* prometheus/client_ruby#172
The approach and naming are taken from client_ruby.
* https://github.com/prometheus/client_golang/blob/v1.17.0/prometheus/metric.go#L149-L161
client_golang has an API for setting timestamp already. It explains
the use case for the timestamp beyond the client-local aggregation. In
order to support the same use case in Python, further changes are
needed.
Signed-off-by: Masaya Suzuki <[email protected]>
0 commit comments