Operations & Diagnostics

## Two readings, two denominators Every utilisation percentage is a fraction, and it means nothing until you know what sits underneath it. A container platform publishes two families of number that look interchangeable on a dashboard and are not: - **What this workload used**, accounted inside its own boundary, divided by **the ceiling declared for that container**. - **What the machine has**, totalled across everything on it, divided by **the installed hardware**. The question *"is this container about to die?"* is answered only by the first. The question *"can this node take another workload?"* is answered only by the second. Reading one as if it were the other is the single most common mistake in container diagnosis, and it goes both ways: people relax because the host looks idle, and people panic because the host looks full while every individual workload is comfortable. ## Where the container's figure comes from When a platform tells you a container is using a certain amount of memory, it is reading the kernel's resource-accounting and limiting mechanism. That mechanism charges each page of memory to the boundary that caused it to be allocated, and it is the same mechanism the ceiling is enforced against. So the numerator and the denominator of the container figure come from the same place — which is exactly why it is the trustworthy reading. It counts what this workload caused, and it compares it against the number that will be used to decide whether this workload keeps running. The host figure is assembled differently: it totals everything on the machine, including the operating system, the platform's own agents, and every other container. A workload can be 5% of a busy host and still be at 100% of its own ceiling. ## What each reading predicts | Reading | Denominator | What it predicts | |---|---|---| | Container usage against its ceiling | the ceiling declared for that container | whether *this* workload is about to be ended for exceeding its memory ceiling | | Container usage against host memory | the machine's installed memory | almost nothing useful about this workload | | Host memory free | the machine | whether the node as a whole is heading for trouble — a different diagnosis, and not this one | ## Why the host's headroom will not save it A ceiling is a hard boundary on the running process, not a hint. The runtime enforces it whether or not the machine has spare capacity, and that is the whole point: the ceiling exists so one workload's growth cannot become the machine's problem. Two consequences follow: 1. A container at 92% of a small ceiling on an almost-empty host is in more danger than a container at 40% of a large ceiling on a busy host. 2. "There is plenty free" is never a reason to dismiss a container's high reading. The free memory belongs to the node, not to this workload. ## Reading the pair together - Judge a workload against its **own** ceiling. That is the number the platform will act on. - Use the host figure to answer node-level questions, and treat it as a separate investigation with its own owner. - Compare like with like across replicas: two copies of the same workload with different ceilings will show different percentages for identical work, and the percentage — not the byte count — is what tells you which one is close to the edge. - Watch the trend, not the instant. A single sample at 92% may be a transient; the same figure climbing across an hour is a trajectory. - Be explicit about which figure an alert is built on. An alert whose threshold was written against a host-wide reading will either never fire for a small container or fire constantly for a large one. ## When there is no ceiling A container does not have to have one. If no memory ceiling was declared, there is no denominator, and the platform can only show you absolute bytes — the percentage either disappears or is quietly computed against the machine, which is the misleading form of the same mistake. In that state the workload's effective limit is whatever the machine has left, shared with everything else on it, and judging "how close is it?" needs the node's picture rather than the container's. That is a different subject; the point for this reading is simply that a percentage with no declared ceiling behind it is not the survival number you think it is. ## The habit to build When someone shows you a memory graph for a container, ask two questions before you interpret it: *what is the ceiling*, and *is this figure charged to the container or to the machine*. Almost every wrong conclusion drawn from a container memory graph comes from skipping one of them.