In this section, we will explore how to monitor the health of applications using NGINX Plus. Application health monitoring is crucial for maintaining the reliability and performance of your web services. NGINX Plus offers advanced features that allow you to monitor the status of your applications and take action when issues arise.

Key Concepts

  1. Health Checks: Regularly checking the status of backend servers to ensure they are operational.
  2. Active Health Checks: Proactively sending requests to backend servers to verify their health.
  3. Passive Health Checks: Monitoring the responses from backend servers to determine their health.
  4. Status API: An API provided by NGINX Plus to retrieve detailed metrics and status information.

Active Health Checks

Active health checks involve NGINX Plus sending requests to backend servers at regular intervals to verify their health. If a server fails to respond correctly, it is marked as unhealthy and removed from the load balancing pool.

Configuration Example

http {
    upstream backend {
        zone backend 64k;
        server backend1.example.com;
        server backend2.example.com;

        # Active health check configuration
        health_check interval=5s fails=3 passes=2;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://backend;
        }
    }
}

Explanation

  • interval=5s: NGINX Plus will send a health check request every 5 seconds.
  • fails=3: A server will be marked as unhealthy after 3 consecutive failed health checks.
  • passes=2: A server will be marked as healthy after 2 consecutive successful health checks.

Passive Health Checks

Passive health checks monitor the responses from backend servers during normal traffic. If a server returns an error response, it is marked as unhealthy.

Configuration Example

http {
    upstream backend {
        zone backend 64k;
        server backend1.example.com;
        server backend2.example.com;

        # Passive health check configuration
        proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://backend;
        }
    }
}

Explanation

  • proxy_next_upstream: Specifies the conditions under which NGINX Plus will consider a server unhealthy and try the next server in the upstream group.

Status API

NGINX Plus provides a Status API that offers detailed metrics and status information about the server and upstream groups.

Configuration Example

http {
    server {
        listen 8080;

        location /status {
            api;
            allow 127.0.0.1;
            deny all;
        }
    }
}

Explanation

  • api: Enables the Status API.
  • allow 127.0.0.1: Allows access to the Status API from localhost.
  • deny all: Denies access to the Status API from all other IP addresses.

Accessing the Status API

You can access the Status API by navigating to http://localhost:8080/status in your web browser or using a tool like curl:

curl http://localhost:8080/status

Practical Exercise

Exercise

  1. Configure an upstream group with two backend servers.
  2. Set up active health checks with an interval of 10 seconds, marking a server as unhealthy after 2 failed checks and healthy after 1 successful check.
  3. Enable passive health checks to mark a server as unhealthy if it returns a 500, 502, 503, or 504 error.
  4. Configure the Status API to be accessible only from localhost.

Solution

http {
    upstream backend {
        zone backend 64k;
        server backend1.example.com;
        server backend2.example.com;

        # Active health check configuration
        health_check interval=10s fails=2 passes=1;

        # Passive health check configuration
        proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://backend;
        }
    }

    server {
        listen 8080;

        location /status {
            api;
            allow 127.0.0.1;
            deny all;
        }
    }
}

Common Mistakes and Tips

  • Incorrect Interval Settings: Setting the interval too low can cause unnecessary load on your backend servers. Adjust the interval based on your application's needs.
  • Ignoring Passive Health Checks: Relying solely on active health checks can miss issues that occur during normal traffic. Combining both active and passive checks provides a more comprehensive monitoring solution.
  • Status API Security: Always restrict access to the Status API to prevent unauthorized access to sensitive information.

Conclusion

In this section, we covered the essential aspects of application health monitoring using NGINX Plus. We explored active and passive health checks, configured the Status API, and provided practical examples and exercises. Understanding and implementing these monitoring techniques will help ensure the reliability and performance of your web services. In the next section, we will delve into dynamic configuration with NGINX Plus.

© Copyright 2024. All rights reserved