Monitoramento de Redis: métricas, comandos e ferramentas

Redis tornou-se peça central em arquiteturas modernas de aplicações: cache, fila de mensagens, sessão de usuário e armazenamento de contadores em tempo real. Como roda inteiramente em memória, qualquer pressão de RAM, fragmentação ou latência reflete diretamente no tempo de resposta percebido pelo usuário final.

Apesar dessa centralidade, muitas equipes ainda tratam o Redis como caixa-preta. Quando o incidente acontece (uma fila de cache que satura, evictions que disparam, replicação que trava), o time de operações descobre o problema pelo ticket do cliente, não pelo dashboard.

Este guia técnico mostra quais métricas observar, quais comandos nativos usar para diagnóstico, quais ferramentas integram o Redis ao seu stack de observabilidade e como definir thresholds de alerta que detectam problemas antes que cheguem ao usuário.

O que é Redis e por que monitorar uma instância em memória

Redis (Remote Dictionary Server) é um armazenamento chave-valor in-memory de código aberto, frequentemente usado como cache distribuído, broker de mensagens, fila de tarefas e cache de sessão. A combinação de baixa latência (microssegundos) e estruturas de dados ricas (strings, hashes, listas, sets, sorted sets, streams) o transformou em componente quase obrigatório em arquiteturas de microsserviços.

A natureza in-memory traz uma característica crítica: o Redis é tão rápido quanto a RAM disponível. Se o servidor começa a fazer swap para disco, a latência sobe de microssegundos para dezenas de milissegundos, derrubando indiretamente todas as aplicações que dependem dele.

Por isso, o monitoramento de Redis exige tratamento dedicado, diferente do monitoramento de bancos de dados relacionais tradicionais. Outro ponto que diferencia o Redis é sua arquitetura predominantemente single-threaded.

Um único comando lento bloqueia toda a fila de execução, o que torna o monitoramento de comandos específicos e tempos de resposta tão importante quanto métricas agregadas de throughput.

Métricas essenciais para monitorar no Redis

Toda estratégia de observabilidade do Redis começa com um conjunto de métricas que combinam saúde de infraestrutura, performance de aplicação e comportamento do cache. As próximas seções detalham cada categoria com os indicadores mais relevantes.

Memória e fragmentação

Como tudo vive em RAM, métricas de memória são prioridade número um. Os indicadores essenciais são:

used_memory: total de bytes alocados pelo Redis para armazenar dados.

used_memory_rss: memória física efetivamente reservada pelo sistema operacional para o processo.

maxmemory: limite configurado para a instância. Quando alcançado, dispara a política de eviction.

mem_fragmentation_ratio: razão entre RSS e used_memory. Valores saudáveis ficam entre 1.0 e 1.4. Abaixo de 1.0 indica swap ativo (situação crítica). Acima de 1.5 sugere fragmentação excessiva, que pode justificar reinicialização ou uso do comando MEMORY PURGE.

Latência e throughput

A latência é o sintoma mais perceptível de problemas no Redis. Um único comando lento (por exemplo, um KEYS * em produção) trava toda a fila de execução. Métricas a observar:

instantaneous_ops_per_sec: throughput em operações por segundo. Quedas bruscas indicam contenção; picos sustentados podem antecipar saturação.

Latência média e p99 medidas via LATENCY LATEST e LATENCY HISTORY.

Tempo de execução por comando, obtido via INFO commandstats. Permite identificar quais comandos consomem mais CPU acumulada ao longo do tempo.

Conexões e clientes

connected_clients: clientes ativos no momento.

rejected_connections: tentativas de conexão recusadas por extrapolar maxclients (padrão de 10.000). Qualquer valor diferente de zero merece investigação imediata.

blocked_clients: clientes aguardando resposta de comandos bloqueantes (BLPOP, BRPOP, WAIT). Valores altos podem indicar consumidores lentos em filas pub/sub.

