Si bien Memorystore para Redis proporciona métricas en tiempo real del servidor para supervisar la capacidad de procesamiento, el uso de CPU y el uso de memoria, es posible que estos datos por sí solos no expliquen por qué tu aplicación cliente experimenta una latencia alta dentro de sistemas distribuidos complejos.
Las métricas del cliente resuelven este problema, ya que proporcionan transparencia en el ciclo completo de solicitud-respuesta. Miden un comando desde el momento en que la aplicación lo inicia hasta que la aplicación procesa la respuesta. Si capturas estos puntos de datos, puedes determinar con precisión si la latencia se origina en la lógica de la aplicación, la ruta de red o el servidor de Redis.
Antes de comenzar
Asegúrate de que tu aplicación cliente use una cuenta de servicio y que se le asignen los siguientes roles de Identity and Access Management (IAM):
roles/cloudtrace.agent(agente de Cloud Trace)roles/monitoring.metricWriter(escritor de métricas de Monitoring)
Para obtener más información para otorgar roles, consulta la guía de inicio rápido Otorga un rol de IAM con la Google Cloud consola.
Habilita la API de Cloud Monitoring
Para exportar métricas del cliente a Monitoring, tu aplicación requiere que la API de Monitoring esté habilitada. Exportar y visualizar estas métricas en Monitoring te permite identificar la causa raíz de los cuellos de botella para determinar si se origina la latencia.
Para habilitar la API de Monitoring, haz lo siguiente:
En la Google Cloud consola de, ve a la página APIs y servicios.
Selecciona el proyecto en el que creaste la instancia de Memorystore para Redis.
Haz clic en Habilitar las APIs y los servicios.
Busca
monitoring.En los resultados de la búsqueda, haz clic en API de Cloud Monitoring.
Si aparece API habilitada, la API ya está habilitada. De lo contrario, haz clic en Habilitar.
Habilita la API de Cloud Trace
Para ver seguimientos distribuidos en Trace, debes habilitar la API de Trace. Luego, puedes usar el Explorador de Trace para ver estos seguimientos, diagnosticar cuellos de botella y aislar la fuente de latencia en tu aplicación.
Para habilitar la API de Trace, haz lo siguiente:
En la Google Cloud consola de, ve a la página APIs y servicios.
Selecciona el proyecto en el que creaste la instancia de Memorystore para Redis.
Haz clic en Habilitar las APIs y los servicios.
Busca
trace.En los resultados de la búsqueda, haz clic en API de Cloud Trace.
Si aparece API habilitada, la API ya está habilitada. De lo contrario, haz clic en Habilitar.
Habilita las métricas del cliente
Para habilitar las métricas del cliente, agrega el OpenTelemetry de OpenTelemetry, el exportador de Cloud Monitoring y el exportador de Cloud Trace al código de tu aplicación. La instrumentación de OpenTelemetry, que se ejecuta directamente dentro de la biblioteca cliente de Redis de tu aplicación, captura las métricas. Esto permite que tu aplicación registre puntos de datos de latencia y los exporte a Monitoring y Trace para su visualización.
Para habilitar las métricas del cliente, puedes usar Go, Java, Node.js, o Python. La información para habilitar las métricas de cada lenguaje aparece en las siguientes pestañas.
Go
Para instalar las dependencias requeridas de OpenTelemetry y Google Cloud exporter, ejecuta los siguientes comandos en tu terminal:
go get github.com/gomodule/redigo/redis@latest go get go.opentelemetry.io/otel go get go.opentelemetry.io/otel/sdk/trace go get go.opentelemetry.io/otel/sdk/metric go get github.com/GoogleCloudPlatform/opentelemetry-operations-go/exporter/trace go get github.com/GoogleCloudPlatform/opentelemetry-operations-go/exporter/metric
Para habilitar las métricas del cliente, crea un archivo
main.goy agrégale el siguiente código:Ejecuta tu aplicación durante al menos un minuto para darle al exportador el tiempo suficiente para agrupar y enviar las métricas publicadas a Monitoring.
Java
Para instalar las dependencias requeridas de OpenTelemetry y Google Cloud exporter dependencies, agrega el siguiente código al archivo
pom.xmlde tu aplicación:Para habilitar las métricas del cliente, crea un archivo
RedisTelemetryApp.javay agrégale el siguiente código:Ejecuta tu aplicación durante al menos un minuto para darle al exportador el tiempo suficiente para agrupar y enviar las métricas publicadas a Monitoring.
Node.js
Para instalar las dependencias requeridas de OpenTelemetry y Google Cloud exporter, ejecuta los siguientes comandos en tu terminal:
npm install redis@^4.6.0 @opentelemetry/api@^1.9.0 @opentelemetry/sdk-trace-node@^2.1.0 @opentelemetry/sdk-trace-base@^2.1.0 @opentelemetry/sdk-metrics@^2.1.0 @opentelemetry/instrumentation@^0.205.0 @opentelemetry/instrumentation-redis@^0.67.0 @google-cloud/opentelemetry-cloud-trace-exporter@^3.0.0 @google-cloud/opentelemetry-cloud-monitoring-exporter@^0.21.0 @opentelemetry/resources@^2.1.0
Para habilitar las métricas del cliente, crea un archivo
server.jsy agrégale el siguiente código:Ejecuta tu aplicación durante al menos un minuto para darle al exportador el tiempo suficiente para agrupar y enviar las métricas publicadas a Monitoring.
Python
Para instalar las dependencias requeridas de OpenTelemetry y Google Cloud exporter, ejecuta los siguientes comandos en tu terminal:
pip install redis==7.0.1 opentelemetry-api==1.39.1 opentelemetry-sdk==1.39.1 opentelemetry-instrumentation-redis==0.60b1 opentelemetry-exporter-gcp-trace==1.11.0 opentelemetry-exporter-gcp-monitoring==1.11.0a0
Para habilitar las métricas del cliente, crea un archivo
main.pyy agrégale el siguiente código a tu aplicación:Ejecuta tu aplicación durante al menos un minuto para darle al exportador el tiempo suficiente para agrupar y enviar las métricas publicadas a Monitoring.
Visualiza métricas en Monitoring
Después de habilitar las métricas del cliente y ejecutar tu aplicación durante al menos un minuto para darle al exportador el tiempo suficiente para agrupar y enviar métricas a Monitoring, usa Monitoring para visualizar tus métricas, agruparlas por operación o instancia y aplicar agregadores para supervisar el rendimiento de tu aplicación.
Para ver las métricas en Monitoring, haz lo siguiente:
En la Google Cloud consola de, ve a la página Explorador de métricas.
Seleccionar tu Google Cloud proyecto.
Haz clic en Selecciona una métrica.
Busca
workload.googleapis.com/redis.Selecciona una métrica del cliente. Agrupa los datos por
operationyinstancesegún sea necesario, y elige un agregador. Para explorar más opciones, consulta Selecciona métricas cuando uses el Explorador de métricas.
Visualiza seguimientos distribuidos en Trace
Después de que tu aplicación comience a exportar datos, puedes usar Trace para visualizar el ciclo completo de solicitud-respuesta de tus comandos de Redis. Ver tus seguimientos distribuidos en Trace te permite diagnosticar cuellos de botella para que puedas aislar rápidamente la fuente exacta de latencia en tu aplicación.
Para ver seguimientos distribuidos en Trace, haz lo siguiente:
En la Google Cloud consola de, ve a la página Explorador de seguimiento.
Selecciona un seguimiento reciente representado por un punto en el diagrama de dispersión.
Examina la vista de cascada para aislar la fuente de latencia. Para ello, identifica los siguientes cuellos de botella:
Duración total de la solicitud: La barra de nivel superior (superior) muestra el tiempo total que debes esperar para que finalice la operación.
Latencia de red y servidor (RTT): Las barras secundarias (como las etiquetadas como
GEToSET) muestran el tiempo que el comando pasó viajando por la red y ejecutándose en el servidor de Memorystore para Redis.Bloqueo de conexión del cliente: Si hay un espacio horizontal grande y vacío antes de que comience el intervalo secundario de Redis, el subproceso de la aplicación se queda esperando una conexión TCP disponible del grupo de conexiones.
Bloqueo de análisis de la aplicación: Si hay un espacio horizontal grande y vacío después de que finaliza el intervalo secundario de Redis, la aplicación tiene problemas para analizar o procesar la carga útil que se muestra. Esto ocurre a menudo con las cadenas JSON de varios megabytes.
Reintentos: Si ves varios intervalos secundarios cortos para el mismo comando que ocurren de forma secuencial dentro del mismo seguimiento superior, es posible que tu cliente experimente una pérdida de paquetes de red y deba activar su bucle de reintento de retirada exponencial.
Solucionar problemas
En esta sección, se enumeran los problemas de rendimiento comunes que puedes identificar con las métricas del cliente, se explican sus causas raíz y se proporcionan instrucciones para solucionar los problemas.
| Problema | Causa | Solucionar problemas |
|---|---|---|
Tu aplicación experimenta un aumento repentino de la latencia, pero Memorystore para Redis parece estar en perfecto estado.
|
El cuello de botella está estrictamente dentro de tu aplicación. Tus
subprocesos intentan ejecutar comandos de Redis, pero el grupo de conexiones está completamente
agotado. La alta redis_client_blocking_latency representa
el tiempo que tu código pasa esperando un socket TCP disponible antes de que se
envíe el comando a la red. |
Para controlar el tráfico simultáneo más alto, aumenta los
límites de tamaño del grupo de conexiones en la configuración de tu cliente de Redis (por ejemplo,
MaxActive para Go, MaxTotal para Java o
max_connections para Node.js y Python). |
La solicitud se completa, pero el extremo tarda mucho más de lo esperado No hay problemas asociados con el estado de tu red o servidor.
|
Memorystore para Redis ejecuta el comando y la red transfiere la
carga útil rápidamente (RTT bajo). Sin embargo, la carga útil que se muestra es grande (por
ejemplo, una cadena JSON de 15 MB). Tu aplicación experimenta una
redis_application_blocking_latency alta porque la aplicación
consume recursos excesivos mientras asigna memoria y deserializa esa
cadena grande en un objeto. |
Optimiza tu modelo de datos. No almacenes objetos JSON masivos en claves únicas.
Divide los datos con hashes de Redis (HSET) y usa
HGET o HMGET para recuperar solo los campos específicos
que necesitas.
|
La latencia de tu aplicación orientada al usuario aumenta, pero tus métricas de Redis informan una latencia baja del servidor y extracciones típicas del grupo de conexiones.
|
Debido a que redis_client_rtt solo captura el RTT de las solicitudes exitosas, no refleja la duración del tiempo de espera de un paquete fallido. Cuando tu aplicación experimenta caídas de paquetes transitorias o restablecimientos de TCP, la lógica de reintento de tu cliente instrumentado incrementa el
redis_retry_count y activa su bucle de retirada exponencial.
Esto introduce un tiempo de suspensión entre los intentos (por ejemplo,
100ms, 200ms, o 400ms). El usuario
experimenta una latencia total alta, pero la causa raíz subyacente es una pérdida de paquetes de red, que activa retrasos de suspensión del cliente. |
Consulta tus registros de flujo de VPC para ver si hay paquetes descartados, limitación de ancho de banda,
o anomalías de enrutamiento entre regiones. Si experimentas tiempos de espera agresivos,
asegúrate de que los tiempos de espera de conexión del cliente (socket_timeout o
connect_timeout) sean mayores que el RTT esperado para tener en cuenta
la fluctuación de red transitoria. |
Todo se detiene y todas las capas de la canalización de telemetría informan latencia alta.
|
Redis tiene un solo subproceso. Cuando ejecutas un comando de complejidad temporal O(N)
(como KEYS *, SMEMBERS
en un conjunto masivo o HGETALL en un hash con millones de
campos), el motor de Redis se detiene para cumplir con esa solicitud. Mientras se ejecuta ese comando, todas las demás solicitudes de la aplicación se ponen en cola, lo que provoca un aumento de la latencia
en todo el sistema. Debido a que tu redis_client_rtt personalizado coincide con la latencia del servidor (commands/usec_per_call), el servidor que ejecuta el comando es el cuello de botella. |
Abre Trace y observa los comandos de Redis en los intervalos lentos para identificar qué consulta causa el bloqueo. Reemplaza los comandos de bloqueo por comandos que no bloqueen en tu código. Para iterar a través de conjuntos de datos grandes de forma incremental sin bloquear el
subproceso del servidor, usa |
Tu aplicación informa una latencia de referencia constante y elevada para todos los comandos de Redis, incluso cuando el tráfico es bajo.
|
El servidor de Redis ejecuta comandos al instante, pero tu aplicación y tu
instancia se implementan en diferentes regiones (por ejemplo,
us-central1 y us-east1). Cada paquete de red
debe viajar a través de la infraestructura de nube física de Google Cloud entre estos
centros de datos geográficos. Esto da como resultado una penalización de latencia entre regiones obligatoria de la velocidad de la luz
para cada viaje de ida y vuelta. |
Para reducir la latencia, implementa tu aplicación para que resida en la misma región y zona que tu instancia. Para ver la región de tu aplicación y instancia, usa la Google Cloud consola. |
¿Qué sigue?
- Obtén más información sobre las métricas del cliente.
- Obtén información sobre las métricas del cliente que están disponibles para Memorystore para Redis.