On 07/08/2022 08:23, Johny wrote:
We are migrating telemetry backend from legacy database to Prometheus
and require estimating percentiles on gauge metrics published by user
applications. Estimating percentiles on a gauge metric in Prometheus
is not feasible and for a number of reasons, client applications will
be difficult to modify to start publishing histograms.
I am exploring feasibility of creating a histogram in a recording rule
in Prometheus based on the metrics published by users. The partial
work put in so far seems inefficient, also illegible. Is there a
recommended approach to solve this problem? As stated earlier, it will
be extremely hard to solve the problem on the client side and I am
looking for a solution within Prometheus.
*Current metric is a gauge with with values representing request latency.*
http_duration_milliseconds_gauge{instance="instance1:port1"}[1h]
1659752188 100
1659752068 120
..
1659751708 150
1659751588 160
I'm not really sure what you are meaning by this metric?
A histogram of request latencies needs access to all the events that
occur, with details of every single latency value. It can then increment
the counter for a particular sot of range buckets to map the
distribution over time. I don't really understand what the single gauge
represents? Is that the latency of the most recent event? Some average
over the last hour?
Without access to the underlying events I can't see how this can be
possible - which is only possible in the application, or if you store
events elsewhere (e.g. in log files) in a tool that connects to your
event store system.
--
Stuart Clark
--
You received this message because you are subscribed to the Google Groups
"Prometheus Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/prometheus-users/bd420182-c1da-d47b-ae66-3f6cdf8032b9%40Jahingo.com.
