Use case / rsyslog

Rsyslog Centralized Logging for Linux Syslog

Rsyslog centralized logging sends Linux syslog from servers to a central syslog receiver so host logs stay searchable after local files rotate, hosts restart, or machines disappear. Fluxtail receives those syslog messages into streams and keeps them readable with live tail, filters, facets, histograms, alerts, MCP diagnostics, and AI chat.

rsyslog centralized logging rsyslog forwarding Centralized syslog Linux syslog

Start free View pricing

Forward from existing Linux hosts

Use rsyslog omfwd to send local syslog events from servers into a central destination.

Keep syslog fields readable

Preserve timestamp, host, app name, process ID, facility, severity, and message text.

Use queues for safer delivery

Rsyslog queues help absorb temporary network or receiver interruptions before messages are dropped.

Read Linux syslog centrally

Fluxtail streams, live tail, filters, facets, histograms, and alerts help inspect forwarded syslog without opening each host.

Source

When this source should be centralized

Use this path when the source already emits logs and central reading, filtering, or alerting is the next need.

01

Linux servers already run rsyslog

Use rsyslog centralized logging when hosts already emit local syslog and the next need is central search, filtering, alerting, and retention outside the host.

02

Host logs should survive rotation and rebuilds

Local syslog files are easy to lose during rotation, disk pressure, rebuilds, and host replacement. Forwarding keeps auth, cron, kernel, daemon, and application syslog available centrally.

03

A heavier collector is not required for every host

Rsyslog forwarding is enough when the source is standard Linux syslog and you mainly need a central syslog receiver, readable stream, filters, and alerts.

Centralization

What Rsyslog Centralized Logging Solves

Rsyslog centralized logging moves Linux syslog away from isolated host files and into one place where the records can be searched, filtered, and alerted on.

01

Local files are fragile

Auth logs, cron messages, kernel messages, daemon output, and application syslog can disappear during rotation, disk cleanup, rebuilds, or host replacement.

02

Many hosts need one view

Forwarding rsyslog traffic keeps SSH, sudo, cron, systemd, kernel, and service messages searchable across servers without opening a shell on each machine.

03

Standard syslog senders can stay simple

If the source already speaks syslog, rsyslog can keep local collection and forwarding simple while Fluxtail provides the central receiver, stream, filters, and alerts.

Fields

Fields to Preserve From Linux Syslog

Centralized syslog is much easier to read when the forwarded row still carries the original syslog fields.

01

Keep the syslog envelope

Preserve timestamp, hostname, app name or tag, process ID, facility, severity, and original message text.

Useful centralized syslog shape

output

timestamp=2026-04-25T14:12:30Z host=web-01 app=sshd facility=authpriv severity=notice message="Accepted publickey for deploy"

02

Add receiver context without hiding the original message

Receiver, stream, source IP, and account-level metadata help route and filter logs, but the original syslog message should remain visible.

Transport

TCP, UDP, and Queue-Backed Forwarding

Rsyslog can forward over TCP or UDP. Choose the transport and queue behavior based on the source, network, and receiver settings.

01

Use TCP when delivery feedback matters

TCP is commonly preferred when message loss matters and the receiver supports it. It gives rsyslog connection feedback and works well with queue-backed forwarding.

02

Use UDP for simple compatibility cases

UDP is simple and widely supported, but can drop messages under network pressure. Use it when compatibility matters more than delivery feedback.

03

Keep queues enabled

Linked-list or disk-backed queues help rsyslog absorb short receiver or network interruptions. Watch queue growth during outages.

Config

Example rsyslog forwarding config

This example forwards Linux syslog from rsyslog to a central syslog receiver. Replace the host, port, protocol, and transport settings with the values from your receiver.

rsyslog omfwd forwarding

config

1# /etc/rsyslog.d/60-fluxtail-forwarding.conf
2 
3module(load="omfwd")
4 
5template(
6  name="FluxtailSyslogFormat"
7  type="string"
8  string="<%pri%>1 %timestamp:::date-rfc3339% %hostname% %app-name% %procid% %msgid% %structured-data% %msg%\n"
9)
10 
11action(
12  type="omfwd"
13  target="logs.example.com"
14  port="10514"
15  protocol="tcp"
16  template="FluxtailSyslogFormat"
17  queue.type="LinkedList"
18  queue.filename="fluxtail_syslog_queue"
19  queue.size="10000"
20  queue.saveOnShutdown="on"
21  action.resumeRetryCount="-1"
22)

