Why Prometheus exporter in Nginx? - Purpose & Use Cases

The Big Idea

What if you could watch your website's health like a heartbeat monitor, catching problems before they grow?

The Scenario

Imagine you run a busy website using nginx. You want to know how many visitors come, how fast pages load, and if any errors happen. Without tools, you open logs and count lines by hand or guess from random checks.

The Problem

This manual way is slow and tiring. Logs are huge and hard to read. You might miss important problems or react too late. It feels like searching for a needle in a haystack every time.

The Solution

Using a Prometheus exporter for nginx changes everything. It automatically collects key data like visitor counts and response times. It sends this info in a clear format to Prometheus, so you can watch your site health live and get alerts fast.

Before vs After

✗ Before

tail -f /var/log/nginx/access.log | grep '200' | wc -l

✓ After

curl http://localhost:9113/metrics | grep nginx_http_requests_total

What It Enables

It lets you see your website's performance and problems instantly, so you fix issues before users notice.

Real Life Example

A company uses the nginx Prometheus exporter to track traffic spikes and error rates. When errors rise, their team gets alerts and fixes the problem quickly, keeping customers happy.

Key Takeaways

Manual log checks are slow and error-prone.

Prometheus exporter automates data collection from nginx.

Real-time monitoring helps catch and fix issues fast.

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