Syslog config generator

Guide

Forwarding syslog, three ways

Getting logs off a machine and onto a central collector is the same idea everywhere — choose what to send and where to send it — but the syntax differs by platform. The generator above covers the three you are most likely to meet. The notes below explain what each generated config is doing so you can adapt it with confidence.

rsyslog

rsyslog, the default on most modern Linux distributions, uses a compact selector syntax: a facility.severity pattern followed by a destination. Forwarding to a remote host looks like this:

*.info @10.0.0.10:514

The *.info selects every facility at severity info and above. The @ means UDP; double it to @@ for TCP. Drop the file in /etc/rsyslog.d/ with a numeric prefix like 60-forward.conf so it loads in order, then restart the service. For reliability you can raise the action resume retry count so messages queue when the collector is briefly unreachable instead of being dropped.

syslog-ng

syslog-ng takes a more explicit, object-oriented approach. Rather than one terse line, you declare named building blocks and then connect them in a log statement:

• source — where messages come from, e.g. system() and internal().
• filter — optional tests such as level(info..emerg) or facility(auth).
• destination — a network() block with the host, transport, and port.
• log — the statement that ties a source, any filters, and a destination together.

It is more typing than rsyslog for a single rule, but the structure pays off as routing grows, because each piece is named and reusable. Reload with syslog-ng-ctl reload after editing.

Cisco IOS

Network gear configures logging with a handful of logging commands entered in configuration mode. The essentials the generator emits are:

• logging host <ip> — the collector to send to, optionally with a transport and port.
• logging trap <level> — the minimum severity, using Cisco’s own keyword set (emergencies, alerts, critical, errors, warnings, notifications, informational, debugging).
• logging facility <facility> — the facility tag to stamp on messages, often a local slot.
• service timestamps log datetime msec — so each message carries a precise, millisecond timestamp.

Finish with end and write memory to persist the configuration across reboots. Cisco severity keywords line up exactly with the standard 0–7 scale — see the PRI calculator for the mapping.

Ports and transport

The traditional syslog port is 514 for both UDP and plain TCP; syslog over TLS conventionally uses 6514. UDP is the historical default and is fine for high-volume operational logs where losing the occasional packet does not matter. For anything you must not lose — audit trails, security events — prefer TCP so the transport retransmits dropped packets and tells you when the far end is down. Whichever you choose, make sure the path and any firewalls permit that port, and that the receiver is actually listening on it.

Once messages are flowing, the syslog parser is handy for confirming the collector is receiving well-formed lines, and the JSON and CEF converter helps when the next hop is a SIEM rather than a plain file.