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 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 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 ist für das Dashboards zur Leistungsüberwachung keine Einrichtung 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 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 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 Dashboards zur Leistungsüberwachung von Projekt A Paketverlustdaten für das A/M-Zonenpaar angezeigt. Wenn die Netzwerke nicht per Peering verbunden sind, wird Dashboards zur Leistungsüberwachung der Messwert „Paketverlust“ für dieses Zonenpaar nicht angezeigt.
Wenn sich diese beiden Netzwerke nicht im selben Projekt befinden, notieren Sie sich, wann die Messwerte im Dashboards 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 bei allen Prüfungen erhobenen 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 jedoch detailliertere Ergebnisse abrufen. Weitere Informationen finden Sie in der Referenz zu Messwerten im Dashboard 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 bleiben auf Google Cloud. Durch die Verwendung externer IP-Adressen kann das Dashboards 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 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 der Zeitraum zwischen dem Senden einer TCP-Sequenznummer (SEQ) und dem Empfang einer entsprechenden ACK berechnet, die die Netzwerk-RTT- und TCP-Stack-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 Samples aus Ihrem Projekt. Die Google Cloud-Latenz basiert auf Stichproben aus der gesamten Google Cloud.
Die globalen Latenzmesswerte werden durch passive Stichprobenerhebungen von TCP-Traffic-Headern und nicht durch aktives Probieren von Google Cloud zu Internetendpunkten ermittelt.
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 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. Sie können in der Regel 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, wird dieser bei der Stichprobenerhebung übersehen und eine spätere Datenantwort wird als schließendesACKfür eine viel frühere SEND-Anfrage gezählt, was die Gesamtmessung der RTT verzerrt.ACKIn 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 der globale Datensatz auch andere Netzwerkpfade mit deutlich unterschiedlichen Latenzen im Vergleich zum 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 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:
- Country: Der Name des Landes.
- Städte: Die Anzahl der Städte. Die Latenzdetails für jede Stadt finden Sie im Diagramm mit den Länderdetails.
- Zielregionen: Die Anzahl der Zielregionen mit Traffic für Nutzer aus einem bestimmten Land.
- Medianlatenz: Der Medianwert der RTT in Millisekunden zwischen dem Land und den Regionen.
Kartenansicht
In der Ansicht Karte sind die geografischen Standorte (Großräume oder Städte) und Google Cloud-Regionen zu sehen.
- Medianlatenz für bestimmte Standorte und Google Cloud-Regionen ansehen
- Wählen Sie eine Google Cloud-Region aus und sehen Sie sich die Standorte mit Traffic zur ausgewählten Region an.
- In der Seitenleiste können Sie sich in einem Latenzdiagramm standortspezifische Details ansehen.
- Mit dem Suchfeld auf der Karte können Sie nach Orten suchen.
Die Standorte sind in verschiedenen Blautönen dargestellt, um die Spannweite der Medianlatenz auf der Karte anzugeben. Auf der folgenden Abbildung kann die Farbe eines Kreises, der eine bestimmte Stadt auf einer globalen Karte darstellt, eine Blauschattierung sein. Je dunkler der Blauton, desto höher ist die Latenz dieser Stadt von einer bestimmten Google Cloud-Region aus.
Zeitachsenansicht
In der Ansicht Zeitachse sehen Sie den RTT-Medianwert zwischen den ausgewählten geografischen Gebieten und Google Cloud-Regionen. Es bietet aktuelle Latenzmesswerte und Verlaufsdaten über sechs Wochen. Mit den Filtern können Sie die Zugriffe auf Stadt-, Regions- und Länderebene weiter zusammenfassen. Sie können die Latenzmesswerte für bestimmte Regions-/Standortpaare nur aufrufen, wenn für dieses Paar genügend Google Cloud-Traffic vorhanden ist.