3 ms·

InfluxDB CEO here. Happy to answer questions about InfluxDB or Telegraf

by pauldix 11y ago

SEJeff 11y ago
Was sad you didn't make it to Monitorama :) I saw your badge on the registration table
- pauldix 11y ago
  Yeah, had to speak at another conference. Going to block it off for next year though!
zalmoxes 11y ago
I've been waiting a long time for 9.0 and am overall very excited about InfluxDB and Telegraf. However I just discovered prometheus.io which looks like a very compelling solution. Now I'm evaluating both. What is your opinion on Prometheus and more importantly on push vs pull models for metric aggregation?
- pauldix 11y ago
  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.
- Rapzid 11y ago
  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.
gnyman 11y ago
do you have any ideas on the lifetime of 0.9 (and 1.0 if it'll be a drop in replacement)?
- pauldix 11y ago
  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.

InfluxDB CEO here. Happy to answer questions about InfluxDB or Telegraf

by pauldix 11y ago

InfluxDB CEO here. Happy to answer questions about InfluxDB or Telegraf

SEJeff 11y ago

Was sad you didn't make it to Monitorama :) I saw your badge on the registration table

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

zalmoxes 11y ago

I've been waiting a long time for 9.0 and am overall very excited about InfluxDB and Telegraf. However I just discovered prometheus.io which looks like a very compelling solution. Now I'm evaluating both. What is your opinion on Prometheus and more importantly on push vs pull models for metric aggregation?

pauldix 11y ago
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.
Rapzid 11y ago
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.

gnyman 11y ago

do you have any ideas on the lifetime of 0.9 (and 1.0 if it'll be a drop in replacement)?

pauldix 11y ago
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.