Métricas y vistas del Panel de rendimiento

En esta página, se describen las métricas que se usan para determinar el rendimiento de los recursos de tu proyecto de Google Cloud y el rendimiento de todo el servicio. También puedes encontrar detalles 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 tu proyecto de Google Cloud, necesitas una cantidad suficiente de VM en el proyecto. Para obtener métricas de latencia, necesitas una cantidad suficiente de tráfico. Además, el Panel de rendimiento no requiere configuración.

En las siguientes secciones, 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 los sondeos activos entre los siguientes elementos:

  • VM dentro de una sola red de VPC.

  • Las VM en redes de VPC con intercambio de tráfico, cuando una o ambas redes están dentro de tu proyecto. Si las redes con intercambio de tráfico se encuentran en proyectos diferentes, la pérdida de paquetes es visible en el proyecto de destino.

  • VM en una red de VPC compartida que utiliza tu proyecto. La pérdida de paquetes entre dos proyectos que usan una red de VPC compartida es visible en el proyecto de servicio de destino.

Por ejemplo, supongamos que el proyecto A incluye dos redes de VPC: la red A, que tiene solo VM en la zona A, y la red M, que tiene VM solo en la zona M. Si esas dos redes intercambian tráfico entre sí, 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 realizan un intercambio de tráfico, el Panel de rendimiento no muestra la métrica de pérdida de paquetes para ese par de zonas.

Si estas dos redes no están en el mismo proyecto, ten en cuenta cuándo se muestran las métricas en el Panel de rendimiento de cada red. Es decir, supongamos que la red A es parte del proyecto A y la red M es parte del proyecto M. Cuando las redes intercambian tráfico, el panel de rendimiento del proyecto M muestra los 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 son visibles solo para el proyecto A. Si las redes no intercambian tráfico, ninguno de los paneles de rendimiento de los proyectos muestra los datos de pérdida de paquetes para el par de zonas.

Los datos recopilados a través de todos los sondeos se agregan en el Panel de rendimiento. Es decir, el panel de rendimiento no te permite aislar datos sobre la pérdida de paquetes dentro del proyecto en comparación con otros tipos (como la pérdida de paquetes relacionados con una red de VPC con intercambio de tráfico en otro proyecto). Sin embargo, puedes usar Monitoring para ver resultados más detallados. Para obtener más información, consulta la referencia de las métricas del Panel de rendimiento.

El panel de rendimiento no envía los sondeos a través de conexiones de Cloud VPN.

Metodología

El panel de rendimiento ejecuta los trabajadores en los hosts físicos que alojan tus VM. Estos trabajadores insertan y reciben paquetes de sondeo que se ejecutan en la misma red que tu tráfico. Debido a que los trabajadores se ejecutan en los hosts físicos y no en las VM, estos no consumen recursos de VM, y el tráfico no es visible en las VM.

Las sondeos 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 indicios de pérdida de paquetes en el Panel de rendimiento y que no haya evidencia de pérdida de paquetes en tu aplicación.

Para todas las VM probadas, Google Cloud intenta acceder a la VM mediante su dirección IP interna y su dirección IP externa (si la hay). Los sondeos no salen de Google Cloud, pero mediante el uso de direcciones IP externas, el panel de rendimiento puede cubrir parte de la ruta que usa el tráfico externo, como el tráfico que proviene de Internet.

La pérdida de paquetes para direcciones IP internas se mide mediante paquetes UDP, y la pérdida de paquetes para direcciones IP externas se mide mediante paquetes TCP.

Disponibilidad de métricas y niveles de confianza

El panel de rendimiento sondea un subconjunto de todos los pares de VM-VM en la red. Luego, los datos recopilados se usan para estimar la pérdida de paquetes que podrías experimentar. La confianza de Google en los datos depende de la tasa de sondeo, y la tasa de sondeo depende de la cantidad de VM que tengas en cada zona, así como de la cantidad de zonas en las que hayas implementado las VM. Por ejemplo, tener 10 VM en dos zonas genera más confianza que tener 10 VM en 10 zonas.

Todas las VM, incluidas las creadas por Google Kubernetes Engine (GKE), cuentan para el total de VM.

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 Cantidad requerida de VM en cada zona Qué muestra el panel de rendimiento en el mapa de calor
95% de confianza 10 VMs multiplicadas por la cantidad de zonas del proyecto. Por ejemplo, si tienes 12 zonas en tu proyecto, debes tener 120 VM en cada zona. Una medición sin ninguna notación adicional
90% de confianza 2.5 VMs multiplicadas por la cantidad de zonas del proyecto. Por ejemplo, si tienes 12 zonas en tu proyecto, debes tener 30 VM en cada zona. Una medición sin ninguna notación adicional
Confianza baja Una medición con un asterisco
No hay suficientes sondeos para tener datos significativos N/A

Las métricas de pérdida de paquetes de Google Cloud siempre están disponibles. Se muestra un asterisco (*) si hay menos de 400 sondeos por minuto.

Latencia específica del proyecto

Las métricas de latencia se miden mediante el tráfico del cliente entre los siguientes elementos:

  • VMs dentro de una sola red de VPC
  • Las VMs entre redes de VPC con intercambio de tráfico, si estas se encuentran en el mismo proyecto
  • VMs y extremos de Internet