Cache hit ratio e evictions

Para cargas de cache, a relação entre hits e misses define a eficiência da camada. O cálculo é hit_ratio = keyspace_hits / (keyspace_hits + keyspace_misses).

Um valor saudável fica acima de 0,8. Cair abaixo desse patamar normalmente sinaliza TTLs muito agressivos, churn excessivo de chaves ou maxmemory subdimensionado.

A métrica evicted_keys mostra quantas chaves foram removidas para liberar espaço quando o limite de memória foi atingido. Em caches puros, evictions são esperadas; em armazenamentos de sessão ou contadores críticos, qualquer eviction é alarme vermelho.

Persistência e replicação

Mesmo sendo in-memory, o Redis oferece persistência via snapshot RDB e log AOF. As métricas rdb_last_bgsave_status e aof_last_write_status devem reportar OK; falhas indicam risco de perda em caso de crash.

Em arquiteturas com réplica, a métrica master_repl_offset versus slave_repl_offset revela o lag de replicação. Lag persistente acima de 10 segundos sinaliza réplica saturada ou rede degradada entre os nós.

Comandos nativos do Redis para diagnóstico

Antes de instalar qualquer agente de monitoramento, vale dominar o ferramental embutido no próprio Redis. Quatro comandos resolvem 80% dos diagnósticos de rotina.

INFO: retorna centenas de métricas organizadas em seções (server, clients, memory, persistence, stats, replication, cpu, commandstats, keyspace). É a base de praticamente todos os exporters e plugins do mercado.

SLOWLOG: mantém um log de comandos que ultrapassaram um limite configurável de microssegundos (por padrão, 10.000 µs). Use SLOWLOG GET 25 para listar os 25 comandos mais lentos recentes e priorizar refatoração de queries.

LATENCY: o framework de latência do Redis monitora eventos internos (fork, AOF rewrite, expirações) que costumam causar picos invisíveis ao SLOWLOG. Combine LATENCY DOCTOR e LATENCY GRAPH event-name para análise visual rápida.

CLIENT LIST e MONITOR: úteis para investigação ad-hoc. O MONITOR, em particular, transmite todo comando que o servidor processa, mas penaliza a performance e deve ser usado por períodos curtos em ambiente controlado.

Ferramentas para monitoramento de Redis

A escolha da ferramenta depende do stack já em uso na operação. Três combinações cobrem a maioria dos cenários corporativos brasileiros.

➡️ Zabbix com template oficial: opção bastante adotada no Brasil em ambientes on-prem e híbridos. O template oficial coleta dezenas de métricas via comandos do Redis e integra alertas ao mesmo console que monitora servidores, redes e clusters Kubernetes. Funciona bem para equipes que preferem consolidar alertas e SLA em uma só ferramenta.

➡️ Prometheus + Redis Exporter + Grafana: padrão em ambientes cloud-native. O exporter expõe um endpoint /metrics que o Prometheus consome em scrape regular. Grafana traz dashboards prontos no Marketplace, e o conjunto costuma ser o ponto de entrada para iniciativas mais amplas dos pilares da observabilidade unificada. O projeto open source mais popular mantido pela comunidade traz suporte a todas as versões recentes.

➡️ RedisInsight: ferramenta gráfica oficial da Redis Inc., focada em diagnóstico rápido e visualização de keyspace. Útil para troubleshooting pontual e análise de padrões de uso, mas não substitui um sistema de alerting persistente.

Plataformas SaaS como Datadog, New Relic e Dynatrace oferecem integrações nativas que aceleram a curva de adoção, com a contrapartida de custo recorrente proporcional ao volume de métricas. A escolha entre open source e SaaS deve considerar orçamento, time disponível para manutenção e necessidade de retenção histórica.

Como configurar alertas e thresholds em produção

Métricas sem alerta são apenas gráficos bonitos. A lista a seguir consolida thresholds práticos como ponto de partida (devem ser ajustados conforme baseline observado em cada ambiente):

