dimonomid

Hey mcint, fyi both of these issues are addressed: the localhost one is addressed for real, and a Match issue is worked around: while it's still not properly implemented, at least it doesn't prevent Nerdlog from starting now. Just in case you wanted to give it another try.

Cheers.

Yeah, I agree. Gonna try and get it done on some weekend.

Thanks for trying it out, and for all the suggestions, very helpful!

Thanks for sharing! Good to know that nerdlog turns out to be helpful not only for devs (the original use case), but also for DevOps :)

Fyi, support for journalctl was added to master, in case you wanted to try it out. I didn't yet add automated tests with the mocked journalctl, but my manual tests show that it's working fine.

If a system doesn't have either `/var/log/messages` or `/var/log/syslog`, nerdlog will now resort to `journalctl` by default.

It can also be selected explicitly by specifying `journalctl` as the file, e.g. `myserver.com:22:journalctl`.

I see, interesting. If you don't mind me asking, is it a sysadmin kind of job? Just trying to understand the use case better.

Regardless, journalctl support is the single most requested feature, so yeah I'll at least try to make that happen; hopefully on the upcoming weekend if I'm lucky.

Yeah well the 2-files limitation is mentioned in some other place; but I agree this section could be rephrased to make it more clear too.

I only had the blood circulation issues from compression during sleeping, and also had no idea until today that the nerve damage like that is possible. I wonder how could it be prevented, if it can.

I seriously hope I won't have to deal with it, but thanks for expanding on it and the treatment.

Wish you a speedy recovery!

Damn I'm sorry to hear that. I'll see if I can get void linux installed somewhere to test it.

Good luck with whatever you're going through!

Fyi I've done a simple benchmark today, and journalctl is indeed a lot slower than simply reading log files. In case you're interested: https://github.com/dimonomid/nerdlog/issues/7#issuecomment-2...

