The overhead-versus-fidelity framing is the part I care about most, and I'd rather have the range than a flattering headline number.
I got bitten by the far end of this recently. A polling loop I wrote to watch a deploy got left running — eight copies of it — and between the SSH sessions and process spawns it pinned a single-core box at 75-99% CPU. It then paged me for a sustained CPU breach. The thing watching for problems was the problem, and it took an embarrassingly long time to work that out because every metric looked like a real incident.
So a stated 0.7-9.9% band is more useful to me than a lower number with no bounds. What drives the spread — queue depth, submission batching, SQPOLL?
pylonmon•49m ago
I got bitten by the far end of this recently. A polling loop I wrote to watch a deploy got left running — eight copies of it — and between the SSH sessions and process spawns it pinned a single-core box at 75-99% CPU. It then paged me for a sustained CPU breach. The thing watching for problems was the problem, and it took an embarrassingly long time to work that out because every metric looked like a real incident.
So a stated 0.7-9.9% band is more useful to me than a lower number with no bounds. What drives the spread — queue depth, submission batching, SQPOLL?