Monitorare le istanze del servizio app usando il controllo integrità

Nota

A partire dal 1° giugno 2024, tutte le app del Servizio app di Azure appena create offriranno la possibilità di generare un nome host predefinito univoco usando la convenzione di denominazione <app-name>-<random-hash>.<region>.azurewebsites.net. I nomi delle app esistenti rimarranno invariati.

Esempio: myapp-ds27dh7271aah175.westus-01.azurewebsites.net

Per altri dettagli, fare riferimento a Nome host predefinito univoco per la risorsa del servizio app.

In questo articolo verrà usato il controllo integrità nel portale di Azure per monitorare le istanze del Servizio app di Azure. Il controllo integrità aumenta la disponibilità dell'applicazione reindirizzando le richieste da istanze non integre e sostituendo le istanze se restano non integre. A tale scopo, ogni minuto effettua il ping di un percorso dell'applicazione Web interessata.

Tenere presente che /api/health è solo un esempio aggiunto a scopo illustrativo. Per impostazione predefinita, non viene creato un percorso del controllo integrità. Assicurarsi che il percorso selezionato sia un percorso valido esistente all'interno dell'applicazione

Operazioni eseguite dal servizio app con i controlli di integrità

• Dopo aver specificato un percorso nell'app, il controllo integrità effettua il ping di questo percorso in tutte le istanze dell'app del Servizio app di Azure a intervalli di 1 minuto.
• Se un'app Web in esecuzione in una determinata istanza non risponde con un codice di stato compreso tra 200 e 299 (inclusi) dopo 10 richieste, il Servizio app di Azure stabilisce che non è integra e la rimuove dal bilanciamento del carico relativo a questa app Web. Il numero di richieste non riuscite in seguito alle quali è possibile considerare un'istanza non integra può essere impostato su un minimo di due richieste.
• Il controllo integrità continua a eseguire il ping dell'istanza non integra anche dopo la rimozione. Se l'istanza inizia a rispondere con un codice di stato integro (200-299), viene reintegrata nel bilanciamento del carico.
• Se l'app Web in esecuzione in un'istanza rimane non integra per un'ora, l'istanza viene sostituita con una nuova.
• Quando si aumenta il numero di istanze, il Servizio app di Azure esegue il ping del percorso del controllo integrità per verificare che le nuove istanze siano pronte.

Nota

• Il controllo integrità non segue i reindirizzamenti 302.
• Verrà sostituita al massimo un'istanza all'ora, con un massimo di tre istanze al giorno per ogni piano del servizio app.
• Se il controllo integrità assegna lo stato Waiting for health check response, è probabile che il controllo abbia esito negativo a causa della presenza di un codice di stato HTTP di tipo 307, che può essere generato se è abilitato il reindirizzamento HTTPS ma è disabilitata l'opzione HTTPS Only.

Abilitare il controllo integrità

1. Per abilitare il controllo integrità, passare al portale di Azure e selezionare l'app del Servizio app di Azure.
2. In Monitoraggio selezionare Controllo integrità.
3. Selezionare Abilita e specificare un percorso URL valido nell'applicazione, ad esempio /health o /api/health.
4. Seleziona Salva.

Nota

• Il piano di servizio app deve essere aumentato a due o più istanze per usare appieno il controllo integrità.
• Il percorso del controllo integrità deve controllare i componenti critici dell'applicazione. Se, ad esempio, l'applicazione dipende da un database e da un sistema di messaggistica, l'endpoint del controllo integrità deve connettersi a questi componenti. Nel caso in cui l'applicazione non riesca a connettersi a un componente critico, il percorso deve restituire un codice di risposta di livello 500 per indicare che l'app non è integra. Inoltre, se il percorso non restituisce una risposta entro 1 minuto, il ping del controllo integrità viene considerato non integro.
• Quando si seleziona il percorso del controllo integrità, assicurarsi di selezionare un percorso che restituisca un codice di stato 200 solo se l'app è completamente pronta.
• Per usare il controllo integrità nell'app per le funzioni, è necessario usare un piano di hosting premium o dedicato.
• Per informazioni dettagliate sul controllo integrità nelle app per le funzioni, vedere: Monitorare app per le funzioni usando Controllo integrità.

