Auf dieser Seite werden die Messwerte beschrieben, mit denen die Leistung der Ressourcen Ihres Google Cloud-Projekts und die Leistung der gesamten Google Cloud bestimmt werden. Ich finden Sie auch Details zu den verschiedenen Ansichten, diese Leistungsmesswerte.
Messwerte
Das Dashboard zur Leistungsüberwachung bietet zwei Arten von Messwerten: Paketverlustmesswerte und Latenzmesswerte (Umlaufzeit bzw. RTT). Um Paketverlustmesswerte für Ihr Google Cloud-Projekt abzurufen, benötigen Sie eine ausreichende Anzahl von VMs im Projekt. Sie benötigen eine ausreichende Menge an Traffic, um Latenzmesswerte zu erhalten. Außerdem Dashboards zur Leistungsüberwachung müssen nicht eingerichtet werden.
In den folgenden Abschnitten werden beide Messwerte ausführlicher beschrieben.
Paketverlust
Die Messwerte für Paketverluste zeigen die Ergebnisse der aktiven Prüfung zwischen folgenden Elementen:
VMs in einem einzelnen VPC-Netzwerk
VMs in Peering-VPC-Netzwerken, wenn sich ein oder beide Netzwerke in Ihrem Projekt befinden. Befinden sich die Peering-Netzwerke in verschiedenen Projekten, Der Paketverlust ist im Zielprojekt sichtbar.
VMs in einem freigegebenen VPC-Netzwerk, die von Ihrem Projekt verwendet werden. Der Paketverlust zwischen zwei Projekten, die ein freigegebenes VPC-Netzwerk verwenden, ist im Zieldienstprojekt sichtbar.
Angenommen, Projekt A enthält zwei VPC-Netzwerke: Netzwerk A mit VMs nur in Zone A und Netzwerk M mit VMs nur in Zone M. Wenn diese beiden Netzwerke über Peering miteinander verbunden sind, werden im Dashboard zur Leistungsüberwachung von Projekt A Paketverlustdaten für das A/M-Zonenpaar angezeigt. Wenn die Netzwerke nicht über Peering verbunden sind, Dashboards zur Leistungsüberwachung wird der Paketverlustmesswert für diese Zone nicht angezeigt Paar zusammen.
Wenn sich diese beiden Netzwerke nicht im selben Projekt befinden, notieren Sie sich, wann die Messwerte im Dashboard zur Leistungsüberwachung der einzelnen Netzwerke angezeigt werden. Das heißt, Netzwerk A gehört zu Projekt A und Netzwerk M gehört zu Projekt M. Bei einem Peering der Netzwerke zeigt das Dashboard zur Leistungsüberwachung des Projekts M Paketverlustdaten in Fällen an, in denen Zone M die Zielzone ist. Umgekehrt gilt: Wenn Zone A die Zielzone ist, sind die Paketverlustdaten nur für Projekt A sichtbar. Wenn die Netzwerke nicht per Peering verbunden sind, werden im Dashboard zur Leistungsüberwachung des Projekts keine Daten zum Paketverlust für das Zonenpaar angezeigt.
Die durch alle Tests gesammelten Daten werden in Dashboards zur Leistungsüberwachung. Das Dashboard zur Leistungsüberwachung erlaubt es Ihnen also nicht, Daten zum produktinternen Paketverlust im Vergleich zu anderen Typen zu isolieren (z. B. Paketverluste im Zusammenhang mit einem Peering-VPC-Netzwerk in einem anderen Projekt). Mit Monitoring können Sie jedoch detailliertere Ergebnisse abrufen. Weitere Informationen finden Sie unter Messwerte zu Dashboards zur Leistungsüberwachung
Das Dashboard zur Leistungsüberwachung sendet keine Prüfungen über Cloud VPN-Verbindungen.
Methoden
Im Dashboard zur Leistungsüberwachung werden Worker auf den physischen Hosts ausgeführt, auf denen sich Ihre VMs befinden. Diese Worker empfangen Prüfpakete, die im selben Netzwerk wie Ihr Traffic ausgeführt werden, und fügen sie ein. Da die Worker auf den physischen Hosts und nicht auf den VMs ausgeführt werden, verbrauchen diese Worker keine VM-Ressourcen und der Traffic ist auf Ihren VMs nicht sichtbar.
Die Prüfungen decken das gesamte Mesh-Netzwerk der VMs ab, die miteinander kommunizieren können. Dies entspricht nicht unbedingt Ihrem Trafficmuster. Daher sind im Dashboard zur Leistungsüberwachung möglicherweise Anzeichen für Paketverluste zu sehen, in Ihrer Anwendung gibt es jedoch keine Hinweise auf Paketverluste.
Google Cloud versucht, bei allen geprüften VMs auf die VM zuzugreifen. Dazu verwendet wird ihre interne IP-Adresse und gegebenenfalls eine externe IP-Adresse. Die Prüfungen Google Cloud verlassen, aber durch die Verwendung von externen IP-Adressen Das Dashboards zur Leistungsüberwachung kann einen Teil des Pfads abdecken, der von externen zum Beispiel aus dem Internet.
Der Paketverlust für interne IP-Adressen wird mithilfe von UDP-Paketen gemessen. Der Paketverlust für externe IP-Adressen wird mithilfe von TCP-Paketen gemessen.
Messwertverfügbarkeit und Konfidenzgrade
Das Dashboard zur Leistungsüberwachung prüft einen Teil aller VM-VM-Paare im Netzwerk. Die erfassten Daten werden dann verwendet, um den Paketverlust abzuschätzen, der bei Ihnen möglicherweise auftritt. Die Konfidenz von Google bezüglich der Daten hängt von der Prüfungsrate ab und diese Prüfungsrate hängt von der Anzahl der VMs in jeder Zone sowie von der Anzahl der Zonen ab, in denen Sie VMs bereitgestellt haben. Wenn Sie beispielsweise zehn VMs in zwei Zonen haben, ist die Konfidenz höher als bei zehn VMs in zehn Zonen.
Alle VMs, auch die von Google Kubernetes Engine (GKE) erstellten, werden auf die Gesamtzahl der VMs angerechnet.
In der folgenden Tabelle werden die unterschiedlichen Konfidenzgrade beschrieben. Niedrigere Konfidenzgrade werden in der Heatmap mit einem Sternchen (*) oder N/A gekennzeichnet.
| Stufe | Erforderliche Anzahl von VMs in den einzelnen Zonen | Das Dashboard zur Leistungsüberwachung auf der Heatmap |
|---|---|---|
| 95 % Konfidenz | 10 VMs multipliziert mit der Anzahl der Zonen im Projekt. Wenn es beispielsweise 12 Zonen in Ihrem Projekt gibt, müssen in jeder Zone 120 VMs vorhanden sein. | Ein Messwert ohne zusätzliche Aussage |
| 90 % Konfidenz | 2,5 VMs multipliziert mit der Anzahl der Zonen im Projekt. Wenn es beispielsweise 12 Zonen in Ihrem Projekt gibt, müssen in jeder Zone 30 VMs vorhanden sein. | Ein Messwert ohne zusätzliche Aussage |
| Geringe Zuverlässigkeit | Ein Messwert mit einem Sternchen | |
| Nicht genügend Prüfungen, um aussagekräftige Daten zu erhalten | N/A |
Die Google Cloud-Paketverlustmesswerte sind immer verfügbar. Ein Sternchen (*) wird angezeigt, wenn weniger als 400 Prüfungen pro Minute vorhanden sind.
Projektspezifische Latenz
Latenzmesswerte werden anhand des Kundentraffics zwischen folgenden Elementen gemessen:
- VMs in einem einzelnen VPC-Netzwerk
- VMs zwischen Peering-VPC-Netzwerken, wenn sich die Netzwerke im selben Projekt befinden
- VMs und Internetendpunkte
Darüber hinaus zeigt das Dashboard zur Leistungsüberwachung für ein Dienstprojekt in einem freigegebenen VPC-Netzwerk nur Daten für die Zonen innerhalb des Dienstprojekts. Angenommen, eine VM in Zone A und das Dienstprojekt A verwenden das Hostprojekt für die Kommunikation mit einer VM in Zone B und dem Dienstprojekt B. Messwerte zu diesem Traffic sind weder für ein Dienstprojekt noch für das Hostprojekt verfügbar.
Google Cloud-Latenz
Latenzmesswerte werden anhand des tatsächlichen Kundentraffics zwischen folgenden Elementen gemessen:
- VMs in einem einzelnen VPC-Netzwerk
- VMs zwischen Peering-VPC-Netzwerken
- VMs und Internetendpunkte
Methoden für die Projekt- und Google Cloud-Latenz
Die Latenz wird mithilfe von TCP-Paketen gemessen.
Basierend auf einer Stichprobe des tatsächlichen Traffics wird die Latenz berechnet als die Zeit,
zwischen dem Senden einer TCP-Sequenznummer (SEQ) und dem Empfang einer
entsprechende ACK, die die Netzwerk-RTT und die TCP-Stack-bezogene Verzögerung enthält. Im Dashboard wird die Latenz als Medianwert aller relevanten Messungen dargestellt.
Der Latenzmesswert basiert auf derselben Datenquelle und Stichprobenmethode wie VPC-Flusslogs.
Die projektspezifische Latenz basiert auf Stichproben aus Ihrem Projekt. Die Die Latenz von Google Cloud basiert auf Stichproben aus Google Cloud.
Die globalen Latenzmesswerte werden durch passive Stichprobenerhebungen von TCP-Traffic-Headern und nicht durch aktives Probieren von Google Cloud zu Internetendpunkten ermittelt.
Latenzmesswert-Anomalien
Beachten Sie die folgenden Anomalien bei Latenzmesswerten:
In Umgebungen mit niedriger Rate verwendet das Network Intelligence Center 60-Sekunden-Prüfungen für Latenzmesswerte. Daher können RTT-Messwerte, die auf der Paketstichprobenerhebung basieren, fälschlicherweise hohe Latenzwerte melden, wenn TCP-basierte Dienste eine verzögerte Antwort auf Anwendungsebene zurückgeben. In der Regel können Sie falsche RTT-Werte überprüfen, indem Sie prüfen, ob sie mit Verzögerungen auf Anwendungsebene übereinstimmen.
Obwohl der TCP-basierte Dienst schnell mit einem
ACKantwortet, wird das Sampling denACKfehlt und zählt eine spätere Datenantwort als schließendeACKfür einen viel früher SEND, wodurch die RTT-Gesamtmessung verzerrt wird. In diesen Fällen können Sie die RTT-Messwerte ignorieren.Manchmal stimmen die projektspezifischen Latenzdaten nicht mit den globalen Latenzdaten. Eine solche Abweichung kann auftreten, wenn der globale Datensatz auch andere Netzwerkpfade mit deutlich unterschiedlichen Latenzen im Vergleich zum Netzwerkpfad des jeweiligen Projekts enthält.
Messwertverfügbarkeit
Der Latenzmesswert von Google Cloud ist immer verfügbar. Der Latenzmesswert pro Projekt ist nur verfügbar, wenn der TCP-Traffic etwa 1.000 Pakete pro Minute oder höher umfasst.
Übersichtstabelle der Messwerte
In der folgenden Tabelle sind die Prüfmethoden und -protokolle zusammengefasst, die zum Melden von Paketverlusten und Latenzmesswerten verwendet werden.
| Paketverlust | Latenz | |
|---|---|---|
| Prüfungsmethode | Aktive Prüfung (synthetischer VM-Traffic) | Passive Prüfung (tatsächlicher VM-Traffic) |
| Protokoll | UDP (interne IP-Adresse), TCP (externe IP-Adresse) | TCP (interne/externe IP-Adressen) |
Latenzansichten
Die Latenzdetails für den Traffictyp Internet zu Google Cloud sind in drei Ansichten verfügbar: Tabelle, Karte und Zeitachse.
Tabellenansicht
In der Ansicht Tabelle sehen Sie den RTT-Medianwert zwischen den ausgewählten geografischen Gebieten und den Regionen, die VM-Instanzen in Ihrem Projekt enthalten. Die Tabelle enthält die folgenden Details:
- Land: Der Name des Landes.
- Städte: Die Anzahl der Städte. Sie können die Latenzdetails der einzelnen Stadt in der Grafik mit den Länderdetails angezeigt.
- Zielregionen: Die Anzahl der Zielregionen mit Traffic für von Nutzern aus einem bestimmten Land.
- Medianlatenz: Der mittlere RTT-Wert in Millisekunden zwischen dem Land und Regionen.
Kartenansicht
Die Kartenansicht zeigt die geografischen Standorte (Großräume oder Städte) und Google Cloud-Regionen.
- Medianlatenz für bestimmte Standorte und Google Cloud-Regionen ansehen
- Google Cloud-Region auswählen und die Standorte mit Traffic ansehen in der ausgewählten Region.
- Standortspezifische Details können Sie sich in einem Latenzdiagramm in der Seitenleiste ansehen.
- Über das Suchfeld auf der Karte können Sie nach Orten suchen.
Die Standorte sind in verschiedenen Blautönen eingefärbt, um die Spannweite der Medianlatenz auf der Karte anzugeben. In der folgenden Abbildung wird die Farbe kann ein Kreis, der eine bestimmte Stadt auf einer Weltkarte zeigt, einen Blauton haben. Je dunkler der Blauton, desto höher ist die Latenz dieser Stadt in einer bestimmten Google Cloud-Region.
Zeitachsenansicht
In der Zeitachse sehen Sie den RTT-Medianwert für die ausgewählten geografischen Regionen. und Google Cloud-Regionen. Es liefert die aktuellen Latenzmesswerte und sechs historischen Daten von mehreren Wochen. Mithilfe der Filter können Sie Traffic auf Stadt-, Regions- und Länderebene. Sie können nur die die spezifischen Paaren aus Region und geografischem Standort entsprechen, falls für dieses Paar ausreichend Google Cloud-Traffic.