Documentation Grafana Tempo Set up Upgrade

Upgrade your Tempo installation

You can upgrade an existing Tempo installation to the next version. However, any new release has the potential to have breaking changes that should be tested in a non-production environment prior to rolling these changes to production.

The upgrade process changes for each version, depending upon the changes made for the subsequent release.

This upgrade guide applies to on-premise installations and not for Grafana Cloud.

For detailed information about any release, refer to the Release notes.

Upgrade to Tempo 2.6

Tempo 2.6 has several considerations for any upgrade:

• Operational change for TraceQL metrics
• vParquet4 is now the default block format
• Updated, removed, or renamed parameters

For a complete list of changes, refer to the Temopo 2.6 changelog.

Operational change for TraceQL metrics

We’ve changed to an RF1 (Replication Factor 1) pattern for TraceQL metrics as we were unable to hit performance goals for RF3 de-duplication. This requires some operational changes to query TraceQL metrics.

TraceQL metrics are still considered experimental, but we hope to mark them GA soon when we productionize a complete RF1 write-read path. [PRs 3628, 3691, 3723, 3995]

For recent data

The local-blocks processor must be enabled to start using metrics queries like { } | rate(). If not enabled metrics queries fail with the error localblocks processor not found. Enabling the local-blocks processor can be done either per tenant or in all tenants.

• Per-tenant in the per-tenant overrides:

  yaml Copy

    overrides:
      'tenantID':
        metrics_generator_processors:
          - local-blocks

• By default, for all tenants in the main config:

  yaml Copy

  overrides:
    defaults:
      metrics_generator:
        processors: [local-blocks]

Add this configuration to run TraceQL metrics queries against all spans (and not just server spans):

yaml Copy

metrics_generator:
  processor:
    local_blocks:
      filter_server_spans: false

For historical data

To run metrics queries on historical data, you must configure the local-blocks processor to flush rf1 blocks to object storage:

yaml Copy

metrics_generator:
  processor:
    local_blocks:
      flush_to_storage: true

Transition to vParquet4

vParquet4 format is now the default block format. It’s production ready and we highly recommend switching to it for improved query performance. [PR 3810]

Upgrading to Tempo 2.6 modifies the Parquet block format. Although you can use Tempo 2.6 with vParquet2 or vParquet3, you can only use Tempo 2.6 with vParquet3.

You can also use the tempo-cli analyse blocks command to query vParquet4 blocks. PR 3868]. Refer to the Tempo CLI documentation for more information.

For information on upgrading, refer to Upgrade to Tempo 2.6 and Choose a different block format.

Updated, removed, or renamed configuration parameters

tempo-query is a standalone server

With Tempo 2.6.1, tempo-query is no longer a Jaeger instance with grpcPlugin. It’s now a standalone server. Serving a gRPC API for Jaeger on 0.0.0.0:7777 by default. [PR 3840]

Upgrade to Tempo 2.5

Tempo 2.5 has several considerations for any upgrade:

• Docker image runs as new UID
• Support for vParquet format removed
• Experimental vParquet4 block format
• Removed configuration parameters

For a complete list of changes, enhancements, and bug fixes, refer to the Tempo 2.5 changelog.

Docker image runs as new UID

The Tempo process in the official Docker image used to run as root. The Tempo process now runs as UID 10001 in the Docker image.

Components such as ingesters and metrics generators that maintain files on disk won’t come up cleanly without intervention. The new user 10001 won’t have access to the old files created by root.

The ownership of /var/tempo changed from root:root to tempo:tempo with the UID/GID of 10001.

The ingester and metrics-generator statefulsets may need to run chown to change ownership to start properly.

Refer to PR 2265 to see a Jsonnet example of an init container.

This change doesn’t impact you if you used the Helm chart with the default security context set in the chart. All data should be owned by the tempo user already. The UID won’t impact Helm chart users.

Support for vParquet format removed

The original vParquet format has been removed from Tempo 2.5. Direct upgrades from Tempo 2.1 to Tempo 2.5 are not possible. You will need to upgrade to an intermediate version and wait for the old vParquet blocks to fall out of retention before upgrading to 2.5. PR 3663]

vParquet(1) won’t be recognized as a valid encoding and any remaining vParquet(1) blocks will not be readable.

Installations running with historical defaults should not require any changes as the default has been migrated for several releases. Installations with storage settings pinned to vParquet must run a previous release configured for vParquet2 or higher until all existing vParquet(1) blocks have expired and been deleted from the backend, or else will encounter read errors after upgrading to this release.

Experimental vParquet4 block format

The vParquet4 block format is required for querying links, events, and arrays and improves query performance relative to previous formats. vParquet4 will be the default block format in the next release. [PR 3368]

While you can use vParquet4, keep in mind that it’s experimental. If you choose to use vParquet4 and then opt to revert to vParquet3, any vParquet4 blocks would not be readable by vParquet3.

To try vParquet4, refer to Choose a block format.

Removed configuration parameters

Additional considerations

