What should Linux server monitoring cover, and how do you set it up?

A Linux box fails in a handful of ways, and each one leaves a different trace. Monitoring that only graphs CPU and memory misses most of them. The full list is short:

• •Host resources: CPU, memory and swap, load average, disk space and inodes per mount, disk I/O latency, and the kernel log for failing disks
• •Services: every systemd unit, Docker container and PM2 process, its state, restart count and the moment it stopped
• •Logs: nginx, Apache, PHP-FPM, Laravel, Docker and journald errors, clustered by pattern so a new error stands out
• •Network and security: listening ports and which process owns them, a database port open to the internet, failed SSH logins, root login, the firewall state, pending security updates
• •Domains and certificates: every virtual host, its SSL expiry and whether the site answers
• •Changes: package installs and upgrades, config edits, deploys and kernel updates in the hours before an incident

The last item is the one most tools skip, and it is the one that answers "what happened?". An error spike that started three minutes after a package upgrade is a different incident from one that started on its own.

Agentless monitoring reads a server over SSH or SNMP from the outside. It needs credentials stored centrally, an inbound path to every server, and it sees only what the protocol exposes. An agent runs on the box as a small service, reads local facts directly (systemd, the Docker socket, log files, the kernel log) and sends them out over HTTPS.

For Linux servers that run applications, an agent is the practical choice: it discovers services and log sources without being told about them, keeps working behind NAT and on private subnets, and opens nothing inbound. The things to check are that it is read-only by default, signs what it sends, never reads application secrets, and is small enough not to matter (the Opservo agent is one 11 MB Go binary).

The honest split: if your job is to read dashboards, Netdata or Prometheus give you the most to read. If you are a developer who is also on call, you want the conclusion, not the data.

With Opservo, the install is one command on each server. The agent registers, discovers what is running and sends its first snapshot within a minute. No config file, no inbound ports, no credentials to store.

curl -sSL https://api.getopservo.com/install.sh | sudo bash

A few minutes later the server page shows its health score, the findings that cost points, each with the command that fixes it, every service and container, the virtual hosts with certificate expiry, listening ports, MySQL, Redis and PostgreSQL facts, and the errors from its logs clustered by pattern. Adding Slack, email, Telegram or a webhook routes critical findings to you.

• •Alert now: a service down, a disk under 10 percent or forecast to fill, a failing disk, a certificate expiring within 7 days, a site that fails an external check twice in a row, a database port that just opened to the internet
• •Digest, never page: CPU at 80 percent, a single 5xx, a container that restarted once, anything that cleared itself
• •Use learned baselines for traffic-driven numbers so a busy day does not page anyone
• •When one cause explains several symptoms (a full disk takes down MySQL, which breaks the app), get one alert for the cause with the symptoms under it, not five

A dashboard shows you numbers and leaves the interpretation to you. Monitoring that explains itself states what is wrong, why, what changed, and what to run. Opservo does that with a deterministic health score first (named rules with thresholds, no model involved) and AI on top for the "why" and the fix, grounded in the live snapshot of that server. On servers where you turn remote actions on, the fix runs from the dashboard with a confirmation and an audit record.