What Is Syslog? A Complete Guide 

Syslog is a standardized system logging protocol and message format that lets devices, applications, and operating systems send log data to a central location for storage and analysis. It was built so that a router, a Linux server, a firewall, and a mail application could all report events in the same basic format, regardless of who made them or what language they were written in.

A syslog message always carries three elements: 

• where the event came from (facility)
• how serious it is (severity)
• what happened (the message text)

Instead of logging into forty devices to check forty log files, an administrator can point all forty at one syslog server and search, filter, and alert on everything from a single screen.

Syslog runs on nearly every Unix-like system by default and is supported on Windows, network hardware, and most enterprise applications through built-in agents or third-party forwarders.

How Does Syslog Work?

Syslog works by moving a message through three layers: The application that generates the event, the transport that carries it, and the collection layer that stores and processes it.

Let’s look at each stage in more detail.

1. Application layer: A program, service, or device generates an event such as a failed login, a dropped connection, a disk nearing capacity and formats it as a syslog message using the local syslog library (syslog() on Linux, for example) or a built-in logging function.

2. Transport layer: The message leaves the source device over UDP (User Datagram Protocol) or TCP (Transmission Control Protocol), typically on port 514, and travels to a receiver. Some environments encrypt this leg with TLS on port 6514, which matters for messages that carry authentication attempts or configuration changes.

3. Collection layer: A syslog server or daemon (syslogd, rsyslogd, syslog-ng) receives the message, parses it into fields, and decides what to do with it: write it to disk, forward it to another system, trigger an alert, or route it into a SIEM.

Local Logging vs. Network Logging

Not every syslog message is sent from its source device. 

• Local logging writes events to a file on the same machine such as on most Linux distributions, that’s /var/log/syslog or /var/log/messages. This works fine for troubleshooting a single server, but it doesn’t scale: if a device is compromised or wiped, its local logs go with it.
• Network logging sends the same messages to a remote syslog server over UDP or TCP, so a copy of every event exists somewhere the originating device can’t reach. 

Most production environments run both — local logging for fast, on-box troubleshooting, and network logging for retention, correlation, and evidence that survives even if the source is compromised.

What Happens After a Message Is Received

The first step is receiving a message. A syslog server that’s doing its job will typically:

• Parse the message into structured fields (timestamp, host, facility, severity, message body)
• Store it, usually in a database or indexed flat-file system, with a defined retention period
• Route it to the right destination for example, a SIEM, a log analytics platform, a long-term archive, or several of these at once
• Alert on it if it matches a rule (a spike in failed logins, for example, or a specific error code)

Storing the message is just one part of the job. A server also needs to parse it, route it, and alert it to be useful.

What Is a Syslog Server?

A syslog server is the system that receives, indexes, and manages log messages sent by other devices on the network. It’s made up of two core components: 

• a listener that accepts incoming UDP or TCP connections
• a database (or log store) that holds the parsed messages for search and retention.

Once a message is received, the server’s job goes beyond storage. Functions a syslog server typically performs include:

Syslog Client, Relay, or Server: What’s the Difference?

These three roles are often used loosely, but they describe different jobs in the same pipeline:

• Syslog client is the originating device. Routers, switches, firewalls, intrusion detection systems, and IoT devices all act as clients, sending their own events outward.
• Syslog relay is an intermediate system that receives messages and forwards them onward, sometimes after filtering or reformatting. Relays are common in segmented networks where a client can’t reach the central server directly.
• Syslog server is the endpoint that stores and indexes messages for the long term.

Why Centralized Logging Matters for Security

A syslog server that stores logs off the originating device gives security teams something a local log file can’t: evidence that survives the incident. 

If an attacker gains access to a device and deletes its local logs to cover their tracks, the copies already sent to the central syslog server remain intact. That’s one reason syslog data shows up in forensic investigations and compliance audits. It’s often the only surviving record of what happened on a compromised host.

What Is the Syslog Message Format?

