Monitorar instâncias do Serviço de Aplicativo usando a Verificação de Integridade

Este artigo descreve como usar a verificação de integridade no portal do Azure para monitorar instâncias do Serviço de Aplicativo do Azure. A verificação de integridade aumenta a disponibilidade do aplicativo ao redirecionar solicitações para instâncias íntegras e substituir instâncias caso permaneçam não íntegras. Ele faz isso enviando pings ao seu aplicativo web a cada minuto, por um caminho que você escolher.

Lembre-se de que /api/health é apenas um exemplo. Não há nenhum caminho de verificação de integridade padrão. Você deve ter certeza de que o caminho escolhido é válido e realmente existe em seu aplicativo.

Como funciona a Verificação de Integridade

• Quando você fornece um caminho para o seu aplicativo, a Verificação de Integridade executa um ping nesse caminho em todas as instâncias do aplicativo do Serviço de Aplicativo em intervalos de um minuto.
• Se um aplicativo Web em execução em uma determinada instância não responder com um código de status entre 200 e 299 (incluindo esses valores) após 10 solicitações, o Serviço de Aplicativo determinará que a instância não está íntegra e a removerá do balanceador de carga do aplicativo Web. O número necessário de solicitações com falha para que uma instância seja considerada não saudável pode ser configurável para um mínimo de duas solicitações.
• Após a remoção da instância, a verificação de integridade continuará executando ping na instância. Se a instância começar a responder com um código de status íntegro (200-299), a instância será retornada para o balanceador de carga.
• Se o aplicativo web em execução em uma instância permanecer com problemas por uma hora, a instância será substituída por uma nova.
• Ao escalar verticalmente, o Serviço de Aplicativo faz um ping no caminho de verificação de integridade para garantir que as novas instâncias estejam prontas.

Observação

• A verificação de integridade não segue redirecionamentos 302.
• No máximo, uma instância é substituída por hora e há um máximo de três instâncias por dia por plano do Serviço de Aplicativo.
• Se a verificação de integridade enviar o status Waiting for health check response, a verificação provavelmente falhará devido a um código de status HTTP 307. Esse status poderá ocorrer se você tiver o redirecionamento HTTPS habilitado, mas tiver HTTPS Only desabilitado.

Habilitar a verificação de integridade

1. Para habilitar a verificação de integridade, acesse o portal do Azure e selecione seu aplicativo do Serviço de Aplicativo.
2. No painel esquerdo, em Monitoramento, selecione Verificação de integridade.
3. Selecione Habilitar e forneça um caminho de URL válido para o seu aplicativo, como /health ou /api/health.
4. Selecione Salvar.

Observação

• Seu plano do Serviço de Aplicativo deve ser dimensionado para duas ou mais instâncias para usar a verificação de integridade.
• O roteiro de verificação de saúde deve verificar os componentes críticos da sua aplicação. Por exemplo, se seu aplicativo depende de um banco de dados e de um sistema de mensagens, o endpoint de verificação de integridade deve se conectar a componentes como o banco de dados e o sistema de mensagens. Se o aplicativo não puder se conectar a um componente crítico, o caminho deverá retornar um código de resposta de 500 níveis para indicar que o aplicativo não está íntegro. Além disso, se o caminho não retornar uma resposta dentro de um minuto, o ping de verificação de integridade será considerado não íntegro.
• Ao selecionar o caminho de verificação de saúde, certifique-se de escolher um caminho que retorne um código de status 200 somente quando o aplicativo estiver completamente inicializado.
• Para usar a verificação de integridade em um aplicativo de funções, você deve usar um plano de hospedagem premium ou dedicado.
• Para obter detalhes sobre a verificação de integridade em aplicativos de funções, consulte Monitorar aplicativos de funções usando a verificação de integridade.

Cuidado

Alterações de configuração da Verificação de Integridade reinicie seu aplicativo. Para minimizar o efeito nos aplicativos de produção, recomendamos que você configure slots de preparo e troque para produção.

Configuração

Além de configurar as opções de verificação de Integridade, você também pode configurar as seguintes configurações de aplicativo:

