Ir al contenido
Documentación

Manual de prueba — NoSqlStudio Redis

Una guía paso a paso para conectar a Redis y usar cada pantalla Redis — keyspace, monitor, diagnóstico, mantenimiento, RCA, pub/sub y el control-plane del Cloud.

Tiempo estimado: ~25 minutos
En este manual

Introducción

Una guía paso a paso para ayudarte a conectar a Redis y usar cada pantalla Redis en NoSqlStudio — una superficie de DBA de primera clase para Redis, junto a las herramientas de MongoDB, sin reemplazar ninguna de ellas. Sigue del Paso 1 hasta el final, en orden. Cada paso te dice qué hacer y qué vas a ver.

Concepto

Plan Enterprise

El soporte de Redis (Cloud + on-prem) es parte de la suscripción Enterprise.

Cómo leer este manual

Cada paso tiene:

  • Haz — la acción exacta (hacer clic, escribir, ejecutar tal comando).
  • Mira — qué debe pasar en pantalla. Este es tu “pasa / falla”.
  • Por qué — contexto extra, solo cuando ayuda (sáltalo si tienes prisa).

Antes de empezar

Concepto

Qué es el soporte de Redis

NoSqlStudio habla con Redis vía RESP (el protocolo de cable), no vía MongoDB. Soporta Redis OSS / Valkey on-prem, las topologías Sentinel y Cluster, Redis Enterprise y Redis Cloud. Todo el plano de datos — keyspace, pub/sub, monitor, diagnóstico, mantenimiento — corre contra cualquier Redis alcanzable. El plano de control (REST de Redis Cloud / Enterprise) es una pantalla aparte cubierta en la Etapa 8.

Atención

Los comandos peligrosos están protegidos

Cada comando se clasifica con un gate de seguridad de 3 niveles: HIDDEN (nunca expuesto — SHUTDOWN, FLUSHSLOTS, REPLICAOF ciego…), CONFIRM (confirmación escrita doble + un diff + una entrada de auditoría — FLUSHALL, CONFIG SET, CLIENT KILL, ACL SETUSER…) y SOFT-GUARD (permitido, pero con tope / re-ruta / cancelable — un KEYS * masivo se redirige a SCAN). Te encontrarás este gate en los pasos destructivos.

Vas a necesitar:

  1. 1Un servidor Redis alcanzable — p. ej. Redis OSS 7.x por un puerto local o un túnel SSH. El plano de datos de este manual se validó en vivo contra Redis OSS 7.4.9 standalone.
  2. 2Su string de conexión en formato redis:// (o rediss:// para TLS), más la contraseña / credenciales ACL si el servidor exige auth.
  3. 3Opcionalmente, redis-cli en la misma máquina (por el túnel) para sembrar unas keys de prueba tipadas en la Etapa 2, y una API key/secret de Redis Cloud (o un clúster Redis Enterprise) si quieres validar la Etapa 8.

Tiempo estimado para el recorrido completo: ~25 minutos.

Etapa 1

Conectar a Redis

Agrega una conexión Redis, elige su topología, pruébala y confirma que la barra lateral cambia al formato Redis.

Paso 1

Abre el formulario de conexión y elige Redis

Haz

Abre el gestor de conexiones (Archivo → Conectar…, o el botón Conectar) y haz clic en + Agregar nueva conexión. Arriba del formulario, pon Tipo: Redis (el control segmentado junto a MongoDB).

Mira

El formulario cambia los campos de auth de Mongo por el bloque Redis: un scheme (redis / rediss), un selector de topología, host/puerto, y campos de auth y TLS.

Por qué

El formulario de conexión es multi-motor. Elegir Redis serializa la conexión como un string redis:// con app-params específicos de Redis, marcada como savedConnectionType: redis, para reabrirse como Redis sin sniff.

Paso 2

Elige la topología

Haz

Elige la topología que corresponde a tu servidor: Standalone, Sentinel (da el nombre del master + la lista de sentinels) o Cluster (da los nodos seed).

Concepto

Un formulario, todos los formatos de Redis

El mismo formulario cubre OSS / Valkey on-prem, Sentinel, Cluster, Redis Enterprise y Redis Cloud. Standalone muestra un índice de base SELECT 0..15; Cluster lo oculta (un keyspace lógico sobre slots); Sentinel conecta al master que resuelven los sentinels.

