What Is Syslog?

Last verified on Nov 8, 2026.

Syslog is a standard message format and protocol for sending system and application logs from a device to a collector. Linux daemons, network equipment, and firewalls commonly emit it. Every syslog message carries a priority number that encodes where it came from and how severe it is, followed by a header and the message text.

RFC 3164 and RFC 5424

Syslog grew up as a Berkeley Software Distribution practice. RFC 3164 wrote down what implementations did, and it states plainly that it is informational and does not specify an Internet standard. It sends over UDP port 514, caps the packet at 1024 bytes, and writes the time as Mmm dd hh:mm:ss, without a year or time zone.

RFC 5424 replaced it. It is a Standards Track document that obsoletes RFC 3164, defines the format independent of transport, and adds structure.

<34>1 2003-10-11T22:14:15.003Z mymachine.example.com su - ID47 - 'su root' failed for lonvick on /dev/pts/8

The - is the nil value. When present, structured data looks like [exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"].

Facility and Severity

The PRI value is the facility number times 8, plus the severity. The example <34> is 4 * 8 + 2: facility 4 (security/authorization messages) and severity 2 (Critical). A local4 (facility 20) message at Notice (5) gives <165>.

RFC 5424 lists facilities 0 to 23. The commonly seen ones are 0 kernel, 1 user-level, 2 mail, 3 system daemons, 4 security/authorization, and 16 to 23 for local use 0 to 7. The eight severities run 0 Emergency, 1 Alert, 2 Critical, 3 Error, 4 Warning, 5 Notice, 6 Informational, and 7 Debug. A lower number means higher practical severity. See log levels for how these map to other scales.

Decoding a priority is a divide and a remainder:

pri = 34
facility, severity = divmod(pri, 8)
print(facility, severity)  # 4 2

Transport and Security

RFC 5424 separates the message format from how it travels. Implementations must support the TLS transport defined in RFC 5425, and should also support UDP per RFC 5426. Receivers must accept messages of at least 480 octets and should accept 2048.

NIST SP 800-92 is blunt about older deployments. Most syslog implementations use UDP, which gives no assurance that entries arrive or arrive in order. Most do no access control, so any host can send, and attackers can flood a server with bogus entries. Most cannot encrypt, so messages can be read or altered in transit. OWASP recommends the syslog message format over TLS for integration with central logging. NIST also notes that message content has no standard fields, which is why log parsing is needed.

Working with Syslog

• On systemd hosts, the journal carries a syslog-compatible priority, and OpenTelemetry's mapping turns it into a severity. See journalctl.
• The OpenTelemetry Collector's syslog receiver parses syslog over TCP or UDP, with protocol set to rfc3164 or rfc5424.
• Forward to a central tier with log forwarding and combine sources with log aggregation.
• Facility 4 carries security and authorization messages, so it is a natural filter for login activity. See failed SSH login attempts and authentication anomalies.
• NIST treats syslog-based centralized logging and SIEM software as the two main categories of log management software.

Syslog in Sazabi

Sazabi, an AI-native observability and security platform, accepts logs from an OpenTelemetry Collector through an otlphttp exporter. Its Collector docs tell you to swap the example receivers for the ones your infrastructure uses, so a syslog receiver on the logs pipeline is one way to get syslog in. See the OpenTelemetry Collector integration.