Metrics collection (Prometheus) in Microservices - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

Prometheus Query Output for HTTP Request Count

Given a Prometheus metric http_requests_total that counts all HTTP requests, what is the output of this query?

sum(rate(http_requests_total[5m]))

Assume the metric increments by 10 requests every minute consistently.

Microservices

sum(rate(http_requests_total[5m]))

A 0.3333333

B 2

C 0.1666667

D 10

💡 Hint

Think about how rate calculates per second over the 5-minute window.

The rate function calculates the per-second average increase over the last 5 minutes. Since 10 requests happen every minute, that's 50 requests in 5 minutes. Dividing 50 by 300 seconds gives 0.1666667 per second. Summing over all instances (assuming 2 instances) doubles it to 0.3333333.

❓ Configuration

intermediate

Prometheus Scrape Configuration for Multiple Targets

Which Prometheus scrape configuration correctly scrapes metrics from two microservices running on ports 8080 and 9090 on the same host?

A

scrape_configs:
  - job_name: 'microservices'
    static_configs:
      - targets: ['localhost:8080 localhost:9090']

B

scrape_configs:
  - job_name: 'microservices'
    static_configs:
      - targets: ['localhost:8080']
      - targets: ['localhost:9090']

C

scrape_configs:
  - job_name: 'microservices'
    static_configs:
      - targets: ['localhost:8080', 'localhost:9090']

D

scrape_configs:
  - job_name: 'microservices'
    static_configs:
      - targets: ['localhost:8080;localhost:9090']

💡 Hint

Targets should be a list of strings, each string is host:port.

Option C correctly lists both targets as separate strings in a single list. Option C splits targets into two lists which is invalid. Options C and D use incorrect separators inside one string.

❓ Troubleshoot

advanced

Diagnosing Missing Metrics in Prometheus

You configured Prometheus to scrape a microservice, but no metrics appear for it in the Prometheus UI. Which of the following is the most likely cause?

A Prometheus is scraping metrics but the query used in UI is incorrect.

B Prometheus server is running but the disk is full.

C The microservice is exposing metrics but Prometheus scrape interval is set to 1 hour.

D The microservice is not exposing metrics on the configured endpoint.

💡 Hint

Check if the microservice endpoint for metrics is reachable and returns data.

If the microservice does not expose metrics on the expected endpoint, Prometheus cannot scrape any data. Disk full or scrape interval issues would cause delays or errors but not complete absence. Incorrect queries affect display, not scraping.

🔀 Workflow

advanced

Prometheus Alerting Workflow

Which sequence correctly describes the workflow for alerting when a microservice's error rate exceeds a threshold using Prometheus and Alertmanager?

A 2,1,3,4

B 1,2,3,4

C 1,3,2,4

D 3,1,2,4

💡 Hint

Think about the order from data collection to notification.

Prometheus first scrapes metrics, then evaluates alert rules, sends alerts to Alertmanager, which then sends notifications. Other orders break this logical flow.

✅ Best Practice

expert

Optimizing Prometheus Metrics for High-Cardinality Labels

Which approach is best to reduce performance issues caused by high-cardinality labels in Prometheus metrics?

A Remove or limit labels that have many unique values, such as user IDs or session tokens.

B Increase Prometheus scrape interval to reduce data points collected.

C Store all raw metrics in long-term storage without aggregation.

D Add more labels to better identify each metric uniquely.

💡 Hint

High-cardinality labels create many time series, which can slow down Prometheus.

Removing or limiting labels with many unique values reduces the number of time series, improving performance. Increasing scrape interval reduces data but doesn't fix cardinality. Storing all raw metrics increases load. Adding more labels increases cardinality.