Live data from Hacker News

I can't recommend serious use of an all-in-one local Grafana Loki setup

utcc.utoronto.ca

31–40 of 100 posts

Re: I can't recommend serious use of an all-in-one local Grafana Loki setup

#31

It seems Red Hat believes in Loki Red Hat logging product manager says: "We made the decision to move to Loki and Vector" https://www.youtube.com/watch?v=QZ4Hv85lEJ0&t=938s

not sure that's a ringing endorsement, given all the other things Red Hat believes in.

Re: I can't recommend serious use of an all-in-one local Grafana Loki setup

#32

Not loki but regarding tempo, I've had good experience with running the components in kubernetes using the operator. These components are typically build to be "cloud-native" which often means run on kubernetes. If you already run on kunernetes, grafana products are typically straightforward to run. In general I think that is the target customer and use case for out of grafana cloud deployments. The all in one binari…

Nice! RedHat built the Tempo operator and I have not had a chance to use it yet. We are looking to collaborate more closely on it soon.

Re: I can't recommend serious use of an all-in-one local Grafana Loki setup

#33

There's also Signoz ( https://signoz.io ) a YC-backed company but open source with (recently) paid hosted.

Looked interesting so I did what I try to do every time, checked the license.

Among other licenses I found this in one of the sub folders (/EE).

> This software and associated documentation files (the "Software") may only be used in production, if you (and any entity that you represent) have agreed to, and are in compliance with, the SigNoz Subscription Terms of Service, available via email (hello@signoz.io) (the "Enterprise Terms"), or other agreement governing the use of the Software, as agreed by you and SigNoz, and otherwise have a valid SigNoz Enterprise license for the correct number of user seats. [...]

I guess it is for enterprise edition or something but it was not immediately obvious to me what parts are under EE and which parts are under the MIT Expat license.

Re: I can't recommend serious use of an all-in-one local Grafana Loki setup

#37

Earlier quoted context omitted.

Grafana requires you to sign a CLA before they will accept any work, which can be really expensive (unless you have in-house lawyers or don't care about understanding the real ramifications of a contract): https://grafana.com/docs/grafana/latest/developers/cla/

This appears to be a 7 clause contract written in good faith to ensure Grafana Labs can continue building a product and service offering around their open source project after accepting your contribution. Am I missing something? Do you have any specific problems with the CLA? Is there an alternative option to a CLA that ensures the original copyright owner can continue offering the code base under multiple licenses a…

Perhaps my contributions are also made in good faith with full awareness that they are subject to the licenses?

We did OSS for decades without CLAs and most projects still do not require CLAs.

Re: I can't recommend serious use of an all-in-one local Grafana Loki setup

#38

It seems Red Hat believes in Loki Red Hat logging product manager says: "We made the decision to move to Loki and Vector" https://www.youtube.com/watch?v=QZ4Hv85lEJ0&t=938s

That doesn't mean much unless you're their customer. "Works well enough and we have people that know it" is perfectly fine way to pick a tool, even if it is not technically the best one.

Re: I can't recommend serious use of an all-in-one local Grafana Loki setup

#40
post #24
post #11

It really is amazing at just how bad the various log shipping systems are for the simple use case of "I have logs on some servers and I want them to be over here." We somehow peaked at rsyslog and have been struggling ever since. If you don't follow the one-true-architecture you will get bitten in a million ways. * Log ingestion on the host pulls logs from the application/system/whatever, timestamps the logs itself (…

> * Log ingestor ships the logs to a durable queue > * Log processor reads from the queue and ships the logs off to persistent storage Why do we need the durable queue in between? Why not let the Log Ingestor ship the logs off to persistent storage?

Something needs to buffer in case of network errors. Although you're right that having that as separate element is not very useful.

Queue is useful if you want to write those logs into multiple places at once

Post reply on HN