Padrão de monitoramento do ponto de extremidade de integridade

Para verificar se os aplicativos e serviços estão funcionando corretamente, é possível usar o padrão de monitoramento do ponto de extremidade de integridade. Esse padrão especifica o uso de verificações funcionais em um aplicativo. Ferramentas externas podem acessar essas verificações em intervalos regulares por meio de pontos de extremidade expostos.

Contexto e problema

É uma boa prática monitorar aplicativos Web e serviços de back-end. O monitoramento ajuda a garantir que os aplicativos e serviços estejam disponíveis e funcionando corretamente. Os requisitos empresariais geralmente incluem monitoramento.

Às vezes é mais difícil monitorar serviços de nuvem do que serviços locais. Um dos motivos é que você não tem controle total do ambiente de hospedagem. Outro é que os serviços geralmente dependem de outros serviços proporcionados pelos fornecedores de plataformas, entre outros.

Muitos fatores afetam os aplicativos hospedados na nuvem. Os exemplos incluem a latência da rede, o desempenho e a disponibilidade dos sistemas subjacentes de computação e armazenamento e a largura de banda da rede entre eles. Um serviço pode falhar total ou parcialmente devido a qualquer desses fatores. Para garantir um nível de disponibilidade necessário, você deve verificar em intervalos regulares se o seu serviço funciona corretamente. Seu contrato de nível de serviço (SLA) pode especificar o nível que você precisa atingir.

Solução

Implementar monitoramento de integridade, enviando solicitações para um ponto de extremidade no seu aplicativo. O aplicativo deve realizar as verificações necessárias e retornar uma indicação de seu status.

Uma verificação de monitoramento de integridade geralmente combina dois fatores:

• As verificações (se houver) que o aplicativo ou serviço realiza em resposta à solicitação ao ponto de extremidade de verificação de integridade
• A análise dos resultados pela ferramenta ou estrutura que executa a verificação de integridade

O código de resposta indica o status do aplicativo. Como opção, o código de resposta também fornece o status dos componentes e serviços que o aplicativo usa. A ferramenta ou estrutura de monitoramento realiza a verificação de latência ou tempo de resposta.

A figura a seguir fornece uma visão geral do padrão.

O código de monitoramento de funcionamento no aplicativo também pode executar outras verificações para determinar:

• A disponibilidade e o tempo de resposta do armazenamento em nuvem ou de um banco de dados.
• O status de outros recursos ou serviços que o aplicativo usa. Esses recursos e serviços podem estar no aplicativo ou fora dele.

Estão disponíveis serviços e ferramentas que monitoram aplicativos Web enviando uma solicitação a um conjunto configurável de pontos de extremidade. Esses serviços e ferramentas avaliam os resultados em relação a um conjunto de regras configuráveis. É relativamente fácil criar um ponto de extremidade de serviço com o único propósito de realizar alguns testes funcionais em um sistema.

As verificações típicas realizadas pelas ferramentas de monitoramento incluem:

• Validando o código de resposta. Por exemplo, uma resposta HTTP de 200 (OK) indica que o aplicativo respondeu sem erro. O sistema de monitoramento também pode verificar se há outros códigos de resposta para obter resultados mais abrangentes.
• Verificação do conteúdo da resposta para detectar erros, mesmo quando o código de status for 200 (OK). Ao verificar o conteúdo, você pode detectar erros que afetam apenas uma seção da página da Web retornada ou da resposta do serviço. Por exemplo, você pode verificar o título de uma página ou procurar uma frase específica que indique que o aplicativo retornou a página correta.
• Medição do tempo de resposta. O valor inclui a latência da rede e o tempo que o aplicativo levou para emitir a solicitação. Um valor crescente pode indicar um problema emergente com o aplicativo ou a rede.
• Verificação de recursos ou serviços localizados fora do aplicativo. Um exemplo é uma rede de entrega de conteúdo que o aplicativo usa para entregar conteúdo de caches globais.
• Verificação da expiração de certificados TLS.
• Medição do tempo de resposta de uma pesquisa de DNS para a URL do aplicativo. Essa verificação mede a latência do DNS e as falhas de DNS.
• Validação do URL retornado por uma pesquisa de DNS. Ao validar, você pode garantir que as entradas estão corretas. Você também pode ajudar a evitar o redirecionamento de solicitações mal-intencionadas que podem ocorrer após um ataque ao seu servidor DNS.

