You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix(opencost): usage metrics are absent for every namespace, so efficiency and rightsizing are unmeasurableΒ #2782
OpenCost reports cpuCoreUsageAverage: 0 and cpuEfficiency: 0 for all 34 namespaces on prod. Requests are populated correctly (e.g. kube-system 5.32 cores), so the allocation side works β only the usage side is empty.
The consequence is worse than a missing feature: a broken sensor and a genuinely idle workload look identical. Anything reading efficiency would conclude the entire cluster is 100% idle and "rightsize" it on an artefact. Cost attribution by CPU/RAM still works; efficiency and rightsizing do not.
Reproduced 2026-07-21 via the allocation API (svc/opencost:9003, window 3d). OpenCost is configured to read Coroot's bundled Prometheus at coroot-prometheus.observability.svc.cluster.local:9090, so the likely cause is that query path β the metric names it expects, or reachability.
What
Restore usage metrics so efficiency is real, then confirm a known-busy namespace reports non-zero usage.
Acceptance criteria
cpuCoreUsageAverage is non-zero for namespaces that are demonstrably doing work
cpuEfficiency is plausible (not uniformly 0, not uniformly 100%)
Root cause named β metric names, query path, or reachability
A check that fails if usage goes uniformly zero again, so this cannot regress silently
Part of #2355 (FinOps agent) β its rightsizing analysis is blocked on this and currently refuses to emit candidates rather than emit wrong ones.
Closing as a duplicate of #2689, which predates this report and now has draft delivery PR #2794. The older issue remains open until production verification proves non-zero CPU and memory usage after deployment.
Activity
devantler commentedon Jul 23, 2026
Closing as a duplicate of #2689, which predates this report and now has draft delivery PR #2794. The older issue remains open until production verification proves non-zero CPU and memory usage after deployment.