github robintra/perf-sentinel chart-v0.2.40
perf-sentinel chart v0.2.40

latest releases: chart-v0.9.8, v0.9.8, chart-v0.9.7...
one month ago

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

  • appVersion bumped from 0.7.4 to 0.7.5, default image.tag now resolves to ghcr.io/robintra/perf-sentinel:0.7.5.
  • artifacthub.io/changes annotation extended with a second entry of kind: fixed covering the Kepler v2 alignment, the v0.7.4 kind: added block is preserved so Hub viewers see both releases.
  • No chart-level config change. values.yaml, every template, the ServiceMonitor rendering, the NetworkPolicy rendering, the optional [daemon.ack] and [daemon.cors] plumbing, and the ack-toml-baseline mount 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_total to kepler_container_cpu_joules_total, label container_name unchanged. The new metric_kind = "process" value (replacing process_package and process_dram) reads kepler_process_cpu_joules_total keyed by the kernel comm label.
  • Daemon binary side: legacy metric_kind values rejected at config load. Operators with metric_kind = "process_package" or metric_kind = "process_dram" in their .perf-sentinel.toml now get a ConfigError::Validation at startup pointing at metric_kind = "process", no more silent Kepler disable. The pre-validation runs before the lossy Config::from conversion so the migration error reaches the operator's stderr.
  • Daemon binary side: service_mappings cap at 15 bytes for Process. Matches the Linux kernel's TASK_COMM_LEN - 1 truncation of comm. 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_seconds keeps its existing reset-on-HTTP-200 semantics, the new docs note in docs/METRICS.md calls 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_kind and validate_kepler_service_mappings reject 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 /metrics line, 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.40

Upgrade an existing release:

helm upgrade perf-sentinel oci://ghcr.io/robintra/charts/perf-sentinel --version 0.2.40

Operator 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

Don't miss a new perf-sentinel release

NewReleases is sending notifications on new releases.