41–50 of 83 posts
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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.
See the PromCon 2016 videos for latest news on this.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
We're happy to take PRs. Seems everyone has opinions on packaging and you know what it's like when everyone has opinions, right? :)
> Seems everyone has opinions on packaging and you know what it's like when everyone has opinions, right? :) Don't try to push this into opinion realm, because it's not, it's a standards realm. Your package doesn't stand lintian test, and it's not a doesn't-really-matter type of errors that there's no README or license file. You don't even put an initscript in packages in a proper way. It wouldn't matter that much, b…
Influx is absolutely amazing. We're using it along with grafana to store and display our desktop and web apps' analytics (it completely replaced GA), store and display HTTP health analytics (piping custom uwsgi request logger into UDP input), and do continuous analysis of Hearthstone games. It's incredibly fast and the grafana/influx/telegraf stack is really cool to play with. Highly recommended.
We evaluated InfluxDB 6 months ago and did not move forward because cluster mode was still in beta. Is there anyone running a cluster in production with some decent traffic?
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?
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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.
Influx is absolutely amazing. We're using it along with grafana to store and display our desktop and web apps' analytics (it completely replaced GA), store and display HTTP health analytics (piping custom uwsgi request logger into UDP input), and do continuous analysis of Hearthstone games. It's incredibly fast and the grafana/influx/telegraf stack is really cool to play with. Highly recommended.
Want to hear more about your HTTP analytics. Particularly interested in collecting selenium/sitespeed.io-style page timing metrics. There are a million commercial solutions for this but so few open source options.
uWSGI has a very flexible logging system. You can create a log with just requests, and completely customize the format of the line.
On top of that, uWSGI supports creating multiple log targets, and supports logging directly into a UDP socket.
If you make it match InfluxDB's line format (https://docs.influxdata.com/influxdb/v1.0/write_protocols/li...), and you set up InfluxDB to accept connections from a matching UDP socket, then uWSGI can essentially log every request directly into influx.
Like this for example:
logformat = uwsgirequest,host="%(host)",status=%(status) msecs=%(msecs),size=%(size) %(epoch)000000000
logger = file:/var/logs/uwsgi/uwsgi.log
req-logger = file:/var/logs/uwsgi/requests.log
req-logger = socket:127.0.0.1:8083
With that, you can create nice graphs with Grafana to analyze your loading times, error rates, page sizes etc:
https://i.imgur.com/fzbXgUd.png
You can also set up Kapacitor to identify when your page load times are abnormally increasing. We had the idea after a database connection leak increased our average loading times by 300%.
Do note that this doesn't batch inputs, so 1 request = 1 connection to influx. But it's pretty easy to put a middleware agent in between those to do validation and batching.
The nice thing about all this is it's application level timing metrics. There's not a lot of ways to get that, except with application middleware which can't always catch everything you want.