• Updating to OTLP 1.3.0 removes the deprecated InstrumentationLibrary and InstrumentationLibrarySpan from the OTLP receivers. PR 3649]
• Removes the addition of a tenant in multitenant trace id lookup. PR 3522]

Upgrade to Tempo 2.4

Tempo 2.4 has several considerations for any upgrade:

• vParquet3 is now the default backend
• Caches configuration was refactored
• Updated, removed, and renamed configuration parameters

For a complete list of changes, enhancements, and bug fixes, refer to the Tempo 2.4 changelog.

Transition to vParquet3 as default block format

vParquet3 format is now the default block format. It is production ready and we highly recommend switching to it for improved query performance and dedicated attribute columns.

Upgrading to Tempo 2.4 modifies the Parquet block format. Although you can use Tempo 2.3 with vParquet2 or vParquet3, you can only use Tempo 2.4 with vParquet3.

With this release, the first version of our Parquet backend, vParquet, is being deprecated. Tempo 2.4 will still read vParquet1 blocks. However, Tempo will exit with error if they are manually configured. [PR 3377]

For information on changing the vParquet version, refer to Choose a different block format.

Cache configuration refactored

The major cache refactor to allow multiple role-based caches to be configured. [PR 3166] This change resulted in several fields being deprecated (refer to the old configuration).

These fields have all been migrated to a top level cache: field.

For more information about the configuration, refer to the Cache section.

The old configuration block looked like this:

yaml Copy

storage:
  trace:
    cache:
    search:
      cache_control:
    background_cache:
    memcached:
    redis:

With the new configuration, you create your list of caches, with either redis or memcached cluster with your configuration, and then define the types of data and roles.

Simple configuration example:

yaml Copy

cache:
  caches:
  - memcached:
      host: <some memcached cluster>
    roles:
    - bloom
    - parquet-footer
  - memcached:
      host: <some memcached cluster>
    roles:
    - frontend-search

Updated, removed, or renamed configuration parameters

The distributor now returns 200 for any batch containing only trace_too_large and max_live_traces errors. The number of discarded spans are still reflected in the tempo_discarded_spans_total metrics.

Upgrade to Tempo 2.3

Tempo 2.3 has several considerations for any upgrade:

• vParquet3 is available as a stable, production-read block format
• Configuration option to use Azure SDK v2
• New defaults block in Overrides module configuration
• Several configuration parameters have been renamed or removed.

For a complete list of changes, enhancements, and bug fixes, refer to the Tempo 2.3 changelog.

Production-ready vParquet3 block format

vParquet3 provides improved query performance and dedicated attribute columns.

This block format is required for using dedicated attribute columns.

While vParquet2 remains the default backend for Tempo 2.3, vParquet3 is available as a stable option. Both work with Tempo 2.3.

Upgrading to Tempo 2.3 doesn’t modify the Parquet block format.

Recommended update process:

1. Upgrade your Tempo installation to version 2.3, remaining on vParquet2.
2. Verify the upgrade is stable and performs as expected. If you notice any issues, you can downgrade to version 2.2, and data remains readable.
3. Change the block format to vParquet3.

If you notice any issues on step 3 using the new block format, you can downgrade to vParquet2. All your data remains readable in Tempo 2.3. However, if you have vParquet3 blocks and have to downgrade to Tempo 2.2, you will have data loss.

Use Azure SDK v2

If you are using Azure storage, we recommend using the v2 SDK, azure-sdk-for-go. You can use the use_v2_sdk configure option for switching.

For more information, refer to the Storage block configuration example documentation.

New defaults block in Overrides module configuration

The Overrides module has a new defaults block for configuring global or per-tenant settings. The Overrides format now includes changes to indented syntax. For more information, read the Overrides configuration documentation.

You can also use the Tempo CLI to migrate configurations. Refer to the tempo-cli documentation.

The old configuration block looked like this:

yaml Copy

overrides:
  ingestion_rate_strategy: local
  ingestion_rate_limit_bytes: 12345
  ingestion_burst_size_bytes: 67890
  max_search_duration: 17s
  forwarders: ['foo']
  metrics_generator_processors: [service-graphs, span-metrics]

The new configuration block looks like this:

yaml Copy

overrides:
  defaults:
    ingestion:
      rate_strategy: local
      rate_limit_bytes: 12345
      burst_size_bytes: 67890
    read:
      max_search_duration: 17s
    forwarders: ['foo']
    metrics_generator:
      processors: [service-graphs, span-metrics]

Removed or renamed configuration parameters

Upgrade to Tempo 2.2

Tempo 2.2 has several considerations for any upgrade:

• vParquet2 is now the default block format
• Several configuration parameters have been renamed or removed.

For a complete list of changes, enhancements, and bug fixes, refer to the Tempo 2.2 changelog.

Default block format changed to vParquet2

While not a breaking change, upgrading to Tempo 2.2 by default changes Tempo’s block format to vParquet2.

