What's the story regarding high availability for InfluxDB 2.0? I know it is a commercial offering in the current release, and while I'm not super thrilled about that, I do think it's reasonable. It would be nice if you could buy the self-hosted version with a "contact sales" step which I honestly will never do. (I would just put a proxy in front of the multiple instances that tries to write to as many of them as possible and does reads from one at random. What could go wrong!)
The other thing I never figured out in the current version is how to write the following query. I store samples like (device, network, direction) -> packet count. I then want to know how many packets were sent across the network in total.
With monitoring systems I've used in the past (internal to my former employer), this was easy. You would do the delta calculation at the lowest level to convert device packet counters to number of packets sent in the last time interval, which varies randomly because samples are not necessarily arriving at discrete intervals. Then you would do an align, to bring the randomly-added sampling times into alignment across all the "streams" (which is a unique (device, network, direction)). Once the data is aligned, you can then do a group by to get rid of a certain tag, like device (and just have (network, direction) -> total packets sent in the time interval).
With InfluxDB, I can't figure out how to do this. It has the group by time concept, but not alignment, so I can't write a query that will work. I ended up just computing the deltas before inserting the item, at which point everything works fine.
I have not tried the same query with Prometheus, but I suspect it would work like I expect, as it seems very heavily inspired by a certain internal monitoring system I am most familiar with.
This release of 2.0 is not a commercial offering. It's completely free and open source under an MIT license without restrictions of any kind. For example, you could use it as the basis of your own commercial offering or use code from it and that is all fair game.
For the query you mention, you can do that in 1.x using a combination of group by time, fill and subqueries. In 2.0 you can do this in Flux using similar operators. More complex possibilities for interpolating missing data is also in the works.
Solving more complex query processing like what you mention is a specific reason why we started developing Flux. We couldn't figure how to address some of the more advanced query feature requests in the old language so we started with something new.
In addition to giving Flux more functions, flow control and more power, we also will be adding more out of the box functions and syntactic sugar to make some of these more advanced queries possible without being overly verbose and complex. Our order of operations for developing the language:
1. Make it powerful
2. Make it easy
3. Make it fast
So it'll take us time to get to all of our goals, but I think we've laid down a pretty good foundation.
The other thing I never figured out in the current version is how to write the following query. I store samples like (device, network, direction) -> packet count. I then want to know how many packets were sent across the network in total.
With monitoring systems I've used in the past (internal to my former employer), this was easy. You would do the delta calculation at the lowest level to convert device packet counters to number of packets sent in the last time interval, which varies randomly because samples are not necessarily arriving at discrete intervals. Then you would do an align, to bring the randomly-added sampling times into alignment across all the "streams" (which is a unique (device, network, direction)). Once the data is aligned, you can then do a group by to get rid of a certain tag, like device (and just have (network, direction) -> total packets sent in the time interval).
With InfluxDB, I can't figure out how to do this. It has the group by time concept, but not alignment, so I can't write a query that will work. I ended up just computing the deltas before inserting the item, at which point everything works fine.
I have not tried the same query with Prometheus, but I suspect it would work like I expect, as it seems very heavily inspired by a certain internal monitoring system I am most familiar with.