Prometheus exporter in Nginx - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

Prometheus Nginx Exporter Metrics Endpoint Output

You have configured the Prometheus Nginx exporter to expose metrics at http://localhost:9113/metrics. What is the expected output when you curl this endpoint?

Nginx

curl http://localhost:9113/metrics

A A binary file download containing compressed metrics data

B A JSON object with keys 'active_connections' and 'total_requests' showing numeric values

C A plain text list of metrics including lines like 'nginx_connections_active 5' and 'nginx_http_requests_total 12345'

D An HTML page showing graphs of Nginx metrics

💡 Hint

Prometheus exporters expose metrics in a simple text format for scraping.

Prometheus exporters expose metrics as plain text with metric names and values, not JSON or HTML.

❓ Configuration

intermediate

Configuring Nginx for Prometheus Exporter

Which Nginx configuration snippet correctly enables the stub_status module at /nginx_status for Prometheus exporter scraping?

A location /nginx_status { stub_status; allow 127.0.0.1; deny all; }

B location /nginx_status { return 404; }

C location /nginx_status { proxy_pass http://localhost:9113; }

D location /nginx_status { autoindex on; }

💡 Hint

The stub_status directive provides basic Nginx metrics.

The stub_status directive enables Nginx to expose metrics at the specified location, allowing Prometheus exporter to scrape them.

❓ Troubleshoot

advanced

Prometheus Exporter Fails to Scrape Nginx Metrics

You configured Prometheus to scrape Nginx metrics from http://localhost:9113/metrics, but no data appears in Prometheus. What is the most likely cause?

A The Nginx stub_status endpoint is not enabled or accessible

B Prometheus server is not running on port 9113

C Nginx is running on a different server than Prometheus exporter

D Prometheus uses JSON format but exporter provides plain text

💡 Hint

Check if Nginx exposes metrics for the exporter to collect.

If the stub_status endpoint is not enabled or blocked, the exporter cannot collect metrics, so Prometheus sees no data.

🔀 Workflow

advanced

Steps to Add Nginx Metrics to Prometheus Monitoring

What is the correct order of steps to add Nginx metrics to Prometheus using the Prometheus Nginx exporter?

A 1,4,2,3

B 1,2,4,3

C 2,1,3,4

D 1,2,3,4

💡 Hint

Think about enabling metrics first, then running exporter, then configuring Prometheus.

First enable stub_status, then run exporter to collect metrics, then configure Prometheus to scrape, finally reload services.

✅ Best Practice

expert

Securing Nginx Metrics Endpoint for Prometheus Exporter

Which method is the best practice to secure the Nginx stub_status endpoint exposed for Prometheus scraping?

A Use basic authentication with a username and password

B Allow access only from Prometheus server IP and deny all others

C Expose the endpoint publicly without restrictions for easy access

D Disable stub_status and rely on logs for metrics

💡 Hint

Limit access to trusted sources only.

Restricting access by IP ensures only Prometheus can scrape metrics, reducing security risks.

Practice

1. What is the main purpose of the stub_status module in nginx when used with Prometheus?

easy

A. To expose basic nginx metrics like active connections and requests

B. To serve static web pages faster

C. To block unauthorized IP addresses

D. To cache dynamic content for faster delivery

Solution

1. Step 1: Understand stub_status role

   The stub_status module provides a simple status page with metrics like active connections, accepts, handled, and requests.

2. Step 2: Connect stub_status to Prometheus

   Prometheus scrapes these metrics from the URL where stub_status is enabled to monitor nginx performance.

3. Final Answer:

   To expose basic nginx metrics like active connections and requests -> Option A

4. Quick Check:

   stub_status exposes metrics = C [OK]

Hint: stub_status shows nginx metrics, not content or blocking [OK]

Common Mistakes:

• Thinking stub_status caches content
• Confusing stub_status with IP blocking
• Assuming stub_status serves web pages

2. Which nginx configuration snippet correctly enables stub_status at the URL /metrics and restricts access to 127.0.0.1?

easy

A. location /metrics { stub_status on; allow all; }

B. location /metrics { stub_status; }

C. location /metrics { stub_status; allow 127.0.0.1; deny all; }

D. location /metrics { stub_status on; }

Solution

1. Step 1: Check stub_status syntax

   The correct directive is stub_status; without 'on'. It must be inside a location block.

2. Step 2: Verify access control

   To protect metrics, use allow 127.0.0.1; and deny all; inside the location.

3. Final Answer:

   location /metrics { stub_status; allow 127.0.0.1; deny all; } -> Option C

4. Quick Check:

   stub_status syntax + IP allow/deny = A [OK]

Hint: stub_status has no 'on'; protect with allow/deny [OK]

Common Mistakes:

• Using 'stub_status on;' which is invalid
• Not adding IP allow/deny rules
• Missing semicolon after stub_status

3. Given this nginx stub_status output scraped by Prometheus:

Active connections: 5
server accepts handled requests
 100 100 200
Reading: 1 Writing: 2 Waiting: 2

What is the value of 'Active connections' metric?

medium

A. 1

B. 100

C. 200

D. 5

Solution

1. Step 1: Identify Active connections line

   The first line shows 'Active connections: 5', so the active connections count is 5.

2. Step 2: Differentiate other numbers

   Numbers 100 and 200 relate to accepts, handled, and requests, not active connections.

3. Final Answer:

   5 -> Option D

4. Quick Check:

   Active connections = 5 [OK]

Hint: Active connections is the first number after label [OK]

Common Mistakes:

• Confusing accepts or requests with active connections
• Picking the largest number instead of the labeled one
• Ignoring the label and choosing Reading/Writing values

4. You configured nginx with stub_status at /metrics but Prometheus shows 'connection refused'. What is the most likely cause?

medium

A. nginx is not running or listening on the expected port

B. The stub_status directive is misspelled as stubstatus

C. Prometheus URL is missing the trailing slash

D. The location /metrics block is missing a root directive

Solution

1. Step 1: Understand 'connection refused' meaning

   This error means Prometheus cannot connect to nginx, likely because nginx is down or not listening on the port.

2. Step 2: Check other options

   Misspelling stub_status causes config errors but not connection refused. Missing slash or root directive won't cause connection refused.

3. Final Answer:

   nginx is not running or listening on the expected port -> Option A

4. Quick Check:

   Connection refused = nginx down or port closed [OK]

Hint: Connection refused means no server listening on port [OK]

Common Mistakes:

• Assuming URL slash causes connection refused
• Thinking config typos cause connection refused
• Believing root directive is required for stub_status

5. You want to expose nginx metrics at /metrics only to Prometheus server IP 10.0.0.5. Which configuration snippet correctly achieves this?

hard

A. location /metrics { stub_status on; allow 10.0.0.5; deny all; }

B. location /metrics { stub_status; allow 10.0.0.5; deny all; }

C. location /metrics { stub_status; allow all; deny 10.0.0.5; }

D. location /metrics { stub_status; deny all; allow 10.0.0.5; }

Solution

1. Step 1: Use correct stub_status syntax

   The directive is stub_status; without 'on'. It must be inside the location block.

2. Step 2: Apply IP allow/deny rules correctly

   To allow only 10.0.0.5, use allow 10.0.0.5; then deny all;. Order matters: allow first, then deny.

3. Final Answer:

   location /metrics { stub_status; allow 10.0.0.5; deny all; } -> Option B

4. Quick Check:

   Correct stub_status + allow IP then deny all = B [OK]

Hint: Allow IP first, then deny all; stub_status has no 'on' [OK]

Common Mistakes:

• Using 'stub_status on;' which is invalid
• Reversing allow and deny order
• Allowing all and denying the IP instead