What's new in chart-v0.2.40
This is a metadata-only chart bump: appVersion advances from 0.7.4 to 0.7.5, the default image.tag now resolves to ghcr.io/robintra/perf-sentinel:0.7.5, and the artifacthub.io/changes annotation gains a kind: fixed block alongside the v0.7.4 kind: added block that landed in chart-v0.2.39 so Artifact Hub consumers keep both the feature-addition narrative and the bug-fix follow-up visible in the rendered card. No chart-level template diff, no values.yaml schema change, no new RBAC, no new optional ConfigMap or Secret, no .perf-sentinel.toml review required to upgrade. The chart-v0.2.39 surface is preserved byte-for-byte.
The 0.7.5 daemon image is a bug fix on the Kepler integration shipped in 0.7.4. The scraper targeted metric names and a label that no released Kepler version ever published, so on any real Kepler v2 cluster every scrape returned HTTP 200 with zero matching samples and the kepler_ebpf co2.model tag never lit up. Full release notes for the daemon at v0.7.5. The fix renames the container metric the scraper reads, replaces the two invalid metric_kind enum values with a single process value, and adds defensive validation so the same class of bug cannot ship silently again. None of this touches a chart-level template, a daemon HTTP route, a Prometheus metric label set the chart already exposes, or the OTLP listener wire format.
Changed
appVersionbumped from0.7.4to0.7.5, defaultimage.tagnow resolves toghcr.io/robintra/perf-sentinel:0.7.5.artifacthub.io/changesannotation extended with a second entry ofkind: fixedcovering the Kepler v2 alignment, the v0.7.4kind: addedblock is preserved so Hub viewers see both releases.- No chart-level config change.
values.yaml, every template, theServiceMonitorrendering, theNetworkPolicyrendering, the optional[daemon.ack]and[daemon.cors]plumbing, and theack-toml-baselinemount are byte-for-byte identical to chart-v0.2.39.
Behavior
- Daemon binary side: Kepler scraper now reads the Kepler v2 series. Container metric renamed from
kepler_container_joules_totaltokepler_container_cpu_joules_total, labelcontainer_nameunchanged. The newmetric_kind = "process"value (replacingprocess_packageandprocess_dram) readskepler_process_cpu_joules_totalkeyed by the kernelcommlabel. - Daemon binary side: legacy
metric_kindvalues rejected at config load. Operators withmetric_kind = "process_package"ormetric_kind = "process_dram"in their.perf-sentinel.tomlnow get aConfigError::Validationat startup pointing atmetric_kind = "process", no more silent Kepler disable. The pre-validation runs before the lossyConfig::fromconversion so the migration error reaches the operator's stderr. - Daemon binary side:
service_mappingscap at 15 bytes forProcess. Matches the Linux kernel'sTASK_COMM_LEN - 1truncation ofcomm. A label longer than 15 bytes can never match a real sample on the wire, rejecting at config load saves a debugging round. - Daemon binary side: zero-sample warn-once. After three consecutive HTTP-200 ticks with zero matching samples (the exact failure mode of running v0.7.5 against a Kepler exporter older than v0.10), the daemon emits a
tracing::warn!line pointing at the most common causes.perf_sentinel_kepler_last_scrape_age_secondskeeps its existing reset-on-HTTP-200 semantics, the new docs note indocs/METRICS.mdcalls out that alerts driven only by the gauge will not catch the zero-sample case. - Daemon binary side: control characters rejected in operator strings.
parse_kepler_metric_kindandvalidate_kepler_service_mappingsreject C0/C1 bytes before any error message interpolates them, closing a low-severity ANSI-injection vector via a hostile.perf-sentinel.toml. - No HTTP-shape change on the daemon side. Every
/api/*route, every/metricsline, the OTLP HTTP and gRPC routes, and every JSON shape are byte-for-byte identical to chart-v0.2.39 for already-clean inputs. - No upgrade hook required, no on-disk migration. The runtime ack store JSONL schema is unchanged, existing acks survive the upgrade. Operators not using
[green.kepler]see no behavioral change at all.
Install
helm install perf-sentinel oci://ghcr.io/robintra/charts/perf-sentinel --version 0.2.40Upgrade an existing release:
helm upgrade perf-sentinel oci://ghcr.io/robintra/charts/perf-sentinel --version 0.2.40Operator action required only if you configured [green.kepler] in v0.7.4
If your .perf-sentinel.toml contains metric_kind = "process_package" or metric_kind = "process_dram", replace it with metric_kind = "process" before upgrading. The 0.7.5 daemon will refuse to start otherwise with a clear migration error. If you used metric_kind = "container" (the default) or did not configure Kepler at all, no action is required.
Full Changelog: chart-v0.2.39...chart-v0.2.40