Paso 3

Ingresa host, auth y TLS

Haz

Escribe el host como una URL redis:// — por ejemplo redis://:<contraseña>@127.0.0.1:6379. Para auth, elige none, requirepass (solo contraseña) o ACL (usuario + contraseña). Para TLS usa el scheme rediss y, si hace falta, adjunta la CA / cert+clave de cliente.

Mira

El formulario acepta la URL. La contraseña queda en tu bóveda de secretos local, nunca devuelta al string de conexión que se muestra en la cabecera.

Por qué

La contraseña la resuelve el proceso principal de la app al conectar y se pasa al driver como opción password / username — la URI redis:// guardada en sí queda sin credenciales.

Paso 4

Prueba, luego Conecta

Haz

Haz clic en Test. Luego haz clic en Connect.

Mira

Test devuelve una línea verde como “Conectado — Redis 7.4.9 · standalone · oss”. Connect cierra el modal y la conexión queda connected, con un punto verde en la barra lateral.

Por qué

Al conectar la app sondea la topología — INFO server / INFO replication, CLUSTER INFO, MODULE LIST, ACL WHOAMI — para detectar versión, role, vendor y módulos. Ese sondeo es lo que llena la línea de estado verde.

Paso 5

Confirma que la barra lateral está en formato Redis

Haz

En la barra lateral, expande la conexión Redis (clic en el ).

Mira

Bajo la conexión Redis aparece 🔑 Keyspace Browser (con la nota “navega el keyspace…”) — y no el Details / Users & Roles de Mongo. Expande una conexión MongoDB para confirmar que sigue mostrando Databases / Details / Users & Roles como antes — sin regresión.

Por qué

La barra lateral se protege por tipo de conexión en cada call site, así conexiones Redis y Mongo renderizan sus propios árboles lado a lado. ✅

Etapa 2

Keyspace browser

Navega las keys sin bloquear el servidor, ve y edita todos los tipos de dato de Redis, gestiona TTL y ejecuta comandos crudos en la consola RESP.

Paso 6

Abre el Keyspace Browser

Haz

Haz clic en 🔑 Keyspace Browser en la barra lateral.

Mira

La pestaña Redis Keyspace se abre, enfocada en esta conexión. Su cabecera muestra algo como ● Redis · oss · v7.4.9 · standalone · role:master · DBSIZE: 5000.

Paso 7

Haz el scan del keyspace

Haz

Haz clic en SCAN (sin MATCH). Luego haz clic en Cargar más · cursor N para traer la siguiente página.

Mira

Cerca de 200 keys cargan al instante, cada una con un icono de tipo. Cargar más avanza el cursor y agrega el siguiente lote; cuando el cursor vuelve a 0 ves fin del scan.

Concepto

Nunca bloquea el servidor

La navegación usa `SCAN` iterativo (paginado por cursor, no bloqueante) — nunca el KEYS * bloqueante, que es O(N) y congelaría la única hebra de comandos de Redis. Un lote incluso puede volver vacío con cursor distinto de cero; el browser sigue hasta que el cursor sea 0.

Paso 8

Filtra con un patrón MATCH

Haz

Escribe un glob en el campo SCAN MATCH — por ejemplo k:1* — y haz clic en SCAN.

Mira

Solo las keys que coinciden con el patrón vuelven. Limpia el campo y haz clic en SCAN de nuevo para navegar todo.

Paso 9

Ve una key con su viewer tipado

Haz

Haz clic en una key (por ejemplo k:3610).

Mira

El panel derecho muestra el valor (v3610), un badge de tipo string, el estado de TTL (p. ej. sin TTL) y la memoria por key.

Por qué

Seleccionar una key ejecuta TYPE, la lectura apropiada al tipo (GET / lectura paginada equivalente a HGETALL / ventana de LRANGE…), TTL y un MEMORY USAGE muestreado — solo al seleccionar, nunca durante el scan.

Paso 10

Siembra keys tipadas para los otros viewers

Haz

Si tu keyspace solo tiene strings, crea una key de cada tipo con redis-cli (por el túnel), luego haz *SCAN MATCH `test:`** en la app y haz clic en cada una:

