Azure Firewall riferimento ai dati di monitoraggio

Questo articolo contiene tutte le informazioni di riferimento sul monitoraggio per questo servizio.

Vedere Monitor Azure Firewall per informazioni dettagliate sui dati che è possibile raccogliere per Azure Firewall e su come usarli.

Metrics

Questa sezione elenca tutte le metriche della piattaforma raccolte automaticamente per questo servizio. Queste metriche fanno anche parte dell'elenco globale di tutte le metriche della piattaforma supportate in Azure Monitor.

Per informazioni sulla conservazione delle metriche, vedere panoramica Azure Monitor Metrics.

Metriche supportate per Microsoft.Network/azureFirewalls

La tabella seguente elenca le metriche disponibili per il tipo di risorsa Microsoft.Network/azureFirewalls.

• Potrebbero non essere presenti tutte le colonne in ogni tabella.
• Alcune colonne potrebbero superare l'area di visualizzazione della pagina. Selezionare Espandi tabella per visualizzare tutte le colonne disponibili.

Intestazioni di tabella

• Categoria: gruppo o classificazione delle metriche.
• Metric: nome visualizzato della metrica visualizzato nel portale di Azure.
• Nome nell'API REST: nome della metrica indicato nell'API REST.
• Unità: Unità di misura.
• Aggregazione: tipo di aggregazione predefinito. Valori validi: Medio (Avg), Minimo (Min), Massimo (Max), Totale (Sum), Conteggio.
• Dimensioni - Dimensioni disponibili per la metrica in questione.
• Intervalli di tempo - Intervalli in cui viene campionata la metrica. Ad esempio, PT1M indica che la metrica viene campionata ogni minuto, PT30M ogni 30 minuti, PT1H ogni ora e così via.
• DS Export- Indica se la metrica è esportabile nei log Azure Monitor tramite le impostazioni di diagnostica. Per informazioni sull'esportazione delle metriche, vedere Creare le impostazioni di diagnostica in Azure Monitor.

Capacità osservata

La metrica Capacità osservata è lo strumento principale per comprendere il modo in cui il firewall sta scalando in pratica.

Procedure consigliate per l'uso della capacità osservata

• Convalidare la configurazione della scalabilità preliminare: Verificare che il firewall mantenga in modo coerente il valore minCapacity definito.
• Tenere traccia del comportamento di ridimensionamento in tempo reale: Usare l'aggregazione Avg per visualizzare le unità di capacità in tempo reale.
• Prevedere le esigenze future: Combinare la capacità osservata cronologica con le tendenze del traffico (ad esempio, picchi mensili o eventi stagionali) per perfezionare la pianificazione della capacità.
• Set proactive alerts: Configure Azure Monitor alerts on Observed Capacity thresholds (ad esempio, alert when scaling exceed 80% of maxCapacity).
• Correlare con le metriche delle prestazioni: Associare la capacità osservata alla velocità effettiva, al probe di latenza e all'utilizzo delle porte SNAT per diagnosticare se il ridimensionamento continua a gestire la domanda.

Stato di integrità del firewall

Nella tabella precedente la metrica Dello stato di integrità del firewall ha due dimensioni:

• Stato: i valori possibili sono Integro, Danneggiato, Non integro.
• Motivo: indica il motivo dello stato corrispondente del firewall.

Se le porte SNAT vengono usate più di 95%, vengono considerate esaurite e l'integrità è 50% con status=Degraded e reason=SNAT port. Il firewall continua a elaborare il traffico e le connessioni esistenti non sono interessate. Tuttavia, le nuove connessioni potrebbero non essere stabilite in modo intermittente.

Se le porte SNAT sono usate meno del 95%, il firewall viene considerato integro e l'integrità viene visualizzata come al 100%.

Se non viene segnalato alcun utilizzo delle porte SNAT, l'integrità viene visualizzata come 0%.

Utilizzo delle porte SNAT

