[iyashjayesh]

Closes #87. Uses the percent-of-one-core convention, matching what the dashboard already displays.

The same measurement, two different numbers

One /metrics response, 10-core host:

load_statistics.service_cpu_load : 1.68%
service_health.icon_msg          : CPU Usage 17.66% / 95.00%

Ratio: 10.51. Cores: 10.

getServiceCPUUsage returns gopsutil's Process.CPUPercent — percent of one core, the top convention where a process saturating two cores reads 200%. The health path then did:

cpuUsagePercentage := (cpuUsage / float64(totalAvailableCores)) * 100

Dividing by the core count converts to share-of-machine. The * 100 then multiplied a value that was already a percentage.

It gets worse as machines get smaller

Cores	Inflation
1	100×
4	25×
10	10×
100	1× (correct by coincidence)

An idle test process, measured:

cores=1: service CPU reads 360.39%, over the whole allowance, for a test process doing nothing
cores=2: service CPU reads 178.20%
cores=4: service CPU reads 131.96%

All three exceed a 95% limit. And since #86 made a breach any single resource over its own limit, that was enough on its own to report a perfectly healthy service as unhealthy — on exactly the small hosts where people are most likely to be watching.

System health was checked, and is fine

calculateSystemHealth uses GetCPUPrecent, which returns a machine-wide total and is used with no division. I verified this rather than assuming it — the issue flagged it as an open question.

A test that was shaped around the defect

healthyStats() set TotalCores = 100000, with a comment explaining that service CPU "is divided by TotalCores, so a small core count makes the result depend on how busy the machine running the tests happens to be." The fixture was compensating for the bug rather than exposing it. It is 8 now.

TestServiceCPUDoesNotScaleWithCoreCount fails on the old arithmetic with the numbers above.

Behaviour note

MaxCPUUsage is now read in the same units, so a service saturating more than one core exceeds 100% by design — as top reports it. Anyone who tuned a threshold against the old inflated figure will want to revisit it; the numbers get smaller, so the failure mode is a threshold that is now too loose rather than too tight.

Verification

go test -race ./... green across all 12 packages, go vet clean.