Syslogs basics explained: Protocols, servers, ports, and real-time monitoring

Syslogs: An overview

Syslog, which stands for System Logging Protocol, is a widely used standard for logging messages across IT environments. The syslog protocol facilitates the transmission of log messages from software applications, operating systems, and network devices to a centralized log management system or syslog server.

Syslogs play a vital role in capturing key information about system events, performance metrics, and errors, making it easier to analyze logs and investigate security incidents. Each syslog message typically contains a timestamp, severity level, facility code, and the event description, enabling efficient monitoring and troubleshooting.

Whether you're running Unix-like systems or Windows servers, or managing various network devices, syslog provides a consistent method to consolidate all these diverse logs into one centralized log management system or syslog server. This centralization is critical for efficient tracking, troubleshooting, and in-depth forensic analysis across your entire IT environment.

In this article, we'll dive into the fundamentals of syslog, explaining what it is, how it works, and its essential components.

Components of syslogs

Syslog is built around several key components that work together to enable efficient log collection, transmission, and analysis. These include:

• Syslog daemon or server: The syslog daemon—such as syslogd, rsyslog, or syslog-ng—receives, processes, and forwards syslog messages. It acts as the central hub for collecting logs from various devices and applications across the network. Learn more about different syslog daemons in this section.
• Syslog message: Each syslog message is structured into three main parts:
  1. PRI (Priority): Encodes both the facility (the subsystem generating the message) and severity (the importance level) in a single value.
  2. Header: Contains information such as the timestamp and hostname or IP address of the device that sent the message.
  3. MSG (Message): The actual log message or event data, which details the nature of the event.
• Facilities and severities: Syslog categorizes messages by facility codes—such as kernel, user, mail, daemon, and severity levels (from emergency to debug)—allowing administrators to filter and prioritize logs effectively.
• Structured data (RFC 5424): In this newer syslog format, the STRUCTURED-DATA field was introduced, which allows for the inclusion of machine-readable, key-value pair data enclosed in square brackets ([ ]). This provides a standardized way for applications to embed additional context, metadata, or specific event details, significantly enhancing the search, filtering, and automated analysis capabilities of logs.
• Syslog listener: On the server side, a syslog listener component receives incoming syslog messages over the network, typically via UDP or TCP on port 514.

These syslog components together ensure that syslogs can reliably collected, categorized, and centralized from a wide range of sources, supporting effective monitoring, troubleshooting, and security analysis.

What is a syslog daemon? Exploring syslogd, rsyslog, and syslog-ng

A syslog daemon is a critical service that runs at the background that receives, processes, and transmits the log messages. The daemon parses each incoming message and determines, based on its configuration file (e.g. /etc/syslog.conf), where to store or forward the log data. Destinations can include local log files, remote syslog servers, or other endpoints.

There are different types of syslog daemons, such as syslogd, rsyslog, and syslog-ng.

• Syslogd is the original and most common syslog daemon found on Unix and Linux systems. Its primary role is to collect, process, and store log messages generated by devices, applications, and operating systems. The syslogd daemon listens for log messages typically sent via local UNIX sockets or over the network and routes them to an appropriate destination file, usually etc/syslog.conf.
• Rsyslog emerged in 2004 as an extension of syslogd, maintaining backward compatibility with the original configuration syntax. Over time, rsyslog added features like high performance, support for TCP and encryption, and modularity. It is the default syslog daemon on many Linux distributions and is valued for its speed and compatibility, though its configuration files can be less intuitive and harder to maintain compared to syslog-ng.
• Syslog-ng was introduced in the late 1990s as a robust, next-generation replacement for syslogd. It brought significant enhancements such as support for TCP transport, encryption, advanced filtering, and a highly flexible, object-oriented configuration syntax. Syslog-ng is known for its portability across many platforms including Linux, BSD, Solaris, AIX, and more. The clear, reusable configuration files of syslog-ng make it suitable for complex or multi-platform environments.

Understanding syslog: How it works

