With the upcoming release of Prometheus 2.0 comes a new format for writing recording and alerting rules.
A blog on monitoring, scale and operational Sanity
With the upcoming release of Prometheus 2.0 comes a new format for writing recording and alerting rules.
As PromQL has evolved, there are some functions that should no longer be used.
While the irate()
function is useful for granular graphs, it is not suitable for alerting.
The Prometheus instrumentation best practices say to "Avoid missing metrics". Let's look at why, and how to deal with it.
You may have noticed that most PromQL functions and operators remove the metric name in their result. Let's look at why.
For day to day use, there's only a handful of PromQL patterns you need to know. Let's look at them.
Prometheus alerts use the same powerful PromQL expressions as queries and graphs. This can be used to produce sophisticated alerts.
Prometheus doesn't have an explicit boolean type or functionality. However there is a convention and enough power in PromQL to work with booleans.
There's so many monitoring systems out there these days that it's difficult to figure out what's actually different, and what just has a different name or falls under a different concept. Let's look at the Graphite, InfluxDB and Prometheus query languages and see how the same ideas are represented in each.
There's various ways Prometheus federation can be used. To ensure your monitoring is scalable and reliable, let's look at how to best use it.