A syslog message is built from a priority value, a header, and a message body. Understanding the priority value — and the facility and severity codes behind it — is what most people skip, but it’s also what makes log data usable instead of just readable.

Decoding the PRI Value

The PRI value is a single number that encodes both the facility and severity of a message in one field.

Every syslog message starts with a PRI value in angle brackets, like <134>. That number is calculated as:

PRI = (Facility × 8) + Severity

Take <134> as an example. Divide 134 by 8: the result is 16 with a remainder of 6. That means the facility code is 16 (local0) and the severity code is 6 (Informational). A network engineer scanning raw logs can decode any PRI value the same way, without needing a lookup tool.

Facility Codes (0–23)

The facility code identifies which type of process generated the message.

Severity Levels (0–7)

Severity indicates how urgent a message is, and it’s the field most teams use to build alerting rules.

Anatomy of a Syslog Message

Here’s a labeled RFC 5424 message:

<34>1 2026-07-15T10:22:41.003Z web-app-03 nginx 8291 – [meta@32473 ip=”203.0.113.5″] Upstream timeout on /checkout

RFC 3164 vs. RFC 5424: What Changed

Syslog has two competing message formats in active use, and knowing which one a device sends affects how you parse it.

RFC 3164’s timestamp is the most common source of parsing headaches: without a year or timezone, correlating events across daylight saving changes or multiple regions takes extra normalization work. Most current environments still receive a mix of both formats, since older network hardware often can’t be upgraded to RFC 5424 output.

What Syslog Tools Should You Use?

Syslog tooling breaks down into five categories, and most log pipelines use at least three of them together.

• Agents and senders: It is lightweight software on the source device that formats and transmits log data (rsyslog, syslog-ng, NXLog)
• Collectors and aggregators: systems that receive messages from many sources and consolidate them before forwarding
• Relays: these are intermediate forwarders used in segmented or multi-site networks
• Analyzers: these are the tools that index, search, and visualize log data (Splunk, Elasticsearch, LogicMonitor Logs)
• Alerting and automation tools: these are systems that trigger notifications or run remediation scripts based on log content

Which Tool Fits Which Environment

• Small team, single data center: A single rsyslog or syslog-ng instance handling collection, filtering, and local storage is usually enough.
• Enterprise, multi-site: Relays at each site forward to a central aggregator, with a dedicated analytics layer on top for search and correlation.
• Mixed-OS environments: Look for agents with native support across Linux, Windows, and network OS variants — Windows doesn’t generate syslog natively, so it needs a forwarding agent (like NXLog or Windows Event Forwarding with a syslog bridge) to participate.
• Network-heavy environments: Prioritize a collector that can handle high message volume over UDP without dropping packets, since routers and switches under load can generate thousands of messages per minute during an incident.

Rsyslog vs. Syslog-ng

The two most common open-source syslog daemons differ mainly in platform support and documentation depth.

1. Syslog-ng runs on AIX, HP-UX, Linux, Solaris, Tru64, and several BSD variants, which makes it a better fit for mixed-OS environments. It also supports real-time log classification and tagging, and its official Administrator Guide walks through filters, sources, destinations, and log formats in enough detail to configure most setups without external help.
2. Rsyslog is primarily built for Linux and Solaris. It comes installed as the default logging daemon on most major Linux distributions, which makes it the path of least resistance for Linux-only environments, but its documentation is thinner. Teams troubleshooting a specific rsyslog module often end up piecing together configuration details from forum threads rather than official docs.

Syslog and SIEM Integration

Syslog data usually feeds into a larger system rather than being the end point itself. Most SIEM and XDR platforms ingest syslog as one of several data sources, correlating it with endpoint telemetry, network flow data, and identity logs to build a fuller picture of an incident.

A firewall’s syslog output showing a blocked connection attempt means more when it’s correlated against an endpoint alert showing malware execution on the same host at the same time — that correlation is what a SIEM adds on top of raw syslog data.

