Monitoraggio di metriche e log in Frontdoor di Azure
Frontdoor di Azure offre diverse funzionalità che consentono di monitorare l'applicazione, tenere traccia delle richieste ed eseguire il debug della configurazione di Frontdoor.
I log e le metriche vengono archiviati e gestiti da Monitoraggio 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.
| Metrica di | Descrizione | Dimensioni | Aggregazioni consigliate |
|---|---|---|---|
| Rapporto riscontri byte | Percentuale di traffico servito dalla cache Frontdoor di Azure, calcolato rispetto al traffico in uscita totale. Il rapporto di riscontri dei byte è basso se la maggior parte del traffico viene inoltrata all'origine anziché servita dalla cache. Rapporto riscontri byte = (in uscita dal bordo - in uscita dall'origine)/in uscita dal bordo. Scenari esclusi dal calcolo del rapporto riscontri byte:
|
Endpoint | Avg, Min |
| Percentuale di integrità origine | Percentuale di probe di integrità riusciti inviati da Frontdoor di Azure alle origini. | Origine, Gruppo di origine | Media |
| Latenza origine | Frontdoor di Azure calcola il tempo trascorso dall'invio della richiesta all'origine alla ricezione dell'ultimo byte di risposta dall'origine. | Endpoint, Origine | Avg, Max |
| Conteggio richieste di origine | Numero di richieste inviate da Frontdoor di Azure alle origini. | Endpoint, Origine, Stato HTTP, Gruppo di stato HTTP | Avg, Sum |
| Percentuale di 4XX | Percentuale di tutte le richieste client per le quali il codice di stato della risposta è 4XX. | Endpoint, Paese client, Area client | Avg, Max |
| Percentuale di 5XX | Percentuale di tutte le richieste client per le quali il codice di stato della risposta è 5XX. | Endpoint, Paese client, Area client | Avg, Max |
| Conteggio richieste | Numero di richieste client gestite tramite Frontdoor di Azure, incluse le richieste gestite interamente dalla cache. | Endpoint, Paese client, Area client, Stato HTTP, Gruppo di stato HTTP | Avg, Sum |
| Dimensioni della richiesta | Numero di byte inviati come richieste dai client a Frontdoor di Azure. | Endpoint, Paese client, area client, stato HTTP, gruppo di stato HTTP | Avg, Max |
| Dimensioni della risposta | Numero di byte inviati come risposte da Frontdoor ai client. | Endpoint, paese client, area client, stato HTTP, gruppo di stato HTTP | Avg, Max |
| Latenza totale | Frontdoor di Azure riceve la richiesta client e invia l'ultimo byte di risposta al client. Questo è il tempo totale impiegato. | Endpoint, Paese client, Area client, Stato HTTP, Gruppo di stato HTTP | Avg, Max |
| Conteggio delle richieste web application firewall | Numero di richieste elaborate dal Web Application Firewall di Frontdoor di Azure. | Azione, Nome criterio, Nome regola | Avg, Sum |
Nota
Se si verifica il timeout di una richiesta all'origine, il valore della dimensione Stato Http è 0.
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.
| Proprietà | Descrizione |
|---|---|
| TrackingReference | Si tratta di una stringa di riferimento univoca che identifica una richiesta servita da Frontdoor di Azure. Il riferimento di rilevamento viene inviato al client e all'origine usando le intestazioni X-Azure-Ref. Usare il riferimento di rilevamento durante la ricerca di una richiesta specifica nei log di accesso o WAF. |
| Time | Data e ora in cui il bordo Frontdoor di Azure ha recapitato il contenuto richiesto al client (in formato UTC). |
| HttpMethod | Metodo HTTP usato dalla richiesta: DELETE, GET, HEAD, OPTIONS, PATCH, POST o PUT. |
| HttpVersion | Versione HTTP specificata dal client nella richiesta. |
| RequestUri | URI della richiesta ricevuta. Questo campo contiene lo schema completo, la porta, il dominio, il percorso e la stringa di query. |
| HostName | Nome host nella richiesta dal client. Se si abilitano domini personalizzati e si dispone di un dominio con caratteri jolly (*.contoso.com), il valore del campo del log HostName è subdomain-from-client-request.contoso.com. Se si usa il dominio Frontdoor di Azure (contoso-123.z01.azurefd.net), il valore del campo del log HostName è contoso-123.z01.azurefd.net. |
| RequestBytes | Dimensioni del messaggio di richiesta HTTP in byte, inclusi intestazioni e corpo della richiesta. |
| ResponseBytes | Dimensioni del messaggio di risposta HTTP in byte. |
| UserAgent | Agente utente usato dal client. In genere, l'agente utente identifica il tipo di browser. |
| ClientIp | Indirizzo IP del client che ha eseguito la richiesta originale. Se nella richiesta è presente un'intestazione X-Forwarded-For, l'indirizzo IP del client viene invece ricavato dall'intestazione. |
| SocketIp | Indirizzo IP della connessione diretta al bordo Frontdoor di Azure. Se il client ha usato un proxy HTTP o un servizio di bilanciamento del carico per inviare la richiesta, il valore di SocketIp è l'indirizzo IP del proxy o del servizio di bilanciamento del carico. |
| timeTaken | Periodo di tempo trascorso dal momento in cui il bordo Frontdoor di Azure ha ricevuto la richiesta del client al momento in cui Frontdoor di Azure ha inviato l'ultimo byte della risposta al client, in secondi. Questo campo non tiene conto della latenza di rete e del buffer TCP. |
| RequestProtocol | Protocollo specificato dal client nella richiesta. I valori possibili includono: HTTP, HTTPS. |
| SecurityProtocol | Versione del protocollo TLS/SSL usata dalla richiesta o Null se la richiesta non usa la crittografia. I valori possibili includono: SSLv3, TLSv1, TLSv1.1, TLSv1.2. |
| SecurityCipher | Quando il valore per il protocollo di richiesta è HTTPS, questo campo indica la crittografia TLS/SSL negoziata dal client e dal Frontdoor di Azure. |
| Endpoint | Nome di dominio dell'endpoint Frontdoor di Azure, ad esempio contoso-123.z01.azurefd.net. |
| HttpStatusCode | Codice di stato HTTP restituito da Frontdoor di Azure. Se si verifica il timeout della richiesta all'origine, il valore per il campo HttpStatusCode è 0. Se il client ha chiuso la connessione, il valore per il campo HttpStatusCode è 499. |
| Pop | Punto di presenza (PoP) perimetrale di Frontdoor di Azure che ha risposto alla richiesta dell'utente. |
| Stato della cache | Come la richiesta è stata gestita dalla cache di Frontdoor di Azure. I valori possibili sono:
|
| MatchedRulesSetName | Nomi delle regole del motore regole elaborate. |
| RouteName | Nome della route corrispondente alla richiesta. |
| ClientPort | La porta IP del client che ha eseguito la richiesta. |
| Referrer | URL del sito che ha originato la richiesta. |
| TimeToFirstByte | Periodo di tempo, in secondi, dal momento in cui il bordo Frontdoor di Azure ha ricevuto la richiesta al momento dell'invio del primo byte al client, misurato da Frontdoor di Azure. Questa proprietà non misura i dati client. |
| ErrorInfo | Se si è verificato un errore durante l'elaborazione della richiesta, questo campo fornisce informazioni dettagliate sull'errore. I valori possibili sono:
|
| OriginURL | URL completo dell'origine in cui è stata inviata la richiesta. L'URL è costituito dallo schema, dall'intestazione host, dalla porta, dal percorso e dalla stringa di query. Riscrittura URL: se l'URL della richiesta è stato riscritto dal Motore regole, il percorso fa riferimento al percorso riscritto. Cache in POP perimetrale: se la richiesta è stata servita dalla cache di Frontdoor di Azure, l'origine è N/D. Richiesta di grandi dimensioni: se il contenuto richiesto è di grandi dimensioni e sono presenti più richieste in blocchi che tornano all'origine, questo campo corrisponde alla prima richiesta all'origine. Per altre informazioni, vedere Suddivisione in blocchi di oggetti. |
| OriginIP | Indirizzo IP dell'origine che ha servito la richiesta. Cache in POP perimetrale: se la richiesta è stata servita dalla cache di Frontdoor di Azure, l'origine è N/D. Richiesta di grandi dimensioni: se il contenuto richiesto è di grandi dimensioni e sono presenti più richieste in blocchi che tornano all'origine, questo campo corrisponde alla prima richiesta all'origine. Per altre informazioni, vedere Suddivisione in blocchi di oggetti. |
| OriginName | Nome host completo (nome DNS) dell'origine. Cache in POP perimetrale: se la richiesta è stata servita dalla cache di Frontdoor di Azure, l'origine è N/D. Richiesta di grandi dimensioni: se il contenuto richiesto è di grandi dimensioni e sono presenti più richieste in blocchi che tornano all'origine, questo campo corrisponde alla prima richiesta all'origine. Per altre informazioni, vedere Suddivisione in blocchi di oggetti. |
| Risultato | SSLMismatchedSNI è un codice di stato che indica una richiesta riuscita con un avviso di mancata corrispondenza tra SNI e intestazione host. Questo codice di stato comporta il fronting del dominio, una tecnica che viola le condizioni di servizio di Frontdoor di Azure. Dopo il 22 gennaio 2024 le richieste con SSLMismatchedSNI verranno rifiutate. |
| Sni | Questo campo specifica l'indicazione nome server (SNI) inviata durante l'handshake TLS/SSL. Si può usare per identificare il valore SNI esatto se è presente un codice di stato SSLMismatchedSNI. Si può inoltre confrontare con il valore dell'host nel campo requestUri per rilevare e risolvere il problema di mancata corrispondenza. |
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:
| Proprietà | Descrizione |
|---|---|
| HealthProbeId | ID univoco per identificare la richiesta del probe di integrità. |
| Time | Data e ora dell'invio del probe di integrità (in formato UTC). |
| HttpMethod | Metodo HTTP usato dalla richiesta del probe di integrità. I valori includono GET e HEAD, in base alla configurazione del probe di integrità. |
| Risultato | Stato del probe di integrità. Il valore è riuscito oppure una descrizione dell'errore ricevuto dal probe. |
| HttpStatusCode | Il codice di stato HTTP restituito dall'origine. |
| ProbeURL | URL di destinazione completo in cui è stata inviata la richiesta probe. L'URL è costituito dallo schema, dall'intestazione host, dal percorso e dalla stringa di query. |
| OriginName | Nome dell'origine a cui è stato inviato il probe di integrità. Questo campo consente di individuare le origini di interesse se l'origine è configurata per l'uso di un FDQN. |
| POP | PoP perimetrale che ha inviato la richiesta probe. |
| ID di origine | Indirizzo IP dell'origine a cui è stato inviato il probe di integrità. |
| TotalLatency | Tempo da quando il bordo Frontdoor di Azure ha inviato la richiesta del probe di integrità all'origine a quando l'origine ha inviato l'ultima risposta a Frontdoor di Azure. |
| ConnectionLatency | Tempo impiegato per configurare la connessione TCP per inviare la richiesta di probe HTTP all'origine. |
| Latenza DNSResolution | Tempo impiegato per la risoluzione DNS. Questo campo ha un valore solo se l'origine è configurata come FDQN anziché un indirizzo IP. Se l'origine è configurata per l'uso di un indirizzo IP, il valore è N/D. |
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.
Nota
I log attività non includono operazioni di lettura. Potrebbero anche non includere tutte le operazioni eseguite usando il portale di Azure o le API di gestione classiche.
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.
Importante
Frontdoor di Azure (classico) verrà ritirato il 31 marzo 2027. Per evitare interruzioni del servizio, è importante eseguire la migrazione dei profili di Frontdoor di Azure (classico) al livello Standard o Premium di Frontdoor di Azure entro marzo 2027. Per altre informazioni, vedere Ritiro di Frontdoor di Azure (classico).
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:
| Metric | Nome visualizzato per la metrica | Unità | Dimensioni | Descrizione |
|---|---|---|---|---|
| RequestCount | Conteggio richieste | Count | HttpStatus HttpStatusGroup ClientRegion ClientCountry |
Numero di richieste client gestite da Frontdoor. |
| RequestSize | Dimensioni della richiesta | Byte | HttpStatus HttpStatusGroup ClientRegion ClientCountry |
Numero di byte inviati come richieste dai client a Frontdoor. |
| ResponseSize | Dimensioni della risposta | Byte | HttpStatus HttpStatusGroup ClientRegion ClientCountry |
Numero di byte inviati come risposte da Frontdoor ai client. |
| TotalLatency | Latenza totale | Millisecondi | HttpStatus HttpStatusGroup ClientRegion ClientCountry |
Tempo totale dalla richiesta client ricevuta da Frontdoor fino all'ultimo byte di risposta inviato da AFD al client. |
| BackendRequestCount | Conteggio delle richieste del back-end | Count | HttpStatus HttpStatusGroup Backend |
Numero di richieste inviate da Frontdoor ai back-end. |
| BackendRequestLatency | Latenza della richiesta del back-end | Millisecondi | Back-end | Tempo calcolato dal momento dell'invio della richiesta al back-end da parte di Frontdoor al momento della ricezione da parte di Frontdoor dell'ultimo byte della risposta inviata dal back-end. |
| BackendHealthPercentage | Percentuale di integrità del back-end | Percentuale | Backend BackendPool |
Percentuale di probe di integrità con esito positivo da Frontdoor ai back-end. |
| WebApplicationFirewallRequestCount | Conteggio delle richieste web application firewall | Count | PolicyName RuleName Azione |
Numero di richieste client elaborate dalla sicurezza del livello dell'applicazione di Frontdoor. |
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).
Nota
Se una richiesta all'origine raggiunge il timeout il valore di HttpStatusCode è impostato su 0.
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à:
Selezionare l'istanza di Frontdoor.
Selezionare Log attività.
Scegliere un ambito di filtraggio, quindi selezionare Applica.
Nota
Il log attività non include operazioni GET o operazioni eseguite usando il portale di Azure o l'API di gestione originale.
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):
Selezionare il profilo Frontdoor di Azure (versione classica).
Selezionare impostazioni di diagnostica.
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:
| Proprietà | Descrizione |
|---|---|
| BackendHostname | Se la richiesta veniva inoltrata a un back-end questo campo rappresenta il nome host del back-end. Questo campo rimane vuoto se la richiesta viene reindirizzata o inoltrata a una cache a livello di area (quando la memorizzazione nella cache è abilitata per la regola di gestione). |
| CacheStatus | Per le situazioni di memorizzazione nella cache, questo campo definisce il rapporto riscontro nella cache/riga non eseguita del POP |
| ClientIp | Indirizzo IP del client che ha eseguito la richiesta. Se nella richiesta è presente un'intestazione X-Forwarded-For, l'indirizzo IP client viene selezionato da essa. |
| ClientPort | La porta IP del client che ha eseguito la richiesta. |
| HttpMethod | Metodo HTTP usato dalla richiesta. |
| HttpStatusCode | Codice di stato HTTP restituito dal proxy. Se una richiesta all'origine raggiunge il timeout il valore di HttpStatusCode è impostato su 0. |
| HttpStatusDetails | Stato risultante nella richiesta. Il significato di questo valore stringa è disponibile in una tabella di riferimento sullo stato. |
| HttpVersion | Tipo della richiesta o della connessione. |
| POP | Nome breve del bordo di destinazione della richiesta. |
| RequestBytes | Dimensioni del messaggio di richiesta HTTP in byte, inclusi intestazioni e corpo della richiesta. |
| RequestUri | URI della richiesta ricevuta. |
| ResponseBytes | Byte inviati dal server back-end come risposta. |
| RoutingRuleName | Nome della regola di gestione corrispondente alla richiesta. |
| RulesEngineMatchNames | I nomi delle regole corrispondenti alla richiesta. |
| SecurityProtocol | Versione del protocollo TLS/SSL usata dalla richiesta o Null se non è stato usato alcun tipo di crittografia. |
| SentToOriginShield (deprecato) * Vedere le note sugli elementi deprecati nella sezione seguente. |
Se true, la risposta alla richiesta proviene dalla cache dello shield di origine anziché dal POP perimetrale. Lo shield di origine è una cache padre usata per migliorare la percentuale di riscontri nella cache. |
| isReceivedFromClient | Se il valore è true, la richiesta proviene dal client. Se è false, la richiesta è una riga non eseguita sul bordo (POP figlio) e riceve una risposta dallo shield dell'origine (POP padre). |
| TimeTaken | Durata del periodo tra il primo byte della richiesta in Frontdoor e l'ultimo byte della risposta, in secondi. |
| TrackingReference | Stringa di riferimento univoca che identifica una richiesta fornita da Frontdoor, inviata anche come intestazione X-Azure-Ref al client. Obbligatoria per la ricerca di dettagli nei log di accesso per una richiesta specifica. |
| UserAgent | Tipo di browser usato dal client. |
| ErrorInfo | Questo campo contiene il tipo specifico di errore per ulteriori operazioni di risoluzione dei problemi. I possibili valori includono: NoError: indica che non sono stati trovati errori. CertificateError: un errore generico del certificato SSL. CertificateNameCheckFailed: nome host nel certificato SSL non valido o non corrispondente. ClientDisconnected: errore nella richiesta a causa della connessione di rete del client. UnspecifiedClientError: errore generico del client. InvalidRequest: richiesta non valida. Può verificarsi a causa del formato non valido dell'intestazione, del corpo e degli URL. DNSFailure: errore del DNS. DNSNameNotResolved: non è stato possibile risolvere il nome o l'indirizzo del server. OriginConnectionAborted: la connessione con l'origine si è interrotta improvvisamente. OriginConnectionError: errore generico di connessione dell'origine. OriginConnectionRefused: non è stato possibile stabilire la connessione con l'origine. OriginError: errore generico dell'origine. OriginInvalidResponse: l'origine ha restituito una risposta non valida o non riconosciuta. OriginTimeout: periodo di timeout scaduto per la richiesta dell'origine. ResponseHeaderTooBig: l'origine ha restituito un'intestazione della risposta troppo grande. RestrictedIP: la richiesta è stata bloccata a causa dell'indirizzo IP limitato. SSLHandshakeError: impossibile stabilire la connessione con l'origine a causa di un errore in fase di handshake SSL. UnspecifiedError: si è verificato un errore che non rientra nelle categorie di errore della tabella. SSLMismatchedSNI: la richiesta non è valida perché l'intestazione del messaggio HTTP non corrisponde al valore presentato nell'estensione SNI TLS durante la configurazione della connessione SSL/TLS. |
| Risultato | SSLMismatchedSNI è un codice di stato che indica una richiesta riuscita con un avviso di mancata corrispondenza tra SNI e intestazione host. Questo codice di stato comporta il fronting del dominio, una tecnica che viola le condizioni di servizio di Frontdoor di Azure. Dopo il 22 gennaio 2024 le richieste con SSLMismatchedSNI verranno rifiutate. |
| Sni | Questo campo specifica l'indicazione nome server (SNI) inviata durante l'handshake TLS/SSL. Si può usare per identificare il valore SNI esatto se è presente un codice di stato SSLMismatchedSNI. Si può inoltre confrontare con il valore dell'host nel campo requestUri per rilevare e risolvere il problema di mancata corrispondenza. |
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
Nota
Per diverse configurazioni di routing e comportamenti del traffico, alcuni campi come backendHostname, cacheStatus, isReceivedFromClient e il campo POP possono rispondere con valori diversi. La tabella seguente illustra i diversi valori che questi campi avranno per diversi scenari:
| Scenari | Numero di voci di log | POP | BackendHostname | isReceivedFromClient | CacheStatus |
|---|---|---|---|---|---|
| Regola di gestione senza memorizzazione nella cache abilitata | 1 | Codice POP perimetrale | Back-end in cui è stata inoltrata la richiesta | Vero | CONFIG_NOCACHE |
| Regola di gestione con memorizzazione nella cache abilitata. Riscontri nella cache nel POP perimetrale | 1 | Codice POP perimetrale | Vuoto | Vero | HIT |
| Regola di gestione con memorizzazione nella cache abilitata. Mancati riscontri nella cache nel POP perimetrale, ma la cache raggiunge il POP della cache padre | 2 | 1. Codice POP perimetrale 2. Codice POP della cache padre |
1. Nome host POP della cache padre 2. Vuoto |
1. Vero 2. Falso |
1. RIGA NON ESEGUITA 2. HIT |
| Regola di gestione con memorizzazione nella cache abilitata. Le cache non sono disponibili nel POP bordo, ma la cache PARTIAL ha raggiunto il pop della cache padre | 2 | 1. Codice POP perimetrale 2. Codice POP della cache padre |
1. Nome host POP della cache padre 2. Back-end che consente di popolare la cache |
1. Vero 2. Falso |
1. RIGA NON ESEGUITA 2. PARTIAL_HIT |
| Regola di gestione con memorizzazione nella cache abilitata. Cache PARTIAL_HIT nel POP bordo, ma la cache ha raggiunto il pop della cache padre | 2 | 1. Codice POP perimetrale 2. Codice POP della cache padre |
1. Codice POP perimetrale 2. Codice POP della cache padre |
1. Vero 2. Falso |
1. PARTIAL_HIT 2. HIT |
| Regola di gestione con memorizzazione nella cache abilitata. Mancati riscontri nella cache nel POP della cache perimetrale e padre | 2 | 1. Codice POP perimetrale 2. Codice POP della cache padre |
1. Codice POP perimetrale 2. Codice POP della cache padre |
1. Vero 2. Falso |
1. RIGA NON ESEGUITA 2. RIGA NON ESEGUITA |
| Si è verificato un errore durante l'elaborazione della richiesta | N/D |
Nota
Per gli scenari di memorizzazione nella cache, il valore per lo stato della cache sarà partial_hit quando alcuni byte per una richiesta vengono serviti dalla cache shield perimetrale od origine di Frontdoor di Azure mentre alcuni byte vengono serviti dall'origine per oggetti di grandi dimensioni.
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)