Verificações de saúde ativas ou passivas: Qual é o certo para você?

Assim como exames regulares com um médico são uma parte importante para se manter saudável, verificações regulares da saúde dos seus aplicativos são essenciais para um desempenho confiável. Ao fazer proxy reverso e balancear tráfego de carga, o NGINX usa verificações de integridade passivas para proteger os usuários do seu aplicativo contra interrupções, desviando automaticamente o tráfego dos servidores que não respondem às solicitações. O NGINX Plus adiciona verificações de integridade ativas , enviando sondas especiais que podem detectar servidores com problemas de integridade antes mesmo que eles falhem em processar uma solicitação. Que tipo de verificação de integridade faz sentido para seus aplicativos? Neste post, daremos a você as informações necessárias para tomar essa decisão.

O que é um check-up de saúde?

No sentido mais básico, uma verificação de integridade é um método para determinar se um servidor é capaz de lidar com tráfego. O NGINX usa verificações de integridade para monitorar os servidores para os quais ele está fazendo proxy reverso ou balanceando o tráfego de carga – o que ele chama de servidores upstream .

Verificações de saúde passivas

Verificações de integridade passivas – disponíveis no NGINX Open Source e no NGINX Plus – dependem da observação de como o servidor se comporta ao manipular conexões e tráfego. Eles ajudam a evitar que os usuários sofram interrupções devido a tempos limite do servidor, porque quando o NGINX descobre que um servidor não está íntegro, ele encaminha imediatamente a solicitação para um servidor diferente, para de enviar solicitações para o servidor com problemas e distribui solicitações futuras entre os servidores íntegros restantes no grupo upstream.

Observe que as verificações de integridade passivas são eficazes somente quando o grupo upstream é definido para ter vários membros. Quando apenas um servidor upstream é definido, ele nunca é marcado como indisponível e os usuários veem uma interrupção quando ele não está íntegro.

Como funcionam as verificações de saúde passivas

Veja aqui uma análise detalhada de como funcionam as verificações de integridade passivas, mas pule para Verificações de integridade ativas se não for do seu interesse.

Por padrão, o NGINX considera um servidor TCP/UDP (fluxo) com problemas se houver um único erro ou tempo limite ao estabelecer uma conexão com ele.

O NGINX considera um servidor HTTP com problemas se houver um único erro ou tempo limite ao estabelecer uma conexão com ele, passar uma solicitação a ele ou ler o cabeçalho de resposta (não receber nenhuma resposta é considerado esse tipo de erro). Você pode usar a diretiva proxy_next_upstream para personalizar essas condições para proxy HTTP , e há uma diretiva paralela para os protocolos FastCGI , gRPC , memcached , SCGI , TCP/UDP e uwsgi .

Tanto para HTTP quanto para TCP/UDP, o NGINX aguarda um tempo padrão de dez segundos antes de tentar se conectar novamente e enviar uma solicitação a um servidor com problemas. Você pode usar o parâmetro fail_timeout na diretiva do servidor [ HTTP ][ Stream ] para alterar essa quantidade de tempo.

Você pode usar o parâmetro max_fails na diretiva do servidor para aumentar o número de erros ou tempos limite que devem ocorrer para que o NGINX considere o servidor não íntegro; nesse caso, o parâmetro fail_timeout define o período durante o qual esse número de erros ou tempos limite deve ocorrer, bem como quanto tempo o NGINX espera para tentar o servidor novamente após marcá-lo como não íntegro.

Verificações de integridade ativas

Verificações de integridade ativas – exclusivas do NGINX Plus – são solicitações especiais enviadas regularmente aos endpoints do aplicativo para garantir que estejam respondendo corretamente. Elas são separadas e adicionais às verificações de saúde passivas. Por exemplo, o NGINX Plus pode enviar uma solicitação HTTP periódica ao servidor web do aplicativo para garantir que ele responda com um código de resposta válido e o conteúdo correto. Verificações de integridade ativas permitem o monitoramento contínuo da integridade de componentes e processos específicos do aplicativo. Constitui uma medição direta da disponibilidade do aplicativo, embora isso dependa de quão representativa a verificação de integridade especificada é da integridade geral do aplicativo.

Você pode personalizar muitos aspectos de uma verificação de integridade ativa; consulte Casos de uso para verificações de integridade ativas .

Casos de uso para verificações de saúde passivas

Verificações de saúde passivas são a aposta mínima. É uma prática recomendada para cada equipe de Desenvolvimento de Aplicativos, DevOps, DevSecOps e Platform Ops executar verificações de integridade passivas como parte de seu programa de monitoramento para infraestrutura de produção. O NGINX executa verificações de integridade passivas no tráfego com balanceamento de carga por padrão, incluindo configurações HTTP, TCP e UDP.

