Observar, diagnosticar y crecer con motivo

Un Redis rápido por dentro puede ofrecer respuestas lentas si el pool está agotado, la red tiene problemas o el cliente recibe valores enormes. Separa tiempo de adquirir conexión, viaje completo del comando, tamaño de respuesta y tiempo de deserialización. Observa percentiles, especialmente p95/p99, además de promedio: una media buena puede ocultar peticiones que agotan su plazo.

Registra contadores por operación y motivo de fallo, sin claves sensibles ni cuerpos completos. Un identificador de trabajo permite unir productor, consumidor y receptor. No registres contraseñas ni la URL Redis completa si contiene credenciales. Añade nombre de entorno y servicio para no mezclar una caída de pruebas con producción.

docker exec redis-practica redis-cli INFO stats
docker exec redis-practica redis-cli INFO memory
docker exec redis-practica redis-cli INFO clients
docker exec redis-practica redis-cli INFO persistence
docker exec redis-practica redis-cli SLOWLOG GET 10

Señal	Interpretación inicial	Qué comprobar después
keyspace_hits, keyspace_misses	Aciertos/ausencias de búsquedas	Deltas del intervalo y métricas por función de caché
evicted_keys creciendo	Se expulsan claves por memoria	Política, cardinalidad, tamaños y TTL
expired_keys creciendo	Vencen claves	Si era esperado o caducaron juntas
used_memory, RSS, pico	Memoria lógica y física	Buffers, fragmentación, forks y límite del host
Conexiones/bloqueados	Clientes y esperas bloqueantes	Fugas, pools y consumidores que esperan mensajes
Estados de RDB/AOF	Éxito de escrituras de persistencia	Disco, permisos, espacio y latencia de almacenamiento
SLOWLOG	Comandos cuyo trabajo interno superó el umbral	Tamaño de operaciones y scripts; no incluye todo el viaje de red

Estos contadores suelen acumularse desde arranque o reset. Para un hit ratio de un minuto, resta las dos mediciones: Δhits / (Δhits + Δmisses). Si el denominador es cero, no hubo observaciones útiles. Los accesos internos de otras funciones también pueden contribuir: añade métricas de aplicación para saber si una caché concreta ayuda.

Si sube la latencia, comprueba primero si se agotó el pool y si Redis recibe tráfico. Después compara carga, errores y memoria con el periodo normal. Un incremento de misses puede explicar que ahora el cuello de botella sea la base de datos, aunque Redis funcione bien. Un OOM con noeviction es diferente de un timeout o de un error de permisos.

Si hay un comando lento, identifica su tamaño y patrón: ¿se pidió HGETALL de un hash enorme?, ¿un LRANGE 0 -1?, ¿un script recorre miles de elementos?, ¿un pipeline agrupa demasiadas respuestas? Limitar tamaño y paginar suele ser más útil que añadir otro servidor a ciegas.

MONITOR muestra comandos en vivo, pero añade carga y puede revelar valores sensibles. No lo dejes permanentemente activado como sistema de logs. SLOWLOG también puede contener argumentos: restringe su acceso y retención. Para depurar una consulta concreta, reproduce primero el patrón con datos de prueba.

XLEN informes:trabajos
XINFO GROUPS informes:trabajos
XINFO CONSUMERS informes:trabajos generadores
XPENDING informes:trabajos generadores
XPENDING informes:trabajos generadores - + 10

Ejecuta esos comandos con redis-cli cuando hayas creado el mini proyecto. XLEN incluye historial, no solo trabajo pendiente. El lag del grupo estima entradas todavía no entregadas; en ciertas situaciones puede ser desconocido. La PEL registra entregadas sin confirmar. Necesitas las dos perspectivas para ver tanto falta de consumidores como consumidores que reciben y se atascan.

Mide edad del trabajo más antiguo, tiempo de procesamiento, reentregas, rechazos permanentes y diferencia entre intenciones registradas e informes terminados. Una tasa de ACK alta no prueba éxito si el código confirma antes de aplicar el efecto. Por eso el mini proyecto permite comprobar directamente las filas del receptor.

Anota tamaño medio y máximo del mensaje, mensajes por segundo, tiempo de cada efecto y retención. Si entran veinte trabajos por segundo y cada trabajador completa cinco, cuatro apenas mantienen el ritmo: no queda margen para picos, pausas o recuperación. El límite real puede ser la base receptora, no Redis.

Prueba un lote con la distribución de tamaños real, varios consumidores, Redis reiniciado y el receptor temporalmente indisponible. Mide tiempo hasta vaciar el atraso y recursos durante la recuperación. Un benchmark de SET con valores diminutos no estima un servicio con JSON grande, AOF, TLS y consultas externas.

Define alertas por impacto: pendientes de más de un plazo admitido, persistencia fallando, memoria sin margen, rechazos por capacidad y ausencia de progreso. Un umbral absoluto de número de claves sin relación con tamaño o carga suele avisar tarde o molestar sin motivo.

Necesidad	Pieza	Cambio que debes asumir
Mantener una copia operativa	Réplica	Puede ir retrasada; no sustituye un backup
Detectar caída y promover una réplica	Sentinel	Cliente debe descubrir el primario y reconectar; failover puede perder escrituras
Repartir el conjunto de datos entre nodos	Cluster	Cliente consciente del cluster, slots y restricciones sobre operaciones multiclave

Sentinel coordina descubrimiento y failover de un primario con réplicas. Los observadores deben repartirse entre fallos independientes; tres procesos en un mismo portátil no ofrecen disponibilidad ante la pérdida del portátil. Después de un cambio, conexiones y operaciones en vuelo pueden fallar o tener resultado incierto: tu aplicación sigue necesitando reintentos seguros y reconexión.

Redis Cluster reparte claves entre 16.384 slots. Una operación atómica que toque varias claves normalmente necesita que compartan slot. Un hash tag, como {usuario-42} dentro de limite:{usuario-42} y estado:{usuario-42}, permite agruparlas. Poner todas las claves bajo el mismo tag vacía de sentido el reparto y puede crear un nodo caliente. Tampoco reparte una sola clave enorme entre todos los nodos.

No necesitas desplegar un cluster para completar este recorrido. Primero separa caché/cola, limita datos, mide la instancia, ensaya restore y considera un servicio gestionado si su operación te aporta más que mantener varios servidores. La escala distribuida se justifica cuando una instancia bien dimensionada no alcanza el conjunto o la disponibilidad necesaria, y aceptas sus nuevas restricciones.

Las guías oficiales de Sentinel y Redis Cluster explican sus procedimientos. Aquí hemos fijado el mapa para tomar una decisión; el mini proyecto siguiente integra un alcance que puedes operar y verificar personalmente, sin fingir un despliegue distribuido que no se ha realizado.