Logging basics: How the Syslog Network Protocol Works

In a previous article, we talked about the syslog protocol and how it works. In this one, we will focus on how it operates at the network level for remote syslog.

The syslog protocol is a widely used standard for message logging on Unix-like operating systems. It enables the transmission of log messages from various devices and applications to a centralized log server. Understanding how syslog messages are transmitted over the network is crucial for effective log management and troubleshooting.

Syslog messages are typically sent using the User Datagram Protocol (UDP) on port 514. However, syslog can also use the Transmission Control Protocol (TCP) for more reliable transmission. Here’s a breakdown of how the syslog network protocol works:



  1. A program generates a log message and formats it according to the syslog protocol.
  2. The message is sent over the network to a syslog server. By default, this is done using UDP on port 514, which is lightweight and has low overhead.
  3. The syslog server receives the message and processes it, storing it in a log file or database for future analysis.



Using UDP for syslog messages is common due to its simplicity and efficiency. However, UDP does not guarantee message delivery, order, or integrity, which can be a drawback in critical logging scenarios. For more reliable transmission, TCP can be used, although it is less common due to the additional overhead.

When examining syslog traffic on the network, tools like tcpdump can be used to capture and analyze the messages. Here’s an example of how to capture syslog traffic with tcpdump:


# Capture syslog traffic on UDP port 514
sudo tcpdump -i eth0 udp port 514

# Capture syslog traffic on TCP port 514
sudo tcpdump -i eth0 tcp port 514

A captured syslog message might look something like this:


14:05:01.123456 IP host1.514 > syslogserver.514: SYSLOG user.notice: Test syslog message

This line shows a syslog message sent from `host1` to `syslogserver` on UDP port 514. The message includes the facility (`user`), severity level (`notice`), and the actual log message (`Test syslog message`).

On the wire, a syslog message consists of a HEADER and a MSG part. The HEADER includes the priority (PRI), version, timestamp, hostname, and app-name, while the MSG contains the structured data and the actual log message.

Here’s a more detailed breakdown of a syslog message structure:


1 VERSION TIMESTAMP HOSTNAME APP-NAME PROCID MSGID STRUCTURED-DATA MSG

For example:


<34>1 2024-05-31T14:05:01.123456Z host1 myapp 12345 ID47 [exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"] Test syslog message

In this example:

  • <34>: The priority value (PRI), indicating the facility and severity level.
  • 1: The version of the syslog protocol.
  • 2024-05-31T14:05:01.123456Z: The timestamp of the message.
  • host1: The hostname of the device that sent the message.
  • myapp: The name of the application or process that generated the message.
  • 12345: The process ID (PROCID).
  • ID47: The message ID (MSGID).
  • [exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"]: Structured data (optional).
  • Test syslog message: The actual log message.



Understanding how syslog messages are transmitted and analyzed helps in setting up efficient logging systems and troubleshooting network or application issues effectively.

If you are using Trunc, we allow you to send syslog messages directly to our logging storage, in addition to other encrypted methods of logging.





Posted in   syslog     by trunc_team

Simple, affordable, log management and analysis.

14 days free trial. No credit card required. Get started