Vulcan: An API-compatible alternative to Prometheus
github.com
github.com
I think the push model is better in terms of security and discovery (which is how I think most of the other metric aggregators work).
I don't even like log scrapping. I just push the log data through kafka or rabbitmq and have something else pick it up.
I do like how Prometheus has a dimensional model instead of just raw timeseries.
Speaking of which I still haven't found an effective way of merging or correlating metric data with log data (particularly since it is two different systems).
I sort of made some experimental headway with Druid since it kind of has generic event and metric support. This was only possibly because the events are being pushed and not pulled (ie pushing to a bus allows for syndication).
I'd recommend listening to their recent CNCF online meetup [1] for some more of the background on push/pull and why they made the choices they did.
I guess it is architecture choice but honestly if our nodes can't push to the bus (because this bus is more than just metrics that can be dropped it is critical biz shit) it is a fatal state for us.
I think if you have a good enough bus like Kafka or RabbitMQ you can create a big enough buffer to prevent absolute chaos of overload (and now you just monitor queue size). If you see overload happening (ie massive queue) you can selectively drop messages (particularly with RabbitMQ as it has routing). But you are absolutely right that bad stuff can happen.
"I've told you once."
This is also closely related to one of my (well, our) wishlist items for any TS system. Quoting from the README.md:
> allows a scraper configured for a high-frequency 15s resolution
Above extract feels like a crystallisation of cognitive dissonance.
For us, and especially our engineers, 15 seconds for resolution is just barely acceptable. Our senior engineers would like a 2-second granularity for most metrics, and should generally accept 5 seconds as a reasonable compromise between storage requirements and data accuracy. (We have 10-15 seconds resolution now, and all too frequently find it annoyingly coarse.)
Interesting, I think the pull model is better at least in terms of discovery, and you need less configuration overall for a pull-based monitoring system, as now you need to only configure the monitoring system to know about your services, and the service instances don't need to know: a) who they are, b) where the monitoring system lives. In a push-based world, you need to configure both sides.
I expand on that a bit more in https://prometheus.io/blog/2016/07/23/pull-does-not-scale-or...
It is sort of nice to have dimensions for rollup/filtering instead of doing weird name mangling like graphite does. For example one might add a dimension of build # or release version to each metric.
Having a dimension like build # you could even effectively say if your releases are improving performance wise and graph it. TBH haven't done it yet but I think it would be useful instead of just manually doing it with time filtering.
You can also shove in multiple related metrics as part of the same measurement.
https://docs.influxdata.com/influxdb/v0.13/write_protocols/l...
Feels like another "We want our shed to be blue".
I haven't looked close enough, but hopefully they've done so in a way that common things (query functions, alertmanager integration, etc) can be kept in sync with upstream easily.