Monitor Docker Compose over SSH, no agent

The short answer

Yes. Everything you need to understand a Docker host is readable over a normal SSH session: the Docker CLI reports containers, health and events, and the Linux kernel exposes per-container CPU, memory and I/O counters through cgroups and pressure stall information (PSI). None of it requires an agent on the server. The cost is that something has to keep asking, and it can only watch while it is connected.

What you can read without installing anything

These are all read-only. They need a user that can run docker, and that is usually membership of the docker group, which is root-equivalent on the host. No sudo is needed for the commands below on most systems.

Find a container’s cgroup

On a host that uses cgroup v2, first confirm it:

stat -fc %T /sys/fs/cgroup
# cgroup2fs means cgroup v2

Then find the container’s directory. With the systemd cgroup driver, which is the common default on current distributions, it looks like this:

id=$(docker inspect -f '{{.Id}}' web)
cd /sys/fs/cgroup/system.slice/docker-$id.scope
ls cpu.stat memory.current memory.events io.stat cpu.pressure

With the cgroupfs driver the directory is /sys/fs/cgroup/docker/$id instead. Hosts still on cgroup v1 expose different files, and PSI may be unavailable.

Read the counters

cat cpu.stat           # usage_usec, nr_throttled, throttled_usec
cat memory.events      # high, max, oom, oom_kill
cat /proc/pressure/io  # some avg10=0.00 avg60=0.00 avg300=0.00 total=...

Most of these are cumulative counters, so a single reading says little. Sample twice and compare, or keep a history so you can tell what is normal for that service.

What is hard to do by hand

• Keeping a history. A problem that happened 20 minutes ago is gone from docker stats.
• Knowing what normal looks like. 70% memory might be fine for postgres and alarming for a small worker.
• Connecting signals. A slow endpoint, a throttled container and a restart are three observations. The useful part is how they relate in time.
• Saying how sure you are. Correlated is not the same as caused, and a good answer says which one it has.

Where Docktor fits

Docktor automates exactly this approach. It uses your existing SSH setup (~/.ssh/config, keys, agent and jump hosts), runs a fixed catalog of read-only commands, takes one small round trip about every 15 seconds that reads kernel counters, and groups containers into Compose deployments. Rules turn the evidence into findings that say what is likely wrong, how confident Docktor is, and what to check next. Nothing is installed on the server, and the history stays on your Mac.

The limits are real: Docktor monitors only while your Mac is awake and the app is open, and it is not external uptime monitoring. If you need alerts at 3 a.m., pair it with a tool built for that. See how Docktor compares.