Esta página descreve as métricas usadas para determinar o desempenho dos recursos do seuGoogle Cloud projeto e o desempenho de todo o projeto Google Cloud. Também pode encontrar detalhes sobre as várias vistas que mostram mais detalhes sobre estas métricas de desempenho.
Métrica
O painel de controlo de desempenho fornece dois tipos de métricas: perda de pacotes e latência (tempo de resposta, ou RTT). Para obter métricas de perda de pacotes para o seu Google Cloud projeto, precisa de um número suficiente de VMs no projeto. Para obter métricas de latência, precisa de uma quantidade suficiente de tráfego. Além disso, o painel de controlo de desempenho não requer configuração.
As secções seguintes descrevem ambas as métricas mais detalhadamente.
Perda de pacotes
As métricas de perda de pacotes mostram os resultados da sondagem ativa entre o seguinte:
VMs numa única rede VPC.
VMs em redes VPC com intercâmbio, quando uma ou ambas as redes estão no seu projeto. Se as redes em peering estiverem em projetos diferentes, a perda de pacotes é visível no projeto de destino.
VMs numa rede VPC partilhada usada pelo seu projeto. A perda de pacotes entre dois projetos que usam uma rede VPC partilhada é visível no projeto de serviço de destino.
Por exemplo, suponha que o projeto A inclui duas redes VPC: a rede A, que tem VMs apenas na zona A, e a rede M, que tem VMs apenas na zona M. Se essas duas redes estiverem em peering, o Performance Dashboard do projeto A mostra os dados de perda de pacotes para o par de zonas A/M. Se as redes não estiverem em peering, o painel de controlo de desempenho não mostra a métrica de perda de pacotes para esse par de zonas.
Se estas duas redes não estiverem no mesmo projeto, tenha em atenção quando o painel de controlo de desempenho de cada rede mostra as métricas. Ou seja, suponhamos que a rede A faz parte do projeto A e a rede M faz parte do projeto M. Quando as redes estão em peering, o painel de controlo de desempenho do projeto M mostra dados de perda de pacotes para situações em que a zona M é a zona de destino. Por outro lado, quando a zona A é a zona de destino, os dados de perda de pacotes só estão visíveis para o projeto A. Se as redes não estiverem em peering, o painel de controlo de desempenho de nenhum dos projetos mostra dados de perda de pacotes para o par de zonas.
Os dados recolhidos através de todas as sondas são agregados no painel de controlo de desempenho. Ou seja, o painel de controlo de desempenho não lhe permite isolar dados sobre a perda de pacotes intraprojeto em comparação com outros tipos (como a perda de pacotes relacionada com uma rede VPC com peering noutro projeto). No entanto, pode usar a monitorização para ver resultados mais detalhados. Para mais informações, consulte o artigo Referência das métricas do painel de controlo de desempenho.
O painel de controlo de desempenho não envia sondagens através de ligações de VPN na nuvem.
Metodologia
O painel de controlo de desempenho executa trabalhadores nos anfitriões físicos que alojam as suas VMs. Estes trabalhadores inserem e recebem pacotes de sondagem que são executados na mesma rede que o seu tráfego. Uma vez que os trabalhadores são executados nos anfitriões físicos e não nas suas VMs, estes trabalhadores não consomem recursos de VMs, e o tráfego não é visível nas suas VMs.
As sondas cobrem toda a malha de VMs que podem comunicar entre si, o que não é necessariamente o mesmo que o seu padrão de tráfego. Por conseguinte, pode ver indicações de perda de pacotes no painel de controlo de desempenho, mas não existem provas de perda de pacotes na sua aplicação.
Para todas as VMs testadas, Google Cloud tenta aceder à VM através do respetivo endereço IP interno e endereço IP externo (se existir). As sondas não saem Google Cloud, mas, ao usar endereços IP externos, o Painel de controlo de desempenho pode abranger parte do caminho usado pelo tráfego externo, como o tráfego proveniente da Internet.
A perda de pacotes para endereços IP internos é medida através de pacotes UDP e a perda de pacotes para endereços IP externos é medida através de pacotes TCP.
Disponibilidade das métricas e níveis de confiança
O painel de controlo de desempenho analisa um subconjunto de todos os pares de VMs na rede. Os dados recolhidos são, em seguida, usados para estimar a perda de pacotes que pode ocorrer. A confiança da Google nos dados depende da taxa de sondagem, e a taxa de sondagem depende do número de VMs que tem em cada zona, bem como do número de zonas onde tem VMs implementadas. Por exemplo, ter 10 VMs em duas zonas gera mais confiança do que ter 10 VMs em 10 zonas.
Todas as VMs, incluindo as criadas pelo Google Kubernetes Engine (GKE), são contabilizadas para o número total de VMs.
Os vários níveis de confiança estão descritos na tabela seguinte. Os níveis de confiança mais baixos são sinalizados no mapa de calor com um asterisco (*) ou N/A.
| Nível | Número necessário de VMs em cada zona | O que o painel de controlo de desempenho mostra no mapa de calor |
|---|---|---|
| 95% de confiança | 10 VMs multiplicadas pelo número de zonas no projeto. Por exemplo, se tiver 12 zonas no seu projeto, tem de ter 120 VMs em cada zona. | Uma medição sem anotações adicionais |
| 90% de confiança | 2,5 VMs multiplicadas pelo número de zonas no projeto. Por exemplo, se tiver 12 zonas no seu projeto, tem de ter 30 VMs em cada zona. | Uma medição sem anotações adicionais |
| Confiança baixa | Uma medição com um asterisco | |
| Não existem sondagens suficientes para ter dados significativos | N/A |
As Google Cloud métricas de perda de pacotes estão sempre disponíveis. É apresentado um asterisco (*) se houver menos de 400 sondagens por minuto.
Latência específica do projeto
As métricas de latência são medidas através do tráfego de clientes entre o seguinte:
- VMs numa única rede da VPC
- VMs entre redes VPC com intercâmbio, se as redes estiverem no mesmo projeto
- VMs e endpoints da Internet
Além disso, o painel de controlo de desempenho de um projeto de serviço numa rede de VPC partilhada mostra dados apenas para as zonas no projeto de serviço. Ou seja, suponhamos que uma VM na zona A e no projeto de serviço A usa o projeto anfitrião para comunicar com uma VM na zona B e no projeto de serviço B. As medições sobre esse tráfego não estão disponíveis para o projeto de serviço nem para o projeto anfitrião.
Google Cloud latência
As métricas de latência são medidas através do tráfego real de clientes entre o seguinte:
- VMs numa única rede da VPC
- VMs entre redes da VPC em intercâmbio
- VMs e endpoints da Internet
Metodologia para projetos e Google Cloud latência
A latência é medida através de pacotes TCP.
Com base numa amostra do seu tráfego real, a latência é calculada como o tempo que decorre entre o envio de um número de sequência TCP (SEQ) e a receção de um ACK correspondente que contém o RTT da rede e o atraso relacionado com a pilha TCP. O painel de controlo mostra a latência como a mediana de todas as medições relevantes.
A métrica de latência baseia-se na mesma origem de dados e metodologia de amostragem que os registos de fluxo de VPC.
A latência específica do projeto baseia-se em exemplos do seu projeto. A Google Cloud latência baseia-se em amostras de todos os Google Cloud.
As métricas de latência global são derivadas da amostragem passiva de cabeçalhos de tráfego TCP e não através da sondagem ativa de Google Cloud para pontos finais da Internet.
Anomalias nas métricas de latência
Tenha em atenção as seguintes anomalias de métricas de latência:
Para ambientes de baixa taxa, o Network Intelligence Center usa sondagens de sessenta segundos para métricas de latência. Por conseguinte, as métricas de RTT baseadas na amostragem de pacotes podem comunicar falsamente níveis de latência elevados quando os serviços baseados em TCP devolvem uma resposta ao nível da aplicação atrasada. Normalmente, pode reconhecer níveis de RTT imprecisos verificando se correspondem a atrasos ao nível da aplicação.
Embora o serviço baseado em TCP responda rapidamente com um
ACK, a amostragem não deteta oACKe contabiliza uma resposta de dados posterior como oACKde fecho para um SEND muito anterior, o que distorce a medição geral do RTT. Nestes casos, pode ignorar as métricas de RTT.Por vezes, os dados de latência específicos do projeto não se alinham com os dados de latência globais. Este desalinhamento pode ocorrer se o conjunto de dados global também incorporar outros caminhos de rede com latências significativamente diferentes em relação ao caminho de rede usado pelo projeto específico.
Disponibilidade de métricas
A Google Cloud métrica de latência está sempre disponível. A métrica de latência por projeto só está disponível se o tráfego TCP for de cerca de 1000 pacotes por minuto ou superior.
Tabela de resumo das métricas
A tabela seguinte resume os métodos de sondagem e os protocolos usados para comunicar métricas de perda de pacotes e latência.
| Perda de pacotes | Latência | |
|---|---|---|
| Método de sondagem | Sondagem ativa (tráfego de VM sintético) | Sondagem passiva (tráfego real da VM) |
| Protocolo | UDP (endereço IP interno), TCP (endereço IP externo) | TCP (endereços IP internos/externos) |
Visualizações de latência
Os detalhes da latência para o tipo de tráfego Internet para Google Cloud estão disponíveis em três vistas: vista de tabela, vista de mapa e vista de linha cronológica.
Vista de tabela
A vista de tabela mostra o RTT mediano entre as áreas geográficas selecionadas e as regiões que contêm instâncias de VM no seu projeto. A tabela inclui os seguintes detalhes:
- País: o nome do país.
- Cidades: o número de cidades. Pode ver os detalhes da latência de cada cidade específica no gráfico de detalhes do país.
- Regiões de destino: o número de regiões de destino com tráfego para utilizadores de um determinado país.
- Latência mediana: o RTT mediano, em milissegundos, entre o país e as regiões.
Vista de mapa
A vista de mapa mostra as localizações geográficas (áreas metropolitanas ou cidades) e as Google Cloud regiões.
- Veja a latência mediana de localizações e Google Cloud regiões específicas.
- Selecione uma Google Cloud região e veja as localizações com tráfego para a região selecionada.
- Veja detalhes específicos da localização num gráfico de latência na barra lateral.
- Pesquise localizações através da caixa de pesquisa no mapa.
As localizações são classificadas por cores em diferentes tons de azul para indicar os intervalos de latência mediana no mapa. Na imagem seguinte, a cor de um círculo que mostra uma determinada cidade num mapa global pode ser um tom de azul. Quanto mais escura for a tonalidade de azul, maior é a latência dessa cidade a partir de uma determinada Google Cloud região.
Vista de linha cronológica
A vista Linha cronológica mostra o TRP mediano entre as áreas geográficas selecionadas e as regiões. Google Cloud Fornece as métricas de latência atuais e seis semanas de dados do histórico. Pode usar os filtros para agregar ainda mais o tráfego ao nível da cidade, região geográfica e país. Só pode ver as métricas de latência correspondentes a pares de localizações geográficas de regiões específicas se houver Google Cloud tráfego suficiente para esse par.