3 ms·
I don't quite get the benefit of pull model by default either. A pull model by default means that it's not easy for a library to publish its metrics. For instan
by hintymad 4y ago
I don't quite get the benefit of pull model by default either. A pull model by default means that it's not easy for a library to publish its metrics. For instance, every god damn application is expected to implement a `/metrics` endpoint for a freaking agent to publish the application's metrics to Prometheus. With Monarch, any library or application can simply publish metrics to Monarch's API. Similarly in Netflix, publishing to its Altas system is totally transparent to library authors, with the help of their metric library.
Sometimes I feel many open source systems do not give a shit about productivity.
- dan-robertson 4y agoThe general theory is that if a push-based system is getting overloaded you drop metric submissions but if a pull-based system is overloaded it will query less frequently and you’ll just get less resolution.
- hintymad 4y agoThanks. It's a valid thought on such trade-off. I do think we can still favor productivity without losing resolution, though, for the following two reasons: 1. A pull-based system can pull less when the system is overload, which means a pulled service needs to keep historical stats. For instance, the endpoint `/metric` needs to keep previous gauge values or the accumulated counters. That said, a push-based metric library can keep history too. Indeed, it is exactly what the micrometers library does. 2. Don't let the metric system overload. This sounds like a hyperbole, but it is what companies do in practice: telemetry system is so foundational and critical to an internet company that it should always run smoothly.