Syslog Tool Selection Checklist

Before choosing a syslog tool, check it against:

• Parsing support for both RFC 3164 and RFC 5424
• Full-text and structured search across historical data
• Rule-based filtering to control message volume before storage
• Alerting on severity, facility, or custom pattern matches
• Configurable retention by log source or type
• TLS support for encrypted transport
• Multi-vendor and multi-OS device support

What Are Syslog Best Practices and Challenges?

Getting syslog running is easy. Keeping it reliable, secure, and useful over time is where most environments run into trouble.

• Assign clear pipeline ownership: Someone needs to own the syslog pipeline the way a team owns a production service like deciding which sources are approved, documenting changes to collector configuration, and verifying after every change that logs are still arriving from every expected source. Without this, it’s common for a source to silently stop forwarding logs for weeks before anyone notices, usually right when those logs are needed for an investigation.
• Control volume before it controls you: A single busy switch can generate thousands of log lines per day, and most of them aren’t worth storing. Filter at the source where possible, normalize message formats so similar events don’t fragment into dozens of variants, and route only the signal into expensive, long-retention storage.
• Plan for transport reliability trade-offs: UDP is fast and lightweight but doesn’t guarantee delivery; a burst of traffic or a brief network hiccup can silently drop messages. TCP guarantees delivery but adds overhead and can back up if the receiver falls behind. High-security or compliance-driven environments generally move critical log sources to TCP or TLS-encrypted TCP, and reserve UDP for lower-stakes, high-volume sources like routine health checks.
• Harden the collection layer itself: Encryption in transit (TLS on port 6514) protects log data on the wire, but it doesn’t protect the collector from unauthorized access, tampering, or an attacker planting false log entries to cover their tracks. Restrict who can write to or modify the syslog server, and monitor the pipeline itself for unexpected gaps or configuration changes.
• Treat retention as an operating cost, not just a compliance checkbox: Retention periods are often set once to satisfy an audit requirement and never revisited, even as log volume grows. Reviewing retention against actual investigation and compliance needs, rather than defaulting to “keep everything forever”,  keeps storage costs predictable as the environment scales.

What Are Common Syslog Use Cases?

Syslog shows up anywhere a device or application needs to report what it’s doing such as across network devices, operating systems, and applications.

Network devices such as routers, switches, and firewalls generate syslog messages that let administrators track user activity, monitor performance trends like latency, detect suspicious traffic such as port scans, and flag unauthorized configuration changes.

Operating systems such as Linux, Windows, and macOS all support syslog-based logging for tracking user activity, auditing account access, and detecting performance issues like high CPU usage or memory leaks before they cause an outage.

Applications like databases, web servers, and VPNs use syslog to support compliance monitoring, debugging, and application health tracking. A DevOps team correlating a spike in HTTP 500 errors with a recent deployment is a direct, practical example of syslog data driving a decision, not just recording history.

Where Did Syslog Come From?

Syslog originated in the 1980s as part of Eric Allman’s Sendmail project, built to let the mail server log its own activity in a consistent way. Other Unix tools adopted the same format because it worked, and it became a de facto standard years before it was formally documented. The IETF published it as RFC 3164 in 2001 — codifying existing practice rather than inventing something new — and followed with RFC 5424 in 2009 to add structured data, precise timestamps, and clearer field definitions.

That history is why legacy RFC 3164-style messages still show up in modern environments: older network hardware and long-lived Unix daemons were built against the original format and were never updated, so most log pipelines still need to parse both formats.

Managing Syslog at Scale

Syslog makes it possible to collect log messages from virtually every device and application in your environment. As infrastructure scales, however, simply collecting logs isn’t enough. Teams also need to search, correlate, alert on, and analyze those logs alongside infrastructure metrics. LogicMonitor brings those capabilities together in a single platform, helping operations teams investigate issues faster by viewing syslog data in context with the resources and alerts that generated it.

FAQs