Observability / Intermediate: instrumentation and interpretation / Lesson 9

Resource identity and cardinality budgets

Keep service identity consistent across signals while distinguishing resource metadata, observation attributes, and unbounded identifiers that change telemetry cost and privacy.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Separate resource identity from event attributes.
Estimate bounded dimension combinations.
Review churn, diagnostic value, and privacy together.

Describe the entity producing the signal

An OpenTelemetry resource describes the entity associated with telemetry, such as a service instance or workload. Observation attributes describe a particular operation or measurement, while instrumentation scope identifies the producing library. Keep these roles distinct. A service name that changes with every request defeats service-level navigation, and an instance identifier alone cannot explain which application owns the data. Review the documented resource conventions and actual SDK detection behavior. Stable service identity across metrics, logs, and traces makes correlation possible, but it is not a guarantee that those signals cover identical populations or time windows.

Bound the values that create metric streams

Each unique combination of metric identity and attributes can create a separate stream, subject to the data model and backend representation. A route template can be bounded; a raw path with a parcel identifier may not be. Even useful dimensions multiply, and short-lived instance identifiers add churn over time. Do not select a limit from another team without examining workload and backend behavior. The offline estimate multiplies three declared dimensions and then adds a hypothetical unbounded event identifier. It is a simple combination bound, not a memory forecast or measured active-series count.

python Offline dimension multiplication

bounded_dimensions = [4, 6, 3]
combinations = 1
for count in bounded_dimensions:
    combinations *= count
print("bounded", combinations)
print("with_event_ids", combinations * 50_000)

Expected output

bounded 72
with_event_ids 3600000

Region, operation, and result allow 72 combinations in this model. Adding 50,000 distinct IDs permits 3,600,000 before other metric identities or churn.

Give every dimension a purpose and owner

A dimension review should state the question it answers, allowed values, expected churn, source authority, sensitivity, and removal consequences. Region may expose a partial outage; result class may distinguish validation from service failure. Parcel ID is useful for a restricted event investigation but unsuitable as a routine metric dimension. Removing all dimensions can save cost while hiding harm, so evaluate usefulness rather than simply minimizing count. The editorial record below keeps bounded operational context and explicitly rejects personal or per-event values. It is not a backend limit or a collector rule.

yaml Illustrative dimension policy

metric_dimension_review: parcel-processing
keep: [bounded-region, operation-family, result-class]
reject: [parcel-id, customer-email, raw-url]
resource_identity: stable-service-and-reviewed-instance-context
owner: instrumentation-contract-review
removal_check: preserve-required-diagnostic-slices

The policy is an editorial allowlist. Actual resource-to-label mapping and limits depend on the exporter and backend.

Inspect translation between data models

A resource attribute may be represented differently after export into another metrics system. Some attributes become labels or metadata, names may be normalized, and limits can drop or transform values. Do not assume that the queryable label set exactly matches the SDK record. Inspect documented mapping for the chosen exporter and backend and preserve a test fixture for required identity. A service rename can split history, while an overly broad normalization can merge unrelated entities. Cross-signal links should use deliberate stable keys and correct authorization rather than a visual name that happens to match.

Review cardinality as the system evolves

Watch new-value creation and churn, not only one active-series snapshot. A release that adds build identity or raw error text can expand streams dramatically without increasing user traffic. Review histogram bucket overhead and multiple metric families when estimating volume. Apply limits deliberately and observe the resulting dropped or overflowed data so consumers understand coverage. This lesson executes a fixed multiplication only; it does not query a monitoring system, scan label values, benchmark storage, or change limits. Any operational adjustment requires actual version-specific behavior and evidence that useful diagnosis remains possible.

Common errors and fixes

Every request creates a new metric stream

Why it happens: An unbounded identifier became a dimension.
How to fix it: Replace it with a bounded operation family and use appropriate event evidence.
Prevent it next time: Review allowed values before instrumentation changes.

Cross-signal links point at unrelated services

Why it happens: Identity normalization merged distinct resources.
How to fix it: Define stable keys and verify exporter mappings.
Prevent it next time: Test identity and authorization together.

A limit quietly hides important failures

Why it happens: Dropped or overflowed values were not observed.
How to fix it: Expose coverage changes and review the affected population.
Prevent it next time: Treat limits as data-contract changes.

Check your understanding

1. Should an instance identifier always be removed to reduce cost?

Show worked solution

No universal rule applies. It may be necessary to diagnose a single bad instance, and the exporter may represent it differently from ordinary dimensions. Evaluate value count, churn, required queries, and retention. Prefer deliberate aggregation or a suitable evidence path while preserving the ability to investigate relevant failures.

2. Why is raw error text a poor metric dimension?