Use case / syslog-ng

syslog-ng Centralized Logging for Linux Syslog

syslog-ng centralized logging sends Linux syslog from servers to a central syslog receiver with explicit source, filter, parser, destination, and log routing. Fluxtail receives those syslog messages into streams and keeps them readable with live tail, filters, facets, histograms, alerts, MCP diagnostics, and AI chat.

syslog-ng centralized logging syslog-ng forwarding Centralized syslog Linux syslog

Start free View pricing

Route syslog explicitly

syslog-ng uses source, filter, parser, destination, and log blocks so forwarding rules stay visible and controlled.

Forward over TCP or UDP

Use a network() destination to send Linux syslog to a central receiver host and port.

Validate before restart

Run syslog-ng -s to catch syntax problems before changing the running service.

Read logs in one place

Fluxtail streams, live tail, filters, facets, histograms, and alerts help inspect forwarded syslog.

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

You want explicit routing blocks

Use syslog-ng centralized logging when source, filter, parser, destination, and log path configuration should stay visible and controlled.

02

Linux syslog needs a central receiver

Forward local Linux syslog without replacing existing host behavior. syslog-ng can keep local routing while Fluxtail provides the central receiver, stream, filters, and alerts.

03

Only selected messages should be forwarded

Use syslog-ng filters when only certain facilities, severities, programs, hosts, or message patterns should reach the central stream.

Centralization

What syslog-ng Centralized Logging Solves

syslog-ng centralized logging keeps Linux syslog searchable outside the local host while preserving the explicit routing rules that syslog-ng is good at.

01

Local files are fragile

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

02

Routes stay visible

source {}, filter {}, parser {}, destination {}, and log {} blocks make it clear which messages are read, changed, filtered, and forwarded.

03

Central reading stays separate from local routing

syslog-ng keeps host-side routing explicit. Fluxtail receives the forwarded records and provides streams, live tail, filters, facets, histograms, and alerts.

Routing

How syslog-ng Routing Works

A syslog-ng route is built from named blocks. The log statement connects the blocks into the actual path messages follow.

01

source {}

Reads local system logs, files, sockets, or network input.

02

filter {} and parser {}

Selects messages by level, facility, program, host, or content. Parsers can extract fields when messages need more structure.

03

destination {} and log {}

The destination sends messages to a file, socket, network endpoint, or other target. The log block connects source, filter, parser, and destination.

syslog-ng route shape

text

1source -> filter -> parser -> destination -> log path

Fields

Fields to Preserve From Linux Syslog

Centralized syslog is easier to search when important fields survive forwarding.

01

Keep the syslog envelope

Preserve timestamp, hostname, program or app name, process ID, facility, severity, message, and structured data when available.

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

Keep receiver context separate

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

Transport

TCP, UDP, and Receiver Transport Settings

syslog-ng network() destinations can forward with tcp or udp. Match protocol, port, and transport settings to the central receiver.

01

Use TCP when delivery feedback matters

TCP is commonly preferred when message loss matters and the receiver supports it.

02

Use UDP for simple compatibility cases

UDP is simple and widely supported, but can drop messages under network pressure.

03

Keep templates consistent

Use a consistent template so the receiver can preserve timestamp, host, app, severity, facility, and message.

Config

Example syslog-ng forwarding config

This example reads local Linux syslog, filters selected messages, and forwards them to a central syslog receiver. Replace host, port, protocol, and transport settings with your receiver values.

syslog-ng forwarding route

config

1# /etc/syslog-ng/conf.d/60-fluxtail-forwarding.conf
2 
3source s_local_system {
4  system();
5  internal();
6};
7 
8filter f_fluxtail_forward {
9  level(info..emerg);
10};
11 
12destination d_fluxtail_syslog {
13  network(
14    "logs.example.com"
15    port(10514)
16    transport("tcp")
17    template("<$PRI>1 $ISODATE $HOST $PROGRAM $PID $MSGID $SDATA $MSG\n")
18  );
19};
20 
21log {
22  source(s_local_system);
23  filter(f_fluxtail_forward);
24  destination(d_fluxtail_syslog);
25};

Match host, port, protocol, and transport settings to the receiver.

Validate and restart syslog-ng

bash

1sudo syslog-ng -s
2sudo systemctl restart syslog-ng
3sudo systemctl status syslog-ng --no-pager
4sudo journalctl -u syslog-ng -n 100 --no-pager

Validate before restart, then check the service and journal for destination or connection 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 or select a syslog receiver

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

02

Add a syslog-ng destination

Use network() to forward matching Linux syslog messages to the receiver.

03

Connect source, filter, and destination

Use a log {} block so selected local messages reach the central syslog receiver.

04

Validate, restart, and test

Run syslog-ng -s, restart syslog-ng, then use logger to emit a known message with a facility, severity, and tag.

05

Read the stream in Fluxtail

Open the target stream and confirm live tail, filtering, facets, histograms, and alerts use the forwarded fields.

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 syslog-ng sender check

bash

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

02

Check local sender health

Confirm syslog-ng validates, the service is running, and the journal shows no destination or connection errors.

Local syslog-ng checks

bash

1sudo syslog-ng -s
2sudo systemctl status syslog-ng --no-pager
3sudo journalctl -u syslog-ng -n 100 --no-pager

03

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.

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.

Set up rsyslog centralized logging with syslog forwarding, omfwd, queues, test messages, and readable Linux syslog streams in Fluxtail.

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.

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

syslog-ng Centralized Logging for Linux Syslog

When this source should be centralized

You want explicit routing blocks

Linux syslog needs a central receiver

Only selected messages should be forwarded

What syslog-ng Centralized Logging Solves

Local files are fragile

Routes stay visible

Central reading stays separate from local routing

How syslog-ng Routing Works

source {}

filter {} and parser {}

destination {} and log {}

Fields to Preserve From Linux Syslog

Keep the syslog envelope

Keep receiver context separate

TCP, UDP, and Receiver Transport Settings

Use TCP when delivery feedback matters

Use UDP for simple compatibility cases

Keep templates consistent

Example syslog-ng forwarding config

How logs move into Fluxtail

Create or select a syslog receiver

Add a syslog-ng destination

Connect source, filter, and destination

Validate, restart, and test

Read the stream in Fluxtail

What to check before relying on it

Confirm the first forwarded row

Check local sender health

Check filtering and grouping

Add alerts and diagnostics after the stream is stable

Related pages

Send one real source and read the logs