Make load-average gauges use CPU thresholds, not fixed 70/100% - #98
Merged
Conversation
renderGauge() hardcoded 70% and 100% of core count as the gauge's warn/crit thresholds, regardless of the configured cpu_warn_percent / cpu_crit_percent. This contradicted the documented behavior in packaging/pimonitor.example.yaml, which claims the load-average gauge scale uses the CPU thresholds relative to core count. renderGauge() now takes warnPercent/critPercent parameters, and the three load-average gauge calls pass config.thresholds.cpu_warn_percent / cpu_crit_percent, matching the documented behavior and the CPU usage bar's own use of the same thresholds. Closes #67
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pull Request
📖 Description
packaging/pimonitor.example.yamldocuments thethresholdssection as driving "the load-average gauge scale, which uses the CPU thresholds relative to core count," butrenderGauge()ininternal/web/assets/app.jshardcodedcores × 0.7/cores × 1.0for the gauge's warn/crit color thresholds, ignoring the configuredcpu_warn_percent/cpu_crit_percent.This fixes the code to match the documented behavior instead of correcting the doc, since using the configured thresholds is more useful (and consistent with how the CPU usage bar already uses the same thresholds).
renderGauge()now takeswarnPercent/critPercentparameters, and the three load-average gauge calls (gauge-load1/5/15) passconfig.thresholds.cpu_warn_percent/cpu_crit_percent.🎫 Issues
Closes #67
👩💻 Reviewer Notes
Pure frontend change in
internal/web/assets/app.js; no Go API/behavior changes. Smoke test: open the dashboard, confirm the load-average gauges still render and change color at the expected thresholds (scaled by core count andcpu_warn_percent/cpu_crit_percent).📑 Test Plan
Added
internal/web/gauge_test.go, following this repo's existing pattern of Go tests that read the embeddedapp.jssource and assert on it (seexss_test.go,dialog_test.go). It guards against the hardcoded0.7/1.0factors reappearing and asserts the load-gauge calls passt.cpu_warn_percent/t.cpu_crit_percent.go build ./...— cleango vet ./...— cleango test ./... -race -cover— all packages passgolangci-lint run— 0 issues✅ Checklist
General
go test ./... -race -coverpasses locally).go vet ./...andgolangci-lint runare clean.ARCHITECTURE.mdif this changes a documented design decision. (not applicable — no design decision changed, just a bug fix)REST API / configuration / packaging
Not applicable — no REST API, config, or packaging changes.
⏭ Next Steps
None.