Brian Candler wrote: > > > I've noticed that if I take a larger resampling interval, like > > "foo[2d:1h]", I lose all my peaks. Which is kind of understandable now > > but the question "how to better find peaks" kind of remains. > > > (foo == N)[2d:15s] will find the peaks, with approximate timestamps within > 15 seconds of the actual time the data was sampled. > > If you want, you can then hit the API with additional queries > > foo[15s] @timestamp > > to get the raw metrics with exact timestamps (it will return the raw > timeseries between timestamp-15s and timestamp).
This "@" modifier seems quite useful. I had not had it enabled before this conversation with you. Now I'll be using it more often. Do you happen to know why it is disabled by default? > > But in many applications, you don't care about this. You're only sampling > the data every 15 seconds anyway, which means you'll miss the exact time > when the state of the thing you're sampling changed; in other words, the > timestamp will already have between 0 and 15 seconds of error. So adding > another 0-15 seconds of error is probably not a big deal. Thank you Brian, you've been able to help me achieve more clarity. The PromQL and the CloudWatch approaches to queries are difficult to get used to for a person who started graphing things with MRTG 20+ years ago. -- Victor Sudakov VAS4-RIPE http://vas.tomsk.ru/ 2:5005/49@fidonet -- 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/YdQmuuW/GqEUP6eO%40admin.sibptus.ru.
