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. A verificação de integridade aumenta a disponibilidade da sua aplicação, redirecionando solicitações para longe de instâncias com problemas e substituindo-as se continuarem com problemas. Ele faz isso ao enviar um sinal para a sua aplicação web a cada minuto, por um caminho que você escolher.

Observe que /api/health é apenas um exemplo. Não há nenhum caminho de "Health check" padrão. Você deve certificar-se de que o caminho escolhido é um caminho válido que existe em seu aplicativo.

Como funciona o exame de integridade

• Quando recebe um caminho na sua aplicação, a verificação de integridade faz ping no caminho em todas as instâncias da sua aplicação no App Service em intervalos de 1 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 (inclusive) 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 configurado para no mínimo duas solicitações.
• Depois que a instância for removida, a verificação de saúde continuará a enviar ping nela. Se a instância começar a responder com um código de status íntegro (200-299), a instância será retornada ao balanceador de carga.
• Se a aplicação web em execução numa instância permanecer em mau estado durante uma hora, a instância será substituída por uma nova.
• Ao escalar horizontalmente, o Serviço de Aplicativo envia um ping para o caminho de verificação de integridade para garantir que novas instâncias estejam prontas.

Observação

• A verificação do estado de saúde não segue redirecionamentos 302.
• No máximo, uma instância será substituída por hora, com um máximo de três instâncias por dia por Plano do Serviço de Aplicativo.
• Se a verificação de integridade estiver enviando o status Waiting for health check response, é provável que a verificação esteja falhando devido a um código de status HTTP de 307, o que pode acontecer se você tiver o redirecionamento HTTPS habilitado, mas tiver HTTPS Only desativado.

Ativar verificação de integridade

1. Para habilitar a verificação de integridade, aceda ao portal do Azure e selecione a sua aplicação do App Service.
2. Em Monitoramento, selecione Verificação de integridade.
3. Selecione Ativar e forneça um caminho de URL válido para seu aplicativo, como /health ou /api/health.
4. Selecione Guardar.

Observação

• O seu plano de Serviço de Aplicações deve ser dimensionado para duas ou mais instâncias para tirar total partido da verificação de integridade.
• O caminho de verificação do estado de saúde deve verificar os componentes críticos da sua aplicação. Por exemplo, se a sua aplicação depende de uma base de dados e de um sistema de mensagens, o endpoint de Health Check deve ligar-se a esses componentes. Se a aplicação não conseguir estabelecer ligação com um componente crítico, o caminho deverá retornar um código de resposta de nível 500 para indicar que a aplicação não está saudável. 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 comprovação de saúde, certifique-se de que está a seleccionar um caminho que retorna um código de status 200 somente quando o aplicativo estiver totalmente operacional.
• Para usar a verificação de integridade em um aplicativo funcional, você deve usar um plano de hospedagem premium ou dedicado.
• Detalhes sobre a verificação de integridade em aplicativos de função podem ser encontrados aqui: Monitorar aplicativos de função usando a verificação de integridade.

Atenção

As alterações na configuração da verificação de integridade reiniciam a sua aplicação. Para minimizar o impacto nas aplicações de produção, recomendamos configurar slots de teste e fazer a transição para produção.

Configuração

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

Nome de definição de aplicação	Valores permitidos	Descrição
WEBSITE_HEALTHCHECK_MAXPINGFAILURES	2 - 10	O número necessário de solicitações falhadas para que uma instância seja considerada não saudável e removida do balanceador de carga. Por exemplo, quando isso é definido como 2, suas instâncias são removidas após 2 pings com falha. (O valor padrão é 10.)
WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT	1 - 100	Por padrão, para evitar sobrecarregar as instâncias saudáveis restantes, não mais da metade das instâncias será excluída do balanceador de carga de cada vez. Por exemplo, se um plano do Serviço de Aplicativo for dimensionado para quatro instâncias e três não estiverem íntegros, duas serão excluídas. As outras duas instâncias (uma saudável e outra não saudável) continuam a receber solicitações. Num cenário em que todas as instâncias estão doentes, nenhuma é 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 casos não saudáveis são removidos. (O valor padrão é 50.).

