So if I'm understanding you correctly. You have multiple pods
exporting a gauge based on a remote request, and because it is load
balanced the request could go to one of many pods, and you are trying
to figure out which one is the most recent? This sounds like a
perfect use case for pushgateway
On 25/08/2023 04:37, sunil sahu wrote:
Hello All,
I need help in my below use case.
We have a centralized python application which continuously monitors
state for other applications by running tests. We creates
*GUAGE* metrics with a value (Ex. 100) and set to different value when
state
I've opened a feature/issue that I plan to implement for my org and submit
upstream to the Prometheus client for python.
The link is here:
https://github.com/prometheus/client_python/issues/953
The proposal is to equip the prometheus client with the ability to
concurrently respond with an HTTP
Hello All,
I need help in my below use case.
We have a centralized python application which continuously monitors state
for other applications by running tests. We creates *GUAGE* metrics with a
value (Ex. 100) and set to different value when state changes (Ex. 200 or
300) using gauge's set
Thanks a lot Julien, tbh I wasn't aware of that table :) Thanks for
pointing me to it.
On Mon, Sep 4, 2023 at 3:45 PM Julien Pivotto
wrote:
> On 04 Sep 14:20, 'Fabian Stäber' via Prometheus Developers wrote:
> > Hi,
> >
> > Many Prometheus client libraries export a metric named
> >
+1 to keeping consistent with the other libraries.
We should clarify the docs that `time` is an ok value in addition to
`timestamp`.
On Mon, Sep 4, 2023 at 2:44 PM Julius Volz wrote:
> Since that's a metric that is standardized across our client libraries, we
> should keep the existing name
On 04 Sep 14:20, 'Fabian Stäber' via Prometheus Developers wrote:
> Hi,
>
> Many Prometheus client libraries export a metric named
> "start_time_seconds", which is the timestamp when the application was
> started.
>
> However, according to https://prometheus.io/docs/practices/naming/ the name
>
Since that's a metric that is standardized across our client libraries, we
should keep the existing name IMO. I'm also not sure if the naming doc is
that clear on whether a timestamp necessarily has to be named "timestamp"
vs. just "time". We also use just "time" in other places as well, like
Hi,
Many Prometheus client libraries export a metric named
"start_time_seconds", which is the timestamp when the application was
started.
However, according to https://prometheus.io/docs/practices/naming/ the name
should be "start_timestamp_seconds".
So, as the Java client will have breaking
9 matches
Mail list logo
