On 2020-03-09 11:21, Venkata Bhagavatula wrote:
Hi Stuart,
sorry for the late reply, i was on vacation.
I will check the recording rule.
The reduction was same for both recorded metric vs original metric.
can you correct my understanding?
After the rule is evaluated, will the type of metric be treated as
Gauge?
If the metric reduced (and it isn't a counter reset) then it suggest it
isn't a counter, and therefore rate() shouldn't be used.
Thanks n Regards,
Chalapathi
On Thu, Feb 27, 2020 at 12:59 PM Stuart Clark
<[email protected]> wrote:
The graph showed a reduction at various points. Is there a bug in
the recording rule calculation that can cause reduction which needs
fixing?
On 27 February 2020 06:24:11 GMT, Venkata Bhagavatula
<[email protected]> wrote:
Hi ,
Thanks for the response. When we a recording rule, what will be the
metric type of this derived counter?. In the increase function
documentation it was mentioned that
increase(v range-vector) calculates the increase in the time series
in the range vector. Breaks in monotonicity (such as counter resets
due to target restarts) are automatically adjusted for.
Also why it worked on the original metric as on both dervied and
original metric has reduction?
Thanks n Regards,
Chalapathi
On Wed, Feb 26, 2020 at 10:49 PM Stuart Clark
<[email protected]> wrote:
Counters must only increase. Any reduction is seen as a counter
reset.
If this isn't a counter use the derivative function rather than rate
On 26 February 2020 14:05:31 GMT, Venkata Bhagavatula
<[email protected]> wrote:
Hi,
In our application, there is one metric that we are deriving from
another metric using recording rules.
When we plot the graphs of recording metric and the original metric
in grafana, we see the graph to follow the same trend. But when we
applied increase , then we have seen recording metric is having huge
spikes, whereas original metric is not having these spikes.
following is the plotted graph:
The bottom panels show the increase of both these metrics over
time. As you can see, there are points where the metric values goes
down. Prometheus handles these as resets for metric type
“Counter”, and the increase function handles it gracefully.
Can you let us know how these recording metrics are treated in
prometheus? and any pointers on how to debug this issue.
Thanks n Regards,
Chalapathi.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
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/CABXnQPuBknw9miVXT0q22YwY%2BiHRLPskaQ45fteARLEzuL9XKg%40mail.gmail.com
[1].
Links:
------
[1]
https://groups.google.com/d/msgid/prometheus-users/CABXnQPuBknw9miVXT0q22YwY%2BiHRLPskaQ45fteARLEzuL9XKg%40mail.gmail.com?utm_medium=email&utm_source=footer
--
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/1b9b97087f81b3bb83594ee108668a3b%40Jahingo.com.
