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.

Sessions

The default session provider is now opaque tokens. JWT stays available by setting the provider and a secret.

Dashboards API

The V1 dashboard CRUD and lock routes, which returned 501 since v0.135.0, are deleted. The V1 public dashboard routes and /api/v2/metrics/dashboards are deleted too. Calls to them get the SigNoz web app's HTML page with HTTP 200 instead of JSON. See V1 dashboard routes are deleted.

AI Observability

You can now monitor your LLM and agent workloads in SigNoz. This release includes:

Overview: tokens, cost, latency and errors across models, providers and agents.
Explorer: query AI spans by model, provider, agent and tool, and filter by rolled-up totals such as tokens and cost.
Attribute mapping: normalizes span attributes from different AI frameworks into the OpenTelemetry gen_ai.* keys, so one set of queries works across all of them.
Pricing: set per-model prices and get cost on every LLM span.

What changes for you

Attribute mapping moves input and output messages from framework-specific attributes like input.value or gen_ai.prompt into the standard gen_ai.input.messages and gen_ai.output.messages. These are the biggest attributes on an LLM span, so we don't keep the original alongside the copy.

Keys that are moved:

Into gen_ai.input.messages: gen_ai.prompt, ai.prompt.messages, input.value
Into gen_ai.output.messages: gen_ai.completion, ai.response.toolCalls, ai.response.text, output.value, final_result

If your queries, saved views or alerts use the old keys, switch them to the standard ones. Spans that already use the standard keys are not affected.

Want to keep the original key too? Go to AI Observability, Attribute Mapping and change the operation from move to copy.

Coming next

Trace detail with conversation threads
Dashboards, alerts and saved views built on AI explorer queries

For the full release scope, see the v0.143.0 release notes.

Who needs to act

SigNoz now manages the signozspanmapper and signozllmpricing processors in your collector over OpAMP. It writes their contents, but it does not add them to the traces pipeline. If you run the default collector config from Foundry or the Helm chart, the new defaults carry them. If you maintain your own collector config, add them yourself.

Before v0.143.0, JWT was the default, so a secret alone was enough. To keep JWT sessions, set both:

SIGNOZ_TOKENIZER_PROVIDER=jwt
SIGNOZ_TOKENIZER_JWT_SECRET=<your 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

Users sign in again once after the switch. See Keep the JWT session provider and the v0.143.0 release notes.

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 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
Call `/api/v1/dashboards`, `/api/v1/public/dashboards/{id}`, or `/api/v2/metrics/dashboards` from scripts or integrations	Move to the V2 or V3 routes before you upgrade, because these routes are deleted and return HTML instead of JSON. See V1 dashboard routes are deleted
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

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.

cast applies the regenerated files but does not pull images. If your casting uses floating tags such as latest, refresh signoz/signoz and signoz/signoz-otel-collector on the host first so the restarted containers run v0.143.0 and v0.144.11. Otherwise the collector restarts on the old image with the new config.

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.

Foundry does not download binaries. Replace the SigNoz and collector binaries at the paths your casting states, then cast:

ARCH=$(uname -m | sed 's/x86_64/amd64/;s/aarch64/arm64/')
 
# defaults; your casting may set foundry.signoz.io/signoz-binary-path and foundry.signoz.io/ingester-binary-path
# extract the full SigNoz tarball: bin/, web/, templates/ and conf/ have to stay together
curl -fsSL "https://github.com/SigNoz/signoz/releases/download/v0.143.0/signoz_linux_${ARCH}.tar.gz" \
  | sudo tar -xz --strip-components=1 -C /opt/signoz
 
curl -fsSL "https://github.com/SigNoz/signoz-otel-collector/releases/download/v0.144.11/signoz-otel-collector_linux_${ARCH}.tar.gz" \
  | sudo tar -xz --strip-components=1 -C /opt/ingester
 
sudo foundryctl cast -f casting.yaml

cast regenerates the collector config, runs the migrations and reloads the units, but does not restart running services. Restart both so they pick up the new binaries and config:

sudo systemctl restart <name>-signoz.service <name>-ingester.service

<name> is metadata.name in your casting.yaml, which is signoz in the shipped example.

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

SigNoz and the collector are healthy (kubectl get pods -n <namespace>, docker compose ps, docker stack ps <stack-name>, or systemctl status 'signoz-*').
SigNoz reports v0.143.0 under Settings.
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 for details.

V1 dashboard routes are deleted

v0.143.0 finishes the dashboard V1 API shutdown that began in v0.135.0. The routes are now deleted rather than returning 501. A call gets the SigNoz web app's HTML page with HTTP 200 instead of JSON, so a script may fail with a JSON parse error. This affects API consumers, automation scripts, and MCP integrations only. There are no UI changes.

V1 dashboard CRUD and lock routes are deleted. The six routes (GET/POST /api/v1/dashboards, GET/PUT/DELETE /api/v1/dashboards/{id}, and PUT /api/v1/dashboards/{id}/lock) returned 501 Not Implemented from v0.135.0. They are deleted in v0.143.0. Move to the matching /api/v2/dashboards routes. See the Dashboards V2 API guide for the full mapping.
V1 public dashboard routes are removed with no prior 501. GET /api/v1/public/dashboards/{id} and GET /api/v1/public/dashboards/{id}/widgets/{idx}/query_range were still functional before this release and are now deleted. Use GET /api/v2/public/dashboards/{id} and GET /api/v2/public/dashboards/{id}/panels/{key}/query_range. The share-config route /api/v1/dashboards/{id}/public is unaffected.
The V2 Metrics Explorer dashboards route is removed. GET /api/v2/metrics/dashboards, which returned the dashboards associated with a metric name, is deleted. Use GET /api/v3/metrics/dashboards.