Uh. I see what you mean. Also, yes, after some fiddling, this isn't 
actually a good query.

Also, also, I have some further problems with instances and pods. The same 
number is coming from different pods in the cluster. Prometheus nicely 
shows that separately but I can't "without" it.

Somehow I have to collapse the two different metrics into one. So now there 
are two rows:

| time | id  | endpoint | instance          | pod    | service  | metric    
             | value |
|---------|-----|----------------|------------------------|-----------|--------------|--------------------------|-----------|
| ...    . | ... | ....             | 10.1.1.1:1234 | pod-a | metrics | 
server_statistic | 5         |
| ...      | ... | ....             | 10.1.1.2:1234 | pod-b | metrics | 
server_statistic | 5         |

So I have to merge this into a single metric ignoring instance and pod 
different but not adding them together. I could just divide by two, but 
that would mean that I would potentially miss metrics. But I might have to 
take that into consideration and say... meh.

On Tuesday, September 1, 2020 at 3:59:17 PM UTC+2 b.ca...@pobox.com wrote:

> If it works for you, then you get to own the query and the results :-)  
> But "garbage in, garbage out" applies here.
>
> What you've written doesn't "count increases".  It calculates average 
> rates of increase and scales them across the whole period, whilst skipping 
> steps where the counter appears to have reset.
>
> Suppose you take a window of 10 time units, which contains the following 
> 10 samples:
>
> . 0 ... 0 ... 3 ... 3 ... 0 ... 0 ... 0 ... 2 ... 0 ... 0 .
>   <----------------->     <----------------->     <----->
>      increase of 3   (rst)   increase of 2   (rst)increase of 0 
>
> |<--------------------- 10 time units ------------------->|
>
>
> I think that increase() works something like this:
> . an increase of 3 over 3 time units
> . an increase of 2 over 3 time units
> . an increase of 0 over 1 time unit
> = an increase of 5 over 7 time units
> = average rate of 5/7
> . scaled to a total time window of 10 units
> = answer of 7.14
>
> The value you were expecting to see was probably 5 (3+2) or possibly 8 
> (3+3+2).
>

-- 
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/52fe1a97-2f4e-46eb-8216-f24bd29cce10n%40googlegroups.com.

Reply via email to