Syslog Protocol Explained: Facilities, Severity Levels, and Linux Log Routing

Learn how Linux syslog works, including facilities, severity levels, selectors, local files, remote UDP/TCP/TLS forwarding, rsyslog configuration, and troubleshooting.

Syslog is a standard logging mechanism and an ecosystem of formats, transports, and daemons. Applications, services, and the operating system create event messages; a local client or logging daemon receives and routes them; destinations store or forward the records.

Logs may describe normal operational status, warnings, errors, authentication and authorization activity, or detailed diagnostic output. Centralized, timestamped records help administrators monitor systems, troubleshoot failures, investigate incidents, and meet retention or compliance requirements.

How syslog works

A typical Linux logging path uses a client-server model:

1. An application, kernel component, or service creates a message.
2. A syslog library, client, or local daemon gives the message a facility and severity.
3. A syslog daemon filters the message using configuration rules.
4. The daemon writes it to a local destination, forwards it to another host, or does both.
5. A collector or syslog server receives remote messages and stores or routes them.

A sender or syslog client originates or forwards a message. A receiver accepts messages. A collector is a receiver that gathers records from multiple systems. A syslog daemon is the background service that receives, filters, forwards, and writes records. A log destination can be a file, terminal, journal, pipe, user, or remote host.

Common Linux implementations include rsyslog, syslog-ng, and systemd-journald. Older systems commonly called the service syslogd; modern systems often use rsyslogd or syslog-ng. Journald can collect messages independently and may forward them to a traditional syslog daemon.

Message structure and PRI

The priority, also called PRI, combines a facility and a severity:

PRI = facility number × 8 + severity number

A message commonly contains a timestamp, hostname, application or program tag, process ID when available, and message body. Implementations can add structured metadata, message identifiers, and transport information.

Traditional BSD-style syslog formatting is commonly associated with RFC 3164. RFC 5424 defines a more structured and standardized format with fields such as version, timestamp, hostname, app-name, procid, msgid, structured data, and message content. Exact output varies by daemon and configuration, so a displayed line is not always a complete representation of the protocol record.

<165>Oct 12 14:22:08 web01 sshd[4210]: Accepted publickey for sam

In this example, <165> is PRI, Oct 12 14:22:08 is the timestamp, web01 is the hostname, sshd is the application tag, [4210] is the process ID, and the remaining text is the message body.

Facilities: the message source category

A facility identifies the category or subsystem that produced a message. Facilities let administrators route mail, authentication, scheduled-job, and custom-application events to different files or collectors.

Numeric facility assignments from older standards can have reserved, historical, or implementation-dependent names. For custom software, local0 through local7 provide predictable categories without mixing application records into general operating-system logs.

Severity levels

Severity describes the urgency or importance of an event. Code 0 is the most severe and code 7 is the least severe.

Aliases such as panic, error, and warn are accepted by some implementations. Use the keyword spelling supported by the installed daemon.

Selectors, thresholds, and actions

A traditional syslog rule has a selector followed by an action:

facility.priority    action

For example, mail.info /var/log/mail.log routes matching mail messages to a file. Threshold matching is reversed from ordinary numeric comparison: mail.info includes info and every more severe level, from notice through emerg, but excludes debug.

Selectors can be combined, for example auth,authpriv.*. Negation and none syntax vary slightly by daemon, so consult the installed implementation's syntax. Rule order matters: later rules, exclusions, and processing-stop actions can change what is ultimately written or forwarded.

Local destinations and file storage

File-based routing commonly stores records under /var/log. Depending on distribution and configuration, examples include /var/log/syslog, /var/log/messages, /var/log/auth.log, /var/log/secure, and mail-specific files. File names are not guaranteed; journald integration and daemon configuration determine the actual destinations.

Other actions include writing to a terminal or console, notifying a named user, writing to all logged-in users, sending data to a pipe or program, and forwarding to a remote collector. File-based logs need log rotation: a retention process such as logrotate renames or compresses old files, removes records beyond the retention period, and creates a new file. Rotation prevents logs from consuming the filesystem.

Remote transport: UDP, TCP, and TLS

Traditional remote syslog commonly uses UDP port 514. UDP has low overhead but no connection, delivery guarantee, retransmission, or congestion control. Packets can be lost, reordered, filtered, or spoofed.

TCP port 514 is often used for connection-oriented syslog, but both sender and receiver must explicitly use TCP and the local environment must verify the chosen port. TCP improves delivery behavior but does not provide encryption by itself.

Syslog over TLS is commonly associated with TCP port 6514. TLS provides encrypted transport and can authenticate peers when certificates are configured correctly. TLS is a secured modern transport approach; classic UDP syslog is not encrypted merely because the message is called syslog.

Firewalls, NAT, DNS failures, routing problems, and packet loss can all affect remote logging. Permit only expected source networks and ports.

Security considerations

Classic syslog over UDP sends content in cleartext and does not reliably authenticate the sender. Risks include disclosure of credentials or personal data, forged messages, message loss, and tampering or confusion during incident investigation. Plain TCP adds delivery behavior but not confidentiality.

• Use TLS-enabled forwarding for sensitive or untrusted paths.
• Restrict listeners with firewalls and network segmentation.
• Use access controls and restrictive permissions on collectors and authentication logs.
• Separate authpriv from general logs because authentication and authorization records can contain sensitive account and access information.
• Protect stored logs against unauthorized modification and define retention appropriate to operational and compliance needs.

Linux configuration workflow

Identify the active logging service

systemctl status rsyslog
systemctl status syslog-ng
systemctl status systemd-journald

Only one traditional syslog daemon may be installed or active, and service names differ by distribution. Journald may run alongside rsyslog or syslog-ng.

Add and validate a local rsyslog rule

