perf-sentinel chart v0.9.22

What's new in chart-v0.9.22

This chart release turns a topology that quietly degrades detection into one that refuses to install, and documents where collector sampling belongs relative to the daemon. workload.kind: DaemonSet puts one pod per node behind a Service, and a plain Service round-robins, so the spans of a single trace land on different pods. Correlation is per-trace and in-memory, so each pod analyzes a slice: N+1 groups fall under their threshold and the findings never appear. Nothing reports that. There is no error, no metric that moves, and the mode reads as working while detection is degraded. The values file already carried the warning as a comment and docs/HELM-DEPLOYMENT.md spelled it out, but neither stops a render, and a comment is not read by whoever copies a values file. appVersion advances to 0.9.22, realigning with the chart version after the chart-only releases 0.9.18 through 0.9.21.

Changed (breaking for workload.kind: DaemonSet)

• The render now fails unless workload.daemonset.spanRoutingByTraceId is true. A values file that installed under 0.9.21 stops installing here, so a CD pipeline tracking the chart with a ~0.9 or ^0.9 constraint fails its next reconcile until the value is set. That is the intent: an install that silently loses findings is worse than one that refuses to start. The opt-in is the operator asserting that an upstream collector routes by trace ID to these pods, for example the OTel loadbalancing exporter with routing_key: traceID pointing at the DaemonSet rather than at a ClusterIP. Deployment with replicas: 1 stays the default and recommended topology, and is unaffected.
• The embedded config.toml documents why sampling_rate stays at its 1.0 default. Below 1.0 the finding counts and the Prometheus totals describe a sample of the traffic rather than a measure of it, and a rare pattern can be missed entirely. The same holds for a collector running tail_sampling in front of the daemon, except perf-sentinel cannot detect that one at all, since a kept trace is indistinguishable from a complete one. Sampling exists to bound what a trace store retains and the daemon retains nothing beyond an in-memory per-trace window, so the recommended layout is a second collector pipeline exporting to perf-sentinel without the sampler. Comment-only change to the rendered ConfigMap, no behavior change.

Fixed

• The DaemonSet guard tolerates a null workload.daemonset. A values file writing workload.daemonset: null, or a --set workload.daemonset=null, used to produce a Go template nil-pointer error instead of the guard's explanation, which is the entire point of the guard.

Behavior

• Deployment and StatefulSet installs render exactly as before. No manifest changes for either, so upgrading from 0.9.21 on the default topology rolls nothing and requires no migration.
• appVersion moves to 0.9.22 and the two numbers realign. The chart-only releases 0.9.18 through 0.9.21 advanced the chart version alone while appVersion stayed on the last shipped daemon, 0.9.17. This release carries the matching application version, so both read 0.9.22 again. Upgrading pulls the new daemon image unless image.tag is pinned. That daemon release changes acknowledgment signatures, see the v0.9.22 release notes before upgrading a cluster with recorded acknowledgments.

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.22

Upgrade an existing release:

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

Running workload.kind: DaemonSet? Set the opt-in in the same command, after confirming an upstream collector routes by trace ID to these pods:

helm upgrade perf-sentinel oci://ghcr.io/robintra/charts/perf-sentinel --version 0.9.22 \
  --set workload.daemonset.spanRoutingByTraceId=true

Full Changelog: chart-v0.9.21...chart-v0.9.22