Diagnostica di Load Balancer Standard con metriche, avvisi e integrità delle risorse

La metrica di disponibilità del percorso dati descrive l’integrità all'interno dell'area del percorso dati verso l'host di calcolo in cui si trovano le macchine virtuali. La metrica è un riflesso dell'integrità del servizio di bilanciamento del carico, in base alla configurazione e all'infrastruttura Azure. La metrica può essere utilizzata per:

• Monitorare la disponibilità esterna del servizio.

• Esaminare la piattaforma in cui viene distribuito il servizio e stabilire se è integra. Stabilire se l'istanza dell'applicazione o il sistema operativo guest è integro.

• Isolare se un evento è correlato al servizio o al piano dati sottostante. Non confondere questa metrica con la metrica di stato del probe di integrità.

Per ottenere la disponibilità del percorso dati per le risorse di servizio di bilanciamento del carico:

1. Assicurarsi che sia selezionata la risorsa di Load Balancer corretta.

2. Nell'elenco a discesa Metrica selezionare Disponibilità percorso dati.

3. Nell’elenco a discesa Aggregazione, selezionare Media.

4. Aggiungere anche un filtro sull'indirizzo IP front-end o sulla porta front-end come dimensione per la porta o l'indirizzo IP front-end richiesto. Raggrupparli quindi in base alla dimensione selezionata.

La metrica viene generata da un servizio di esecuzione del probe nell'area che simula il traffico. Il servizio di esecuzione del probe genera periodicamente un pacchetto che corrisponde alla regola front-end e di bilanciamento del carico della distribuzione. Il pacchetto attraversa quindi l'area dall'origine all'host di una macchina virtuale nel pool back-end. L'infrastruttura di Load Balancer esegue le stesse operazioni di traslazione e bilanciamento del carico che vengono effettuate per tutto il resto del traffico. Dopo che il probe arriva nell'host, in cui si trova una macchina virtuale nel pool back-end, l'host genera una risposta al servizio di esecuzione del probe. La macchina virtuale in uso non vede questo traffico.

Si noti che la metrica di disponibilità del percorso dati viene generata solo nelle configurazioni IP front-end con regole di bilanciamento del carico.

La metrica di disponibilità del percorso dati può essere danneggiata per i motivi seguenti:

• La distribuzione non ha macchine virtuali integre rimanenti nel pool back-end.

• Si è verificata un'interruzione dell'infrastruttura.

Per scopi di diagnostica, è possibile usare la metrica di disponibilità del percorso dati con lo stato del probe di integrità.

Usare Media come aggregazione per la maggior parte degli scenari.

La metrica di stato del probe di integrità descrive l'integrità della distribuzione dell'applicazione come configurato dall'utente quando si configura il probe di integrità del servizio di bilanciamento del carico. Load Balancer usa lo stato del probe di integrità per determinare dove inviare nuovi flussi. Le sonde di integrità provengono da un indirizzo dell'infrastruttura Azure e sono visibili all'interno del sistema operativo guest della macchina virtuale (VM).

Per ottenere la metrica di stato del probe di integrità per le risorse di servizio di bilanciamento del carico:

1. Selezionare la metrica Stato probe di integrità con tipo di aggregazione Media.

2. Applicare un filtro sulla porta o sull'indirizzo IP front-end richiesto (o entrambi).

I probe di integrità hanno esito negativo per le ragioni seguenti:

• Se si configura un probe di integrità per una porta che non è in ascolto, non risponde o non utilizza il protocollo corretto. Se il servizio usa regole di IP mobile o di tipo Direct Server Return, verificare che il servizio sia in ascolto sull'indirizzo IP della configurazione IP della scheda di interfaccia di rete e sul loopback configurato con l'indirizzo IP front-end.

• Il gruppo di sicurezza di rete, il firewall del sistema operativo guest della macchina virtuale o i filtri del livello applicazione non consentono il traffico del probe di integrità.

Usare Media come aggregazione per la maggior parte degli scenari.

La metrica SNAT Connection Count descrive il volume di connessioni riuscite e fallite per i flussi in uscita.

Un volume di connessioni fallite superiore a zero indica esaurimento della porta SNAT. Devi indagare ulteriormente per determinare cosa possa causare questi guasti. L'esaurimento delle porte SNAT si manifesta sotto forma di errore durante la definizione di un flusso in uscita. Fare riferimento all'articolo sulle connessioni in uscita per comprendere gli scenari e i meccanismi coinvolti e scoprire come ridurre ed evitare l'esaurimento delle porte SNAT in fase di progettazione.

Per ottenere statistiche sulle connessioni SNAT:

1. Seleziona SNAT Connection Count e Sum come aggregazione.

2. Procedere al raggruppamento per Stato connessione per il conteggio delle connessioni SNAT riuscite e non riuscite rappresentate da righe diverse.

