Syslog Guide: Understanding its Features and Code Examples

June 25, 2024 by OpenObserve Team

Introduction to Syslog

Syslog is a protocol computer system that sends event data logs to a central location for storage and analysis.

The protocol consists of three layers: content, application, and transport. Individual applications or system components generate Syslog messages and follow a standard format that includes

  • a facility code for message source identification and
  • a severity indicator.

These messages are crucial for maintaining system health, troubleshooting issues, and monitoring network activities.

The primary purposes of syslog include:

  • Centralized Logging: Syslog allows logs from various devices, such as routers, switches, firewalls, and operating systems, to be collected in a central location for monitoring and review.
  • Event Tracking and Error Monitoring: It helps track events, errors, and system performance, providing valuable information for system administrators.
  • Anomaly Detection: By aggregating logs from multiple devices to a central server, syslog aids in detecting anomalies and streamlining network monitoring.
  • Enhanced Visibility: Syslog offers enhanced visibility across the network, allowing administrators to have a comprehensive view of system activities without the need to log into individual devices.
  • Security and Troubleshooting: It provides administrators with critical information about system events, health status, and abnormal occurrences, aiding in troubleshooting and addressing security-related issues effectively.

Despite its popularity and usefulness, syslog has some limitations, such as lacking built-in authentication mechanisms, potential message loss due to UDP transport, and inconsistencies in message formatting.

However, it remains a widely used and effective option for logging event data on networks, offering a standardized way to exchange log information efficiently.

Careers for Developers at OpenObserve

Syslog messages have eight built-in severity levels, denoted by both a number and a name:

Number Severity Description
0 Emergency System is unusable
1 Alert Take action immediately
2 Critical Critical conditions
3 Error Error conditions
4 Warning Warning conditions
5 Notice Normal but significant conditions
6 Informational Informational messages
7 Debug Debug-level messages

These severity levels are used to categorize the importance and urgency of syslog messages.

The syslog severity is set based on the log type and contents.

For example,

  • Traffic and configuration logs are typically set to the Informational severity level,
  • Threat and system logs can range from Low (Notice) to Critical (Critical) severity depending on the specific event.

Get started for FREE with OpenObserve.

Syslog was developed in the 1980s by Eric Allman as part of the Sendmail project. Other systems, such as routers, readily adopted it.

Syslog originally functioned as a de facto standard without any authoritative published specification, and many incompatible implementations existed.

In 2001, the Internet Engineering Task Force (IETF) documented the status quo in RFC 3164, known as the "BSD syslog" protocol. However, RFC 3164 was later obsoleted by RFC 5424 in 2009, which standardized the "modern" version of syslog.

The key changes in the standardization process include:

  1. Adoption of ISO-8601 timestamps that include the year
  2. Introduction of structured data fields
  3. Support for UTF-8 encoding
  4. The Syslog protocol has evolved to support various network transports:
  5. The earliest implementations used UDP, documented in RFC 5426
  6. TCP support was added, detailed in RFC 3195 and RFC 6587
  7. TLS encryption was introduced, as specified in RFC 5425

Despite the standardization efforts, many systems still use the older RFC 3164 formatting for syslog messages. Multiple RFCs published by the IETF now define the Syslog protocol.

Benefits of Logging

The Importance of Logging

Logging is a critical component of any software system. Here are some key reasons why logging is so important:

  1. Debugging and Troubleshootinga. Logs are essential for identifying the root cause and resolving problems quickly when issues arise in an application.
    b. Logs provide a detailed history of events leading up to an issue, allowing developers to confirm assumptions, verify data, and pinpoint the source of the problem.
  2. Monitoring and Performance Analysisa. Logs can monitor an application's performance and identify potential bottlenecks.
    b. Logs record metrics such as response times, resource usage, and error rates, providing insights into an application's performance in real-time.
  3. Compliance and Auditinga. In many industries, compliance and auditing are critical concerns.
    b. Logging provides a detailed record of user activity, system events, and data access, allowing organizations to demonstrate that their applications are operating compliantly and securely.
  4. Gaining Insights and Enhancing User Experiencea. Logs can provide valuable insights into user behavior and patterns, enabling data-driven decisions to improve the user experience.
    b. By tracking events and analyzing historical data, organizations can fine-tune processes and enhance the value of their systems.
  5. Facilitating Knowledge Transfera. Detailed logs can help new team members quickly understand an application's behavior and identify problem areas, saving time and money on knowledge transfer efforts.
    b. This is especially important in today's dynamic job market, where employees frequently change roles.

