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

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 #

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 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 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 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 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 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 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> , orsystemctl status 'signoz-*' ).
2. SigNoz reports v0.143.0 under Settings .
3. The collector log shows no unknown type error forsignozspanmapper orsignozllmpricing .

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 for details.