tempo-k8s docs - Manage tracing storage
Traces are high-volume, and production deployments can rapidly generate large amounts of data that are expensive to store. You can manage your storage footprint using two primary methods: retention policies (deleting old data) and ingestion sampling (limiting incoming data).
Configure the maximum retention period
The most direct way to limit storage consumption is by setting a maximum retention period. This instructs the compactor component to periodically delete all traces older than your specified limit.
The baseline, recommended limit (which is also the default in tempo-coordinator-k8s), is 30 days (720 hours). Depending on your operational needs (and your storage capabilities), you can choose to increase or decrease that limit at will.
To configure the retention period (for example, to 24 hours) on the tempo-coordinator-k8s charm, use the retention-period config option:
juju config tempo retention-period=24
Configure trace sampling in the collector
You can reduce the volume of data passed to Tempo by configuring sampling rates within the opentelemetry-collector or opentelemetry-collector-k8s charms. This allows you to store only a representative percentage of your total traces.
You can apply different sampling rates depending on whether the trace comes from the charms, the workload, or contains errors.
| Target | Description | Example command |
|---|---|---|
| Charm traces | Traces generated by the charm. | juju config opentelemetry-collector tracing_sampling_rate_charm=20.0 |
| Workload traces | Traces generated by your applications. | juju config opentelemetry-collector tracing_sampling_rate_workload=0.1 |
| Error traces | Traces containing errors. | juju config opentelemetry-collector tracing_sampling_rate_error=100.0 |
See more:
opentelemetry-collector-k8sconfiguration reference;opentelemetry-collectorconfiguration reference
Last updated 5 days ago.