pauldix

26 ms·

211.
InfluxDB 1.2 released: subqueries, 50% better throughput on larger hardware(influxdata.com)
5 points by pauldix 10y ago|0 comments
212.
InfluxData Is Looking for an SRE in SF. We're a Go and CoreOS Shop(boards.greenhouse.io)
1 points by pauldix 10y ago
213.
InfluxDB is hiring a director of engineering, golang, DB expert (remote U.S.)(boards.greenhouse.io)
1 points by pauldix 10y ago
214.
by pauldix 10y ago
1 N 4th. The one that got built in front of the Edge. Moved in right after they opened up. Was in 184 Kent before that.
215.
by pauldix 10y ago
Agree, NYC. There's no better place to be. Unfortunately, SF/SV keep pulling me back in so I spend almost half my time there. I'm in Williamsburg on the waterfront too :) https://www.dropbox.com/s/j6fyj1i
216.
InfluxDB is hiring remote Go programmers with strong CS backgrounds(boards.greenhouse.io)
1 points by pauldix 10y ago
217.
by pauldix 10y ago
This is a great paper. On InfluxDB we used a similar compression technique for float64s in our new storage engine. A key difference we have is that we separated timestamps from values so we can use run length encoding for regular time serie
218.
by pauldix 10y ago
This section in our (InfluxDB's) doc on the evolution of our storage engine highlights some of the issues: https://docs.influxdata.com/influxdb/v1.1/concepts/storage_e...
219.
InfluxDB is hiring remote database and distributed systems engineers(boards.greenhouse.io)
1 points by pauldix 10y ago
220.
by pauldix 10y ago
This resonates with me. I've definitely been discouraged over years of OSS work by people that are rude or expect free labor. However, I try to remind myself that these are the vocal minority. There are many people that are positive an
221.
by pauldix 10y ago
That should be getting changed to have a dismiss x on the upper right. TBH I thought it had been done already. Overly aggressive marketing department...
222.
by pauldix 10y ago
The admin UI functionality is getting moved over to Chronograf, which is now open source. We do have commercial stuff, but trying to make money off our UI was never a strategy.
223.
by pauldix 10y ago
Before we actually remove the admin interface, we'll have a modern version of it in the now OSS Chronograf. Basically moving that functionality to there so we can iterate on the UI separately from the DB.
224.
Chronograf: a UI for the TICK stack, a complete open source monitoring solution(influxdata.com)
6 points by pauldix 10y ago|0 comments
225.
Kubernetes monitoring and auto scaling with Telegraf and Kapacitor(influxdata.com)
8 points by pauldix 10y ago|0 comments
226.
by pauldix 10y ago
In our system it actually doesn't matter if they have no legal teeth. If your former employer wants to spend money to take you to court to attempt to enforce a non-compete, you'll be forced to spend tens of thousands of dollars (i
227.
InfluxData closes $16M Series B led by Battery Ventures(techcrunch.com)
7 points by pauldix 10y ago|0 comments
228.
by pauldix 10y ago
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 add
229.
by pauldix 10y ago
It's worth noting that Prometheus isn't distributed either. So OSS InfluxDB or that are the same in terms of distributed capabilities.
230.
by pauldix 10y ago
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 w
231.
by pauldix 10y ago
Telegraf users are generally parsing the logs into structured metrics and events that go into InfluxDB. Not sure that it supports multi-line logs or docker logs. I'll have to look into it, but both should probably be done if they'
232.
by pauldix 10y ago
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-
233.
by pauldix 10y ago
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...
234.
by pauldix 10y ago
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?
235.
by pauldix 10y ago
Yep, we're very focused on solving the cardinality problem now. See these for some details about how we're thinking about it: https://github.com/influxdata/influxdb/pull/7175 https://gith
236.
by pauldix 10y ago
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.
237.
by pauldix 10y ago
Thanks, Philip! You helped us get here :)
238.
by pauldix 10y ago
We're working on the cardinality problem. Will be resolved in an upcoming release. Moving the index over to a disk based format that will hopefully still be fast and not sacrifice lookup performance.
239.
by pauldix 10y ago
Or maybe you were sad because you only saw package downloads from S3 and you were looking for an actual Debian repository? Well, that actually already exists. See: https://docs.influxdata.com/influxdb/v1.0/introduc
240.
by pauldix 10y ago
Maybe, but we get asked all the time about Cassandra vs. us. Both in terms of feature set and performance. And performance only makes sense for our potential users if we're trying to replicate the features on Cassandra.

More ›