Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

utcc.utoronto.ca

Post reply on HN
Print view View original

21–30 of 100 posts

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

#21

Post by number101010 »

dpkirchner wrote: post #5
ciguy wrote: post #3

Loki is open source. OP should take some of that frustrated energy and create a PR to improve the docs. I don't think this is a matter of Grafana Inc not wanting people to run Loki themselves but rather a resource constraints issue.

Unfortunately, Grafana discourages contributions from the community, even for its documentation.

I work on Grafana Tempo and this is not at all how I see things. I'm sorry if you've had a bad experience, but we work quite hard to field questions, PRs, and suggestions.

Every day I wake up and spend at least an hour reading and responding to issues and PRs in the Tempo repo.

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

#22

Post by isodude »

dpkirchner wrote: post #5
ciguy wrote: post #3

Loki is open source. OP should take some of that frustrated energy and create a PR to improve the docs. I don't think this is a matter of Grafana Inc not wanting people to run Loki themselves but rather a resource constraints issue.

Unfortunately, Grafana discourages contributions from the community, even for its documentation.

Not sure what you mean. Grafana as in the dashboard do seem to not accept patches in some sense, I think it's related to their enterprise offering. Loki was quite the breeze to send patches to. Thanks chaudum!

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

#24

Post by danwee »

Spivak wrote: 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?

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

#26

Post by jerrygenser »

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 binaries are more toys to say hello world or maybe test things in local development.

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

#27

Post by r3trohack3r »

dpkirchner wrote: post #13
gganley wrote: post #7

Earlier quoted context omitted.

Not that I don't believe that's entirely possible, but do you have a link to something demonstrating this behavior? A _very_ cursory google search didn't come up with anything immediately. Like this article might just be for show but its the first thing that came up ¯\_(ツ)_/¯ https://grafana.com/docs/grafana/latest/developers/contribut...

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 after accepting an external contribution?

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

#28

Post by detaro »

berkle4455 wrote: post #19

Grafana is a terribly ran company that once made a pretty decent OSS dashboard system. Stay away from them for anything but some charts.

And even the dashboard system kinda feels like there should be something better, but somehow there isn't (or I don't know it).

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

#29

Post by isodude »

Spivak wrote: 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 (…

I spent 2 days fixing a Graylog instance last week. When the elasticsearch nodes gets too big they tend be quite hard to work with. And of course you only log in when there's a problem and forgot everything about the setup in the meantime.
Post reply on HN