Live data from Hacker News

InfluxDB 1.0 GA Released: A Retrospective and What’s Next

influxdata.com

31–40 of 83 posts

Re: InfluxDB 1.0 GA Released: A Retrospective and What’s Next

#31
post #30

> We had been grappling with what we should do for most of August 2013 and had another idea that I planned to debut at Monitorama in Berlin in late September. The conference was all about monitoring and I thought it would be a good place to find a receptive audience for a new monitoring product. What was it?

It was going to be called Anomalous. The idea behind it was that it would be an agent that gets deployed everywhere in your infrastructure that has collection, time series storage (either in memory, on-disk or both), alerting, and a basic web UI.

The agents would all call to a central service, which would have bidirectional communication. The central service would then act as a distributed alerting/query aggregator. So you could hit that and query a specific agent, aggregate across multiple ones, etc.

Kind of like a fully distributed time series, monitoring, and anomaly detection platform.

I still like the idea, but we didn't have the runway or resources to go down that path. Open source got us much more traction, combined with the fact that I personally like to work on OSS projects :)

Re: InfluxDB 1.0 GA Released: A Retrospective and What’s Next

#32
post #22

Earlier quoted context omitted.

We added log parsing to Telegraf a month or so ago. See here for more details: https://github.com/influxdata/telegraf/tree/master/plugins/i...

