Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Caso de uso: auditar o desempenho da rede
Suponha que você seja um administrador de rede que ofereça suporte a uma rede que inclua vários aplicativos com balanceamento de carga. Você foi solicitado a auditar as configurações de rede que suportam esses aplicativos para garantir que as configurações sejam consistentes com o estado esperado da rede. Ao fazer essa auditoria, você garante que os clientes estejam conseguindo a menor latência possível para seus aplicativos.
O caso de uso a seguir demonstra como a Topologia de Rede pode ajudá-lo a verificar suas configurações atuais. Por exemplo, você pode verificar se todas as solicitações de clientes
estão sendo atendidas por instâncias de aplicativos da região Google Cloud
mais próxima do cliente. Você também pode garantir que o tráfego entre regiões seja baixo porque esse tráfego vem de bancos de dados que replicam dados globalmente.
Visão geral da topologia
A implantação abrange três Google Cloud regiões (us-central1,
europe-west1 e asia-east1). Todas as solicitações de clientes externos são atendidas por um
único balanceador de carga de aplicativo externo que tem vários back-ends em cada uma das três
regiões. As solicitações de clientes provenientes de uma das três regiões de negócios (Américas,
EMEA e APAC) são atendidas por instâncias de aplicativos na região
Google Cloud mais próxima.
O gráfico a seguir mostra a hierarquia de nível superior para a implantação.
Topologia de exemplo de topologia de rede (clique para ampliar)
Recursos e caminhos de tráfego
Neste exemplo, o projeto contém os seguintes recursos Google Cloud:
1 Balanceador de carga HTTPS
4 serviços de back-end: browse, shopping_cart, checkout e feeds
12 grupos de instâncias (que são os backends do balanceador de carga)
Há um grupo de instâncias para cada serviço de back-end em cada uma das três
regiões.
3 instâncias de banco de dados, uma em cada região
Você espera que o tráfego de determinados países chegue aos seguintes
locais:
O tráfego de países na região de negócios Americas vai para back-end na região us-central1. Por exemplo, o tráfego de um cliente externo no Canadá viaja pelo balanceador de carga para o back-end checkout na região us-central1.
O tráfego de países na região de negócios EMEA vai para back-end na região europe-west1. Por exemplo, o tráfego de um cliente externo na Polônia viaja pelo balanceador de carga para o back-end checkout na região europe-west1.
O tráfego de países na região de negócios APAC vai para back-end na região asia-east1. Por exemplo, o tráfego de um cliente externo
no Japão viaja pelo balanceador de carga para o back-end checkout na
região asia-east1.
O tráfego para uma instância de banco de dados vem de um back-end na mesma região. Por exemplo, os back-end em asia-east1 enviam dados apenas para a instância do banco de dados em asia-east1.
O tráfego entre regiões é limitado à replicação do banco de dados. Por exemplo, o tráfego entre us-central1 e europe-west1 viaja apenas entre instâncias de banco de dados nessas regiões.
Fluxo de tráfego inesperado
Nesse cenário, você descobre que o tráfego da região de negócios EMEA
agora está indo para duas regiões diferentes do Google Cloud , us-central1 e
europe-west1. Usando a Topologia de rede, você descobre que um dos back-ends está superutilizado.
Você quer verificar se o tráfego externo que está passando pelo balanceador de carga acaba indo para a região Google Cloud correta. Você filtra
o gráfico para mostrar apenas o tráfego do seu balanceador de carga externo
shopping-site-lb.
Depois de aplicar o filtro, a Topologia de Rede mostra apenas as conexões relacionadas ao balanceador de carga, conforme mostrado no exemplo a seguir.
Filtro para um balanceador de carga (clique para ampliar)
Você mantém o ponteiro sobre cada região de negócios para destacar a comunicação com essa região.
Quando você mantém o ponteiro sobre Américas e APAC, o tráfego
vai para a região Google Cloud mais próxima: us-central1 e asia-
east1, respectivamente. No entanto, quando você mantém o ponteiro sobre EMEA, o tráfego vai para us-central1 e europe-west1. Idealmente, para reduzir
a latência, todo o tráfego da EMEA precisa ir para europe-west1.
Em seguida, clique em EMEA para estudar a taxa de transferência entre ela e as regiõesGoogle Cloud . A topologia de rede sobrepõe os valores da largura de banda em cada conexão. Você observa que cerca de 0,58 bytes por segundo são enviados para
us-central1 e 29,9 kilobytes por segundo são enviados
para europe-west1. Você sabe que a maior parte do tráfego está sendo direcionada como
seria de esperar, mas algum tráfego está fluindo para us-central1.
OValores de largura de banda sobrepostos 1 (clique para ampliar)
1 A figura é para referência. Seus dados não refletem o caso de uso.
Para investigar mais, expanda us-central1 para ver para onde o tráfego está indo. Como há apenas uma rede com uma única sub-rede nessa região, a Topologia de Rede não mostra esses níveis da hierarquia e pula para os grupos de instâncias.
Você vê que o tráfego está indo para um grupo de instâncias associado ao serviço de
back-end do balanceador de carga. Como é uma quantidade relativamente pequena de tráfego
indo para europe-west1, é possível que os recursos em europe-west1 sejam
superutilizados fazendo com que o tráfego seja direcionado para us-central1.
Caminho do tráfego 1 (clique para ampliar)
1 A figura é para referência. Seus dados não refletem o caso de uso.
Para confirmar sua conclusão, expanda a região europe-west1 até chegar à instância que está associada ao mesmo serviço de back-end do balanceador de carga. A topologia de rede mostra gráficos de séries temporais no painel de detalhes da instância.
No gráfico, você percebe que a taxa de utilização da CPU é de 81% para a
instância. O limite para este exemplo é 80%, indicando que a instância
está com excesso de assinaturas. Você resolve esse problema escalando o grupo de instâncias
para que o tráfego retorne ao fluxo ideal.
Gráfico de séries temporais para uma instância 1 (clique para ampliar)
1 A figura é para referência. Seus dados não refletem
o caso de uso.
Tráfego entre regiões
Na seção a seguir, verifique se o tráfego interno entre regiões está limitado apenas ao tráfego da instância do banco de dados.
Para se concentrar no tráfego interno, na lista Configuração de topologia, marque
apenas as caixas de seleção Instâncias e Gateways do Cloud NAT. Como você está visualizando apenas o tráfego no seu aplicativo, não precisa ver clientes externos nem o tráfego do balanceador de carga externo.
Mostrando tráfego somente interno (clique para ampliar)
Você expande a região asia-east1 e vê cinco grupos de instâncias. Eles não são agregados por rede, sub-rede ou zona, porque estão todos na mesma rede, sub-rede e assim por diante.
Você percebe que apenas um grupo de instâncias (db-group-asia) contém um caminho para o tráfego entre regiões. Todos os outros grupos de instâncias estão se comunicando na região.
Você continua a expandir o grupo db-group-asia até chegar à entidade base. Nesse cenário, a entidade base é uma instância de máquina virtual (VM, na sigla em inglês)
(db-instance-asia) que atua como um servidor de banco de dados. Ele está se comunicando com outras regiões para replicar dados, o que você esperava, portanto, nenhuma investigação adicional é necessária.
̦
Tráfego entre regiões 1 (clique para ampliar)
1 A figura é para referência. Seus dados não refletem
o caso de uso.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-09-03 UTC."],[],[],null,["# Use case: Audit network performance\n===================================\n\nAssume that you're a network administrator who supports a network that includes\nseveral load-balanced applications. You've been asked to audit the network\nconfigurations that support those applications to ensure that the configurations\nare consistent with the expected state of your network. By doing this audit, you\ncan ensure that customers are getting the lowest possible latency to your\napplications.\n\nThe following use case demonstrates how Network Topology can help you\ncheck your existing configurations. For example, you can check that all client\nrequests are being served by application instances from the Google Cloud\nregion that's closest to the client. You can also ensure that cross-region\ntraffic is low because that traffic comes from databases that replicate data\nglobally.\n\nTopology overview\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 graph 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\n### Resources and traffic paths\n\nIn this example, the project contains the following Google Cloud\nresources:\n\n- 1 HTTPS load balancer\n\n- 4 backend services: `browse`, `shopping_cart`, `checkout`, and `feeds`\n\n- 12 instance groups (which are the load balancer's backends)\n\n There is one instance group for each backend service in each of the three\n regions.\n- 3 database instances, one in each region\n\nYou expect that traffic from certain countries goes to the following\nlocations:\n\n- Traffic from countries in the `Americas` business region goes to backends in the `us-central1` region. For example, traffic from an external client in Canada travels through the load balancer to the `checkout` backend in the `us-central1` region.\n- Traffic from countries in the `EMEA` business region goes to backends in the `europe-west1` region. For example, traffic from an external client in Poland travels through the load balancer to the `checkout` backend in the `europe-west1` region.\n- Traffic from countries in the `APAC` business region goes to backends in the `asia-east1` region. For example, traffic from an external client in Japan travels through the load balancer to the `checkout` backend in the `asia-east1` region.\n- Traffic to a database instance comes from a backend in the same region. For example, the backends in `asia-east1` send data only to the database instance in `asia-east1`.\n- Cross-region traffic is limited to database replication. For example, traffic between `us-central1` and `europe-west1` travels only between database instances in those regions.\n\nUnexpected traffic flow\n-----------------------\n\nIn this scenario, you discover that traffic from the `EMEA` business region\nis now going to two different Google Cloud regions, `us-central1` and\n`europe-west1`. By using Network Topology, you discover that one of\nthe backends is overutilized.\n\n1. You want to check that external traffic that is going through the load\n balancer eventually goes to the correct Google Cloud region. You filter\n the graph 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. You hold the pointer over each business region to highlight the communication\n to that region.\n\n When you hold the pointer over **Americas** and **APAC** , you see traffic\n going to the nearest Google Cloud region: `us-central1` and `asia-\n east1` respectively. However, when you hold the pointer over **EMEA** , you\n see traffic going to `us-central1` and `europe-west1`. Ideally, to reduce\n latency, all traffic from EMEA should go to `europe-west1`.\n3. Next, you click **EMEA** to study the throughput between it and the\n Google Cloud regions. Network Topology overlays bandwidth\n values on each connection. You see that about 0.58 bytes per second is\n going to `us-central1` and 29.9 kilobytes per second is going\n to `europe-west1`. You know that most of the traffic is being directed as\n you would expect, but some traffic is flowing to `us-central1`.\n\n [](/static/network-intelligence-center/docs/network-topology/images/use-cases/auditing-bandwidth.png) Overlaid bandwidth values^1^ (click to enlarge) \n\n ^1^The figure is for reference. Its data doesn't reflect the use\n case.\n4. To investigate further, you expand `us-central1` to view where traffic is\n going. Because there's only one network with a single subnet in that region,\n Network Topology doesn't show those levels of the hierarchy and\n skips to the instance groups.\n\n You see that traffic is going to an instance group that's associated with the load\n balancer's backend service. Because it's a relatively small amount of traffic\n going to `europe-west1`, it's possible that resources in `europe-west1` are\n overutilized and causing traffic to overflow to `us-central1`.\n [](/static/network-intelligence-center/docs/network-topology/images/use-cases/auditing-traffic.png) Traffic path^1^ (click to enlarge) \n\n ^1^The figure is for reference. Its data doesn't reflect the use\n case.\n5. To confirm your conclusion, you expand the `europe-west1` region until you\n reach the instance that is associated with the same load balancer's backend\n service. Network Topology shows time-series charts in the details\n pane for the instance.\n\n In the chart, you notice that the CPU utilization rate is at 81% for the\n instance. The threshold for this example is 80%, indicating that the instance\n is oversubscribed. You resolve this issue by scaling up the instance group so\n that traffic returns to the ideal flow.\n [](/static/network-intelligence-center/docs/network-topology/images/use-cases/auditing-chart.png) Time-series chart for an instance^1^ (click to enlarge) \n\n ^1^The figure is for reference. Its data doesn't reflect the\n use case.\n\nInter-region traffic\n--------------------\n\nIn the following section, you check that internal traffic between regions\nis limited to only database instance traffic.\n\n1. To focus on internal traffic, in the **Topology configuration** list, you select\n only the **Instances** and **Cloud NAT gateways** checkboxes. Because you are only\n viewing traffic within your application, you don't need to see external clients\n and external load balancer traffic.\n\n [](/static/network-intelligence-center/docs/network-topology/images/use-cases/auditing-internalonly.png) Showing internal-only traffic (click to enlarge)\n2. You expand the `asia-east1` region, and you see five instance groups. They are\n not aggregated by network, subnet, or zone because\n they are all in the same network, subnet, and so on.\n\n You notice that only one instance group (`db-group-asia`) contains a path\n for inter-region traffic. All other instance groups are communicating within\n the region.\n\n You continue to expand the `db-group-asia` group until you reach the base\n entity. In this scenario, the base entity is a virtual machine (VM) instance\n (`db-instance-asia`) that acts as a database server. It's communicating with\n other regions to replicate data, which is what you expected, so no further\n investigations are required.\n ̦\n [](/static/network-intelligence-center/docs/network-topology/images/use-cases/auditing-dbtraffic.png) Inter-region traffic^1^ (click to enlarge) \n\n ^1^The figure is for reference. Its data doesn't reflect the\n use case.\n\n \u003cbr /\u003e\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: Troubleshoot network connectivity](/network-intelligence-center/docs/network-topology/concepts/troubleshooting-network-connectivity)\n- [Troubleshoot Network Topology](/network-intelligence-center/docs/network-topology/support/troubleshooting)"]]
