Nginx Plus monitoring - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to enable the Nginx Plus status page.

Nginx

location /status {
    stub_status [1];
}

Drag options to blanks, or click blank then click option'

Atrue

Boff

Con

Denabled

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'off' instead of 'on' disables the status page.

Using 'enabled' or 'true' is not valid syntax.

The stub_status on; directive enables the Nginx status page.

2fill in blank

medium

Complete the code to allow access to the Nginx Plus status page only from localhost.

Nginx

location /status {
    allow [1];
    deny all;
}

Drag options to blanks, or click blank then click option'

A0.0.0.0

B127.0.0.1

C192.168.1.1

Dlocalhost

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'localhost' is not valid in the allow directive.

Allowing '0.0.0.0' grants access to all IPs.

The IP 127.0.0.1 represents localhost, allowing only local access.

3fill in blank

hard

Fix the error in the configuration to enable the Nginx Plus API endpoint.

Nginx

location /api {
    api [1];
}

Drag options to blanks, or click blank then click option'

Aon

Bactivate

Ctrue

Denable

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'enable' or 'activate' causes syntax errors.

Using 'true' is not recognized by Nginx.

The correct directive to enable the API is api on;.

4fill in blank

hard

Fill both blanks to configure the Nginx Plus API to listen on port 8080 and allow only local access.

Nginx

server {
    listen [1];
    location /api {
        allow [2];
        deny all;
        api on;
    }
}

Drag options to blanks, or click blank then click option'

A8080

B127.0.0.1

C0.0.0.0

D80

Attempts:

3 left

💡 Hint

Common Mistakes

Using port 80 instead of 8080 for the API.

Allowing '0.0.0.0' grants access to everyone.

Port 8080 is commonly used for API endpoints, and 127.0.0.1 restricts access to localhost.

5fill in blank

hard

Fill all three blanks to create a status page with JSON format, enabled stub_status, and allow access from localhost.

Nginx

location /status {
    stub_status [1];
    status_format [2];
    allow [3];
    deny all;
}

Drag options to blanks, or click blank then click option'

Aon

Bjson

C127.0.0.1

Doff

Attempts:

3 left

💡 Hint

Common Mistakes

Forgetting to enable stub_status.

Using 'off' instead of 'on' disables status.

Allowing access from all IPs instead of localhost.

Enable stub_status with on, set status_format json; for JSON output, and allow localhost access with 127.0.0.1.

Practice

1. What is the main purpose of the Nginx Plus monitoring API endpoint?

easy

A. To provide live data about server traffic and health

B. To serve static website files

C. To configure SSL certificates automatically

D. To block unwanted IP addresses

Solution

1. Step 1: Understand Nginx Plus monitoring role

   Nginx Plus monitoring API endpoint is designed to show live server data such as traffic, errors, and health.

2. Step 2: Identify the correct purpose

   Serving static files, configuring SSL, or blocking IPs are unrelated to monitoring API.

3. Final Answer:

   To provide live data about server traffic and health -> Option A

4. Quick Check:

   Monitoring API = live server data [OK]

Hint: Monitoring API shows live server info, not config or files [OK]

Common Mistakes:

• Confusing monitoring API with static file serving
• Thinking it manages SSL certificates
• Assuming it blocks IP addresses

2. Which configuration snippet correctly enables Nginx Plus monitoring API at the path /api?

easy

A. location /api { api; }

B. location /api { proxy_pass http://backend; }

C. location /api { return 404; }

D. location /api { root /var/www/html; }

Solution

1. Step 1: Recall correct syntax for enabling Nginx Plus API

   The directive api; inside a location block enables the monitoring API endpoint.

2. Step 2: Compare options

   Only location /api { api; } uses api; directive. Others proxy, return 404, or serve files, which do not enable monitoring API.

3. Final Answer:

   location /api { api; } -> Option A

4. Quick Check:

   Enable API = location with api; directive [OK]

Hint: Use 'location /api { api; }' to enable monitoring [OK]

Common Mistakes:

• Using proxy_pass instead of api directive
• Returning 404 disables the endpoint
• Serving files does not enable API

3. Given this Nginx Plus config snippet, what will be the output when accessing /api?

location /api {
    api;
}

medium

A. A 404 Not Found error

B. A JSON response with live server metrics

C. The contents of /api directory on disk

D. A redirect to another URL

Solution

1. Step 1: Understand the api; directive effect

   The api; directive enables the Nginx Plus monitoring API, which returns live server data in JSON format.

2. Step 2: Analyze the response type

   Accessing /api returns JSON with metrics, not a 404, file contents, or redirect.

3. Final Answer:

   A JSON response with live server metrics -> Option B

4. Quick Check:

   api; returns JSON metrics [OK]

Hint: api; returns JSON live metrics at /api [OK]

Common Mistakes:

• Expecting file contents instead of JSON
• Thinking it returns 404 error
• Assuming it redirects

4. You added this config to enable Nginx Plus monitoring but get a 404 error when accessing /api:

location /api {
    api
}

What is the likely cause?

medium

A. The api directive requires a parameter

B. Wrong location path, should be /monitor

C. Nginx Plus monitoring is not supported on this server

D. Missing semicolon after api directive

Solution

1. Step 1: Check syntax of the api directive

   The api directive must end with a semicolon (api;). Missing it causes config errors and 404 responses.

2. Step 2: Evaluate other options

   The location path /api is correct, monitoring is supported, and api directive takes no parameters.

3. Final Answer:

   Missing semicolon after api directive -> Option D

4. Quick Check:

   Directive missing semicolon = 404 error [OK]

Hint: Always end directives with semicolon ; [OK]

Common Mistakes:

• Omitting semicolon after api directive
• Changing location path unnecessarily
• Assuming api directive needs parameters

5. You want to monitor multiple Nginx Plus servers centrally. Which approach using the monitoring API is best?

hard

A. Use location /api { proxy_pass http://backend; } to forward monitoring requests

B. Set up a single Nginx Plus server with location /api { api; } and proxy all traffic through it

C. Configure each server with location /api { api; } and use a script to fetch JSON from each server's /api endpoint

D. Disable the monitoring API and use log files only

Solution

1. Step 1: Understand monitoring API usage per server

   Each Nginx Plus server exposes its own live data at /api when configured with api;.

2. Step 2: Centralize monitoring by fetching data

   A script or tool can query each server's /api endpoint to collect and aggregate metrics centrally.

3. Step 3: Evaluate other options

   Proxying all traffic through one server or disabling API loses direct live data. Proxy_pass does not enable monitoring API.

4. Final Answer:

   Configure each server with location /api { api; } and use a script to fetch JSON from each server's /api endpoint -> Option C

5. Quick Check:

   Each server exposes API; central script collects data [OK]

Hint: Enable api; on each server, fetch data centrally via script [OK]

Common Mistakes:

• Trying to proxy monitoring API through one server
• Disabling API and relying only on logs
• Misusing proxy_pass for monitoring API