In questa pagina vengono descritte le metriche utilizzate per determinare il rendimento dei tuoi le risorse del progetto Google Cloud e le prestazioni dell'intero Google Cloud. Tu puoi trovare dettagli sulle varie visualizzazioni che mostrano ulteriori dettagli queste metriche sul rendimento.
Metriche
Performance Dashboard offre due tipi di metriche: perdita di pacchetti e latenza (tempo di round trip o RTT). Per ottenere le metriche di perdita di pacchetti devi avere un numero sufficiente di VM nel progetto Google Cloud. A per ottenere metriche di latenza, ti serve una quantità sufficiente di traffico. Inoltre, Performance Dashboard non richiede alcuna configurazione.
Nelle sezioni seguenti vengono descritte entrambe le metriche in modo più dettagliato.
Perdita pacchetti
Le metriche relative alla perdita di pacchetti mostrano i risultati di un probe attivo tra i seguenti:
all'interno di una singola rete VPC.
VM nelle reti VPC in peering, quando una o entrambe le reti sono all'interno del progetto. Se le reti in peering sono in progetti diversi, di perdita di pacchetti è visibile nel progetto di destinazione.
VM in una rete VPC condiviso utilizzata dal tuo progetto. Pacchetto la perdita tra due progetti che utilizzano una rete VPC condiviso è visibile nel progetto di servizio di destinazione.
Supponiamo, ad esempio, che il progetto A includa due reti VPC: A, che ha VM solo nella zona A, e la rete M, che ha VM solo nella zona M. Se queste due reti sono in peering, Performance Dashboard del progetto A mostra i dati di perdita di pacchetti per la coppia di zone A/M. Se le reti non sono connesse in peering, Performance Dashboard non mostra la metrica di perdita di pacchetti per quella zona .
Se queste due reti non si trovano nello stesso progetto, nota quando Performance Dashboard di ciascuna rete mostra le metriche. Vale a dire che supponiamo che la rete A faccia parte del progetto A e la rete M sia parte del progetto M. Quando le reti sono connesse in peering, Performance Dashboard 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 destinazione i dati relativi alla perdita di pacchetti sono visibili solo al progetto A. Se le reti non sono in peering, né Performance Dashboard del progetto mostra di perdita di dati per la coppia di zone.
I dati raccolti attraverso tutti i probe vengono aggregati in Performance Dashboard. Performance Dashboard non consente puoi isolare i dati relativi alla perdita di pacchetti all'interno del progetto rispetto ad altri (come la perdita di pacchetti relativa a una rete VPC in peering in un altro progetto). Tuttavia, puoi utilizzare Monitoring per visualizzare risultati dettagliati. Per ulteriori informazioni, vedi Informazioni sulle metriche di Performance Dashboard.
Performance Dashboard non invia probe e le connessioni Cloud VPN.
Metodologia
Performance Dashboard esegue i lavoratori sugli host fisici che ospitano i tuoi delle VM in esecuzione. Questi worker inseriscono e ricevono pacchetti di probe in esecuzione sulla stessa rete come traffico. Poiché i lavoratori vengono eseguiti sugli host fisici e non sui tuoi VM, questi worker non consumano risorse VM e il traffico non è visibile sulle tue VM.
I probe coprono l'intera rete mesh di VM che possono comunicare tra loro, che non corrisponde necessariamente al tuo modello di traffico. Pertanto, potresti indicazioni della perdita di pacchetti in Performance Dashboard, ma non ci sono prove e la perdita di pacchetti nella tua applicazione.
Per tutte le VM sottoposte a probe, Google Cloud tenta di accedere alla VM sia utilizzando il suo indirizzo IP interno e indirizzo IP esterno (se esistente). I probe non esce da Google Cloud, ma utilizzando indirizzi IP esterni Performance Dashboard può coprire parte del percorso utilizzato da un ad esempio quelle provenienti da internet.
La perdita di pacchetti per gli indirizzi IP interni viene misurata utilizzando pacchetti UDP e la perdita di pacchetti per gli indirizzi IP esterni viene misurata utilizzando pacchetti TCP.
Disponibilità delle metriche e livelli di confidenza
Performance Dashboard rileva un sottoinsieme di tutte le coppie VM-VM nella rete. I dati raccolti vengono quindi utilizzati per stimare la perdita di pacchetti che potresti un'esperienza senza intervento manuale. L'affidabilità di Google nei dati dipende dalla percentuale di probe e dipende dal numero di VM presenti in ogni zona, nonché il numero di zone in cui è stato eseguito il deployment delle VM. Ad esempio, avere 10 VM due zone generano più affidabilità rispetto ad avere 10 VM in 10 zone.
Tutte le VM, incluse quelle create da Google Kubernetes Engine (GKE), vengono conteggiate ai fini del calcolo il numero totale di VM.
I diversi livelli di affidabilità sono descritti nella tabella seguente. Valore minimo
i livelli di affidabilità sono indicati nella mappa termica con un asterisco
(*) o N/A.
| Livello | Numero richiesto di VM in ciascuna zona | Dati mostrati da Performance Dashboard sulla mappa termica |
|---|---|---|
| 95% di confidenza | 10 VM moltiplicate per il numero di zone nel progetto. Ad esempio, se disponi 12 zone nel progetto, ogni zona deve avere 120 VM. | Una misurazione senza notazioni aggiuntive |
| 90% di confidenza | 2,5 VM moltiplicate per il numero di zone nel progetto. Ad esempio, se disponi 12 zone nel progetto, devi avere 30 VM in ciascuna zona. | Una misurazione senza notazioni aggiuntive |
| Scarsa affidabilità | Una misura con un asterisco | |
| Insufficienti probe per avere dati significativi | N/A |
Le metriche di perdita di pacchetti di Google Cloud sono sempre disponibili. Un asterisco Il simbolo (*) viene visualizzato se ci sono meno di 400 probe al minuto.
Latenza specifica del progetto
Le metriche sulla latenza vengono misurate utilizzando il traffico dei clienti tra seguenti:
- VM all'interno di una singola rete VPC
- VM tra reti VPC in peering, se le reti si trovano stesso progetto
- VM ed endpoint internet
Inoltre, Performance Dashboard per un progetto di servizio La rete VPC condiviso mostra i dati solo per le zone all'interno della progetto di servizio. Supponiamo che una VM nella zona A e il progetto di servizio A utilizzi per comunicare con una VM nella zona B e nel progetto di servizio B. Le misurazioni relative al traffico non sono disponibili per il progetto di servizio o del progetto host.
Latenza di Google Cloud
Le metriche sulla latenza vengono misurate utilizzando il traffico effettivo dei clienti tra seguenti:
- 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 di Google Cloud
La latenza viene misurata mediante l'uso di pacchetti TCP.
In base a un campione del tuo traffico effettivo, la latenza viene calcolata come il tempo in cui
tra l'invio di un numero di sequenza TCP (SEQ) e la ricezione
ACK corrispondente che contiene il ritardo relativo allo stack RTT di rete e TCP. La
mostra la latenza come mediana di tutte le misurazioni pertinenti.
La metrica relativa alla latenza si basa sulla stessa origine dati e sulla stessa metodologia di campionamento Log di flusso VPC.
La latenza specifica del progetto si basa su campioni del tuo progetto. La La latenza di Google Cloud si basa su campioni provenienti da tutto Google Cloud.
Le metriche di latenza globali derivano da un campionamento passivo del traffico TCP intestazioni e non tramite probe attivi da Google Cloud a internet endpoint.
Anomalie delle metriche di latenza
Nota le seguenti anomalie nelle metriche di latenza:
Per ambienti a basso costo, Network Intelligence Center utilizza una durata 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 un ritardo a livello di applicazione. Di solito è possibile riconoscere un RTT impreciso livelli controllando se corrispondono a ritardi a livello di applicazione.
Sebbene il servizio basato su TCP risponda rapidamente con un
ACK, il campionamento non rilevaACKe conteggia una risposta dati successiva comeACKdi chiusura a un molto prima di SEND, 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 le i dati sulla latenza. Un tale disallineamento può verificarsi se anche il set di dati globale incorpora altri percorsi di rete con latenze significativamente diverse rispetto al percorso di rete usato dal progetto specifico.
Disponibilità delle metriche
La metrica di latenza di Google Cloud è sempre disponibile. Per progetto è disponibile solo se il traffico TCP è di circa 1000 pacchetti per minuto o più.
Tabella di riepilogo delle metriche
La tabella seguente riassume i metodi e i protocolli di indagine utilizzati per i report sulle metriche di perdita di pacchetti e latenza.
| Perdita pacchetti | Latenza | |
|---|---|---|
| Metodo di probe | Probing attivo (traffico VM sintetico) | Probing passivo (traffico VM effettivo) |
| Protocollo | UDP (indirizzo IP interno), TCP (indirizzo IP esterno) | TCP (indirizzi IP interni/esterni) |
Visualizzazioni latenza
I dettagli della latenza per il tipo di traffico Da Internet a 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 il 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 per una città specifica nel grafico dei dettagli del paese.
- Regioni di destinazione: il numero di regioni di destinazione con traffico per. di utenti di un determinato paese.
- Latenza mediana: l'RTT mediano, in millisecondi, tra il paese e regioni.
Visualizzazione mappa
La visualizzazione Mappa mostra le posizioni geografiche (aree metropolitane o città) e regioni di Google Cloud.
- Visualizza la latenza mediana di località specifiche e di Google Cloud regioni.
- Seleziona una regione Google Cloud e visualizza le località con traffico per la regione selezionata.
- Visualizza i dettagli specifici per località in un grafico della latenza nella barra laterale.
- Cerca un luogo utilizzando la casella di ricerca sulla mappa.
Le posizioni vengono classificate in diverse tonalità di blu per indicare intervalli di latenza mediana sulla mappa. Nell'immagine seguente, il colore un cerchio che mostra una determinata città su una mappa globale può avere una sola tonalità di blu. Più scura è la tonalità di blu, maggiore è la latenza della città da in una determinata regione Google Cloud.
Visualizzazione Timeline
La visualizzazione Sequenza temporale mostra il valore RTT mediano tra le aree geografiche selezionate. Google Cloud e Google Cloud. Fornisce le metriche di latenza attuali e sei settimane di dati storici. Puoi utilizzare i filtri per aggregare ulteriormente i dati traffico a livello di città, regione geografica e paese. Puoi visualizzare solo metriche di latenza corrispondenti a specifiche coppie regione-località geografica, se c'è sufficiente per la coppia.