4 ms·

This looks really cool, but I'm always instinctively turned off by the pull model. - Assuming metrics are stored in memory, they'll be lost if the app or serve

This looks really cool, but I'm always instinctively turned off by the pull model. - Assuming metrics are stored in memory, they'll be lost if the app or server recycles. Of course, a push model should probably batch so there's probably some kind of overlap here. - I've heard pull is good for detecting if a server is down. The flip side is no automatic discovery and dynamic scaling where a server going down might not necessarily be a bad thing. - Security. Not super thrilled with exposing something that says "Hey come get my data".

bbrazil 11y ago
> - Assuming metrics are stored in memory, they'll be lost if the app or server recycles. Similarly if the server dies before sending the metrics, so that's a draw. > The flip side is no automatic discovery and dynamic scaling where a server going down might not necessarily be a bad thing. That's more about top-down vs. bottom-up target discovery than the scraping itself, see http://www.boxever.com/push-vs-pull-for-monitoring http://www.boxever.com/push-vs-pull-for-monitoring As of Prometheus 0.14.0 which was released earlier in the week, Prometheus supports target discovery. http://prometheus.io/blog/2015/06/01/advanced-service-discovery/ http://prometheus.io/blog/2015/06/01/advanced-service-discov... > Security. Not super thrilled with exposing something that says "Hey come get my data". That's a fair concern, though I'd expect your metric endpoint not to be internet accessible (and some of the push options will have a HTTP endpoint for debugging).