Introdução
Um guia passo a passo para te ajudar a conectar ao Redis e usar cada tela Redis no NoSqlStudio — uma superfície de DBA de primeira classe para Redis, ao lado das ferramentas MongoDB, sem substituir nenhuma delas. Siga do Passo 1 até o fim, em ordem. Cada passo diz o que fazer e o que você vai ver.
Conceito
Plano Enterprise
O suporte a Redis (Cloud + on-prem) faz parte da assinatura Enterprise.
Como ler este manual
Cada passo tem:
- Faça — a ação exata (clicar, digitar, rodar tal comando).
- Veja — o que deve acontecer na tela. Este é o seu “passou / falhou”.
- Por quê — contexto extra, só quando ajuda (pule se estiver com pressa).
Antes de começar
Conceito
O que é o suporte a Redis
O NoSqlStudio fala com o Redis via RESP (o protocolo de fio), não via MongoDB. Ele suporta Redis OSS / Valkey on-prem, as topologias Sentinel e Cluster, o Redis Enterprise e o Redis Cloud. Todo o plano de dados — keyspace, pub/sub, monitor, diagnóstico, manutenção — roda contra qualquer Redis alcançável. O plano de controle (REST do Redis Cloud / Enterprise) é uma tela separada coberta na Etapa 8.
Atenção
Comandos perigosos são protegidos
Todo comando é classificado por um gate de segurança de 3 níveis: HIDDEN (nunca exposto — SHUTDOWN, FLUSHSLOTS, REPLICAOF cego…), CONFIRM (confirmação digitada dupla + um diff + um registro de auditoria — FLUSHALL, CONFIG SET, CLIENT KILL, ACL SETUSER…) e SOFT-GUARD (permitido, mas com cap / re-rota / cancelável — um KEYS * em massa é redirecionado para SCAN). Você vai encontrar esse gate nos passos destrutivos.
Você vai precisar de:
- 1Um servidor Redis alcançável — ex.: Redis OSS 7.x por uma porta local ou um túnel SSH. O plano de dados deste manual foi validado ao vivo contra o Redis OSS 7.4.9 standalone.
- 2A string de conexão no formato
redis://(ourediss://para TLS), mais a senha / credenciais ACL se o servidor exigir auth. - 3Opcionalmente, o
redis-clina mesma máquina (pelo túnel) para semear algumas keys de teste tipadas na Etapa 2, e uma API key/secret do Redis Cloud (ou um cluster Redis Enterprise) se você quiser validar a Etapa 8.
Tempo estimado para o passo a passo completo: ~25 minutos.
Conectar ao Redis
Adicione uma conexão Redis, escolha a topologia, teste-a e confirme que a sidebar muda para o formato Redis.
Abra o formulário de conexão e escolha Redis
Abra o gerenciador de conexões (Arquivo → Conectar…, ou o botão Conectar) e clique em + Adicionar nova conexão. No topo do formulário, defina Tipo: Redis (o controle segmentado ao lado de MongoDB).
O formulário troca os campos de auth do Mongo pelo bloco Redis: um scheme (redis / rediss), um seletor de topologia, host/porta, e campos de auth e TLS.
O formulário de conexão é multi-engine. Escolher Redis serializa a conexão como uma string redis:// com app-params específicos do Redis, marcada como savedConnectionType: redis, para reabrir como Redis sem sniff.
Escolha a topologia
Escolha a topologia que corresponde ao seu servidor: Standalone, Sentinel (informe o nome do master + a lista de sentinels) ou Cluster (informe os nós seed).
Conceito
Um formulário, todos os formatos de Redis
O mesmo formulário cobre OSS / Valkey on-prem, Sentinel, Cluster, Redis Enterprise e Redis Cloud. Standalone mostra um índice de banco SELECT 0..15; Cluster o oculta (um keyspace lógico sobre slots); Sentinel conecta ao master que os sentinels resolvem.
Informe host, auth e TLS
Digite o host como uma URL redis:// — por exemplo redis://:<senha>@127.0.0.1:6379. Para auth, escolha none, requirepass (só senha) ou ACL (usuário + senha). Para TLS use o scheme rediss e, se preciso, anexe a CA / cert+chave do cliente.
O formulário aceita a URL. A senha fica no seu cofre de segredos local, nunca devolvida na string de conexão mostrada no header.
A senha é resolvida pelo processo principal do app no momento da conexão e passada ao driver como opção password / username — a URI redis:// salva em si fica sem credenciais.
Teste, depois Conecte
Clique em Test. Depois clique em Connect.
Test retorna uma linha verde como “Conectado — Redis 7.4.9 · standalone · oss”. Connect fecha o modal e a conexão fica connected, com um ponto verde na sidebar.
Na conexão o app sonda a topologia — INFO server / INFO replication, CLUSTER INFO, MODULE LIST, ACL WHOAMI — para detectar versão, role, vendor e módulos. Essa sondagem é o que preenche a linha de status verde.
Confirme que a sidebar está no formato Redis
Na sidebar, expanda a conexão Redis (clique no ▸).
Sob a conexão Redis aparece 🔑 Keyspace Browser (com a nota “navegue o keyspace…”) — e não o Details / Users & Roles do Mongo. Expanda uma conexão MongoDB para confirmar que ela continua mostrando Databases / Details / Users & Roles como antes — sem regressão.
A sidebar é gateada por tipo de conexão em cada call site, então conexões Redis e Mongo renderizam suas próprias árvores lado a lado. ✅
Keyspace browser
Navegue pelas keys sem travar o servidor, veja e edite todos os tipos de dado do Redis, gerencie TTL e rode comandos crus no console RESP.
Abra o Keyspace Browser
Clique em 🔑 Keyspace Browser na sidebar.
A aba Redis Keyspace abre, focada nesta conexão. O header mostra algo como ● Redis · oss · v7.4.9 · standalone · role:master · DBSIZE: 5000.
Faça o scan do keyspace
Clique em SCAN (sem MATCH). Depois clique em Carregar mais · cursor N para buscar a próxima página.
Cerca de 200 keys carregam instantaneamente, cada uma com um ícone de tipo. Carregar mais avança o cursor e anexa o próximo lote; quando o cursor volta a 0 aparece fim do scan.
Conceito
Nunca trava o servidor
A navegação usa `SCAN` iterativo (paginado por cursor, não bloqueante) — nunca o KEYS * bloqueante, que é O(N) e travaria a única thread de comandos do Redis. Um lote pode até voltar vazio com cursor diferente de zero; o browser continua até o cursor ser 0.
Filtre com um padrão MATCH
Digite um glob no campo SCAN MATCH — por exemplo k:1* — e clique em SCAN.
Só as keys que casam com o padrão voltam. Limpe o campo e clique em SCAN de novo para navegar tudo.
Veja uma key com seu viewer tipado
Clique numa key (por exemplo k:3610).
O painel direito mostra o valor (v3610), um badge de tipo string, o estado de TTL (ex.: sem TTL) e a memória por key.
Selecionar uma key roda TYPE, a leitura apropriada ao tipo (GET / leitura paginada equivalente a HGETALL / janela de LRANGE…), TTL e um MEMORY USAGE amostrado — só no select, nunca durante o scan.
Semeie keys tipadas para os outros viewers
Se o seu keyspace só tem strings, crie uma key de cada tipo com o redis-cli (pelo túnel), depois faça *SCAN MATCH `test:`** no app e clique em cada uma:
redis-cli -u redis://:<senha>@127.0.0.1:6379 <<'CMDS'
SET test:str "olá 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 criado pedido 8821
CMDSCada tipo ganha seu próprio viewer: hash → uma tabela field/value; list → uma tabela índice/valor; set → uma lista de membros; zset → uma tabela member/score; stream → entradas mais info do stream. Strings detectam JSON automaticamente em um editor estruturado; números ganham um stepper.
Conceito
Módulos precisam de suporte a módulos
Keys JSON / TimeSeries / Search (RedisJSON, RediSearch, RedisTimeSeries) precisam dos módulos correspondentes carregados. Um Redis OSS puro não tem nenhum, então esses comandos falham lá — use um servidor redis-stack para exercitar os viewers de módulo.
Edite um valor string (preservando o TTL)
Selecione uma key cobaia como k:101. O valor vira um textarea editável — mude o texto (ex.: valor-de-teste) e clique em Salvar (SET KEEPTTL).
O viewer reabre mostrando o novo valor, e qualquer TTL existente é preservado.
As edições usam SET … KEEPTTL de propósito: um SET simples apagaria silenciosamente o TTL da key. O editor sempre o preserva.
Defina e limpe um TTL
No campo TTL s digite 60 e clique em EXPIRE. Depois clique em PERSIST.
Após EXPIRE o badge vira TTL 60s e a lista mostra 60s ao lado da key. Após PERSIST o badge volta a sem TTL.
Apague uma key com UNLINK
Com k:101 selecionada, clique em UNLINK. Um modal de confirmação aparece — clique em Confirmar.
A key some da lista e o DBSIZE diminui 1.
Atenção
Comandos destrutivos têm confirmação digitada
O delete usa `UNLINK` (assíncrono, não bloqueante) em vez de DEL, e é gateado: o modal de confirmação é o nível CONFIRM do gate de segurança. O mesmo gate protege FLUSHDB / RENAME (sobrescrita) / LTRIM / XTRIM.
Alterne para read-only
Clique no toggle 🔓 Editável → 🔒 Read-only, depois selecione uma key.
O textarea editável e os botões EXPIRE / PERSIST / UNLINK somem — a key fica só de leitura. Volte para 🔓 para reabilitar a edição.
O modo read-only vem ligado por padrão em conexões com prod-tag, para você não digitar uma escrita por engano na produção enquanto navega.
Rode comandos crus no console RESP
Abra o console RESP e rode alguns comandos crus:
TYPE test:hash
HGETALL test:hash
OBJECT ENCODING test:zset
MEMORY USAGE test:list SAMPLES 5A resposta de cada comando renderiza no console. Comandos destrutivos digitados aqui ainda passam pelo mesmo gate de segurança — KEYS * é redirecionado para SCAN, e FLUSHALL exige confirmação digitada.
Monitor em tempo real
Um dashboard ao vivo guiado por INFO de como a instância está se comportando agora.
Abra o dashboard em tempo real
No menu de monitoramento Redis (ou no menu de contexto da conexão → Abrir Real-Time), abra o Real-Time Dashboard.
Um dashboard ao vivo começa a fazer polling, com sparklines que se preenchem ao longo dos próximos ticks.
O dashboard faz polling de INFO num timer e parseia cada seção. Contadores cumulativos viram taxas (delta ÷ tempo); gauges e campos de status são lidos como estão.
Leia os tiles ao vivo
Observe os tiles enquanto algo escreve no Redis (seu loop de redis-cli ou tráfego normal).
- Ops/seg e rede in/out como taxas ao vivo.
- Gauge de hit-ratio computado sobre o delta (não o lifetime).
- Memória usada vs
maxmemorycom util %, mais o ratio de fragmentação (avisa acima de 1.5, crítico acima de 2.0, e abaixo de 1.0 = swap = crítico). - Evictions / expirations, clientes conectados / bloqueados, replicação offset-lag e
master_link_status, chips de status de persistência, CPU e o último tempo de fork.
Os contadores se movem como taxas, e um gauge muda de cor pelo valor — então um problema de util de memória ou fragmentação fica visível num relance.
Sobreviva a um restart sem sujeira
Se o servidor reiniciar ou você rodar CONFIG RESETSTAT, o dashboard nota a mudança de run_id / queda de uptime, descarta aquele delta e re-baseliniza em vez de desenhar um pico falso. Você não precisa fazer nada — as taxas continuam honestas.
Slowlog & Latência (Diagnóstico)
Ache os comandos lentos, veja o que o próprio Redis culpa pela latência, e inspecione ou mate conexões de clientes.
Abra o viewer de Slowlog
Abra o pane Slowlog (Diagnóstico). Ele faz tail de `SLOWLOG GET`.
Uma tabela append-only se enche com os comandos mais lentos — cada linha mostra a duração, o comando e seus args — com um marcador “N new” e um rollup por comando. Clique numa linha para abrir os args completos.
As entradas são de-duplicadas por id de slowlog, então re-polling só anexa comandos lentos genuinamente novos.
Leia o doctor de latência
Abra o pane Latency. Ele roda `LATENCY LATEST` / `LATENCY HISTORY` e `LATENCY DOCTOR`.
Cards por evento (fork, aof-fsync, expire, eviction, defrag…) com uma timeline de picos, mais o veredito do DOCTOR em linguagem simples.
Conceito
O que picos de latência significam
O Redis roda comandos numa única thread, então um pico costuma ser um evento bloqueante atrás dela: um fork lento para um save, uma parada de AOF fsync, expiração/eviction em massa de keys, ou defrag ativo. O nome do evento no pico aponta direto para a causa.
Inspecione e mate clientes
Abra o pane Clients. Ele tira um snapshot de `CLIENT LIST`. Filtre a tabela, depois (se preciso) selecione uma conexão e clique em Kill.
Uma tabela virtualizada de conexões — endereço, nome, idade, idle, flags, db, memória de buffer de saída, usuário e biblioteca cliente. Kill pede uma confirmação digitada primeiro.
CLIENT KILL é um comando de nível CONFIRM, então matar uma conexão exige uma confirmação deliberada — sem desconexões acidentais.
Manutenção & Ops
Leia e altere a configuração, analise memória, dispare saves em background e gerencie usuários ACL — tudo atrás do gate de segurança.
Edite a configuração
Abra o pane Config. Ele mostra *`CONFIG GET ** agrupado por área, com um indicador **dirty vs persisted**. Mude um parâmetro e aplique (**CONFIG SET`), depois clique em REWRITE** para persistir no arquivo de config.
Uma confirmação digitada dupla aparece mostrando o diff old → new antes da mudança aplicar; depois o log de auditoria registra, e o REWRITE limpa o marcador dirty.
Atenção
As ops passam pelo gate de segurança de 3 níveis
Comandos de manutenção são classificados: CONFIRM = confirmação digitada dupla + um diff + um registro de auditoria (CONFIG SET/REWRITE, CLIENT KILL, ACL SETUSER/DELUSER, MEMORY PURGE); SOFT-GUARD = permitido mas com cap / cancelável (um scan de big-keys orça o total de chamadas MEMORY USAGE). No Redis gerenciado (Cloud) algumas keys de CONFIG são bloqueadas e o pane troca para o control-plane REST.
Analise a memória e ache big keys
Abra o pane Memory. Leia o veredito do `MEMORY DOCTOR` e a quebra dataset-vs-overhead, depois rode o finder de big-keys.
O veredito do DOCTOR, os ratios de fragmentação, e uma tabela de big-keys (key, tipo, encoding, cardinalidade, memória) que se preenche com uma barra de progresso que você pode cancelar.
O finder de big-keys é clean-room: ele faz SCAN e amostra `MEMORY USAGE … SAMPLES 5` por key (nunca uma varredura O(N) completa), orçando o total de chamadas para nunca sobrecarregar o servidor.
Dispare a persistência
Abra o pane Persistence. Ele mostra INFO persistence, LASTSAVE e DBSIZE. Clique em BGSAVE (snapshot RDB) ou BGREWRITEAOF (compactar o AOF).
O save / rewrite em background começa e o pane reflete o novo estado de LASTSAVE / AOF quando termina.
Conceito
Em background, não bloqueante
`BGSAVE` e `BGREWRITEAOF` dão fork num filho para a thread principal continuar servindo. Os bloqueantes SAVE e DEBUG RELOAD são HIDDEN pelo gate. No OSS, restaurar de um backup é advisory (arquivo + restart) — Cloud/Enterprise fazem via REST.
Gerencie usuários ACL
Abra o pane ACL. Ele roda `ACL LIST` / `ACL GETUSER` / `ACL CAT` / `ACL WHOAMI`. Crie ou edite um usuário (`ACL SETUSER`) ou apague um (`ACL DELUSER`).
A lista de usuários com as regras de cada um; criar/editar/apagar pedem uma confirmação digitada, e o registro de auditoria reda qualquer >password / #hash para que segredos nunca caiam no log.
O pane renderiza por capacidade — botões ficam cinza onde o seu próprio ACL nega a ação ou o comando foi renomeado — então você só vê o que pode de fato fazer.
DBA · RCA (causa-raiz)
A tela heroína do DBA: um clique roda uma varredura de saúde completa e te entrega achados ranqueados com evidência e ação recomendada — e, opcionalmente, uma explicação por IA.
Rode uma varredura de saúde
Abra a tela DBA · RCA e clique na varredura de saúde de um clique.
Uma única passagem coleta sobre memória, latência, persistência, cluster e replicação, e então retorna uma lista de achados ranqueados.
Em vez de você abrir cinco panes e correlacioná-los na mão, a varredura junta os sinais uma vez e ranqueia o que está de fato errado.
Leia a evidência e a ação de um achado
Clique no achado do topo para expandi-lo.
Cada achado carrega sua evidência (as métricas / linhas de log que o dispararam) e uma ação recomendada, com a causa-raiz posta numa timeline ao vivo para você ver correlações através de memória / latência / persistência / cluster / replicação.
Opcionalmente, peça à IA para explicar
Se você tem um modelo configurado, clique em AI analysis no achado.
Uma explicação em linguagem simples e um resumo de remediação aparecem, construídos a partir da mesma evidência.
Conceito
Traga seu próprio LLM, modelo mais barato
A análise por IA é opcional e usa o seu próprio LLM configurado (BYO-LLM). Ela escolhe automaticamente o modelo capaz mais barato, para a explicação custar o mínimo possível — e nada sai da sua configuração se você não habilitar.
Pub/Sub
Faça o tail de canais e padrões ao vivo, e publique mensagens de teste de um publisher embutido para vê-las chegar.
Inscreva-se num canal
Abra o pane Pub/Sub. Descubra os canais ativos (ele usa PUBSUB CHANNELS), depois inscreva-se num com `SUBSCRIBE`, ou num padrão com `PSUBSCRIBE` (ex.: news.*).
Um tail ao vivo começa — as mensagens recebidas streamam para um buffer rolante, as mais novas primeiro.
O tail roda numa conexão de subscriber dedicada (uma duplicata da conexão de dados), porque um socket inscrito só aceita comandos de subscribe/ping. Sua conexão de navegação nunca fica presa.
Publique uma mensagem de teste
No publisher embutido, envie uma mensagem para o canal que você está tailando:
PUBLISH news.sports "olá do NoSqlStudio"A mensagem aparece no topo do tail ao vivo num instante. O buffer tem cap (mais antigas descartadas) e você pode pausar / auto-parar para nunca crescer sem limite.
Redis Cloud & Enterprise (plano de controle)
Conecte o plano de controle REST para gerenciar subscriptions e bancos — e pule de volta ao plano de dados com uma string de conexão gerada.
Conecte o plano de controle REST
Abra a tela Redis Cloud. Para o Redis Cloud, informe a API key e a secret key da sua conta (contra api.redislabs.com). Para o Redis Enterprise, aponte para o endpoint REST do cluster na porta `:9443` com as credenciais dele.
O plano de controle autentica e lista as subscriptions × bancos da sua conta.
Atenção
Esta etapa precisa de infra Cloud / Enterprise real
Todo o plano de dados (Etapas 1–7) foi validado ao vivo contra o Redis OSS 7.4.9. O plano de controle está construído e empacotado mas só pode ser validado com uma conta Redis Cloud real (API key/secret) ou um cluster Redis Enterprise. Com um servidor OSS puro não há nada para esta tela conectar. A secret key fica só no lado do main e nunca é enviada para a UI.
Explore subscriptions, bancos e módulos
Desça de uma subscription para seus bancos. Abra um banco para ver seus módulos e qualquer geo-distribuição Active-Active (CRDB).
Detalhes por banco — memória, eviction, persistência, módulos, replicação — mais, para um banco Active-Active, os clusters participantes e as regiões. Active-Active é apenas plano de controle: uma única conexão de dados só alcança uma região.
Um clique para o plano de dados
Num banco do cloud, clique em Connect this database.
Uma string de conexão redis:// (aqui rediss://) é gerada e o formulário de conexão se pré-preenche com vendor redis-cloud — conecte para cair no Keyspace Browser da Etapa 2 contra aquele banco.
Isso faz a ponte entre os dois planos: descubra bancos via REST, depois pule para o plano de dados ao vivo de qualquer um deles sem copiar detalhes de conexão na mão. ✅
Limpeza (quando terminar)
Apague as keys de teste que você criou, depois feche as abas Redis. Do console RESP ou do redis-cli:
UNLINK k:101
UNLINK test:str test:hash test:list test:set test:zset test:streamAs keys de teste somem e o DBSIZE diminui de acordo.
Conceito
Sua conexão Redis e os segredos dela (senhas, API keys do Cloud) vivem no seu perfil local — fechar as abas não os apaga. Remova a conexão salva no gerenciador de conexões se você quiser eliminá-los.
Resumo do que você validou
| Tela | O que você pode fazer |
|---|---|
| 1 | Conectar ao Redis (Standalone / Sentinel / Cluster, TLS, auth) e ter uma sidebar no formato Redis |
| 2 | Keyspace Browser: SCAN não bloqueante, viewers + editores tipados, TTL, memória por key, UNLINK, console RESP |
| 3 | Monitor em tempo real: dashboard de INFO ao vivo com taxas, gauges e alertas |
| 4 | Diagnóstico: Slowlog, Latency DOCTOR, e inspecionar/matar clientes |
| 5 | Manutenção & Ops: CONFIG GET/SET/REWRITE, memória + big-keys, BGSAVE/BGREWRITEAOF, ACL — tudo gateado |
| 6 | DBA · RCA: varredura de saúde de um clique, achados ranqueados com evidência, análise BYO-LLM opcional |
| 7 | Pub/Sub: tail ao vivo de canais & padrões com um publisher embutido |
| 8 | Plano de controle Redis Cloud & Enterprise: subscriptions × bancos, módulos, conexão de um clique |