Live data from Hacker News

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

utcc.utoronto.ca

61–70 of 100 posts

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

#61

Quickwit is an open source Loki alternative too. Like said in one comment here, it works well on billions of logs on one modest instance. And Grafana integration is on the way :) https://github.com/quickwit-oss/quickwit (disclaimer: I'm one of the cofounders)

Care to give the Quickwit pitch? Especially on why it is better than Loki.

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

#62
post #46
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 (…

The whole stuff is so much worse than "old unix" architecture of "you give logger an address to push stuff, and it pushes stuff there". We have DNS, we don't need log sender to have a service discovery mechanism on top of that. Set it to log server address and be done, scale at that point if you need to, we know how to do it. Log processor doesn't need a fucking queue. Log sender does, for network reliability one. An…

Whenever I have to deal with logs, it's either:

a) simplicity of rsyslog

b) monstruosity of ELK | Grafana | etc.

Somehow I like Prometheus (I think it's "simple"), but it's not enough to display and search for logs. Somehow, none of the companies I have worked for, have used "simple tools" like rsyslog to handle logs. They all used cloud (Datadog, New relic) or self hosted (ELK, Prometheus + Grafana). I wonder why (I guess it's because "money buys you simplicity")

I just want the following:

- on each machine I want to get logs from: install the agent (a simple binary) + simple /etc/myagent.conf. The agent forwards logs to my "main log server"

- on my "main log server": install the "log processor" (again, just a binary please!) + simple /etc/mylogprocessor.conf. The "log processor" shows me a nice localhost:9090/ web interface in which I can search for logs (indexed by any field I want).

Easy, no? My use case is not thousands of machines nor Terabytes of data logs per second. I just have a few machines and I don't want to deal with multi-clustered solutions or anything like that. Just 2 binaries! Does that exist?

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

#63

Would a php script which fires up grep to sift through rsyslogd files be feasible as an alternative? I'm considering right now to implement this.

Syslog-ng has a feature where each line can be piped into a long running program (eg Perl) and parse/match each line as it arrives. Then pump matched lines to the necessary thing.

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

#64
I installed promtail a few weeks back and I ran into this bug, that had been outstanding for months: https://github.com/grafana/loki/issues/8663 (e.g. a fix had been written but had not been released):

Due to a buffering issue, Loki would exit in case of configuration error without printing any error message or anything at all.

There is definitely something weird about how the project is run.

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

#65

Parseable is an open source Loki alternative. - Single binary - Written in Rust (lightweight, fast and stable) - Use S3 bucket or Mount point - Visualize with Grafana https://github.com/parseablehq/parseable (founder here)

Can Parseable be sharded, or can you just run a single instance?

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

#66

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

Vector is wonderful, and while I have no experience with Loki, if it's as bad as this post and thread suggest, perhaps Vector makes it more manageable by normalising and buffering everything coming into it.

For example, another comment here talks about Loki locking up Docker if it's the logging backend and the container crashes. I suspect that wouldn't be possible, or would be less likely and more manageable with Vector in the middle because it will buffer. I've also dealt with normalising logs from different sources and it can be a pain, but Vector will do some or all of that already, reducing the requirements put on Loki.

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

#67
I don't like being negative and I always appreciate open source / free software but..

I tried using it in a small k8s cluster on digital ocean. Initial installation using the recommended helm package was easy enough. However, it only saved a very short period of log data. I spent a fair amount of time searching docs and the web about how to increase the storage, with no luck. Such an obvious and common need should not be so difficult to configure. You should not have to deep dive, reverse engineer, and read source code in order to solve such simple problems.

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

#68
I’ve always viewed all in one mode for Loki as a demo or very small install version. It’s meant to be run in its component architecture as a scaling ingestion and query engine.

That said: 1) I feel like Loki is languishing and not reaching its full potential. User experience needs a lot of work.

2) Grafana is a for profit company

3) Grafana sees its future in the margin rich Saas offering

4) open source is still supported, but only to a certain point and the rest is commercial. I wouldn’t expect material support if you’re not paying for it.

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

#69

> An attempt to upgrade our Loki 2.7.4 to 2.8.1 failed badly and could not be reverted, forcing us to delete our entire accumulated log data for the second time in a few months (after the first time). This sucks, but it’s also why you take filesystem snapshots or perform a backup before upgrades.

And then you lose logs since the bad upgrade instead of until the bad upgrade. Definitely not better.

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

#70
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 (…

Here is a question, I mean it honestly, I'm relatively old school and have built many apps using syslog. When it comes to doing log mining, I've got a fairly old school utility belt, I poke around with less, I cat through grep (really ripgrep), I cat through grep and pipe to awk and extract things. Sometimes I fire up cut. I get a ton of milage from sort and uniq. Obviously, I fire up zcat in place of cat when needed. I also generously apply find when needed. It feels like I find what I need pretty quickly. Admittedly, I generally don't have terabytes of logs with these tools but it handles 10s of GB shockingly well.

With Splunk, ELK, Greylog, it feels insanely pokey. I know they have the parsers and such. At times I've kind of boned up on their search syntax but I've never gone "all in" with any of them, maybe because they all don't seem like a really solid long term solution. They seems to have a different kind of model than what I want, the time range is kind of nice but often times I won't have a time range until later. My model involves winnowing down the the data I want and then extracting pieces and viewing the data different ways. Am I just using all these tools the wrong way? Is my mental model off? Maybe it's a log consistency thing, it's always sort of a great day when you get "Error: abc failed because xyz and def." and that's the answer to everything. Many times I'll be spending time looking at logs and I'll notice an increase in a certain behavior happened before the outage happened and that's the give away.. Then a new grafana dashboard is created with a new metric to try and identify that before it happens again.

Loki kind of looks like it supports my method but again, I'm back to that "I haven't gone all in" with it problem. As I'm rambling, I've seen these sexy dashboards with like red/yellow/green lights and some latency graphs and cool looking stuff and then a little table of the last 20 "log messages" and maybe I'm used to looking at logs that you don't show in your dashboard or something like that.

They all feel like a square hole to my round peg. Maybe it's just me.

Post reply on HN