Per la metrica di utilizzo delle porte SNAT, quando si aggiungono altri indirizzi IP pubblici al firewall, sono disponibili più porte SNAT, riducendo l'utilizzo delle porte SNAT. Inoltre, quando il firewall viene ridimensionato per motivi diversi (ad esempio, CPU o velocità effettiva) diventano disponibili anche più porte SNAT.

In effetti, una determinata percentuale di utilizzo delle porte SNAT potrebbe risultare inattiva senza aggiungere indirizzi IP pubblici, proprio perché il servizio è stato ridimensionato. È possibile controllare direttamente il numero di indirizzi IP pubblici disponibili per aumentare le porte disponibili nel firewall. Tuttavia, non è possibile controllare direttamente il ridimensionamento del firewall.

Se il firewall è in esecuzione nell'esaurimento delle porte SNAT, è necessario aggiungere almeno cinque indirizzi IP pubblici. Questo aumenta il numero di porte SNAT disponibili. Per altre informazioni, vedere Azure Firewall features.

Probe di latenza AZFW

La metrica AZFW Latency Probe misura la latenza complessiva o media di Azure Firewall in millisecondi. Gli amministratori possono usare questa metrica ai fini seguenti:

• Diagnosticare se Azure Firewall causa la latenza nella rete
• Monitorare e segnalare problemi di latenza o prestazioni, in modo che i team IT possano interagire in modo proattivo
• Identificare vari fattori che possono causare una latenza elevata in Azure Firewall, ad esempio un utilizzo elevato della CPU, una velocità effettiva elevata o problemi di rete

Misure della metrica AZFW Latency Probe

• Measures: La latenza di Azure Firewall all'interno della piattaforma Azure
• Non misura: Latenza end-to-end per l'intero percorso di rete. La metrica riflette le prestazioni all'interno del firewall anziché la latenza Azure Firewall introduce nella rete
• Segnalazione errori: Se la metrica di latenza non funziona correttamente, segnala il valore 0 nel dashboard delle metriche, che indica un errore o un'interruzione del probe

Fattori che influisce sulla latenza

Diversi fattori possono influire sulla latenza del firewall:

• Utilizzo elevato della CPU
• Velocità effettiva elevata o carico del traffico
• Problemi di rete all'interno della piattaforma Azure

Probe di latenza: da ICMP a TCP

Il probe di latenza usa attualmente la tecnologia Ping Mesh di Microsoft, basata su ICMP (Internet Control Message Protocol). ICMP è adatto per controlli di integrità rapidi, ad esempio le richieste ping, ma potrebbe non rappresentare accuratamente il traffico dell'applicazione reale, che in genere si basa su TCP. Tuttavia, i probe ICMP assegnano priorità in modo diverso alla piattaforma Azure, con conseguente variazione tra SKU. Per ridurre queste discrepanze, Azure Firewall prevede la transizione ai probe basati su TCP.

Considerazioni importanti:

• Picchi di latenza: Con i probe ICMP, i picchi intermittenti sono normali e fanno parte del comportamento standard della rete host. Non interpretate erroneamente questi picchi come problemi del firewall, a meno che non siano persistenti.
• Average latency: In media, Azure Firewall la latenza è compresa tra 1 ms e 10 ms, a seconda delle dimensioni dello SKU del firewall e della distribuzione.

Procedure consigliate per il monitoraggio della latenza

• Impostare una linea di base: stabilire una linea di base di latenza in condizioni di traffico leggero per confronti accurati durante l'utilizzo normale o di picco.

  Note

  Quando si stabilisce la baseline, prevedere picchi di metriche occasionali a causa di modifiche recenti dell'infrastruttura. Questi picchi temporanei sono normali e derivano da rettifiche di report delle metriche, non da problemi effettivi. Inviare una richiesta di supporto solo se i picchi persistono nel tempo.

• Monitorare i modelli: prevedere picchi di latenza occasionali come parte delle normali operazioni. Se la latenza elevata persiste oltre queste variazioni normali, può indicare un problema più approfondito che richiede un'indagine.

