As Developers, SRE, DevOps look to replace Elastic from their logging stack - we believe the log storage of future won't be another search and indexing engine in a new language.
Parseable leverages Apache Arrow, Parquet and widely available object storage platforms for efficiency, cost effectiveness and performance.
Aside - with so much to choose from wrt logs and metrics - I'd assume "prometheus for logs" implied "pulling" log data (rather than push). While maybe "Victoria metrics for logs" might imply "easier to operate, efficient, fewer moving parts".
I hadn't heard of qryn before, but it seems that the AGPL has become the go-to license of choice for these kind of tools. It makes me sad, but for clarity: it just makes me sad, the authors are entitled to use whatever license they want
I always find it confusing what I can and can't do with the entire GPL family of licenses, specifically when something is considered a "derivative" work or not. The AGPL network provision makes this an even bigger issue. It also introduces a whole new layer of uncertainty.
I also have seen a trend over the years of companies who adopt AGPL not caring about the open source community around the code. This is not specific to the AGPL, and not every user of it does so, but I see it correlating more often.
Many companies refuse to use AGPL licensed code... some claim their lawyers are stupid and don't know what they are doing... but it can still prevent adoption of AGPL licensed products.
So, it means that I don't get to use awesome looking toys at work because no one is going to pay the lawyer fees to find out what, exactly, we can and can't have those network requests touch
I have been trying to be much more careful in commentary about this because I'm not trying to change the author's license, it's their code, and I'm not trying to get into debates about "well, it only matters if ..." because IANAL and I don't want to assume the risk, because for this situation, being wrong would be very expensive, so I just stick to Apache or MIT tools
My comment wasn't a call to action, it was just crying out loud
As the author of qryn, I agree this is not perfect or ideal - but for lack of other options, we still consider AGPL better than BSL/SPL Licenses at protecting our community of real users. Any suggestion is absolutely welcome!
Well, a tiny bit because then I'd know the author had absolutely no interest in being a participant in the open source community and just wanted free labor. The AGPL license decision I believe is made in good faith, sharing the code as well as the rights to the community. The AGPL choice just means (from my perspective) that the code was _almost_ open enough that I could use it or maybe even contribute fixes for edge cases I run into, versus those "source available" where I can just immediately close the window -- or, I guess, pedantically, it means I can check back on the project in 5 years or whatever the "license change cliff" is nowadays
at qryn we're past the logs-only phase and currently we're concentrating on the polyglot aspects - we already support ingestion and querying of logs, metrics and telemetry using various inputs (loki, influx, elastic, etc) and supporting logql, promql and tempo for searching. Less moving parts, more power.
I really like the idea of storing logs in parquet format in S3. It's something I've wanted to play with for a long time, but never have had a use-case. I'm also a big fan of Rust.
As Developers, SRE, DevOps look to replace Elastic from their logging stack - we believe the log storage of future won't be another search and indexing engine in a new language.
Parseable leverages Apache Arrow, Parquet and widely available object storage platforms for efficiency, cost effectiveness and performance.