To stay on a previous block format, read the Parquet configuration documentation. We strongly encourage upgrading to vParquet2 as soon as possible as this is required for using structural operators in your TraceQL queries and provides query performance improvements, in particular on queries using the duration intrinsic.

Updated JSonnet supports statefulset for the metrics-generator

Tempo 2.2 updates the microservices JSonnet to support a statefulset for the metrics_generator component.

To support a new processor, the metrics-generator has been converted from a deployment into a statefulset with a PVC. This requires manual intervention to migrate successfully and avoid downtime. Note that currently both a deployment and a statefulset will be managed by the JSonnet for a period of time, after which we will delete the deployment from this repo and you will need to delete user-side references to the tempo_metrics_generator_deployment, as well as delete the deployment itself.

Refer to the PR for seamless migration instructions. [PRs 2533, 2467]

Removed or renamed configuration parameters

The following fields were removed or renamed.

query_frontend:
  tolerate_failed_blocks: 

storage:
  trace:
  s3:
  insecure_skip_verify: true  // renamed to tls_insecure_skip_verify

Upgrade to Tempo 2.1

Tempo 2.1 has two major considerations for any upgrade:

• Support for search on v2 block is removed
• Breaking changes to metric names

For more information on other enhancements, read the Tempo 2.1 release notes.

Remove support for Search on v2 blocks

Users can no longer search blocks in v2 format. Only the Parquet formats support search. These search configuration options were removed from the overrides section:

Copy

overrides:
  max_search_bytes_per_trace:
  search_tags_allow_list:
  search_tags_deny_list:

The following metrics configuration was also removed:

Copy

tempo_ingester_trace_search_bytes_discarded_total

Upgrade path to maintain search from Tempo 1.x to 2.1

Removing support for search on v2 blocks means that if you upgrade directly from 1.9 to 2.1, you will not be able to search your v2 blocks. To avoid this, upgrade to 2.0 first, since 2.0 supports searching both v2 and vParquet blocks. You can let your old v2 blocks gradually age out while Tempo creates new vParquet blocks from incoming traces. Once all of your v2 blocks have been deleted and you only have vParquet format-blocks, you can upgrade to Tempo 2.1. All of your blocks will be searchable.

Parquet files are no longer cached when carrying out searches.

Breaking changes to metric names exposed by Tempo

All Prometheus metrics exposed by Tempo on its /metrics endpoint that were previously prefixed with cortex_ have now been renamed to be prefixed with tempo_ instead. (PR 2204)

Tempo now includes SLO metrics to count where queries are returned within a configurable time range. (PR 2008)

The query_frontend_result_metrics_inspected_bytes metric was removed in favor of query_frontend_bytes_processed_per_second.

Upgrade from Tempo 1.5 to 2.0

Tempo 2.0 marks a major milestone in Tempo’s development. When planning your upgrade, consider these factors:

• Breaking changes:
  • Renamed, removed, and moved configurations are described in section below.
  • The TempoRequestErrors alert was removed from mixin. Any Jsonnet users relying on this alert should copy this into their own environment.
• Advisory:
  • Changed defaults – Are these updates relevant for your installation?
  • TraceQL editor needs to be enabled in Grafana to use the query editor.
  • Resource requirements have changed for Tempo 2.0 with the default configuration.

Once you upgrade to Tempo 2.0, there is no path to downgrade.

Check Tempo installation resource allocation

Parquet provides faster search and is required to enable TraceQL. However, the Tempo installation will require additional CPU and memory resources to use Parquet efficiently. Parquet is more costly due to the extra work of building the columnar blocks, and operators should expect at least 1.5x increase in required resources to run a Tempo 2.0 cluster. Most users will find these extra resources are negligible compared to the benefits that come from the additional features of TraceQL and from storing traces in an open format.

You can can continue using the previous v2 block format using the instructions provided in the Parquet configuration documentation. Tempo will continue to support trace by id lookup on the v2 format for the foreseeable future.

Enable TraceQL in Grafana

TraceQL is enabled by default in Tempo 2.0. The TraceQL query editor requires Grafana 9.3.2 and later.

The TraceQL query editor is in beta in Grafana 9.3.2 and needs to be enabled with the traceqlEditor feature flag.

Check configuration options for removed and renamed options

The following tables describe the parameters that have been removed or renamed.

Removed and replaced

query_frontend:
  query_shards:

querier:
  query_timeout:

ingester:
  use_flatbuffer_search:

Renamed

The following compactor configuration parameters were renamed.

compaction:
  chunk_size_bytes:

compaction:
  flush_size_bytes:

compaction:
  iterator_buffer_size:

The following storage configuration parameters were renamed.

wal:
  encoding:

block:
  index_downsample_bytes:

block:
  index_page_size_bytes:

block:
  encoding:

block:
  row_group_size_bytes:

The Azure Storage configuration section now uses snake case with underscores (_) instead of dashes (-). Example of using snake case on Azure Storage config:

yaml Copy

# config.yaml
storage:
  trace:
    azure:
      storage_account_name:
      storage_account_key:
      container_name: