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, die weitere Details zu diesen Leistungsmesswerten enthalten.
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 abzurufen. Sie benötigen eine ausreichende Menge an Traffic, um Latenzmesswerte zu erhalten. Außerdem muss das Dashboards zur Leistungsüberwachung 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 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, zeigt das Dashboards zur Leistungsüberwachung von Projekt A die Paketverlustdaten für das A/M-Zonenpaar an. Wenn die Netzwerke nicht per Peering verbunden sind, wird Dashboards zur Leistungsüberwachung nicht der Paketverlustmesswert für dieses Zonenpaar angezeigt.
Wenn sich diese beiden Netzwerke nicht im selben Projekt befinden, geben Sie an, wann die Messwerte im Dashboards zur Leistungsüberwachung der einzelnen Netzwerke angezeigt werden. Das heißt, 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 bei allen Prüfungen erfassten 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). Sie können Monitoring jedoch verwenden, um detailliertere Ergebnisse zu erhalten. Weitere Informationen finden Sie unter Messwertreferenz für 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 sie 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, über die interne IP-Adresse und die externe IP-Adresse (falls vorhanden) auf die VM zuzugreifen. Die Prüfungen verlassen Google Cloud nicht, aber mithilfe externer IP-Adressen kann das Dashboards zur Leistungsüberwachung einen Teil des Pfads abdecken, der von externem 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 von 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 von 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. Im Dashboard wird die Latenz als Medianwert aller relevanten Messungen angezeigt.
Der Latenzmesswert basiert auf derselben Datenquelle und Stichprobenmethode wie VPC-Flusslogs.
Die projektspezifische Latenz basiert auf Stichproben aus Ihrem Projekt. Die Google Cloud-Latenz basiert auf Stichproben aus der gesamten Google Cloud-Umgebung.
Die globalen Latenzmesswerte werden aus passiven Stichproben von TCP-Traffic-Headern abgeleitet und nicht durch aktive Prüfungen von Google Cloud zu Internetendpunkten.
Anomalien mit Latenzmesswerten
Beachten Sie die folgenden Anomalien bei den Latenzmesswerten:
In Umgebungen mit niedrigen Datenraten verwendet Network Intelligence Center 60-Sekunden-Prüfungen für Latenzmesswerte. Daher können RTT-Messwerte, die auf Paketstichproben basieren, fälschlicherweise hohe Latenzwerte melden, wenn TCP-basierte Dienste eine verzögerte Antwort auf Anwendungsebene zurückgeben. Sie können ungenaue RTT-Werte in der Regel erkennen, indem Sie prüfen, ob sie mit Verzögerungen auf Anwendungsebene übereinstimmen.
Obwohl der TCP-basierte Dienst schnell mit einem
ACKantwortet, wird bei der Stichprobe dasACKnicht erfasst und eine spätere Datenantwort wird als schließendeACKauf einen viel früheren SEND-Vorgang gezählt, 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 überein. Solche Abstimmungsprobleme können auftreten, wenn das globale Dataset auch andere Netzwerkpfade mit erheblich unterschiedlichen Latenzen in Bezug auf den vom jeweiligen Projekt verwendeten Netzwerkpfad 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 bei etwa 1.000 Paketen pro Minute oder mehr liegt.
Ü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 Zeitachsenansicht.
Tabellenansicht
Die Ansicht Tabelle zeigt die Median-RTT 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 Städte in der Grafik mit den Länderdetails ansehen.
- Zielregionen: Die Anzahl der Zielregionen mit Traffic für Nutzer aus einem bestimmten Land.
- Medianlatenz: Die Median-RTT zwischen dem Land und den Regionen in Millisekunden.
Kartenansicht
Die Kartenansicht zeigt die geografischen Standorte (Großräume oder Städte) und Google Cloud-Regionen.
- 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 in der ausgewählten Region an.
- Sehen Sie sich standortspezifische Details in einem Latenzdiagramm in der Seitenleiste an.
- Über das Suchfeld auf der Karte können Sie nach Orten suchen.
Standorte werden in verschiedenen Blautönen farblich abgestuft, um die Bereiche der Medianlatenz auf der Karte anzugeben. In der folgenden Abbildung kann ein Kreis, der eine bestimmte Stadt auf einer Weltkarte darstellt, einen Blauton haben. Je dunkler der Blauton, desto größer ist die Latenz dieser Stadt von einer bestimmten Google Cloud-Region aus.
Zeitachsenansicht
Die Zeitachse zeigt die Median-RTT zwischen den ausgewählten geografischen Gebieten und Google Cloud-Regionen. Sie liefert die aktuellen Latenzmesswerte und Verlaufsdaten aus sechs Wochen. Mit den Filtern können Sie den Traffic auf Stadt-, Regions- und Länderebene weiter aggregieren. Sie können die Latenzmesswerte für bestimmte regions-geografische Standortpaare nur dann ansehen, wenn für dieses Paar genügend Google Cloud-Traffic vorhanden ist.