What's new in chart-v0.22.2
A metadata-only bump. No template changes, no values.yaml key added or removed, and the rendered perf-sentinel.toml is byte-for-byte what chart-v0.22.1 rendered, same 5477 bytes and the same digest. appVersion moves to 0.22.2 and image.tag follows it to :0.22.2, which is the whole of this release: everything it ships is inside the daemon image.
What moves inside the pod
A trace that begins in a message consumer now says where it came from. It has no inbound HTTP route to name, and under the OpenTelemetry Java agent it has no application frame above the I/O either, so every N+1 behind every listener in a service reported the same endpoint, unknown. They folded into one row, and acknowledging that row hid all of them at once.
The endpoint falls back to the destination of the nearest consumer span, <messaging.system> <destination>, on OTLP, Jaeger and Zipkin. On the streaming path that is a retention problem rather than a lookup: a consumer span ends after everything it wraps, so it usually arrives in a later export than the queries it explains, and the daemon now keeps consumer destinations in the trace window with their parent links to answer for them.
This one is worth more under Helm than on a laptop, because a cluster is where the listeners are. A deployment whose services consume from RabbitMQ or Kafka goes from one unknown row per service to one row per queue, which is the granularity the acknowledgment workflow needs.
The image also picks up rustls 0.23.45 against RUSTSEC-2026-0285, where a TLS 1.3 handshake message that followed a key-changing message inside the same record was accepted at the wrong encryption level. It reaches the daemon through its own TLS listeners and through the shared outbound client. The transcript stays authenticated, so this is not a path to altering or completing a handshake.
The v0.22.2 binary notes describe all of it.
Upgrade impact
- Pods roll on the image.
helm upgradereplaces them becauseappVersionandimage.tagmove together. - Acknowledgments on consumer-rooted findings have to be taken again. An acknowledgment matches on the finding type, the service, the endpoint and a digest of the template, so a finding that read
unknownand now names its queue is a different signature. This reaches the runtime store on the PVC as well as a.perf-sentinel-acknowledgments.tomlbaseline. A finding whose endpoint already resolved keeps the signature it had. checksum/configmoves too, and not because your configuration changed. The renderedperf-sentinel.tomlis identical, but the ConfigMap carrieshelm.sh/chartandapp.kubernetes.io/versionlabels that bump with the chart, so the checksum over it differs on every version bump. Nothing in the daemon's configuration is re-read differently.- No
values.yamlkey is added or removed, no template changes, and the shippedPrometheusRuleis untouched. - The two example Grafana dashboards moved, and they do not ship here. The overview goes to
version9 and the findings one toversion6, each gaining aCompatibilitybadge that says when the daemon feeding it is older than its panels need. Re-import them wherever you provision them.
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.22.2Upgrade an existing release:
helm upgrade perf-sentinel oci://ghcr.io/robintra/charts/perf-sentinel --version 0.22.2Read docs/HELM-DEPLOYMENT.md for the ServiceMonitor section, sizing and Ingress postures.
If you are upgrading from chart-v0.18.0 or earlier, read the chart-v0.19.0 notes first: that release adds a grouping label to five metrics and is breaking for an unaggregated alert on any of them. From chart-v0.16.0 or earlier, read the chart-v0.17.0 notes as well, which change the shipped PrometheusRule.
Full Changelog: chart-v0.22.1...chart-v0.22.2