stddev_over_time applied to delta

[igh...@gmail.com]

The first query works !

delta(stream_gauge_family{variable=~"delta.*"}[10s])

However, this one fails,

stddev_over_time((delta(stream_gauge_family{variable=~"delta.*"}[10s]))[10s])

with the following error message : 

{ "status": "error", "errorType": "bad_data", "error": "parse error at char 73: range specification must be preceded by a metric selector, but follows a *promql.Call instead", "message": "parse error at char 73: range specification must be preceded by a metric selector, but follows a *promql.Call instead" }

How can i avoid such message ? 

[Brian Brazil]

See https://www.robustperception.io/composing-range-vector-functions-in-promql/

What are you trying to calculate here?

--

Brian Brazil

www.robustperception.io

[igh...@gmail.com]

obtain a time series of standard deviation of the differences between values that are 10s away from each other.

[Brian Brazil]

On 16 June 2017 at 12:40, <igh...@gmail.com> wrote:

obtain a time series of standard deviation of the differences between values that are 10s away from each other.

I don't understand, how is a stddev useful in those circumstances? It's basically the same sort of result as subtraction would be.

Brian

 

On Friday, 16 June 2017 13:33:32 UTC+2, Brian Brazil wrote:

On 16 June 2017 at 12:32, <igh...@gmail.com> wrote:

The first query works !

delta(stream_gauge_family{variable=~"delta.*"}[10s])

However, this one fails,

stddev_over_time((delta(stream_gauge_family{variable=~"delta.*"}[10s]))[10s])

with the following error message : 

{ "status": "error", "errorType": "bad_data", "error": "parse error at char 73: range specification must be preceded by a metric selector, but follows a *promql.Call instead", "message": "parse error at char 73: range specification must be preceded by a metric selector, but follows a *promql.Call instead" }

How can i avoid such message ? 

See https://www.robustperception.io/composing-range-vector-functions-in-promql/

What are you trying to calculate here?

--

Brian Brazil

www.robustperception.io

--
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+unsubscribe@googlegroups.com.
To post to this group, send email to prometheus-users@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-users/ab16cd25-fc25-4acc-b6c6-ba861d5201d7%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Brian Brazil

www.robustperception.io

[igh...@gmail.com]

The time series has jumps at a roughly hour interval. These jumps are expected, so that i don't want to generate alerts when the jumps occurs. However, I'd like to detect changes between these jumps

On Friday, 16 June 2017 13:44:23 UTC+2, Brian Brazil wrote:

On 16 June 2017 at 12:40, <igh...@gmail.com> wrote:

obtain a time series of standard deviation of the differences between values that are 10s away from each other.

I don't understand, how is a stddev useful in those circumstances? It's basically the same sort of result as subtraction would be.

Brian

 

On Friday, 16 June 2017 13:33:32 UTC+2, Brian Brazil wrote:

On 16 June 2017 at 12:32, <igh...@gmail.com> wrote:

The first query works !

delta(stream_gauge_family{variable=~"delta.*"}[10s])

However, this one fails,

stddev_over_time((delta(stream_gauge_family{variable=~"delta.*"}[10s]))[10s])

with the following error message : 

{ "status": "error", "errorType": "bad_data", "error": "parse error at char 73: range specification must be preceded by a metric selector, but follows a *promql.Call instead", "message": "parse error at char 73: range specification must be preceded by a metric selector, but follows a *promql.Call instead" }

How can i avoid such message ? 

See https://www.robustperception.io/composing-range-vector-functions-in-promql/

What are you trying to calculate here?

--

Brian Brazil

www.robustperception.io

--

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-use...@googlegroups.com.
To post to this group, send email to promethe...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-users/ab16cd25-fc25-4acc-b6c6-ba861d5201d7%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Brian Brazil

www.robustperception.io

[igh...@gmail.com]

Maybe i can rephrase the question in that way. If i have an easy way to detect the intervals in the time series that i do not want to monitor. Is it possible to extract only the requested ones, with the current prometheus query language or should i compute those events separately ? 

something like that

