I’ve been using logwatch on my VMs for a long time. But it seems that every new OS release results in messier and messier output. That’s likely because applications get updated but the logwatch rules don’t.
A boot of a Rocky9 instance throws up a gazillion systemd “Unmatched” lines, for example
**Unmatched Entries**
Commit a transient machine-id on disk was skipped because of an unmet condition check (ConditionPathIsMountPoint=/etc/machine-id).: 2 Time(s)
Create System Users was skipped because no trigger condition checks were met.: 2 Time(s)
First Boot Complete was skipped because of an unmet condition check (ConditionFirstBoot=yes).: 2 Time(s)
First Boot Wizard was skipped because of an unmet condition check (ConditionFirstBoot=yes).: 2 Time(s)
Hostname set to <localhost>.: 1 Time(s)
Kernel Module supporting RPCSEC_GSS was skipped because of an unmet condition check (ConditionPathExists=/etc/krb5.keytab).: 1 Time(s)
Load CPU microcode update was skipped because of an unmet condition check (ConditionPathExists=/sys/devices/system/cpu/microcode/reload).: 1 Time(s)
...
(and lots more)
On a regular (non-reboot) day there might be lots of entries like Mark boot as successful after the user session has run 2 minutes was skipped because of an unmet condition check (ConditionUser=!@system)
This all adds noise to the output and makes it hard to determine if there’s anything I really need to look at.
Is there anything that does similar to logwatch but is better maintained? Or should I give up?
I’ve had similar thoughts as I keep seeing more and more “normal condition” messages that were reported by logwatch instead of being filtered. I did a little digging and found some maintainer information on git hub. Here’s a link to the github repository: GitHub - TheApacheCats/logwatch: git clone of the sourceforge files. I start writing perl code in about 1993 so thinking about seeing what sort of help they need. Feel free to also check.
Don’t know of any actual replacements for logwatch. Seems like a lot of organizations just go with something like splunk and dump all of their log files into a database that they look at when something goes wrong. I prefer the proactive approach of reporting anomalies like logwatch tries to do.
I don’t know of a replacement. You probably could create a filter to remove the “unmet condition checks” from the log output. /usr/share/doc/logwatch has some documents that outline how you would go about setting up filters.
Whilst logwatch is probably handy for the odd machine or two, when you have a load of servers to monitor it would be difficult to keep up with loads of emails coming in.
I tend to use Graylog a log, which is great for reporting and sending alerts, for example if you configure it to find certain SSH logs and then make some dashboards from it or send emails when someone attempts and fails to connect over ssh, etc. Or if interested in security alerts, then Wazuh will do a lot of stuff without you having to configure anything manually.
Graylog can require a lot of work for filtering certain logs, to create dashboards or alerts. I use it to get logs from my Fortigate firewalls as well, so comes in handy for that since logs generally on a firewall device itself are somewhat short-lived, so then I’ve got them for historical purposes.