Monitoraggio di metriche e log in Frontdoor di Azure

I report forniscono informazioni dettagliate sul flusso del traffico attraverso Frontdoor di Azure, il Web Application Firewall (WAF) e l'applicazione.

Metrica

Frontdoor di Azure misura e invia le metriche in intervalli di 60 secondi. Le metriche possono richiedere fino a 3 minuti per essere elaborate da Monitoraggio di Azure e potrebbero non essere visualizzate fino al completamento dell'elaborazione. Le metriche possono essere visualizzate anche in grafici o griglie e sono accessibili tramite il portale di Azure, Azure PowerShell, l'interfaccia della riga di comando di Azure e le API di Monitoraggio di Azure. Per altre informazioni, vedere le metriche di Monitoraggio di Azure.

Le metriche elencate nella tabella seguente vengono registrate e archiviate gratuitamente per un periodo di tempo limitato. Per un costo aggiuntivo, è possibile archiviare per un periodo di tempo più lungo.

Registri

Registra tutte le richieste che passano attraverso Frontdoor di Azure. L'elaborazione e l'archiviazione dei log possono richiedere alcuni minuti.

Esistono più log di Frontdoor, che è possibile usare per scopi diversi:

• È possibile usare i log di accesso per identificare le richieste lente, determinare le percentuali di errore e comprendere il funzionamento del comportamento di memorizzazione nella cache di Frontdoor per la soluzione.
• I log di Web Application Firewall (WAF) possono essere usati per rilevare potenziali attacchi e rilevamenti falsi positivi che potrebbero indicare richieste legittime bloccate dal WAF. Per altre informazioni sui log WAF, vedere Monitoraggio e registrazione di Web Application Firewall di Azure.
• È possibile usare i log del probe di integrità per identificare le origini non integre o che non rispondono alle richieste provenienti da alcuni PoP distribuiti geograficamente di Frontdoor.
• I log attività offrono visibilità sulle operazioni eseguite sulle risorse di Azure, come ad esempio le modifiche di configurazione al profilo Frontdoor di Azure.

I log di accesso e WAF includono un riferimento di rilevamento, che viene propagato anche nelle richieste alle origini e alle risposte client usando l'intestazione X-Azure-Ref. È possibile usare il riferimento di rilevamento per ottenere una visualizzazione end-to-end dell'elaborazione delle richieste dell'applicazione.

I log di accesso, i log del probe di integrità e i log WAF non sono abilitati per impostazione predefinita. Per abilitare e archiviare i log di diagnostica, vedere Configurare i log di Frontdoor di Azure. Le voci dei log attività vengono raccolte per impostazione predefinita e possono essere visualizzate nel portale di Azure.

Log di accesso

Le informazioni su ogni richiesta vengono registrate nel log di accesso. Ogni voce del log di accesso contiene le informazioni elencate nella tabella seguente.

Log del probe di integrità

Frontdoor di Azure registra ogni richiesta di probe di integrità non riuscita. Questi log consentono di diagnosticare i problemi relativi a un'origine. I log forniscono informazioni che è possibile usare per analizzare il motivo dell'errore e quindi riportare l'origine a uno stato integro.

Alcuni scenari per cui questo log può essere utile sono:

• Si è notato che il traffico di Frontdoor di Azure è stato inviato a un subset delle origini. Ad esempio, si potrebbe aver notato che solo tre su quattro origini ricevono traffico. Si vuole sapere se le origini ricevono e rispondono ai probe di integrità in modo da sapere se le origini sono integre.
• Si è notato che la metrica della percentuale di integrità dell'origine è inferiore a quella prevista. Si vuole sapere quali origini vengono registrate come non integre e il motivo degli errori del probe di integrità.

Ogni voce del log probe di integrità ha lo schema seguente:

Il frammento JSON di esempio seguente mostra una voce del log del probe di integrità per una richiesta di probe di integrità non riuscita.

{
  "records": [
    {
      "time": "2021-02-02T07:15:37.3640748Z",
      "resourceId": "/SUBSCRIPTIONS/mySubscriptionID/RESOURCEGROUPS/myResourceGroup/PROVIDERS/MICROSOFT.CDN/PROFILES/MyProfile",
      "category": "FrontDoorHealthProbeLog",
      "operationName": "Microsoft.Cdn/Profiles/FrontDoorHealthProbeLog/Write",
      "properties": {
        "healthProbeId": "9642AEA07BA64675A0A7AD214ACF746E",
        "POP": "MAA",
        "httpVerb": "HEAD",
        "result": "OriginError",
        "httpStatusCode": "400",
        "probeURL": "http://www.example.com:80/",
        "originName": "www.example.com",
        "originIP": "PublicI:Port",
        "totalLatencyMilliseconds": "141",
        "connectionLatencyMilliseconds": "68",
        "DNSLatencyMicroseconds": "1814"
      }
    }
  ]
}

Log di Web Application Firewall

Per altre informazioni sui log di Web Application Firewall (WAF) di Frontdoor, vedere Monitoraggio e registrazione di Web Application Firewall di Azure.

Log attività

I log attività forniscono informazioni sulle operazioni di gestione sulle risorse di Frontdoor di Azure. I log includono informazioni dettagliate su ogni operazione di scrittura eseguita su una risorsa Frontdoor di Azure, tra cui quando si è verificata l'operazione, chi l'ha eseguita e quale operazione è stata eseguita.

Per altre informazioni, vedere Visualizzare i log attività.

Passaggi successivi

Per abilitare e archiviare i log di diagnostica, vedere Configurare i log di Frontdoor di Azure.

