The Prometheus instrumentation best practices say to "Avoid missing metrics". Let's look at why, and how to deal with it.
Reliable Insights
A blog on monitoring, scale and operational Sanity
Prometheus is architected for reliability of alerting, how do you set it up?
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.
Have you ever wondered how many CPU seconds it takes to probe an instance via TCP or HTTP 100, 1,000, or 10,000 times?
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.
