What is Syslog? The Complete Beginner’s Guide (2026)

Logs are the lifeblood of IT operations. Whether you’re debugging an application, monitoring network devices, investigating a security incident, or preparing for an audit, logs provide the visibility you need. But with so many sources generating events, how do you collect and manage them efficiently?

That’s where syslog comes in.

Syslog is old and not without its issues, but still one of the most widely used standards for log message transport and management. It has been around since the early days of Unix, yet it continues to power modern observability pipelines, Security information and event management (SIEM) systems, and security data lakes.

In this guide, we’ll cover:

• What syslog is and how it works
• Why syslog remains relevant
• Common syslog use cases
• Benefits and limitations you should know

This post is the starting point for our Comprehensive Guide to Syslog.

What is Syslog?

Syslog is a standardized protocol for sending and receiving log messages across systems and devices. It allows operating systems, applications, and network appliances to report events to a syslog server, where the events can be stored locally (typically in a logfile), or sent to a central syslog server for centralized collection.

• Origin: Created in the 1980s as part of the Sendmail project.
• Standardization: Formalized in RFC 3164 (The BSD syslog protocol, 2001) and updated in RFC 5424 (The syslog protocol, 2009).
• Purpose: Provide a lightweight, consistent way to collect event data.

At its core, syslog defines a simple message format (a header and a free-form message) and a transport method. Any system that speaks syslog can forward logs to a collector — whether it’s a router, Linux server, or firewall. This simplicity made syslog easy to use, but its lack of security, reliability, and most notably, standards for structuring content is causing data processing issues for observability and SOC teams even today.    

Learn how syslog fits into broader infrastructures in our article on Resilient Syslog Architectures.

How Syslog Works (High-Level)

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.

A well-formed BSD syslog message consists of a header and the message body, like this:

<priority>timestamp hostname application: message body with info
<-----------------header----------------><----message body----->

1. Priority (PRI): Encodes facility (subsystem) + severity level.
2. Timestamp: The date the message was created. Incorrect date formats and missing timezone information can cause problems.
3. 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.
4. Program: Identifies the application or process that generated the message.
5. Message body: The actual log event.
   

Transport Options:

• UDP 514 → Fast, but no delivery guarantee. The most common cause of syslog data loss.
• TCP 514 → Reliable, ordered delivery, but still not secure.
• TLS → Secure, encrypted transport, with optional authentication.
  

What happens to an event:

1. An application or device generates an event.
2. The local syslog daemon (for example, AxoSyslog or rsyslog) that’s running on the host processes it.
3. The syslog daemon forwards the message about the event to a central syslog server.
4. The server stores the message in local storage and/or routes it to other tools (analytics/observability/SIEM).

For a deep dive into parsing and filtering, see Parsing Firewall logs.

Common Syslog Use Cases

Syslog’s versatility makes it useful across industries for collecting:

• Operating system logs → Kernel errors, authentication events, service restarts.
• Network device logs → Firewalls, switches, and routers reporting status changes, alerts, and data about the traffic.
• Application logs → Web servers (e.g., Apache, Nginx), databases, or custom apps.
• Compliance & auditing → PCI-DSS, HIPAA, SOC 2, and other laws and industry standards require centralized logging.

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

Benefits and Limitations

Benefits

• Standardized → Supported across thousands of platforms.
• Centralized collection → Allows easier troubleshooting and monitoring.
• Flexibility → Can forward messages to multiple destinations.

Limitations

• Scaling → Scaling syslog architectures to high volumes requires significant know-how, particularly when using the UDP transport.
• Security gaps → Early syslog had no encryption or authentication.
• Reliability → Traditional syslog is prone to losing messages. Native syslog lacks application-level acknowledgement and backpressure handling.
• Unstructured payload → The main body of the messages is unstructured, causing data quality issues when sent to SIEMs (this is particularly acute with the older BSD syslog format). Parsing the content of the messages requires an extensive database that’s difficult to create and maintain.

See how to handle scaling challenges in Scalable Syslog Architectures.

For details on the advantages of using OpenTelemetry to transport log messages, see Why Use OpenTelemetry gRPC for Log Data Transport.

Key Takeaways

• Syslog is a time-tested logging standard that remains relevant. In certain environments, the source of over 50% of security data is still syslog.
• It’s supported by nearly every system, making it a universal choice for log transport.
• While it has limitations, many devices support only syslog, with no direct support for more reliable protocols like OpenTelemetry.

For a complete list of topics covered in this series, see the Comprehensive Guide to Syslog.