Cette page décrit les métriques utilisées pour déterminer les performances des ressources de votre projetGoogle Cloud et celles de l'ensemble de Google Cloud. Vous trouverez également des informations sur les différentes vues qui affichent plus de détails sur ces métriques de performances.
Métriques
Performance Dashboard fournit deux types de métriques : la perte de paquets et la latence (délai aller-retour ou DAR). Pour obtenir des métriques concernant la perte de paquets pour votre projetGoogle Cloud , vous avez besoin d'un nombre suffisant de VM dans le projet. Pour obtenir des métriques de latence, vous avez besoin d'une quantité de trafic suffisante. De plus, Performance Dashboard ne nécessite aucune configuration.
Les sections suivantes décrivent plus en détail les deux métriques.
Perte de paquets
Les métriques de perte de paquets indiquent le résultat de la vérification active entre les éléments suivants :
VM au sein d'un même réseau VPC.
Les VM des réseaux VPC appairés lorsqu'un ou les deux réseaux se trouvent dans votre projet. Si les réseaux appairés se trouvent dans des projets différents, la perte de paquets est visible dans le projet de destination.
VM d'un réseau VPC partagé utilisé par votre projet. La perte de paquets entre deux projets utilisant un réseau VPC partagé est visible dans le projet de service de destination.
Par exemple, supposons que le projet A comprend deux réseaux VPC : le réseau A, qui ne possède que des VM dans la zone A et le réseau M, qui contient uniquement des VM dans la zone M. Si ces deux réseaux sont appairés, Performance Dashboard du projet A affiche les données de perte de paquets de la paire de zones A/M. Si les réseaux ne sont pas appairés, Performance Dashboard n'affiche pas la métrique de perte de paquets pour cette paire de zones.
Si ces deux réseaux ne sont pas dans le même projet, notez quand Performance Dashboard de chaque réseau affiche les métriques. Supposons que le réseau A fait partie du projet A et que le réseau M fait partie du projet M. Lorsque les réseaux sont appairés, Performance Dashboard pour le projet M affiche les données de perte de paquets pour les situations où la zone M est la zone de destination. Inversement, lorsque la zone A est la zone de destination, les données de perte de paquets ne sont visibles que dans le projet A. Si les réseaux ne sont pas appairés, Performance Dashboard n'affiche pas les données de perte de paquets pour cette paire de zones.
Les données collectées par toutes les vérifications sont regroupées dans Performance Dashboard. En d'autres termes, Performance Dashboard ne vous permet pas d'isoler des données sur la perte de paquets au sein du projet par rapport à d'autres types (tels que la perte de paquets associée à un réseau VPC appairé dans un autre projet). Toutefois, vous pouvez utiliser Monitoring pour afficher des résultats plus détaillés. Pour en savoir plus, consultez la documentation de référence sur les métriques de Performance Dashboard.
Performance Dashboard n'envoie pas de vérifications via les connexions Cloud VPN.
Méthodologie
Performance Dashboard exécute des nœuds de calcul sur les hôtes physiques qui hébergent vos VM. Ces nœuds de calcul insèrent et reçoivent des paquets de vérification, qui s'exécutent sur le même réseau que votre trafic. Étant donné que les nœuds de calcul s'exécutent sur l'hôte physique et non sur votre VM, ils ne consomment pas de ressources de VM, et le trafic n'est pas visible sur vos VM.
Les vérifications couvrent l'intégralité du maillage des VM pouvant communiquer entre elles, ce qui n'est pas nécessairement le cas pour votre modèle de trafic. Par conséquent, vous pouvez voir des indications de perte de paquets dans Performance Dashboard, mais aucune preuve de perte de paquets dans votre application.
Pour toutes les VM vérifiées, Google Cloud tente d'accéder à la VM en utilisant son adresse IP interne et son adresse IP externe (le cas échéant). Les vérifications ne quittent pas Google Cloud, mais en utilisant des adresses IP externes, Performance Dashboard peut couvrir une partie du chemin utilisé par le trafic externe, tel que le trafic provenant d'Internet.
La perte de paquets pour les adresses IP internes est mesurée à l'aide de paquets UDP, et la perte de paquets pour les adresses IP externes est mesurée à l'aide de paquets TCP.
Disponibilité des métriques et niveaux de confiance
Performance Dashboard vérifie un sous-ensemble de toutes les paires VM-VM du réseau. Les données collectées sont ensuite utilisées pour estimer la perte de paquets que vous pourriez rencontrer. La confiance de Google dans les données dépend du taux de vérification, et celui-ci dépend du nombre de VM présentes dans chaque zone, ainsi que du nombre de zones dans lesquelles vous avez déployé des VM. Par exemple, le fait d'avoir 10 VM dans deux zones génère plus de confiance que 10 VM dans 10 zones.
Toutes les VM, y compris celles créées par Google Kubernetes Engine (GKE), sont comptabilisées dans le nombre total de VM.
Les différents niveaux de confiance sont décrits dans le tableau suivant. Les niveaux de confiance inférieurs sont signalés par un astérisque (*) ou N/A dans la carte de densité.
| Niveau | Nombre de VM requis dans chaque zone | Ce que Performance Dashboard affiche sur la carte de densité |
|---|---|---|
| 95 % de confiance | 10 VM multipliées par le nombre de zones dans le projet. Par exemple, si votre projet comporte 12 zones, vous devez avoir 120 VM par zone. | Une mesure sans notation supplémentaire |
| 90 % de confiance | 2,5 VM multipliées par le nombre de zones dans le projet. Par exemple, si votre projet comporte 12 zones, vous devez avoir 30 VM par zone. | Une mesure sans notation supplémentaire |
| Fiabilité faible | Mesure avec un astérisque | |
| Le nombre de vérifications n'est pas suffisant pour obtenir des données significatives | N/A |
Les métriques de perte de paquets Google Cloud sont toujours disponibles. Un astérisque (*) s'affiche s'il y a moins de 400 vérifications par minute.
Latence spécifique au projet
Les métriques de latence sont mesurées à l'aide du trafic client entre :
- VM au sein d'un même réseau VPC
- VM entre des réseaux VPC appairés, si les réseaux résident dans le même projet
- VM et points de terminaison Internet
En outre, Performance Dashboard pour un projet de service au sein d'un réseau VPC partagé affiche uniquement les données des zones de ce projet. En d'autres termes, supposons qu'une VM se trouve dans la zone A et que le projet de service A utilise le projet hôte pour communiquer avec une VM dans la zone B et le projet de service B. Les mesures sur ce trafic ne sont pas disponibles pour le projet de service ou le projet hôte.
Latence :Google Cloud
Les métriques de latence sont mesurées à l'aide du trafic client réel entre :
- VM au sein d'un même réseau VPC
- VM entre des réseaux VPC appairés
- VM et points de terminaison Internet
Méthodologie pour la latence des projets et de Google Cloud
La latence est mesurée à l'aide de paquets TCP.
Sur la base d'un échantillon de votre trafic réel, la latence correspond au temps qui s'écoule entre l'envoi d'un numéro de séquence TCP (SEQ) et la réception d'un ACK correspondant qui contient le DAR du réseau et le délai lié à la pile TCP.
Étant donné que l'échantillonnage et le comportement des applications influencent le moment où les ACK sont enregistrés, la métrique de latence peut également inclure des retards au niveau de l'application.
Pour en savoir plus, consultez Anomalies des métriques de latence.
Pour savoir comment la latence des applications influence le DAR, consultez A Brief Look at Round-Trip Time.
Le tableau de bord affiche la latence en tant que médiane de toutes les mesures pertinentes.
La métrique de latence est basée sur la même source de données et la même méthodologie d'échantillonnage que les journaux de flux VPC.
La latence spécifique au projet est basée sur des échantillons de votre projet. La latenceGoogle Cloud est basée sur des échantillons de tous les Google Cloud.
Les métriques de latence globale sont dérivées de l'échantillonnage passif des en-têtes de trafic TCP, et non par le biais d'un sondage actif de Google Cloud vers les points de terminaison Internet.
Anomalies des métriques de latence
Notez les anomalies suivantes concernant les métriques de latence :
Pour les environnements à faible débit, Network Intelligence Center utilise des probes de 60 secondes pour les métriques de latence. Par conséquent, les métriques DAR basées sur l'échantillonnage de paquets peuvent signaler à tort des niveaux de latence élevés lorsque les services basés sur TCP renvoient une réponse au niveau de l'application différée. Vous pouvez généralement identifier les niveaux de DAR inexacts en vérifiant s'ils correspondent à des retards au niveau de l'application.
Bien que le service basé sur TCP réponde rapidement avec un
ACK, l'échantillonnage manque leACKet comptabilise une réponse de données ultérieure commeACKde clôture d'un SEND beaucoup plus ancien, ce qui fausse la mesure globale du DAR. Dans ce cas, vérifiez la latence avec une autre source de données (par exemple, un testping). Si elle indique un DAR plus faible, vérifiez la réactivité de votre application.Il arrive que les données de latence spécifiques à un projet ne correspondent pas aux données de latence globales. Ce décalage peut se produire si l'ensemble de données global inclut également d'autres chemins réseau avec des latences très différentes de celles du chemin réseau utilisé par le projet spécifique.
Disponibilité des métriques
La métrique de latence Google Cloud est toujours disponible. La métrique de latence par projet n'est disponible que si le trafic TCP est d'environ 1 000 paquets par minute ou plus.
Tableau récapitulatif des métriques
Le tableau suivant récapitule les méthodes et protocoles de vérification utilisés pour la génération de rapports sur les métriques de perte et de latence.
| Perte de paquets | Latence | |
|---|---|---|
| Méthode de vérification | Vérification active (trafic de VM synthétique) | Vérification passive (trafic de VM réel) |
| Protocol (Protocole) | UDP (adresse IP interne), TCP (adresse IP externe) | TCP (adresses IP internes/externes) |
Vues de latence
Les détails de latence pour le type de trafic Internet vers Google Cloud sont disponibles dans trois vues : Tableau, Carte et Chronologie.
Vue Tableau
La vue Tableau affiche le DAR médian entre les zones géographiques sélectionnées et les régions contenant des instances de VM dans votre projet. Le tableau comprend les informations suivantes :
- Pays : nom du pays.
- Villes : nombre de villes. Vous pouvez afficher les détails de la latence de chaque ville spécifique dans le graphique des détails du pays.
- Régions de destination : nombre de régions de destination avec du trafic pour les utilisateurs d'un pays donné.
- Latence médiane : latence médiane (temps d'aller-retour) en millisecondes entre le pays et les régions.
Plan
La vue Carte affiche les zones géographiques (agglomérations ou villes) et les régionsGoogle Cloud .
- Affichez la latence médiane de régions et d'emplacements spécifiques. Google Cloud
- Sélectionnez une région Google Cloud et affichez les lieux où le trafic est dirigé vers cette région.
- Afficher des informations spécifiques à un lieu dans un graphique de latence dans la barre latérale.
- Recherchez des lieux à l'aide du champ de recherche sur la carte.
Les lieux sont colorés en différentes nuances de bleu pour indiquer les plages de latence médiane sur la carte. Dans l'image suivante, la couleur d'un cercle représentant une ville donnée sur une carte du monde peut être une nuance de bleu. Plus la nuance de bleu est foncée, plus la latence de cette ville par rapport à une région Google Cloud donnée est importante.
Vue chronologique
La vue Chronologie affiche le DAR médian entre les zones géographiques sélectionnées et les régions Google Cloud . Il fournit les métriques de latence actuelles et six semaines de données historiques. Vous pouvez utiliser les filtres pour agréger davantage le trafic au niveau des villes, des régions géographiques et des pays. Vous ne pouvez afficher les métriques de latence correspondant à des paires région-emplacement géographique spécifiques que si le trafic Google Cloud est suffisant pour cette paire.