Upgrade SigNoz to v0.143.0 with OTel Collector v0.144.11

SigNoz released v0.143.0, which requires self-hosted users to run signoz-otel-collector v0.144.11 with two new processors added to the traces pipeline for AI observability, and moves login sessions to opaque tokens so every user must sign in again. Users who override the collector config or pin the collector image below v0.144.11 must add the processors or stay on SigNoz v0.142.x, and those setting SIGNOZ_TOKENIZER_JWT_SECRET or SIGNOZ_JWT_SECRET must add SIGNOZ_TOKENIZER_PROVIDER=jwt before upgrading to keep JWT sessions. The upgrade requires backing up the SigNoz Metastore (SQLite or Postgres) first, and Swarm users must run docker stack rm before foundryctl cast because Swarm configs are immutable.

SigNoz v0.143.0 prepares the OTel collector for AI observability and moves login sessions to opaque tokens. Two things follow for self-hosted upgrades: the collector must run signoz-otel-collector v0.144.11 with two new processors in its traces pipeline, and every user signs in again once. Who needs to act | If you | Then | |---|---| | Run the default collector config | Nothing beyond the upgrade. Sign in again afterwards | | Override the collector config or its traces pipeline | Add the two processors add-the-ai-observability-processors-to-a-custom-collector-config before or with the upgrade | | Pin the collector image below v0.144.11 | Move it to v0.144.11, or stay on SigNoz v0.142.x until you can | | Set SIGNOZ TOKENIZER JWT SECRET or SIGNOZ JWT SECRET today | Your sessions move to opaque and the secret is ignored. To stay on JWT, add SIGNOZ TOKENIZER PROVIDER=jwt before you upgrade. See Keep the JWT session provider keep-the-jwt-session-provider | Upgrade self-hosted SigNoz Step 1: Back up your data Pricing rules and attribute mappings live in the SigNoz Metastore SQLite or Postgres alongside dashboards and alerts. Back up the Metastore before you start. If you are more than one release behind, check the Upgrade Path Tool https://signoz.io/upgrade-path/ for required stops before you move to v0.143.0. Step 2: Upgrade SigNoz and the collector Upgrade both together. SigNoz v0.143.0 requires signoz-otel-collector v0.144.11. Upgrade foundryctl https://github.com/SigNoz/foundry/blob/main/docs/getting-started.md to pick up the v0.143.0 collector config, then re-apply your existing casting.yaml . curl -fsSL https://signoz.io/foundry.sh | bash foundryctl cast -f casting.yaml cast regenerates the collector config with the two processors when the ingester image is latest or a version that ships them, and keeps the previous config for an older pin. If your casting.yaml https://github.com/SigNoz/foundry/blob/main/docs/reference/casting-file.md pins image versions, bump SigNoz to v0.143.0 and the collector to v0.144.11 yourself; cast refuses SigNoz v0.143.0 paired with a collector that cannot load the processors and tells you to move to v0.144.11. If your casting sets spec.config on the ingester with its own traces processors list, that list replaces the generated one. Add the two processors add-the-ai-observability-processors-to-a-custom-collector-config to it. Swarm configs are immutable. cast cannot update the changed collector config in place, so docker stack deploy fails on the existing stack. Remove the stack first, then cast: curl -fsSL https://signoz.io/foundry.sh | bash docker stack rm <stack-name foundryctl cast -f casting.yaml The stack is named after metadata.name in your casting.yaml , which is signoz in the shipped example. All services are down between docker stack rm and foundryctl cast . docker stack rm removes the services and the networks, so data on named volumes is kept. Update the chart https://github.com/SigNoz/charts and upgrade. Replace <namespace and <release-name with your own values: helm repo update helm -n <namespace upgrade <release-name signoz/signoz -f <your-values.yaml helm upgrade takes the newest chart; add --version 0.143.0 to pin the v0.143.0 chart. The chart's default otelCollector.config carries both processors. Helm replaces lists instead of merging them, so if your values file sets otelCollector.config.service.pipelines.traces.processors , add the two processors add-the-ai-observability-processors-to-a-custom-collector-config to your list. Step 3: Verify the upgrade 1. SigNoz and the collector are healthy kubectl get pods -n <namespace , docker compose ps , docker stack ps <stack-name , or systemctl status 'signoz- ' . 2. SigNoz reports v0.143.0 under Settings . 3. The collector log shows no unknown type error for signozspanmapper or signozllmpricing . Add the AI observability processors to a custom collector config Add both processors under processors , exactly as below. SigNoz fills groups and default pricing.rules over OpAMP, so leave them empty here. processors: signozspanmapper: groups: signozllmpricing: attrs: model: gen ai.request.model in: gen ai.usage.input tokens out: gen ai.usage.output tokens cache read: gen ai.usage.cache read.input tokens cache write: gen ai.usage.cache creation.input tokens default pricing: rules: output attrs: in: signoz.gen ai.usage.input tokens.cost out: signoz.gen ai.usage.output tokens.cost cache read: signoz.gen ai.usage.cache read.input tokens.cost cache write: signoz.gen ai.usage.cache write.input tokens.cost total: signoz.gen ai.usage.tokens.cost Then add both to the traces pipeline, after signozspanmetrics/delta and before batch : service: pipelines: traces: receivers: otlp processors: signozspanmetrics/delta, signozspanmapper, signozllmpricing, batch exporters: clickhousetraces, metadataexporter, signozmeter A collector with the processors defined but missing from the pipeline starts fine; token costs and attribute mapping stay off until the pipeline entries are in place. Keep the JWT session provider SigNoz v0.143.0 issues opaque session tokens by default. Before v0.143.0 JWT was the default, so a secret alone was enough. To stay on JWT, set both before you upgrade: SIGNOZ TOKENIZER PROVIDER=jwt SIGNOZ TOKENIZER JWT SECRET=<your existing secret With the jwt provider and no secret, SigNoz refuses to start: jwt::secret must be set when provider is jwt, without a JWT secret, user sessions are vulnerable to tampering and unauthorized access If you still use SIGNOZ JWT SECRET , rename it to SIGNOZ TOKENIZER JWT SECRET . See Configure the JWT Secret https://signoz.io/docs/manage/administrator-guide/configuration/jwt-secret/ for details.