Attenzione

Eventuali modifiche alla configurazione del controllo integrità determinano il riavvio dell'app. Per ridurre al minimo l'impatto sulle app di produzione, è consigliabile configurare slot di staging e passare a un ambiente di produzione.

Impostazione

Oltre alle opzioni del controllo integrità, è possibile configurare anche le impostazioni dell'app seguenti:

Nome impostazione app	Valori consentiti	Descrizione
WEBSITE_HEALTHCHECK_MAXPINGFAILURES	2 - 10	Il numero di richieste non riuscite in seguito alle quali un'istanza può essere considerata non integra e viene rimossa dal bilanciamento del carico. Se, ad esempio, questo parametro è impostato su 2, le istanze vengono rimosse dopo 2 ping non riusciti (il valore predefinito è 10).
WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT	1 - 100	Per impostazione predefinita, non possono essere escluse contemporaneamente dal bilanciamento del carico più della metà delle istanze, in modo da non sovraccaricare le istanze integre rimanenti. Se, ad esempio, un piano di servizio app viene aumentato a quattro istanze e tre non sono integre, ne vengono escluse due. Le altre due istanze (una integra e una non integra) continueranno a ricevere richieste. Nello scenario peggiore in cui tutte le istanze non sono integre, non ne verrà esclusa nessuna. Per eseguire l'override di questo comportamento, impostare questo parametro dell'app su un valore compreso tra 1 e 100. Più alto è il valore, maggiore è il numero di istanze non integre che possono essere rimosse (il valore predefinito è 50).

Autenticazione e sicurezza

Il controllo integrità si integra con le funzionalità di autenticazione e autorizzazione del Servizio app di Azure. Se queste funzionalità di sicurezza sono abilitate, non sono necessarie altre impostazioni.

Se si preferisce usare il proprio sistema di autenticazione, il percorso del controllo integrità deve consentire l'accesso anonimo. Per proteggere l'endpoint del controllo integrità, è necessario usare prima funzionalità quali restrizioni IP, certificati client o una rete virtuale per limitare l'accesso all'applicazione. Con queste funzionalità in esecuzione, è possibile autenticare una richiesta del controllo integrità controllandone l'intestazione, x-ms-auth-internal-token, e accertandosi che corrisponda all'hash SHA256 della variabile di ambiente WEBSITE_AUTH_ENCRYPTION_KEY. Se corrispondono, la richiesta del controllo integrità è valida e ha origine dal Servizio app di Azure.

Nota

La funzione che serve da endpoint del controllo integrità deve consentire l'accesso anonimo soprattutto per l'autenticazione di Funzioni di Azure.

.NET

using System;
using System.Text;

/// <summary>
/// Method <c>HeaderMatchesEnvVar</c> returns true if <c>headerValue</c> matches WEBSITE_AUTH_ENCRYPTION_KEY.
/// </summary>
public Boolean HeaderMatchesEnvVar(string headerValue) {
    var sha = System.Security.Cryptography.SHA256.Create();
    String envVar = Environment.GetEnvironmentVariable("WEBSITE_AUTH_ENCRYPTION_KEY");
    String hash = System.Convert.ToBase64String(sha.ComputeHash(Encoding.UTF8.GetBytes(envVar)));
    return hash == headerValue;
}

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;
}

Nota

L'intestazione x-ms-auth-internal-token è disponibile solo nel servizio app di Windows.

Istanze

Dopo aver abilitato il controllo integrità, è possibile riavviare e monitorare lo stato delle istanze dell'applicazione tramite la scheda Istanze, in cui sono riportati il nome e lo stato dell'istanza dell'applicazione e che consente di riavviare manualmente l'istanza.

