Automated Log Forwarding Triggers

Synchronize system logs to remote endpoints based on custom systemd event triggers.

In this lesson, you will learn how to trigger the immediate synchronization of local system logs to a remote server using event-driven systemd units.

Why Triggered Forwarding?

While standard log shippers (like rsyslog or fluentd) typically run as persistent background daemons, there are scenarios where you want to conserve resources or ensure immediate offloading only when a specific, high-priority event occurs. By utilizing systemd.path units, we can "watch" specific log files or journal states and fire off a forwarding script exactly when new data is written.

The Trigger Architecture

To implement this, we decouple the detection from the transmission:

The Trigger (.path unit): Monitors the filesystem (e.g., /var/log/critical-alerts.log) for modifications.
The Action (.service unit): A transient service that executes a synchronization command, such as rsync or scp, to push the logs to your remote endpoint.

Consider a setup where you only forward logs when a specific security warning is generated:

# /etc/systemd/system/log-forwarder.path
[Path]
PathChanged=/var/log/security-alerts.log
Unit=log-forwarder.service

[Install]
WantedBy=multi-user.target

When security-alerts.log is updated, the path unit triggers log-forwarder.service. Your service unit then handles the heavy lifting:

# /etc/systemd/system/log-forwarder.service
[Service]
Type=oneshot
ExecStart=/usr/local/bin/sync-logs.sh

Implementing the Sync

Your sync-logs.sh script should be designed to be idempotent—meaning it can run multiple times without causing duplication or errors. Using tools like rsync with the --append or --partial flags is ideal here, as it ensures only the new fragments of the log file are transmitted to your remote storage, minimizing network overhead.

By using this trigger-based approach, your system remains quiet during idle periods, only consuming network bandwidth and CPU cycles at the precise moment that logs demand off-site backup. This effectively prevents the "noisy neighbor" syndrome in high-density environments where constant log streaming would otherwise impact performance.

Key Takeaway: Automated log forwarding is best managed by pairing systemd.path units to detect file activity with oneshot services that efficiently push delta changes to remote destinations.