Prometheus exporter in Nginx - Time & Space Complexity

Time Complexity: Prometheus exporter

O(1)

Understanding Time Complexity

When using nginx as a Prometheus exporter via stub_status, it is important to understand how the time to collect metrics grows as the number of monitored endpoints increases.

We want to know how the work done by nginx scales when exporting metrics to Prometheus.

Scenario Under Consideration

Analyze the time complexity of the following nginx configuration snippet for Prometheus metrics export.

server {
    listen 9113;
    location /metrics {
        stub_status;
        access_log off;
    }
}
    

This snippet configures nginx to expose its status metrics on port 9113 for Prometheus to scrape.

Identify Repeating Operations

Identify the loops, recursion, array traversals that repeat.

• Primary operation: nginx reads global counters and formats fixed status metrics each time Prometheus scrapes the /metrics endpoint.
• How many times: Once per scrape request, which happens repeatedly over time. No loops over connections.

How Execution Grows With Input

The stub_status module maintains aggregate counters (e.g., total requests, active connections) updated atomically. Generating the output reads these counters in constant time.

Input Size (active connections)	Approx. Operations
10	Constant: read counters & format
100	Constant: read counters & format
1000	Constant: read counters & format

Pattern observation: The work to generate metrics is constant time, independent of active connections or requests, as no iteration occurs.

Final Time Complexity

Time Complexity: O(1)

This means the time to generate metrics is constant per scrape, regardless of load on nginx.

Common Mistake

[X] Wrong: "The metrics export time grows linearly with the number of active connections."

[OK] Correct: nginx stub_status uses pre-maintained global counters; no traversal of connections is needed. Output is always a fixed small number of lines.

Interview Connect

Understanding that basic nginx monitoring is O(1) helps evaluate when to use it vs. more complex exporters. Shows knowledge of real-world performance characteristics.

Self-Check

"What if nginx cached the metrics output instead of generating it fresh on each scrape? How would the time complexity change?"

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