At its core, syslog operates on a straightforward client-server model. This architecture allows a multitude of devices across your IT environment to centralize their log messages, making management and analysis significantly more efficient.

Here's a breakdown of how the syslog process typically unfolds:

1. Log generation:

• Every device, application, or operating system configured to use syslog acts as a syslog client (also known as a syslog sender).
• When an event occurs—whether it's a user logging in, a system error, a firewall blocking traffic, or an application starting—the client's logging daemon (like rsyslog or syslog-ng on Linux, or a dedicated syslog agent on Windows) generates a log message.
• This message is formatted according to the syslog protocol, including its priority (facility and severity), timestamp, hostname, and the actual event description.

2. Message transmission

• Once a log message is generated, the syslog client sends it over the network to a designated syslog server (also known as a syslog collector).
• The most common transport protocol for syslog is UDP (User Datagram Protocol), typically on syslog port 514. UDP is fast and lightweight, making it suitable for high-volume log streams. However, it's a connectionless protocol, meaning there's no guarantee of delivery; messages can be dropped if the network is congested.
• For environments requiring guaranteed delivery and enhanced security, syslogs can also be transmitted over TCP (Transmission Control Protocol). TCP provides reliable, ordered, and error-checked delivery, often over port 6514, and can be secured using TLS/SSL encryption for confidential log transfer.

3. Log reception by the syslog server:

• The syslog server acts as the central receiving point. It has a syslog listener component that constantly monitors the designated syslog ports (e.g., UDP 514, TCP 6514) for incoming log messages.
• When a message arrives, the server processes it. This involves parsing the message into its individual components (priority, timestamp, host, message content, etc.).

4. Log processing and storage:

• After receiving and parsing, the syslog server's software performs actions based on configured rules. This can include:
  • Filtering: Discarding irrelevant messages or routing specific types of logs to different destinations.
  • Normalization: Converting logs from various sources into a common format for easier analysis.
  • Enrichment: Adding context to logs, such as mapping IP addresses to geographical locations or user identities.
  • Storage: Storing the processed log data in a syslog database or file system for long-term retention, historical analysis, and compliance purposes. Modern syslog servers often use optimized databases for fast querying of large volumes of data.

5. Analysis and action:

• The collected and stored logs then become a rich source of information for monitoring, security, and operational teams. Tools integrated with or built into the syslog server facilitate:
  • Real-time monitoring: Displaying live log streams for immediate oversight.
  • Alerting: Triggering notifications (email, SMS, tickets) based on predefined criteria (e.g., multiple failed login attempts, critical errors, etc.).
  • Reporting: Generating historical reports for compliance audits, trend analysis, and performance reviews.
  • Forensic analysis: Allowing security analysts to search, filter, and correlate events across multiple systems to investigate incidents.

This continuous cycle of generation, transmission, reception, and analysis forms the backbone of effective centralized log management, providing invaluable insights into the health, performance, and security posture of an entire IT infrastructure.

Learn more about syslogs

• Syslog formats and fields
• Different protocols used for syslog collection
• How to encrypt syslogs with TLS
• ManageEngine EventLog Analyzer as your syslog server

Syslog severity levels

Syslogs use severity levels to indicate the importance and urgency of each log message. These levels help administrators prioritize issues, filter logs, automate responses, and meet compliance requirements.

Syslog facilities

Syslog facilities refer to the source of log messages, such as the kernel, mail system, or user processes. Facilities—combined with severity levels—indicate the message's priority, which helps in filtering, analyzing, and routing logs.

Common facilities include:

• 0 - kernel
• 1 - user-level
• 2 - mail system
• 3 - system daemons
• 4 - security/authorization
• 16–23 (local0–local7) - often used for custom or device specific logs

Syslog message formats

A standard syslog message—particularly following RFC 5424—is composed of several distinct parts. Understanding these syslog formats is crucial for parsing logs correctly and extracting meaningful information for analysis, monitoring, and troubleshooting.

Here are the key components typically found in a syslog message:

