Is Syslog Still the Best Choice for Simple, Low‑Cost Log Collection?

What Is Syslog?

Syslog is a standard protocol for forwarding log messages over an IP network. It originated in BSD Unix and is now defined by RFC 5424 (2009). A typical Syslog message looks like:

<34>1 2023-12-29T10:30:00.123Z server01 sshd 1234 - [meta sessionId="abc123"] Failed password for root from 192.168.1.100

The message consists of several parts: <PRI> – priority (facility + severity) VERSION – protocol version (usually 1) TIMESTAMP – UTC time of the event HOSTNAME – source host name APP-NAME – application name PROCID – process ID MSGID – message identifier (optional) STRUCTURED-DATA – optional structured data MSG – the actual log text

The priority field is calculated as PRI = Facility * 8 + Severity. Common facility values include 0 (kern), 1 (user), 3 (daemon) and 16‑23 (local0‑local7). Severity values range from 0 (Emergency) to 7 (Debug). For example, <34> means Facility = 4 (auth) and Severity = 2 (Critical) because 34 = 4*8 + 2.

Why Syslog Is Still Attractive

1. Simplicity

Syslog works over UDP (or TCP) with a few lines of code. A minimal Java client looks like:

import java.net.DatagramPacket;
import java.net.DatagramSocket;
import java.net.InetAddress;

public class SyslogClient {
    public static void sendSyslog(String message, int facility, int severity) throws Exception {
        int priority = facility * 8 + severity;
        String syslogMsg = "<" + priority + ">" + message;
        try (DatagramSocket socket = new DatagramSocket()) {
            byte[] data = syslogMsg.getBytes();
            InetAddress address = InetAddress.getByName("192.168.1.10");
            DatagramPacket packet = new DatagramPacket(data, data.length, address, 514);
            socket.send(packet);
        }
    }
    public static void main(String[] args) throws Exception {
        sendSyslog("Application started successfully", 1, 6);
    }
}

On the server side, Linux ships with lightweight daemons such as rsyslog or syslog-ng that can receive and store messages without additional agents.

2. High Standardisation

Almost every network device (routers, switches, firewalls) supports Syslog natively. Collecting device logs only requires pointing the device to a Syslog server:

# Cisco device example
logging host 192.168.1.10
logging trap warnings

3. Low Resource Consumption

The client is tiny, making it suitable for edge devices, IoT gateways, or embedded systems. A single modest server (e.g., 2 CPU / 4 GB RAM) can handle thousands of messages per second, which is sufficient for most small‑to‑medium deployments.

Typical Scenarios

Scenario 1 – Network‑Device Log Centralisation

Collect configuration changes, connection status, and traffic anomalies from routers, switches, and firewalls.

Why Syslog? No agent needed, native support on devices, and a fixed log format simplifies parsing.

Practical tip: Store logs per device type, e.g. /var/log/remote/routers/, /var/log/remote/switches/, /var/log/remote/firewalls/.

Scenario 2 – Compliance Auditing & Long‑Term Retention

Industries such as finance and government require years of immutable logs.

Why Syslog? Plain‑text logs are easy to archive to cold storage (NAS, object stores) and can be organised by business line for quick retrieval.

Practical tip: Separate logs by system, e.g.

/var/log/remote/trading-system/   # trading logs
/var/log/remote/user-center/      # user‑center logs
/var/log/remote/payment-gateway/   # payment‑gateway logs

Scenario 3 – Edge Computing & IoT

Thousands of edge gateways need to push logs over unreliable networks.

Why Syslog? Minimal CPU/memory footprint; can use TCP or RELP for reliable delivery.

Scenario 4 – Modernising Legacy Applications

Old monolithic or C/S applications need a cheap way to start sending logs to a central system.

Why Syslog? Replace the existing file appender with a Syslog appender; no heavy dependencies are introduced.

Hands‑On: Building a Syslog Server with rsyslog (Ubuntu)

Install rsyslog (usually pre‑installed): sudo apt install rsyslog Edit /etc/rsyslog.conf to enable UDP and TCP reception:

# UDP reception
module(load="imudp")
input(type="imudp" port="514")

# TCP reception
module(load="imtcp")
input(type="imtcp" port="514")

Define a dynamic file template to store logs per host:

$template DynamicFile,"/var/log/remote/%HOSTNAME%/%$YEAR%-%$MONTH%-%$DAY%.log"
*.* ?DynamicFile

Restart the service: sudo systemctl restart rsyslog Test with the built‑in logger command:

logger -n 192.168.1.10 -P 514 "Hello from client"

Logs will appear under /var/log/remote/<hostname>/YYYY‑MM‑DD.log.

Analyzing Syslog Data

Command‑Line Techniques (for operators)