Se lo stato dell'istanza dell'applicazione non è integro, è possibile riavviare manualmente l'istanza usando il pulsante di riavvio disponibile nella tabella. Tenere presente che, in questo caso, verranno riavviate anche tutte le altre applicazioni ospitate nello stesso piano di servizio app dell'istanza. Se il piano di servizio app dell'istanza viene usato anche da altre applicazioni, queste verranno elencate nel pannello che si apre premendo il pulsante di riavvio.

Se si riavvia l'istanza e il processo di riavvio ha esito negativo, si ha la possibilità di sostituire il ruolo di lavoro (è possibile sostituire una sola istanza all'ora). Questa operazione influisce anche su tutte le altre applicazioni che usano lo stesso piano di servizio app.

I processi possono essere inoltre visualizzati dalle applicazioni Windows tramite Esplora processi, in modo da poter acquisire informazioni più dettagliate sui processi dell'istanza, tra cui il numero di thread, la memoria privata e il tempo totale della CPU.

Raccolta delle informazioni di diagnostica

Per le applicazioni Windows, è possibile raccogliere informazioni di diagnostica nella scheda Controllo integrità. Abilitando la raccolta di informazioni di diagnostica si aggiunge una regola di correzione automatica che crea dump di memoria per le istanze non integre e le salva in un account di archiviazione designato. L'abilitazione di questa opzione modifica le configurazioni di correzione automatica. Se sono già presenti regole di correzione automatica, è consigliabile configurare questa impostazione tramite la scheda di diagnostica del servizio app.

Dopo aver abilitato la raccolta di informazioni di diagnostica, è possibile creare un account di archiviazione per i file o sceglierne uno esistente. È possibile selezionare solo account di archiviazione presenti nella stessa area geografica dell'applicazione. Tenere presente che l'azione di salvataggio riavvia l'applicazione. Al termine del salvataggio, se le istanze del sito vengono trovate non integre dopo la sequenza di ping, è possibile passare alla risorsa dell'account di archiviazione e visualizzare i dump di memoria.

Monitoraggio

Dopo aver specificato il percorso del controllo integrità dell'applicazione, è possibile monitorare l'integrità del sito usando Monitoraggio di Azure. Nel pannello Controllo integrità del portale selezionare la voce Metriche nella barra degli strumenti superiore. Verrà aperto un nuovo pannello in cui è possibile visualizzare la cronologia dello stato di integrità del sito e creare una nuova regola di avviso. Le metriche del controllo integrità aggregano i ping riusciti e gli errori di visualizzazione solo se l'istanza è stata considerata non integra in base alla configurazione del controllo integrità. Per altre informazioni sul monitoraggio dei siti, vedere la guida su Monitoraggio di Azure.

Limiti

• È possibile abilitare il controllo integrità per piani di servizio app gratuiti e condivisi, in modo da disporre di metriche sugli avvisi di integrità e configurazione del sito, ma poiché i siti gratuiti e condivisi non possono aumentare il numero di istanze, eventuali istanze non integre non verranno sostituite. È consigliabile aumentare il numero di istanze fino al livello Basic o superiore, in modo da poter aumentare le istanze a più di 2 e sfruttare appieno i vantaggi del controllo integrità. Questo suggerimento è valido soprattutto per le applicazioni di produzione, poiché contribuisce ad aumentare la disponibilità e le prestazioni dell'app.
• Nell'ambito di un piano di servizio app, è possibile sostituire una sola istanza non integra all'ora e, al massimo, tre istanze al giorno.
• Esiste un limite non configurabile relativamente al numero totale di istanze sostituite dal controllo integrità per unità di scala. Se viene raggiunto questo limite, non viene sostituita alcuna istanza non integra. Questo valore viene reimpostato ogni 12 ore.

Domande frequenti

Cosa accade se l'app è in esecuzione in una singola istanza?

Se l'app viene ridotta a una sola istanza e diventa non integra, non verrà esclusa dal bilanciamento del carico perché questa operazione eliminerebbe completamente l'applicazione. Tuttavia, dopo un'ora di ping non integri continui, l'istanza viene sostituita. Aumentare quindi il numero di istanze a due o più in modo da usufruire del vantaggio di reindirizzamento offerto dal controllo integrità. Se l'app è in esecuzione in una singola istanza, è comunque possibile usare la funzionalità di monitoraggio del controllo integrità per tenere traccia dell'integrità dell'applicazione.

