Log sender: what matters from a host's own logs

The Oversight log sender is a small program that reads a Linux host's own logs, picks out the lines that matter using rules you write, and sends just those to Oversight every five minutes, where they appear on the Logs page. Who logged in. Which addresses fail2ban banned. What a nightly job reported. It reads log files, the systemd journal, or whatever is piped into it, and it can run as a service or once from cron.

Each thing it sends is a channel, with a name of its own, such as secure or fail2ban, and its own rules. One host can send several channels; each is its own service, with its own config.

For syslog from a site's routers and switches, use the Syslog sender instead. The two share the rules, the limits and the Logs page.

Flavours

Most hosts want the same few things, so they come ready-made, as flavours, and GEN adds more as they are asked for:

Installing is one command, as root, naming the flavours wanted. A host without the log a flavour reads skips it, so one command can name every flavour for a whole estate. For each one, the install finds the log, writes the channel's rules (keeping any you have already edited), makes the log readable by the sender the way the host already intends, checks that log rotation keeps it that way, labels what it wrote where SELinux is enforcing, and starts a service that follows the log through rotation.

The first install on a host prints a token, which GEN registers against your account; until then Oversight refuses what the host sends. A host has one token whatever it sends, shared by every channel on it and a syslog sender there, so a host is registered once.

Worked example: fail2ban

fail2ban's log is mostly noise: every address it notices, every jail starting, every ban it restores when it restarts. What matters is the bans and unbans:

2026-10-15 09:12:01,234 fail2ban.actions        [1234]: NOTICE  [sshd] Ban 203.0.113.7
2026-10-15 09:22:01,301 fail2ban.actions        [1234]: NOTICE  [sshd] Unban 203.0.113.7

The fail2ban flavour sends those two, in any jail and at any level, and nothing else. Found, already banned, start-up chatter and Restore Ban stay on the host.

Each line arrives in Oversight with its rule's name, so the Logs page can show just the bans. On a host whose SSH faces the internet that can be a few hundred a day.

Worked example: who logged in

The login log is mostly failed attempts by strangers, and housekeeping: cron opening sessions every minute, sudo, systemd starting each user's session. What matters is who actually got in:

Oct 15 12:52:22 mail sshd-session[56905]: Accepted password for root from 172.16.128.40 port 52499 ssh2
Oct 15 09:06:02 mail su[3401]: pam_unix(su-l:session): session opened for user root(uid=0) by richard(uid=1000)

The secure flavour sends successful SSH logins by any method, su, logins at the console and logins to Cockpit, each under its own rule: ssh, su, console, cockpit.

Two things are worth knowing:

• Newer OpenSSH logs each connection as sshd-session, not sshd: AlmaLinux 9 does now. The rule takes either. A rule written for one alone misses every login on the other, silently.
• sudo is left out on purpose. It is logged for every command, and a host run by scripts or Ansible would send thousands. A rule of your own can send it all the same.

A machine that logs in all day by itself, a backup server say, can be kept out with an exclude rule. On a host that keeps its logs only in the journal, minimal Debian 12 for one, the flavour reads the journal instead, and the same rules work.

Your own channel

Anything else is a channel of your own: a name, where to read, and rules. It can follow an application's log file through rotation, or the systemd journal for one service, and Oversight can be told how often to expect it, so GEN is told if it stops. A channel with no rules at all sends every line, for input that is already exactly what should go.

The sender does not have to run all the time, either. Given a file, or something piped into it, it reads to the end, sends what matches and stops, so a job that produces a short report each hour can send it from cron as a channel, and a job that stops running is noticed.

Rules can be tried before they are relied on: a dry run over a log that is already there prints what each rule would have sent, a month of logins in a second, and sends nothing.

Things to know

• Log rotation is followed whichever way it is done: renamed and recreated, or copied and emptied in place. A log that is deleted is waited for, and read from its start when it comes back.
• Permission is the commonest fault: the service runs as oversight, and many logs are root's alone. The journal says permission denied and names the file. Once it is put right, the sender carries on from that moment, without sending the log's history.
• Limits, which no config can raise: a batch covers at least five minutes and holds at most 8,192 lines of up to 4KB each. Lines beyond the limit are counted, and the Logs page shows the batch in orange. Batches that cannot be sent wait an hour on the host, then are counted and shown as a gap.
• Only plain text goes. Accented letters and anything that is not plain ASCII are taken out of a line before the rules see it.