Hacker News Reader

Comment by devupio | Hacker News Reader

Introducing Parseable, simple, efficient, cloud native log storage and query system.

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.

View on HN

How does it compare with loki/qryn("née cloki/clickhouse loki)?

https://grafana.com/oss/loki/

https://github.com/metrico/qryn

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

As someone with an AGPL sticker on my laptop - why does that make you sad?

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.

What the sibling commenter said, plus even Google with their army of lawyers is all "nope" (https://opensource.google/documentation/reference/using/agpl...), and every small company I've worked for (who don't have an army of lawyers) also forbids it

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

Would you prefer the commons clause, or SSPL, or the business source license?

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

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!

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.

I imagine you've seen apenwarr's blog post on logging: https://apenwarr.ca/log/20190216

With that in mind I'd like to read more about the architecture. Specifically:

1. Do you have separate components for ingest and querying that can be scaled independently?

2. How dumb is the log ingest path?

Are you using S3 Select[1]?

[1]: https://aws.amazon.com/blogs/aws/s3-glacier-select/

logged into https://demo.parseable.io/index.html with parseable/parseable as username/password... no data is showing for frontend/k6test feed

Apologies, can you try the `frontend` stream and change the duration to last 7 days or so.

results! thanks

Reply on news.ycombinator.com