• Soglia di latenza consigliata: una linea guida consigliata è che la latenza non deve superare 3 volte la baseline. Se questa soglia viene superata, è consigliabile eseguire ulteriori indagini.

• Controllare il limite di regole: assicurarsi che le regole di rete siano entro il limite di 20.000 regole. Il superamento di questo limite può influire sulle prestazioni.

• Onboarding di nuove applicazioni: verificare le applicazioni appena caricate che potrebbero aggiungere un carico significativo o causare problemi di latenza.

• Richiesta di supporto: se si osserva una riduzione della latenza continua che non è allineata al comportamento previsto, provare a inviare un ticket di supporto per ulteriore assistenza.

  

Dimensioni delle metriche

Per informazioni sulle dimensioni delle metriche, vedere Metriche multidimensionali.

Questo servizio ha le dimensioni seguenti associate alle relative metriche.

• Protocol
• Reason
• Status

Log delle risorse

Questa sezione elenca i tipi di log delle risorse che si possono raccogliere per questo servizio. La sezione esegue il pull dall'elenco di tutti i tipi di categoria dei log delle risorse supportati in Azure Monitor.

Log delle risorse supportati per Microsoft.Network/azureFirewalls

Log di traccia del flusso DNS

I log di traccia del flusso DNS offrono visibilità più approfondita sulle attività DNS, consentendo agli amministratori di risolvere i problemi di risoluzione e verificare il comportamento del traffico.

In precedenza, la registrazione proxy DNS era limitata a:

• AZFWDNSQuery : query client iniziale
• AZFWInternalFqdnResolutionFailure - Errori di risoluzione FQDN

Con i log di traccia del flusso DNS, gli amministratori possono tracciare il flusso di risoluzione DNS completo dalla query client tramite Azure Firewall come proxy DNS, al server DNS esterno e di nuovo al client.

Fasi di risoluzione DNS

I log acquisisce le fasi seguenti:

1. Query client: query DNS iniziale inviata dal client
2. query Forwarder: Azure Firewall inoltrare la query a un server DNS esterno (se non memorizzato nella cache)
3. risposta Forwarder: risposta del server DNS a Azure Firewall
4. risposta Client: risposta risolta finale da Azure Firewall al client

Il diagramma seguente mostra una rappresentazione visiva generale del flusso di query DNS:

Questi log forniscono informazioni dettagliate preziose, ad esempio:

• Il server DNS sottoposto a query
• Indirizzi IP risolti
• Indica se è stata usata la cache Azure Firewall

Abilitazione dei log di traccia del flusso DNS

Prima di configurare i log di traccia del flusso DNS, è necessario abilitare la funzionalità usando Azure PowerShell.

Abilitare i log (prerequisiti)

Eseguire i comandi seguenti in Azure PowerShell, sostituendo i segnaposto con i valori:

Set-AzContext -SubscriptionName <SubscriptionName>
$firewall = Get-AzFirewall -ResourceGroupName <ResourceGroupName> -Name <FirewallName>
$firewall.EnableDnstapLogging = $true
Set-AzFirewall -AzureFirewall $firewall

Disabilitare i log (facoltativo)

Per disabilitare i log, usare lo stesso comando Azure PowerShell precedente e impostare il valore su False:

Set-AzContext -SubscriptionName <SubscriptionName>
$firewall = Get-AzFirewall -ResourceGroupName <ResourceGroupName> -Name <FirewallName>
$firewall.EnableDnstapLogging = $false
Set-AzFirewall -AzureFirewall $firewall

Configurare i log di traccia del flusso DNS e del proxy DNS

Usare la procedura seguente per configurare il proxy DNS e abilitare i log di traccia del flusso DNS:

1. Abilitare il proxy DNS:

   1. Passare a Azure Firewall impostazioni DNS e abilitare proxy DNS.
   2. Configurare un server DNS personalizzato o usare il Azure DNS predefinito.
   3. Passare a Virtual Network impostazioni DNS e impostare l'INDIRIZZO IP privato del firewall come server DNS primario.