As vantagens das verificações de saúde passivas incluem:

• Disponível em NGINX Open Source
• Habilitado por padrão para os servidores incluídos em um bloco de configuração upstream{}
• Nenhuma carga adicional nos servidores upstream
• Configurável em termos de número mínimo de falhas dentro de um período de tempo, conforme descrito em Como funcionam as verificações de integridade passivas
• Início lento configurável (exclusivo do NGINX Plus) – quando um servidor retorna à saúde, o NGINX Plus aumenta gradualmente a quantidade de tráfego encaminhado a ele, para dar tempo de “aquecer”

As vantagens do NGINX Open Source são custo (nenhum, obviamente), configurabilidade e uma vasta biblioteca de módulos de terceiros. Como o código-fonte está disponível, os desenvolvedores podem modificar e estender a funcionalidade para atender às suas necessidades específicas.

Para muitos aplicativos (e seus desenvolvedores), verificações de integridade passivas são suficientes. Por exemplo, verificações de integridade ativas podem ser um exagero para microsserviços que não atendem clientes e executam tarefas menores. Da mesma forma, eles podem não ser necessários para aplicativos em que o cache pode reduzir as chances de problemas de latência ou onde as redes de distribuição de conteúdo (CDNs) podem assumir algumas das tarefas do aplicativo. Para resumir, as verificações de saúde passivas são melhores para:

• Monitoramento de tráfego HTTP
• Monitoramento de infraestrutura separadamente de aplicativos
• Monitoramento de aplicativos onde a latência é tolerável
• Monitoramento de aplicações internas onde alto desempenho não é importante

Casos de uso para verificações de saúde ativas

Para aplicações de missão crítica, verificações de integridade ativas geralmente são cruciais porque os clientes e os principais processos são diretamente afetados pelos problemas. Com esses aplicativos, é essencial testá-los essencialmente como o cliente ou consumidor do aplicativo faz, e isso requer verificações de integridade ativas. As verificações de integridade ativas são semelhantes às ferramentas de monitoramento de desempenho de aplicativos, como New Relic e AppDynamics, que usam verificações fora de banda para medir a latência e as respostas dos aplicativos. Para verificações de integridade ativas, o NGINX Plus inclui uma série de recursos e funcionalidades não incluídos no NGINX Open Source:

• Verificações de integridade fora de banda para disponibilidade do aplicativo
• Teste os pontos finais configurados e procure respostas específicas
• Teste portas diferentes daquelas que manipulam o tráfego real do aplicativo
• Conexões HTTP Keepalive para verificações de integridade, eliminando a necessidade de configurar uma nova conexão para cada verificação
• Maior controle sobre as condições de aprovação e reprovação
• Opcionalmente, teste todos os servidores recém-adicionados antes que eles recebam tráfego de aplicativo real

Com verificações de integridade ativas, os desenvolvedores podem configurar o NGINX Plus para detectar automaticamente quando um servidor de backend está inativo ou com problemas e, em seguida, rotear o tráfego para servidores íntegros até que o problema seja corrigido. A maior configurabilidade das verificações de integridade ativas permite que verificações de integridade mais sofisticadas sejam realizadas, possivelmente detectando problemas no aplicativo antes que eles afetem os usuários reais do aplicativo. Isso pode minimizar o tempo de inatividade e evitar interrupções no acesso do usuário ao aplicativo.

Como configurar verificações de integridade

As verificações de integridade passivas são habilitadas por padrão, mas você pode personalizar sua frequência e o número de falhas que ocorrem antes que um serviço seja marcado como não íntegro, conforme descrito em Como funcionam as verificações de integridade passivas . Para obter instruções completas de configuração para verificações de integridade passivas e ativas, consulte nossa documentação:

• Verificações de integridade HTTP
• Verificações de integridade do TCP
• Verificações de saúde do UDP
• Verificações de integridade do gRPC

Conclusão: Escolha as verificações de saúde que correspondem aos requisitos da sua aplicação

As verificações de integridade são uma parte importante para manter qualquer aplicativo de produção funcionando sem problemas e com capacidade de resposta. Elas são a melhor maneira de detectar problemas e identificar fontes crescentes de latência antes que afetem os usuários finais. Para muitas aplicações, verificações de integridade passivas são suficientes.

Para aplicações mais críticas, onde são necessários insights diretos sobre comportamentos de aplicações no nível do usuário, verificações ativas são melhores. O NGINX Open Source é gratuito e fornece verificações de integridade passivas configuráveis. O NGINX Plus oferece recursos avançados de verificação de integridade ativa, bem como suporte comercial.

Quer experimentar verificações de saúde ativas com o NGINX Plus? Comece hoje mesmo seu teste gratuito de 30 dias ou entre em contato conosco para discutir seus casos de uso .