Logging is essential for building robust, reliable, and maintainable software systems.

Logging is a critical tool for developers and organizations alike. It provides valuable insights into application behavior, enables debugging and troubleshooting, supports compliance and auditing, and facilitates knowledge transfer.

Get started for FREE with OpenObserve.

Advantages of Syslog

The advantages of using syslog for logging include:

  1. Centralized Logging: a. Syslog enables organizations to have a centralized logging system, improving security and data privacy by providing a single point of access for storing logs.
    b. This centralized approach ensures consistent logging across the entire environment, reducing the risk of log manipulation or unauthorized changes.
  2. Easier Monitoring and Managing of Logs: a. By storing log data in one place, syslog simplifies tracking log history and quickly detecting errors or anomalies.
    b. This real-time visibility into systems allows organizations to promptly identify potential threats or malicious activities and improve response times in case of security breaches.
  3. Compatibility with Various Devices and Operating Systems: a. Syslog is compatible with many devices and operating systems, making it suitable for almost any device regardless of platform or architecture.
    b. This compatibility ensures effective log collection from multiple sources into a central repository, facilitating easier analysis.
  4. Scalability: a. Syslog improves the scalability of logging data by efficiently handling large volumes of information from one central location.
    b. This eliminates the need for multiple simultaneous processes, reducing the risk of overloading and instability. It is ideal for high-workload environments where storing large amounts of log data is crucial.

Overall, syslog offers an efficient and secure way to manage logs across multiple devices and operating systems for high-workload environments.

Components of Syslog Servers

Components of Syslog Servers

Syslog listener

A Syslog listener is a crucial component of a Syslog server that listens to and collects messages sent over the network.

It gathers and processes syslog data sent over UDP port 514, the default port for syslog communication.

The Syslog listener receives log messages from various devices and applications and forwards them to the Syslog server for storage, analysis, and dispatch.

Database for log storage

The database for log storage is a crucial component of a syslog server, responsible for storing and organizing log messages received from various devices and applications.

This database allows for the structured storage of log data, enabling easy retrieval, analysis, and management of logs.

In the context of Syslog-ng Store Box (SSB), the database for log storage plays a vital role in collecting log messages from different sources, including UNIX/Linux/Windows system logs, firewall and router logs, various application logs, and SQL sources.

The SSB appliance can parse, rewrite, filter, and store these log messages, providing a comprehensive log management solution.

Management and filtering software

Management and filtering software are crucial components of a syslog server that enable efficient management, filtering, and analysis of the collected log data.

This software provides the following key functionalities:

  • Filtering:
    • The management software allows users to filter syslog messages based on various criteria such as input source, message text, host IP address or name, time of day, or priority level.
    • This helps quickly identify and focus on the most relevant log data, making detecting potential issues or security threats easier.
  • Alerting:
    • The management software enables customizable alerts based on specific syslog messages or patterns.
    • These alerts can trigger actions like running scripts, sending email notifications, or forwarding messages to other systems, allowing prompt response to critical events.
  • Reporting:
    • The software provides reporting capabilities to generate security event reports and gain insights into network activities, such as administrator logins, device configuration changes, and blocked packets.
    • Users can customize report layouts, event log columns, logos, colors, and fonts.
  • Compliance and Auditing:
    • The management software helps organizations meet compliance requirements by monitoring controls and notifying them in real-time when any compliance control fails.
    • It supports PCI/DSS, CMMC, NIST, ISO 27001, and GDPR compliance frameworks.
  • Syslog Retention Policy:
    • The software allows configuring syslog message retention policies, such as archiving entries older than a specified period and removing archived entries after a more extended period.
    • This helps manage storage requirements and comply with data retention regulations.
  • Syslog Analysis:
    • The management software provides tools for real-time syslog monitoring, searching through large log files, highlighting specific entries, viewing frequencies, and exporting result sets.
    • It also enables grouping and sorting syslog messages using complex regular expression-based criteria.

