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.
I think everything is in /var/log/socklog/everything/current, so this could be considered united.
Before you add the timefmt, it may be better to add a configuration file if one does not already exist, but it seems like it does? You already have ~/.config/nerdlog/logstreams.yaml, so might as well have config.yaml?
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.
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)
Thank you! :(. It is also referred to as wristdrop.
> If you sleep in a position that causes radial nerve compression, you may wake up experiencing numbness and tingling along the back of your arm, forearm, and hand. With more severe compression, you may also experience “wrist drop”. With wrist drop, your wrist becomes limp, and is unable to extend up.
This is what happened. It happened to me before 2 times, but this time it was only about 30 mins long compression so it is not THAT severe as it was the previous 2 times.
The reason I expanded on it is that just mere 30 minutes of sleeping on your arm may damage the nerves which results in radial nerve palsy. I would have never imagined it would happen to me, heck, I had no idea it was a thing. I had limp arms before from compression but that was related to only blood circulation, not nerve damage.
Radial nerve palsy is a nightmare for programmers. The first one was so severe that I lost my muscle memory, meaning I could not access some of my accounts.
Treatment is rest, selective electrical stimulation, and B1-B6-B12 combination, ideally injected IM. The faster the better. The first incident took months to recover, this one may only last 3 weeks.
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.
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"].
At the very grave risk of scope creep, I'll point out that the GP's yaml is very close to an Ansible inventory file so rather than just making up a new structure one could leverage any existing muscle memory (and create helpful defaults for folks who have not yet seen Ansible but have seen your tool)
That first "children" key is because in ansible's world one can have "vars" and "hosts" that exist at the very top, too; the top-level "vars" would propagate down to all hosts which one can view as "not necessary" in the GP's example, or "useful" if those files are always the same for every single host in the whole collection. Same-same for the "user:" but I wasn't trying to get bogged down in the DRY for this exercise
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.
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.
I appreciate this response, and want to say I really like your tool's UI over something like lazyjournal. But like the above commentor, I would love to see journald support as well, just because it's the default these days on the distros I use, and seems like the direction the Linux system industry has headed in.
I think it will impact first-time users giving nerdlog a quick test/trial run, and cause them to bounce to another tool when it doesn't show them logs from journald out of the box. Users can be finicky and impatient with new tools ;-)
Example: I'm running an Arch-based Linux desktop. Installing ryslog took several minutes to build and install. If I wasn't highly motivated to try out nerdlog, I would have canceled the install.
Also, can the SSH requirement for localhost be bypassed? Most users won't be running an SSH server on their desktop, and this would improve nerdlog's use-cases and make it easier for new users to give it a quick local test run.
Final suggestion: add `go get` support to your repo, so that I can install nerdlog from a single command and not have to clone the repo itself.
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, I'm bouncing for now on the localhost requirement. Or, on a related issue of not parsing my .ssh/config, a Match directive, and not wanting it to parse it yet. I grep'ed for an env var to override, but only USER and SSH_AUTH_SOCK are pulled in.
I did go get install ...nerdlog/cmd/nerdlog-tui@latest just fine.
Thanks for hacking in the open, and releasing early.
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.
I would say that their thanks is sincere, and that they're applauding you for releasing a new tool to a public/critical audience while also taking feedback in very constructive manner.
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.
I have no doubt that journald is slower, and I have no real preference for it. The request for journald support goes back to it being the default on most distros these days. I have to interact with a variety of different servers in different environments, most of which are not managed by myself, and hence I have to interact with was previously setup... which is usually the default config provided by the distro.
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.
My role is classified as DevOps consulting, working for several different companies, each with their own unique setup and teams... but yeah, it's basically glorified sysadmin work ;-). On the plus side though, I get to see the realities of internal company tech stacks, and that the default settings often are chosen over better solutions.
Thanks again for considering journald, and at the same time, don't forget that it's your project at the end of the day... you can always disregard feature requests if it's not a direction you want to head in. Though in this case, I do believe journald support would get your tool more traction with a larger audience in the long term.
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`.
Looking good so far! Now it just needs localhost-without-SSH enabled by default (so that as a new user I test out nerdlog immediately without having to think about which server to connect it to), and your initial onboarding/out-of-the-box experience will be ready for a very wide audience! :-)
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.
> '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.
No social security to speak of. Health care is excellent and reasonably priced, so not too big a deal. Set aside some savings and get some basic insurance / critical illness insurance. No pension either, so plan for your own retirement.
With what you save on taxes you can do that and take three months of awesome vacation a year anywhere you want and still save money over most countries.
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.
Yeah, it's pretty awesome. Panama has its problems too mind you, and one really should learn Spanish if you're going to live there.
But all of that seems small in comparison to the tax break that you get. You could spend the whole summer in Europe or North America if you wanted and it would be free, including food and entertainment, and you'd still have plenty left for a medical and retirement savings account for yourself.
