Agentless server monitoring over SSH: how far it goes
What you can learn about a Linux server with nothing installed on it: the read-only commands, how to forecast a full disk, and where agentless monitoring stops.
On this page
Agent or no agentWhat you can read with plain commandsRun a check without leaving a traceFrom a snapshot to a forecastStop signals from flappingWhere agentless stopsHealth in Gatesys SSHFAQMost monitoring starts with installing something: an exporter, a collector, an agent with root. There are servers where that is not yours to decide. A customer’s machine, a locked-down production box, a host you were given a login to for a week. On those, all you have is SSH. It turns out to be enough for a surprising amount, and this article shows how much, and where it runs out.
Agent or no agent
| With an agent | Agentless, over SSH | |
|---|---|---|
| Installed on the server | A daemon, often as root | Nothing |
| Runs when you are away | Yes | No |
| History | Weeks or months | From the moment you connect |
| Alerts at 3 a.m. | Yes | No |
| Needs a change request | Usually | No. It is the commands you would type anyway |
| Sees | Whatever it is built to export | Whatever your login may read |
They answer different questions. An agent answers what happened last Tuesday and wake me if it happens again. Agentless monitoring answers what is wrong with this box, right now, while I am looking at it.
What you can read with plain commands
Every command below is read-only and needs no root.
| Question | Command |
|---|---|
| How loaded is it? | cat /proc/loadavg and nproc. Load above the core count means work is queueing |
| Is memory short? | free -m. Read the available column, not free |
| Which disk is filling? | df -h -x tmpfs -x devtmpfs |
| Out of inodes? | df -i. A disk can be full with space to spare |
| What is eating the CPU? | ps -eo pid,user,pcpu,pmem,rss,etimes,comm --sort=-pcpu | head |
| Is it waiting on disk? | vmstat 1 5. The wa column is I/O wait |
| Did anything fail? | systemctl --failed --no-legend |
| Was a process killed for memory? | journalctl -k --since -1d | grep -i "out of memory" |
| What is listening? | ss -tln |
| Are containers unhealthy? | docker ps -a --filter health=unhealthy |
| Is a reboot pending? | cat /var/run/reboot-required on Debian and Ubuntu; needs-restarting -r on the RHEL family |
| Is the clock right? | timedatectl show -p NTPSynchronized --value |
| When does the certificate expire? | openssl x509 -enddate -noout -in /path/to/cert.pem |
Some answers depend on who you are. Without the docker group you cannot list containers, and on many systems the kernel log is closed to ordinary users. The honest result then is not visible to this login, never nothing is wrong.
Run a check without leaving a trace
Put the commands in a file on your own computer and send it down standard input:
ssh deploy@server 'sh -s' < healthcheck.shNothing is written to the server, nothing lands in the shell history, and the script runs as your own login with your own permissions. The server’s audit tools still see a short sh process, which is as it should be.
From a snapshot to a forecast
A snapshot says /var is 81% full. The useful question is when it reaches 100%. That takes two readings and a ruler.
Say /var is 100 GB. An hour ago 78 GB were used, and now 81 GB are. It grows 3 GB an hour, 19 GB are left, so it is full in a little over six hours. Make the fit over several points and you can also say how well a straight line describes them.
Three rules keep forecasts honest:
- No forecast from too little data. Two points a minute apart describe a blip. When the points are few, or do not sit on a line, show no estimate.
- Warn on time left, not only on percentage. A disk at 70% that fills in two hours matters more than one that has sat at 92% for a year.
- A fixed threshold still has its place. At 97%, the trend no longer matters.
The same arithmetic finds a memory leak: a process whose resident memory climbs in a straight line across ten minutes of samples is going to meet the limit at a time you can calculate.
Stop signals from flapping
A reading that hovers at a threshold turns an alert on and off every few seconds, and soon nobody reads it. Two habits fix that:
- Require persistence. Raise a signal after two checks over the line in a row, not one.
- Use two lines. Raise at 80% and clear only below, say, 75%, and only after several checks in a row without it.
Where agentless stops
Be clear about the limits before you rely on it.
- It sees only while connected. Close the laptop and the watching ends. There is no record of the night.
- It cannot page you. No connection, no alert.
- It is not free of footprint. The commands are light, but they are processes on the server. Poll gently: a
psevery ten seconds while something is hot, adfonce a minute. - Security tools will notice. A short
shandpstree is exactly what auditd and an EDR are built to record. That is correct behaviour. Tell your security team what to expect.
For a fleet with on-call rotas and SLOs, you want a monitoring stack: Prometheus with node_exporter, Netdata, Zabbix or a hosted service. Agentless checks do not replace it. They cover the servers the stack does not reach, and the moment when you are already in a shell and want to know what is going on.
Health in Gatesys SSH
Health in Gatesys SSH is this article as a feature, on the free plan. It reads the metrics the terminal header already samples, plus a few read-only commands over the SSH session you opened, and works out every signal on your computer with fixed rules. Nothing is installed on the server, and no model is involved.
| Kind | Example |
|---|---|
| Resource hogs | java pid 2211 at 340% CPU for 6 min |
| Forecasts | /var full in ~3 h, from a straight-line fit over the last hour. Raised when the fill is due within 24 hours |
| Memory leaks | A process whose resident memory climbs steadily, with its growth per hour |
| Saturation | Load above the core count, I/O wait, swap that is growing |
| Unusual for this hour | CPU 71% — usually 8–22% at this hour, learned per host |
| Events | An out-of-memory kill, a failed systemd unit, an unhealthy container |
| Pending risks | A kernel waiting for a reboot, a clock that drifted, a certificate near expiry |
Each signal card says what happens if you ignore it and when, shows the measured values behind it, and offers read-only commands to look closer. A signal is raised only after two checks, and clears only after three without it. With too little data, no estimate is shown.
The sampling is what this article recommends: one ps at most every ten seconds, only while CPU or memory is hot or the panel is open, and a df once a minute, on a background channel of your own session.
With Pro, the Farabi assistant explains a signal as numbered claims, each citing a measured line, and a claim that cites nothing measured is dropped. The signals themselves stay free. And the limits above apply here too: Health watches while Gatesys SSH is connected. It is not a pager.
FAQ
What is agentless monitoring?
Monitoring that installs nothing on the machine being watched. The monitor connects over a protocol the server already speaks, usually SSH, and runs read-only commands to collect what it needs.
Is it safe to run health checks on a production server over SSH?
Read-only commands such as df, ps and ss are what administrators run by hand all day. Keep the polling gentle, run as an unprivileged login, and let your security team know what the process tree looks like.
Can agentless monitoring replace Prometheus or Datadog?
No. It has no history from before you connected and it cannot alert when you are away. It complements a monitoring stack, and covers hosts where you may not install one.
How do I predict when a disk will be full?
Take the used space at several moments, fit a straight line, and divide the free space by the growth rate. Trust the result only when you have enough points and they sit close to the line.
Does Gatesys SSH install anything on my servers?
No. Health and host facts are read over the SSH session you opened, as your own login, from a fixed list of read-only commands. See what runs on the server.
