If you’ve determined a metric should be tested, how do you go about that?
Should you unit test every bit of instrumentation you add? Not always.
If you’ve an existing instrumentation library in use, it’s not always practical to immediately switch to a Prometheus instrumentation library. There are a multitude of integrations available to aid your transition.
After 1.6.0 back in April, Prometheus 1.7.0 is now out. Let’s look at what has changed.
When metrics come from another system they often don’t have labels. metric_relabel_configs offers one way around that.
You may have noticed that most PromQL functions and operators remove the metric name in their result. Let’s look at why.
It’s often claimed that an advantage of push-based monitoring systems is that, compared to pull-based systems like Prometheus, they don’t need service discovery. This isn’t true, and I’m going to explain why.
Prometheus client libraries don’t just export metrics in our format, they can parse that format too.
For day to day use, there’s only a handful of PromQL patterns you need to know. Let’s look at them.
Prometheus 1.6 includes a new experimental feature called remote read. Let’s look at what it can do.