Nome da configuração do aplicativo	Valores permitidos	Descrição
WEBSITE_HEALTHCHECK_MAXPINGFAILURES	2 - 10	O número de solicitações com falha necessárias para que uma instância seja considerada não íntegra e removida do balanceador de carga. Por exemplo, quando essa configuração é definida como 2, suas instâncias são removidas após 2 pings com falha. (O valor padrão é 10).
WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT	1 a 100	Por padrão, para evitar sobrecarregar as instâncias restantes, no máximo metade delas será removida do balanceador de carga ao mesmo tempo. Por exemplo, se um Plano do Serviço de Aplicativo for dimensionado para quatro instâncias e três não estiverem íntegras, duas são excluídas. As outras duas instâncias (uma íntegra e outra não íntegra) continuam recebendo solicitações. Se todas as instâncias não estiverem íntegras, nenhuma delas será excluída. Para substituir esse comportamento, defina essa configuração de aplicativo como um valor entre 1 e 100. Um valor mais alto significa que mais instâncias não íntegras serão removidas. (O valor padrão é 50).

Autenticação e segurança

A verificação de integridade se integra aos recursos de autenticação e autorização do Serviço de Aplicativo. Nenhuma outra configuração é necessária se esses recursos de segurança estiverem habilitados.

Se você usar seu próprio sistema de autenticação, o caminho de verificação de integridade deverá permitir acesso anônimo. Para fornecer segurança para o ponto de extremidade de verificação de integridade, primeiro você deve usar recursos como restrições de IP, certificados de cliente ou uma rede virtual para restringir o acesso ao aplicativo. Depois de implementar esses recursos, autentique a solicitação de Verificação de integridade inspecionando o cabeçalho x-ms-auth-internal-token e validando se ele corresponde ao hash SHA256 da variável de ambiente WEBSITE_AUTH_ENCRYPTION_KEY. Se corresponderem, a solicitação de verificação de integridade será válida e será originária do Serviço de Aplicativo.

Observação

Para a autenticação do Azure Functions, a função que serve como o endpoint de verificação de saúde precisa permitir o acesso anônimo.

.NET

using System;
using System.Security.Cryptography;
using System.Text;

/// <summary>
/// Method <c>HeaderMatchesEnvVar</c> returns true if <c>headerValue</c> matches WEBSITE_AUTH_ENCRYPTION_KEY.
/// </summary>
public bool HeaderMatchesEnvVar(string headerValue)
{
    var sha = SHA256.Create();
    string envVar = Environment.GetEnvironmentVariable("WEBSITE_AUTH_ENCRYPTION_KEY");
    string hash = Convert.ToBase64String(sha.ComputeHash(Encoding.UTF8.GetBytes(envVar)));
    return string.Equals(hash, headerValue, StringComparison.Ordinal);
}

Python

from hashlib import sha256
import base64
import os

def header_matches_env_var(header_value):
    """
    Returns true if SHA256 of header_value matches WEBSITE_AUTH_ENCRYPTION_KEY.
    
    :param header_value: Value of the x-ms-auth-internal-token header.
    """
    
    env_var = os.getenv('WEBSITE_AUTH_ENCRYPTION_KEY')
    hash = base64.b64encode(sha256(env_var.encode('utf-8')).digest()).decode('utf-8')
    return hash == header_value

Java

import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.util.Base64;
import java.nio.charset.StandardCharsets;

public static Boolean headerMatchesEnvVar(String headerValue) throws NoSuchAlgorithmException {
    MessageDigest digest = MessageDigest.getInstance("SHA-256");
    String envVar = System.getenv("WEBSITE_AUTH_ENCRYPTION_KEY");
    String hash = new String(Base64.getDecoder().decode(digest.digest(envVar.getBytes(StandardCharsets.UTF_8))));
    return hash.equals(headerValue);
}

Node.js

var crypto = require('crypto');

function envVarMatchesHeader(headerValue) {
    let envVar = process.env.WEBSITE_AUTH_ENCRYPTION_KEY;
    let hash = crypto.createHash('sha256').update(envVar).digest('base64');
    return hash == headerValue;
}

Observação

O cabeçalho x-ms-auth-internal-token só está disponível no Serviço de Aplicativo para Windows.

Instâncias

