Fluxtail
Sign in Start free
Feature / Syslog

Syslog Server for Live, Centralized Syslog Collection

Fluxtail acts as a central syslog server for hosts, VMs, appliances, routers, firewalls, rsyslog, syslog-ng, and legacy services. Create a syslog receiver, point senders at the assigned host and port, then inspect live rows by host, app, severity, message, and time.

Syslog server rsyslog syslog-ng Centralized syslog
Start free View pricing
Central syslog collection

Point existing syslog senders at a Fluxtail receiver, then route the resulting rows into a stream built for reading and filtering.

Fields operators search

Keep timestamp, host, app, severity, facility, stream, receiver, and message visible enough to narrow quickly.

Works beside other log sources

Syslog can sit beside HTTP apps, collectors, OpenTelemetry logs, OTLP pipelines, and GELF senders in the same account.

Analysis after live tail

Use filters, facets, histograms, alerts, MCP diagnostics, and built-in AI chat once the syslog rows are arriving.

Setup proof

Forward syslog into Fluxtail, then verify the stream

Use the host, port, and transport shown by your Fluxtail syslog receiver. Start with one sender, confirm the row shape, then expand the source list.

Fluxtail live tail showing active log rows in the product.

Minimal rsyslog forwarding shape
config
1# Replace host, port, and transport with the values shown by your Fluxtail receiver.
2action(
3    type="omfwd"
4    protocol="<receiver-transport>"
5    target="<your-fluxtail-syslog-host>"
6    port="<your-fluxtail-syslog-port>"
7    queue.type="LinkedList"
8    queue.filename="fluxtail-fwd"
9    queue.saveonshutdown="on"
10)

The queue settings are sender-side rsyslog resilience. Match transport, host, and port to the receiver values Fluxtail shows.

syslog-ng destination shape
config
1destination d_fluxtail {
2  network(
3    "<your-fluxtail-syslog-host>"
4    port(<your-fluxtail-syslog-port>)
5    transport("<receiver-transport>")
6  );
7};
8 
9log {
10  source(s_src);
11  destination(d_fluxtail);
12};

Keep the local syslog-ng routing you already use. The important part is sending the final destination to the Fluxtail receiver.

Fields worth preserving once the rows land
output
timestamp=2026-04-24T14:18:22Z receiver=syslog-prod stream=infra/syslog host=edge-01 app=sshd severity=info facility=authpriv message="Accepted publickey for deploy from 203.0.113.24 port 54418 ssh2"
timestamp=2026-04-24T14:18:27Z receiver=syslog-prod stream=infra/syslog host=router-01 app=firewall severity=warning facility=kern message="blocked inbound packet from 203.0.113.10"
timestamp=2026-04-24T14:18:34Z receiver=syslog-prod stream=infra/syslog host=db-01 app=postgres severity=error facility=local0 message="could not extend file: No space left on device"

Centralized syslog is useful when host, app, severity, facility, receiver, stream, and message survive the forwarding path.

Syslog collection

Collect syslog from hosts, VMs, routers, firewalls, and appliances

Use Fluxtail when you need one place to collect and inspect syslog without making every sender use a new logging library.

01

Keep existing syslog senders

This page fits infrastructure that already emits syslog: Linux hosts, VMs, routers, switches, firewalls, appliances, rsyslog, syslog-ng, and older services.

  • servers forwarding through rsyslog
  • hosts using syslog-ng routing
  • routers, switches, firewalls, and appliances
  • legacy apps that can only emit syslog
02

Route syslog into streams

Each syslog receiver can write into a Fluxtail stream so operators can filter by host, app, severity, receiver, message content, and time window.

03

Use it beside newer logs

Syslog collection can sit beside HTTP logs, OpenTelemetry logging, GELF, Kubernetes logs through collectors, and client-library events in the same account.

04

Read first, then analyze

Live tail is the first check. After that, use filters, facets, histograms, alerts, MCP diagnostics, or built-in AI chat when the pattern needs more inspection.

Verification

What to verify before calling the syslog path ready

Do not stop at “the receiver exists.” Send one known line, then confirm the row shape is still useful in the live stream.

01

Generate one known test event from a real sender

Use logger on a VM or bare-metal host you control so you can verify hostname, app name, and timestamp without guessing.

Generate a known syslog line
bash
1logger -p user.info "fluxtail syslog check $(date -Iseconds)"
What should show up in the live stream
output
2026-04-24T14:18:22Z INFO  infra/syslog edge-01 logger fluxtail syslog check 2026-04-24T14:18:22-04:00

If host, app, severity, or timestamp are already unclear here, fix the forwarding path before adding more senders.

02

Narrow by host or app before reading the whole stream

A syslog server is useful when you can cut the stream down to one sender and one short time window without exporting rows first.

Focused incident slice
output
host=edge-01 app=sshd window=14:18:00-14:19:00
2026-04-24T14:18:22Z INFO  infra/syslog edge-01 sshd Accepted publickey for deploy from 203.0.113.24 port 54418 ssh2
2026-04-24T14:18:27Z WARN  infra/syslog edge-01 sshd Failed password for invalid user backup from 203.0.113.51 port 54519 ssh2

This is the point where centralized syslog starts helping with triage instead of just moving the file somewhere else.

03

Check receiver, transport, stream, and filters

If logs do not appear, verify the receiver host, port, transport, sender reload, network path, stream selection, and active filters before changing application logging.

  • sender uses the assigned Fluxtail host and port
  • sender transport matches the receiver values shown in Fluxtail
  • rsyslog or syslog-ng was reloaded after config changes
  • the expected host appears in live tail
  • app/program names and severity are visible enough to filter
Analysis

Analyze syslog after live tail shows the rows

Once syslog rows are landing, use Fluxtail to answer the next operational question without changing the sender setup.

01

Find noisy or failing senders

Filter by host, app, receiver, stream, source IP, severity, or message text, then use facets to see which sender is producing repeated warnings or errors.

02

Compare activity over time

Use histograms to check whether firewall denies, authentication failures, kernel warnings, or appliance events changed during a short time window.

03

Use AI and MCP for specific follow-ups

Use built-in AI chat to summarize repeated syslog patterns. Use MCP diagnostics to check receiver health, find exceptions, summarize errors, or investigate why expected logs are missing.

04

Link to deeper syslog analysis

Open the syslog analyzer guide when the main task is parsing a noisy burst, isolating repeated messages, or deciding what to inspect next.

Next step

Start with a receiver, then verify the live stream

The value of a syslog server shows up once the messages land somewhere you can read, filter, and use during a real check.

Step 1

Create the syslog receiver

Create the receiver and copy the host, port, stream, and transport values shown by Fluxtail.

Step 2

Forward from rsyslog or syslog-ng

Reuse the sender tooling that already exists instead of forcing every host or appliance to run a new local collector.

Step 3

Validate the live stream

Check live rows to confirm host, app, severity, facility, receiver, stream, and message shape before adding more senders.

Step 4

Layer on investigation

Add filters, facets, histograms, alerts, AI summaries, and MCP diagnostics once the base syslog path is readable.

Related

Related pages

Related page
Log management

Centralized log management with readable live tail, clear streams, and straightforward ingest.
Related page
Syslog analyzer

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

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

Learn how OpenTelemetry logging preserves service, resource, trace, and severity context with readable Fluxtail log views.
Related page
Log aggregation

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