High Cardinality Span Name

Problem

A service is generating span names that embed variable data: user IDs, order numbers, full SQL statements. Span names are meant to identify the operation, so when each request produces a new name, nothing can be grouped: every operation looks unique.

Insights tracks unique span names per service over a 24-hour rolling window and flags the service once it passes 1,000 unique names.

Impact

• Trace search slows down as name indexes balloon.
• Service maps and latency breakdowns break: there’s no “the checkout endpoint”, only a million one-off operations.
• Sampling policies misfire, treating every request as a brand-new operation.

Example

Unique per request:

GET /users/981237/orders/55672
SELECT * FROM orders WHERE id=987654

Groupable:

GET /users/{user_id}/orders/{order_id}
SELECT orders

How to fix

1. Use the route template, not the resolved URL, as the HTTP span name; most instrumentation libraries do this once route information is available to them.
2. For database spans, name them by operation and table; put the full statement in the db.query.text attribute if you need it.
3. Move any remaining variable data into span attributes, where cardinality is expected.

Expected gains

Operations group again: latency percentiles per endpoint, working service maps, effective sampling, and a much smaller trace index.

See the Insights catalog for everything Insights can detect.