Create a dedicated file such as /etc/rsyslog.d/30-myapp.conf:

local0.notice    /var/log/myapp.log

This includes local0.notice and all more severe local0 messages, but not local0.debug. Validate before applying the change:

sudo rsyslogd -N1
sudo systemctl restart rsyslog
sudo systemctl status rsyslog

Then generate and confirm a uniquely tagged event:

logger -p local0.notice -t myapp-test "Application logging test"
journalctl -t myapp-test --since "5 minutes ago"
sudo grep 'Application logging test' /var/log/myapp.log
sudo tail -f /var/log/myapp.log

The message may appear in the journal, the flat file, or both. That depends on forwarding and routing configuration. If the file does not exist, inspect daemon status, destination permissions, filesystem space, and the active configuration.

Configure a centralized receiver

On the collector, create an rsyslog UDP listener such as /etc/rsyslog.d/10-udp-listener.conf:

module(load="imudp")
input(type="imudp" port="514")

For TCP, use a separate configuration such as /etc/rsyslog.d/11-tcp-listener.conf:

module(load="imtcp")
input(type="imtcp" port="514")

A receiver also needs a routing rule. For example, route messages from a particular facility to a collector file:

local0.*    /var/log/remote-local0.log

Restart or reload the receiver, confirm the service, and verify its sockets:

sudo rsyslogd -N1
sudo systemctl restart rsyslog
sudo systemctl status rsyslog
sudo ss -lunp | grep ':514'
sudo ss -ltnp | grep ':514'

Permit the selected protocol and trusted sender networks in the firewall. The exact firewall command depends on the platform; inspect the active policy rather than assuming the port is open:

sudo firewall-cmd --list-all
sudo ufw status verbose
sudo nft list ruleset

Do not enable an unrestricted public listener. For production use involving sensitive records, configure certificates, TLS input, peer validation, firewall restrictions, and protected destination permissions instead of treating plain TCP as secure.

Configure a sender

On the sending host, add a forwarding rule such as /etc/rsyslog.d/90-forwarding.conf:

*.* @logcollector.example.net:514
*.* @@logcollector.example.net:514

In traditional rsyslog shorthand, one at-sign means UDP and two at-signs mean TCP. These examples do not enable encryption. Production TLS forwarding requires explicit TLS configuration and certificates.

Validate and restart the sender, then generate a controlled test:

sudo rsyslogd -N1
sudo systemctl restart rsyslog
logger -p local0.notice -t sender-test "Centralized logging test"
sudo journalctl -t sender-test --since "5 minutes ago"
sudo tcpdump -ni any port 514

On the receiver, watch the expected file and capture traffic at the same time:

sudo tail -f /var/log/remote-local0.log
sudo journalctl -f
sudo tcpdump -ni any port 514
sudo ss -lunp
sudo ss -ltnp

If ss is unavailable, netstat -lunp and netstat -ltnp can show UDP and TCP listeners where the legacy tool is installed. A packet capture on the sender proves that traffic leaves the host; a capture on the receiver proves that traffic arrives, but neither alone proves that the daemon accepted or stored the message.

Verification and troubleshooting

Local message missing from a file

• Confirm the test facility and priority match the selector: logger -p local0.notice -t test "message".
• Run sudo rsyslogd -N1 or sudo syslog-ng --syntax-only for the installed daemon.
• Check systemctl status rsyslog, systemctl status syslog-ng, or relevant journal entries for daemon failures.
• Confirm the configuration file is in an included directory and that the daemon was reloaded or restarted.
• Search both stores: journalctl -t test --since "5 minutes ago" and the expected file.
• Check destination ownership, permissions, SELinux or other security policy, filesystem space, and whether the daemon can create the file.

Info messages missing but errors appear

A rule such as mail.warning excludes mail.notice and mail.info. Remember that lower numeric values are more severe. Review exact selectors, none exclusions, negation, rule order, and any processing-stop action.

Remote collector receives nothing

• Confirm that the receiver has the correct UDP or TCP input module and that ss shows the expected listening socket.
• Ensure sender and receiver use the same protocol, hostname or IP address, and port.
• Check DNS resolution, routing, NAT, host firewalls, network firewalls, and security policies.
• Use tcpdump -ni any port 514 on both sides. No sender packets indicates a sender or name-resolution problem; packets leaving but not arriving indicate a network or firewall problem; arriving packets without stored records indicate receiver configuration or permissions.
• For TLS, verify certificates, trust configuration, hostname validation, and the TLS listener port, commonly 6514.

Journal-versus-file storage

On systemd systems, journald may contain a record even when no flat-file rule writes it. Conversely, a syslog daemon may write a file while journal forwarding is disabled. Use journalctl -f, journalctl -t tag, and tail -f on the selected file to determine whether the event exists in one store or both. Check journald-to-syslog forwarding and application logging paths when results differ.

Duplicate messages

Duplicates can result from journald forwarding and a separate application path, overlapping rsyslog rules, multiple local actions, or a relay forwarding the same message more than once. Compare timestamps, tags, hostnames, process IDs, and message identifiers. Trace the path from application to local daemon, relay, and collector, then remove unintended forwarding or overlapping write rules. Some duplicate writes are intentional when both local retention and centralized collection are required.

Exam-relevant summary

• Facility identifies the source category; severity identifies urgency.
• PRI conceptually equals facility multiplied by 8 plus severity.
• Severity 0, emerg, is most severe; severity 7, debug, is least severe.
• mail.info includes info and all more severe mail messages, but not mail.debug.
• One rsyslog @ commonly means UDP forwarding; @@ commonly means TCP forwarding.
• TCP alone is not encryption; use TLS for confidentiality and stronger peer authentication.
• Always verify daemon status, syntax, listener sockets, firewall policy, packet flow, and destination storage separately.