Sempre que possível, também é útil executar essas verificações em diferentes locais ou locais hospedados e depois comparar os tempos de resposta. O ideal é que monitore aplicativos de locais próximos aos clientes. Assim, você obtém uma visão precisa do desempenho de cada local. Essa prática fornece um mecanismo de verificação mais robusto. Os resultados também podem ajudar você a tomar as seguintes decisões:

• Onde implantar seu aplicativo
• Se deve ser implantado em mais de um datacenter

Para garantir que seu aplicativo funcione corretamente para todos os clientes, execute testes em todas as instâncias de serviço usadas pelos clientes. Por exemplo, se o armazenamento do cliente se espalhar por mais de uma conta de armazenamento, o processo de monitoramento deverá verificar cada conta.

Problemas e considerações

Considere os seguintes pontos ao decidir como implementar esse padrão:

• Pense em como validar a resposta. Por exemplo, determine se um código de status 200 (OK) é suficiente para verificar se o aplicativo está funcionando corretamente. Verificar o código de status é a implementação mínima desse padrão. Um código de status fornece uma medida básica da disponibilidade do aplicativo. Mas um código fornece poucas informações sobre as operações, tendências e possíveis problemas futuros na aplicação.

• Determine o número de pontos de extremidade para expor um aplicativo. Uma abordagem é expor pelo menos um ponto de extremidade para os serviços principais que o aplicativo usa e outro para serviços de menor prioridade. Com essa abordagem, você pode atribuir diferentes níveis de importância a cada resultado do monitoramento. Considere também expor pontos de extremidade extras. Você pode expor um para cada serviço principal para aumentar a granularidade do monitoramento. Por exemplo, uma verificação de integridade pode verificar o banco de dados, o armazenamento e um serviço de geocodificação externo usado por um aplicativo. Cada um pode exigir um nível diferente de tempo de atividade e tempo de resposta. O serviço de geocodificação ou alguma outra tarefa em segundo plano pode ficar indisponível por alguns minutos. Mas o aplicativo ainda pode estar íntegro.

• Decida se deseja usar o mesmo ponto de extremidade para monitoramento e acesso geral. Você pode usar o mesmo ponto de extremidade para ambos, mas criar um caminho específico para verificações de integridade. Por exemplo, você pode usar /health no ponto de extremidade de acesso geral. Com essa abordagem, as ferramentas de monitoramento podem executar alguns testes funcionais na aplicação. Os exemplos incluem registrar um novo usuário, fazer logon e fazer um pedido de teste. Ao mesmo tempo, você também pode verificar se o ponto de extremidade de acesso geral está disponível.

• Determine o tipo de informação a ser coletada no serviço em resposta às solicitações de monitoramento. Você também precisa determinar como retornar essas informações. A maioria das ferramentas e estruturas existentes pesquisa apenas o código de status HTTP que o ponto de extremidade retorna. Para retornar e validar informações adicionais, talvez seja necessário criar um serviço ou utilitário de monitoramento personalizado.

• Descubra quanta informação coletar. Executar um processamento excessivo durante a verificação pode sobrecarregar o aplicativo e afetar outros usuários. O tempo de processamento também pode exceder o tempo limite do sistema de monitoramento. Como resultado, o sistema poderá marcar o aplicativo como indisponível. A maioria dos aplicativos inclui instrumentação como manipuladores de erros e contadores de desempenho. Essas ferramentas podem registrar informações detalhadas sobre desempenho e erros, o que pode ser suficiente. Considere usar esses dados em vez de retornar informações adicionais de uma verificação de integridade.

• Considere armazenar em cache o status do ponto de extremidade. Executar a verificação de integridade com frequência pode ser caro. Por exemplo, se o estado de integridade for relatado através de um painel, você não deseja que cada solicitação do painel apresente uma verificação de integridade. Em vez disso, verifique periodicamente a integridade do sistema e armazene em cache o status. Exponha um ponto de extremidade que retorna o status em cache.