Quando si usa Frontdoor di Azure (versione classica), è possibile monitorare le risorse nei modi seguenti:

• Metrics (Metriche). Frontdoor di Azure include attualmente otto metriche per visualizzare i contatori delle prestazioni.
• Log. I log di attività e diagnostica consentono di salvare o usare i dati delle prestazioni, di accesso e di altre tipologie da una risorsa a fini di monitoraggio.

Metrica

Le metriche sono una funzionalità di alcune risorse di Azure che consente di visualizzare i contatori delle prestazioni nel portale. Di seguito sono riportate le metriche di Frontdoor disponibili:

Log attività

I log attività forniscono informazioni sulle operazioni eseguite in un profilo Frontdoor di Azure (versione classica). Determinano anche cosa, chi e quando per qualsiasi operazione di scrittura (put, post o delete) eseguita su un profilo Frontdoor di Azure (versione classica).

Accedere ai log attività in Frontdoor o a tutti i log delle risorse di Azure in Monitoraggio di Azure. Per visualizzare i log di attività:

1. Selezionare l'istanza di Frontdoor.

2. Selezionare Log attività.

   

3. Scegliere un ambito di filtraggio, quindi selezionare Applica.

Log di diagnostica

I log di diagnostica non elaborati offrono informazioni dettagliate sulle operazioni e sugli errori importanti per il controllo e la risoluzione dei problemi. I log di diagnostica differiscono dai log attività.

I log attività offrono informazioni dettagliate sulle operazioni eseguite sulle risorse di Azure. I log di diagnostica forniscono informazioni approfondite sulle operazioni eseguite dalla risorsa. Per altre informazioni, vedere Log di diagnostica di Monitoraggio di Azure.

Per configurare i log di diagnostica per Frontdoor di Azure (versione classica):

1. Selezionare il profilo Frontdoor di Azure (versione classica).

2. Selezionare impostazioni di diagnostica.

3. Selezionare Attiva diagnostica. Archiviare i log di diagnostica con le metriche in un account di archiviazione, trasmessi a un hub eventi o inviati ai log di Monitoraggio di Azure.

Frontdoor attualmente fornisce i log di diagnostica. I log di diagnostica non elaborati forniscono richieste API singole le cui voci hanno lo schema seguente:

Deprecazione di Inviato o shield dell'origine

La proprietà del log non elaborato isSentToOriginShield è deprecata e sostituita da un nuovo campo: isReceivedFromClient. Se si sta utilizzando il campo deprecato, passare al nuovo campo.

I log non elaborati includono i log generati dal bordo della rete CDN (POP figlio) e dello shield dell'origine. Lo shield dell'origine si riferisce ai nodi padre ubicati strategicamente in tutto il mondo. Questi nodi comunicano con i server dell'origine e riducono il carico di traffico sull'origine.

Per ogni richiesta inviata a uno shield dell'origine sono presenti due voci di log:

• Una per i nodi perimetrali
• Uno per lo shield dell'origine.

Per distinguere i dati in uscita o le risposte dei nodi perimetrali rispetto allo shield dell'origine è possibile usare il campo isReceivedFromClient che consente di ottenere i dati corretti.

Se il valore è false, la richiesta riceve una risposta dallo shield dell'origine ai nodi perimetrali. Questo approccio è efficace per confrontare i log non elaborati e i dati di fatturazione. Non sono previsti addebiti per i dati in uscita dallo shield dell'origine ai nodi perimetrali. Vengono addebitati costi per i dati in uscita dai nodi perimetrali ai client.

Esempio di query di Kusto per escludere i log generati sullo shield dell'origine in Log Analytics.

AzureDiagnostics | where Category == "FrontdoorAccessLog" and isReceivedFromClient_b == true

Frontdoor di Azure usa una tecnica chiamata suddivisione degli oggetti in blocchi. Quando viene richiesto un file di grandi dimensioni, Frontdoor di Azure recupera piccole parti del file dall'origine. Dopo che il server POP Frontdoor di Azure riceve un intervallo completo o di byte del file richiesto, il server perimetrale frontdoor di Azure richiede il file dall'origine in blocchi di 8 MB.

Quando il blocco arriva al bordo Frontdoor di Azure, viene memorizzato nella cache e reso immediatamente disponibile all'utente. Frontdoor di Azure esegue quindi la prelettura del blocco successivo in parallelo. Questa prelettura fa sì che il contenuto resti in anticipo di un blocco rispetto all'utente, riducendo la latenza. Questo processo continua finché non viene scaricato l'intero file (se richiesto), non sono disponibili tutti gli intervalli di byte (se richiesto) o il client non termina la connessione. Per altre informazioni sulla richiesta di intervalli di byte, vedere RFC 7233. Frontdoor di Azure memorizza nella cache tutti i blocchi ricevuti. Il file non deve essere necessariamente memorizzato interamente nella cache di Frontdoor. Le richieste successive per i file o gli intervalli di byte vengono gestite dalla cache di Frontdoor di Azure. Se non tutti i blocchi vengono memorizzati nella cache di Frontdoor di Azure, viene usata la prelettura per richiedere i blocchi dall'origine. Questa ottimizzazione presuppone il fatto che il server di origine supporti le richieste di intervalli di byte. Se il server di origine non supporta le richieste di intervalli di byte, questa ottimizzazione non è efficace.

Passaggi successivi

• Informazioni su come creare un profilo Frontdoor (versione classica) di Azure
• Informazioni sul funzionamento di Frontdoor di Azure (versione classica)