I'm collecting Windows server events on an openSUSE Leap 16 syslog server running rsyslog. The events arrive through SolarWinds Event Log Forwarder for Windows.
I'd like rsyslog to create a directory for each Windows server, with separate files for categories such as Security, Windows System/Application events, and Active Directory events. At the moment, all messages from each server are filtered into one file, which makes searching and extracting useful information difficult.
I tried creating a dynamic file template that uses the hostname and a regular expression against the message to determine the event category, then routes messages containing "MSWinEventLog" to that file. The configuration passes rsyslog's syntax check, but it does not behave as expected: the messages end up in the generic warning log defined elsewhere in rsyslog.conf.
The configuration uses a dynamic path under /var/log/syslog/servers/, a filename based on the hostname and event data, and a separate template for formatting the log lines. What should I change to make the dynamic routing work, and are there common issues with the template properties, regex, permissions, or directory creation that I should check?
3 Answers
You can confirm the basic dynamic-file mechanism with a much smaller test. For example, create a template whose filename contains a date variable, then route messages from a known source to it with an explicit condition and stop processing afterward. Once that works, test hostname-based paths and only then add the event-category regex.
Also check the file creation mode, ownership, and whether the parent directories already exist or are allowed to be created by rsyslog. A syntax check only confirms that the configuration parses; it does not prove that the action can create the path or that the regular expression matches the actual incoming message.
Simplify the configuration first and add the pieces back one at a time. In particular, remove the $now property from the list template for now, since it is not being used as a normal message property, and temporarily stop extracting the event category with a regex. Get the dynamic path working with only the hostname first.
Likewise, keep the output template minimal—timestamp, hostname, and the message with control characters removed. Once that successfully writes files, add the event classification logic back in. If the regex still fails after that, check whether the incoming message actually has the format you expect. Also verify that rsyslog can create and write to the target directories; permissions or security policy restrictions can cause messages to fall through even when the syntax is valid.
A simpler and often more maintainable approach is to keep the forwarded Windows events in one main file, or at most one file per broad source type. Splitting by host and event category in filenames creates a lot of configuration and makes troubleshooting harder. The hostname, event source, and event ID are already present in the message, so grep, awk, or a log-analysis tool can filter them when needed.
If you need searching, dashboards, alerts, and structured fields regularly, that is usually a sign to use something such as Graylog, Loki, or ELK rather than continuing to build increasingly elaborate rsyslog filename logic.
After fighting with the configuration for most of the afternoon, I’m starting to agree. Keeping the setup simple may be the better choice here.
A reasonable middle ground is one file for all forwarded Windows events, or one file per broad source type. Once the setup starts acting like a small SIEM, it may be time to deploy a log-analysis system instead.
Thanks! The server is running openSUSE Leap 16, and I’ll test the simpler hostname-only version first before adding the event parsing back.