bash·8 linhas
redis-cli -u redis://:<contraseña>@127.0.0.1:6379 <<'CMDS'
SET   test:str    "hola mundo"
HSET  test:hash   name "Marcos" plan "corporate" age 30
RPUSH test:list   a b c d
SADD  test:set    x y z
ZADD  test:zset   100 alice 200 bob 150 carol
XADD  test:stream * tipo creado pedido 8821
CMDS
Mira

Cada tipo recibe su propio viewer: hash → una tabla field/value; list → una tabla índice/valor; set → una lista de miembros; zset → una tabla member/score; stream → entradas más info del stream. Las strings detectan JSON automáticamente en un editor estructurado; los números reciben un stepper.

Concepto

Los módulos necesitan soporte de módulos

Las keys JSON / TimeSeries / Search (RedisJSON, RediSearch, RedisTimeSeries) necesitan los módulos correspondientes cargados. Un Redis OSS puro no tiene ninguno, así que esos comandos fallan ahí — usa un servidor redis-stack para ejercitar los viewers de módulo.

Paso 11

Edita un valor string (preservando su TTL)

Haz

Selecciona una key descartable como k:101. Su valor se vuelve un textarea editable — cambia el texto (p. ej. valor-de-prueba) y haz clic en Guardar (SET KEEPTTL).

Mira

El viewer reabre mostrando el nuevo valor, y cualquier TTL existente se preserva.

Por qué

Las ediciones usan SET … KEEPTTL a propósito: un SET simple borraría silenciosamente el TTL de la key. El editor siempre lo preserva.

Paso 12

Pon y quita un TTL

Haz

En el campo TTL s escribe 60 y haz clic en EXPIRE. Luego haz clic en PERSIST.

Mira

Tras EXPIRE el badge se vuelve TTL 60s y la lista muestra 60s junto a la key. Tras PERSIST el badge vuelve a sin TTL.

Paso 13

Borra una key con UNLINK

Haz

Con k:101 seleccionada, haz clic en UNLINK. Aparece un modal de confirmación — haz clic en Confirmar.

Mira

La key desaparece de la lista y el DBSIZE baja en 1.

Atención

Los comandos destructivos tienen confirmación escrita

El borrado usa `UNLINK` (asíncrono, no bloqueante) en vez de DEL, y está protegido: el modal de confirmación es el nivel CONFIRM del gate de seguridad. El mismo gate protege FLUSHDB / RENAME (sobrescritura) / LTRIM / XTRIM.

Paso 14

Cambia a read-only

Haz

Haz clic en el toggle 🔓 Editable → 🔒 Read-only, luego selecciona una key.

Mira

El textarea editable y los botones EXPIRE / PERSIST / UNLINK desaparecen — la key queda solo de lectura. Vuelve a 🔓 para reactivar la edición.

Por qué

El modo read-only viene activado por defecto en conexiones con prod-tag, para que no escribas por error en producción mientras navegas.

Paso 15

Ejecuta comandos crudos en la consola RESP

Haz

Abre la consola RESP y ejecuta un par de comandos crudos:

text·4 linhas
TYPE test:hash
HGETALL test:hash
OBJECT ENCODING test:zset
MEMORY USAGE test:list SAMPLES 5
Mira

La respuesta de cada comando se renderiza en la consola. Los comandos destructivos escritos aquí siguen pasando por el mismo gate de seguridad — KEYS * se redirige a SCAN, y FLUSHALL exige confirmación escrita.

Etapa 3

Monitor en tiempo real

Un dashboard en vivo guiado por INFO de cómo se está comportando la instancia ahora mismo.

Paso 16

Abre el dashboard en tiempo real

Haz

Desde el menú de monitoreo Redis (o el menú contextual de la conexión → Abrir Real-Time), abre el Real-Time Dashboard.

Mira

Un dashboard en vivo empieza a hacer polling, con sparklines que se llenan a lo largo de los próximos ticks.

Por qué

El dashboard hace polling de INFO en un temporizador y parsea cada sección. Los contadores acumulativos se convierten en tasas (delta ÷ tiempo); los gauges y campos de estado se leen tal cual.

Paso 17

Lee los tiles en vivo

Haz

