Auf dieser Seite werden die Messwerte beschrieben, mit denen die Leistung der Ressourcen Ihres Google Cloud-Projekts und die Leistung der gesamten Google Cloud ermittelt werden. Außerdem finden Sie hier Details zu den verschiedenen Ansichten mit weiteren Details zu diesen Leistungsmesswerten.
Messwerte
Das Dashboard zur Leistungsüberwachung bietet zwei Arten von Messwerten: Paketverlustmesswerte und Latenzmesswerte (Umlaufzeit bzw. RTT). Sie benötigen eine ausreichende Anzahl von VMs im Projekt, um Paketverlustmesswerte für Ihr Google Cloud-Projekt zu erhalten. Sie benötigen genügend Traffic, um Latenzmesswerte zu erhalten. Außerdem ist keine Einrichtung des Dashboards zur Leistungsüberwachung erforderlich.
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 eines 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 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 verbunden sind, werden im Dashboards zur Leistungsüberwachung von Projekt A die Paketverlustdaten für das A/M-Zonenpaar angezeigt. Wenn die Netzwerke nicht über Peering verbunden sind, zeigt das Dashboards zur Leistungsüberwachung nicht den Paketverlustmesswert für dieses Zonenpaar an.
Falls sich diese beiden Netzwerke nicht im selben Projekt befinden, prüfen Sie, wann die Messwerte im Dashboards zur Leistungsüberwachung der einzelnen Netzwerke angezeigt werden. Angenommen, Netzwerk A ist Teil von Projekt A und Netzwerk M ist Teil von 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 Prüfungen gesammelten Daten werden im Dashboards zur Leistungsüberwachung zusammengefasst. 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 sich jedoch detailliertere Ergebnisse ansehen. 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 Ihren 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.
Bei allen geprüften VMs versucht Google Cloud, sowohl über die interne als auch über die externe IP-Adresse (falls vorhanden) auf die VM zuzugreifen. Die Prüfungen verlassen Google Cloud nicht. Durch die Verwendung externer IP-Adressen kann das Dashboards zur Leistungsüberwachung jedoch einen Teil des Pfads abdecken, der für externen Traffic verwendet wird, z. B. 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 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 als die Zeit berechnet, die zwischen dem Senden einer TCP-Sequenznummer (SEQ) und dem Empfang einer entsprechenden ACK mit der Netzwerk-RTT und der TCP-Stack-bezogenen Verzögerung verstrichen ist. Das Dashboard zeigt die Latenz als Medianwert aller relevanten Messungen an.
Der Latenzmesswert basiert auf derselben Datenquelle und Stichprobenmethode wie VPC-Flusslogs.
Die projektspezifische Latenz basiert auf Stichproben aus Ihrem Projekt. Die Latenz von Google Cloud basiert auf Stichproben aus Google Cloud.
Die globalen Latenzmesswerte werden aus passiven Stichproben von TCP-Traffic-Headern und nicht durch aktive Prüfungen von Google Cloud zu Internetendpunkten abgeleitet.
Latenzmesswert-Anomalien
Beachten Sie die folgenden Anomalien bei den Latenzmesswerten:
In Umgebungen mit niedrigen Raten verwendet Network Intelligence Center 60-Sekunden-Prüfungen für Latenzmesswerte. Daher können RTT-Messwerte, die auf Paketstichproben basieren, hohe Latenzzeiten fälschlicherweise melden, wenn TCP-basierte Dienste eine verzögerte Antwort auf Anwendungsebene zurückgeben. In der Regel können Sie ungenaue RTT-Werte erkennen, indem Sie prüfen, ob sie mit Verzögerungen auf Anwendungsebene übereinstimmen.
Obwohl der TCP-basierte Dienst schnell mit einem
ACKantwortet, fehlt beim Sampling derACKund zählt eine spätere Datenantwort als schließendeACKfür einen viel früheren SEND, was die gesamte RTT-Messung verfälscht. In diesen Fällen können Sie die RTT-Messwerte ignorieren.Manchmal stimmen die projektspezifischen Latenzdaten nicht mit den globalen Latenzdaten überein. Solche Fehlausrichtungen können auftreten, wenn das globale Dataset auch andere Netzwerkpfade mit erheblich anderen Latenzen im Verhältnis zum Netzwerkpfad enthält, der vom jeweiligen Projekt verwendet wird.
Messwertverfügbarkeit
Der Latenzmesswert von Google Cloud ist immer verfügbar. Der Latenzmesswert pro Projekt ist nur bei TCP-Traffic von etwa 1.000 Paketen pro Minute oder mehr verfügbar.
Ü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: Tabellenansicht, Kartenansicht und Zeitachse.
Tabellenansicht
Die Ansicht Tabelle zeigt 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. Die Latenzdetails der einzelnen Städte finden Sie in der Grafik mit den Länderdetails.
- Zielregionen: Die Anzahl der Zielregionen mit Traffic für Nutzer aus einem bestimmten Land.
- Medianlatenz: Der Medianwert für die RTT zwischen dem Land und der Region in Millisekunden.
Kartenansicht
Die Kartenansicht zeigt die geografischen Standorte (Großräume oder Städte) und Google Cloud-Regionen an.
- Sehen Sie sich die Medianlatenz bestimmter Standorte und Google Cloud-Regionen an.
- Wählen Sie eine Google Cloud-Region aus und sehen Sie sich die Standorte mit Traffic zur ausgewählten Region an.
- 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 farblich abgestuft, um die Bereiche der Medianwerte für die Latenz auf der Karte anzugeben. In der folgenden Abbildung kann die Farbe eines Kreises, der eine bestimmte Stadt auf einer Weltkarte darstellt, einen Blauton haben. Je dunkler der Blauton, desto größer ist die Latenz dieser Stadt aus einer bestimmten Google Cloud-Region.
Zeitachsenansicht
Die Zeitachse zeigt den RTT-Medianwert zwischen den ausgewählten geografischen Gebieten und Google Cloud-Regionen. Er liefert die aktuellen Latenzmesswerte und Verlaufsdaten für sechs Wochen. Sie können die Filter verwenden, um den Traffic auf Stadt-, geografische Region- und Länderebene weiter zu aggregieren. Sie können die Latenzmesswerte für bestimmte Region/geografische Standort-Paare nur dann ansehen, wenn genügend Google Cloud-Traffic für dieses Paar vorhanden ist.