Además, el panel de rendimiento de un proyecto de servicio dentro de una red de VPC compartida muestra datos solo para las zonas del proyecto de servicio. Es decir, supongamos que una VM en la zona A y el proyecto de servicio A usan el proyecto host para comunicarse con una VM en la zona B y en el proyecto B. Las mediciones sobre ese tráfico no están disponibles para el proyecto de servicio ni para el proyecto host.

Latencia de Google Cloud

Las métricas de latencia se miden mediante el tráfico real del cliente entre los siguientes elementos:

  • VMs dentro de una sola red de VPC
  • VM entre redes de VPC con intercambio de tráfico
  • VMs y extremos de Internet

Metodología para los proyectos y la latencia de Google Cloud

La latencia se mide mediante el uso de paquetes TCP.

En función de una muestra de tu tráfico real, la latencia se calcula como el tiempo que transcurre entre el envío de un número de secuencia de TCP (SEQ) y la recepción de un ACK correspondiente que contiene el RTT de la red y el retraso relacionado con la pila de TCP. En el panel, se muestra la latencia como la mediana de todas las mediciones relevantes.

La métrica de latencia se basa en la misma fuente de datos y metodología de muestreo que los registros de flujo de VPC.

La latencia específica del proyecto se basa en muestras de tu proyecto. La latencia de Google Cloud se basa en muestras de todo Google Cloud.

Las métricas de latencia global se derivan del muestreo pasivo de encabezados de tráfico de TCP y no del sondeo activo de Google Cloud a extremos de Internet.

Anomalías de latencia en la métrica

Observa las siguientes anomalías en las métricas de latencia:

  • En entornos de frecuencia baja, Network Intelligence Center usa sondeos de sesenta segundos para las métricas de latencia. Por lo tanto, las métricas de RTT basadas en el muestreo de paquetes podrían informar erróneamente niveles de latencia altos cuando los servicios basados en TCP muestran una respuesta retrasada a nivel de aplicación. Por lo general, puedes reconocer niveles de RTT inexactos si verificas si se corresponden con retrasos a nivel de la aplicación.

    Aunque el servicio basado en TCP responde rápidamente con un ACK, el muestreo omite el ACK y cuenta una respuesta de datos posterior como la ACK de cierre a un SEND mucho anterior, lo que distorsiona la medición general de RTT. En estos casos, puedes ignorar las métricas de RTT.

  • A veces, los datos de latencia específicos del proyecto no se alinean con los datos de latencia global. Este desajuste puede ocurrir si el conjunto de datos global también incorpora otras rutas de red con latencias muy diferentes relacionadas con la ruta de red que usa el proyecto específico.

Disponibilidad de métricas

La métrica de latencia de Google Cloud siempre está disponible. La métrica de latencia por proyecto solo está disponible si el tráfico de TCP es de 1,000 paquetes por minuto o más.

Tabla de resumen de métricas

En la siguiente tabla, se resumen los métodos y los protocolos de sondeo que se usan para informar las métricas de pérdida paquetes y latencia.

Pérdida de paquetes Latencia
Método de sondeo Sondeo activo (tráfico de VM sintético) Sondeo pasivo (tráfico de VM real)
Protocol UDP (dirección IP interna), TCP (dirección IP externa) TCP (direcciones IP internas y externas)

Vistas de latencia

Los detalles de latencia para el tipo de tráfico De Internet a Google Cloud están disponibles en tres vistas: Tabla, Mapa y Cronograma.

Vista de tabla

En la vista de Tabla, se muestra la mediana del RTT entre las áreas geográficas seleccionadas y las regiones que contienen instancias de VM en tu proyecto. La tabla incluye los siguientes detalles:

  • País: Indica el nombre del país.
  • Ciudades: Es la cantidad de ciudades. Puedes ver los detalles de latencia de cada ciudad específica en el gráfico de detalles del país.
  • Regiones de destino: Es la cantidad de regiones de destino con tráfico para los usuarios de un país determinado.
  • Latencia mediana: La mediana de RTT, en milisegundos, entre el país y las regiones.

Vista de mapa

En la vista de mapa, se muestran las ubicaciones geográficas (áreas metropolitanas o ciudades) y las regiones de Google Cloud.

  • Ver la latencia mediana de ubicaciones específicas y regiones de Google Cloud
  • Selecciona una región de Google Cloud y visualiza las ubicaciones con tráfico a la región seleccionada.
  • Consulta los detalles específicos de la ubicación en un gráfico de latencia en la barra lateral.
  • Usa el cuadro de búsqueda en el mapa para buscar ubicaciones.

Las ubicaciones se califican en diferentes tonos de azul para indicar los rangos de latencia mediana en el mapa. En la siguiente imagen, el color de un círculo que muestra una ciudad determinada en un mapa mundial puede ser de un tono azul. Cuanto más oscuro sea el tono de azul, mayor será la latencia de esa ciudad desde una región de Google Cloud determinada.

Rangos de latencia mediana en el mapa.
Rangos de mediana de latencia en el mapa (haz clic para ampliar)

Vista de cronograma

En la vista Cronograma, se muestra la mediana de RTT entre las áreas geográficas seleccionadas y las regiones de Google Cloud. Proporciona las métricas de latencia actuales y datos históricos de seis semanas. Puedes 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 pares de región/ubicación geográfica específicos si hay suficiente tráfico de Google Cloud para ese par.