Syslog sender: collecting a site's syslog

The Oversight syslog sender is a small program that runs on one Linux machine at a site and collects the syslog from every device on its LAN: routers, switches, firewalls, UPS cards, other servers. It keeps everything it receives in a file per day on that machine, picks out the few lines that matter using rules you write, and sends just those to Oversight every five minutes. They appear on the Logs page, under the channel syslog.

That split is the point of it. A normal site sends hundreds of thousands of syslog lines a day, nearly all of it firewall logging, logins by monitoring systems and routine chatter. None of that crosses the internet. On a good day nothing at all is shipped; on a bad one, the loop warning, the switch that rebooted itself or the port flapping between 10M and 1G is in Oversight within five minutes, with the full day's record still on the site if you need to look further.

It needs no rsyslog, syslog-ng or logrotate: it has its own listener, writes and rotates its own files, and only ever connects out to Oversight, over HTTPS. For a host's own log files, such as fail2ban's or the login log, see Log sender; the rules are the same.

How it is installed

It goes on one Linux machine at the site that is always on and that the devices can reach: a server, a VM or a small box. It is installed with one command, as root, which checks the build against its published checksum and starts it as a service under an unprivileged user that may listen on the syslog port and do nothing else. It never needs root once installed, and the same command upgrades it later, leaving its settings alone.

The install prints a token, which GEN registers against your account. Until it is registered, Oversight refuses everything the sender uploads. A machine that already runs a log sender keeps the token it has.

Keep the machine's syslog port to the LAN. Syslog has no authentication, and the sender trusts the address a line came from.

What sends to it

Anything that can send syslog: MikroTik routers and switches, Linux servers through their own rsyslog, and the switches, firewalls, NAS units and UPS cards that have a syslog server setting somewhere in their web interface. There is no need to send a router's own firewall logging, which is the bulk of any router's syslog and is better left on the router.

Windows has no syslog of its own. The Oversight Windows agent sends the event log on, with each event's log, provider, ID and level as fields in the line, so a rule can pick out failed logons on a domain controller or services that crashed by name.

What it keeps on the site

Everything received goes into a file per day by UTC date, one line per message:

2026-10-14T23:56:52.914Z 172.16.128.254 udp interface,warning ether8 - CRS317 Switch excessive broadcasts/multicasts, probably a loop

That is when it arrived, which device sent it, how, and the message exactly as received. After midnight the day before is compressed, and by default files older than 90 days are deleted; some customers keep every file for ever and copy them off to their own storage. This is the place to go when something in Oversight needs its context.

The rules

Each line is tested against the exclude rules first, and dropped if any matches. Then the include rules, in order: the first that matches sends the line, and its name goes with it to Oversight. A line no include rule matches is not sent. A rule can name the devices it applies to, by address or range, the message's severity and facility, and words to look for, as a regular expression. Aim for a normal day to send nothing: the routine is better watched by sensors.

MikroTik devices send no severity at all, so a severity rule never matches them; their rules match the words at the front of the line instead, such as interface,warning.

At a real site, a MikroTik router and switches with a few Linux servers, checked against a full day of its traffic, seven include rules and three excludes send a loop warning, link changes and real VPN failures, and nothing else. The excludes take out what would otherwise match: the router's firewall logging, internet scanners knocking on its VPN port, and password guessing.

Rules can be tried against the live traffic before they are relied on. A dry run shows each line a rule would send the moment it matches, with a count for each rule, and sends nothing.

In Oversight

The Logs page shows each channel's lines, newest first, for today unless a longer range is chosen, filtered by device, rule, severity and words in the message. It shows at most the 2,000 newest that match; to see older ones, narrow the filter. Export CSV gives every matching line. Your users need the Logs permission, under Setup, Users.

A device that matches a device in your tree by address is shown by that device's name. Below the lines is every device the sender has heard from, with how many lines it sent today and how many of them were shipped, with the percentage. Some logs are worth sending whole, so this is a figure to check the rules against, not a warning.

The page also says when the rules need attention:

• Lines dropped at the limit, in orange: more than 8,192 lines matched in five minutes, and the rest were not sent. A rule is far too broad.
• A config fault or disk full, in red: the sender is sending nothing until it is put right.
• Gaps, among the lines: a stretch when nothing was received, so a silence is never mistaken for a quiet spell.

GEN is told if a sender stops uploading for three intervals.