Controles de salud activos o pasivos: ¿Cuál es adecuado para usted?

Just as regular check‑ups with a doctor are an important part of staying healthy, regular checks on the health of your apps are critical for reliable performance. When reverse proxying and load balancing traffic, NGINX uses passive health checks to shield your application users from outages by automatically diverting traffic away from servers that don’t respond to requests. NGINX Plus adds active health checks, sending special probes that can detect unhealthy servers even before they fail to process a request. Which type of health check makes sense for your applications? In this post, we give you the info you need to make that decision.

What Is a Health Check?

En el sentido más básico, una comprobación del estado es un método para determinar si un servidor es capaz de manejar el tráfico. NGINX utiliza controles de estado para monitorear los servidores para los cuales realiza el proxy inverso o equilibra la carga del tráfico (lo que denomina servidores ascendentes) .

Controles de salud pasivos

Passive health checks – available in both NGINX Open Source and NGINX Plus – rely on observing how the server behaves while handling connections and traffic. They help prevent users from experiencing outages due to server timeouts, because when NGINX discovers a server is unhealthy it immediately forwards the request to a different server, stops sending requests to the unhealthy server, and distributes future requests among the remaining healthy servers in the upstream group.

Tenga en cuenta que las comprobaciones de estado pasivas solo son efectivas cuando el grupo ascendente está definido para tener varios miembros. Cuando solo se define un servidor ascendente, nunca se marca como no disponible y los usuarios ven una interrupción cuando no funciona correctamente.

How Passive Health Checks Work

A continuación se muestra una descripción detallada de cómo funcionan los controles de salud pasivos, pero salte a los controles de salud activos si no le interesa.

By default, NGINX considers a TCP/UDP (stream) server unhealthy if there is a single error or timeout while establishing a connection with it.

NGINX considers an HTTP server unhealthy if there is a single error or timeout while establishing a connection with it, passing a request to it, or reading the response header (receiving no response at all counts as this type of error). You can use the proxy_next_upstream directive to customize these conditions for HTTP proxying, and there is a parallel directive for the FastCGI, gRPC, memcached, SCGI, TCP/UDP, and uwsgi protocols.

For both HTTP and TCP/UDP, NGINX waits a default ten seconds before again trying to connect and send a request to an unhealthy server. You can use the fail_timeout parameter to the server[HTTP][Stream] directive to change this amount of time.

You can use the max_fails parameter to the server directive to increase the number of errors or timeouts that must occur for NGINX to consider the server unhealthy; in this case, the fail_timeout parameter sets the period during which that number of errors or timeouts must occur, as well as how long NGINX waits to try the server again after marking it unhealthy.

Comprobaciones de estado activas

Active health checks – which are exclusive to NGINX Plus – are special requests that are regularly sent to application endpoints to make sure they are responding correctly. They are separate from and in addition to passive health checks. For example, NGINX Plus might send a periodic HTTP request to the application’s web server to ensure it responds with a valid response code and the correct content. Active health checks enable continuous monitoring of the health of specific application components and processes. It constitutes a direct measurement of application availability, although that depends on how representative the specified health check is of overall application health.

You can customize many aspects of an active health check; see Use Cases for Active Health Checks.

Use Cases for Passive Health Checks

Passive health checks are table stakes. It’s a best practice for every Application Development, DevOps, DevSecOps, and Platform Ops team to run passive health checks as a part of its monitoring program for production infrastructure. NGINX runs passive health checks on load‑balanced traffic by default, including HTTP, TCP, and UDP configurations.

The advantages of passive health checks include:

• Disponible en NGINX de código abierto
• Habilitado de forma predeterminada para los servidores incluidos en un bloque de configuración upstream{}
• No additional load on the upstream servers
• Configurable in terms of minimum number of failures within a time period, as described in How Passive Health Checks Work
• Inicio lento configurable (exclusivo de NGINX Plus): cuando un servidor vuelve a estar en buen estado, NGINX Plus aumenta gradualmente la cantidad de tráfico que se le reenvía, para darle tiempo a "calentarse".

Las ventajas de NGINX Open Source son el costo (ninguna, obviamente), la capacidad de configuración y una amplia biblioteca de módulos de terceros. Como el código fuente está disponible, los desarrolladores pueden modificar y ampliar la funcionalidad para adaptarla a sus necesidades específicas.

Para muchas aplicações (y sus desarrolladores) los controles de estado pasivos son suficientes. Por ejemplo, los controles de estado activos pueden ser excesivos para los microservicios que no están orientados a los clientes y realizan tareas más pequeñas. De manera similar, es posible que no sean necesarios para aplicações en las que el almacenamiento en caché puede reducir las posibilidades de problemas de latencia o las redes de distribución de contenido (CDN) pueden hacerse cargo de algunas de las tareas de la aplicação . En resumen, los controles de salud pasivos por sí solos son mejores para:

• Monitoreo del tráfico HTTP
• Monitoring infrastructure separately from applications
• Monitoreo de aplicações donde la latencia es tolerable
• Monitoring internal applications where high performance isn’t important

Use Cases for Active Health Checks

For mission‑critical applications, active health checks are often crucial because customers and key processes are directly impacted by problems. With these applications, it is critical to test the application essentially as the customer or consumer of the application does, and that requires active health checks. Active health checks are similar to application performance monitoring tools such as New Relic and AppDynamics, which use out-of-band checks to measure application latency and responses. For active health checks, NGINX Plus includes a number of features and capabilities not included in NGINX Open Source:

• Out-of-band health checks for application availability
• Test configured end points and look for specific responses
• Pruebe puertos diferentes a los que manejan el tráfico de aplicação reales
• Keepalive HTTP connections for health checks, eliminating the need to set up a new connection for each check
• Mayor control sobre las condiciones de aprobación y de fallo
• Optionally test any newly added servers before they receive real application traffic

Con controles de estado activos, los desarrolladores pueden configurar NGINX Plus para detectar automáticamente cuando un servidor backend está inactivo o experimenta problemas, y luego dirigir el tráfico a servidores en buen estado hasta que se solucione el problema. La mayor capacidad de configuración de los controles de estado activos permite realizar controles de estado más sofisticados, posiblemente detectando problemas de aplicação antes de que afecten a los usuarios reales de la aplicação . Esto puede minimizar el tiempo de inactividad y evitar interrupciones en el acceso de los usuarios a la aplicação.

How to Configure Health Checks

Passive health checks are enabled by default, but you can customize their frequency and the number of failures that occur before a service is marked unhealthy, as described in How Passive Health Checks Work. For complete configuration instructions for both passive and active health checks, see our documentation:

• HTTP health checks
• Comprobaciones de estado de TCP
• UDP health checks
• gRPC health checks

Conclusion: Pick the Health Checks that Match Your Application Requirements

Los controles de salud son una parte importante para mantener cualquier aplicação de producción funcionando sin problemas y con capacidad de respuesta. Son la mejor manera de detectar problemas e identificar fuentes crecientes de latencia antes de que afecten a los usuarios finales. Para muchas aplicações, los controles de salud pasivos son suficientes.

Para aplicações más críticas, donde se necesita información directa sobre el comportamiento de las aplicação a nivel de usuario, es mejor utilizar verificaciones activas. NGINX Open Source es de uso gratuito y proporciona controles de estado pasivos configurables. NGINX Plus ofrece capacidades avanzadas de verificación de estado activo, así como soporte comercial.

Want to try active health checks with NGINX Plus? Start your 30-day free trial today or contact us to discuss your use cases.