Practise the language of controlling metric cardinality: high-cardinality labels, cardinality explosion, label dropping, and cost control.
0 / 10 completed
1 / 10
The number of unique label-value combinations for a metric is its ___.
Cardinality is the count of distinct time series produced by a metric's label combinations; it drives storage and query cost.
2 / 10
Adding a label like user_id or request_id can cause a cardinality ___.
Unbounded labels (per-user, per-request IDs) multiply series count enormously, an explosion that can overwhelm a metrics backend.
3 / 10
Removing a problematic label before ingestion to cut series count is label ___.
Dropping (or aggregating away) a high-cardinality label reduces series count, trading per-label detail for sustainable cost.
4 / 10
High-cardinality detail such as a specific request ID belongs better in ___ than in metrics.
Per-request identifiers fit traces and logs, which are designed for high-cardinality lookup, whereas metrics should stay low-cardinality and aggregatable.
5 / 10
Capping how many distinct values a label may have to protect the backend is a cardinality ___.
A cardinality limit (or budget) bounds the series a metric can create, preventing a single bad label from exhausting capacity.
6 / 10
Sarah from the Data Governance team just commented on your PR: 'I'm seeing a really high cardinality on the user_id label in our daily performance dashboard. It's spiking significantly during peak hours. What does this likely indicate?'
High cardinality on a label like user_id often points to a problem with data quality. Duplicate IDs or a large number of distinct users generating requests will dramatically increase the cardinality count, impacting dashboard performance and potentially misleading aggregations. The key is identifying *why* there are so many unique values.
7 / 10
You're drafting a PR description for a change that adds a new label: transaction_timestamp to the event stream. Your team lead asks: 'How will this impact our cardinality management strategy?'
The frequency with which a label is updated directly drives its cardinality. A rapidly changing timestamp (e.g., high-frequency transactions) will result in a much larger number of distinct values compared to a less volatile label like user_id. Adding new labels without considering their potential impact on cardinality can quickly overwhelm systems.
8 / 10
During the daily standup meeting, Mark asks: 'We've noticed a significant increase in the number of unique requests processed today. How can we proactively manage this rising cardinality?'
The root cause of rising cardinality is often data quality – duplicate or near-duplicate identifiers. While monitoring and scaling are important, addressing the *source* of the problem (e.g., faulty logging) is crucial for long-term cardinality management. Simply increasing database size won't solve a fundamental issue.
9 / 10
You receive the following API response from our metrics service: `{'metric_name': 'request_latency', 'cardinality': 1234567}`. A colleague asks: 'What does this high cardinality value mean?'
The cardinality value in this response reflects the *number of distinct values* recorded for that specific metric (request_latency) within the given time window. It doesn't directly represent the total number of requests or indicate a performance bottleneck – those require further investigation based on other metrics.
10 / 10
Your team is designing a new system for tracking user engagement. You want to limit the number of distinct values that can be stored for the session_duration label to prevent performance issues. Which approach would best achieve this?
Capping cardinality is a core technique to control resource consumption. By setting a limit on the number of distinct values for session_duration, you prevent individual high-cardinality values from dominating storage and processing resources. This ensures that aggregations remain performant.
What will I practise in "Metric Cardinality Management Language"?
This module focuses on Observability Engineering — real workplace phrasing you'll use on the job. It contains 10 scenario-based multiple-choice questions with instant feedback.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account or sign-up required.
How many questions does this exercise have?
This module includes 10 questions. Each one gives an immediate right/wrong result plus a full explanation of the correct phrasing.
What happens if I answer a question incorrectly?
You'll see the correct answer highlighted straight away, along with a plain-English explanation of why it's right and why the other options don't fit — mistakes are part of the learning here.
Can I retry the exercise if I want a better score?
Yes — use the 'Try again' button on the results screen to reset your score and go through the questions again. There's no limit on attempts.
Who is this Observability Engineering exercise for?
It's aimed at IT professionals with working English who want to sound more natural and precise around observability engineering — useful whether you're preparing for real conversations at work or just building confidence with the vocabulary.
Do I need an account to track my progress?
No account is needed. Your progress through the exercise is tracked locally in your browser for the current session, and you can replay the module at any time.
How is this different from reading a blog article?
This exercise is an interactive drill that tests and reinforces specific phrasing through multiple-choice questions with instant feedback, while blog articles explain concepts and vocabulary in prose. The two work well together.
Where can I find more Observability Engineering exercises?
See the Observability Engineering hub for more modules like this one, or browse the full Exercises page for other IT-English topics.
Can I complete this exercise on my phone?
Yes — every exercise on CoderSlingo is fully responsive and works on phones and tablets, so you can practise anywhere.