Autenticação e segurança

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

Se estiveres a usar o teu próprio sistema de autenticação, o caminho de verificação de saúde deverá permitir acesso anónimo. Para fornecer segurança para o ponto de extremidade de verificação de integridade, deve-se primeiro usar recursos como restrições de IP, certificados de cliente ou uma rede virtual para restringir o acesso ao aplicativo. Depois de ter esses recursos instalados, você pode autenticar 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 WEBSITE_AUTH_ENCRYPTION_KEYde ambiente. Se corresponderem, a solicitação de verificação de integridade é válida e originada do Serviço de Aplicativo.

Observação

Para a autenticação do Azure Functions, a função que serve como ponto de verificação de integridade precisa permitir 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);
}

Píton

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 x-ms-auth-internal-token cabeçalho só está disponível no Serviço de Aplicativo para Windows.

Instâncias

Assim que o Health check estiver habilitado, poderá reiniciar e monitorizar o estado das instâncias da aplicação no separador Instâncias. O separador Instâncias mostra o nome da instância e o estado dessa instância da aplicação. Você também pode fazer manualmente uma reinicialização avançada do aplicativo a partir desta guia usando o botão "Reiniciar".

Se o estado da instância da aplicação for "não íntegro", pode reiniciar o processo de trabalho da respetiva aplicação manualmente usando o botão 'Reiniciar' na tabela. Isso não afetará nenhum dos outros aplicativos hospedados no mesmo plano do Serviço de Aplicativo. Se houver outras aplicações a utilizar o mesmo plano de Serviço de Aplicativo que a instância, elas serão listadas no painel inicial associado ao botão de reiniciar.

Se você reiniciar a instância e o processo de reinicialização falhar, você terá a opção de substituir o trabalhador. (Apenas uma instância pode ser substituída por hora.) Isso afetará todos os aplicativos que usam o mesmo plano do Serviço de Aplicativo.

Para aplicativos do Windows, você também pode exibir processos por meio do Process Explorer. Isso fornece mais informações sobre os processos da instância, incluindo contagem de threads, memória privada e tempo total da CPU.

Recolha 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. A habilitação da 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. Ativar essa opção altera as configurações de recuperação automática. Se houver regras de recuperação automática existentes, recomendamos configurá-las por meio do diagnóstico do Serviço de Aplicativo.

Depois que a coleta de diagnóstico 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. Após guardar, se as instâncias do seu site apresentarem problemas após pings contínuos, pode aceder ao recurso da conta de armazenamento e visualizar os dumps de memória.

Monitorização

Depois de fornecer o caminho de verificação de integridade do seu aplicativo, você pode monitorar a integridade do seu site usando o Azure Monitor. Na folha Verificação de integridade no portal, selecione Métricas na barra de ferramentas superior. Isso abre uma nova folha onde você pode ver o histórico de status da verificação de integridade do site e criar uma nova regra de alerta. A métrica de status da verificação de integridade agrega os pings bem-sucedidos e exibe apenas as falhas quando a instância é considerada não saudável, com base no valor do limite de balanceamento de carga da verificação de integridade configurado. Por defeito, este valor é definido como 10 minutos, portanto, são necessários 10 pings consecutivos (1 por minuto) para que uma determinada instância seja considerada não saudável, e só então isso será refletido na métrica. Para obter mais informações sobre como monitorar seus sites, consulte Cotas e alertas do Serviço de Aplicativo do Azure.

Limitações

