Practice vocabulary for metrics instrumentation: counters, histograms, gauges, Prometheus client libraries, and cardinality management.
0 / 10 completed
1 / 10
A metric that only goes up and tracks how many times something has happened (e.g., total HTTP requests) is called:
The counter increments on each request — counters only go up (or reset to zero on restart). Use rate() in PromQL to compute per-second rates from counters.
2 / 10
A metric that samples and bins numeric observations to show statistical distribution (e.g., request latencies in p50/p95/p99) is called:
The histogram tracks request duration distribution — histograms bucket observations and allow calculating percentiles (e.g., histogram_quantile(0.95, ...) in Prometheus).
3 / 10
A metric that represents a current value that can go up or down (e.g., number of active connections right now) is called:
The gauge shows current active connections — unlike counters, gauges can decrease. Examples: active goroutines, memory usage, current queue depth.
4 / 10
The standard way to add metrics collection to an application is described as:
We instrument the application with Prometheus client library — Prometheus has official client libraries for Go, Python, Java, Ruby, and others that expose metrics via HTTP.
5 / 10
When too many unique label combinations are used in a metric (e.g., user_id as a label), causing memory and performance problems, this is called:
The metric cardinality explosion vocabulary — cardinality = number of unique time series. Using high-cardinality labels like user_id or request_id creates millions of series, overwhelming Prometheus.
6 / 10
Alex from the Performance team just commented on your PR: 'I'm seeing a spike in the request_duration_seconds metric. It's consistently above 500ms for requests originating from users in Europe. Can you investigate?'. Which term best describes this metric?
This metric, request_duration_seconds, is a classic Key Performance Indicator (KPI) because it directly measures a critical aspect of application performance. While anomaly detection tools *could* be used to alert on this, the comment itself highlights the specific KPI being monitored – response time – and its impact on users in Europe. Aggregate metrics are broader; this is focused on a single metric.
7 / 10
Sarah sent you the following Slack message: 'We need to understand the distribution of request latencies. The raw data is overwhelming – we're seeing a huge number of requests with very short durations alongside a smaller number with extremely long ones. How can we best visualize this?'. Which approach would be most appropriate?
Sarah's message indicates a need to understand the *distribution* of request latencies. Generating percentiles (p50, p95, p99) is the standard practice for visualizing this type of data – it provides a concise representation of how latency values are spread out. A simple line chart wouldn't capture the distribution; a scatter plot would be too noisy; and calculating standard deviation only tells you about the *spread* but not the shape.
8 / 10
You're reviewing the API response from your monitoring service. The following JSON is returned:
```json{
"metric_name": "active_connections",
"value": 125,
"timestamp": "2024-10-27T10:30:00Z"
}
```
What does the term 'value' in this context represent?
The 'value' field represents the *current* numerical value of the metric – in this case, the number of active connections at that specific timestamp. The timestamp indicates *when* that value was measured, while other fields would represent different aspects of connection behavior.
9 / 10
During a standup meeting, your team lead asks: 'How are we tracking the number of failed API calls?'. Which statement best describes the standard approach to adding this type of metric collection?
The standard way to add metric collection for failed API calls (or any event) is through a centralized metrics pipeline. This allows for automated data aggregation, real-time monitoring, and avoids the manual burden of tracking failures across multiple systems. Custom logging or spreadsheets are less scalable and prone to error.
10 / 10
You've noticed a performance issue with your application's metrics collection. The system is generating an extremely large number of metric events, and the memory usage is rapidly increasing. This situation is best described as:
'Metric cardinality' refers to the high volume of unique label combinations within your metrics – in this case, a large number of distinct user IDs or request types. This leads to an exponential increase in the number of metric events generated, overwhelming storage and processing capabilities. Data saturation is related but applies when the *volume* of data exceeds capacity; cardinality specifically addresses the diversity of labels.
What will I practise in "Metrics Instrumentation Vocabulary"?
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.