Assim como consultas médicas regulares são importantes para manter a saúde, verificações periódicas da integridade dos seus aplicativos são essenciais para garantir um desempenho confiável. Ao atuar como proxy reverso e balancear o tráfego, o NGINX usa verificações passivas de integridade para proteger os usuários dos seus aplicativos contra indisponibilidades, desviando automaticamente o tráfego de servidores que não respondem às solicitações. O NGINX Plus também oferece verificações ativas de integridade, enviando sondagens especiais capazes de detectar servidores com problemas antes mesmo que eles deixem de processar uma solicitação. Qual tipo de verificação de integridade é mais adequado para seus aplicativos? Neste post, fornecemos as informações necessárias para você tomar essa decisão.
O que é uma verificação de integridade?
Em termos mais básicos, uma verificação de integridade é um método para determinar se um servidor é capaz de processar tráfego. O NGINX usa verificações de integridade para monitorar os servidores para os quais atua como proxy reverso ou faz o balanceamento de carga do tráfego — o que ele chama de servidores upstream.
Verificações passivas de integridade
As verificações passivas de integridade – disponíveis tanto no NGINX Open Source quanto no NGINX Plus – baseiam-se na observação do comportamento do servidor ao processar conexões e tráfego. Elas ajudam a evitar que os usuários enfrentem interrupções devido a tempos limite do servidor, pois, quando o NGINX detecta que um servidor não está íntegro, ele encaminha imediatamente a solicitação para outro servidor, deixa de enviar solicitações ao servidor com problemas e distribui as solicitações futuras entre os servidores íntegros restantes no grupo upstream.
Observe que as verificações passivas de integridade só são eficazes quando o grupo upstream é definido com vários membros. Quando apenas um servidor upstream é definido, ele nunca é marcado como indisponível, e os usuários enfrentam uma interrupção quando ele não está íntegro.
Como funcionam as verificações passivas de integridade
Veja em detalhes como funcionam as verificações passivas de integridade, mas, se isso não for do seu interesse, pule para Verificações ativas de integridade.
Por padrão, o NGINX considera um servidor TCP/UDP (stream) não íntegro se ocorrer um único erro ou tempo limite ao estabelecer uma conexão com ele.
O NGINX considera um servidor HTTP não íntegro se ocorrer um único erro ou tempo limite ao estabelecer uma conexão com ele, encaminhar uma solicitação a ele ou ler o cabeçalho da resposta (não receber nenhuma resposta também é considerado esse tipo de erro). Você pode usar a diretiva proxy_next_upstream para personalizar essas condições para o proxy de HTTP, e há uma diretiva equivalente para os protocolos FastCGI, gRPC, memcached, SCGI, TCP/UDP e uwsgi.
Tanto para HTTP quanto para TCP/UDP, o NGINX aguarda, por padrão, dez segundos antes de tentar novamente se conectar e enviar uma solicitação a um servidor não íntegro. Você pode usar o parâmetro fail_timeout da diretiva server[HTTP][Stream] para alterar esse período.
Você pode usar o parâmetro max_fails da diretiva server 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 por quanto tempo o NGINX aguarda antes de tentar acessar o servidor novamente após marcá-lo como não íntegro.
Verificações ativas de integridade
As verificações ativas de integridade — exclusivas do NGINX Plus — são solicitações especiais enviadas regularmente aos endpoints da aplicação para garantir que estejam respondendo corretamente. Elas são realizadas separadamente das verificações passivas de integridade e de forma complementar a elas. Por exemplo, o NGINX Plus pode enviar periodicamente uma solicitação HTTP ao servidor web da aplicação para garantir que ele responda com um código de resposta válido e o conteúdo correto. As verificações ativas de integridade permitem o monitoramento contínuo da integridade de componentes e processos específicos da aplicação. Isso constitui uma medição direta da disponibilidade da aplicação, embora dependa de quanto a verificação de integridade especificada representa a integridade geral da aplicação.
Você pode personalizar vários aspectos de uma verificação de integridade ativa; consulte Casos de uso de verificações de integridade ativas.
Casos de uso de verificações passivas de integridade
As verificações passivas de integridade são um requisito básico. É uma prática recomendada que todas as equipes de Desenvolvimento de Aplicações, DevOps, DevSecOps e Operações de Plataforma realizem verificações passivas de integridade como parte de seu programa de monitoramento da infraestrutura de produção. Por padrão, o NGINX realiza verificações passivas de integridade no tráfego com balanceamento de carga, incluindo configurações HTTP, TCP e UDP.
As vantagens das verificações passivas de integridade incluem:
- Disponível no NGINX Open Source
- Habilitado por padrão para os servidores incluídos em um bloco de configuração
upstream{}configuration block - Nenhuma carga adicional nos servidores upstream
- Configurável quanto ao número mínimo de falhas em um período, conforme descrito em Como funcionam as verificações passivas de integridade
- Inicialização lenta configurável (exclusiva do NGINX Plus) – quando um servidor volta a ficar íntegro, o NGINX Plus aumenta gradualmente a quantidade de tráfego encaminhado a ele, dando-lhe tempo para “aquecer”
As vantagens do NGINX Open Source são o custo (nenhum, obviamente), a capacidade de configuração e uma vasta biblioteca de módulos de terceiros. Como o código-fonte está disponível, os desenvolvedores podem modificar e ampliar a funcionalidade para atender às suas necessidades específicas.
Para muitas aplicações (e seus desenvolvedores), as verificações passivas de integridade são suficientes. Por exemplo, as verificações ativas de integridade podem ser excessivas para microsserviços que não interagem diretamente com os clientes e executam tarefas menores. Da mesma forma, elas podem não ser necessárias para aplicações em que o uso de cache reduz a probabilidade de problemas de latência ou em que redes de distribuição de conteúdo (CDNs) podem assumir algumas das tarefas da aplicação. Em resumo, apenas as verificações passivas de integridade são mais indicadas para:
- Monitoramento do tráfego HTTP
- Monitoramento da infraestrutura separadamente das aplicações
- Monitoramento de aplicações em que a latência é tolerável
- Monitoramento de aplicações internas em que o alto desempenho não é importante
Casos de uso para verificações ativas de integridade
Para aplicações de missão crítica, as verificações ativas de integridade costumam ser essenciais, pois os clientes e os principais processos são diretamente afetados por problemas. Nessas aplicações, é fundamental testá-las essencialmente da mesma forma que o cliente ou usuário, o que exige verificações ativas de integridade. As verificações ativas de integridade são semelhantes a ferramentas de monitoramento de desempenho de aplicações, como New Relic e AppDynamics, que usam verificações fora de banda para medir a latência e as respostas das aplicações. Para verificações ativas de integridade, o NGINX Plus inclui diversos recursos e funcionalidades que não estão disponíveis no NGINX Open Source:
- Verificações de integridade fora de banda para a disponibilidade da aplicação
- Teste os endpoints configurados e verifique se há respostas específicas
- Teste portas diferentes daquelas que processam o tráfego real da aplicação
- Conexões HTTP persistentes para verificações de integridade, eliminando a necessidade de estabelecer uma nova conexão a cada verificação
- Maior controle sobre as condições de falha e aprovação
- Opcionalmente, teste os servidores recém-adicionados antes que eles recebam tráfego real da aplicação
Com as verificações de integridade ativas, os desenvolvedores podem configurar o NGINX Plus para detectar automaticamente quando um servidor de backend está inativo ou apresentando problemas e, em seguida, direcionar o tráfego para servidores íntegros até que o problema seja corrigido. A maior capacidade de configuração das verificações de integridade ativas permite realizar verificações mais sofisticadas, possivelmente detectando problemas na aplicação antes que afetem usuários reais. Isso pode minimizar o tempo de inatividade e evitar interrupções no acesso dos usuários à aplicação.
Como configurar verificações de integridade
As verificações de integridade passivas são habilitadas por padrão, mas você pode personalizar a frequência e o número de falhas necessárias para 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 das verificações de integridade passivas e ativas, consulte nossa documentação:
- Verificações de integridade HTTP
- Verificações de integridade TCP
- Verificações de integridade UDP
- Verificações de integridade do gRPC
Conclusão: escolha as verificações de integridade que atendam aos requisitos da sua aplicação
As verificações de integridade são essenciais para manter qualquer aplicação em produção funcionando de forma estável e responsiva. 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, as verificações de integridade passivas são suficientes.
Para aplicações mais críticas, nas quais é necessário ter uma visão direta do comportamento da aplicação no nível do usuário, as verificações ativas são mais adequadas. O NGINX Open Source é gratuito e oferece verificações passivas de integridade configuráveis. O NGINX Plus oferece recursos avançados de verificação ativa de integridade, além de suporte comercial.
Quer experimentar as verificações ativas de integridade com o NGINX Plus? Comece sua avaliação gratuita de 30 dias hoje mesmo ou entre em contato conosco para conversar sobre seus casos de uso.
Sobre o autor
Publicações relacionadas no blog
Como o F5 NGINX One aprimora o gerenciamento e a observabilidade
Descubra como o F5 NGINX One aprimora o gerenciamento e a observabilidade de ambientes híbridos e multicloud ao oferecer um console web centralizado baseado em SaaS, com insights em tempo real, conformidade automatizada e gerenciamento simplificado de configurações.
Do OpenAPI ao NGINX como gateway de API usando uma API declarativa
Descubra como transformar uma definição de esquema OpenAPI em uma configuração NGINX totalmente funcional, operando como um API Gateway com a segurança de um Web Application Firewall e um Portal do Desenvolvedor, usando uma abordagem declarativa de API.
Como gerenciar picos repentinos de tráfego e sobrecarga do servidor
Picos de tráfego e sobrecarga de servidores são preocupações sérias para varejistas online em qualquer época, mas especialmente durante a “Cyber Season” de compras de fim de ano. Detalhamos como você pode aproveitar as soluções de entrega de aplicações de nível de produção da NGINX para se preparar para aumentos repentinos de tráfego.
Distribuição segura de chaves privadas SSL com o NGINX
Descrevemos três maneiras progressivamente mais seguras de proteger chaves privadas SSL ao configurar o NGINX para processar tráfego HTTPS: permitir acesso de leitura apenas ao usuário root, criptografar as chaves com senhas armazenadas separadamente e distribuir as senhas a partir de um repositório central.
Agrupando solicitações de API em lotes com NGINX Plus e o módulo JavaScript do NGINX
O módulo JavaScript do NGINX lançado com o NGINX Plus R15 oferece suporte a subsolicitações, possibilitando uma classe totalmente nova de casos de uso para o NGINX Plus. Este exemplo completo também usa a API do NGINX Plus e os módulos de chave-valor para converter solicitações de API dos clientes em solicitações separadas para as APIs dos microsserviços que compõem um aplicativo.
Como superar o esgotamento de portas efêmeras no NGINX e no NGINX Plus
Confira dicas para evitar o esgotamento de portas efêmeras com ajustes no kernel do Linux, conexões keepalive e conexões vinculadas dinamicamente a endereços IP locais.