Memória usada > 80% de maxmemory: alerta amarelo. Antecipa pressão de eviction.

mem_fragmentation_ratio < 1.0 ou > 1.5: alerta crítico. Indica swap ou fragmentação severa.

Hit ratio < 0,8: alerta amarelo em ambientes de cache.

rejected_connections > 0: alerta crítico. Cliente está sendo recusado pelo servidor.

SLOWLOG com mais de 10 entradas em 5 minutos: alerta investigativo para queries problemáticas.

Replication lag > 10s: alerta crítico em arquiteturas master/replica.

rdb_last_bgsave_status diferente de OK: alerta imediato. Snapshot falhou e backup pode estar desatualizado.

connected_clients > 80% de maxclients: alerta amarelo. Capacidade próxima do limite.

A configuração de thresholds deve sempre se basear no baseline da própria operação, observado durante pelo menos uma semana. Threshold genérico costuma gerar fadiga de alertas de TI quando aplicado sem ajuste fino.

Equipes maduras combinam alertas baseados em valores absolutos com detecção de anomalias por desvio padrão da média histórica. Em arquiteturas críticas, vale também integrar os alertas de Redis com o restante do monitoramento de servidores para correlacionar pressão de RAM da VM com pressão de memória interna do Redis.

Boas práticas e armadilhas comuns no monitoramento de Redis

Mesmo com métricas e alertas bem definidos, alguns padrões de incidentes se repetem. Os mais frequentes são:

Cache stampede: quando uma chave popular expira simultaneamente em milhares de requests, todas as instâncias batem no banco de origem ao mesmo tempo. Detecte via spike súbito de keyspace_misses combinado com queda de hit ratio. Mitigação: TTLs com jitter aleatório e bloqueio cooperativo.

Comandos com complexidade O(N): KEYS, SMEMBERS e HGETALL em estruturas grandes travam o servidor. Use SCAN, HSCAN e SSCAN em paginação. O SLOWLOG é o melhor detector dessa categoria.

AOF rewrite em hardware lento: a reescrita periódica do log de comandos consome I/O e pode disparar latência percebida. Monitore aof_current_size, aof_pending_rewrite e use LATENCY para captar picos correlacionados ao evento.

Réplica sem leitura: manter réplicas só para failover é desperdício. Direcionar leituras para a réplica reduz pressão no master, mas exige atenção ao lag para evitar leituras inconsistentes em endpoints sensíveis.

maxmemory-policy mal escolhida: usar noeviction em cache puro causa erros OOM command not allowed. Para sessão crítica, allkeys-lru ou allkeys-lfu costumam ser mais adequados que as variantes volatile-*.

Documentar a política de eviction adotada e revisar trimestralmente faz parte de uma operação saudável. A documentação oficial do projeto fornece referência detalhada de cada parâmetro de configuração.

Conclusão

Monitorar Redis vai além de coletar uso de memória e taxa de hit. Exige entender o contexto de uso (cache, sessão, fila, broker), correlacionar métricas internas com infraestrutura subjacente e definir thresholds que reflitam a realidade da operação, não valores genéricos.

Quando bem feito, o monitoramento detecta cache stampede, fragmentação progressiva e replicação travada antes que esses problemas virem incidentes visíveis para o usuário final.

Comandos nativos como INFO, SLOWLOG e LATENCY resolvem boa parte do diagnóstico ad-hoc. Já a operação contínua exige integração com plataformas como Zabbix, Prometheus ou ferramentas SaaS que mantenham histórico, alertas e dashboards acessíveis a toda a equipe.

Se a sua operação depende de Redis para servir milhões de requests com baixa latência e a pressão por SLA está crescendo, a equipe da OpServices pode ajudar a estruturar uma estratégia completa de observabilidade integrada ao restante da infraestrutura. Fale com um especialista para uma avaliação personalizada do seu ambiente.