I don't think there's anything wrong with this format, it looks good. The most important thing for nerdlog is that all components of the timestamp must be at the fixed offsets from the beginning of each line. So I believe it can be implemented, I can look at it on the weekend. Feel free to create an issue on Github (I won't be able to test it for real, so would need your help with that)

Fyi I was going to create a Github issue for the journald support, but apparently someone else filed it first: https://github.com/dimonomid/nerdlog/issues/7

Just posting it in case you want to subscribe to it. Looks like it's a popular demand indeed, so I'll at least poke it and see what kind of performance we can get out of it.

Sorry to hear you're having issues. I'll try to reproduce and fix the issue with the Match.

Not sure if that "Thanks" for releasing early is sarcastic, but regardless, I appreciate the feedback.

That's good news that we have /var/log/socklog/everything/current, but I'm also trying to figure the format. Is it like this? (sourced from chatgpt)

2025-04-21 12:34:56 myhostname myservice: Something happened

If so, then yeah it's totally doable to make this format supported.

Re: config.yaml, yeah I thought of that, but in the long term I rather wanted it to be nerdlogrc.lua, so a Lua script which nerdlog executes on startup. Similar to vim (or rather, more like neovim in this case since it's Lua). Certainly having config.yaml is easier to implement, but in the longer term it may make things more confusing if we also introduce the Lua scripting.

Thanks, appreciate that!

Re: the date/time format, I was thinking about implementing support for an option like timefmt, so you'd be able to do :set timefmt=2006-01-02T15:04:05Z07:00 , but postponed for now.

That's not hard to implement, however to make it persistent requires implementing some config / scriptability, which is a whole other thing and requires more thought.

Re: runit, I never tested it, but after looking around briefly, it sounds like there is no unified log file, and not even unified log format? I mean it's possible to make it work, treating every log file as a separate logstream, but I've no idea what these logs look like and whether supporting the formats would be easy.

Thanks. And no, as of today, there's no way to define a group like that. Might be a viable idea though.

However, before we go there, I want to double check that we're on the same page: this `log_files` field specifies only files _in the same logstream_; meaning, these files need to have consecutive logs. So for example, it can be ["/var/log/syslog", "/var/log/syslog.1"], or it can be ["/var/log/auth.log", "/var/log/auth.log.1"], but it can NOT be something like ["/var/log/syslog", "/var/log/auth.log"].

I first responded before your edit about ssh and localhost, so: yeah, as briefly mentioned in the article, as of today there's no shortcut even for localhost. I was debating whether I should implement this feature before open sourcing it, but I had to draw the line somewhere (I have TONS of ideas what could be implemented), and since reading local logs isn't the primary focus of nerdlog, I decided to skip it for now.

But yes the bypass for localhost can definitely be implemented.

Yeah you're right, agree with both of your points.

The `go get` one should be easy to solve though, and my bad for not thinking of it before, thanks. I'll look into it.

Thanks for the feedback!

Yeah it would be great, and I do want to support it, especially if the demand is popular. In fact, even if you ungzip them manually, as of today nerdlog doesn't support more than 2 files in a logstream, which needs to be fixed first.

Specifically about supporting gzipped logs though, the UX I'm thinking about is like this: if the requested time range goes beyond the earliest available ungzipped file, then warn the user that we'll have to ungzip the next file (that warning can be turned off in options though, but by default I don't want to just ungzip it silently, because it can consume a signficant amount of disk space). So if the user agrees, nerdlog ungzips it and places somewhere under tmp. It'll never delete it manually though, relying on the regular OS means of cleaning up /tmp, and will keep using it as long as it's available.

Does it make sense?

Thanks, and yeah getting distro packages would be dope. Hopefully, some day.

Not really, at least not yet, because nerdlog's focus is very different than that of lnav. There is a section about it in the article as well.

In fact nerdlog doesn't even support anything like -f (realtime following) yet. The idea to implement it did cross my mind, but I never really needed it in practice, so I figured I'd spend my time on something else. Might do it some day if the demand is popular, but still, nerdlog in general is not about just reading a continuous stream of logs; it's rather about being able to query arbitrary time periods from remote logs, and being very fast at that.

Thanks for the feedback. I'll see what I can do. But for now, do you think the workaround of having to install rsyslog is not good enough?

Yeah right, my bad, and thanks for reminding me. Just added one (the BSD 2-clause).

That's true, as of today nerdlog doesn't use journalctl, and needs plain log files. There were a few reasons of that, primarily related to the sheer amount of logs that we were dealing with.

As mentioned in the article, my original use case was: having a fleet of hosts, each printing pretty sizeable amount of logs, e.g. having more than 1-2GB log file on every host on a single day was pretty common. My biggest problem with journalctl is that, during some intensive spikes of logs, it might drop logs; we were definitely observing this behavior that some messages are clearly missing from the journalctl output, but when we check the plain log files, the messages are there. I don't remember details now, but I've read about some kind of ratelimiting / buffer overflow going on there (and somehow the part which writes to the files enjoys not having these limits, or at least having more permissive limits). So that's the primary one; I definitely didn't want to deal with missing logs. Somehow, old school technology like plain log files keeps being more reliable.

Second, at least back then, journalctl was noticeably slower than simply using tail+head hacks to "select" the requested time range.

Third, having a dependency like journalctl it's just harder to test than plain log files.

Lastly, I wanted to be able to use any log files, not necessarily controlled by journalctl.

I think adding support for journalctl should be possible, but I still do have doubts on whether it's worth it. You mention that you don't want to store plaintext logs and using logrotate, but is it painful to simply install rsyslog? I think it takes care of all this without us having to worry about it.

'm a bit confused by this as I'm used to seeing the opposite complaint, that Rust packages are too small.

By "packages" here you're probably referring to the public crates on crates.io, right?

Indeed, those public crates are not big in general, but that's not the point of the article. The article is rather talking about large, multi-crate projects, organized as a Cargo workspace. I agree it could have been clearer in the article.

First of all, what are other examples of "Rust empowers the developer, Go protects the developer from themselves"? As article mentions, Rust as a language is actually must stricter than Go, C++ and many others, and Rust community likes to brag that by restricting what we can do in safe Rust, we end up with better software. And I agree with that. But when it comes to dependency management, Rust turns out to be surprisingly lax.

Also, in this case, Go doesn't exactly protect the developer from anything. One could create a single package with tons of files in them, and it'll keep working. But the way Go package system is designed, it just subtly suggests to the developer that it's not the right thing to do: having a package (i.e. directory) with 200+ files in it just feels wrong by default. One trait of a well-designed system is that it's difficult to abuse.

My math still can't show how this is true.

If we take a gross income of 20K BGN (which is not a bad income for a software engineer), then with dividends, net income will be roughly this:

  20000*0.9*0.95-710*(0.148+0.05+0.08) = 16902, which means taxes are 15.59%.

  20000*0.9-3000*(0.148+0.05+0.08) = 17166, which means taxes are 14.17%. It's lower than dividends, but still far from the 11.5% that you mentioned.

  50000*0.9-3000*(0.148+0.05+0.08) = 44166, so the taxes are around 11.67%.

I guess there can be some bonuses which aren't taxed, and this way one could reduce the tax, but paying large bonuses to myself smells too much to me since it's clearly done just to pay less taxes.

Thanks, I'll research more into that.

In the meantime, I clarified in the article that as long as a company is concerned, the article only focuses on the dividends option, and added the link to your comment.

So they literally don't take any tax for foreign income and don't require any social security payments? That's seriously awesome. Actually I specifically like it because, while I'm paying here those social security contributions for pension etc, I've no idea if I'm gonna be able to use them for the retirement, since I'm not a citizen, and not sure if I'm ever going to be one.

By paying those I'm helping other people though, which is not a bad thing I guess. But I'd definitely prefer this to be more of a donation and less of a tax.

Anyway, thanks again. You got me researching about Panama this evening.

While I def agree that those are not mutually exclusive and I considered paying myself a salary, but paying a salary still involves a bunch of extra taxes, which end up being more than the dividend's 5%. At least that's what I had from my accountant, but I'd be happy to know details of how to make the combination of salary+dividends to require less taxes than just dividends.

Thanks for that info!

Yeah taxes in Bulgaria are lower than the average, but not lowest for sure. Good to know about Panama.

What about social security though?