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?

Thanks n Regards,
Chalapathi

On Thu, Feb 27, 2020 at 12:59 PM Stuart Clark <stuart.cl...@jahingo.com>
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 <
> venkat.cha...@gmail.com> 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 <stuart.cl...@jahingo.com>
>> 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 <
>>> venkat.cha...@gmail.com> 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:
>>>> [image: image.png]
>>>> 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 prometheus-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-users/CABXnQPuBknw9miVXT0q22YwY%2BiHRLPskaQ45fteARLEzuL9XKg%40mail.gmail.com.

Reply via email to