Syslog server software simplifies collecting, analyzing, and responding to log data from various network devices and applications by offering management and filtering capabilities.

Filtering Specifics

Here are some examples of message filtering using Syslog:

  • Filtering by Severity Level
    • You can use the level() filter function to filter messages by severity level.
    • For example, to only allow messages with a severity warning or higher, you would use: filter f_warn { level(warning..emerg); };
    • This will match messages with severity warning, error, critical, alert, or emergency.
  • Filtering by Facility
    • You can use the facility() filter function to filter messages by facility.
    • For example, to only allow messages from the mail facility: filter f_mail { facility(mail); };
    • You can also negate the filter to exclude messages from a facility: filter f_not_mail { not facility(mail); };
    • This will match all messages except those from the mail facility.
  • Filtering by Program Name
    • To filter messages by the program name that sent the message, you can use the program() filter function.
    • For example, to only allow messages from the sudo program: filter f_sudo { program("sudo"); };
    • This will match " sudo " messages in the program name field.
  • Filtering by Message Content
    • To filter messages based on the content of the message text itself, you can use the match() filter function along with a regular expression.
    • For example, to match messages containing the string "error": filter f_error { match("error"); };
    • This will match any message with the word "error" anywhere in the message text.

Combining these filter functions with boolean operators like and or not, you can create complex filtering rules to route messages to the appropriate destinations based on your needs.

Filters are a powerful way to control the flow of log messages in a syslog environment.

How It Works

The three layers of the Syslog standard are defined as follows:

  1. Syslog Content Layer:
    • This layer contains the actual information present in the event message.
    • It includes details such as facility codes and severity levels, providing essential data about the reported event.
  2. Syslog Application Layer:
    • The application layer generates, interprets, routes, and stores the syslog messages.
    • It processes and manages the messages, ensuring they are correctly handled and stored for further analysis.
  3. Syslog Transport Layer:
    • The transport layer is responsible for transmitting the syslog messages over the network.
    • It ensures the efficient and reliable delivery of log messages from the originator to the collector or other relays in the syslog architecture.

Configuration for sending messages to several destinations

To configure syslog-ng to send messages to multiple destinations, you can define multiple destinations and specify them in the log path statement.

For example, you can use the mod() function to send every nth message to a different destination.

Note that the exact configuration may vary depending on your specific use case and the version of syslog-ng you are using.

You should consult the syslog-ng documentation and community forums for more detailed information and examples.

OpenObserve on Github

Alarms and instant notifications

Syslog can send instant notifications and alarms using various monitoring and management tools.

Here are a few key ways Syslog enables alarms and notifications:

  • Integrating with SIEM systems:
    • Tenable Identity Exposure can push security information related to Active Directory to SIEM Syslog servers to improve monitoring and alerting.
    • Alerts can be configured to trigger changes, such as each deviance, each attack, or health check status changes.
  • Configuring alarm notification actions:
    • Tools like Veeam ONE support configuring syslog as an alarm notification action.
    • In the Alarm Settings window, you can select "Send Syslog" as the action to trigger when an alarm is raised.
  • Leveraging syslog severity levels:
    • ManageEngine OpManager maps its alarm severities to syslog severities when sending notifications via Syslog.
    • For example, critical alarms are sent with the syslog severity "critical," trouble alarms as "error," and clear alarms as "informational."
  • Enabling remote syslog notifications:
    • Netdata allows forwarding alarms to a remote syslog server using arbitrary user-specified templates.
    • This enables the integration of Netdata alarms with existing alerting mechanisms that consume syslog events.
  • Sending structured syslog alerts:
    • Tools like Sandfly Security send rich structured data to the syslog destination, providing the same detailed information as seen in the tool's interface.

By integrating with Syslog, monitoring and management tools can send instant notifications and alarms by leveraging the organization's centralized logging capabilities and existing alerting pipelines.

Syslog Servers

Syslog Servers for Diagnostic and Monitoring Data

Syslog servers are crucial in collecting, storing, and analyzing diagnostic and monitoring data from various network devices.