Observa los tiles mientras algo escribe en Redis (tu bucle de redis-cli o tráfico normal).

  • Ops/seg y red in/out como tasas en vivo.
  • Gauge de hit-ratio calculado sobre el delta (no el lifetime).
  • Memoria usada vs maxmemory con util %, más el ratio de fragmentación (avisa por encima de 1.5, crítico por encima de 2.0, y por debajo de 1.0 = swap = crítico).
  • Evictions / expirations, clientes conectados / bloqueados, replicación offset-lag y master_link_status, chips de estado de persistencia, CPU y el último tiempo de fork.
Mira

Los contadores se mueven como tasas, y un gauge cambia de color por valor — así un problema de util de memoria o fragmentación se ve de un vistazo.

Paso 18

Sobrevive a un restart limpiamente

Por qué

Si el servidor reinicia o ejecutas CONFIG RESETSTAT, el dashboard nota el cambio de run_id / caída de uptime, descarta ese delta y re-baseliniza en vez de dibujar un pico falso. No tienes que hacer nada — las tasas se mantienen honestas.

Etapa 4

Slowlog & Latencia (Diagnóstico)

Encuentra los comandos lentos, ve qué culpa el propio Redis por la latencia, e inspecciona o mata conexiones de clientes.

Paso 19

Abre el viewer de Slowlog

Haz

Abre el panel Slowlog (Diagnóstico). Hace tail de `SLOWLOG GET`.

Mira

Una tabla append-only se llena con los comandos más lentos — cada fila muestra la duración, el comando y sus args — con un marcador “N new” y un rollup por comando. Haz clic en una fila para abrir los args completos.

Por qué

Las entradas se de-duplican por id de slowlog, así el re-polling solo agrega comandos lentos genuinamente nuevos.

Paso 20

Lee el doctor de latencia

Haz

Abre el panel Latency. Ejecuta `LATENCY LATEST` / `LATENCY HISTORY` y `LATENCY DOCTOR`.

Mira

Cards por evento (fork, aof-fsync, expire, eviction, defrag…) con una timeline de picos, más el veredicto del DOCTOR en lenguaje sencillo.

Concepto

Qué significan los picos de latencia

Redis ejecuta comandos en una sola hebra, así que un pico suele ser un evento bloqueante detrás de ella: un fork lento para un save, una parada de AOF fsync, expiración/eviction masiva de keys, o defrag activo. El nombre del evento en el pico apunta directo a la causa.

Paso 21

Inspecciona y mata clientes

Haz

Abre el panel Clients. Toma un snapshot de `CLIENT LIST`. Filtra la tabla, luego (si hace falta) selecciona una conexión y haz clic en Kill.

Mira

Una tabla virtualizada de conexiones — dirección, nombre, edad, idle, flags, db, memoria de buffer de salida, usuario y librería cliente. Kill pide una confirmación escrita primero.

Por qué

CLIENT KILL es un comando de nivel CONFIRM, así que matar una conexión exige una confirmación deliberada — sin desconexiones accidentales.

Etapa 5

Mantenimiento & Ops

Lee y cambia la configuración, analiza memoria, dispara saves en background y gestiona usuarios ACL — todo detrás del gate de seguridad.

Paso 22

Edita la configuración

Haz

Abre el panel Config. Muestra *`CONFIG GET ** agrupado por área, con un indicador **dirty vs persisted**. Cambia un parámetro y aplícalo (**CONFIG SET`), luego haz clic en REWRITE** para persistirlo al archivo de config.

Mira

Aparece una confirmación escrita doble mostrando el diff old → new antes de aplicar el cambio; después el log de auditoría lo registra y REWRITE limpia el marcador dirty.

Atención

Las ops pasan por el gate de seguridad de 3 niveles

Los comandos de mantenimiento se clasifican: CONFIRM = confirmación escrita doble + un diff + una entrada de auditoría (CONFIG SET/REWRITE, CLIENT KILL, ACL SETUSER/DELUSER, MEMORY PURGE); SOFT-GUARD = permitido pero con tope / cancelable (un scan de big-keys presupuesta el total de llamadas MEMORY USAGE). En Redis gestionado (Cloud) algunas keys de CONFIG están bloqueadas y el panel cambia al control-plane REST.

Paso 23

Analiza la memoria y encuentra big keys

Haz

Abre el panel Memory. Lee el veredicto del `MEMORY DOCTOR` y el desglose dataset-vs-overhead, luego ejecuta el finder de big-keys.

Mira

