What is Syslog?

Syslog (System Logging Protocol) is a standardized, message-based logging format that enables data transfers between infrastructure nodes (such as load balancers or routers) and a central logging server. This sharing of access and runtime information is crucial for auditing, debugging, and error reporting. Using the Syslog protocol and format monitoring, tools can collect information from multi-vendor software and devices for better visibility and security across an organization. 

Syslog is considered an application layer (Layer 7) protocol using either TCP or UDP. The Syslog standard unifies logging protocols and formats across software and devices. It does not require administrators to configure unique log management logic for every service or client they oversee. However, specific log formats are often parsed prior to storage within a database for graphing or search indexing. 

Eric Allman (computer programmer) helped launch Syslog in the 1980s, as part of the Sendmail development project. The Internet Engineering Task Force (IETF) initially defined Syslog under the RFC 3164 standard. Today, the modern iteration of Syslog (at the time of writing) is defined under RFC 5424. Syslog's introduction has since launched multiple spinoff projects aiming to refine the protocol and add functionality.

How does Syslog work?

Understanding Syslog versions

Syslog messages are typically received and transmitted using one of multiple available daemons installed on the machine — though some software natively sends and receives Syslog messages directly. These daemons are baked natively into Linux and Unix systems — typically as either syslogd, sysklogd, rsyslog, or syslog-ng. Each is a unique program (or logging approach) and carries its own version number. 

While older versions of Syslog leverage UDP for messaging, newer implementations support TCP. UDP offers high-volume, low-latency transmission while TCP offers more reliable message delivery. Transmitting over TCP allows administrators to encrypt log transfers using TLS and/or verify that messages are successfully received. UDP doesn't offer encryption or reliability protections since the protocol is connection-less. 

Individual Syslog messages are lightweight due to their simple structure and payload. However, bottlenecking and storage concerns often arise when traffic and activity scale up. Administrators must carefully consider processing capacity — including CPU, memory, and bandwidth — and database size as millions of Syslog messages are collected in a brief period. The same level of planning is also needed to determine how often messages are generated and forwarded. 

Windows approaches logging differently — using Windows Event Log or an external logging tool to create and transport logs. Windows' logging approach is also proprietary, which is why various Windows Server versions don't natively support the Syslog standard. This setup is ideal for those working primarily within the Windows ecosystem, yet introduces added complexity for those sharing logs between Windows devices and Linux or Unix-based servers.

Understanding Syslog components

Syslog relies on three components to operate successfully: the client (which generates and forwards logs), the Syslog server (which receives and stores those logs), and the Syslog protocol itself. Each Syslog message may contain the following data types and attributes depending on whether it follows the BSD or IETF RFC standard: 

• Timestamp

• Hostname

• Source IP address

• Severity level

• Priority value (PRI)

• Process ID (PID)

• Message ID

• Version

• Application

Syslog message attributes are arranged into key-value pairs. The messages themselves are highly structured (especially versus past versions) and are UTF-8 encoded. They may also contain structured metadata with added details about the system. 

Together, the combination of these attributes gives each message important contextual information. They're machine readable and ultimately human readable since they're sent in plain text. However, it's possible to secure log messages with SSL/TLS and use a secure tunnel to prevent man-in-the-middle (MITM) attackers from intercepting them. 

Each Syslog message also contains a block of text in an application-specific format, which can be a simple sentence or a complex JSON structure.

To transmit this information unencrypted, Syslog uses port 514 for both UDP and TCP. Encrypted Syslog transmissions instead use TCP port 6514 — which is secure and not possible with UDP. However, one's networking configurations and logging solutions can specify alternate ports for log forwarding. This is fairly uncommon.

Understanding Syslog severity levels 

Syslog messages are used to share networking details and activity, yet they're also used to report errors. As a result, each message receives a severity level and category indicating whether immediate attention or retrospective analysis is needed: 

• Level 0 – The system is unusable or unavailable (EMERGENCY)

• Level 1 – Corrective action is needed immediately (ALERT)

• Level 2 – Device or system condition is critical (CRITICAL)

• Level 3 – A condition or set of conditions is causing an error (ERROR)

• Level 4 – A condition or set of conditions requires caution (WARNING)

• Level 5 – A condition is considered normal but may require extra attention (NOTICE)

• Level 6 – Runtime information such as access logs (INFORMATIONAL)

• Level 7 – Debugging information (DEBUG)

Source is also quite important for Syslog in Unix. Depending on where the Syslog message originates, the protocol will assign a numerical facility code for tracking. These are as follows: 

• Code 0 – Kernel-level messages

• Code 1 – User-level messages

• Code 2 – Mail system

• Code 3 – System daemons

• Code 4 – Authorization and security messages

• Code 5 – Internally-generated Syslog messages

• Code 6 – Line printer subsystems

• Code 7 – Network news subsystems 

• Code 8 – Unix-to-Unix copy (UUCP) subsystems

• Code 9 – Clock daemon

• Code 10 – Authorization and security messages

• Code 11 – File Transfer Protocol (FTP) daemon

• Code 12 – Network Time Protocol (NTP) subsystem

• Code 13 – Log auditing

• Code 14 – Log alerting

• Code 15 – Clock daemon

• Codes 16 through 23 – Named local0 through local7, these facilities are used for software not covered above (such as web server or load balancer logs).

Does HAProxy support Syslog?

Yes! HAProxy One provides fast and reliable load balancing for UDP, QUIC, and TCP/HTTP traffic with one powerful solution. This includes support for unmatched Syslog forwarding reliability and performance — up to 3.8 million messages per second on a single HAProxy Enterprise instance. HAProxy Fusion also centrally compiles your HAProxy logs in an easy-to-read format for improved searchability, auditing, and compliance. 

HAProxy sends its error and access logs using the Syslog protocol, while formatting them in plain text, JSON, or CBOR for rapid transmission and parsing.

To learn more about Syslog support in HAProxy, check out our UDP load balancing solution or our Log Forwarding With HAProxy & Syslog blog post.