They serve the following purposes:

  • Centralized Logging: Syslog servers provide a centralized location for storing log messages from routers, switches, firewalls, servers, and other network devices. This centralized approach simplifies log management and enables efficient monitoring and troubleshooting.
  • Real-Time Alerts: Syslog servers can be configured to generate real-time alerts based on predefined events or thresholds. These alerts help network administrators identify and address issues promptly, ensuring optimal network performance.
  • Security Auditing: Syslog servers facilitate security auditing by collecting and analyzing syslog data monitoring and detecting suspicious activities, unauthorized access attempts, and system changes. This helps maintain network security and compliance.
  • Historical Analysis: Syslog servers store log messages over time, allowing for historical analysis of network events. This historical data can be valuable for identifying patterns, trends, and recurring issues.
  • Integration with Monitoring Tools: Syslog servers can integrate with monitoring tools and Security Information and Event Management (SIEM) systems to view network activities comprehensively.

Examples of Windows-based and Mac-OS Syslog Servers

Windows-Based Syslog Servers:

Kiwi Syslog Server: A simple-to-install server that generates reports in plain text or HTML.

PRTG: It adds a sensor to enable Syslog monitoring, focusing on SNMP and Syslog protocol data.

SNMPSoft Sys-log Watcher: A dedicated syslog server compatible with various Windows versions.

The Dude: It is used for general network management and has a built-in syslog server. It is compatible with Windows and Linux.

Visual Syslog Server: A lightweight option for real-time alerts and configurable thresholds, compatible with various Windows versions.

Mac-OS Syslog Server:

Splunk: Enables system monitoring and syslog events, known for operational intelligence. It can be configured as a forwarder to a central monitoring server.

These syslog servers offer different functionalities and are compatible with Windows, Linux, Unix, and MacOS environments. They provide options for collecting and managing diagnostic and monitoring data across networks.

The Syslog Format

The structure of a Syslog message, according to RFC 5424, includes the following components:

PRI (Priority)

A calculated value that combines the Facility and Severity of the message. It is calculated as PRI = Facility * 8 + Severity.

It contains identifying information about the message, including:

  • VERSION: Denotes the version of the Syslog protocol specification.
  • TIMESTAMP: A formalized timestamp that includes the date and time of the event, with year and milliseconds concerning the time zone.
  • HOSTNAME: Identifies the machine that originally sent the Syslog message.
  • APP-NAME: Identifies the device or application from which the message originated.
  • PROCID: Provides the process name or ID associated with the Syslog system.
  • MSGID: Identifies the type of message.
  • STRUCTURED-DATA: Provides a mechanism to express information in a well-defined and interpretable data format.
  • MSG: Contains the free-form message that provides information about the event.

The structure of a syslog message in RFC 5424 is designed to provide for well-defined information representation.

Syslog Messages

Syslog messages are categorized into eight severity levels, each denoted by a number and a name.

These levels help indicate the importance and urgency of the message.

Here is a breakdown of the syslog message levels:

  • Emergency (0): Indicates that the system is unusable and requires immediate attention.
  • Alert (1): Signifies that action must be taken immediately.
  • Critical (2): Denotes critical conditions that need to be addressed promptly.
  • Error (3): Indicates error conditions that require attention.
  • Warning (4): Highlights warning conditions that should be noted.
  • Notice (5): Represents normal but significant conditions that may require monitoring.
  • Informational (6): Conveys informational messages for general system status.
  • Debug (7): Reserved for debug-level messages used during troubleshooting and debugging processes.

These severity levels help categorize and prioritize syslog messages based on their criticality and impact on the system.

Examples of Syslog Messages

Example 1:

Timestamp: May 27 03:01:42


Severity Level: 5 (Notification)

Mnemonic: UPDOWN

Description: Line protocol on Interface GigabitEthernet0/0 changed state to down

Example 2:

Timestamp: May 26 14:34:35


Severity Level: 1

Mnemonic: URLs

Description: A client with IP address sent an HTTP GET request for

These examples illustrate how syslog messages are structured.

Each message provides valuable information about system events, network activities, and potential issues requiring attention or monitoring.

The Most Important Log Files to Track and Monitor

