This set builds vocabulary for high-cardinality tracing and exploratory data slicing during debugging.
0 / 5 completed
1 / 5
At standup, a dev describes querying high-cardinality trace data by arbitrary fields, like a specific user ID or request ID, without predefined dashboards. Which capability fits?
High-cardinality querying lets an engineer filter and group trace data by fields with many unique values, like a specific user or request ID, on the fly, rather than being limited to whatever dimensions a predefined dashboard happens to expose. Platforms built around this, like Honeycomb, are designed specifically to make this kind of exploratory querying fast. This flexibility matters most when debugging an issue affecting a narrow, specific slice of traffic.
2 / 5
During a design review, the team wants to break down request latency by an arbitrary combination of dimensions, like region and customer tier, during a live investigation. Which practice supports this?
Exploratory data slicing lets an engineer combine and recombine dimensions like region and customer tier on the fly while investigating an issue, following the data wherever the evidence leads rather than being constrained to pre-built dashboard views. This flexibility is especially valuable for debugging novel or unanticipated failure modes. It contrasts with a purely dashboard-driven monitoring workflow.
3 / 5
In a code review, a dev adds a custom field to a trace span capturing a business-specific attribute, like a feature flag's value during that request. What does this practice represent?
Enriching traces with custom fields, like a feature flag's value or a business-specific identifier, attaches context beyond generic technical metadata, making it possible to later query and correlate issues with business-relevant conditions. This enrichment turns generic tracing into a tool tailored to the application's actual domain. It requires deliberate instrumentation choices by the development team.
4 / 5
An incident report shows an investigation was slowed because traces lacked any high-cardinality identifiers, forcing the team to guess which requests were affected. What practice would prevent this?
Without high-cardinality identifiers like a specific request or user ID captured in traces, an investigation is left guessing which requests were actually affected instead of querying for them directly. Deliberately instrumenting for this upfront pays off precisely during an incident when specificity matters most. This is a core argument for observability tooling built to handle high-cardinality data well.
5 / 5
During a PR review, a teammate asks why the team invests in tooling optimized for high-cardinality queries instead of relying solely on traditional low-cardinality dashboards. What is the reasoning?
A predefined, low-cardinality dashboard can only answer the specific questions it was built to answer, while high-cardinality querying supports investigating novel issues by slicing data along dimensions no one anticipated in advance. This flexibility is particularly valuable for debugging rare or unusual production issues. The tradeoff is often higher data volume and storage cost to retain that granularity.