Questa pagina descrive le metriche utilizzate per determinare le prestazioni delle risorse del tuo progetto Google Cloud e quelle dell'intero progetto Google Cloud. Puoi anche trovare dettagli sulle varie viste 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 della perdita di pacchetti per il tuo progetto Google Cloud, è necessario un numero sufficiente di VM nel progetto. Per visualizzare le metriche di latenza, è necessaria una quantità sufficiente di traffico. Inoltre, Performance Dashboard non richiede alcuna configurazione.
Le seguenti sezioni descrivono entrambe le metriche in modo più dettagliato.
Perdita pacchetti
Le metriche sulla perdita di pacchetti mostrano i risultati dei probe attivi tra i seguenti:
VM all'interno di un'unica rete VPC.
VM in reti VPC in peering, quando una o entrambe le reti si trovano all'interno del 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, con VM solo nella zona A, e la rete M, che ha VM solo nella zona M. Se queste due reti sono connesse 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 della perdita di pacchetti per quella coppia di zone.
Se queste due reti non sono nello stesso progetto, prendi nota di quando Performance Dashboard di ogni rete mostra le metriche. Supponiamo che la rete A faccia parte del progetto A e la rete M faccia parte del progetto M. Quando le reti sono connesse 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 è quella di destinazione, i dati relativi alla perdita di pacchetti sono visibili solo per il 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 zona.
I dati raccolti attraverso tutti i probe vengono aggregati in Performance Dashboard. In altre parole, Performance Dashboard non consente di isolare i dati sulla perdita di pacchetti all'interno del progetto rispetto ad altri tipi (ad esempio la perdita di pacchetti relativa a una rete VPC in peering in un altro progetto). Tuttavia, puoi utilizzare Monitoring per visualizzare risultati più dettagliati. Per maggiori informazioni, consulta Riferimento sulle metriche della dashboard sul rendimento.
Performance Dashboard non invia probe su connessioni Cloud VPN.
Metodologia
Performance Dashboard esegue i worker sugli host fisici che ospitano le VM. Questi worker inseriscono e ricevono i pacchetti del probe eseguiti sulla stessa rete del tuo traffico. Poiché i worker vengono eseguiti sugli host fisici e non sulle VM, non consumano risorse delle VM e il traffico non è visibile sulle VM.
I probe coprono l'intero mesh di VM che possono comunicare tra loro, che non corrispondono necessariamente al tuo modello di traffico. Di conseguenza, potresti visualizzare indicazioni della perdita di pacchetti in Performance Dashboard, ma nessuna prova della perdita di pacchetti nell'applicazione.
Per tutte le VM sottoposte a probe, Google Cloud tenta di accedere alla VM utilizzando l'indirizzo IP interno e l'indirizzo IP esterno (se esistente). I probe non lasciano 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 i pacchetti TCP.
Disponibilità delle metriche e livelli di confidenza
Performance Dashboard analizza un sottoinsieme di tutte le coppie VM-VM nella rete. I dati raccolti vengono quindi utilizzati per stimare la perdita di pacchetti che potresti sperimentare. L'affidabilità di Google nei dati dipende dalla frequenza di probe, che dipende dal numero di VM che hai in ciascuna zona e dal numero di zone in cui sono state distribuite le VM. Ad esempio, avere 10 VM in due zone genera maggiore sicurezza rispetto a 10 VM in 10 zone.
Tutte le VM, incluse quelle create da Google Kubernetes Engine (GKE), vengono conteggiate nel numero totale di VM.
I diversi livelli di confidenza sono descritti nella tabella seguente. Livelli di affidabilità più bassi sono contrassegnati nella mappa termica con un asterisco (*) o N/A.
| Livello | Numero richiesto di VM in ogni zona | Dati visualizzati nella dashboard delle prestazioni nella mappa termica |
|---|---|---|
| 95% di confidenza | 10 VM moltiplicate per il numero di zone nel progetto. Ad esempio, se il tuo progetto prevede 12 zone, devi avere 120 VM in ogni zona. | Una misurazione senza notazioni aggiuntive |
| 90% di confidenza | 2,5 VM moltiplicate per il numero di zone nel progetto. Ad esempio, se il tuo progetto include 12 zone, devi avere 30 VM in ogni zona. | Una misurazione senza notazioni aggiuntive |
| Scarsa affidabilità | Una misura con un asterisco | |
| Sonde insufficienti per avere dati significativi | N/A |
Le metriche sulla perdita di pacchetti di Google Cloud sono sempre disponibili. Viene visualizzato un asterisco (*) se sono presenti meno di 400 probe al minuto.
Latenza specifica del progetto
Le metriche di latenza vengono misurate utilizzando il traffico dei clienti tra i seguenti:
- VM in 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 in una rete VPC condiviso mostra i dati solo relativi alle zone all'interno del progetto di servizio. Supponiamo che una VM nella zona A e il progetto di servizio A utilizzino il progetto host per comunicare con una VM nella zona B e con il progetto di servizio B. Le misurazioni relative al traffico non sono disponibili né per il progetto di servizio né per il progetto host.
Latenza di Google Cloud
Le metriche di latenza vengono misurate utilizzando il traffico effettivo dei clienti tra quanto segue:
- VM in una singola rete VPC
- VM tra reti VPC in peering
- VM ed endpoint internet
Metodologia per la latenza di progetto e Google Cloud
La latenza viene misurata utilizzando pacchetti TCP.
In base a un campione del 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 contenente il ritardo relativo allo stack RTT di rete e TCP. La dashboard mostra la latenza come mediana di tutte le misurazioni pertinenti.
La metrica di latenza si basa sulla stessa origine dati e sulla stessa metodologia di campionamento dei log di flusso VPC.
La latenza specifica del progetto si basa su esempi del progetto. La latenza di Google Cloud si basa su campioni di Google Cloud.
Le metriche di latenza globale derivano dal campionamento passivo delle intestazioni del traffico TCP e non tramite probe attivi da Google Cloud agli endpoint internet.
Anomalie delle metriche Latenza
Tieni presente le seguenti anomalie delle metriche di latenza:
Per gli ambienti a bassa velocità, Network Intelligence Center utilizza probe di 60 secondi per le metriche di latenza. Pertanto, le metriche RTT basate sul campionamento dei pacchetti potrebbero riportare erroneamente livelli di latenza elevati quando i servizi basati su TCP restituiscono una risposta ritardata a livello di applicazione. Generalmente, puoi riconoscere livelli RTT non accurati controllando se corrispondono a ritardi a livello di applicazione.
Anche se il servizio basato su TCP risponde rapidamente con un
ACK, nel campionamento manca ilACKe conteggia una risposta dati successiva come laACKdi chiusura di un SEND molto precedente, il che distorce la misurazione RTT complessiva. In questi casi, puoi ignorare le metriche RTT.A volte, i dati di latenza specifici del progetto non sono in linea con i dati di latenza globale. 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 di latenza di Google Cloud è sempre disponibile. La metrica di latenza per progetto è disponibile solo se il traffico TCP è di circa 1000 pacchetti al minuto o superiore.
Tabella di riepilogo delle metriche
La seguente tabella riassume i metodi e i protocolli di probe utilizzati per segnalare le metriche di perdita e latenza di pacchetti.
| Perdita pacchetti | Latenza | |
|---|---|---|
| Metodo di probe | Probing attivo (traffico delle VM sintetiche) | Probing passivo (traffico effettivo delle VM) |
| Protocollo | UDP (indirizzo IP interno), TCP (indirizzo IP esterno) | TCP (indirizzi IP interni/esterni) |
Visualizzazioni della latenza
I dettagli sulla latenza per il tipo di traffico Da Internet a Google Cloud sono disponibili in tre visualizzazioni: Tabella, Mappa e Sequenza temporale.
Visualizzazione tabella
La visualizzazione tabella mostra l'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 sulla 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 le regioni di Google Cloud.
- Visualizza la latenza mediana di località e regioni Google Cloud specifiche.
- Seleziona una regione Google Cloud e visualizza le località con traffico verso la regione selezionata.
- Visualizza i dettagli specifici per la località in un grafico di latenza nella barra laterale.
- Cerca un luogo utilizzando la casella di ricerca sulla mappa.
Le località sono valutate per colore con diverse tonalità di blu per indicare gli intervalli di latenza mediana sulla mappa. Nell'immagine seguente, il colore di un cerchio che mostra una data città su una mappa globale può essere di una tonalità di blu. Più scura è la tonalità del blu, maggiore è la latenza della città da una determinata regione Google Cloud.
Visualizzazione Timeline
La visualizzazione Sequenza temporale mostra l'RTT mediano tra le aree geografiche selezionate e le regioni di 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 coppie di località geografica-regione specifiche solo se il traffico Google Cloud è sufficiente per quella coppia.