The most critical log files to track and monitor for system management using Syslog are:

  • /var/log/messages or /var/log/syslog:
    • Contains generic system activity logs informational and non-critical system messages.
    • It can track non-kernel boot errors, application-related service errors, and messages logged during system startup.
  • /var/log/auth.log or /var/log/secure:
    • Records authentication-related events, such as user logins, failed login attempts, and authentication system actions.
    • It helps track security breaches and unauthorized access attempts.
  • /var/log/kern.log:
    • It contains kernel-related logs, crucial for troubleshooting kernel errors, warnings, hardware debugging, and connectivity issues.
  • /var/log/cron:
    • Records information about cron jobs, including successful executions and error messages.
    • It helps in troubleshooting issues with scheduled tasks.
  • /var/log/maillog or /var/log/mail.log:
    • Logs email server activities, such as incoming and outgoing emails.
    • It can be used to troubleshoot email-related issues.
  • /var/log/httpd or /var/log/apache2:
    • Contains logs related to the Apache web server, including access and error logs.
    • These logs are essential for monitoring web server performance, debugging issues, and analyzing user activity.
  • /var/log/mysql.log:
    • Logs MySQL database-related activities, such as queries, errors, and warnings.
    • It helps in troubleshooting database-related issues and monitoring database performance.

By regularly monitoring these critical log files using syslog, system administrators can gain valuable insights into system performance and ensure the system's overall health and stability.

Get started for FREE with OpenObserve.

Pros and Cons of Syslog

Here are the main pros and cons of using Syslog:


  • Centralized Logging:
    • Syslog provides a centralized logging system, improving security and data privacy by having a single point of access for storing logs.
    • This centralized approach ensures consistent logging across the entire environment.
  • Easier Monitoring and Managing of Logs:
    • By storing log data in one place, syslog simplifies tracking log history and quickly detecting errors or anomalies.
    • This real-time system visibility allows organizations to identify potential threats or malicious activities promptly.
  • Compatibility with Various Devices and Operating Systems:
    • Syslog is compatible with a wide range of devices and operating systems, making it suitable for almost any type of device, regardless of platform or architecture.
    • This compatibility ensures effective log collection from multiple sources into a central repository, facilitating easier analysis.
  • Scalability:
    • Syslog improves the scalability of logging data by efficiently handling large volumes of information from one central location.
    • This eliminates the need for multiple simultaneous processes, reducing the risk of overloading and instability.


  • Lack of Authentication:
    • Syslog does not have an authentication feature. When it receives a log message, the syslog server doesn't verify the sending client's hostname or source IP address.
    • As a result, logs can be spoofed by tools such as Netcat.
  • Potential Data Loss:
    • Relying on UDP can lead to a high level of packet loss, particularly in high-latency environments.
    • This can be a major issue for time-sensitive or security logs, where people rely on the data for their processes.
  • Lack of Encryption:
    • Syslog messages are sent in clear text, and there is no requirement to encrypt data on message transport.
    • This means that attackers could intercept and read messages.
  • Vulnerability to Denial-of-Service Attacks:
    • Syslog is vulnerable to denial-of-service attacks, in which the network is flooded by invalid syslog messages.

Overall, syslog offers an efficient and secure way to manage logs across multiple devices and operating systems for high-workload environments.

However, it also has some limitations to consider.

Best Practices

Here are some best practices for securing and managing log files:

Ensure Log Integrity

  • Record logs locally and to a remote server outside the control of regular system managers to provide redundancy and an extra layer of security.
  • Use write-once media to prevent an attacker from overwriting logs.
  • Implement access controls to configure secure, controlled access to audit log data and prevent unauthorized persons from altering or deleting audit records.

Implement Structured Logging

  • Use structured logging formats like JSON or XML that are easier to parse, analyze, and query than plain text logs.
  • Include meaningful information and additional context in log messages to help with diagnostics and root cause analysis.

Optimize Logging Configuration

  • Carefully configure your audit policy to log critical events and avoid logging non-essential or sensitive information.
  • Set the maximum security log size and retention policy based on your organization's audit requirements.
  • Synchronize system clocks to ensure accurate timestamps in retained logs.

Centralized Log Management

  • Archive log data centrally and ensure their integrity by encrypting, implementing time stamping, hashing, and other techniques.
  • Use log management tools to collect, analyze, and visualize log data from diverse sources.