1. PRI (Priority Value):
   • This is an 8-bit field, often the first part of a syslog message, enclosed in angle brackets (e.g., <34>).
   • It combines two values:
     • Facility Code: Indicates the source of the message (e.g., kernel messages, mail system, security authorization, local use). There are 24 standard Facility values.
     • Severity Level: Denotes the urgency or importance of the message (e.g., Emergency, Error, Warning, Informational). There are eight standard Severity levels.
   • The formula to calculate PRI is (Facility * 8) + Severity. For example, <34> signifies a Facility of 4 (security/authorization messages) and a Severity of 2 (Critical).
2. VERSION: Identifies the version of the syslog protocol specification. For RFC 5424, this value is typically "1".
3. TIMSTAMP: Indicates when the event occurred. Formatted according to RFC 3339—which is a profile of ISO 8601—ensuring precision (often down to the millisecond) and timezone information (e.g., 2025-06-16T13:55:35.123Z or 2025-06-16T19:25:35.123+05:30).
4. HOSTNAME: The identity of the host that originated the message. This can be a hostname, an IP address, or a system name.
5. APP-NAME: Identifies the application or process that generated the message (e.g., sshd, httpd, kernel). This field can be "-" if not applicable.
6. PROCID (Process ID): The process ID of the application that generated the message. This field can also be "-" if not available.
7. MSGID (Message ID): A string that identifies the type of message. This part of the syslog message can be used to filter and analyze specific types of events. Like APP-NAME and PROCID, this field can be "-" if not applicable.
8. STRUCTURED-DATA:
   • This is a highly flexible component introduced in RFC 5424, enclosed in square brackets (e.g., [exampleSDID@32473 iut="3" eventSource="App" eventID="1011"]).
   • It allows for the inclusion of machine-parsable data in a key-value pair format. This is incredibly useful for embedding application-specific metadata, making logs richer and easier to analyze programmatically. It significantly enhances the search and filtering capabilities.
   • This field can be "-" if no structured data is present.
9. MSG (Message): This is the human-readable part of the log message, which has the actual log content or event description. It's often free-form text providing details about the event that occurred.

Example of an RFC 5424 syslog message (Illustrative):

            <34>1 2025-06-16T13:55:35.123Z myhost.example.com sshd 12345 ID20 [meta sd_id="login_attempt" username="john_doe"] Failed password for root from 192.168.1.100 port 54321 ssh2
            In this example:
            <34>: PRI (Facility 4, Severity 2)
            1: VERSION
            2025-06-16T13:55:35.123Z: TIMESTAMP
            myhost.example.com: HOSTNAME
            sshd: APP-NAME
            12345: PROCID
            ID20: MSGID
            [meta sd_id="login_attempt" username="john_doe"]: STRUCTURED-DATA
            Failed password for root from 192.168.1.100 port 54321 ssh2: MSG
        

ManageEngine EventLog Analyzer as a syslog server

ManageEngine EventLog Analyzer is a comprehensive log management solution that can effectively function as your syslog server too. The solution simplifies the collection, monitoring, and analysis of syslog data from network devices such as routers and switches, Linux/Unix systems, servers, and applications. With support for both UDP and TCP syslog protocols, EventLog Analyzer enables real-time log aggregation, and offers advanced search, intuitive dashboards, and automated alerting for security and compliance. Its user-friendly interface and robust reporting make it easy to detect threats, troubleshoot issues, and meet regulatory requirements—all from a single platform.

EventLog Analyzer:

• Supports the syslog protocol, allowing you to receive and process syslog messages from various devices. Check out the log formats supported by EventLog Analyzer.
• Centralizes the storage and management of syslogs from multiple sources for effective correlation and analysis.
• Generates alerts in real time, allowing critical events to be immediately detected.
• Helps you comply with regulatory mandates by offering custom log retention, forensic analysis, and incident report generation.

Explore the syslog monitoring capabilities of EventLog Analyzer

Syslog basics: FAQs