상태 확인 및 서버 모니터링

Imagine a busy restaurant with multiple chefs. If one chef gets sick, you don't want to send orders to them, right?

In load balancing, health checks do exactly that. They constantly monitor backend servers to ensure they are ready to handle requests.

Without health checks, a load balancer might keep sending requests to a server that is down, overloaded, or unresponsive.

• Bad User Experience: Users get errors instead of content.
• Wasted Resources: The load balancer tries to connect to a dead end.
• Cascading Failures: Overloads can spread if requests aren't redirected.

Nginx provides built-in directives within its upstream block to perform passive health checks. These checks react to failed connection attempts or responses.

The two main directives are max_fails and fail_timeout.

The max_fails directive sets the number of consecutive failed attempts after which Nginx considers a server "unhealthy".

• Default: 1 (one failure marks it unhealthy).
• `max_fails=0`: Disables health checks for that server.
• A "failure" can be a connection error, timeout, or specific HTTP status codes (like 5xx) if configured.

Once a server is marked unhealthy, Nginx will stop sending requests to it for a duration specified by fail_timeout.

• Default: 10s (10 seconds).
• After this timeout, Nginx will tentatively send a request to the server to check if it has recovered.
• This prevents hammering a down server.

Let's see how to configure max_fails and fail_timeout in an Nginx upstream block. Here, we define two backend servers.

When a server hits its max_fails limit within the fail_timeout period, Nginx temporarily removes it from the load balancing pool.

• Requests are then distributed among the remaining healthy servers.
• After fail_timeout expires, Nginx tries sending a single request to the "unhealthy" server. If it succeeds, the server is marked healthy again.

While Nginx's basic health checks are passive, you can observe their effects in Nginx logs.

Error logs will show messages when a server is marked down or up. For more advanced, active monitoring and a dashboard, Nginx Plus offers dedicated features, but that's beyond basic Nginx.

Properly configuring health checks is key for reliable systems:

• Tune Values: Adjust max_fails and fail_timeout based on your application's responsiveness and recovery time.
• Backend Readiness: Ensure your backend applications have a dedicated health endpoint (e.g., /health) that reports true service readiness.
• Combine with Monitoring: Use external monitoring tools to alert you when Nginx marks servers down.

You've configured an Nginx upstream server with max_fails=2 and fail_timeout=30s. If the server fails 3 consecutive requests, what happens next?

In this lesson, we learned about Nginx's essential health check directives:

• max_fails: The number of failed attempts before a server is marked unhealthy.
• fail_timeout: The period for which an unhealthy server is taken out of the load balancing pool.
• These passive checks are crucial for maintaining backend reliability and improving user experience.