El veredicto del DOCTOR, los ratios de fragmentación, y una tabla de big-keys (key, tipo, encoding, cardinalidad, memoria) que se llena con una barra de progreso que puedes cancelar.

Por qué

El finder de big-keys es clean-room: hace SCAN y muestrea `MEMORY USAGE … SAMPLES 5` por key (nunca un barrido O(N) completo), presupuestando el total de llamadas para nunca sobrecargar el servidor.

Paso 24

Dispara la persistencia

Haz

Abre el panel Persistence. Muestra INFO persistence, LASTSAVE y DBSIZE. Haz clic en BGSAVE (snapshot RDB) o BGREWRITEAOF (compactar el AOF).

Mira

El save / rewrite en background empieza y el panel refleja el nuevo estado de LASTSAVE / AOF cuando termina.

Concepto

En background, no bloqueante

`BGSAVE` y `BGREWRITEAOF` hacen fork de un hijo para que la hebra principal siga sirviendo. Los bloqueantes SAVE y DEBUG RELOAD están HIDDEN por el gate. En OSS, restaurar desde un backup es advisory (archivo + restart) — Cloud/Enterprise lo hacen vía REST.

Paso 25

Gestiona usuarios ACL

Haz

Abre el panel ACL. Ejecuta `ACL LIST` / `ACL GETUSER` / `ACL CAT` / `ACL WHOAMI`. Crea o edita un usuario (`ACL SETUSER`) o borra uno (`ACL DELUSER`).

Mira

La lista de usuarios con las reglas de cada uno; crear/editar/borrar piden una confirmación escrita, y la entrada de auditoría redacta cualquier >password / #hash para que los secretos nunca caigan en el log.

Por qué

El panel renderiza por capacidad — los botones se vuelven grises donde tu propio ACL niega la acción o el comando fue renombrado — así solo ves lo que realmente puedes hacer.

Etapa 6

DBA · RCA (causa raíz)

La pantalla estrella del DBA: un clic ejecuta un barrido de salud completo y te entrega hallazgos rankeados con evidencia y una acción recomendada — y, opcionalmente, una explicación por IA.

Paso 26

Ejecuta un barrido de salud

Haz

Abre la pantalla DBA · RCA y haz clic en el barrido de salud de un clic.

Mira

Una sola pasada recolecta sobre memoria, latencia, persistencia, cluster y replicación, y luego devuelve una lista de hallazgos rankeados.

Por qué

En vez de que abras cinco paneles y los correlaciones a mano, el barrido junta las señales una vez y rankea lo que de verdad está mal.

Paso 27

Lee la evidencia y la acción de un hallazgo

Haz

Haz clic en el hallazgo principal para expandirlo.

Mira

Cada hallazgo lleva su evidencia (las métricas / líneas de log que lo dispararon) y una acción recomendada, con la causa raíz puesta en una timeline en vivo para que veas correlaciones entre memoria / latencia / persistencia / cluster / replicación.

Paso 28

Opcionalmente, pide a la IA que lo explique

Haz

Si tienes un modelo configurado, haz clic en AI analysis en el hallazgo.

Mira

Aparece una explicación en lenguaje sencillo y un resumen de remediación, construidos a partir de la misma evidencia.

Concepto

Trae tu propio LLM, el modelo más barato

El análisis por IA es opcional y usa tu propio LLM configurado (BYO-LLM). Elige automáticamente el modelo capaz más barato, para que la explicación cueste lo mínimo posible — y nada sale de tu configuración si no lo habilitas.

Etapa 7

Pub/Sub

Haz tail de canales y patrones en vivo, y publica mensajes de prueba desde un publisher embebido para verlos llegar.

Paso 29

Suscríbete a un canal

Haz

Abre el panel Pub/Sub. Descubre los canales activos (usa PUBSUB CHANNELS), luego suscríbete a uno con `SUBSCRIBE`, o a un patrón con `PSUBSCRIBE` (p. ej. news.*).

Mira

Un tail en vivo empieza — los mensajes entrantes fluyen a un buffer con scroll, los más nuevos primero.

Por qué

El tail corre en una conexión de subscriber dedicada (una duplicada de la conexión de datos), porque un socket suscrito solo acepta comandos de subscribe/ping. Tu conexión de navegación nunca queda ocupada.

Paso 30