Establish Retention Policies

  • Retain logs for a considerable period based on regulatory requirements, typically at least 90 days.
  • Set up log retention policies to retain necessary log data and delete older data.

Monitor and Alert

  • Review audit logs regularly to enable early detection of suspicious activity, bugs, and system errors.
  • Configure real-time alerts about unusual activities.
  • Set up alerts for specific incidents informed by audit log entries to identify security incidents in real-time.

By following these best practices, organizations can secure and maintain the integrity and value of their log data.

Free and Paid Tools For Centralized Logging

Here is a comparison chart for several free and paid tools for centralized logging:

Tool Type Key Features Pricing
OpenObserve Open-source
  • Centralized log management
  • Real-time log analysis
  • Alerting and notifications
  • Integrations with popular tools
Free, Paid
Splunk Paid Paid
  • Real-time search and analysis
  • Visualizations and dashboards
  • Machine learning capabilities
  • Enterprise-grade security and compliance
Paid, based on data volume
ELK Stack (Elasticsearch, Logstash, Kibana) Open-source
  • Powerful search and analytics
  • Flexible data processing with Logstash
  • Intuitive data visualization with Kibana
Graylog Open-source
  • Real-time log analysis
  • Flexible data processing pipelines
  • Scalable and reliable
  • User-friendly interface
Free, paid options available
Fluentd Open-source
  • Modular architecture with plugins
  • Supports a wide range of data sources and destinations
  • Built-in buffering for handling failures
Grafana Loki Open-source
  • Designed for logs
  • Scalable and cost-effective
  • Integrates with Grafana for visualization
SigNoz Open-source
  • Centralized log management and analysis
  • Real-time visibility and troubleshooting
  • Supports OpenTelemetry for data collection
Logstash Open-source
  • Powerful data processing pipeline
  • Collects, transforms, and enriches log data
  • Integrates with Elasticsearch for storage and search
Loggly Paid
  • Cloud-based log management
  • Real-time search and analysis
  • Alerts and notifications
  • Integrations with popular tools
Paid, based on data volume
Papertrail Paid
  • Cloud-based log management
  • Real-time search and analysis
  • Alerts and notifications
  • Integrations with popular tools
Paid, based on data volume


Here is a summary of key points about syslog management and some additional resources:


  • Syslog is a standard for collecting and storing log information from various devices and applications. It uses a client-server architecture where clients send logs to a dedicated Syslog server.
  • Syslog servers centrally store syslog messages and SNMP traps. They typically include a syslog listener to gather event data and a database to handle the large volume of log data.
  • Syslog supports various transport protocols, such as UDP and TCP. UDP is faster but can tolerate data loss, while TCP is slower but ensures reliable delivery.
  • Syslog messages include standard attributes like timestamp, hostname, severity level, source IP, and the actual log message content. They can be used for security investigations, auditing, system management, and infrastructure maintenance.
  • While syslog is natively supported on Linux, Unix, and macOS, Windows requires third-party tools to collect event logs and forward them to a syslog server.
  • Syslog has drawbacks, like a lack of encryption and authentication and vulnerability to spoofing and denial-of-service attacks. Relying on UDP can also lead to data loss in high-latency environments.

Additional Resources

By understanding Syslog and following best practices for its management, organizations can effectively leverage centralized logging to improve system monitoring, troubleshooting, and compliance.

Get started for FREE with OpenObserve.

Who are we?

We provide the simplest and most sophisticated open-source observability platform. Our flagship product, OpenObserve, gives you a unified platform to collect, process, and visualize all your logs, metrics, and traces.

We are committed to building the best observability platform for developers and operators. We believe in open source and thrive on building a community around our products.

We are a remote-first company with a globally distributed team. We are headquartered in San Francisco, California.

Get in touch with us

Let's talk

Send us an email at or connect with us:

Get started with OpenObserve



The OpenObserve Team comprises dedicated professionals committed to revolutionizing system observability through their innovative platform, OpenObserve. Dedicated to streamlining data observation and system monitoring, offering high performance and cost-effective solutions for diverse use cases.

OpenObserve Inc. © 2024