grep – quick keyword search:

# Find error lines
grep -i "error" /var/log/remote/*/*.log

# Find a specific timestamp
grep "2023-12-29T10:" /var/log/remote/*/*.log

awk – extract fields:

# Show failed SSH logins
awk /Failed\ password/ {print $1, $2, $NF} /var/log/remote/*.log

sed – clean or transform logs:

# Remove duplicate lines
sort /var/log/remote/app.log | uniq > app-unique.log

tail -f – real‑time monitoring, optionally with multitail for several files.

Visual Tools

Graylog – open‑source log management. Quick Docker deployment:

docker run --name mongo -d mongo:4
docker run --name elasticsearch -d elasticsearch:7
docker run --link mongo --link elasticsearch -p 9000:9000 -d graylog/graylog

Filebeat Syslog module – if you already run ELK, enable the built‑in module:

# filebeat.yml excerpt
filebeat.inputs:
  - type: syslog
    protocol.udp:
      host: "0.0.0.0:514"
    max_message_size: 10MiB

output.elasticsearch:
  hosts: ["localhost:9200"]

lnav – terminal log viewer with colour, timeline and SQL‑like queries:

apt install lnav
lnav /var/log/remote/*/*.log

Integrating Syslog with Spring Boot / Java Applications

Two popular appenders are logback‑syslog and log4j‑syslog‑appender. Example using Logback:

<dependency>
    <groupId>net.logstash.logback</groupId>
    <artifactId>logstash-logback-encoder</artifactId>
    <version>7.4</version>
</dependency>

Configure logback‑spring.xml:

<configuration>
    <appender name="SYSLOG" class="ch.qos.logback.classic.net.SyslogAppender">
        <syslogHost>192.168.1.10</syslogHost>
        <port>514</port>
        <facility>LOCAL1</facility>
        <suffixPattern>%app [%thread] %logger %msg</suffixPattern>
    </appender>

    <root level="INFO">
        <appender-ref ref="SYSLOG"/>
        <appender-ref ref="CONSOLE"/>
    </root>
</configuration>

Use the logger as usual:

@Slf4j
@RestController
public class UserController {
    @GetMapping("/user/{id}")
    public User getUser(@PathVariable Long id) {
        log.info("Fetching user by id: {}", id);
        return userService.getById(id);
    }
}

All log entries are automatically forwarded to the Syslog server.

Syslog vs ELK/Loki – When to Choose Which

Prefer Syslog When

Collecting logs from network equipment that already speaks Syslog.

Compliance or long‑term archival is the primary goal.

Operating in resource‑constrained environments (edge, IoT, small VMs).

Requirements are simple: collect and store, no heavy analytics.

Budget is limited and a lightweight solution is needed.

Prefer ELK/Loki When

Full‑text search, complex queries, and visual dashboards are required.

Large‑scale microservice architectures generate massive log volumes.

Cross‑service correlation (trace IDs) and real‑time alerting are essential.

In practice the two can be combined: use Syslog for device and audit logs, and ELK/Loki for application logs that need fast search.

Best Practices

Prefer TCP (or RELP) over UDP for reliable delivery.

<appender name="SYSLOG_TCP" class="ch.qos.logback.classic.net.SyslogAppender">
    <syslogHost>192.168.1.10</syslogHost>
    <port>514</port>
    <facility>LOCAL1</facility>
    <useExactLine>true</useExactLine>
</appender>

Configure log rotation (e.g., logrotate) to avoid unbounded growth:

/var/log/remote/*/*.log {
    daily
    rotate 30
    compress
    delaycompress
    missingok
    notifempty
    create 0640 syslog syslog
}

Always use UTC timestamps (RFC 5424 requires UTC) to avoid time‑zone confusion.

For structured data, embed JSON in the MSG field:

log.info("User action: {}", objectMapper.writeValueAsString(Map.of(
    "userId", 12345,
    "action", "login",
    "ip", "192.168.1.100")));

Set appropriate log levels – send only INFO and above to the Syslog server, keep DEBUG locally.

<root level="INFO">
    <appender-ref ref="SYSLOG"/>
</root>

<logger name="com.example" level="DEBUG" additivity="false">
    <appender-ref ref="FILE"/>
</logger>

Secure transport with TLS when logs contain sensitive information.

# rsyslog TLS example
module(load="gtls")
input(type="imtcp" port="6514")
action(name="tls-input" type="omrelp" target="server.example.com" port="6514" tls="on" tls.authMode="x509/name")

Conclusion

Syslog is not a flashy, cutting‑edge technology, but its simplicity, stability, and universal support make it a practical choice for many logging scenarios. When the requirements are modest or when you need to ingest logs from a wide range of network devices, Syslog remains a reliable, low‑cost solution.