When system messages come from several Linux hosts, a collector can provide one place to search them. Syslog describes a message format and a way for software to send system events to a logging service.
This article explains what syslog means and walks through configuring rsyslog to send a test message to a receiver.
TL;DR
Run rsyslog on a receiver with a network input, then configure each sender to forward to that receiver using the same protocol and port.
- Use a dedicated ruleset and file for remote messages so they are distinct.
- Validate both configurations with rsyslogd -N1 before restarting the service.
- For a network that is not fully trusted, use TLS and restrict the receiver firewall to approved senders.
What Is Syslog in Linux?
Syslog describes a message format and a way for software to send system events to a logging service. On Linux, rsyslog often reads local messages, applies rules and writes or forwards them.
For remote logging, configure the collector before pointing senders at it.
On systemd systems, inspect journal entries with journalctl. A missing text file alone does not show that logging has stopped.
A missing file alone does not show that logging has stopped. The grep command can search a file after you identify its destination.
Syslog messages commonly carry facility and severity fields alongside a timestamp, host and message text. Those fields help administrators interpret and filter records.
A remote collector provides one place to search across hosts, while a sender’s local journal remains available during network outages.
The receiver example below defines its own destination for incoming messages.
How to Set Up Remote Syslog Step by Step
Configure and test the receiver before pointing senders at it. This example uses rsyslog RainerScript and TCP on port 514. Substitute the receiver’s reachable DNS name or address, and adapt service and firewall commands to your distribution.
The steps configure the collector first, then the sender, and finally verify that a test record reaches its destination.
Log Generation, Reception and Analysis
On a systemd machine, services may write to the journal, while applications using the syslog interface send records to the local logging daemon. Check whether the service’s records reach that daemon before expecting them at the collector.
A service that writes only to journald may need a local forwarding path configured for the daemon to receive its records.
The input assigns each received record to a ruleset that selects its output action, allowing remote traffic to use a distinct retention policy. This keeps the receiver’s network input tied to the intended destination.
Search the known collector destination for a unique marker, then compare a match’s host, timestamp, facility and severity with the sender’s expected event.
Rsyslog actions can write to files or forward records onward. Read the active configuration rather than relying on a filename from another distribution.
When a marker is found, compare its host name and timestamp with the sender that produced it. Then check whether the expected facility or severity appears in the selected output. This confirms that filtering has not discarded the event before storage.
For recurring analysis, keep the search expression specific and avoid placing credentials or personal data in test messages. A short retention window for test events can prevent diagnostic markers from being mistaken for operational alerts later.
Table of Contents
- What syslog means and where local messages come from.
- How to configure a receiver, sender and test message.
- How to diagnose transport, routing and storage failures.
Use the following steps to configure a collector and sender, then trace any missing test message through the route.
Step 1: Confirm rsyslog is available
Check whether the daemon and its service are present on both machines. Minimal images may omit rsyslog, so consult the distribution package manager if the executable is missing.
rsyslogd -v
systemctl status rsyslog
The status command only inspects the service. If rsyslog is absent, follow your distribution’s current installation instructions because package names and defaults differ. Package installation and service enablement change system state.
Step 2: Configure the receiver
Put site-specific rules in a separate file under /etc/rsyslog.d/ when the distribution includes that directory. A dedicated ruleset sends network input to its own output, apart from the receiver’s local rules.
# /etc/rsyslog.d/10-remote.conf
module(load="imtcp")
ruleset(name="remote") {
action(type="omfile" file="/var/log/remote.log")
}
input(type="imtcp" port="514" ruleset="remote")
This sample receives plain TCP messages and writes them to one file. A host-specific template can split logs into per-sender files, but use a sanitizing template and confirm filesystem permissions before creating paths from network-supplied fields. Create or select a destination that the rsyslog service can write to.
Rsyslog documents the following command as a configuration syntax check. It does not test DNS, firewall access or remote delivery.
sudo rsyslogd -N1
The receiver setup and the validation command are documented by the rsyslog remote-server tutorial. Restart rsyslog after validation using your system’s service manager, then check its status and listener. These commands change service state and are shown as instructions, not as actions performed here.
sudo systemctl restart rsyslog
systemctl status rsyslog
ss -ltn
Step 3: Allow only the required network traffic
Permit inbound TCP port 514 only from known sender addresses for this example. Keep the plain-text listener off the public internet, and remember that a UDP rule will not allow TCP.
Choose the firewall tool already managed on the host, such as UFW or firewalld. Check cloud security groups and network ACLs too.
The firewalld guide covers firewall-cmd concepts. Keep a plain-text listener off the public internet.
Step 4: Forward messages from a sender
On each sender, add a forwarding action that targets the receiver and matches its TCP port. Use a separate numbered configuration file so the forwarding rule is straightforward to audit and remove.
# /etc/rsyslog.d/20-forward.conf
action(
type="omfwd"
target="logs.example.net"
port="514"
protocol="tcp"
queue.type="linkedList"
)
Replace logs.example.net with the receiver name or IP address. The linked-list action queue can buffer messages while the receiver is unavailable. Plan its capacity for outage duration and message rate.
This action forwards messages that reach it. To limit forwarding to selected facilities or severities, add a filter before the action and confirm its match semantics in the rsyslog documentation.
Validate the sender configuration with rsyslogd -N1, then restart the service after reviewing the result. The rsyslog forwarding guide documents TCP forwarding, queues and a logger-based test.
sudo rsyslogd -N1
sudo systemctl restart rsyslog
Step 5: Send a test and verify it at the receiver
Send a unique test message from the sender with the logger utility, then search the receiver’s selected output for that exact text. This verifies more than a listening socket because it exercises forwarding, transport, input routing and file output.
logger -t remote-check "syslog test from sender"
sudo grep -F "syslog test from sender" /var/log/remote.log
The commands are documented steps for an end-to-end test. Use a unique marker that contains no secrets, then remove or expire it according to your retention policy. Confirm the marker appears in the receiver’s configured destination before treating the route as ready.
Remote Syslog Errors and Security Limits
Transport, firewall and routing mismatches can prevent a message from reaching storage. The configuration check recorded earlier printed “rsyslogd: version 8.2312.0, config validation run (level 1), master config /etc/rsyslog.conf” and “rsyslogd: End of config validation run. Bye.”
I passed an invalid option to logger and got “logger: unrecognized option ‘--definitely-invalid-option’” and “Try ‘logger --help’ for more information.” Check the utility help and correct the option before sending a test message.
| Symptom | Likely check | Next action |
|---|---|---|
| No message arrives | Target name, matching protocol and port, listener and network firewall | Resolve the target, inspect the receiver socket, and verify each network policy allows the configured protocol. |
| Validation fails | Syntax, module name, duplicate module load or missing parameter | Read the reported file and line, correct it, then check the configuration before restart. |
| Message reaches the host but not the file | Input ruleset, output action and destination permissions | Trace the receiver input’s assigned ruleset and confirm the daemon can write to the file. |
| Messages stop during an outage | Sender queue state and available queue capacity | Inspect rsyslog status and queue configuration. size durable buffering for expected outage duration. |
UDP has low connection overhead but no transport acknowledgement, while TCP is ordered but a successful write does not prove durable storage. Sender queues buffer outages and RELP adds acknowledgement semantics when supported by both ends.
For untrusted networks, configure rsyslog TLS with certificate validation and verify the peer identity. RFC 5425 sets TCP port 6514 as the default, and the rsyslog TLS tutorial explains certificate configuration.
A receiver is a data collection point, so restrict access, protect stored logs and set rotation and retention rules. Avoid building output paths directly from untrusted hostnames or message fields. If a sender uses a different syslog implementation, check its protocol framing and TLS behavior rather than assuming every product’s TCP mode inter-operates.
When a message is missing, check in order that the sender is active, its target resolves, the receiver listens on the matching protocol and port, and host and network firewalls allow traffic. If packets reach the receiver but the file stays empty, inspect its ruleset, output action and write permissions.
Conclusion
Remote syslog works when the receiver’s input, sender’s forwarding action, network policy and output destination agree. Keep remote messages in a deliberate ruleset, validate configuration before restarting, and prove the route with a test marker seen at the receiver.
For deeper configuration details, start with the rsyslog remote server tutorial, omfwd reference and RFC 5425. Use a TLS deployment when the network is not trusted, and plan queue capacity and log retention for your workload.
FAQ
These answers address common questions about Linux syslog setup and checks.
How do I check whether rsyslog is running?
Use systemctl status rsyslog to inspect the service. Check its listener separately with ss because an active service may not accept remote connections.
How do I check an rsyslog configuration?
Run rsyslogd -N1 before restarting the service. Validation checks syntax and configuration loading, not end-to-end network delivery.
Which port does remote syslog use?
Port 514 is commonly used for UDP or plain TCP examples. Syslog over TLS uses TCP port 6514 by default under RFC 5425. Configure the same transport and port on both ends.
Where are syslog messages stored in Linux?
The location depends on the distribution and rsyslog rules. Check the active rules and destination. systemd journal entries can also be read with journalctl.