Eventos
17 de mar., 21 - 21 de mar., 10
Junte-se à série de encontros para criar soluções de IA escaláveis com base em casos de uso do mundo real com outros desenvolvedores e especialistas.
Registrar agoraNão há mais suporte para esse navegador.
Atualize o Microsoft Edge para aproveitar os recursos, o suporte técnico e as atualizações de segurança mais recentes.
Observação
A partir de 1º de junho de 2024, os aplicativos do Serviço de Aplicativo recém-criados podem gerar um nome de host padrão exclusivo que usa a convenção de nomenclatura <app-name>-<random-hash>.<region>.azurewebsites.net
. Os nomes de aplicativos existentes permanecem inalterados. Por exemplo:
myapp-ds27dh7271aah175.westus-01.azurewebsites.net
Para obter mais informações, confira Nome do host padrão exclusivo para o recurso do Serviço de Aplicativo.
Este artigo explica 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 do aplicativo fazendo um novo roteamento das solicitações distante das instâncias não íntegras e substituindo instâncias caso permaneçam não íntegras. A verificação de integridade funciona executando pings no seu aplicativo Web a cada minuto, através de um caminho que você escolher.
Lembre-se de que /api/health é apenas um exemplo. Não existe um 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.
Observação
Waiting for health check response
, isso pode indicar que a verificação está falhando devido a um código de status HTTP 307; o que pode ocorrer se você estiver com o redirecionamento HTTPS habilitado, mas a opção HTTPS Only
desabilitada./health
ou /api/health
.Observação
Cuidado
Alterações de configuração da verificação de Integridade reinicie seu aplicativo. Para minimizar o impacto nos aplicativos de produção, é recomendável Configurar slots de preparo e alternar para produçã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 necessário de solicitações com falha para que uma instância seja considerada não íntegra e removida do balanceador de carga. Por exemplo, quando isso estiver 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 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 escalado para quatro instâncias e três não estiverem íntegras, duas são excluídas. As outras duas instâncias (uma íntegra e uma não íntegra) continuam a receber 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 ). |
A verificação de integridade com os 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ê estiver usando seu próprio sistema de autenticação, o caminho de verificação de Integridade deverá permitir o acesso anônimo. Para garantir a segurança do ponto de extremidade de Verificação de integridade, você deve primeiro usar recursos como restrições de IP, certificados de clienteou 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 eles corresponderem, a solicitação de Verificação de integridade será válida e será originada do Serviço de Aplicativo.
Observação
Para a autenticação do Azure Functions, a função que atua como ponto de extremidade de Verificação de integridade precisa permitir o acesso anônimo.
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);
}
Observação
O cabeçalho x-ms-auth-internal-token
só está disponível no Serviço de Aplicativo para Windows.
Após habilitar a Verificação de integridade, você pode reiniciar e monitorar o status das instâncias do seu aplicativo guia de instâncias. A guia de instâncias mostra o nome da instância e o status da instância desse aplicativo. Você também pode reiniciar manualmente a instância a partir dessa guia.
Se o status da instância do aplicativo estiver "não íntegro", você poderá reiniciá-la manualmente usando o botão de reinicialização na tabela. Tenha em mente que quaisquer outros aplicativos hospedados no mesmo Plano do Serviço de Aplicativo da instância também serão afetados pela reinicialização. Se houver outros aplicativos usando o mesmo Plano do Serviço de Aplicativo da instância, eles serão listados no painel de abertura no botão de reinicialização.
Se você reiniciar a instância e o processo de reinicialização falhar, terá a opção de substituir a função de trabalho. (Apenas uma instância pode ser substituída por uma hora). Isso também afetará todos os aplicativos que utilizam o mesmo Plano do Serviço do 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 a contagem de threads, memória privada e tempo total de CPU.
Para aplicativos Windows, você tem a opção de coletar informações de diagnóstico na guia de Verificação de Integridade. Habilitar a coleta de diagnósticos adiciona uma regra de recuperação automática que cria despejos de memória para instâncias não íntegras e as 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 coleta de diagnósticos estiver habilitada, você poderá criar ou escolher uma conta de armazenamento 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.
Depois de fornecer o caminho de verificação de Integridade do aplicativo, você pode monitorar a integridade do seu site usando Azure Monitor. Na folha Verificação de integridade no portal, selecione Métricas na barra de ferramentas superior. Isso abre uma nova folha 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 as falhas de exibição somente quando a instância foi considerada não íntegra com base no valor do 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 mais informações sobre como monitorar seus sites, confira a página Cotas e alertas do Serviço de Aplicativo.
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 estiver em execução em uma única instância, você ainda poderá usar o recurso de monitoramento da Verificação de Integridade para acompanhar a integridade do aplicativo.
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.
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.
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á 200. Será um redirecionamento (301), que marcará a função de trabalho como não íntegra.
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 com a Verificação de integridade habilitada também estiverem não íntegros. Os aplicativos que não têm a verificação de integridade habilitada não serão considerados.
Imagine 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 se tornar não íntegro em duas instâncias, o balanceador de carga deixará 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 houvesse outro site ou slot no plano (App C) sem a verificação de integridade habilitada, ele não seria levado em consideração para a substituição da instância.
Se todas as instâncias do seu 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 acontecerá.
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 será 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.
Sim, a verificação de integridade está disponível para o Ambiente do Serviço de Aplicativo v3.
Eventos
17 de mar., 21 - 21 de mar., 10
Junte-se à série de encontros para criar soluções de IA escaláveis com base em casos de uso do mundo real com outros desenvolvedores e especialistas.
Registrar agoraTreinamento
Módulo
Introdução à Integridade do Serviço do Azure - Training
Introdução à Integridade do Serviço do Azure e como obter informações de integridade da plataforma Azure.