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

latest releases: chart-v0.9.26, v0.9.26
5 hours ago

What's new in chart-v0.9.25

This chart release carries a new daemon image and nothing else. No template, no value, no schema and no bundled config.toml key changes, so every workload kind renders byte for byte as it did under 0.9.24 and an upgrade rolls the image alone. appVersion advances to 0.9.25, the release that stops a [green] setting from changing what a disclosure publishes and gives the archived windows an integrity chain of their own.

Behavior

  • No template changes. Deployment, StatefulSet and DaemonSet manifests are identical to 0.9.24. The DaemonSet opt-in workload.daemonset.spanRoutingByTraceId introduced in 0.9.22 is unchanged and still required.
  • No values or schema changes. Nothing to add to a values file, and nothing that can fail a gate that passed before. The four quality-gate rules in the bundled config.toml are the same four.
  • The eight PrometheusRule alerts are unchanged, and still disabled by default under prometheusRule.enabled.
  • appVersion moves to 0.9.25, so upgrading pulls the new daemon image unless image.tag is pinned.

What the new image changes for a deployed daemon

Archived windows are hash-chained. When [daemon.archive] is configured, each NDJSON line now records the hash of its own content, the hash of its predecessor and its position in the file, so a window edited, removed or reordered after it was written becomes detectable, and disclose walks that chain while aggregating and publishes the verdict under integrity.trace_integrity_chain. Archives written by an earlier version stay readable and are counted as written before chaining existed rather than as broken. Each line is written unbuffered and a failed write cuts the file back to its last complete window, so an ungraceful pod kill surfaces as a dropped window instead of as an accusation of tampering. A restarted daemon reads the last hash back before appending, which is what makes a restart on a persisted archive a non-event. A clean truncation of the file's tail stays invisible to the chain alone, since what remains is a shorter but self-consistent chain: detecting that needs an anchor kept outside the file, which integrity.cross_period_log stays reserved for. This is tamper-evidence after the fact, not proof of a sincere source.

Three [green] keys tighten in a mounted config.toml. network_energy_per_byte_kwh is deprecated and ignored, the transport coefficient is fixed at 0.04 kWh/GB so that two disclosures cannot scale the same traffic differently, and the sourced 0.001 to 0.059 kWh/GB bracket is published beside the term. include_network_transport is deprecated and ignored too, the term is computed, displayed and disclosed on every run. embodied_carbon_per_request_gco2 = 0.0 warns and falls back to the default, since a zeroed coefficient erased the embodied term from a public figure while looking like a measurement. All three warn rather than refuse, so no key in this release turns an upgrade into a boot failure, and no mounted config needs editing before rolling the image.

The disclosure schema moves to perf-sentinel-report/v1.6. Reports gain the carbon parameters that scale their own figures, a split of the total into its operational, embodied and transport terms so a reader can tell the reducible part from the irreducible one, and the chain verdict above. Every term of that split is omitted rather than published as zero when nothing measured it. Additive: a report produced by an earlier version keeps its content_hash when re-hashed on this binary.

One figure moves for an operator who had turned network transport off: that period now reports a larger carbon total, once, because the term it was hiding is counted. No detector, threshold, score or exported metric changes, and /metrics carries the same series with the same labels.

The bundled Grafana dashboard does need a re-import

examples/grafana-dashboard.json is not part of this chart, but it is the dashboard the Helm deployment guide points at, and unlike the last two releases this one changed it. It gains two template variables. Job selects which Prometheus job to read, which matters as soon as one Prometheus scrapes several daemons, staging and production for instance: 31 of the 32 queries carried no job filter and summed them silently. Service filters the per-service I/O panel and only that one, because every other metric the daemon exports is daemon-wide by design and a filter that appeared to narrow the whole dashboard would be misreporting the rest of it. Rate panels now use $__rate_interval and follow the time range you pick instead of a fixed five-minute window, except the two whose title names a window, where that window is the measure rather than a display choice.

Re-import it manually, or let the sidecar pick it up if you load it from a ConfigMap. The observability section of the Helm deployment guide has both paths.

Install

The chart is published as an OCI artifact on GHCR, install it directly with no helm repo add step:

helm install perf-sentinel oci://ghcr.io/robintra/charts/perf-sentinel --version 0.9.25

Upgrade an existing release:

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

An upgrade from 0.9.24 needs no values change and rolls one new image. Read the v0.9.25 release notes for everything the new image carries, including the CLI and report changes this chart does not deploy.

Full Changelog: chart-v0.9.24...chart-v0.9.25

Don't miss a new perf-sentinel release

NewReleases is sending notifications on new releases.