InfluxDB 0.9.1 and Telegraf 0.1.2 released

https://influxdb.com/blog/2015/07/02/InfluxDB-0_9_1-and-Telegraf-0_1_2-released-with-new-docs.html

by pauldix • 11 years ago

30 16 11 years ago

influxdb.com

pauldix7• 11 years ago

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

SEJeff• 11 years ago

Was sad you didn't make it to Monitorama :)

I saw your badge on the registration table

pauldix7• 11 years ago

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

zalmoxes• 11 years 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?

pauldix7• 11 years 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• 11 years 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• 11 years ago

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

pauldix7• 11 years 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.

sciurus• 11 years ago

"Some users logged issues about a large number of IOPS during heavy write loads. To address this we implemented a write ahead log, or WAL. No migration is required to take advantage of this feature and it is available as soon as you upgrade. It’s worth noting here that if you are testing a high write load scenario, you will get occasional pauses of up to 3 seconds during WAL flushes (depending on hardware and schema). Set your timeouts accordingly. We’ll work on smoothing this out over time in future 0.9 point releases."

This is a pretty major change and a big caveat!

joshpadnick• 11 years ago

I'd love it if you could comment on how InfluxDB + Telegraf + Grafana + $OpenSourceAlertingTool compares to commercial offerings like DataDog or SignalFx?

Also, is Telegraf meant to replace cAdvisor for InfluxDB users?

pauldix7• 11 years ago

DataDog is more of a fully featured application. We want to be a platform for people building custom monitoring, DevOps, and sensor data applications for their needs.

As for cAdvisor, my hope is that it gets updated to work with the new InfluxDB API

johngd• 11 years ago

Careful about installing Influxdb and Telegraf on the same system via RPM (maybe DEB too), they both share common paths and filenames, and cause one (or the other) not to start.

https://github.com/influxdb/telegraf/issues/22 https://github.com/influxdb/influxdb/issues/3123

Also, the changelog items for telegraf all point at influxdb issues.

https://github.com/influxdb/telegraf/blob/master/CHANGELOG.m...

I am really excited about telegraf, but am worried about long term maintenance of yet another stats collector. It is very easy to setup, and seems like it will be quiet easy to extend.

pauldix7• 11 years ago

We'll have to fix the issues of installing on two systems. For the issue linked to InfluxDB I assume it was for the client tags. The tagging issue in Telegraf was actually a problem with the InfluxDB client.

Anyway, we're committed to maintaining this and pushing it forward

crymer11• 11 years ago

The dual-installation issue the grandparent mentioned also exists for DEB, which is what prompted my PR. Any way you can help with https://github.com/influxdb/telegraf/pull/23? I really want to install InfluxDB and Telegraf on the same system, but I don't want to maintain a fork.

arunoda• 11 years ago

So, next two product will be

* One for Chart UIs * One for Alerts

Good Luck with the Tick Platform.

InfluxDB 0.9.1 and Telegraf 0.1.2 released

Related Stories