• Planeje como configurar a segurança para os pontos de extremidade de monitoramento. Ao configurar a segurança, você pode ajudar a proteger os pontos de extremidade do acesso público, o que pode:

  • Expor o aplicativo a ataques maliciosos.
  • Criar um risco de exposição de informações confidenciais.
  • Atrair ataques de DoS (negação de serviço).

  Geralmente, você configura a segurança na configuração do aplicativo. Com isso, você pode atualizar as configurações facilmente sem reiniciar o aplicativo. Considere usar uma ou mais das seguintes técnicas:

  • Proteger o ponto de extremidade exigindo autenticação. Se o serviço ou ferramenta de monitoramento permitir autenticação, você poderá usar uma chave de segurança de autenticação no cabeçalho da solicitação. Você também pode passar credenciais com a solicitação. Ao usar a autenticação, considere como acessar seus pontos de extremidade de verificação de integridade. Por exemplo, o serviço de aplicativo do Azure tem uma verificação de integridade interna que se integra aos recursos de autenticação e autorização do Serviço de Aplicativo.

  • Utilizar um ponto de extremidade oculto ou obscuro. Por exemplo, exponha o ponto de extremidade em um endereço IP diferente daquele usado pela URL do aplicativo padrão. Configure o ponto de extremidade em uma porta HTTP não padrão. Além disso, considere usar um caminho complexo para sua página de teste. Geralmente, você pode especificar portas e endereços de ponto de extremidade extras na configuração do aplicativo. Se necessário, você pode adicionar entradas para esses pontos de extremidade ao servidor DNS. Assim, você evita a necessidade de especificar o endereço IP diretamente.

  • Expor um método em um ponto de extremidade que aceite um parâmetro, como um valor de chave ou um valor de modo de operação. Quando chega uma solicitação, o código pode executar testes específicos que dependem do valor do parâmetro. O código pode retornar um erro 404 (Não encontrado) se não reconhecer o valor do parâmetro. Possibilite a definição de valores de parâmetros na configuração da aplicação.

  • Use um ponto de extremidade separado que execute testes funcionais básicos sem comprometer a operação do aplicativo. Com essa abordagem, você pode ajudar a reduzir o impacto de um ataque DoS. O ideal é evitar usar um teste que possa expor informações confidenciais. Às vezes você deve retornar informações que podem ser úteis para um invasor. Nesse caso, considere como proteger o ponto de extremidade e os dados contra acesso não autorizado. Confiar na obscuridade não é suficiente. Considere também usar uma conexão HTTPS e criptografar dados confidenciais, embora essa abordagem aumente a carga no servidor.

• Decida como garantir que o agente de monitoramento esteja sendo executado corretamente. Uma abordagem é expor um ponto de extremidade que retorne um valor a partir da configuração do aplicativo ou um valor aleatório que pode ser utilizado para testar o agente. Certifique-se também de que o sistema de monitoramento realiza verificações em si mesmo. Você pode usar um autoteste ou um teste integrado para evitar que o sistema de monitoramento emita resultados falsos positivos.

Quando usar esse padrão

Esse padrão é útil para:

• Monitorar sites e aplicativos Web para verificar a disponibilidade.
• Monitorar sites e aplicativos Web para verificar a operação correta.
• Monitorar serviços compartilhados ou de camada intermediária para detectar e isolar falhas que podem interromper outros aplicativos.
• Complementar a instrumentação existente no aplicativo, como contadores de desempenho e manipuladores de erro. A verificação de integridade não substitui os requisitos do aplicativo para registro em log e auditoria. A instrumentação pode fornecer informações valiosas para uma estrutura existente que monitora contadores e logs de erros para detectar falhas ou outros problemas. Mas a instrumentação não pode fornecer informações se um aplicativo não estiver disponível.

Design de carga de trabalho

Um arquiteto deve avaliar como o padrão Monitoramento do Ponto de Extremidade de Integridade pode ser usado no design das suas cargas de trabalho para abordar os objetivos e os princípios discutidos nos pilares do Azure Well-Architected Framework. Por exemplo:

Tal como acontece com qualquer decisão de design, considere quaisquer compensações em relação aos objetivos dos outros pilares que possam ser introduzidos com este padrão.