original time series : ***************++++++************

filtered time series :  ***************             ***********

[Brian Brazil]

On 16 June 2017 at 13:05, <igh...@gmail.com> wrote:

Maybe i can rephrase the question in that way. If i have an easy way to detect the intervals in the time series that i do not want to monitor. Is it possible to extract only the requested ones, with the current prometheus query language or should i compute those events separately ? 

something like that

original time series : ***************++++++************

filtered time series :  ***************             ***********

That's probably possible somehow, but I think you might want to consider a different monitoring strategy for this.

Brian

 

To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-users+unsubscribe@googlegroups.com.
To post to this group, send email to prometheus-users@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-users/76027f28-0daa-468e-a4e8-64c50a415d3d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Brian Brazil

www.robustperception.io

[igh...@gmail.com]

thanks brian,

would you recommend using a particular labeling strategy ?

 

I mean : Is it possible to have a gauge time series that has some labels for a specific time interval, and another set of labels for another specific time interval ?

To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-users/76027f28-0daa-468e-a4e8-64c50a415d3d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Brian Brazil

www.robustperception.io

[Brian Brazil]

On 16 June 2017 at 14:26, <igh...@gmail.com> wrote:

thanks brian,

would you recommend using a particular labeling strategy ?

 

I mean : Is it possible to have a gauge time series that has some labels for a specific time interval, and another set of labels for another specific time interval ?

That doesn't make sense semantically, as those are two different time series due to having two different sets of labels.

What sort of service is this that you're trying to monitor?

Brian

 

To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-users+unsubscribe@googlegroups.com.
To post to this group, send email to prometheus-users@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-users/6e64ac05-1825-4023-8f7c-09e360ee654c%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Brian Brazil

www.robustperception.io

[igh...@gmail.com]

A finite time-span stream of events being repeated continuously. I am monitoring the latency. 

So basically what you are saying is that semantically, it would make sense to consider these finite streams as different time series. And so adding to each of them a kind if counter label.  

To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-users/6e64ac05-1825-4023-8f7c-09e360ee654c%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Brian Brazil

www.robustperception.io

[Brian Brazil]

On 16 June 2017 at 14:42, <igh...@gmail.com> wrote:

A finite time-span stream of events being repeated continuously. I am monitoring the latency. 

What sort of system is this that hourly spikes are okay, but other spikes aren't?

 

So basically what you are saying is that semantically, it would make sense to consider these finite streams as different time series. And so adding to each of them a kind if counter label.  

No, it's one time series.

Brian

 

To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-users+unsubscribe@googlegroups.com.
To post to this group, send email to prometheus-users@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-users/75b6853c-0838-440d-bf46-8e0c3f955697%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Brian Brazil

www.robustperception.io

[igh...@gmail.com]

On Friday, 16 June 2017 15:49:17 UTC+2, Brian Brazil wrote:

On 16 June 2017 at 14:42, <igh...@gmail.com> wrote:

A finite time-span stream of events being repeated continuously. I am monitoring the latency. 

What sort of system is this that hourly spikes are okay, but other spikes aren't?

well if you stream now the state your system had in the past, during a certain period of time, let's say 50 min, and that you loop it continuously let's say every hour.You end up observing "non linearities" as you go back in the past every hour.

  

 

So basically what you are saying is that semantically, it would make sense to consider these finite streams as different time series. And so adding to each of them a kind if counter label.  

No, it's one time series.

OK.This makes sense

 

Brian

 

To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-users/75b6853c-0838-440d-bf46-8e0c3f955697%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Brian Brazil

www.robustperception.io

[Ben Kochie]

For monitoring the latency of a stream of events, you should use one of two counter metrhods:

A pair of counters that counts the number of events, and the total time for those events.  This allows you to take the rate(time) / rate(count) to get the average latency.

Or

Use a histogram that allows you to bucket the events.  This will give you much more useful data.

To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-users+unsubscribe@googlegroups.com.
To post to this group, send email to prometheus-users@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-users/75b6853c-0838-440d-bf46-8e0c3f955697%40googlegroups.com.