Prerequisites
- A known deployed version, one process identity and one metric expected to carry release identity.
- Read access to resource configuration, exported metrics and backend series labels; Python with opentelemetry-sdk and prometheus-client for the standalone example.
Before running the checks
python3 -m pip install opentelemetry-sdk prometheus-clientDiagnostic example
from opentelemetry.sdk.resources import Resource
from prometheus_client import CollectorRegistry, Counter, generate_latest
resource = Resource.create({"service.name": "checkout", "service.version": "1.2.0"})
assert resource.attributes["service.version"] == "1.2.0"
registry = CollectorRegistry()
requests = Counter("checkout_requests_total", "Requests",
["service", "version"], registry=registry)
requests.labels(resource.attributes["service.name"],
resource.attributes["service.version"]).inc()
text = generate_latest(registry).decode()
assert 'version="1.2.0"' in text
print(text)
# This explicit mapping is for a Prometheus client metric.
# It does not configure an OTel exporter or change stored historical series.
Connect your backend
Inspect the metric provider’s resource first; a version attribute on a span or tracer provider does not configure the meter provider. Then inspect the actual exporter path. OpenTelemetry resources may appear in target_info rather than on each metric, and label translation depends on the backend. Explicit bounded labels, selected attribute promotion, or an identity-safe info-metric join are different solutions. Choose the one supported by your pipeline. Do not enable blanket promotion of every resource attribute simply to recover version. The example shows explicit Prometheus client labels and is not an OTel exporter configuration.
Verification checklist
- Run the example to confirm that service.version exists on the resource and is explicitly copied into a version label in generated metric text.
- In a known deployed process, verify that the release value is correct and attached to the meter provider used by the metric. Recreate the provider/process on release rather than mutating old resource identity.
- Inspect exposition or OTLP payload, then stored series and target_info. Locate the first stage where the version is lost or represented differently.
- Check queries for label spelling/translation and aggregation that removes version. Inspect raw series before editing the dashboard.
- After correcting the mapping, verify new samples from both old and new rollout cohorts. Historical samples without version will not be retroactively relabeled.
Common failures
| Symptom | Check |
|---|---|
| Version is only in traces | Configure the metric provider resource or explicit metric labels; signal providers can be initialized independently. |
| Version appears only in target_info | Inspect supported attribute promotion or join using unique resource identity. Do not join only on service name across multiple instances. |
| Export contains version; backend does not | Check relabeling, remote-write/OTLP conversion and backend allowlists or translation settings. |
| Backend has version; dashboard does not | Retain version in aggregation grouping and use the actual stored label name. Avoid treating missing series as a healthy release. |