I'm wondering if Telegraf is a legit replacement for logstash or fluentd for shipping logs. I couldn't find this info from docs, so do you know if: - it supports multi-line logs (e.g. java stack traces) - it can output to elasticsearch (didn't see an output plugin) - there's any solution for reading docker logs (looks like docker metrics are supported) - any other critical logstash functionality missing? If it doesn'…

> - it supports multi-line logs (e.g. java stack traces)

unfortunately it doesn't, there hasn't been a request for it yet but please feel free to open an issue on the repo with any details you can bring: https://github.com/influxdata/telegraf/issues

> - it can output to elasticsearch (didn't see an output plugin)

Nope, not yet: https://github.com/influxdata/telegraf/issues/782

> - there's any solution for reading docker logs (looks like docker metrics are supported)

If there is a logstash "grok" pattern for parsing docker logs, then telegraf supports it. Though it's probably worth formulating a grok pattern specifically for telegraf that properly takes advantage of tags, fields, measurements, etc.

> - any other critical logstash functionality missing?

Need more user feedback to tackle this one, but feel free to open an issue with anything that you find is missing :) https://github.com/influxdata/telegraf/issues

Re: InfluxDB 1.0 GA Released: A Retrospective and What’s Next

#33
post #24

While talking about InfluxDB people should not forget about their beta release of clustering to attract more users and then making it just enterprise. And no, it's not an argument that this is the only way to get paid in open source. Users should be careful while adopting InfluxDB as Influxdata does not clearly elaborate their plans on the product.

Yeah, that's kinda a dick move. I was waiting for 1.0 before giving it another real go (after their decision to rewrite everything for 0.9). Looks like I'll be checking out something else now, maybe Prometheus[1] or DalmatinerDB[2] will fit the bill.

1. https://prometheus.io/ 2. https://dalmatiner.io/

Re: InfluxDB 1.0 GA Released: A Retrospective and What’s Next

#34
post #24

While talking about InfluxDB people should not forget about their beta release of clustering to attract more users and then making it just enterprise. And no, it's not an argument that this is the only way to get paid in open source. Users should be careful while adopting InfluxDB as Influxdata does not clearly elaborate their plans on the product.

Yeah, that's kinda a dick move. I was waiting for 1.0 before giving it another real go (after their decision to rewrite everything for 0.9). Looks like I'll be checking out something else now, maybe Prometheus[1] or DalmatinerDB[2] will fit the bill. 1. https://prometheus.io/ 2. https://dalmatiner.io/

It's worth noting that Prometheus isn't distributed either. So OSS InfluxDB or that are the same in terms of distributed capabilities.

Re: InfluxDB 1.0 GA Released: A Retrospective and What’s Next

#35
post #20

I've been using InfluxDB for almost a year now. At one point around 9 months ago I had given up on it because it was a bit crashy, and the database just was growing too fast. But the promise behind it was too compelling and I started experimenting with newer versions around 6 months ago and it has been just great! Much easier to deal with than Graphite/collectd/carbon, telegraf has not been eating our servers like co…

We updated the SNMP plugin a few weeks ago. Was thanks to a contributor who has been super helpful. Does the updated one do what you need?

Please pay the guy. He is helping your product.

Re: InfluxDB 1.0 GA Released: A Retrospective and What’s Next

#36
post #13

Earlier quoted context omitted.

I answered my own question because your original comment left no clue as to why you're so upset. Neither does this one that I'm now responding to.

Agreed, them providing .debs is far from "packaging being a mess". I'm quite happy that they provided .debs, worked with them to make some changes to the debs via pull-requests, and after that have been super happy with the packaging. I grab and import their packages into my own private repo for historic reasons, but it does mean I have to chase upstream changes. Personally, I think this is a straw-man argument. With…

> Agreed, them providing .debs is far from "packaging being a mess". I'm quite happy that they provided .debs, worked with them to make some changes to the debs via pull-requests, and after that have been super happy with the packaging.

Clearly you haven't checked how they build their DEBs and RPMs. Some opaque, overcomplicated script that eventually calls fpm instead of proper debianization or spec file for RPM. This results, among the others, in some configs not being marked as configs.

> I grab and import their packages into my own private repo for historic reasons, but it does mean I have to chase upstream changes. Personally, I think this is a straw-man argument.

It's not. You can't rebuild a server if you suddenly don't have access to packages this server has installed, especially if you need them to be in specific versions. BTDT, several times.

Re: InfluxDB 1.0 GA Released: A Retrospective and What’s Next

#37
post #32

Earlier quoted context omitted.

I'm wondering if Telegraf is a legit replacement for logstash or fluentd for shipping logs. I couldn't find this info from docs, so do you know if: - it supports multi-line logs (e.g. java stack traces) - it can output to elasticsearch (didn't see an output plugin) - there's any solution for reading docker logs (looks like docker metrics are supported) - any other critical logstash functionality missing? If it doesn'…

> - it supports multi-line logs (e.g. java stack traces) unfortunately it doesn't, there hasn't been a request for it yet but please feel free to open an issue on the repo with any details you can bring: https://github.com/influxdata/telegraf/issues > - it can output to elasticsearch (didn't see an output plugin) Nope, not yet: https://github.com/influxdata/telegraf/issues/782 > - there's any solution for reading doc…

Thanks for this great response. To give more color on my use case, my goal is to ship logs off the server and to some central log aggregation platform. That could be self-managed (e.g. Elasticsearch) or hosted (e.g. SumoLogic, Loggly).

In many cases, I'd want to get those logs from Docker containers and include metadata on each container so I know, e.g. what app is running, the container Id, on what host, etc.

Traditionally, tools like logstash, fluentd, and heka meet these needs.

It doesn't sounds like Telegraf is quite ready to support this use case in full, but could certainly head in that direction.

Re: InfluxDB 1.0 GA Released: A Retrospective and What’s Next

#38
post #27
post #26

Earlier quoted context omitted.

We're working on a re-envisioned Chronograf. The goal is to have something that's complementary to Grafana. Most of our users love Grafana and that's good. The next version of Chronograf, coming later this year, will be a re-envisioned and fully open source version. It won’t be about dashboards, it’ll be about an out of the box user experience for monitoring containers, Kubernetes, and Docker Swarm. We're actually lo…

Until you'll decide to make some of the features just for enterprise, as you did with InfluxDB?

Just exploring this for devops at work. This comment makes me a little worried. Is there a risk that some features will go 'enterprise only' in future?

Re: InfluxDB 1.0 GA Released: A Retrospective and What’s Next

#39
post #20

Earlier quoted context omitted.

We updated the SNMP plugin a few weeks ago. Was thanks to a contributor who has been super helpful. Does the updated one do what you need?

Please pay the guy. He is helping your product.

So, super obvious, but thought I'd just mention that influxdb is open source. It's likely that free version helped the contributor with his issue so he contributed back.

Re: InfluxDB 1.0 GA Released: A Retrospective and What’s Next

#40
post #27

Earlier quoted context omitted.

Until you'll decide to make some of the features just for enterprise, as you did with InfluxDB?

Just exploring this for devops at work. This comment makes me a little worried. Is there a risk that some features will go 'enterprise only' in future?

Our enterprise offering is for HA and scale out clusters of InfluxDB.

InfluxDB single server, Telegraf, Kapacitor single server, and soon Chronograf are all open source.

We'll continue to heavily develop our open source projects in addition to developing closed source software that we can license to customers. Basically, to be able to continue open source development, we need to have paying customers.

Post reply on HN