What it is for
meulog watches other people's software and did not watch the ground it stands on. "Why did it get slow at three in the morning" had an answer in three screens — the queue, the jobs, performance — and none of them said whether memory had run out.
Everything here is published by the kernel as a text file:
/proc/meminfo, /proc/loadavg, the container's
cgroups. Installing a collector to read four files would trade a
File.read for one more process to keep alive — and in an error
monitor, for one more thing that can fall over.
What each meter says
- Memory is the container's ceiling when there is one, not
the machine's. Inside a container
/proc/meminfoshows the whole host, and the host is not what makes the OOM killer show up. Below it, how much of that total is this Ruby process — without it, high memory does not tell "meulog is heavy" from "the neighbour on the same host is". - CPU is the load against the number of cores, as a ratio. Load 4 means nothing on its own: on eight cores it is half the machine, on two it is twice it. A container's quota wins over the host's core count — half a core of quota does not get better by running on a 32-core box.
- Disk is the filesystem meulog writes to.
The colour comes from the proportion, not from a threshold somebody sets: up to 75% is the normal drawing, 90% is attention, above that it is severity.
Where the space is going
Four lines, and all four are actionable: the database grows with occurrences and the purge decides; evidence is what weighs most and has its own policy; backups delete themselves by count; the log is the only one nobody cleans.
When a reading is missing
Each reading is independent, and the one that cannot be taken disappears from the screen instead of showing zero — zero would be indistinguishable from "it is using nothing". Outside Linux, none of them exist.