Monitoring

Monitoring here is agentless: nothing installs on servers, no extra ports open. The app keeps one SSH connection per monitored VM and runs exactly one read-only command per poll cycle.

Enable for a VM

Open the VM’s Monitoring tab, then:

1. Toggle Enable.
2. Choose the credential to use for polling — should be a low-privilege account, see Credentials.
3. Set the interval (seconds). 60 seconds is a reasonable balance for most cases.

Polling starts within about 15 seconds — a background monitoring task periodically checks which VMs are enabled and matches them to running tasks. Toggling off stops the task within the same timeframe.

The Poll now button runs one immediate cycle without waiting for the next scheduled one.

Vault Locked Means Monitoring Stops

Polling needs credentials, and credentials live in the vault. So:

• Lock vault → all polling tasks stop.
• Unlock vault → tasks restart automatically.
• Lock screen → no effect, polling continues normally.

Collected Metrics

Group	Content
System load	Uptime, 1-minute load average, CPU percent
Memory	RAM used/total, swap used/total
Disk	Per mount: used, total, percent
Network	Receive/transmit rate in bytes per second
Processes	Top six CPU consumers
Security	Listening ports, accounts, authorized SSH keys, sudoers, login log

CPU percent and network rate are derived between consecutive polls — so the first poll after enabling monitoring won’t have these two values.

History and Retention

• Raw samples are kept 14 days, then cleaned up.
• Meanwhile, data is aggregated into daily summaries and kept long-term. Monthly reports read from this summary table, not raw samples — if they read samples, a “monthly report” would silently include only two weeks.

The monitoring tab draws graphs from the 14-day raw sample window.

When the Server Does Not Respond

One missed poll is normal. Two consecutive failures mark the VM unreachable and create an event.

After each failure, the poll interval backs off gradually (maximum 5 minutes) to avoid hammering a dead machine. When it recovers, the interval returns to normal and a recovery event is recorded.

Probe Command

This is what you’ll need when the customer asks “what does your software run on our server”. The command is a constant in the source code, never assembled from user data, and the app displays it verbatim (button View probe command in the monitoring tab).

LC_ALL=C; export LC_ALL
echo '@@VMOPS:uptime@@';  cat /proc/uptime
echo '@@VMOPS:load@@';    cat /proc/loadavg
echo '@@VMOPS:cpu@@';     grep '^cpu ' /proc/stat
echo '@@VMOPS:mem@@';     grep -E '^(MemTotal|MemFree|MemAvailable|Buffers|Cached|SwapTotal|SwapFree):' /proc/meminfo
echo '@@VMOPS:net@@';     cat /proc/net/dev
echo '@@VMOPS:disk@@';    df -P -k
echo '@@VMOPS:procs@@';   ps -eo pcpu,pmem,comm --sort=-pcpu | head -6
echo '@@VMOPS:ports@@';   ss -H -tuln || netstat -tuln
echo '@@VMOPS:users@@';   cut -d: -f1,3,7 /etc/passwd
echo '@@VMOPS:keys@@';    # readable authorized_keys file contents
echo '@@VMOPS:sudoers@@'; cat /etc/sudoers /etc/sudoers.d/*
echo '@@VMOPS:auth@@';    journalctl -u sshd  # or /var/log/auth.log
echo '@@VMOPS:fail2ban@@'; fail2ban-client status sshd
echo '@@VMOPS:end@@'

Four principles behind this design:

One round trip. Every poll is exactly one sh -c returning a single delimited blob. Monitoring 30 machines a minute must not mean 300 exec channels.

Read /proc, not top. The output of top, vmstat, and free changes between distributions and locales; /proc does not.

Fixed and auditable. The command is never assembled from input data — there is no surface for command injection, and its content is always inspectable.

Degrade, never break. Anything needing root that isn’t available comes back empty, and the rest of the poll still lands.