Monitorare Frontdoor di Azure
Monitoraggio di Azure raccoglie e aggrega metriche e log dal sistema per monitorare la disponibilità, le prestazioni e la resilienza e notificare eventuali problemi che interessano il sistema. È possibile usare il portale di Azure, PowerShell, l'interfaccia della riga di comando di Azure, l'API REST o le librerie client per configurare e visualizzare i dati di monitoraggio.
Sono disponibili metriche e log diversi per diversi tipi di risorse. Questo articolo descrive i tipi di dati di monitoraggio che è possibile raccogliere per questo servizio e i modi per analizzare tali dati.
I report forniscono informazioni dettagliate sul flusso del traffico attraverso Frontdoor di Azure, il Web Application Firewall (WAF) e l'applicazione.
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).
Raccogliere dati con Monitoraggio di Azure
Questa tabella descrive come raccogliere i dati per monitorare il servizio e le operazioni che è possibile eseguire con i dati dopo la raccolta:
| Dati da raccogliere | Descrizione | Come raccogliere e instradare i dati | Dove visualizzare i dati | Dati supportati |
|---|---|---|---|---|
| Dati delle metriche | Le metriche sono valori numerici che descrivono determinati aspetti di un sistema in un particolare momento. Le metriche possono essere aggregate usando algoritmi, rispetto ad altre metriche e analizzate per individuare le tendenze nel tempo. | - Raccolto automaticamente a intervalli regolari. - È possibile instradare alcune metriche della piattaforma a un'area di lavoro Log Analytics per eseguire query con altri dati. Controllare l'impostazione di esportazione DS per ogni metrica per verificare se è possibile usare un'impostazione di diagnostica per instradare i dati delle metriche. |
Esplora metriche | Metriche di Frontdoor di Azure supportate da Monitoraggio di Azure |
| Dati del log delle risorse | I log vengono registrati eventi di sistema con un timestamp. I log possono contenere tipi diversi di dati e possono essere strutturati o in formato libero. È possibile instradare i dati del log delle risorse alle aree di lavoro Log Analytics per l'esecuzione di query e l'analisi. | Creare un'impostazione di diagnostica per raccogliere e instradare i dati del log delle risorse. | Log Analytics | Dati di log delle risorse di Frontdoor di Azure supportati da Monitoraggio di Azure |
| Dati del log attività | Il log attività di Monitoraggio di Azure fornisce informazioni dettagliate sugli eventi a livello di sottoscrizione. Il log attività include informazioni relative, ad esempio, alla modifica di una risorsa o all'avvio di una macchina virtuale. | - Raccolto automaticamente. - Creare un'impostazione di diagnostica per un'area di lavoro Log Analytics senza costi aggiuntivi. |
Log attività |
Per l'elenco di tutti i dati supportati da Monitoraggio di Azure, vedere:
Monitoraggio predefinito per Frontdoor di Azure
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). Per le connessioni WebSocket, l'ora rappresenta la chiusura della connessione. |
| 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. Per le connessioni WebSocket, questo valore è il numero totale di byte inviati dal client al server tramite la connessione. |
| ResponseBytes | Dimensioni del messaggio di risposta HTTP in byte. Per le connessioni WebSocket, questo valore è il numero totale di byte inviati dal server al client tramite la connessione. |
| 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 | Durata da quando il perimetro frontdoor di Azure ha ricevuto la richiesta del client a quando l'ultimo byte della risposta è stato inviato al client, misurato in secondi. Questa metrica esclude la latenza di rete e il buffer TCP. Per le connessioni WebSocket, rappresenta la durata della connessione dall'istituzione alla chiusura. |
| RequestProtocol | Protocollo specificato dal client nella richiesta. I valori possibili includono: HTTP, HTTPS. Per WebSocket, i protocolli sono WS, WSS. Solo le richieste che vengono aggiornate correttamente a WebSocket hanno WS/WSS. |
| 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 | Modalità di gestione della richiesta da parte della 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 il motore regole riscrive l'URL della richiesta, 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 notare 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 nome di dominio completo. |
| 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 FQDN 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.
Per frontdoor di Azure classico, il monitoraggio predefinito include i log di diagnostica.
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 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).
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 valori possibili includono: NoError: indica che non è stato trovato alcun errore. CertificateError: un 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 generico del client. InvalidRequest: richiesta non valida. Può verificarsi a causa del formato non valido dell'intestazione, del corpo e degli URL. DNSFailure: errore DNS. DNSNameNotResolved: non è stato possibile risolvere il nome o l'indirizzo del server. OriginConnectionAborted: la connessione con l'origine è stata interrotta improvvisamente. OriginConnectionError: errore generico di connessione dell'origine. OriginConnectionRefused: la connessione con l'origine non è stata in grado di stabilire. OriginError: errore generico dell'origine. OriginInvalidResponse: l'origine ha restituito una risposta non valida o non riconosciuta. OriginTimeout: periodo di timeout per la richiesta di origine scaduta. 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 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 scudo di 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 potrebbero rispondere con valori diversi. La tabella seguente illustra i diversi valori di questi campi 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 è un PARTIAL_HIT quando alcuni byte per una richiesta vengono serviti dalla cache perimetrale o di 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.
Usare gli strumenti di Monitoraggio di Azure per analizzare i dati
Questi strumenti di Monitoraggio di Azure sono disponibili nella portale di Azure per analizzare i dati di monitoraggio:
Alcuni servizi di Azure hanno un dashboard di monitoraggio predefinito nella portale di Azure. Questi dashboard sono denominati informazioni dettagliate ed è possibile trovarli nella sezione Insights di Monitoraggio di Azure nella portale di Azure.
Esplora metriche consente di visualizzare e analizzare le metriche per le risorse di Azure. Per altre informazioni, vedere Analizzare le metriche con Esplora metriche di Monitoraggio di Azure.
Log Analytics consente di eseguire query e analizzare i dati di log usando il linguaggio di query Kusto (KQL). Per altre informazioni, vedere Introduzione alle query dei log del Monitoraggio di Azure.
Il portale di Azure dispone di un'interfaccia utente per la visualizzazione e le ricerche di base del log attività. Per eseguire analisi più approfondite, indirizzare i dati ai log di Monitoraggio di Azure ed eseguire query più complesse in Log Analytics.
Application Insights monitora la disponibilità, le prestazioni e l'utilizzo delle applicazioni Web, in modo da poter identificare e diagnosticare gli errori senza attendere che un utente li segnala.
Application Insights include punti di connessione a vari strumenti di sviluppo e si integra con Visual Studio per supportare i processi DevOps. Per altre informazioni, vedere Monitoraggio delle applicazioni per il Servizio app.
Gli strumenti che consentono una visualizzazione più complessa includono:
- I dashboard che consentono di combinare tipi di dati diversi in un singolo riquadro nel portale di Azure.
- Cartelle di lavoro, report personalizzabili che è possibile creare nel portale di Azure. Le cartelle di lavoro possono includere testo, metriche e query di log.
- Grafana è una piattaforma aperta, ideale per i dashboard operativi. È possibile usare Grafana per creare dashboard che includano dati da più origini diverse dal Monitoraggio di Azure.
- Power BI, un servizio di analisi aziendale che fornisce visualizzazioni interattive per un'ampia varietà di origini dati. È possibile configurare per Power BI per importare automaticamente i dati di log da Monitoraggio di Azure per sfruttare i vantaggi di queste visualizzazioni.
Esportare i dati di Monitoraggio di Azure
È possibile esportare i dati da Monitoraggio di Azure in altri strumenti usando:
Metriche: usare l'API REST per le metriche per estrarre i dati delle metriche dal database delle metriche del Monitoraggio di Azure. Per altre informazioni, vedere Informazioni di riferimento sull'API REST del Monitoraggio di Azure.
Log: usare l'API REST o le librerie client associate.
Esportazione dei dati dell'area di lavoro Log Analytics.
Per iniziare a usare l'API REST di Monitoraggio di Azure, vedere Procedura dettagliata per l'API REST di monitoraggio di Azure.
Usare query Kusto per analizzare i dati di log
È possibile analizzare i dati dei log di Monitoraggio di Azure usando il linguaggio di query Kusto (KQL). Per altre informazioni, vedere Log di query in Monitoraggio di Azure.
Usare gli avvisi di Monitoraggio di Azure per notificare i problemi
Gli avvisi di Monitoraggio di Azure consentono di identificare e risolvere i problemi nel sistema e inviare notifiche proattive quando vengono rilevate condizioni specifiche nei dati di monitoraggio prima che i clienti li notino. È possibile creare avvisi su qualsiasi metrica o fonte di dati di log nella piattaforma di dati di Monitoraggio di Azure. Esistono diversi tipi di avvisi di Monitoraggio di Azure a seconda dei servizi monitorati e dei dati di monitoraggio raccolti. Vedere Scelta del tipo di regola di avviso corretto.
Per esempi di avvisi comuni per le risorse di Azure, vedere Query di avviso di log di esempio.
Implementazione di avvisi su larga scala
Per alcuni servizi, è possibile effettuare un monitoraggio su larga scala applicando la stessa regola di avviso delle metriche a più risorse dello stesso tipo presenti nella stessa area di Azure. Gli avvisi di base di Monitoraggio di Azure (AMBA) offrono un metodo semi-automatizzato per implementare importanti avvisi, dashboard e linee guida per le metriche della piattaforma su larga scala.
Ottenere raccomandazioni personalizzate con Azure Advisor
Per alcuni servizi, se si verificano condizioni critiche o modifiche imminenti durante le operazioni sulle risorse, viene visualizzato un avviso nella pagina Panoramica del servizio nel portale. È possibile trovare altre informazioni e correzioni consigliate per l'avviso in Consigli di Advisor in Monitoraggio nel menu a sinistra. Durante il normale funzionamento non viene visualizzato nessun consiglio di Advisor.
Per altre informazioni su Azure Advisor, vedere Informazioni generali su Azure Advisor.