Depois que a verificação de integridade estiver habilitada, você poderá reiniciar e monitorar o status das instâncias do aplicativo na guia Instâncias. A guia Instâncias mostra o nome da instância e o status da instância desse aplicativo. Você também pode fazer manualmente uma reinicialização avançada do aplicativo nessa guia selecionando o botão Reiniciar.

Se o status da instância do aplicativo estiver Não íntegro, você poderá reiniciar o processo de trabalho do respectivo aplicativo manualmente selecionando o botão Reiniciar na tabela. A reinicialização não afetará nenhum dos outros aplicativos hospedados no mesmo plano do Serviço de Aplicativo. Se houver outros aplicativos usando o mesmo plano do Serviço de Aplicativo que a instância, eles serão listados no painel que será aberto quando você selecionar Reiniciar.

Se você reiniciar a instância e o processo de reinicialização falhar, você recebe a opção de substituir o trabalho. (Somente uma instância pode ser substituída por hora.) Essa ação afeta todos os aplicativos que usam o mesmo plano do Serviço de Aplicativo.

Para aplicativos Windows, você pode visualizar os processos através do Explorador de processos. Isso fornece mais informações sobre os processos da instância, incluindo contagem de threads, memória privada e tempo total da CPU.

Coleta de informações de diagnóstico

Para aplicativos do Windows, você tem a opção de coletar informações de diagnóstico na guia Verificação de integridade. Habilitar a coleta de diagnóstico adiciona uma regra de recuperação automática que cria despejos de memória para instâncias não íntegras e os salva em uma conta de armazenamento designada. Habilitar essa opção altera as configurações de recuperação automática. Se existirem regras de recuperação automática, recomendamos configurá-las através do diagnóstico do Serviço de Aplicativo.

Depois que a coleção de diagnósticos estiver habilitada, você poderá criar uma conta de armazenamento ou escolher uma existente para seus arquivos. Você só pode selecionar contas de armazenamento na mesma região do seu aplicativo. Lembre-se de que salvar reinicia seu aplicativo. Depois de salvar, se as instâncias do seu site forem consideradas não íntegras após pings contínuos, você poderá ir para o recurso da sua conta de armazenamento e exibir os despejos de memória.

Monitoramento

Depois de fornecer o caminho de verificação de integridade do aplicativo, você pode monitorar a integridade do seu site usando o Azure Monitor. Na página Verificação de integridade no portal, selecione Métricas na barra de ferramentas. Isso abre uma nova página em que você pode ver o histórico de status de verificação de integridade do site e criar uma nova regra de alerta. A métrica de status de verificação de integridade agrega os pings bem-sucedidos e exibe falhas somente quando a instância é considerada não íntegra com base no valor limite de balanceamento de carga de verificação de integridade configurado. Por padrão, esse valor é definido como 10 minutos, portanto, leva 10 pings consecutivos (1 por minuto) para que uma determinada instância seja considerada não íntegra e só então será refletida na métrica. Para obter mais informações sobre como monitorar seus sites, consulte cotas e métricas do Serviço de Aplicativo do Azure.

Limitações

• A verificação de integridade pode ser habilitada para os Planos de Serviço de Aplicativo Gratuito e Compartilhado para que você obtenha as métricas sobre a integridade do site e configure alertas. No entanto, como sites Gratuitos e Compartilhados não dão suporte à expansão, instâncias com falhas não serão substituídas automaticamente. Você deve escalar verticalmente para a camada Básica ou superior para que possa escalar horizontalmente para duas ou mais instâncias e receber o benefício completo da verificação de integridade. Recomendamos essa configuração para aplicativos voltados para produção porque aumenta a disponibilidade e o desempenho do aplicativo.
• Um plano de serviço de aplicativo pode ter no máximo uma instância com problemas substituída por hora e, no máximo, três instâncias por dia.
• Há um limite não configurável no número total de instâncias substituídas pela verificação de integridade por unidade de escala. Se esse limite for atingido, nenhuma instância não íntegra será substituída. Esse valor é redefinido a cada 12 horas.

Perguntas frequentes

O que acontece se meu aplicativo for executado em uma única instância?

Se o aplicativo for escalado apenas para uma instância e ficar não íntegro, ele não será removido do balanceador de carga porque isso deixaria o aplicativo totalmente inoperante. No entanto, após uma hora de pings não íntegros contínuos, a instância será substituída. Escale horizontalmente para duas ou mais instâncias para obter o benefício de novo roteamento da Verificação de Integridade. Se o aplicativo for executado em uma única instância, você ainda poderá usar o recurso de monitoramento de verificação de integridade para acompanhar a integridade do aplicativo.