Exemplo

Você pode usar o middleware e as bibliotecas de verificações de integridade do ASP.NET para relatar a integridade dos componentes da infraestrutura do aplicativo. Essa estrutura fornece uma maneira de relatar verificações de integridade de forma consistente. Ela implementa muitas das práticas descritas neste artigo. Por exemplo, as verificações de integridade do ASP.NET incluem verificações externas, como conectividade de banco de dados e conceitos específicos, como investigação de disponibilidade e preparação.

Vários exemplos de implementações que usam verificações de integridade do ASP.NET estão disponíveis no GitHub.

Monitorar pontos de extremidade em aplicações hospedadas no Azure

As opções para monitorizar pontos de extremidades em aplicativos do Azure incluem:

• Utilize as funcionalidades de monitorização incorporadas do Azure, como o Azure Monitor.
• Use um serviço de terceiros ou uma estrutura como o Microsoft System Center Operations Manager.
• Criar um serviço ou utilitário personalizado que seja executado em seu próprio servidor ou em um servidor hospedado.

Embora o Azure forneça opções de monitorização abrangentes, é possível utilizar serviços e ferramentas adicionais para fornecer informações adicionais. O Application Insights, um recurso do monitor, foi projetado para equipes de desenvolvimento. Esse recurso ajuda você a entender o desempenho do seu aplicativo e como ele é usado. O Application Insights monitora taxas de solicitação, tempos de resposta, taxas de falha e taxas de dependência. Pode ajudar você a determinar se os serviços externos estão provocando atraso.

As condições que podem ser monitoradas dependem do mecanismo de hospedagem escolhido para seu aplicativo. Todas as opções nesta seção oferecem suporte a regras de alerta. Uma regra de alerta usa um ponto de extremidade da Web que você especifica nas configurações do seu serviço. Este ponto de extremidade deve responder em tempo hábil para que o sistema de alerta possa detectar que o aplicativo está executando corretamente. Para obter mais informações, consulte Criar uma nova regra de alerta.

Se houver uma grande paralisação, o tráfego do cliente deverá ser roteável para uma implantação de aplicativo que esteja disponível em outras regiões ou zonas. Essa situação é um bom argumento para conectividade entre locais e balanceamento de carga global. A escolha depende se a aplicativo é interno ou externo. Serviços como o Azure Front Door, o Gerenciador de Tráfego do Azure ou redes de entrega de conteúdos podem rotear o tráfego entre regiões com base nos dados fornecidos por investigações de integridade.

Gerenciador de Tráfego é um serviço de roteamento e balanceamento de carga. Ele pode usar uma variedade de regras e configurações para distribuir solicitações para instâncias específicas do seu aplicativo. Além de pedidos de roteamento, o Gerenciador de Tráfego pode executar ping regularmente em uma URL, porta e caminho relativo. Você especifica os alvos de ping com o objetivo de determinar quais instâncias do seu aplicativo estão ativas e respondendo às solicitações. Se o Gerenciador de Tráfego detectar um código de status 200 (OK), ele marcará o aplicativo como disponível. Qualquer outro código de status faz com que o Gerenciador de Tráfego marque o aplicativo como offline. O console Gerenciador de Tráfego apresenta o estado de cada aplicativo. Você pode configurar cada regra para redirecionar solicitações para outras instâncias do aplicativo que estão respondendo.

O Gerenciador de Tráfego aguardará um determinado período de tempo para receber uma resposta da URL de monitoramento. Certifique-se de que seu código de verificação de integridade seja executado nesse período. Permita a latência da rede para a viagem de ida e volta do Gerenciador de Tráfego para a sua aplicação e vice-versa.

Próximas etapas

As diretrizes a seguir podem ser úteis para implementar esse padrão:

• Diretrizes de monitoramento de integridade em aplicativos baseados em microsserviços
• Monitoramento de integridade do aplicativo para melhorar a confiabilidade, parte do Azure Well-Architected Framework
• Criar nova regra de alerta

Recursos relacionados

• Padrão de repositório de configuração externo
• Padrão de interruptor de circuito
• Padrão de roteamento de gateway
• Padrão de gatekeeper