Log di diagnostica per gateway applicazione
gateway applicazione log forniscono informazioni dettagliate sugli eventi correlati a una risorsa e alle relative operazioni. Questi log sono disponibili per eventi come Access, Activity, Firewall e Performance (solo per V1). Le informazioni granulari nei log sono utili per la risoluzione di un problema o la creazione di un dashboard di analisi usando questi dati non elaborati.
I log sono disponibili per tutte le risorse di gateway applicazione. Tuttavia, per utilizzarli, è necessario abilitare la raccolta in una posizione di archiviazione di propria scelta. L'accesso app Azure lication Gateway è abilitato dal servizio Monitoraggio di Azure. È consigliabile usare l'area di lavoro Log Analytics perché è possibile usare facilmente le query predefinite e impostare avvisi in base a condizioni di log specifiche.
Tipi di log di diagnostica
In Azure è possibile usare diversi tipi di log per gestire e risolvere i problemi dei gateway applicazione. Altre informazioni su questi tipi sono disponibili di seguito:
- Log attività: è possibile usare i log attività di Azure, chiamati in precedenza log operativi e log di controllo, per visualizzare tutte le operazioni inviate alla sottoscrizione di Azure e il relativo stato. Le voci dei log attività vengono raccolte per impostazione predefinita e possono essere visualizzate nel portale di Azure.
- Log di accesso: è possibile usare questo log per visualizzare gateway applicazione modelli di accesso e analizzare informazioni importanti. Sono inclusi l'IP del chiamante, l'URL richiesto, la latenza di risposta, il codice restituito e i byte in ingresso e in uscita. Un log di accesso viene raccolto ogni 60 secondi. Il log contiene un record per ogni istanza del gateway applicazione. L'istanza del gateway applicazione può essere identificata dalla proprietà instanceId.
- Log delle prestazioni: è possibile usare questo log per visualizzare le prestazioni delle istanze del gateway applicazione. Questo log acquisisce informazioni sulle prestazioni per ogni istanza, incluse le richieste totali gestite, la velocità effettiva in byte, le richieste totali gestite, il numero di richieste non riuscite e il numero di istanze back-end integre e non integre. Il log delle prestazioni viene raccolto ogni 60 secondi. Il log delle prestazioni è disponibile solo per lo SKU v1. Per lo SKU v2, usare Metriche per i dati sulle prestazioni.
- Log del firewall: è possibile usare questo log per visualizzare le richieste registrate tramite la modalità di rilevamento o prevenzione di un gateway applicazione configurato con il web application firewall. I log del firewall vengono raccolti ogni 60 secondi.
Nota
I log sono disponibili solo per le risorse distribuite nel modello di distribuzione di Azure Resource Manager. Non è possibile usare i log per le risorse nel modello di distribuzione classica. Per altre informazioni sui due modelli, vedere le informazioni sulla distribuzione di Resource Manager e la distribuzione classica.
Archiviazione località
Sono disponibili le opzioni seguenti per archiviare i log nella posizione preferita.
Area di lavoro Log Analytics: questa opzione consente di usare facilmente query, visualizzazioni e avvisi predefiniti in base a condizioni di log specifiche. Le tabelle usate dai log delle risorse nell'area di lavoro Log Analytics dipendono dal tipo di raccolta usato dalla risorsa:
Diagnostica di Azure: i dati sono scritti nella tabella Diagnostica di Azure. Diagnostica di Azure tabella viene condivisa tra più tipi di risorsa, ognuno dei quali aggiunge i propri campi personalizzati. Quando il numero di campi personalizzati inseriti in Diagnostica di Azure tabella supera 500, i nuovi campi non vengono aggiunti come primo livello ma aggiunti al campo "AdditionalFields" come coppie chiave dinamica.
Specifica della risorsa(scelta consigliata): i dati sono scritti in tabelle dedicate per ogni categoria della risorsa. In modalità specifica della risorsa, a ogni categoria di log selezionata nell'impostazione di diagnostica viene assegnata la propria tabella all'interno dell'area di lavoro scelta. Questo offre diversi vantaggi, tra cui:
- Semplificare la manipolazione dei dati nelle query di log
- Miglioramento dell'individuabilità degli schemi e delle relative strutture
- Prestazioni migliorate in termini di latenza di inserimento e tempi di query
- Possibilità di assegnare diritti di controllo degli accessi in base al ruolo di Azure a tabelle specifiche
Per gateway applicazione, la modalità specifica della risorsa crea tre tabelle:
Nota
L'opzione specifica della risorsa è attualmente disponibile in tutte le aree pubbliche.
Gli utenti esistenti possono continuare a usare Diagnostica di Azure oppure possono scegliere tabelle dedicate passando all'interruttore in Impostazioni di diagnostica su Specifica risorsa o su Dedicato nella destinazione API. La modalità doppia non è possibile. I dati in tutti i log possono essere trasmessi a Diagnostica di Azure o a tabelle dedicate. Tuttavia, è possibile avere più impostazioni di diagnostica in cui un flusso di dati è di diagnostica di Azure e un altro usa una risorsa specifica contemporaneamente.
Selezione della tabella di destinazione in Log Analytics: tutti i servizi di Azure usano infine le tabelle specifiche delle risorse. Come parte di questa transizione, è possibile selezionare la tabella specifica della diagnostica o della risorsa di Azure nell'impostazione di diagnostica usando un interruttore. L'interruttore è impostato su Risorsa specifica per impostazione predefinita e in questa modalità i log per le nuove categorie selezionate vengono inviati a tabelle dedicate in Log Analytics, mentre i flussi esistenti rimangono invariati. Vedi l'esempio seguente.
Trasformazioni dell'area di lavoro: il consenso esplicito per l'opzione Specifica risorsa consente di filtrare e modificare i dati prima di essere inseriti con le trasformazioni dell'area di lavoro. In questo modo viene fornito un controllo granulare, che consente di concentrarsi sulle informazioni più rilevanti dai log, riducendo i costi dei dati e migliorando la sicurezza. Per istruzioni dettagliate sulla configurazione delle trasformazioni dell'area di lavoro, vedere:Esercitazione: Aggiungere una trasformazione dell'area di lavoro ai log di Monitoraggio di Azure usando il portale di Azure.
Esempi di ottimizzazione dei log di accesso tramite trasformazioni dell'area di lavoro
Esempio 1: Proiezione selettiva di colonne: si supponga di disporre di log di accesso al gateway applicazione con 20 colonne, ma si è interessati ad analizzare i dati solo da 6 colonne specifiche. Usando la trasformazione dell'area di lavoro, è possibile proiettare queste 6 colonne nell'area di lavoro, escludendo in modo efficace le altre 14 colonne. Anche se i dati originali di tali colonne escluse non verranno archiviati, i segnaposto vuoti per tali colonne verranno comunque visualizzati nel pannello Log. Questo approccio ottimizza l'archiviazione e garantisce che vengano conservati solo i dati rilevanti per l'analisi.
Nota
Nel pannello Log selezionare l'opzione Prova nuovo Log Analytics offre un maggiore controllo sulle colonne visualizzate nell'interfaccia utente.
Esempio 2: Concentrarsi su codici di stato specifici: quando si analizzano i log di accesso, anziché elaborare tutte le voci di log, è possibile scrivere una query per recuperare solo le righe con codici di stato HTTP specifici (ad esempio 4xx e 5xx). Poiché la maggior parte delle richieste rientra idealmente nelle categorie 2xx e 3xx (che rappresentano risposte riuscite), concentrandosi sui codici di stato problematici restringe il set di dati. Questo approccio mirato consente di estrarre le informazioni più rilevanti e gestibili, rendendole sia vantaggiose che convenienti.
Strategia di transizione consigliata per passare dalla diagnostica di Azure alla tabella specifica della risorsa:
- Valutare la conservazione dei dati corrente: determinare la durata per cui i dati vengono attualmente conservati nella tabella diagnostica di Azure( ad esempio: si supponga che la tabella di diagnostica mantenga i dati per 15 giorni).
- Stabilire una conservazione specifica della risorsa: implementare una nuova impostazione di diagnostica con una tabella specifica della risorsa.
- Raccolta dati parallela: per un periodo temporaneo, raccogliere i dati contemporaneamente sia nelle impostazioni Diagnostica di Azure che nelle impostazioni specifiche della risorsa.
- Verificare l'accuratezza dei dati: verificare che la raccolta dati sia accurata e coerente in entrambe le impostazioni.
- Rimuovere l'impostazione diagnostica di Azure: rimuovere l'impostazione Diagnostica di Azure per impedire la raccolta di dati duplicati.
Altre posizioni di archiviazione:
- Archiviazione di Azure account: gli account Archiviazione vengono usati meglio per i log quando i log vengono archiviati per una durata più lunga ed esaminati quando necessario.
- Hub eventi di Azure: hub eventi è un'ottima opzione per l'integrazione con altri strumenti di gestione degli eventi e informazioni di sicurezza (SIEM) per ricevere avvisi sulle risorse.
- Integrazioni dei partner di Monitoraggio di Azure.
Altre informazioni sulle destinazioni delle impostazioni di diagnostica di Monitoraggio di Azure.
Abilitare la registrazione tramite PowerShell
Registrazione attività viene abilitata automaticamente per tutte le risorse di Resource Manager. È necessario abilitare la registrazione degli accessi e delle prestazioni per iniziare a raccogliere i dati disponibili tramite tali log. Per abilitare la registrazione, seguire questa procedura:
Prendere nota dell'ID risorsa dell'account di archiviazione in cui vengono archiviati i dati dei log. Il valore ha il formato seguente: /subscriptions/<subscriptionId>/resourceGroups/<nome gruppo di risorse>/providers/Microsoft.Storage/storageAccounts/<nome account archiviazione>. È possibile usare qualsiasi account di archiviazione della sottoscrizione. Per trovare queste informazioni è possibile usare il portale di Azure.
Prendere nota dell'ID risorsa del gateway applicazione per cui è abilitata la registrazione. Il valore ha il formato seguente: /subscriptions/<subscriptionId>/resourceGroups/<nome gruppo di risorse>/providers/Microsoft.Network/applicationGateways/<nome gateway applicazione>. Per trovare queste informazioni è possibile usare il portale.
Abilitare la registrazione diagnostica usando il cmdlet di PowerShell seguente:
Set-AzDiagnosticSetting -ResourceId /subscriptions/<subscriptionId>/resourceGroups/<resource group name>/providers/Microsoft.Network/applicationGateways/<application gateway name> -StorageAccountId /subscriptions/<subscriptionId>/resourceGroups/<resource group name>/providers/Microsoft.Storage/storageAccounts/<storage account name> -Enabled $true
Suggerimento
I log attività non richiedono un account di archiviazione separato. Per l'uso del servizio di archiviazione per la registrazione degli accessi e delle prestazioni è previsto un addebito.
Abilitare la registrazione tramite il portale di Azure
Nella portale di Azure trovare la risorsa e selezionare Impostazioni di diagnostica.
Per il gateway applicazione sono disponibili tre log:
- Log di accesso
- Log delle prestazioni
- Log del firewall
Per iniziare a raccogliere dati, selezionare Attiva diagnostica.
La pagina Impostazioni di diagnostica include le impostazioni per i log di diagnostica. In questo esempio viene usato Log Analytics per archiviare i log. Per salvare i log di diagnostica è possibile anche usare l'hub eventi e un account di archiviazione.
Digitare un nome per le impostazioni, confermare le impostazioni e selezionare Salva.
Log attività
Azure genera il log attività per impostazione predefinita. I log vengono conservati per 90 giorni nell'archivio dei log eventi di Azure. Per altre informazioni sui log, leggere l'articolo Visualizzare eventi e log attività.
Log di accesso
Il log di accesso viene generato solo se è stato abilitato in ogni istanza del gateway applicazione, come descritto nei passaggi precedenti. I dati vengono archiviati nell'account di archiviazione specificato quando è stata abilitata la registrazione. Ogni accesso di gateway applicazione viene registrato in formato JSON, come illustrato di seguito.
Per sku di gateway applicazione e WAF v2
Nota
Per informazioni correlate al proxy TLS/TCP, vedere informazioni di riferimento sui dati.
| Valore | Descrizione |
|---|---|
| instanceId | Istanza del gateway applicazione che ha gestito la richiesta. |
| clientIP | IP del client immediato di gateway applicazione. Se un altro proxy esegue il front-end del gateway applicazione, verrà visualizzato l'indirizzo IP del proxy di fronting. |
| httpMethod | Metodo HTTP usato dalla richiesta. |
| requestUri | URI della richiesta ricevuta. |
| UserAgent | Agente utente dell'intestazione della richiesta HTTP. |
| httpStatus | Codice di stato HTTP restituito al client dal gateway applicazione. |
| httpVersion | Versione HTTP della richiesta. |
| receivedBytes | Dimensione del pacchetto ricevuto, espressa in byte. |
| sentBytes | Dimensione del pacchetto inviato, espressa in byte. |
| clientResponseTime | Differenza di tempo (in secondi) tra il primo byte e l'ultimo gateway applicazione di byte inviato al client. Utile per valutare il tempo di elaborazione di gateway applicazione per le risposte o i client lenti. |
| timeTaken | Intervallo di tempo (in secondi) necessario per il primo byte di una richiesta client da elaborare e il relativo ultimo byte inviato nella risposta al client. È importante notare che il campo Tempo impiegato include in genere il tempo della trasmissione in rete dei pacchetti di richiesta e risposta. |
| WAFEvaluationTime | Intervallo di tempo (in secondi) necessario per l'elaborazione della richiesta da parte del WAF. |
| WAFMode | Il valore può essere Rilevamento o Prevenzione |
| transactionId | Identificatore univoco per correlare la richiesta ricevuta dal client |
| sslEnabled | Indica se la comunicazione con i pool back-end ha usato TLS. I valori validi sono on e off. |
| sslCipher | Suite di crittografia usata per la comunicazione TLS (se TLS è abilitato). |
| sslProtocol | Protocollo SSL/TLS usato (se TLS è abilitato). |
| serverRouted | Il server back-end a cui il gateway applicazione instrada la richiesta. |
| serverStatus | Codice di stato HTTP del server back-end. |
| serverResponseLatency | Latenza della risposta (in secondi) dal server back-end. |
| host | Indirizzo elencato nell'intestazione host della richiesta. Se riscritto usando la riscrittura dell'intestazione, questo campo contiene il nome host aggiornato |
| originalRequestUriWithArgs | Questo campo contiene l'URL della richiesta originale |
| requestUri | Questo campo contiene l'URL dopo l'operazione di riscrittura in gateway applicazione |
| upstreamSourcePort | Porta di origine usata da gateway applicazione all'avvio di una connessione alla destinazione back-end |
| originalHost | Questo campo contiene il nome host della richiesta originale |
| error_info | Motivo dell'errore 4xx e 5xx. Visualizza un codice di errore per una richiesta non riuscita. Altri dettagli sono disponibili in Informazioni sul codice di errore. |
| contentType | Tipo di contenuto o dati elaborati o recapitati dal gateway applicazione |
{
"timeStamp": "2021-10-14T22:17:11+00:00",
"resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/{applicationGatewayName}",
"listenerName": "HTTP-Listener",
"ruleName": "Storage-Static-Rule",
"backendPoolName": "StaticStorageAccount",
"backendSettingName": "StorageStatic-HTTPS-Setting",
"operationName": "ApplicationGatewayAccess",
"category": "ApplicationGatewayAccessLog",
"properties": {
"instanceId": "appgw_2",
"clientIP": "185.42.129.24",
"clientPort": 45057,
"httpMethod": "GET",
"originalRequestUriWithArgs": "\/",
"requestUri": "\/",
"requestQuery": "",
"userAgent": "Mozilla\/5.0 (Windows NT 6.1; WOW64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/52.0.2743.116 Safari\/537.36",
"httpStatus": 200,
"httpVersion": "HTTP\/1.1",
"receivedBytes": 184,
"sentBytes": 466,
"clientResponseTime": 0,
"timeTaken": 0.034,
"WAFEvaluationTime": "0.000",
"WAFMode": "Detection",
"transactionId": "592d1649f75a8d480a3c4dc6a975309d",
"sslEnabled": "on",
"sslCipher": "ECDHE-RSA-AES256-GCM-SHA384",
"sslProtocol": "TLSv1.2",
"sslClientVerify": "NONE",
"sslClientCertificateFingerprint": "",
"sslClientCertificateIssuerName": "",
"serverRouted": "52.239.221.65:443",
"serverStatus": "200",
"serverResponseLatency": "0.028",
"upstreamSourcePort": "21564",
"originalHost": "20.110.30.194",
"host": "20.110.30.194",
"error_info":"ERRORINFO_NO_ERROR",
"contentType":"application/json"
}
}
Nota
I log di accesso con il valore clientIP 127.0.0.1 provengono da un processo di sicurezza interno in esecuzione nelle istanze del gateway applicazione. È possibile ignorare in modo sicuro queste voci di log.
Per gateway applicazione SKU Standard e WAF (v1)
| Valore | Descrizione |
|---|---|
| instanceId | Istanza del gateway applicazione che ha gestito la richiesta. |
| clientIP | IP di origine della richiesta. |
| clientPort | Porta di origine della richiesta. |
| httpMethod | Metodo HTTP usato dalla richiesta. |
| requestUri | URI della richiesta ricevuta. |
| RequestQuery | Server-Routed: istanza del pool back-end che è stata inviata la richiesta. X-AzureApplicationGateway-LOG-ID: ID di correlazione usato per la richiesta. Può essere usato per risolvere i problemi di traffico nei server back-end. SERVER-STATUS: codice di risposta HTTP ricevuto dal gateway applicazione dal back-end. |
| UserAgent | Agente utente dell'intestazione della richiesta HTTP. |
| httpStatus | Codice di stato HTTP restituito al client dal gateway applicazione. |
| httpVersion | Versione HTTP della richiesta. |
| receivedBytes | Dimensione del pacchetto ricevuto, espressa in byte. |
| sentBytes | Dimensione del pacchetto inviato, espressa in byte. |
| timeTaken | Periodo di tempo in millisecondi impiegato per l'elaborazione di una richiesta e l'invio della risposta. Questo valore corrisponde all'intervallo di tempo intercorso dal momento in cui il gateway applicazione riceve il primo byte di una richiesta HTTP al termine dell'operazione di invio della risposta. È importante notare che il campo Tempo impiegato include in genere il tempo della trasmissione in rete dei pacchetti di richiesta e risposta. |
| sslEnabled | Indica se la comunicazione con i pool back-end ha usato TLS/SSL. I valori validi sono on e off. |
| host | Nome host per il quale la richiesta è stata inviata al server back-end. Se viene eseguito l'override del nome host back-end, questo nome riflette tale nome. |
| originalHost | Nome host per il quale la richiesta è stata ricevuta dal gateway applicazione dal client. |
{
"resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/PEERINGTEST/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/{applicationGatewayName}",
"operationName": "ApplicationGatewayAccess",
"time": "2017-04-26T19:27:38Z",
"category": "ApplicationGatewayAccessLog",
"properties": {
"instanceId": "ApplicationGatewayRole_IN_0",
"clientIP": "191.96.249.97",
"clientPort": 46886,
"httpMethod": "GET",
"requestUri": "/phpmyadmin/scripts/setup.php",
"requestQuery": "X-AzureApplicationGateway-CACHE-HIT=0&SERVER-ROUTED=10.4.0.4&X-AzureApplicationGateway-LOG-ID=874f1f0f-6807-41c9-b7bc-f3cfa74aa0b1&SERVER-STATUS=404",
"userAgent": "-",
"httpStatus": 404,
"httpVersion": "HTTP/1.0",
"receivedBytes": 65,
"sentBytes": 553,
"timeTaken": 205,
"sslEnabled": "off",
"host": "www.contoso.com",
"originalHost": "www.contoso.com"
}
}
Informazioni sul codice di errore
Se il gateway applicazione non riesce a completare la richiesta, archivia uno dei codici motivo seguenti nel campo error_info del log di accesso.
| Errori 4XX | I codici di errore 4xx indicano che si è verificato un problema con la richiesta del client e il gateway applicazione non può soddisfarlo. |
|---|---|
| ERRORINFO_INVALID_METHOD | Il client ha inviato una richiesta non conforme a RFC. Possibili motivi: il client che usa il metodo HTTP non supportato dal server, il metodo con errori di ortografia, la versione del protocollo HTTP incompatibile e così via. |
| ERRORINFO_INVALID_REQUEST | Il server non può soddisfare la richiesta a causa di una sintassi errata. |
| ERRORINFO_INVALID_VERSION | Il gateway applicazione ha ricevuto una richiesta con una versione HTTP non valida o non supportata. |
| ERRORINFO_INVALID_09_METHOD | Richiesta inviata dal client con protocollo HTTP versione 0.9. |
| ERRORINFO_INVALID_HOST | Il valore specificato nell'intestazione "Host" è mancante, formattato in modo non corretto o non corrisponde al valore host previsto. Ad esempio, quando non è presente alcun listener Basic e nessuno dei nomi host dei listener multisito corrisponde all'host. |
| ERRORINFO_INVALID_CONTENT_LENGTH | La lunghezza del contenuto specificato dal client nell'intestazione content-Length non corrisponde alla lunghezza effettiva del contenuto nella richiesta. |
| ERRORINFO_INVALID_METHOD_TRACE | Il client ha inviato il metodo HTTP TRACE, che non è supportato dal gateway applicazione. |
| ERRORINFO_CLIENT_CLO edizione Standard D_REQUEST | Il client ha chiuso la connessione con il gateway applicazione prima che sia trascorso il periodo di timeout di inattività. Controllare se il periodo di timeout del client è maggiore del periodo di timeout di inattività per il gateway applicazione. |
| ERRORINFO_REQUEST_URI_INVALID | Indica un problema con l'URI (Uniform Resource Identifier) fornito nella richiesta del client. |
| ERRORINFO_HTTP_NO_HOST_HEADER | Il client ha inviato una richiesta senza intestazione host. |
| ERRORINFO_HTTP_TO_HTTPS_PORT | Il client ha inviato una normale richiesta HTTP a una porta HTTPS. |
| ERRORINFO_HTTPS_NO_CERT | Indica che il client non invia un certificato TLS valido e configurato correttamente durante l'autenticazione TLS reciproca. |
| Errori 5XX | Descrizione |
|---|---|
| ERRORINFO_UPSTREAM_NO_LIVE | Il gateway applicazione non è in grado di trovare server back-end attivi o raggiungibili per gestire le richieste in ingresso |
| ERRORINFO_UPSTREAM_CLO edizione Standard D_CONNECTION | Il server back-end ha chiuso la connessione in modo imprevisto o prima che la richiesta sia stata elaborata completamente. Questo problema può verificarsi a causa del raggiungimento dei limiti del server back-end, dell'arresto anomalo e così via. |
| ERRORINFO_UPSTREAM_TIMED_OUT | La connessione TCP stabilita con il server è stata chiusa perché la connessione ha richiesto più tempo del valore di timeout configurato. |
Log delle prestazioni
Il log delle prestazioni viene generato solo se è stato abilitato in ogni istanza del gateway applicazione, come descritto nei passaggi precedenti. I dati vengono archiviati nell'account di archiviazione specificato quando è stata abilitata la registrazione. I dati del log delle prestazioni vengono generati a intervalli di un minuto. È disponibile solo per lo SKU v1. Per lo SKU v2, usare Metriche per i dati sulle prestazioni. Vengono registrati i dati seguenti:
| Valore | Descrizione |
|---|---|
| instanceId | Istanza del gateway applicazione per cui vengono generati i dati delle prestazioni. Per un gateway applicazione a istanze multiple, è presente una riga per istanza. |
| healthyHostCount | Numero di host integri nel pool back-end. |
| unHealthyHostCount | Numero di host non integri nel pool back-end. |
| requestCount | Numero di richieste gestite. |
| latenza | Latenza media in millisecondi delle richieste dall'istanza al back-end che gestisce le richieste. |
| failedRequestCount | Numero di richieste non riuscite. |
| throughput | Velocità effettiva media dall'ultimo log, misurata in byte al secondo. |
{
"resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/{applicationGatewayName}",
"operationName": "ApplicationGatewayPerformance",
"time": "2016-04-09T00:00:00Z",
"category": "ApplicationGatewayPerformanceLog",
"properties":
{
"instanceId":"ApplicationGatewayRole_IN_1",
"healthyHostCount":"4",
"unHealthyHostCount":"0",
"requestCount":"185",
"latency":"0",
"failedRequestCount":"0",
"throughput":"119427"
}
}
Nota
La latenza è calcolata dal momento in cui viene ricevuto il primo byte della richiesta HTTP al momento in cui viene inviato l'ultimo byte della risposta HTTP. Si tratta della somma del tempo di elaborazione del gateway applicazione, del costo di rete per il back-end e del tempo impiegato dal back-end per elaborare la richiesta.
Log del firewall
Il log del firewall viene generato solo se è stato abilitato in ogni gateway applicazione, come descritto nei passaggi precedenti. Questo log richiede anche che il web application firewall sia configurato in un gateway applicazione. I dati vengono archiviati nell'account di archiviazione specificato quando è stata abilitata la registrazione. Vengono registrati i dati seguenti:
| Valore | Descrizione |
|---|---|
| instanceId | Istanza del gateway applicazione per cui vengono generati i dati del firewall. Per un gateway applicazione a istanze multiple, è presente una riga per istanza. |
| clientIp | IP di origine della richiesta. |
| clientPort | Porta di origine della richiesta. |
| requestUri | URL della richiesta ricevuta. |
| ruleSetType | Tipo di set di regole. Il valore disponibile è OWASP. |
| ruleSetVersion | Versione del set di regole usata. I valori disponibili sono 2.2.9 e 3.0. |
| ruleId | ID regola dell'evento di attivazione. |
| messaggio | Messaggio descrittivo dell'evento di attivazione. Altre informazioni sono disponibili nella sezione dei dettagli. |
| action | Azione eseguita sulla richiesta. I valori disponibili sono Blocked e Allowed (per le regole personalizzate), Matched (quando una regola corrisponde a una parte della richiesta) e Detected e Blocked (queste sono entrambe per le regole obbligatorie, a seconda che waf sia in modalità di rilevamento o prevenzione). |
| sito | Sito per cui è stato generato il log. Attualmente viene visualizzato solo Global poiché le regole sono globali. |
| dettagli | Dettagli dell'evento di attivazione. |
| details.message | Descrizione della regola. |
| details.data | Dati specifici individuati nella richiesta corrispondente alla regola. |
| details.file | File di configurazione che conteneva la regola. |
| details.line | Numero di riga nel file di configurazione che ha attivato l'evento. |
| hostname | Nome host o indirizzo IP del gateway applicazione. |
| transactionId | ID univoco per una determinata transazione che consente di raggruppare più violazioni delle regole che si sono verificate all'interno della stessa richiesta. |
{
"timeStamp": "2021-10-14T22:17:11+00:00",
"resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/{applicationGatewayName}",
"operationName": "ApplicationGatewayFirewall",
"category": "ApplicationGatewayFirewallLog",
"properties": {
"instanceId": "appgw_2",
"clientIp": "185.42.129.24",
"clientPort": "",
"requestUri": "\/",
"ruleSetType": "OWASP_CRS",
"ruleSetVersion": "3.0.0",
"ruleId": "920350",
"message": "Host header is a numeric IP address",
"action": "Matched",
"site": "Global",
"details": {
"message": "Warning. Pattern match \\\"^[\\\\d.:]+$\\\" at REQUEST_HEADERS:Host .... ",
"data": "20.110.30.194:80",
"file": "rules\/REQUEST-920-PROTOCOL-ENFORCEMENT.conf",
"line": "791"
},
"hostname": "20.110.30.194:80",
"transactionId": "592d1649f75a8d480a3c4dc6a975309d",
"policyId": "default",
"policyScope": "Global",
"policyScopeName": "Global"
}
}
Visualizzare e analizzare Log attività
È possibile visualizzare e analizzare i dati del log attività usando uno dei metodi seguenti:
- Strumenti di Azure: recuperare le informazioni dal log attività con Azure PowerShell, l'interfaccia della riga di comando (CLI) di Azure, l'API REST di Azure o il portale di Azure. Le istruzioni dettagliate di ciascun metodo sono fornite nell'articolo Operazioni attività con Resource Manager.
- Power BI: se non esiste ancora un account Power BI , è possibile crearne uno di prova gratuitamente. Usando le app modello di Power BI, è possibile analizzare i dati.
Visualizzare e analizzare i log di accesso, delle prestazioni e del firewall
I log di Monitoraggio di Azure consentono di raccogliere i file dei log contatori ed eventi dall'account di archiviazione BLOB. Include visualizzazioni e funzionalità di ricerca avanzate per analizzare i log.
È anche possibile connettersi all'account di archiviazione e recuperare le voci del log JSON per i log di accesso e delle prestazioni. Dopo avere scaricato i file JSON, è possibile convertirli in CSV e visualizzarli in Excel, PowerBI o un altro strumento di visualizzazione dei dati.
Suggerimento
Se si ha familiarità con Visual Studio e i concetti di base relativi alla modifica dei valori per costanti e variabili in C#, è possibile usare gli strumenti del convertitore di log disponibili in GitHub.
Analisi dei log di accesso con GoAccess
È stato pubblicato un modello di Resource Manager che installa ed esegue il diffuso analizzatore di log GoAccess per i log di accesso del gateway applicazione. GoAccess offre statistiche utili sul traffico HTTP, ad esempio il numero di visitatori unici, file richiesti, host, sistemi operativi, browser, codici di stato HTTP e altro ancora. Per altre informazioni, vedere il file Readme nella cartella del modello di Resource Manager in GitHub.
Passaggi successivi
- Visualizzare i log contatori ed eventi usando i log di Monitoraggio di Azure.
- Post di blog Visualize your Azure activity log with Power BI (Visualizzare il log attività di Azure con Power BI).
- Post di blog View and analyze Azure activity logs in Power BI and more (Visualizzare e analizzare i log attività di Azure in Power BI e altre opzioni).