If you have to choose one of push or pull in your core, which should it be?
Reliable Insights
A blog on monitoring, scale and operational Sanity
Continuing in our exploration of the ongoing epic saga of push vs. pull where the very future of humanity is at stake, let's look at two general classes of push that are often conflated.
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.
The Prometheus client library guidelines recommend having a Child be returned via labels(). Why?
Another not uncommon question we get about Prometheus is as to why we don't have a single per-machine agent that handles all the collection, and instead have one exporter per application. Doesn't that make it harder to manage?
When designing a monitoring system and the datastore that goes with it, it can be tempting to go straight for a clustered highly consistent approach. But is that the best approach?
It's a frequently asked question as to how to do various security related features with Prometheus. Let's take a deeper look at why we chose the approach we did.
A not uncommon question about Prometheus is why the Alertmanager is a separate binary. Let's look at that.
Just after you've launched is not the best time to find out that you can't handle the load you predicted, or that running costs are much higher than you'd like. By estimating the operational parameters of your system as you design you can gain confidence that the system will work as you expect.