Match host, port, protocol, and transport settings to the receiver. Keep queueing enabled for production senders.

Validate and restart rsyslog

bash

1sudo rsyslogd -N1
2sudo systemctl restart rsyslog
3sudo systemctl status rsyslog
4sudo journalctl -u rsyslog -n 100 --no-pager

Validate the config before restart, then check the service and journal for forwarding or queue errors.

Send a known test message

bash

1logger -p authpriv.notice -t sshd "Accepted publickey for deploy from 203.0.113.10 port 53422 ssh2"

The tag, facility, severity, host, and message should be visible after the event arrives centrally.

Readable centralized syslog row

output

2026-04-25T14:12:30Z host=web-01 app=sshd severity=notice facility=authpriv Accepted publickey for deploy from 203.0.113.10 port 53422 ssh2

A readable centralized syslog row keeps timestamp, host, app, severity, facility, and the original message visible.

Setup

How logs move into Fluxtail

Keep the sender configuration explicit, then confirm the resulting stream keeps the fields needed for reading and filtering.

01

Create a syslog receiver

Create a Fluxtail syslog receiver and note the assigned host, port, protocol, stream, and receiver settings.

02

Add rsyslog forwarding config

Use omfwd to forward matching Linux syslog messages to the receiver. Prefer a clear RFC5424-style template when possible.

03

Validate, restart, and test

Run rsyslogd -N1, restart rsyslog, then use logger to emit a known message with a facility, severity, and tag.

04

Read the stream in Fluxtail

Open the target stream, use live tail, and confirm the host, app, severity, facility, and message are visible.

Verification

What to check before relying on it

Collection is useful only when the resulting rows still carry enough context to search, filter, and alert on.

01

Confirm the first forwarded row

Send a known logger message and confirm it appears in the expected Fluxtail stream with timestamp, host, app name, severity, facility, and message.

Known rsyslog sender check

bash

1logger -p local0.info -t fluxtail-test "centralized rsyslog test from $(hostname)"

02

Check filtering and grouping

Filter by host, app name, severity, facility, message text, and time window. Facets should reveal top hosts, apps, facilities, and severities. Histograms should show syslog volume over time.

03

Check local sender health

Confirm rsyslog is running, the config validates, the journal shows no forwarding errors, and queue files are not growing unexpectedly.

Local rsyslog checks

bash

1sudo rsyslogd -N1
2sudo systemctl status rsyslog
3sudo journalctl -u rsyslog -n 100 --no-pager

04

Add alerts and diagnostics after the stream is stable

Use alerts for high-severity syslog events, MCP diagnostics for receiver or stream checks, and AI chat to summarize repeated messages while the raw rows stay visible.

Use Fluxtail as a syslog server for centralized syslog collection, live tail, filters, and syslog analysis.

What a syslog analyzer should help you do: filter syslog logs by host, app, severity, and time, then summarize the selected rows.

Compare free syslog server options, what they handle, and when a hosted log reader helps.

Set up syslog-ng centralized logging with source, filter, destination, and log blocks. Forward Linux syslog to Fluxtail for live tail and search.

Watch production logs in real time with a live log viewer for readable streams, live tail, filters, and diagnostics.

Centralized log management with readable live tail, clear streams, and straightforward ingest.

Learn how log aggregation works across apps, hosts, syslog, containers, Kubernetes, OTLP, GELF, and collectors.

Next step

Send one real source and read the logs

The fastest check is to point one real source at Fluxtail and see whether the resulting stream is easier to read.

Point one real source at Fluxtail.

Create a receiver, send one source, and inspect the first stream.

Start free View pricing

Rsyslog Centralized Logging for Linux Syslog

When this source should be centralized

Linux servers already run rsyslog

Host logs should survive rotation and rebuilds

A heavier collector is not required for every host

What Rsyslog Centralized Logging Solves

Local files are fragile

Many hosts need one view

Standard syslog senders can stay simple

Fields to Preserve From Linux Syslog

Keep the syslog envelope

Add receiver context without hiding the original message

TCP, UDP, and Queue-Backed Forwarding

Use TCP when delivery feedback matters

Use UDP for simple compatibility cases

Keep queues enabled

Example rsyslog forwarding config

How logs move into Fluxtail

Create a syslog receiver

Add rsyslog forwarding config

Validate, restart, and test

Read the stream in Fluxtail

What to check before relying on it

Confirm the first forwarded row

Check filtering and grouping

Check local sender health

Add alerts and diagnostics after the stream is stable

Related pages

Send one real source and read the logs