2. Abilitare i log di traccia del flusso DNS:

   1. Passare a Azure Firewall nel portale di Azure.
   2. Selezionare Impostazioni di diagnostica in Monitoraggio.
   3. Scegliere un'impostazione di diagnostica esistente o crearne una nuova.
   4. Nella sezione Log selezionare Log di traccia del flusso DNS.
   5. Scegliere la destinazione desiderata (Log Analytics o account di archiviazione).

   Note

   I Log di traccia DNS Flow non sono supportati con Event Hub come destinazione.

   6. Fare clic su Save (Salva) per salvare le impostazioni.

3. Testare la configurazione:

   1. Generare query DNS dai client e verificare i log nella destinazione scelta.

Informazioni sui log

Ogni voce di log corrisponde a una fase specifica del processo di risoluzione DNS. Nella tabella seguente vengono descritti i tipi di log e i campi chiave:

I campi precedenti sono solo un subset dei campi disponibili in ogni voce di log.

Note chiave:

• Se viene usata la cache DNS, vengono generate solo le voci Query client e Risposta client .
• I log includono metadati standard, ad esempio timestamp, INDIRIZZI IP di origine/destinazione, protocolli e contenuto dei messaggi DNS.
• Per evitare un volume eccessivo di log in ambienti con molte query di breve durata, abilitare log proxy DNS aggiuntivi solo quando è necessaria una risoluzione dei problemi DNS più approfondita.

Flussi principali

Il log dei flussi principali è noto nel settore come log del flusso fat e nella tabella precedente come Azure Firewall log del flusso di grasso. Il log dei flussi principali mostra le principali connessioni che contribuiscono alla velocità effettiva più elevata tramite il firewall.

La velocità di flusso è definita come velocità di trasmissione dei dati in megabit al secondo unità. Si tratta di una misura della quantità di dati digitali che possono essere trasmessi in una rete in un periodo di tempo attraverso il firewall. Il protocollo Top Flows viene eseguito periodicamente ogni tre minuti. La soglia minima da considerare un flusso superiore è di 1 Mbps.

Abilitare i log dei flussi principali

Usare i comandi di Azure PowerShell seguenti per abilitare i log dei flussi principali:

Set-AzContext -SubscriptionName <SubscriptionName>
$firewall = Get-AzFirewall -ResourceGroupName <ResourceGroupName> -Name <FirewallName>
$firewall.EnableFatFlowLogging = $true
Set-AzFirewall -AzureFirewall $firewall

Disabilitare i log dei flussi principali

Per disabilitare i log, usare lo stesso comando Azure PowerShell e impostare il valore su False. Per esempio:

Set-AzContext -SubscriptionName <SubscriptionName>
$firewall = Get-AzFirewall -ResourceGroupName <ResourceGroupName> -Name <FirewallName>
$firewall.EnableFatFlowLogging = $false
Set-AzFirewall -AzureFirewall $firewall

Verificare la configurazione

Esistono diversi modi per verificare che l'aggiornamento sia riuscito. Passare alla panoramica del firewall e selezionare Visualizzazione JSON nell'angolo in alto a destra. Ecco un esempio:

Per creare un'impostazione di diagnostica e abilitare tabella specifica della risorsa, vedere Creare le impostazioni di diagnostica in Azure Monitor.

Traccia del flusso

I log del firewall mostrano il traffico attraverso il firewall nel primo tentativo di connessione TCP, noto come pacchetto SYN . Tuttavia, tale voce non mostra il percorso completo del pacchetto nell'handshake TCP. Di conseguenza, è difficile risolvere i problemi se si è verificato un pacchetto o un routing asimmetrico. Il log di traccia del flusso Azure Firewall risolve questo problema.

Proprietà di traccia del flusso

È possibile aggiungere le proprietà seguenti:

• SYN-ACK: flag ACK che indica il riconoscimento del pacchetto SYN.

