Questa pagina descrive le metriche utilizzate per determinare il rendimento delle risorse del tuo progettoGoogle Cloud e dell'intero Google Cloud. Puoi anche trovare dettagli sulle varie visualizzazioni che mostrano ulteriori dettagli su queste metriche sul rendimento.
Metriche
Performance Dashboard fornisce due tipi di metriche: perdita di pacchetti e latenza (tempo di round trip o RTT). Per ottenere le metriche sulla perdita di pacchetti per il tuo progettoGoogle Cloud , devi avere un numero sufficiente di VM nel progetto. Per ottenere le metriche di latenza, è necessario un volume di traffico sufficiente. Inoltre, Performance Dashboard non richiede alcuna configurazione.
Le sezioni seguenti descrivono entrambe le metriche in modo più dettagliato.
Perdita pacchetti
Le metriche sulla perdita di pacchetti mostrano i risultati del probing attivo tra:
VM all'interno di una singola rete VPC.
VM in reti VPC in peering, quando una o entrambe le reti si trovano all'interno del tuo progetto. Se le reti in peering si trovano in progetti diversi, la perdita di pacchetti è visibile nel progetto di destinazione.
VM in una rete VPC condiviso utilizzata dal tuo progetto. La perdita di pacchetti tra due progetti che utilizzano una rete VPC condiviso è visibile nel progetto di servizio di destinazione.
Ad esempio, supponiamo che il progetto A includa due reti VPC: la rete A, che ha VM solo nella zona A, e la rete M, che ha VM solo nella zona M. Se le due reti sono in peering, Performance Dashboard del progetto A mostra i dati sulla perdita di pacchetti per la coppia di zone A/M. Se le reti non sono in peering, Performance Dashboard non mostra la metrica relativa alla perdita di pacchetti per la coppia di zone.
Se queste due reti non si trovano nello stesso progetto, annota quando la Performance Dashboard di ciascuna rete mostra le metriche. ovvero, supponiamo che la rete A faccia parte del progetto A e la rete M faccia parte del progetto M. Quando le reti sono in peering, Performance Dashboard del progetto M mostra i dati sulla perdita di pacchetti per le situazioni in cui la zona M è la zona di destinazione. Al contrario, quando la zona A è la zona di destinazione, i dati sulla perdita di pacchetti sono visibili solo al progetto A. Se le reti non sono in peering, Performance Dashboard di nessuno dei due progetti mostra i dati sulla perdita di pacchetti per la coppia di zone.
I dati raccolti tramite tutti i probe vengono aggregati nella Performance Dashboardo. ovvero Performance Dashboard non consente di isolare i dati sulla perdita di pacchetti intra-progetto rispetto ad altri tipi (ad esempio la perdita di pacchetti correlata a una rete VPC in peering in un altro progetto). Tuttavia, puoi utilizzare Monitoring per visualizzare risultati più dettagliati. Per saperne di più, consulta Riferimento alle metriche di Performance Dashboard.
Performance Dashboard non invia probe tramite le connessioni Cloud VPN.
Metodologia
Performance Dashboard esegue i worker sugli host fisici che ospitano le tue VM. Questi worker inseriscono e ricevono pacchetti di probe che vengono eseguiti sulla stessa rete del tuo traffico. Poiché i worker vengono eseguiti sugli host fisici e non sulle tue VM, non consumano risorse VM e il traffico non è visibile sulle tue VM.
I probe coprono l'intera mesh di VM che possono comunicare tra loro, che non corrisponde necessariamente al tuo pattern di traffico. Pertanto, potresti vedere indicazioni di perdita di pacchetti inPerformance Dashboardo, ma nessuna prova di perdita di pacchetti nella tua applicazione.
Per tutte le VM sottoposte a probe, Google Cloud tenta di accedere alla VM utilizzando sia il suo indirizzo IP interno sia l'indirizzo IP esterno (se esistente). I probe non escono da Google Cloud, ma utilizzando indirizzi IP esterni, Performance Dashboard può coprire parte del percorso utilizzato dal traffico esterno, ad esempio il traffico proveniente da internet.
La perdita di pacchetti per gli indirizzi IP interni viene misurata utilizzando pacchetti UDP, mentre la perdita di pacchetti per gli indirizzi IP esterni viene misurata utilizzando pacchetti TCP.
Livelli di disponibilità e affidabilità delle metriche
Performance Dashboard esamina un sottoinsieme di tutte le coppie VM-VM nella rete. I dati raccolti vengono poi utilizzati per stimare la perdita di pacchetti che potresti riscontrare. L'affidabilità dei dati di Google dipende dalla frequenza di probing, che a sua volta dipende dal numero di VM presenti in ogni zona, nonché dal numero di zone in cui sono state implementate le VM. Ad esempio, avere 10 VM in due zone genera più confidenza rispetto ad averne 10 in 10 zone.
Tutte le VM, incluse quelle create da Google Kubernetes Engine (GKE), vengono conteggiate nel numero totale di VM.
I vari livelli di confidenza sono descritti nella tabella seguente. I livelli di confidenza
inferiori sono contrassegnati nella mappa termica con un asterisco
(*) o N/A.
| Livello | Numero richiesto di VM in ogni zona | Che cosa mostra Performance Dashboard sulla mappa termica |
|---|---|---|
| 95% di affidabilità | 10 VM moltiplicate per il numero di zone nel progetto. Ad esempio, se hai 12 zone nel tuo progetto, devi avere 120 VM in ogni zona. | Una misurazione senza annotazioni aggiuntive |
| 90% di affidabilità | 2,5 VM moltiplicate per il numero di zone nel progetto. Ad esempio, se hai 12 zone nel tuo progetto, devi avere 30 VM in ogni zona. | Una misurazione senza annotazioni aggiuntive |
| Scarsa affidabilità | Una misurazione con un asterisco | |
| Probe insufficienti per disporre di dati significativi | N/A |
Le metriche di perdita di pacchetti Google Cloud sono sempre disponibili. Un asterisco (*) viene visualizzato se ci sono meno di 400 probe al minuto.
Latenza specifica per progetto
Le metriche di latenza vengono misurate utilizzando il traffico dei clienti tra quanto segue:
- VM all'interno di una singola rete VPC
- VM tra reti VPC in peering, se le reti si trovano nello stesso progetto
- VM ed endpoint internet
Inoltre, Performance Dashboard per un progetto di servizio all'interno di una rete VPC condiviso mostra i dati solo per le zone all'interno del progetto di servizio. Supponiamo, ad esempio, che una VM nella zona A e nel progetto di servizio A utilizzi il progetto host per comunicare con una VM nella zona B e nel progetto di servizio B. Le misurazioni relative a questo traffico non sono disponibili né per il progetto di servizio né per il progetto host.
Google Cloud latency
Le metriche di latenza vengono misurate utilizzando il traffico effettivo dei clienti tra quanto segue:
- VM all'interno di una singola rete VPC
- VM tra reti VPC in peering
- VM ed endpoint internet
Metodologia per la latenza del progetto e Google Cloud
La latenza viene misurata utilizzando i pacchetti TCP.
In base a un campione del tuo traffico effettivo, la latenza viene calcolata come il tempo che trascorre tra l'invio di un numero di sequenza TCP (SEQ) e la ricezione di un ACK corrispondente che contiene il ritardo relativo allo stack RTT di rete e TCP.
Poiché il comportamento di campionamento e dell'applicazione influisce sul momento in cui vengono registrati i ACK,
la metrica di latenza potrebbe includere anche ritardi a livello di applicazione.
Per ulteriori informazioni, consulta Anomalie della metrica di latenza.
Per scoprire in che modo la latenza dell'applicazione influisce sull'RTT, consulta
Breve panoramica del tempo di andata e ritorno.
La dashboard mostra la latenza come mediana di tutte le misurazioni pertinenti.
La metrica della latenza si basa sulla stessa origine dati e metodologia di campionamento dei log di flusso VPC.
La latenza specifica del progetto si basa su campioni del progetto. La latenza Google Cloud si basa su campioni provenienti da tutti i Google Cloud.
Le metriche di latenza globale derivano dal campionamento passivo delle intestazioni del traffico TCP e non dal probing attivo da Google Cloud agli endpoint internet.
Anomalie delle metriche di latenza
Tieni presente le seguenti anomalie delle metriche di latenza:
Per gli ambienti con velocità ridotta, Network Intelligence Center utilizza probe di sessanta secondi per le metriche di latenza. Pertanto, le metriche RTT basate sul campionamento dei pacchetti potrebbero segnalare erroneamente livelli di latenza elevati quando i servizi basati su TCP restituiscono una risposta a livello di applicazione ritardata. In genere, puoi riconoscere i livelli RTT imprecisi controllando se corrispondono a ritardi a livello di applicazione.
Sebbene il servizio basato su TCP risponda rapidamente con un
ACK, il campionamento non rileva l'ACKe considera una risposta di dati successiva comeACKdi chiusura di un SEND molto precedente, il che distorce la misurazione RTT complessiva. In questi casi, verifica la latenza con un'altra origine dati (ad esempio, un testping) e, se mostra un RTT inferiore, controlla la reattività della tua applicazione.A volte, i dati di latenza specifici del progetto non corrispondono a quelli globali. Questo disallineamento può verificarsi se il set di dati globale incorpora anche altri percorsi di rete con latenze significativamente diverse rispetto al percorso di rete utilizzato dal progetto specifico.
Disponibilità delle metriche
La metrica Google Cloud latenza è sempre disponibile. La metrica della latenza per progetto è disponibile solo se il traffico TCP è pari o superiore a circa 1000 pacchetti al minuto.
Tabella di riepilogo delle metriche
La tabella seguente riassume i metodi e i protocolli di probing utilizzati per generare report sulle metriche di perdita e latenza dei pacchetti.
| Perdita pacchetti | Latenza | |
|---|---|---|
| Metodo di probing | Probe attivo (traffico VM sintetico) | Probe passivo (traffico VM effettivo) |
| Protocollo | UDP (indirizzo IP interno), TCP (indirizzo IP esterno) | TCP (indirizzi IP interni/esterni) |
Visualizzazioni della latenza
I dettagli della latenza per il tipo di traffico Internet to Google Cloud sono disponibili in tre visualizzazioni: Tabella, Mappa e Cronologia.
Visualizzazione tabella
La visualizzazione Tabella mostra il valore RTT mediano tra le aree geografiche selezionate e le regioni che contengono istanze VM nel tuo progetto. La tabella include i seguenti dettagli:
- Paese: il nome del paese.
- Città: il numero di città. Puoi visualizzare i dettagli della latenza di ogni città specifica nel grafico dei dettagli del paese.
- Regioni di destinazione: il numero di regioni di destinazione con traffico per gli utenti di un determinato paese.
- Latenza mediana: l'RTT mediano, in millisecondi, tra il paese e le regioni.
Visualizzazione mappa
La visualizzazione Mappa mostra le posizioni geografiche (aree metropolitane o città) e leGoogle Cloud regioni.
- Visualizza la latenza mediana di località e regioni specifiche. Google Cloud
- Seleziona una Google Cloud regione e visualizza le località con traffico verso la regione selezionata.
- Visualizza i dettagli specifici per località in un grafico della latenza nella barra laterale.
- Cerca le località utilizzando la casella di ricerca nella mappa.
Le località sono classificate in diverse tonalità di blu per indicare gli intervalli di latenza mediana sulla mappa. Nell'immagine seguente, il colore di un cerchio che mostra una determinata città su una mappa globale può essere una tonalità di blu. Più è scura la tonalità di blu, maggiore è la latenza di quella città rispetto a una determinata regione Google Cloud .
Visualizzazione Timeline
La visualizzazione Cronologia mostra l'RTT mediano tra le aree geografiche selezionate e le regioni. Google Cloud Fornisce le metriche di latenza attuali e sei settimane di dati storici. Puoi utilizzare i filtri per aggregare ulteriormente il traffico a livello di città, regione geografica e paese. Puoi visualizzare le metriche di latenza corrispondenti a specifiche coppie regione-località geografica solo se è presente un volume di traffico sufficiente per la coppia. Google Cloud