Perché le richieste del controllo integrità non vengono visualizzate nei log del server Web?

Le richieste del controllo integrità vengono inviate al sito internamente e, pertanto, non vengono visualizzate nei log del server Web. È comunque possibile aggiungere istruzioni di log al codice del controllo integrità per sapere quando è stato eseguito il ping del percorso del controllo integrità.

Le richieste del controllo integrità vengono inviate tramite HTTP o HTTPS?

Nel servizio app di Windows, le richieste del controllo integrità vengono inviate tramite HTTPS se nel sito è abilitata l'opzione solo HTTPS. In caso contrario, vengono inviate tramite HTTP. Nel servizio app di Linux, le richieste del controllo integrità vengono inviate attualmente solo tramite HTTP e non possono essere inviate tramite HTTPS.

Il controllo integrità segue i reindirizzamenti configurati tramite il codice dell'applicazione tra il dominio predefinito e il dominio personalizzato?

No, la funzionalità Controllo integrità esegue il ping del percorso del dominio predefinito dell'applicazione Web. Se è presente un reindirizzamento dal dominio predefinito a un dominio personalizzato, il codice di stato restituito dal controllo integrità non sarà 200, ma sarà un reindirizzamento (301), che contrassegnerà il ruolo di lavoro non integro.

Cosa accade se sono presenti più app nello stesso piano del servizio app?

Eventuali istanze non integre verranno sempre rimosse dalla rotazione del servizio di bilanciamento del carico indipendentemente dalla presenza di altre app nel piano di servizio app (fino alla percentuale specificata in WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT). Quando un'app in un'istanza rimane non integra per più di un'ora, l'istanza verrà sostituita solo se anche tutte le altre app con il controllo integrità abilitato non sono integre. Eventuali app che non hanno il controllo integrità abilitato non verranno prese in considerazione.

Esempio

Si supponga di avere due applicazioni (o un'app con uno slot) con il controllo integrità abilitato, denominate App A e App B, presenti nello stesso piano di servizio app e che il piano venga aumentato a quattro istanze. Se l'app A diventa non integra in due istanze, il servizio di bilanciamento del carico interrompe l'invio di richieste all'App A in queste due istanze. Le richieste vengono comunque indirizzate all'App B in quelle stesse istanze, presupponendo che l'App B sia integra. Se l'app A rimane non integra per più di un'ora nelle due istanze, queste vengono sostituite solo se anche l'App B è non integra in tali istanze. Se l'app B è integra, l'istanza non viene sostituita.

Nota

Se nel piano (Sito C) è presente un altro sito o uno slot senza il controllo integrità abilitato, non verrà preso in considerazione per la sostituzione dell'istanza.

Cosa accade se tutte le istanze non sono integre?

Nel caso in cui tutte le istanze dell'applicazione non siano integre, il servizio app non escluderà le istanze dal bilanciamento del carico. In questo scenario, infatti, l'esclusione di tutte le istanze di app non integre dalla rotazione del servizio di bilanciamento del carico determinerebbe un'interruzione dell'applicazione. La sostituzione delle istanze verrà comunque rispettata.

Il controllo integrità funziona in ambienti del servizio app?

Sì, il controllo integrità è disponibile per la versione 3 dell'ambiente del servizio app, ma non per le versioni 1 o 2. Se si usa una versione precedente dell'ambiente del servizio app, è possibile usare la funzionalità di migrazione per eseguire la migrazione dell'ambiente del servizio app alla versione 3.

Passaggi successivi

• Creare un avviso di log attività per monitorare tutte le operazioni del motore di scalabilità automatica della sottoscrizione
• Creare un avviso di log attività per monitorare tutte le operazioni di scalabilità automatica in riduzione e in aumento non riuscite per la sottoscrizione
• Informazioni di riferimento sulle variabili di ambiente e le impostazioni dell'app