Auf dieser Seite werden die Messwerte beschrieben, mit denen die Leistung der Ressourcen Ihres Projekts inGoogle Cloud und die Leistung der gesamten Google Cloudbestimmt werden. Außerdem finden Sie hier Details zu den verschiedenen Ansichten, die weitere Informationen zu diesen Leistungsmesswerten enthalten.
Messwerte
Das Dashboard zur Leistungsüberwachung bietet zwei Arten von Messwerten: Paketverlustmesswerte und Latenzmesswerte (Umlaufzeit bzw. RTT). Um Paketverlustmesswerte für Ihr Projekt inGoogle Cloud zu erhalten, muss das Projekt eine ausreichende Anzahl an VMs enthalten. Um Latenzmesswerte zu erhalten, muss ein ausreichendes Volumen an Traffic vorhanden sein. Darüber hinaus ist für das Dashboard zur Leistungsüberwachung keine Einrichtung erforderlich.
In den folgenden Abschnitten werden beide Messwerte ausführlicher beschrieben.
Paketverlust
Paketverlustmesswerte 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. Wenn sich die Peering-Netzwerke in verschiedenen Projekten befinden, ist der Paketverlust im Zielprojekt sichtbar.
VMs in einem gemeinsam genutzten VPC-Netzwerk, das von Ihrem Projekt verwendet wird. Der Paketverlust zwischen zwei Projekten, die ein gemeinsam genutztes 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, wird im Dashboard zur Leistungsüberwachung kein Paketverlustmesswert für dieses Zonenpaar angezeigt.
Wenn sich diese beiden Netzwerke nicht im selben Projekt befinden, sollten Sie wissen, wann die Messwerte im Dashboard zur Leistungsüberwachung der Netzwerke angezeigt werden. Angenommen, Netzwerk A gehört zu Projekt A und Netzwerk M 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 in Projekt A sichtbar. Wenn die Netzwerke nicht über Peering verbunden sind, werden in keinem der beiden Projekt-Dashboards zur Leistungsüberwachung Daten zum Paketverlust für das Zonenpaar angezeigt.
Die bei allen Prüfungen erhobenen Daten werden im Dashboard zur Leistungsüberwachung aggregiert. Mit dem Dashboard zur Leistungsüberwachung können Daten zum projektinternen Paketverlust also nicht im Vergleich zu anderen Typen isoliert werden (z. B. Paketverluste im Zusammenhang mit einem Peering-VPC-Netzwerk in einem anderen Projekt). Mit dem Tool „Monitoring“ können Sie jedoch detailliertere Ergebnisse aufrufen. Weitere Informationen finden Sie in der Referenz zu Messwerten der Dashboards zur Leistungsüberwachung.
Das Dashboard zur Leistungsüberwachung sendet keine Prüfungen über Cloud VPN-Verbindungen.
Methodik
Im Dashboard zur Leistungsüberwachung werden Worker auf den physischen Hosts ausgeführt, auf denen sich Ihre VMs befinden. Diese Worker senden und empfangen Prüfpakete über das Netzwerk, über das auch Ihr Traffic läuft. 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 Traffic-Muster. Daher können im Dashboard zur Leistungsüberwachung Anzeichen für Paketverluste zu sehen sein, während es in Ihrer Anwendung keine Hinweise auf Paketverlust gibt.
Google Cloud versucht bei allen geprüften VMs, sowohl über die interne als auch die externe IP-Adresse (sofern vorhanden) auf die VM zuzugreifen. Die Prüfungen verlassen Google Cloudnicht. Durch die Verwendung externer IP-Adressen kann das Dashboard zur Leistungsüberwachung jedoch einen Teil des Pfads abdecken, der von externem Traffic verwendet wird, beispielsweise von Traffic 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 Konfidenzniveau
Das Dashboard zur Leistungsüberwachung prüft einen Teil aller VM-VM-Paare im Netzwerk. Mit den erfassten Daten wird dann der Paketverlust abgeschätzt, der bei Ihnen möglicherweise auftritt. Die Konfidenz von Google bezüglich der Daten hängt von der Prüfungsrate ab. Die 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 10 VMs in 2 Zonen haben, ist die Konfidenz höher als bei 10 VMs in 10 Zonen.
Alle VMs, auch die von der Google Kubernetes Engine (GKE) erstellten, werden auf die Gesamtzahl der VMs angerechnet.
In der folgenden Tabelle werden die unterschiedlichen Konfidenzniveaus beschrieben. Niedrigere Konfidenzniveaus werden in der Heatmap mit einem Sternchen (*) oder N/A gekennzeichnet.
| Level | Erforderliche Anzahl von VMs in jeder Zone | Anzeige des Dashboards 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. | Messwert ohne zusätzliche Hinweise |
| 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. | Messwert ohne zusätzliche Hinweise |
| Geringe Konfidenz | Messwert mit einem Sternchen | |
| Nicht genügend Prüfungen für aussagekräftige Daten | N/A |
Die Paketverlustmesswerte für Google Cloud sind immer verfügbar. Ein Sternchen (*) wird bei weniger als 400 Prüfungen pro Minute angezeigt.
Projektspezifische Latenz
Latenzmesswerte werden anhand des Kunden-Traffics 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 Internet-Endpunkte
Darüber hinaus zeigt das Dashboard zur Leistungsüberwachung für ein Dienstprojekt in einem gemeinsam genutzten VPC-Netzwerk nur Daten für die Zonen innerhalb des Dienstprojekts an. Angenommen, eine VM in Zone A und das Dienstprojekt A verwenden das Hostprojekt zur Kommunikation mit einer VM in Zone B und dem Dienstprojekt B. Messwerte zu diesem Traffic sind weder im Dienstprojekt noch im Hostprojekt verfügbar.
Latenz inGoogle Cloud
Latenzmesswerte werden anhand des tatsächlichen Kunden-Traffics zwischen folgenden Elementen gemessen:
- VMs in einem einzelnen VPC-Netzwerk
- VMs zwischen Peering-VPC-Netzwerken
- VMs und Internet-Endpunkte
Methodik für die Latenz in Projekten und in Google Cloud
Die Latenz wird mithilfe von TCP-Paketen gemessen.
Basierend auf einer Stichprobe des tatsächlichen Traffics wird die Latenz als der Zeitraum zwischen dem Senden einer TCP-Sequenznummer (SQE) und dem Empfang einer entsprechenden ACK berechnet, der auch die Netzwerk-RTT- und TCP-Stack-Verzögerung umfasst. Im Dashboard wird die Latenz als Medianwert aller relevanten Messungen angezeigt.
Der Latenzmesswert basiert auf derselben Datenquelle und Stichprobenmethodik wie VPC-Flusslogs.
Die projektspezifische Latenz basiert auf Stichproben aus Ihrem Projekt. Die fürGoogle Cloud spezifische Latenz basiert auf Stichproben aus der gesamten Google Cloud.
Die globalen Latenzmesswerte werden aus der passiven Stichprobenerhebung von TCP-Traffic-Headern abgeleitet und nicht durch aktive Prüfung von Google Cloud zu Internetendpunkten.
Anomalien bei Latenzmesswerten
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 kann es bei RTT-Messwerten, die auf Paketstichproben basieren, fälschlicherweise zu Meldungen hoher Latenzzeiten kommen, wenn die Antwort von TCP-basierten Diensten auf Anwendungsebene verzögert ist. Ungenaue RTT-Werte lassen sich in der Regel daran erkennen, dass sie mit Verzögerungen auf Anwendungsebene übereinstimmen.
Obwohl der TCP-basierte Dienst schnell mit einem
ACKantwortet, wird dasACKbei der Stichprobenerhebung nicht berücksichtigt und eine spätere Datenantwort wird als das schließendeACKfür eine viel frühere SEND-Anfrage gezählt, was die gesamte RTT-Messung verzerrt. In diesen Fällen können Sie die RTT-Messwerte ignorieren.Manchmal stimmen die projektspezifischen Latenzdaten nicht mit den globalen Latenzdaten überein. Eine solche Abweichung kann auftreten, wenn das globale Dataset auch andere Netzwerkpfade mit deutlich unterschiedlichen Latenzen im Vergleich zum Netzwerkpfad des jeweiligen Projekts enthält.
Messwertverfügbarkeit
Der Latenzmesswert für 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 mehr umfasst.
Übersichtstabelle der Messwerte
In der folgenden Tabelle sind die Prüfungsmethoden und Protokolle zusammengefasst, die zum Melden von Paketverlust 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 Traffic-Typ Internet zu Google Cloud sind in drei Ansichten verfügbar: Tabelle, Karte und Zeitachse.
Tabellenansicht
In der Ansicht Tabelle wird der RTT-Medianwert zwischen den ausgewählten geografischen Gebieten und den Regionen mit VM-Instanzen in Ihrem Projekt angezeigt. Die Tabelle enthält die folgenden Details:
- Land: Name des Landes
- Städte: Anzahl der Städte. Sie können die Latenzdetails für jede Stadt im Diagramm mit den Länderdetails ansehen.
- Zielregionen: Anzahl der Zielregionen mit Traffic für Nutzer aus einem bestimmten Land
- Medianlatenz: RTT-Medianwert zwischen dem Land und den Regionen in Millisekunden
Kartenansicht
In der Ansicht Karte werden die geografischen Standorte (Großräume oder Städte) und Regionen vonGoogle Cloud angezeigt.
- Sie können sich den Medianwert für die Latenz bestimmter Standorte sowie Regionen von Google Cloudansehen.
- Sie können eine Region von Google Cloud auswählen und sich die Standorte mit Traffic zur ausgewählten Region ansehen.
- Sie können sich standortspezifische Details in einem Latenzdiagramm in der Seitenleiste ansehen.
- Sie können mithilfe des Suchfeldes auf der Karte nach Standorten suchen.
Standorte werden auf der Karte in verschiedenen Blautönen dargestellt, die für verschiedene Medianwertbereiche stehen. Gemäß der folgenden Abbildung kann die Farbe eines Kreises, der eine bestimmte Stadt auf einer globalen Karte darstellt, einen bestimmten Blauton haben. Je dunkler der Blauton, desto höher die Latenz von einer bestimmten Region von Google Cloud aus zu dieser Stadt.
Zeitachsenansicht
In der Ansicht Zeitachse wird der RTT-Medianwert zwischen den ausgewählten geografischen Gebieten und Regionen von Google Cloud angezeigt. Die Ansicht enthält die aktuellen Latenzmesswerte und Verlaufsdaten über sechs Wochen. Mit den Filtern können Sie den Traffic auf Ebene von Städten, Regionen und Ländern weiter aggregieren. Sie können die Latenzmesswerte für bestimmte Regions-/Standortpaare nur ansehen, wenn für dieses Paar genügend Traffic in Google Cloud vorhanden ist.