Publica un mensaje de prueba

Haz

En el publisher embebido, envía un mensaje al canal que estás haciendo tail:

text·1 linha
PUBLISH news.sports "hola desde NoSqlStudio"
Mira

El mensaje aparece arriba del tail en vivo en un instante. El buffer tiene tope (los más antiguos se descartan) y puedes pausar / auto-detener para que nunca crezca sin límite.

Etapa 8

Redis Cloud & Enterprise (plano de control)

Conecta el plano de control REST para gestionar subscriptions y bases — y salta de vuelta al plano de datos con un string de conexión generado.

Paso 31

Conecta el plano de control REST

Haz

Abre la pantalla Redis Cloud. Para Redis Cloud, ingresa la API key y la secret key de tu cuenta (contra api.redislabs.com). Para Redis Enterprise, apunta al endpoint REST del clúster en el puerto `:9443` con sus credenciales.

Mira

El plano de control autentica y lista las subscriptions × bases de tu cuenta.

Atención

Esta etapa necesita infra Cloud / Enterprise real

Todo el plano de datos (Etapas 1–7) se validó en vivo contra Redis OSS 7.4.9. El plano de control está construido y empaquetado pero solo se puede validar con una cuenta Redis Cloud real (API key/secret) o un clúster Redis Enterprise. Con un servidor OSS puro no hay nada a lo que esta pantalla pueda conectar. La secret key queda solo del lado del main y nunca se envía a la UI.

Paso 32

Explora subscriptions, bases y módulos

Haz

Baja de una subscription a sus bases. Abre una base para ver sus módulos y cualquier geo-distribución Active-Active (CRDB).

Mira

Detalles por base — memoria, eviction, persistencia, módulos, replicación — más, para una base Active-Active, los clústeres participantes y las regiones. Active-Active es solo plano de control: una única conexión de datos solo alcanza una región.

Paso 33

Un clic al plano de datos

Haz

En una base del cloud, haz clic en Connect this database.

Mira

Se genera un string de conexión redis:// (aquí rediss://) y el formulario de conexión se pre-llena con vendor redis-cloud — conéctalo para aterrizar en el Keyspace Browser de la Etapa 2 contra esa base.

Por qué

Esto tiende el puente entre los dos planos: descubre bases vía REST, luego salta al plano de datos en vivo de cualquiera de ellas sin copiar detalles de conexión a mano. ✅

Limpieza (cuando termines)

Haz

Borra las keys de prueba que creaste, luego cierra las pestañas Redis. Desde la consola RESP o redis-cli:

text·2 linhas
UNLINK k:101
UNLINK test:str test:hash test:list test:set test:zset test:stream
Mira

Las keys de prueba desaparecen y el DBSIZE baja en consecuencia.

Concepto

Tu conexión Redis y sus secretos (contraseñas, API keys del Cloud) viven en tu perfil local — cerrar las pestañas no los borra. Quita la conexión guardada del gestor de conexiones si quieres eliminarlos.

Resumen de lo que validaste

PantallaQué puedes hacer
1Conectar a Redis (Standalone / Sentinel / Cluster, TLS, auth) y tener una barra lateral en formato Redis
2Keyspace Browser: SCAN no bloqueante, viewers + editores tipados, TTL, memoria por key, UNLINK, consola RESP
3Monitor en tiempo real: dashboard de INFO en vivo con tasas, gauges y alertas
4Diagnóstico: Slowlog, Latency DOCTOR, e inspeccionar/matar clientes
5Mantenimiento & Ops: CONFIG GET/SET/REWRITE, memoria + big-keys, BGSAVE/BGREWRITEAOF, ACL — todo protegido
6DBA · RCA: barrido de salud de un clic, hallazgos rankeados con evidencia, análisis BYO-LLM opcional
7Pub/Sub: tail en vivo de canales y patrones con un publisher embebido
8Plano de control Redis Cloud & Enterprise: subscriptions × bases, módulos, conexión de un clic
Si cada paso dio el “Mira” esperado, las pantallas Redis están validadas de extremo a extremo en tu servidor. El plano de datos está probado contra Redis OSS 7.4.9; el plano de control del Cloud (Etapa 8) necesita una cuenta Redis Cloud o Enterprise real para confirmar. Anota el número del paso de cualquier discrepancia para que podamos corregirla.