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.
Metriche
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 le API di Monitoraggio di Azure, portale di Azure, Azure PowerShell, l'interfaccia della riga di comando di Azure e 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 |
|---|---|---|
| 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 di passaggi byte = (uscita dal bordo - uscita dall'origine)/uscita dal bordo. Scenari esclusi dai calcoli del rapporto riscontri byte:
|
Endpoint |
| Percentuale di integrità origine | Percentuale di probe di integrità riusciti inviati da Frontdoor di Azure alle origini. | Origin, Origin Group |
| 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 |
| Conteggio richieste di origine | Numero di richieste inviate da Frontdoor di Azure alle origini. | Endpoint, Origine, Stato HTTP, Gruppo di stato HTTP |
| Percentuale di 4XX | Percentuale di tutte le richieste client per le quali il codice di stato della risposta è 4XX. | Endpoint, Paese client, Area client |
| Percentuale di 5XX | Percentuale di tutte le richieste client per le quali il codice di stato della risposta è 5XX. | Endpoint, Paese client, Area client |
| 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 |
| Dimensioni della richiesta | Numero di byte inviati nelle richieste dai client a Frontdoor di Azure. | Endpoint, Paese client, area client, stato HTTP, gruppo di stato HTTP |
| Dimensioni della risposta | Numero di byte inviati come risposte da Frontdoor ai client. | Endpoint, paese client, area client, stato HTTP, gruppo di stato HTTP |
| 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 |
| Conteggio delle richieste web application firewall | Numero di richieste elaborate dal web application firewall di Frontdoor di Azure. | Azione, Nome criterio, Nome regola |
Nota
Se si verifica il timeout di una richiesta all'origine, il valore della dimensione Http Status è 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:
- I log di accesso possono essere usati 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.
- I log del probe di integrità possono essere usati 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, ad esempio le modifiche di configurazione al profilo frontdoor di Azure.
I log di accesso e i log 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 | 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 X-Azure-Ref intestazioni . 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 effettuato la richiesta originale. Se è presente un'intestazione X-Forwarded-For nella richiesta, l'indirizzo IP del client viene ricavato dall'intestazione. |
| SocketIp | Indirizzo IP della connessione diretta al perimetro 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 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) 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 | Porta IP del client che ha effettuato la richiesta. |
| Referrer | URL del sito che ha originato la richiesta. |
| TimetoFirstByte | Periodo di tempo, in secondi, dal momento in cui il perimetro frontdoor di Azure ha ricevuto la richiesta al momento dell'invio del primo byte al client, come 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 nel poP perimetrale: se la richiesta è stata servita dalla cache di Frontdoor di Azure, l'origine è N/A. 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 nel poP perimetrale: se la richiesta è stata servita dalla cache di Frontdoor di Azure, l'origine è N/A. 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 nel poP perimetrale: se la richiesta è stata servita dalla cache di Frontdoor di Azure, l'origine è N/A. 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 l'intestazione host. Questo codice di stato implica il fronting del dominio, una tecnica che viola le condizioni di servizio di Frontdoor di Azure. Le richieste con SSLMismatchedSNI verranno rifiutate dopo il 22 gennaio 2024. |
| Sni | Questo campo specifica l'indicazione del nome server (SNI) inviata durante l'handshake TLS/SSL. Può essere usato per identificare il valore SNI esatto se è presente un SSLMismatchedSNI codice di stato. Inoltre, può essere confrontato con il valore host nel requestUri campo 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 o una descrizione dell'errore ricevuto dal probe. |
| HttpStatusCode | 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 | Ora da quando il perimetro 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. |
| Connessione ionLatency | 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/A. |
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/27CAFCA8-B9A4-4264-B399-45D0C9CCA1AB/RESOURCEGROUPS/AFDXPRIVATEPREVIEW/PROVIDERS/MICROSOFT.CDN/PROFILES/AFDXPRIVATEPREVIEW-JESSIE",
"category": "FrontDoorHealthProbeLog",
"operationName": "Microsoft.Cdn/Profiles/FrontDoorHealthProbeLog/Write",
"properties": {
"healthProbeId": "9642AEA07BA64675A0A7AD214ACF746E",
"POP": "MAA",
"httpVerb": "HEAD",
"result": "OriginError",
"httpStatusCode": "400",
"probeURL": "http://afdxprivatepreview.blob.core.windows.net:80/",
"originName": "afdxprivatepreview.blob.core.windows.net",
"originIP": "52.239.224.228:80",
"totalLatencyMilliseconds": "141",
"connectionLatencyMilliseconds": "68",
"DNSLatencyMicroseconds": "1814"
}
}
]
}
Log del web application firewall
Per altre informazioni sui log 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 le API di gestione portale di Azure o 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 (versione classica) verrà ritirato il 31 marzo 2027. Per evitare interruzioni del servizio, è importante eseguire la migrazione dei profili frontdoor di Azure (versione classica) al livello Frontdoor di Azure Standard o Premium entro marzo 2027. Per altre informazioni, vedere Ritiro di Frontdoor di Azure (versione classica).
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 utilizzare dati da una risorsa a scopo di monitoraggio.
Metriche
Le metriche sono una funzionalità per determinate risorse di Azure che consentono 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 | Conteggio | 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 | Conteggio | Back-end HttpStatusGroup HttpStatus |
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 | BackendPooling back-end |
Percentuale di probe di integrità con esito positivo da Frontdoor ai back-end. |
| WebApplicationFirewallRequestCount | Conteggio delle richieste web application firewall | Conteggio | Azione Nomecontetto PolicyName |
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 si verifica il timeout di una richiesta all'origine, 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 filtro e 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 forniscono 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à forniscono informazioni dettagliate sulle operazioni eseguite sulle risorse di Azure. I log di diagnostica forniscono informazioni dettagliate 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).
Scegliere Impostazioni di diagnostica.
Selezionare Attiva diagnostica. Archiviare i log di diagnostica insieme alle metriche a un account di archiviazione, trasmetterli a un hub eventi o inviarli ai log di Monitoraggio di Azure.
Frontdoor attualmente fornisce i log di diagnostica. I log di diagnostica forniscono singole richieste API con ogni voce con lo schema seguente:
| Proprietà | Descrizione |
|---|---|
| BackendHostname | Se la richiesta è stata inoltrata a un back-end, questo campo rappresenta il nome host del back-end. Questo campo è vuoto se la richiesta viene reindirizzata o inoltrata a una cache a livello di area (quando la memorizzazione nella cache viene abilitata per la regola di routing). |
| CacheStatus | Per gli scenari di memorizzazione nella cache, questo campo definisce l'hit/miss della cache nel 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 dallo stesso. |
| ClientPort | Porta IP del client che ha effettuato la richiesta. |
| HttpMethod | Metodo HTTP usato dalla richiesta. |
| HttpStatusCode | Codice di stato HTTP restituito dal proxy. Se si verifica il timeout di una richiesta all'origine, 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 in cui è atterrata la 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 routing corrispondente alla richiesta. |
| RulesEngineMatchNames | 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 sulla deprecazione 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 true, significa che la richiesta proviene dal client. Se false, la richiesta è un mancato perimetro (POP figlio) e viene risposta dallo scudo di origine (POP padre). |
| TimeTaken | Intervallo di tempo dal primo byte della richiesta in Frontdoor all'ultimo byte di 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 valori possibili includono: NoError: indica che non è stato trovato alcun errore. CertificateError: errore generico del certificato SSL. CertificateNameCheckFailed: il nome host nel certificato SSL non è valido o non corrisponde. ClientDisconnected: errore di richiesta a causa della connessione di rete client. UnspecifiedClientError: errore client generico. InvalidRequest: richiesta non valida. Può verificarsi a causa di intestazioni, corpo e URL in formato non valido. DNSFailure: errore DNS. DNSNameNotResolved: impossibile risolvere il nome o l'indirizzo del server. Origin Connessione ionAborted: la connessione con l'origine è stata interrotta improvvisamente. Origin Connessione ionError: errore di connessione di origine generica. Origin Connessione ionRefused: la connessione con l'origine non è stata in grado di stabilire. OriginError: errore di origine generico. OriginInvalidResponse: l'origine ha restituito una risposta non valida o non riconosciuta. OriginTimeout: periodo di timeout per la richiesta di origine scaduto. ResponseHeaderTooBig: l'origine ha restituito un'intestazione di risposta troppo grande. RestrictedIP: la richiesta è stata bloccata a causa di un indirizzo IP limitato. SSLHandshakeError: impossibile stabilire la connessione con l'origine a causa di un errore di scuotemento della mano SSL. UnspecifiedError: si è verificato un errore che non rientra in nessuno degli errori nella 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 l'intestazione host. Questo codice di stato implica il fronting del dominio, una tecnica che viola le condizioni di servizio di Frontdoor di Azure. Le richieste con SSLMismatchedSNI verranno rifiutate dopo il 22 gennaio 2024. |
| Sni | Questo campo specifica l'indicazione del nome server (SNI) inviata durante l'handshake TLS/SSL. Può essere usato per identificare il valore SNI esatto se è presente un SSLMismatchedSNI codice di stato. Inoltre, può essere confrontato con il valore host nel requestUri campo per rilevare e risolvere il problema di mancata corrispondenza. |
Deprecazione dello scudo di origine
La proprietà del log non elaborato isSentToOriginShield è deprecata e sostituita da un nuovo campo isReceivedFromClient. Usare il nuovo campo se si usa già il campo deprecato.
I log non elaborati includono i log generati sia dal bordo rete CDN (POP figlio) che dallo scudo di origine. Lo scudo di origine si riferisce a nodi padre che si trovano strategicamente in tutto il mondo. Questi nodi comunicano con i server di origine e riducono il carico del traffico sull'origine.
Per ogni richiesta inviata a uno scudo di origine, sono presenti due voci di log:
- Uno per i nodi perimetrali
- Uno per lo scudo di origine.
Per distinguere le risposte o i nodi perimetrali rispetto allo scudo di origine, è possibile usare il campo isReceivedFromClient per ottenere i dati corretti.
Se il valore è false, significa che la richiesta viene risposta dallo scudo di origine ai nodi perimetrali. Questo approccio è efficace per confrontare i log non elaborati con i dati di fatturazione. Gli addebiti non vengono addebitati per l'uscita dallo scudo di origine ai nodi perimetrali. I costi vengono addebitati per l'uscita dai nodi perimetrali ai client.
Esempio di query Kusto per escludere i log generati sullo scudo di 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 routing senza memorizzazione nella cache abilitata | 1 | Codice POP edge | Back-end in cui è stata inoltrata la richiesta | Vero | CONFIG_NOCACHE |
| Regola di routing con memorizzazione nella cache abilitata. Riscontri nella cache nel POP perimetrale | 1 | Codice POP edge | Vuoto | Vero | HIT |
| Regola di routing 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 edge 2. Codice POP della cache padre |
1. Nome host POP della cache padre 2. Vuoto |
1. Vero 2. Falso |
1. MISS 2. HIT |
| Regola di routing con memorizzazione nella cache abilitata. Le cache non sono disponibili nel POP perimetrale, ma la cache PARTIAL ha raggiunto il pop della cache padre | 2 | 1. Codice POP edge 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. MISS 2. PARTIAL_HIT |
| Regola di routing con memorizzazione nella cache abilitata. Cache PARTIAL_HIT nel POP perimetrale, ma la cache ha raggiunto il pop della cache padre | 2 | 1. Codice POP edge 2. Codice POP della cache padre |
1. Codice POP edge 2. Codice POP della cache padre |
1. Vero 2. Falso |
1. PARTIAL_HIT 2. HIT |
| Regola di routing con memorizzazione nella cache abilitata. Mancati riscontri nella cache nel POP della cache perimetrale e padre | 2 | 1. Codice POP edge 2. Codice POP della cache padre |
1. Codice POP edge 2. Codice POP della cache padre |
1. Vero 2. Falso |
1. MISS 2. SIGNORINA |
| Errore durante l'elaborazione della richiesta | N/D |
Nota
Per gli scenari di memorizzazione nella cache, il valore per Lo stato della cache verrà partial_hit quando alcuni byte per una richiesta vengono serviti dalla cache di protezione dell'origine o dal bordo di Frontdoor di Azure mentre alcuni byte vengono serviti dall'origine per oggetti di grandi dimensioni.
Frontdoor di Azure usa una tecnica denominata suddivisione in blocchi di oggetti. Quando viene richiesto un file di grandi dimensioni, Frontdoor di Azure recupera parti più piccole 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.
Dopo che il blocco arriva al perimetro frontdoor di Azure, viene memorizzato nella cache e immediatamente servito all'utente. Frontdoor di Azure esegue quindi il prelettura del blocco successivo in parallelo. Questo prelettura garantisce che il contenuto rimanga un blocco davanti all'utente, riducendo la latenza. Questo processo continua fino a quando l'intero file viene scaricato (se richiesto), tutti gli intervalli di byte sono disponibili (se richiesto) o il client chiude la connessione. Per altre informazioni sulla richiesta di intervalli di byte, vedere RFC 7233. Frontdoor di Azure memorizza nella cache tutti i blocchi ricevuti. L'intero file non deve essere memorizzato 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 in Frontdoor di Azure, il prelettura viene usato per richiedere 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 di Azure (versione classica)
- Informazioni sul funzionamento di Frontdoor di Azure (versione classica)