En esta página se describen las métricas que se usan para determinar el rendimiento de los recursos de tuGoogle Cloud proyecto y el rendimiento de todo el Google Cloud. También puedes consultar información sobre las distintas vistas que muestran más detalles sobre estas métricas de rendimiento.
Métricas
El panel de rendimiento proporciona dos tipos de métricas: pérdida de paquetes y latencia (tiempo de ida y vuelta o RTT). Para obtener métricas de pérdida de paquetes de tuGoogle Cloud proyecto, necesitas un número suficiente de VMs en el proyecto. Para obtener métricas de latencia, necesitas una cantidad de tráfico suficiente. Además, no es necesario configurar el panel de control de rendimiento.
En las secciones siguientes se describen ambas métricas con más detalle.
Pérdida de paquetes
Las métricas de pérdida de paquetes muestran los resultados de las comprobaciones activas entre los siguientes elementos:
Máquinas virtuales de una misma red de VPC.
Máquinas virtuales de redes de VPC emparejadas, cuando una o ambas redes están en tu proyecto. Si las redes emparejadas están en proyectos diferentes, la pérdida de paquetes se puede ver en el proyecto de destino.
Máquinas virtuales de una red de VPC compartida que utilice tu proyecto. La pérdida de paquetes entre dos proyectos que usan una red de VPC compartida se puede ver en el proyecto de servicio de destino.
Por ejemplo, supongamos que el proyecto A incluye dos redes de VPC: la red A, que solo tiene VMs en la zona A, y la red M, que solo tiene VMs en la zona M. Si esas dos redes están emparejadas, el panel de rendimiento del proyecto A muestra los datos de pérdida de paquetes del par de zonas A/M. Si las redes no están emparejadas, el panel de control de rendimiento no muestra la métrica de pérdida de paquetes de ese par de zonas.
Si estas dos redes no están en el mismo proyecto, anota cuándo muestra las métricas el panel de rendimiento de cada red. Es decir, supongamos que la red A forma parte del proyecto A y la red M forma parte del proyecto M. Cuando las redes están emparejadas, el panel de control de rendimiento del proyecto M muestra datos de pérdida de paquetes en situaciones en las que la zona M es la zona de destino. Por el contrario, cuando la zona A es la zona de destino, los datos de pérdida de paquetes solo los puede ver el proyecto A. Si las redes no están emparejadas, el panel de rendimiento de ninguno de los proyectos muestra datos de pérdida de paquetes de la zona.
Los datos recogidos a través de todas las sondas se agregan en el panel de control de rendimiento. Es decir, el panel de control Rendimiento no te permite aislar los datos sobre la pérdida de paquetes entre proyectos frente a otros tipos (como la pérdida de paquetes relacionada con una red de VPC emparejada en otro proyecto). Sin embargo, puede usar Monitorización para ver resultados más detallados. Para obtener más información, consulta el artículo Referencia de métricas del panel de control de rendimiento.
El panel de control de rendimiento no envía sondeos a través de conexiones de Cloud VPN.
Metodología
Panel de rendimiento ejecuta los procesos de trabajo en los hosts físicos que alojan tus VMs. Estos trabajadores insertan y reciben paquetes de sondeo que se ejecutan en la misma red que su tráfico. Como los trabajadores se ejecutan en los hosts físicos y no en tus máquinas virtuales, no consumen recursos de las máquinas virtuales y el tráfico no se puede ver en ellas.
Las sondas cubren toda la malla de máquinas virtuales que pueden comunicarse entre sí, lo que no es necesariamente lo mismo que tu patrón de tráfico. Por lo tanto, es posible que veas indicaciones de pérdida de paquetes en el panel de rendimiento, pero no pruebas de pérdida de paquetes en tu aplicación.
En todas las VMs analizadas, Google Cloud intenta acceder a la VM tanto con su dirección IP interna como con su dirección IP externa (si existe). Las sondas no salen de Google Cloud, pero, al usar direcciones IP externas, el panel de control de rendimiento puede cubrir parte de la ruta que utiliza el tráfico externo, como el tráfico procedente de Internet.
La pérdida de paquetes de las direcciones IP internas se mide mediante paquetes UDP, mientras que la pérdida de paquetes de las direcciones IP externas se mide mediante paquetes TCP.
Disponibilidad de las métricas y niveles de confianza
Panel de rendimiento sondea un subconjunto de todos los pares de VMs de la red. Los datos recogidos se usan para estimar la pérdida de paquetes que puedes experimentar. La confianza de Google en los datos depende de la frecuencia de sondeo, y esta depende del número de máquinas virtuales que tengas en cada zona, así como del número de zonas en las que hayas implementado máquinas virtuales. Por ejemplo, tener 10 VMs en dos zonas genera más confianza que tener 10 VMs en 10 zonas.
Todas las máquinas virtuales, incluidas las creadas por Google Kubernetes Engine (GKE), se tienen en cuenta para el número total de máquinas virtuales.
En la siguiente tabla se describen los distintos niveles de confianza. Los niveles de confianza más bajos se marcan en el mapa de calor con un asterisco (*) o N/A
.
Nivel | Número obligatorio de VMs en cada zona | Qué muestra el Panel de rendimiento en el mapa de calor |
---|---|---|
95% de confianza | 10 VMs multiplicado por el número de zonas del proyecto. Por ejemplo, si tienes 12 zonas en tu proyecto, debes tener 120 VMs en cada zona. | Una medición sin ninguna anotación adicional |
90% de confianza | 2,5 VMs multiplicado por el número de zonas del proyecto. Por ejemplo, si tienes 12 zonas en tu proyecto, debes tener 30 VMs en cada zona. | Una medición sin ninguna anotación adicional |
Poca confianza | Una medición con un asterisco | |
No hay suficientes sondas para obtener datos significativos | N/A |
Las Google Cloud métricas de pérdida de paquetes están disponibles en todo momento. Se muestra un asterisco (*) si hay menos de 400 sondas por minuto.
Latencia específica del proyecto
Las métricas de latencia se miden mediante el tráfico de los clientes entre los siguientes elementos:
- Máquinas virtuales de una misma red de VPC
- Máquinas virtuales entre redes de VPC emparejadas, si las redes están en el mismo proyecto
- Máquinas virtuales y endpoints de Internet
Además, el panel de control de rendimiento de un proyecto de servicio de una red de VPC compartida solo muestra datos de las zonas del proyecto de servicio. Es decir, supongamos que una VM de la zona A y el proyecto de servicio A usan el proyecto host para comunicarse con una VM de la zona B y el proyecto de servicio B. Las métricas sobre ese tráfico no están disponibles para el proyecto del servicio ni para el proyecto del host.
Google Cloud latencia
Las métricas de latencia se miden mediante el tráfico real de los clientes entre los siguientes elementos:
- Máquinas virtuales de una misma red de VPC
- Máquinas virtuales entre redes de VPC emparejadas
- Máquinas virtuales y endpoints de Internet
Metodología para proyectos y Google Cloud latencia
La latencia se mide mediante paquetes TCP.
La latencia se calcula a partir de una muestra de tu tráfico real como el tiempo que transcurre entre el envío de un número de secuencia TCP (SEQ) y la recepción de un ACK
correspondiente que contiene el RTT de la red y el retraso relacionado con la pila TCP. El panel de control muestra la latencia como la mediana de todas las mediciones pertinentes.
La métrica de latencia se basa en la misma fuente de datos y metodología de muestreo que Registros de flujo de VPC.
La latencia específica del proyecto se basa en muestras de tu proyecto. La latencia deGoogle Cloud se basa en muestras de todo Google Cloud.
Las métricas de latencia global se derivan del muestreo pasivo de los encabezados de tráfico TCP y no de las comprobaciones activas de Google Cloud a los endpoints de Internet.
Anomalías en las métricas de latencia
Tenga en cuenta las siguientes anomalías de la métrica de latencia:
En entornos de baja tasa, el Centro de control de la red usa sondeos de 60 segundos para las métricas de latencia. Por lo tanto, las métricas de RTT basadas en el muestreo de paquetes pueden informar falsamente de niveles de latencia altos cuando los servicios basados en TCP devuelven una respuesta a nivel de aplicación con retraso. Normalmente, puedes reconocer los niveles de RTT incorrectos comprobando si se corresponden con los retrasos a nivel de aplicación.
Aunque el servicio basado en TCP responde rápidamente con un
ACK
, el muestreo no detecta elACK
y cuenta una respuesta de datos posterior como elACK
de cierre de un SEND mucho anterior, lo que distorsiona la medición general del RTT. En estos casos, puede ignorar las métricas de RTT.A veces, los datos de latencia específicos del proyecto no coinciden con los datos de latencia globales. Este desfase puede producirse si el conjunto de datos global también incorpora otras rutas de red con latencias significativamente diferentes en relación con la ruta de red utilizada por el proyecto específico.
Disponibilidad de las métricas
La métrica de latencia Google Cloud siempre está disponible. La métrica de latencia por proyecto solo está disponible si el tráfico TCP es de unos 1000 paquetes por minuto o más.
Tabla de resumen de métricas
En la siguiente tabla se resumen los métodos y protocolos de sondeo que se usan para generar informes sobre las métricas de pérdida de paquetes y latencia.
Pérdida de paquetes | Latencia | |
---|---|---|
Método de sondeo | Comprobación activa (tráfico sintético de VMs) | Comprobación pasiva (tráfico real de la VM) |
Protocolo | UDP (dirección IP interna) y TCP (dirección IP externa) | TCP (direcciones IP internas o externas) |
Vistas de latencia
Los detalles de latencia del tipo de tráfico Internet a Google Cloud están disponibles en tres vistas: Tabla, Mapa y Cronología.
Vista de tabla
La vista Tabla muestra la mediana del RTT entre las zonas geográficas seleccionadas y las regiones que contienen instancias de VM en tu proyecto. La tabla incluye los siguientes detalles:
- País: el nombre del país.
- Ciudades: número de ciudades. Puede ver los detalles de la latencia de cada ciudad específica en el gráfico de detalles del país.
- Regiones de destino: el número de regiones de destino con tráfico de usuarios de un país determinado.
- Latencia mediana: la mediana del RTT, en milisegundos, entre el país y las regiones.
Vista de mapa
La vista Mapa muestra las ubicaciones geográficas (áreas metropolitanas o ciudades) y lasGoogle Cloud regiones.
- Consulta la latencia media de ubicaciones y regiones específicas. Google Cloud
- Selecciona una Google Cloud región y consulta las ubicaciones con tráfico de la región seleccionada.
- Consulta los detalles específicos de una ubicación en un gráfico de latencia de la barra lateral.
- Busca ubicaciones mediante el cuadro de búsqueda del mapa.
Las ubicaciones se muestran en diferentes tonos de azul para indicar los intervalos de latencia media en el mapa. En la siguiente imagen, el color de un círculo que muestra una ciudad en un mapa mundial puede ser un tono de azul. Cuanto más oscuro sea el tono azul, mayor será la latencia de esa ciudad desde una Google Cloud región Google Cloud determinada.

Vista cronológica
La vista Cronología muestra la mediana del RTT entre las zonas geográficas y las Google Cloud regiones seleccionadas. Proporciona las métricas de latencia actuales y datos históricos de seis semanas. Puede usar los filtros para agregar aún más el tráfico a nivel de ciudad, región geográfica y país. Solo puedes ver las métricas de latencia correspondientes a combinaciones específicas de región y ubicación geográfica si hay Google Cloud tráfico suficiente para esa combinación.