robintra/perf-sentinel chart-v0.11.0

perf-sentinel chart v0.11.0

on GitHub

What's new in chart-v0.11.0

Two template lines and an appVersion move from 0.10.0 to 0.11.0. The template change repairs a duplicate scrape that only StatefulSet users saw, and only when they had a ServiceMonitor. Everything under Behavior is what the new daemon image does differently once it rolls, and the first of those changes the shape of a findings list you may know by heart.

Fixed

• The ServiceMonitor no longer scrapes every pod twice. A StatefulSet needs a headless Service for pod DNS, and that Service carries the same selector labels as the main one, so the ServiceMonitor matched both. Prometheus scraped each pod under two jobs, <release> and <release>-headless, and every Grafana panel rendered each value twice: a stat panel showed two numbers side by side, a time series drew two identical lines. The headless Service now carries app.kubernetes.io/component: headless and the ServiceMonitor excludes it with a NotIn expression, which still matches the main Service since that one does not carry the key. Only workload.kind=StatefulSet with serviceMonitor.enabled was affected. After upgrading, Prometheus drops the -headless job on its next discovery cycle, and the duplicate series it already stored age out with your retention rather than disappearing at once.

Behavior

• The upgrade rolls the pods. The image tag falls back to .Chart.AppVersion when image.tag is empty, which is the default, so the pod spec moves from 0.10.0 to 0.11.0. The checksum/config annotation also changes, since the ConfigMap carries the chart version in its labels. Pinning image.tag explicitly keeps the old image and forgoes everything below, while still taking the ServiceMonitor fix.
• Findings split by deployment, which changes the shape of a report. [detection] grouping_attributes names the ordered resource or span attributes that separate one deployment from another, defaulting to k8s.namespace.name then service.namespace. In a cluster whose spans carry either, the same N+1 in two namespaces stops folding into one row with summed occurrences: the finding count rises, the occurrences per finding drop. That is the point of the release, but size your alerting on findings counts accordingly. Set grouping_attributes = [] in the daemon config to keep the previous behaviour. Nothing is hardcoded to Kubernetes, a shared cluster can group by tenant.id with a one-line change.
• /api/correlations gained two fields and stopped pairing across deployments. Each endpoint carries grouping_key and the grouping value, and the correlator never links a finding in one deployment to a finding in another. A dashboard or script reading that route sees the new fields as additions, and may see fewer pairs than before, the ones that were never causally related.
• No acknowledgment needs re-capturing. Signatures are untouched on both the TOML baseline and the daemon's runtime store, and one acknowledgment still covers every grouping. Grouping answers who is affected and where, an acknowledgment answers whether the code is accepted debt, and that decision does not vary by deployment.
• One /metrics change to check before upgrading. Exemplars now require a scraper to explicitly accept application/openmetrics-text. A */* wildcard used to count as an opt-in, so vmagent, whose Accept is text/plain;version=0.0.4;*/*;q=0.1, received an exemplar suffix its parser cannot read and minted a dead metric name on every scrape. One real cluster accumulated 6,216 junk metric names against 41 real ones in a few hours. The stock Prometheus ServiceMonitor path is unaffected. If you scrape with vmagent, this upgrade stops the bleeding but does not clean up the series already stored.
• A batch analyze now says when it ignored a configured energy backend. This does not affect the daemon this chart deploys, which scrapes those backends normally, but a CI job running analyze against the same config file will emit a new warning rather than silently scoring with the I/O proxy estimate.
• The archived per-window JSON keeps its shape. A disclosure content_hash computed under 0.10.0 still verifies here.
• No other template, value or default moves. Rendering a values file gives you the same objects as 0.10.0 apart from the two ServiceMonitor lines, the image tag, the chart version labels and the checksum they feed. Nothing about the Deployment, the StatefulSet, the Service, the probes, the PrometheusRule, the NetworkPolicy, the Ingress or the fragment mounts changes.

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

Upgrade an existing release:

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

Verify that the rollout picked up the new image:

kubectl get pod -l app.kubernetes.io/name=perf-sentinel \
  -o jsonpath='{.items[*].spec.containers[*].image}'

If you run a StatefulSet with a ServiceMonitor, confirm the duplicate job is gone:

kubectl get servicemonitor -l app.kubernetes.io/name=perf-sentinel \
  -o jsonpath='{.items[*].spec.selector.matchExpressions}'

Read docs/HELM-DEPLOYMENT.md for the sizing guidance, the Ingress postures and the NetworkPolicy peer an ingress controller needs.

Full Changelog: chart-v0.10.0...chart-v0.11.0