Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Cas d'utilisation : Résoudre les problèmes de connectivité réseau
Dans ce cas d'utilisation, vous êtes un administrateur réseau chargé de gérer un réseau comprenant plusieurs applications à équilibrage de charge. Vous avez été alerté d'un problème de latence. Selon les informations dont vous disposez, l'application mobile de votre organisation est ralentie par intermittence et dépasse le délai d'attente. Vous savez qu'un certain nombre d'utilisateurs différents sont affectés et qu'il n'y a eu aucun déploiement d'application récent. Le problème est probablement lié à un changement dans l'environnement et non à l'application.
Le cas d'utilisation suivant montre comment Network Topology peut vous aider à identifier et à résoudre rapidement les problèmes de votre déploiement.
Détails de la topologie
Le déploiement s'étend sur trois régions Google Cloud (us-central1, europe-west1 et asia-east1). Toutes les requêtes client externes sont traitées par un seul équilibreur de charge d'application externe disposant de plusieurs backends dans chacune des trois régions. Les requêtes des clients provenant de l'une des trois régions commerciales (Amériques, EMEA et APAC) sont traitées par des instances d'application dans la régionGoogle Cloud la plus proche.
La topologie suivante montre la hiérarchie de premier niveau du déploiement:
Exemple de topologie Network Topology (cliquez pour agrandir)
Latence du réseau
Dans ce scénario, nous supposons que vous disposez d'un équilibreur de charge nommé shopping-site-lb.
Vous vérifiez la latence entre les clients externes et l'équilibreur de charge pour voir si la latence entre eux a changé. Selon vos observations, c'est bien ce qui s'est produit et décidez d'examiner plus en détail les backends de l'équilibreur de charge.
Vous filtrez la topologie pour n'afficher que le trafic de votre équilibreur de charge externe shopping-site-lb.
Après avoir appliqué le filtre, Network Topology n'affiche que les connexions liées à l'équilibreur de charge, comme illustré dans l'exemple suivant.
Filtre pour un équilibreur de charge (cliquez pour agrandir)
En commençant par les clients externes dans la région Amériques, vous cliquez sur les métriques de trafic entre la région commerciale Amériques et l'équilibreur de charge.
Network Topology affiche des graphiques dans le volet Détails. Les informations incluent le trafic entrant et sortant entre votre entité sélectionnée et l'entité associée. Par exemple, Network Topology fournit les dernières valeurs de requêtes par seconde (QPS) et de latence de la requête HTTP.
Dans le graphique de latence de la requête, vous voyez les valeurs des 50e, 95e et 99e centiles. Dans cet exemple, imaginons que toutes les valeurs de latence sont plus élevées que prévu.
Pour développer les graphiques de séries temporelles sur six semaines, en haut du volet "Détails", sélectionnez 6 semaines.
Développement du graphique1 (cliquez pour agrandir)
1 La figure est fournie à titre indicatif. Les données ne reflètent pas le cas d'utilisation.
Vous voyez un bond important qui s'est produit il y a environ deux heures, à peu près lorsque les premiers problèmes ont été signalés. Vous êtes convaincu que le problème est lié à une latence accrue avec l'équilibreur de charge.
Pour obtenir une vue d'ensemble du problème, étudiez l'équilibreur de charge davantage en accédant à la page Équilibrage de charge dans la console Google Cloud . Vous constatez finalement qu'une instance du service de backend de l'équilibreur de charge mettait plus de temps que la normale à répondre. Vous mettez cette instance hors service, ce qui résout le problème.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/08 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/08 (UTC)."],[],[],null,["# Use case: Troubleshoot network connectivity\n===========================================\n\nIn this use case, you're a network administrator supporting a network that\nincludes several load-balanced applications. You've been alerted of a latency\nproblem and have been told that your organization's mobile application is\nintermittently slow and timing out. You know that a number of different users\nare affected, and that there have been no recent application deployments. The\nissue is likely related to a change in the environment and not the application.\n\nThe following use case demonstrates how Network Topology can help you\nquickly troubleshoot and investigate issues in your deployment.\n\nTopology details\n----------------\n\nThe deployment spans three Google Cloud regions (`us-central1`,\n`europe-west1`, and `asia-east1`). All external client requests are served by a\nsingle external Application Load Balancer that has multiple backends in each of the three\nregions. Client requests that come from one of three business regions (Americas,\nEMEA, and APAC) are served by application instances in the closest\nGoogle Cloud region.\n\nThe following topology shows the top-level hierarchy for the deployment:\n[](/static/network-intelligence-center/docs/network-topology/images/use-cases/auditing-topology.png) Network Topology example topology (click to enlarge)\n\nNetwork latency\n---------------\n\nIn this scenario, assume that you have a load balancer named `shopping-site-lb`.\nYou check the latency between external clients and the load balancer to see if\nthe latency between them has changed. You discover that it has and decide to\nfurther investigate the load balancer's backends.\n\n1. You filter the topology to show only the traffic for your external load balancer\n `shopping-site-lb`.\n\n After you apply the filter, Network Topology shows only the\n connections related to the load balancer, as shown in the following example.\n [](/static/network-intelligence-center/docs/network-topology/images/use-cases/auditing-filter.png) Filter for a load balancer (click to enlarge)\n2. Starting with the external clients in Americas, you click the traffic metrics\n between the Americas business region and the load balancer.\n\n Network Topology shows charts in the details pane. The\n information includes ingress and egress traffic between your selected\n entity and the connected entity. For example, Network Topology\n provides the latest values for queries per second (QPS) and the HTTP request\n latency.\n\n In the request latency chart, you see values for the 50th, 95th, and 99th\n percentiles. In this example, assume that all of the latency values are\n higher than you expected.\n3. To expand the time series charts to 6 weeks, at the top of the details pane, you select\n **6 weeks**.\n\n [](/static/network-intelligence-center/docs/network-topology/images/use-cases/troubleshooting-zoom.png) Expanding the chart^1^ (click to enlarge) \n\n ^1^The figure is for reference. Its data doesn't reflect the use\n case.\n\n You see a significant jump that happened about two hours ago, roughly when\n the first issues were reported. You're confident that the issue is related\n to increased latency with the load balancer.\n4. Having a high-level view of the issue, you investigate the load balancer\n further by going to the **Load balancing** page in the Google Cloud console. You\n eventually find that an instance in the load balancer's backend service was\n taking longer than normal to respond. You take that instance out of service,\n which resolves the issue.\n\nWhat's next\n-----------\n\n- [Monitor your networking configuration with Network Topology](/network-intelligence-center/docs/network-topology/how-to/audit-troubleshoot-networking-issues)\n- [Use case: Audit network performance](/network-intelligence-center/docs/network-topology/concepts/auditing-network-performance)\n- [Troubleshoot Network Topology](/network-intelligence-center/docs/network-topology/support/troubleshooting)"]]