• FIN: flag completato del flusso di pacchetti originale. Non vengono trasmessi altri dati nel flusso TCP.

• FIN-ACK: flag ACK che indica il riconoscimento del pacchetto FIN.

• RST: il flag Reset indica che il mittente originale non riceve altri dati.

• INVALID (flussi): indica che il pacchetto non può essere identificato o non ha alcuno stato.

  Per esempio:

  • Un pacchetto TCP si trova in un'istanza di Virtual Machine Scale Sets, che non ha una cronologia precedente per questo pacchetto
  • Pacchetti CheckSum non valido
  • La voce della tabella rilevamento connessione è completa e non è possibile accettare nuove connessioni
  • Pacchetti ACK eccessivamente ritardati

Abilitare i log di traccia del flusso

Usare i comandi di Azure PowerShell seguenti per abilitare i log di traccia di Flow. In alternativa, passare al portale e cercare Abilita registrazione connessione TCP:

Connect-AzAccount 
Select-AzSubscription -Subscription <subscription_id> or <subscription_name>
Register-AzProviderFeature -FeatureName AFWEnableTcpConnectionLogging -ProviderNamespace Microsoft.Network
Register-AzResourceProvider -ProviderNamespace Microsoft.Network

L'applicazione di questa modifica può richiedere alcuni minuti. Dopo aver registrato la funzionalità, è consigliabile eseguire un aggiornamento in Azure Firewall affinché la modifica venga applicata immediatamente.

Controllare lo stato della registrazione

Per controllare lo stato della registrazione di AzResourceProvider, eseguire il comando Azure PowerShell seguente:

Get-AzProviderFeature -FeatureName "AFWEnableTcpConnectionLogging" -ProviderNamespace "Microsoft.Network"

Disabilitare i log di traccia del flusso

Per disabilitare il log, usare i comandi Azure PowerShell seguenti:

Connect-AzAccount 
Select-AzSubscription -Subscription <subscription_id> or <subscription_name>
$firewall = Get-AzFirewall -ResourceGroupName <ResourceGroupName> -Name <FirewallName>
$firewall.EnableTcpConnectionLogging = $false
Set-AzFirewall -AzureFirewall $firewall

Per creare un'impostazione di diagnostica e abilitare tabella specifica della risorsa, vedere Creare le impostazioni di diagnostica in Azure Monitor.

tabelle dei log Azure Monitor

Questa sezione elenca le tabelle dei log Azure Monitor rilevanti per questo servizio, disponibili per la query Log Analytics tramite query Kusto. Le tabelle contengono i dati dei log delle risorse ed eventualmente altro, a seconda di ciò che viene raccolto e indirizzato verso di esse.

Azure Firewall Microsoft.Network/azureFirewalls

• AZFWNetworkRule
• AZFWFatFlow
• AZFWFlowTrace
• AZFWApplicationRule
• AZFWThreatIntel
• AZFWNatRule
• AZFWIdpsSignature
• AZFWDnsQuery
• AZFWInternalFqdnResolutionFailure
• AZFWNetworkRuleAggregation
• AZFWApplicationRuleAggregation
• AZFWNatRuleAggregation
• AzureActivity
• AzureMetrics
• AzureDiagnostics

Log attività

Nella tabella collegata sono elencate le operazioni che possono essere registrate nel log attività per questo servizio. Queste operazioni sono un sottoinsieme di tutte le possibili operazioni del provider di risorse nel log attività.

Per altre informazioni sullo schema delle voci del log attività, vedere Schema del log attività.

• Operazioni del provider di risorse di rete

Contenuti correlati

• Per una descrizione del monitoraggio Azure Firewall, vedere Monitor Azure Firewall.
• Vedere Track rule set changes for detailed Azure Resource Graph querys to track firewall rule changes( Modifiche alle regole del firewall).
• Per informazioni dettagliate sul monitoraggio delle risorse Azure, vedere Monitor Azure risorse con Azure Monitor.