111–119 of 119 posts
Earlier quoted context omitted.
Yeah, a Vector dev that is now at Datadog told me that Vector is essentially deprecated.
I'm using Vector for my own infrastructure and at work, at the time it seemed the best option to ship logs to various destinations. Are there any alternatives?
I hate Datadog. We use their name as an epithet at our company for how not to sell/market. Their selling tactics circa 2015-2018 completely burned us out. Endless calls and emails. The icing on the cake was an AWS reInvent presentation on Lambda right when lambda was first announced. We were pumped to get in on lambda early. Got the whole crew to attend the talk. Turned out to be a rudimentary copy of a Barr "lambda…
There are multiple possible outcomes from the merge with Datadog. As my ex manager once told - there is no such thing as nice people in P&L statement. Someone has to pay It's very easy to be anxious and see the path to the dark side here. However one of possible outcomes - there will be a valid open source competitor to Grafana ecosystems, and this along secure the rest of scene from relicensing. There is a chance it…
You may want to check out SigNoz [1] - takes a all in one app approach compared to different modules for each signal approach which Grafana takes
Disclaimer : I am one of the maintainers
Sqreen was a great product for startups. Unfortunately acquired by the Datadog. Product was never fully integrated into their offerings and there is no such alternative.
Hey I'm an engineer who worked at Sqreen and now Datadog. What kind of feature is still missing in Datadog ASM? To my knowledge everything is there except managing CSP and security headers now.
Earlier quoted context omitted.
I suggest giving SigNoz a try. Built on top of Clickhouse, it’s fast and scalable https://github.com/SigNoz/signoz PS: I am maintainer at SigNoz
what another open source you can recommend ?
I was going to take advantage of Clickhouse using S3 as warm-to-cold storage since my mental model is that most logs, metrics, and traces are written and not read https://clickhouse.com/docs/en/integrations/s3#configuring-s...
I believe one could do that with SigNoz, too, so I don't mean to imply that trickery was qryn specific, just that I didn't want to get into the "constantly resizing io3 PVC" game
Earlier quoted context omitted.
I suggest giving SigNoz a try. Built on top of Clickhouse, it’s fast and scalable https://github.com/SigNoz/signoz PS: I am maintainer at SigNoz
what another open source you can recommend ?
Earlier quoted context omitted.
what another open source you can recommend ?
I'm not the person you asked -- and I also want to be transparent that I only PoC-ed it and due to external circumstances didn't get it all the way out to production -- but I really like how https://github.com/metrico/qryn (AGPLv3) thinks about the world. It is, like SigNoz, unified (logs, metrics, traces) but it actually implements several of the common endpoint schemes allowing it to pretend to be "your favorite to…
Earlier quoted context omitted.
Hey I'm an engineer who worked at Sqreen and now Datadog. What kind of feature is still missing in Datadog ASM? To my knowledge everything is there except managing CSP and security headers now.
Few months ago when I’ve tried it there was no full support for ruby language.
We just moved from Elastic to Quickwit. Sigh. What other open source, object storage backed logging databases do people recommend?
We just moved from Elastic to Quickwit. Sigh. What other open source, object storage backed logging databases do people recommend?
Loki by Grafana Labs is nice ( https://grafana.com/oss/loki/ ). There was a time (3+ years ago) where the product was changing pretty rapidly and much of the documentation was on git, so we had a few headaches doing minor version bumps, but I believe its much more mature now.
- It is non-trivial to setup and operate. It requires properly configuring and orchestrating numerous components - distributor, ingestor, querier, query frontend, compactor, consul, ruler, memcache, index service, etc. - see https://grafana.com/docs/loki/latest/get-started/architectur...
- Its' configs tend to break with every new release, since some configs become obsolete and some configs change names and/or structure.
- It is very slow on "needle in the haystack" queries such as "search for logs containing some rarely seen trace_id", since it needs to read, unpack and scan all the logs at object storage. This may be also very expensive if the object storage service charges for read IO.
- It doesn't support log fields with big number of unique values (aka high-cardinality log fields). It you'll try storing logs with high-cardinality fields into Loki, then it will quickly explode with enormous RAM usage. Recent Loki releases provide half-baked solution for this problem - "structured metadata" ( https://grafana.com/docs/loki/latest/get-started/labels/stru... ), but it is still experimental and requires non-trivial configs (aka it doesn't work).