La metrica per l'uso delle porte SNAT tiene traccia del numero di porte SNAT utilizzate per gestire i flussi in uscita. Questa metrica indica il numero di flussi univoci stabiliti tra un'origine Internet e una macchina virtuale back-end o un set di scalabilità di macchine virtuali dietro un servizio di bilanciamento del carico e non ha un indirizzo IP pubblico. Confrontando il numero di porte SNAT in uso con la metrica per le porte SNAT allocate, è possibile determinare se il servizio riscontri o sia a rischio di esaurimento SNAT con conseguente errore del flusso in uscita.

Se le metriche indicano il rischio di errore per il flusso in uscita, vedere l'articolo relativo alle operazioni necessarie per correggere questo problema e garantire l'integrità dei servizi.

Per visualizzare l'utilizzo e l'allocazione delle porte SNAT:

1. Impostare l'aggregazione temporale del grafico su 1 minuto per assicurare che vengano visualizzati i dati desiderati.

2. Selezionare Porte SNAT usate e/o porte SNAT allocate come tipo di metrica e Media come aggregazione.

   • Per impostazione predefinita, tali metriche rappresentano il numero medio di porte SNAT allocate o usate da ogni macchina virtuale back-end o set di scalabilità di macchine virtuali. Corrispondono a tutti gli indirizzi IP pubblici front-end mappati al servizio di bilanciamento del carico e aggregati su TCP e UDP.

   • Per visualizzare le porte SNAT totali usate o allocate per il servizio di bilanciamento del carico, usare l'aggregazione delle metriche Somma.

3. Filtrare in base a un tipo di protocollo specifico e a un set di indirizzi IP back-end e/o indirizzi IP front-end.

4. Per monitorare l'integrità per ogni istanza back-end o front-end, applicare la suddivisione.

   • Si noti che la suddivisione consente solo la visualizzazione di una singola metrica alla volta.

5. Ad esempio, per monitorare l'utilizzo SNAT per i flussi TCP per computer, aggregare per Media, divisa per Indirizzi IP back-end e filtrare in base al tipo di protocollo.

Per altre informazioni sulle connessioni in uscita, vedere SNAT (Source Network Address Translation) per le connessioni in uscita

Usare Somma come aggregazione per la maggior parte degli scenari.

La metrica relativa ai contatori di byte e pacchetti descrive il volume di byte e pacchetti inviati o ricevuti dal servizio per ogni front-end.

Usare Somma come aggregazione per la maggior parte degli scenari.

Per ottenere statistiche relative al conteggio di byte o pacchetti:

1. Selezionare il tipo di metrica Conteggio byte e/o Conteggio pacchetti con Media come aggregazione.

2. Effettuare una delle operazioni seguenti:

   • Applicare un filtro su una porta o indirizzo IP front-end specifico o su una porta o indirizzo IP back-end specifico.

   • È possibile ottenere statistiche generali per la risorsa di Load Balancer senza applicare filtri.

La combinazione delle metriche relative alla disponibilità del percorso dati e dello stato del probe di integrità su un singolo grafico consente di identificare il punto in cui si verificano e si possono risolvere i problemi. È possibile assicurarsi che Azure funzioni correttamente e usare queste informazioni per determinare in modo definitivo che la configurazione o l'applicazione è la causa radice.

È possibile usare le metriche della sonda di integrità per comprendere come Azure interpreta lo stato della distribuzione in base alla configurazione fornita. L'analisi dei probe di integrità costituisce sempre una valida opzione per iniziare a monitorare o determinare una causa.

È possibile procedere ulteriormente e usare la metrica di disponibilità del percorso dati per ottenere una visione dettagliata di come Azure valuta l'integrità del piano dati sottostante che è responsabile per la distribuzione specifica. Quando si combinano entrambe le metriche, è possibile isolare il punto in cui potrebbe verificarsi l'errore come illustrato in questo esempio:

Figura. Combinazione delle metriche di disponibilità del percorso dati e stato del probe di integrità.

In questo grafico vengono visualizzate le informazioni seguenti:

• L'infrastruttura che ospita le macchine virtuali non era disponibile e si trovava allo 0% all'inizio del grafico. Successivamente, l'infrastruttura risultava integra, le macchine virtuali erano raggiungibili e più macchine virtuali erano posizionate nel back-end. Queste informazioni sono indicate dalla traccia blu per la disponibilità del percorso dati, successivamente al 100%.

• Lo stato del probe di integrità, indicato dalla traccia viola, è pari allo 0% all'inizio del grafico. L'area cerchiata in rosso evidenzia il punto in cui lo stato del probe di integrità è diventato integro e il punto in cui la distribuzione del cliente è stata in grado di accettare nuovi flussi.

Il grafico consente al cliente di risolvere i problemi della distribuzione in modo autonomo senza dover fare supposizioni o contattare il supporto per sapere se si stanno verificando altri problemi. Il servizio non era disponibile perché i probe di integrità hanno avuto esito negativo a causa di una configurazione errata o di un'applicazione non riuscita.