Alerts & Drift Detection

Guiding principle throughout this section: an alert list nobody trusts is worse than having no alerts. So the rule count stays low, and events only happen when state transitions — a disk stuck at 91% for a week is one event, not ten thousand.

Three Event Types

Type	When it fires
threshold	A resource metric exceeds a threshold you set.
drift	Security-related config changed from the previous poll.
reachability	VM stopped responding, or started responding again.

Each event has level info, warning, or critical, plus a short title and detailed description.

Resource Thresholds

Set in Settings. Four thresholds: disk warning, disk critical, RAM, and CPU.

Disk alerts immediately when exceeded. RAM and CPU must exceed across several polls before alerting — a CPU spike lasting one minute during a backup isn’t worth waking someone up.

Disk Fullness Forecast

Static thresholds say very little about urgency. 80% that hasn’t budged in a year needs no one’s attention; 60% that jumped ten points this week needs someone to act today.

The app fits a linear regression through the last seven days of data for each mount and extrapolates to when it fills. Result displays as “about N days left”.

This extrapolation refuses to answer rather than guess, when:

• there are fewer than 6 samples or data spans less than 6 hours;
• the trend is flat or declining (mount being freed);
• the result is farther than 365 days — “it will fill eventually” is not news.

Forecasts recalculate at most hourly per VM, since they must read a week of history.

The model assumes growth rate stays constant. It’s wrong for log rotation and wrong for databases that double overnight. Read it as a priority indicator, not a promise.

Drift Detection

Four items are compared to the previous poll. These are the real footprints an attacker leaves:

Item	Changes detected
keys	authorized_keys — SSH keys added or removed
users	/etc/passwd — new accounts, shell changes
ports	Listening ports — new services exposing outward
sudoers	/etc/sudoers and /etc/sudoers.d/*

Most changes are legitimate: a colleague adds their key, a new service gets deployed. The value is knowing it happened and when — instead of discovering it six months later.

SSH Login Review

When the poll account can read the auth log, the app summarizes:

• Successful logins — user, IP, method, timestamp.
• Failed by IP — ranked by count, most first.
• IPs under block — read from fail2ban if present.
• Familiar networks — subnets each user typically logs in from.

The “familiar networks” part is the most useful here: a successful login from an unfamiliar subnet stands out far more than thousands of failures from the Internet — failures are par for any server exposed to the net.

Logins outside business hours are flagged, not turned into alerts on their own. Plenty of legitimate work happens at night.

Acknowledge Alerts

The alert center lists events most recent first. Mark acknowledged one at a time or all at once; the status bar count only shows unacknowledged ones.

Events are never deleted when you acknowledge them, and are not cleaned up by the 14-day metric data retention — they are kept long-term and feed into monthly reports.

System Notifications

Critical-level events push an OS notification so you see them even if the app window is obscured. Disable/enable in the notification settings of your OS itself.