▎Introduction

Health checks are vital for ensuring high availability and fault tolerance in web applications. NGINX, a powerful web server, provides various methods for implementing health checks. This guide explores how to configure NGINX for both active and passive health checks, enhancing the robustness and reliability of your services.

▎What are Health Checks?

Health checks are tests conducted by load balancers or reverse proxies to assess if a backend server can handle requests. Active health checks proactively test servers at regular intervals, while passive health checks monitor ongoing traffic and flag servers as unhealthy when errors exceed a specified threshold.

▎Active Health Checks

Here's a basic configuration for active health checks in NGINX:

http {
    upstream backend {
        server backend1.example.com;
        server backend2.example.com;
        check interval=3000 rise=2 fall=5 timeout=1000 type=http;
        check_http_send "HEAD /health HTTP/1.1rnHost: localhostrnConnection: closernrn";
        check_http_expect_alive http_2xx http_3xx;
    }

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

In this setup, NGINX sends a HEAD request to the /health endpoint every 3 seconds. A server is deemed healthy if it returns a 2xx or 3xx HTTP status code twice in succession (rise=2). If it fails to respond correctly 5 times consecutively (fall=5), it is marked unhealthy.

▎Passive Health Checks

For passive health checks, NGINX analyzes live traffic. Here’s the configuration:

stream {
    upstream backend {
        server backend1.example.com;
        server backend2.example.com max_fails=2 fail_timeout=30s;
    }

    server {
        listen 80;
        proxy_pass backend;
        proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
    }
}

In this configuration, if a backend server fails to respond correctly twice within 30 seconds (max_fails=2, fail_timeout=30s), it is temporarily removed from the pool. The proxy_next_upstream directive specifies which errors will trigger a retry with a different server.

▎Advanced Health Check Configurations

For more complex scenarios, consider this advanced configuration using shared memory zones and custom failure detection:

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

        health_check
        match=healthy
        interval=2000
        fails=3
        passes=1
        uri=/custom_check;
    }

    match healthy {
        status 200-399;
    }

    server {
        location / {
            proxy_pass http://backend;
            proxy_set_header Host $host;
        }
    }
}

This example includes a health_check block that conducts checks every 2 seconds, with specific conditions for failing and passing. The status codes that indicate a healthy server are defined in a separate match block labeled healthy.

▎Testing and Troubleshooting Health Checks

To verify your health checks, use NGINX’s logging capabilities:

server {
    location / {
        proxy_pass http://backend;
        access_log /var/log/nginx/backend_access.log;
        error_log /var/log/nginx/backend_error.log;
    }

    location /health {
        access_log /var/log/nginx/health_access.log;
        proxy_pass http://backend;
    }
}

By directing access logs for the health check endpoint to a separate file, you can easily monitor their status. The error log is useful for troubleshooting any issues.

▎Automating Health Checks with NGINX Plus

NGINX Plus users benefit from dynamic health checks and an intuitive dashboard for management. The configuration process is straightforward:

[Continue with configuration details specific to NGINX Plus.]





#nginx #ha #load #balancing #linux #net

https://t.me/unixmens