En esta página, se describen las métricas que se usan para determinar el rendimiento de los recursos de tu proyecto deGoogle Cloud y el rendimiento de todo el Google Cloud. También puedes encontrar detalles sobre las distintas vistas en las que se muestra más información sobre estas métricas de rendimiento.
Métricas
En el Panel de rendimiento, se proporcionan dos tipos de métricas: las de pérdida de paquetes y las de latencia (tiempo de ida y vuelta [RTT]). Para obtener las métricas de pérdida de paquetes de tu proyecto deGoogle Cloud , este debe tener una cantidad suficiente de VMs. 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 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 los sondeos activos entre los elementos que se indican a continuación:
VMs en una sola red de VPC.
VMs en redes de VPC con intercambio de tráfico, cuando una o ambas redes se encuentran en tu proyecto. Si las redes con intercambio de tráfico se encuentran en proyectos diferentes, la pérdida de paquetes se verá en el proyecto de destino.
VMs en una red de VPC compartida que tu proyecto usa. La pérdida de paquetes entre dos proyectos que usan una red de VPC compartida se ve 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 tiene VMs solo en la zona M. Si esas dos redes intercambian tráfico, en el Panel de rendimiento del proyecto A se muestran los datos de pérdida de paquetes correspondientes al par de zonas A/M. Si las redes no intercambian tráfico, en el Panel de rendimiento no se muestra la métrica de pérdida de paquetes correspondiente ese par de zonas.
Si estas dos redes no están en el mismo proyecto, observa cuándo se muestran las métricas en el Panel de rendimiento de cada una. Es decir, supongamos que la red A forma parte del proyecto A, y la red M forma parte del proyecto M. Cuando las redes intercambian tráfico, en el Panel de rendimiento del proyecto M se muestran 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, en ningún Panel de rendimiento de los proyectos se muestran los datos de pérdida de paquetes correspondiente al par de zonas.
Los datos recopilados a través de todos los sondeos se agregan al Panel de rendimiento. Es decir, el Panel de rendimiento no permite aislar datos sobre la pérdida de paquetes dentro del proyecto en comparación con otros tipos (como la pérdida de paquetes relacionada 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 a tus VMs. Estos trabajadores insertan y reciben paquetes de sondeo que se ejecutan en la misma red que el tráfico. Debido a que los trabajadores se ejecutan en los hosts físicos y no en las VMs, no consumen recursos de VM, y el tráfico no es visible en las VMs.
Los sondeos cubren toda la malla de las VMs 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 pruebas de pérdida de paquetes en la aplicación.
Para todas las VMs sondeadas, Google Cloud intenta acceder a la VM con su dirección IP interna y externa (si existe). Los sondeos no salen de Google Cloud, pero usando direcciones IP externas, el Panel de rendimiento puede abarcar parte de la ruta de acceso que el tráfico externo usa, como el tráfico proveniente de Internet.
La pérdida de paquetes para direcciones IP internas se mide con paquetes UDP, y la pérdida de paquetes para direcciones IP externas se mide con paquetes TCP.
Disponibilidad de métricas y niveles de confianza
El Panel de rendimiento sondea un subconjunto de todos los pares de VM de la red. Luego, los datos recopilados se usan para calcular la pérdida de paquetes que podrías experimentar. La confianza de Google en los datos depende de la tasa de sondeo, y esta depende de la cantidad de VMs que tengas en cada zona, así como de la cantidad de zonas en las que hayas implementado las VMs. Por ejemplo, tener 10 VMs en dos zonas genera más confianza que tener 10 VMs en 10 zonas.
Todas las VMs, incluidas las que crea Google Kubernetes Engine (GKE), se tienen en cuenta para el recuento total de VMs.
En la tabla siguiente, 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 VMs en cada zona | Qué muestra el Panel de rendimiento en el mapa de calor |
|---|---|---|
| Un 95% de confianza | 10 VMs multiplicadas por la cantidad de zonas del proyecto. Por ejemplo, si tienes 12 zonas en el proyecto, debes tener 120 VMs en cada una. | Una medición sin ninguna notación adicional |
| Un 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 VMs en cada una. | 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 con el tráfico del cliente entre los elementos que se indican a continuación:
- VMs dentro de una sola red de VPC
- VMs entre redes de VPC con intercambio de tráfico, si las redes están 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 de ese tráfico no estarán disponibles para el proyecto de servicio ni para el proyecto host.
LatenciaGoogle Cloud
Las métricas de latencia se miden a través del tráfico real del cliente entre los elementos que se indican a continuación:
- VMs dentro de una sola red de VPC
- VMs entre redes de VPC con intercambio de tráfico
- VMs y extremos de Internet
Metodología para la latencia del proyecto y de Google Cloud
La latencia se mide con paquetes TCP.
Según una muestra del tráfico real, la latencia se calcula como el tiempo que
transcurre entre el envío de un número de secuencia (SEQ) de TCP y la recepción de un
ACK correspondiente que contiene el RTT de la red y la demora relacionada 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 las muestras del 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 de TCP, y no a través de sondeos activos desde Google Cloud hasta los extremos de Internet.
Anomalías en las métricas de latencia
Ten en cuenta las siguientes anomalías en las métricas de latencia:
En entornos de baja velocidad, 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 pueden informar de forma incorrecta niveles de latencia altos cuando los servicios basados en TCP devuelven una respuesta con demora a nivel de la aplicación. En general, puedes reconocer los niveles de RTT imprecisos verificando si corresponden a demoras a nivel de la aplicación.
Si bien el servicio basado en TCP responde rápido con un
ACK, el muestreo omite elACKy considera una respuesta de datos posterior como elACKde cierre de un SEND mucho más anterior, lo que distorsiona la medición general del RTT. En estos casos, puedes 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 disparidad puede ocurrir si el conjunto de datos global también incorpora otras rutas de acceso a la red con latencias muy diferentes en relación con la ruta de acceso a la red que el proyecto específico usa.
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 alrededor de 1,000 paquetes por minuto o más.
Tabla de resumen de métricas
En la tabla siguiente, se resumen los métodos y los protocolos de sondeo que se usan para informar las métricas de pérdida de 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) |
| Protocolo | UDP (dirección IP interna), TCP (dirección IP externa) | TCP (direcciones IP internas y externas) |
Vistas de latencia
Los detalles de la 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
La vista de tabla 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 detalles que se indican a continuación:
- País: Indica el nombre del país.
- Ciudades: Indica 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: Indica la cantidad de regiones de destino con tráfico para los usuarios de un país determinado.
- Latencia mediana: Es la mediana del RTT expresada en milisegundos entre el país y las regiones.
Vista de mapa
La vista de mapa muestra las ubicaciones geográficas (áreas metropolitanas o ciudades) y las regiones deGoogle Cloud .
- Consulta la latencia mediana de ubicaciones y regiones Google Cloud.
- Selecciona una región Google Cloud y consulta las ubicaciones con tráfico hacia la región seleccionada.
- Consulta detalles específicos de la ubicación en un gráfico de latencia en la barra lateral.
- Busca ubicaciones con el cuadro de búsqueda del mapa.
Las ubicaciones se clasifican por color en diferentes tonos de azul para indicar los rangos de latencia mediana en el mapa. En la imagen siguiente, el color de un círculo que muestra una ciudad determinada en un mapa global puede ser un tono de azul. Cuanto más oscuro sea el tono de azul, mayor será la latencia de esa ciudad desde una región Google Cloud determinada.
Vista de cronograma
La vista de cronograma muestra la mediana del RTT entre las áreas geográficas y las regiones Google Cloud seleccionadas. Esta proporciona las métricas de latencia actuales y datos históricos correspondientes a seis semanas. Puedes usar los filtros para agregar aún más tráfico a nivel de ciudad, región geográfica y país. Solo puedes ver las métricas de latencia correspondientes a pares específicos de región y ubicación geográfica si hay suficiente tráfico de Google Cloud para ese par.