On 23/01/2021 13:15, akshay sharma wrote:
Thanks for the clarification,
It makes sense, but why we are deleting the data as soon as Prometheus
scrapes becuase next time (at t15minutes) we can't register same
metric ,as it is already registered at time t1. We are using
Prometheus go client and that's the limitation.
And if we delete data or unregistered at t15, and add new data or
register again with new values then will loose data which was register
by other go routines and which haven't processed yet.
So how can we monitor dynamic metrics ??
Or how can we resolve above issue?
Or can we do ,only set.value (for the metric was already register)
instead of unregister and register again? Using goclient library.??
I'm not as directly familiar with the Go client library, but my
understanding is it operates very similarly with other ones such as the
Python one.
Broadly there are two ways to use the client library. The first is for
direct instrumentation of an application. With this you create
counter/gauge/etc objects and then when something happens (e.g.
increment a counter on an event, add request time to a counter) you use
those objects to adjust the current metric state. Separately you have
the HTTP interface which allows Prometheus (or any other system which
can understand OpenMetrics or Prometheus exposition format) to fetch the
current metric state.
The second mechanism, which sound like the one you actually want, is
commonly used for exporters where the metric information isn't created
via code running and adjusting objects directly, but instead by calling
an external service and converting the returned data or (as in your
case) querying a cache of such data. For that you would register a
custom collector which is called on every scrape. That collector is then
responsible for doing whatever is needed to obtain the information
(again for you just look at some local state data storage) and then
convert and return the data in the correct Prometheus format. The
difference between the two can be easily seen with a counter. For direct
instrumentation you would have an object that represents the counter and
then you would use the increment method to adjust its value based on the
events that are occurring (e.g. adding the timing of an action to a
counter). At no point does the main code know or care what the current
value of the counter is - that is purely for the HTTP interface to use.
For an exporter the custom collector instead creates an object during
the scrape process (rather than it being created on startup) and
directly sets the value (not using increments).
Some Python code can be found here to explain that:
https://godoc.org/github.com/prometheus/client_golang/prometheus#hdr-Custom_Collectors_and_constant_Metrics
For Go the equivalent documentation seems to be here:
https://godoc.org/github.com/prometheus/client_golang/prometheus#hdr-Custom_Collectors_and_constant_Metrics
From what you describe I'm not sure if you are using the custom
collector method or are trying to use the mechanism designed for direct
instrumentation.
--
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/2224f40b-2ecf-93b0-1fe5-f7a9d473d217%40Jahingo.com.
