Syslog is the standard protocol and message format for recording and transmitting log events on Unix-like servers, network devices and many appliances. In monitoring and logs it provides a common way for the kernel, system services and applications to emit messages, each tagged with a facility that identifies the source and a severity that indicates urgency.
The term covers three related things: the message format defined in RFC 5424 and the older BSD format described in RFC 3164, the transport used to send messages across a network, and the local logging daemons, such as rsyslog and syslog-ng, that receive, filter, store and forward those messages.
How syslog messages are structured
Every syslog message begins with a priority value (PRI) in angle brackets. The PRI encodes facility and severity in one number calculated as facility multiplied by 8 plus severity. For example, a message from the mail facility (2) with severity error (3) carries PRI 19.
In the RFC 5424 format, the PRI is followed by a version number, a timestamp with time zone, the host name, the application name, a process ID, a message ID, optional structured data in key-value form and finally the free-text message. The older RFC 3164 style lacks a year and time zone in its timestamp, which causes ambiguity when collecting logs across regions.
The eight severity levels form a fixed scale used throughout syslog filtering and alerting, from the most urgent to the least.
| Code | Severity | Typical meaning |
|---|---|---|
| 0 | Emergency | System is unusable |
| 1 | Alert | Action must be taken immediately |
| 2 | Critical | Critical condition such as hardware failure |
| 3 | Error | Error condition in a component |
| 4 | Warning | Possible problem that may need attention |
| 5 | Notice | Normal but significant event |
| 6 | Informational | Routine operational message |
| 7 | Debug | Detailed diagnostic output |
Facilities and how filtering works
The facility identifies the kind of program that produced a message. Standard facilities include kern, user, mail, daemon, auth, syslog, cron and authpriv, plus local0 to local7, which are reserved for site-defined use such as application or network device logs.
| Facility | Code | Typical source |
|---|---|---|
| kern | 0 | Kernel messages |
| 2 | Mail transfer agents | |
| daemon | 3 | System services without their own facility |
| auth and authpriv | 4 and 10 | Logins, sudo, authentication events |
| cron | 9 | Scheduled job execution |
| local0 to local7 | 16 to 23 | Applications and network equipment |
Logging daemons apply selector rules that combine facility and minimum severity. A rule such as authpriv.* /var/log/secure writes all authentication messages to a protected file, while *.err might forward every error-level message to a central server. Severity filters are inclusive: selecting warning also captures error, critical, alert and emergency.
Syslog transport options
Syslog was originally sent over UDP port 514, which is simple but unreliable: messages can be lost without notice, and there is no encryption. Modern deployments increasingly use TCP or TLS for reliable and confidential delivery.
| Transport | Default port | Reliability | Security |
|---|---|---|---|
| UDP | 514 | No delivery guarantee | Plain text, spoofable source |
| TCP | 514 or 601 | Delivery while connected | Plain text |
| TLS over TCP | 6514 | Delivery while connected | Encrypted and authenticated |
| RELP | Commonly 2514 | Application-level acknowledgments | Can be combined with TLS |
Even TCP can lose messages if a sender’s buffer overflows during a long network outage. Daemons such as rsyslog therefore offer disk-assisted queues that store messages locally until the collector is reachable again, an important safeguard for audit and security logs.
Network equipment often supports only a subset of these options. Many switches, routers and older appliances can send only UDP syslog, so a common design places a local relay collector close to such devices. The relay accepts UDP on the trusted management network and forwards the messages over TLS to the central system, which limits the exposure of unencrypted traffic.
Syslog compared with related logging approaches
Syslog remains the common denominator for system and device logging, but it coexists with newer approaches. The comparison below places it among its closest neighbors in the logging stack.
| Technology | Role | Relationship to syslog |
|---|---|---|
| systemd journal | Local binary log store on Linux | Often forwards to a syslog daemon |
| Application log files | Logs written directly by programs | May bypass syslog entirely |
| Structured logging | Logs as JSON or key-value records | Can be carried inside syslog messages |
| Log aggregation platforms | Central search and retention, such as the ELK stack or Splunk | Commonly receive syslog as an input |
| SNMP traps | Event notifications from network devices | Parallel channel, different protocol |
In practice, a typical server sends messages to the local journal or syslog daemon, which writes local files such as /var/log/syslog or /var/log/messages and forwards selected events to a central log aggregation system for search, correlation and alerting.
Practical guidance and common pitfalls
Syslog is easy to enable but harder to operate well at scale. Most problems relate to lost messages, inconsistent timestamps and uncontrolled volume.
- Synchronize clocks with NTP on every sender, because correlating events across hosts depends on accurate timestamps.
- Prefer RFC 5424 with time zones or UTC timestamps for central collection.
- Use TLS for sensitive logs, especially authentication events that cross untrusted networks.
- Limit debug-level logging in production, since it can produce enormous volume and fill disks.
- Combine local storage with log rotation, so that local files remain available when the collector is down without exhausting disk space.
- Protect central logs from tampering, because attackers who gain access often try to erase their traces.
Message size is another pitfall. Many receivers truncate messages beyond a configured limit, commonly between 1 and 8 KB, so long stack traces or large structured records may arrive incomplete unless both sender and receiver are configured to accept larger messages.
In plain words
Syslog is a shared way for servers and network devices to write down what happens to them, such as logins, errors and restarts. Each note gets a label saying where it came from and how serious it is.
These notes can stay on the machine or be sent to one central collection point. Administrators can then search all their systems in one place when something goes wrong.
A real-world example
A university IT department manages two hundred Linux servers, forty switches and several firewalls. Every device sends syslog messages over TLS on port 6514 to a pair of central collectors, which use disk-assisted queues and forward the data to a log aggregation platform.
One morning, students report failed logins to the learning system. An administrator filters the central logs for the authpriv facility at warning level and above and finds thousands of failed attempts from one address range within minutes. The firewall team blocks the range, and because all clocks are synchronized, the security office reconstructs the complete timeline of the attack for its report.