Por que a solicitação de verificação de integridade não está sendo exibida nos meus logs do servidor Web?

As solicitações de verificação de integridade são enviadas ao site internamente, para que não sejam mostradas nos logs do servidor Web. Você pode adicionar instruções de log ao código de verificação de integridade para manter os logs de quando foi efetuado ping no caminho de verificação de integridade.

As solicitações de verificação de integridade são enviadas por HTTP ou HTTPS?

No Serviço de Aplicativo para Windows e Linux, as solicitações de Verificação de integridade são enviadas por HTTPS quando a opção Somente HTTPS for habilitada no site. Caso contrário, elas serão enviadas por HTTP.

A verificação de integridade segue os redirecionamentos configurados pelo código do aplicativo entre o domínio padrão e o domínio personalizado?

Não, o recurso de Verificação de Integridade execute o ping no caminho do domínio padrão do aplicativo Web. Se houver um redirecionamento do domínio padrão para um domínio personalizado, o código de status retornado pela verificação de integridade não será um 200. Será um redirecionamento (301), que marcará a função de trabalho como não íntegra.

E se eu tiver vários aplicativos no mesmo Plano do Serviço de Aplicativo?

As instâncias não íntegras serão sempre removidas da rotação do balanceador de carga, independentemente de outros aplicativos no plano do Serviço de Aplicativo (até o percentual especificado em WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT). Quando um aplicativo em uma instância permanece não íntegro por mais de uma hora, a instância só será substituída se todos os outros aplicativos nos quais a verificação de integridade estiver habilitada também não estiverem íntegras. Os aplicativos que não têm a verificação de integridade habilitada não serão considerados.

Exemplo

Suponha que você tenha dois aplicativos (ou um aplicativo com um slot) com a verificação de integridade habilitada. Eles são chamados de App A e App B. Ambos estão no mesmo Plano do Serviço de Aplicativo, que está escalado para quatro instâncias. Se o Aplicativo A ficar em estado de falha em duas instâncias, o balanceador de carga para de enviar solicitações para o Aplicativo A nessas duas instâncias. As solicitações ainda são direcionadas para o App B nessas instâncias, assumindo que o App B está íntegro. Se o App A permanecer não íntegro por mais de uma hora nessas duas instâncias, as instâncias só serão substituídas se o App B também estiver não íntegro nessas instâncias. Se o App B estiver íntegro, as instâncias não serão substituídas.

Observação

Se houver outro site ou slot no plano (Aplicativo C) que não tenha a verificação de integridade habilitada, ele não será levado em consideração para a substituição da instância.

E se todas as minhas instâncias não estiverem íntegras?

Se todas as instâncias do aplicativo não estiverem íntegras, o Serviço de Aplicativo não removerá instâncias do balanceador de carga. Nesse cenário, a replicação de todas as instâncias de aplicativo não íntegras da rotação do balanceador de carga causaria efetivamente uma paralisação em seu aplicativo. No entanto, a substituição da instância ainda ocorre.

O que acontece durante uma troca de slots?

A configuração de verificação de integridade não é específica de slot, portanto, após uma troca, a configuração de verificação de integridade do slot trocado é aplicada ao slot de destino e vice-versa. Por exemplo, se você tiver a Verificação de Integridade habilitada para o slot de preparo, o ponto de extremidade configurado será aplicado ao slot de produção após uma troca. Recomendamos usar a configuração consistente para slots de produção e não produção, se possível, para evitar qualquer comportamento inesperado após uma troca.

A verificação de integridade funciona nos Ambientes do Serviço de Aplicativo?

Sim, a verificação de integridade está disponível para o Ambiente de Serviço de Aplicativos v3.

Conteúdo relacionado

• Criar um alerta de log de atividades para monitorar todas as operações de mecanismo de escala automática em sua assinatura
• Criar um alerta de log de atividades para monitorar todas as operações de escalar horizontalmente/reduzir horizontalmente com falha em sua assinatura
• Referência de variáveis de ambiente e configurações de aplicativo