How Syslog Works: Core Concepts Explained

If you manage infrastructure, you’ve seen syslog at work. It’s the universal language of Linux/UNIX logging, helping servers, applications, and network devices report events in a standardized way.

But what happens to a syslog message from the moment it’s generated to when it lands in your log server or SIEM?

In this guide, we’ll break down the core concepts behind syslog:

Message structure (PRI, timestamp, hostname, application, and body)
Transport protocols (UDP, TCP, TLS)
Severity levels and facilities
Message routing and forwarding logic
Buffering, queuing, and reliability

If you’re new to syslog, start with What is Syslog.

Syslog Message Format

The formats of syslog messages are described by two major RFCs (“Request for Comments”). The first originated well over 40 years ago, and is referred to as RFC3164 or “BSD Syslog”. Though it is the older of the two standards (the other being RFC5424), it is still widely used. Other RFCs derived from these main ones cover capabilities such as transmission over TCP and TLS encryption.

The purpose of the RFCs is to describe a standard structure and format for syslog traffic, with the end goal of making parsing and analysis of the data (particularly between different device vendors) simpler. These RFCs are actually quite readable, and the industry would do well to digest their contents when developing device logging code. Unfortunately, rigorous adherence to the RFCs has not taken hold in the industry, with many vendors “bending the rules” when crafting their individual log formats. Throughout this paper, we will assume all messages adhere to one of the main RFC specifications.

RFC 3164 Syslog Message Structure

<priority>TIMESTAMP HOSTNAME APPLICATION: Message body with info
<-----------------header----------------><----message body----->

Priority (PRI): Encodes facility (subsystem) + severity level.
TIMESTAMP: The date the message was created. Incorrect date formats and missing timezone information can cause problems.
HOSTNAME: The hostname or IP address of the sender.
Note that problems in host attribution (determining which host sent the message) can hinder forensic investigations and threat detection.
APPLICATION: Identifies the application or process that generated the message.‍
Message body: The actual log event.

For example:

<34>Oct 02 12:00:00 web01 apache: User login failed

RFC 5424 Syslog Message Structure

<priority>VERSION ISOTIMESTAMP HOSTNAME APPLICATION PID MESSAGEID STRUCTURED-DATA MSG

<priority>: Encodes severity + facility into a single integer.
VERSION: Protocol version (RFC 5424 introduced this).
TIMESTAMP: Time the event occurred, in ISO 8601 compatible standard timestamp format (yyyy-mm-ddThh:mm:ss+-ZONE).
HOSTNAME: Source machine or device.
APPLICATION: The device or application that generated the message.
PID: The process name or process ID of the syslog application that sent the message. It’s not necessarily the process ID of the application that generated the message.
STRUCTURED-DATA: Optional metadata and key-value pairs for richer context.‍
MESSAGE-BODY: The actual log message.

For example:

<34>1 2025-10-02T12:00:00Z web01 apache 1234 ID47 [iut="3" eventSource="Application" eventID="1011"] "User login failed"

See how parsing challenges are handled in Parsing Syslog Messages.

Facilities and Severities

Syslog messages include two critical dimensions: facility (what subsystem) and severity (how urgent). The Priority value is calculated by first multiplying the Facility number by 8 and then adding the numerical value of the Severity.

Facilities (0-23):

0 	kernel messages
1 	user-level messages
2 	mail system
3 	system daemons
4 	security/authorization messages
5 	messages generated internally by syslogd
6 	line printer subsystem
7 	network news subsystem
8 	UUCP subsystem
9 	clock daemon
10 	security/authorization messages
11 	FTP daemon
12 	NTP subsystem
13 	log audit
14 	log alert
15 	clock daemon
16-23 	locally used facilities (local0-local7)

Severities (0–7):

0 – Emergency (system is unusable)
1 – Alert (immediate action required)
2 – Critical (serious failure)
3 – Error
4 – Warning
5 – Notice (normal but significant)
6 – Informational
7 – Debug

Together, facility and severity form the PRI value, which helps syslog daemons decide how to handle the message.

Syslog Transport Protocols: UDP vs TCP vs TLS

Syslog can be transported using different protocols, each with pros and cons:

UDP (Port 514)

Has been the default transport for decades.
Lightweight, low overhead.
No delivery guarantees — messages may be dropped.
Good for high-throughput but non-critical logging.
Very difficult (if not impossible) to effectively load balance.
In some very high-throughput cases, UDP may be the only choice.

TCP (Port 514)

Reliable delivery with ordering and retransmission.
Higher resource usage than UDP.
Often used for critical infrastructure logs.
No application-level acknowledgement; messages are still “send and forget”.

TLS (TCP with encryption)

Secure and authenticated.
Prevents eavesdropping and tampering.
Required in compliance-heavy environments (finance, healthcare).

Related reading: Syslog over UDP: How to Avoid Losing Messages. To learn about a more reliable way to transport log data, see Why Use OpenTelemetry gRPC for Log Data Transport.

Message Routing and Processing

Syslog daemons (or servers) like AxoSyslog, syslog-ng or rsyslog are responsible for:

Receiving messages from applications or network devices.
Parsing the PRI value to extract severity and facility.
Applying rules/filters to determine the destination for the logs, including files, HTTP/REST, message queues (Kafka), Cloud services, and many others.
Forwarding messages to previously determined destinations.

This makes syslog highly adaptable — a single daemon can write system logs to /var/log/messages, forward events to a SIEM, and ship application logs to a cloud analytics platform simultaneously.

Example: See how syslog integrates with modern pipelines in Send Syslog Data to Grafana Loki.

Buffering, Queuing, and Reliability

One of syslog’s biggest challenges is ensuring reliable delivery in high-volume environments.

In-memory queues → Hold messages before forwarding and send in batches for increased performance; risk of loss if the daemon crashes.
Disk buffering → When a remote destination is unavailable, messages are temporarily written to disk. For details, see Disk buffering for a resilient syslog architecture.
Persistent queues → Increases reliability at the cost of performance.
Backpressure management → Helps prevent overload by slowing input or dropping low-priority logs if messages cannot be sent or processed in a timely manner.

Modern syslog implementations like AxoSyslog enhance reliability with buffering and flow control to handle enterprise-scale message rates without data loss.

For more details, see Scalable Syslog Architectures. To learn about a more reliable way to transport log data, see Why Use OpenTelemetry gRPC for Log Data Transport.

Key Takeaways

Syslog messages should follow a structured format according to RFC 3164 or RFC 5424, with PRI, timestamp, hostname, application name, and body. Unfortunately, many implementations fail to comply with that, causing parsing issues.
The UDP, TCP, and TLS transport protocols each offer trade-offs between speed, reliability, and security.
Facilities and severities help classify and prioritize logs.
Routing logic enables filtering messages and flexibly selecting destinations for compliance, observability, and monitoring.
Buffering and queues are essential for reliability in modern, high-volume environments.

Understanding these syslog fundamentals is the first step toward building a resilient, enterprise-grade logging pipeline. For a complete list of topics covered in this series, see the Comprehensive Guide to Syslog.