A host at 70% CPU and 80% memory tells you the machine is working. It does not tell you which of the dozen things running on it is responsible, whether that is normal for this time of day, or whether one of them has been restarting all night. Host metrics are how you find out there is a problem. Per-process metrics are how you find out whose.
Bleemeo calls this Key Process Monitoring, and it is on by default — which means the interesting question is not how to enable it but what to do with it.
What per-process metrics answer
CPU, and the core you cannot see
This is the case that convinces people. A process that is single-threaded — a lot of them are, from Redis to a Node worker to most cron jobs — can be completely saturated at 100% of one core. On an eight-core host that is 12.5% of total CPU.
Host CPU will look fine. It is fine. And the service is as slow as it can possibly get, with no headroom whatsoever, because the thing limiting it is a single core it has already filled. Per-process CPU is the only place this is visible, and once you have seen it once you stop trusting host averages.
Memory, where the shape is the answer
Resident memory per process, graphed over days rather than hours, is the most useful leak detector there is. The shape tells you what is happening:
- A steady climb that never comes back down — a leak. It will end in the OOM killer or a cgroup limit, and the graph tells you roughly when.
- A sawtooth — a leak plus something already restarting the process for you. Systemd, a supervisor, Kubernetes, or the OOM killer. This one is the quiet disaster: the service works, nobody is paged, and it has been dying and coming back for months.
- A step change — a deploy moved the baseline. Fine, as long as the new plateau is a plateau.
- A slow climb that plateaus — usually a cache filling up, not a leak. The distinction matters and only a long window shows it.
Hours of data cannot tell these apart. Days can.
I/O, to find who is holding the disk
Host iowait says the disk is saturated. It never says by whom, and on a box
running a database, a log shipper and a backup job that is the whole question.
Per-process read and write bytes settle it in seconds — and the answer is
surprisingly often the backup or the log rotation rather than the database
everyone suspected.
Presence and restarts
The most basic metrics here, and the ones most often missing. Is the process running? How long has it been up?
A service that crashes and gets restarted within seconds leaves almost no trace in host metrics — a small CPU blip, nothing more. But a process whose uptime keeps resetting is a process that is failing, and an alert on that catches an entire class of incident that availability checks miss because the service is back up by the time they run.
Containers make this mandatory
Under a cgroup, a process has its own memory and CPU limits, independent of the host’s. It can be OOM-killed at 512 MB on a host with 60 GB free, or CPU-throttled while the host sits at 20%. Every host-level metric will look healthy throughout.
If you run anything in containers, per-process — or per-container — resource metrics are not a refinement. They are the only place the constraint that actually applies is visible.
Why it belongs next to your service metrics
This is the part the original version of this article was reaching for, and it is worth being concrete about.
Service metrics tell you what a service is doing: queries per second, requests served, messages consumed. Resource metrics tell you what it costs. Neither is diagnostic alone; together they are.
- Queries per second flat, CPU pinned → one expensive query or a bad plan, not load. Scaling out will not help.
- Queries per second up, CPU up proportionally → genuine load. Scaling will help.
- Queries per second down, I/O up → the process is stuck waiting on disk, and throughput is the symptom rather than the cause.
- Everything flat, memory climbing → a leak, on a service nobody has complained about yet.
The same two graphs answer four different questions depending on which way they move. That is why a dashboard mixing both is worth building, and why either half on its own leaves you guessing.
Setting it up with Bleemeo
There is nothing to configure. The open-source agent automatically detects more than 60 services and creates the associated metrics — memory, CPU, network and I/O for each discovered process — as described in the documentation. Any service process the agent discovers is covered.
Taking MySQL as the example: alongside the MySQL service metrics, the agent creates memory, CPU, network and I/O usage metrics for the process itself. For the service metrics it connects to MySQL; on most Linux distributions the system account is used and there is nothing to set up.
Key Process Monitoring metrics appear in the agent’s metrics tab, in the process section:
Build the dashboard
These are not graphed by default — deliberately, since a dashboard carrying every process on every host would be unreadable. Pick the services that matter and put them on a custom dashboard. For MySQL:
- Memory used by MySQL in bytes
- Status of MySQL
- CPU used by MySQL
- I/O read by MySQL in bytes
- I/O written by MySQL in bytes
Then add the service metrics next to them, which is where the combination starts paying:
- Number of queries per second
- Number of selects per second
- Network traffic received from clients in bytes per second
- Network traffic sent to clients in bytes per second
Set the time range to a week rather than an hour. Leaks, restart loops and capacity trends are all invisible at an hour and obvious at a week.
Which of these deserve an alert
| Alert on | Why |
|---|---|
| Process absent | The cheapest alert here and the one most often missing |
| Process uptime resetting repeatedly | A restart loop leaves almost no trace in host metrics |
| Process memory approaching its cgroup or host limit | The OOM kill is predictable days ahead |
| Process CPU near 100% of a single core | Saturation invisible in host CPU on a multi-core box |
| Process memory climbing with flat throughput | A leak, before anybody complains |
Per-process CPU and I/O as absolute values belong on the dashboard. They vary with your traffic, so an alert on them mostly tells you the business had a good day.
Process monitoring FAQ
Why do I need per-process metrics if I already monitor the host?
Because host metrics identify a symptom and never a culprit. The clearest example: a single-threaded process saturated at 100% of one core registers as 12.5% CPU on an eight-core host. The host looks idle, the service has no headroom left, and only per-process CPU shows it. The same applies to disk — host iowait says the disk is busy, per-process I/O says which of the database, the log shipper or the backup is doing it.
How do I tell a memory leak from a cache filling up?
By the window and the shape. Over days, a leak climbs and never comes back down until something kills the process; a cache climbs and plateaus. A sawtooth means both a leak and something already restarting the process for you — systemd, a supervisor, or the OOM killer — which is the case worth finding, because the service keeps working and nobody gets paged.
Does key process monitoring need configuration?
No. The agent detects more than 50 services on its own and creates memory, CPU, network and I/O metrics for each discovered process. What it does not do is graph them by default — a dashboard with every process on every host would be unreadable — so choosing which services matter and putting them on a custom dashboard is the one manual step.
Is any of this different in containers?
It matters more. A containerised process has its own cgroup memory and CPU limits, independent of the host's, so it can be OOM-killed at 512 MB on a host with 60 GB free, or CPU-throttled while the host sits at 20%. Every host-level metric stays green throughout. Per-process metrics are the only place the limit that actually applies is visible.