• A verificação de integridade pode ser habilitada para os planos do Serviço de Aplicativo Gratuito e Compartilhado , para que você possa ter métricas sobre a integridade do site e configurar alertas. No entanto, como os sites gratuitos e compartilhados não oferecem suporte à expansão, as instâncias não íntegras não serão substituídas automaticamente. Você deve escalar para a camada Básica ou superior para poder expandir para duas ou mais instâncias e obter todos os benefícios da verificação de integridade. Isso é recomendado para aplicativos voltados para produção, pois aumenta a disponibilidade e o desempenho do aplicativo.
• Um plano de Serviço de Aplicações pode ter no máximo uma instância não saudável 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 este limite for atingido, nenhuma instância com problemas será substituída. Esse valor é redefinido a cada 12 horas.

Perguntas frequentes

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

Se a sua aplicação estiver dimensionada apenas para uma instância e ficar com problemas de funcionamento, ela não será removida do equilibrador de carga porque isso iria encerrar completamente a sua aplicação. No entanto, após uma hora de pings insalubres contínuos, a instância é substituída. Expanda para duas ou mais instâncias para obter o benefício de reencaminhamento da verificação de saúde. Se seu aplicativo estiver sendo 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 as solicitações de verificação de integridade não são exibidas nos logs do meu servidor Web?

As solicitações de verificação de integridade são enviadas para seu site internamente, portanto, a solicitação não será exibida nos logs do servidor Web. Você pode adicionar instruções de log no código de verificação de integridade para manter registros de quando o caminho da verificação de integridade é pingado.

As solicitações de verificação de saúde 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 via HTTPS quando Somente HTTPS está habilitado no site. Caso contrário, eles serão enviados por HTTP.

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

Não, o recurso Verificação de integridade executa 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 assinala o trabalhador como não saudável.

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

As instâncias não saudáveis serão sempre removidas da rotação do balanceador de carga, independentemente de outras aplicações no plano App Service (até a percentagem especificada 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 está habilitada também não estiverem íntegros. Os aplicativos que não têm a verificação de integridade ativada não serão levados em consideração.

Exemplo

Imagine que você tem dois aplicativos (ou um aplicativo com um slot) com a verificação de integridade ativada. Eles são chamados de App A e App B. Eles estão no mesmo plano do Serviço de Aplicativo e o plano é expandido para quatro instâncias. Se o Aplicativo A não estiver funcional em duas instâncias, o balanceador de carga deixa de enviar solicitações para o Aplicativo A nessas duas instâncias. As solicitações ainda são roteadas para o Aplicativo B nessas instâncias, supondo que o Aplicativo B esteja íntegro. Se a Aplicação A permanecer não saudável por mais de uma hora nessas duas instâncias, estas só serão substituídas se a Aplicação B também não estiver saudável nessas instâncias. Se o Aplicativo B estiver íntegro, as instâncias não serão substituídas.

Observação

Se houvesse outro site ou slot no plano (App C) sem a verificação de integridade ativada, ele não seria levado em consideração para a substituição da instância.

E se todas as minhas instâncias não estiverem saudáveis?

Se todas as instâncias do seu aplicativo estiverem não saudáveis, o App Service não removerá instâncias do balanceador de carga. Nesse cenário, retirar todas as instâncias de aplicação comprometidas do ciclo do balanceador de carga efetivamente causaria uma interrupção na sua aplicação. No entanto, a substituição da instância ainda ocorrerá.

O que acontece durante uma troca de slots?

A configuração da verificação de integridade não é específica do slot, portanto, após uma troca, a configuração da verificação de integridade do slot trocado será aplicada ao slot de destino e vice-versa. Por exemplo, se tiveres a Verificação de Integridade ativada para o teu slot intermédio, o endpoint configurado será aplicado à slot de produção após uma troca. Recomendamos o uso de uma configuração consistente para slots de produção e não produção, se possível, para evitar qualquer comportamento inesperado após a troca.

A verificação de integridade funciona em ambientes do Serviço de Aplicativo?

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

Próximos passos

• Crie um Alerta de Registo de Atividades para monitorizar todas as operações do motor Autoscale na sua subscrição
• Crie um Alerta de Registro de Atividades para monitorar todas as operações de dimensionamento/expansão automática com falha em sua assinatura
• Referência de variáveis de ambiente e configurações de aplicativo