I haven't really formulated an opinion on pull vs. push models for metrics. For us, we're aiming to be more than just a DevOps platform. Those kinds of metrics are just one of the use cases we're trying to hit, which means that pull won't work for us. In the case of sensor data, which we want to be useful for, they need to be able to push. They also need to be able to push things that are time delayed by potentially many hours due to spotty network connectivity.

I think that push also makes it easier if you're sending metrics from an application. That is, push makes more sense if you're talking about event driven metrics, vs. sampling metrics (like from your system).

However, overall I think Prometheus is a great project. I'm hoping that as we advance the storage engine in InfluxDB, it'll become a preferred method to store long term metrics from Prometheus.

Someone also submitted a PR to Telegraf that would make it respond to metric pull requests from Prometheus, which is something we're totally up for. We just need to figure out the right structure.

I HAVE formulated an opinion on this. Further to what pauldix said, a push infrastructure seems more the way to go from my own experiences both as a consumer and would-be implementer of metric pipelines. It's far easier to put a pull-to-push system in front of a push infrastructure than to bolt on a push gateway in front of a pull infrastructure.. It's actually very bizarre IMHO when comparing to how people utilize Kafka and other pipeline supporting services.. To me, the pull has been the Achilles heel of prometheus. I haven't looked at it recently but shortly after it came out the push gateway, which you would have thought was where you were to push stuff, was not suitable as an actual push gateway and rolling your own was recommended.

Yeah, had to speak at another conference. Going to block it off for next year though!

Our goal is to release a point release in the 0.9 line every 3 weeks for the next 3-5 months. Once we've reached a good level of stability and implemented some of the key features on our roadmap, we'll start the 1.0 release cycle.

The goal is that 1.0 won't make any breaking API changes from 0.9 and its release cycle will be 4-6 weeks after whatever the last 0.9 point release is.

Basically, 1.0 will simply be the marker that the 0.9 line has reached maturity and we're locking the API there for a longer portion of time. We're trying to avoid any breaking changes between 0.9 and 1.0.