Bases de dados
    Atualizado maio de 2026
    KeyDB logo

    KeyDB Monitorização

    Monitorize as operações do KeyDB por segundo, a utilização de memória, o estado da replicação e o desempenho multithread em tempo real, sem necessidade de configuração.

    Iniciar período de avaliação gratuitaVer documentos

    Por que monitorizar KeyDB?

    O KeyDB é uma versão derivada do Redis, multithread e de alto desempenho, que oferece um débito superior. A monitorização do KeyDB garante um número ideal de operações por segundo, uma utilização adequada da memória e uma replicação fiável em toda a sua camada de dados em memória.

    Deteção automática via Xitogent
    Monitorização de operações por segundo
    Utilização de memória e fragmentação
    Métricas de desempenho multi-thread
    Acompanhamento do lag de replicação
    Monitorização de clientes ligados
    Acompanhamento de evictions de chaves
    Intervalos de recolha de 1 minuto
    Compatível ao nível de wire com e com todo o ecossistema de tooling Redis
    Intervalos de recolha de métricas de 1 minuto, prontos a usar
    O que é a monitorização do KeyDB?

    Monitorização do KeyDB, explicada

    A monitorização do KeyDB deteta pressão de memória, divergência de replicação (especialmente em configurações ativo-ativo multi-master), saturação de threads e problemas no tier de armazenamento FLASH antes que impactem o desempenho da cache ou causem desvios de dados entre réplicas. Como o KeyDB é um substituto direto do Redis com capacidades adicionais (multi-threading, ativo-ativo, tier SSD FLASH), monitorizá-lo bem significa acompanhar tanto o conjunto padrão de métricas Redis COMO os sinais específicos do KeyDB. O Xitoring descobre automaticamente o seu KeyDB, lê o INFO mais o estado por thread, e encaminha alertas para Slack, PagerDuty, Telegram ou para a sua equipa de plantão existente.

    Métricas

    O que monitorizamos

    Ops/s

    Total de operações por segundo.

    Utilização de memória

    Memória usada face à disponível.

    Clientes ligados

    Ligações de cliente ativas.

    Lag de replicação

    Bytes em atraso face ao master na replicação.

    Evictions de chaves

    Chaves removidas devido à pressão de memória.

    Taxa de hit

    Rácio de cache hit vs miss.

    rejected_connections

    Tentativas de ligação descartadas por se ter atingido `maxclients`. Qualquer crescimento sinaliza fugas no pool de ligações do lado da aplicação ou picos de tráfego.

    Estado de réplica ativa

    Quando `active-replica yes` está configurado, expõe o offset de replicação por réplica e o estado de aceitação de escritas — crítico para implementações multi-master onde cada nó aceita escritas.

    Lag do offset de replicação

    `master_repl_offset` menos `slave_repl_offset` por réplica. Lag sustentado significa que uma réplica não consegue acompanhar — normalmente rede ou CPU do lado da réplica.

    Hit/miss do tier FLASH

    Quando `storage-provider flash` está ativado (tier suportado por SSD específico do KeyDB), expõe a divisão hot/warm/cold de objetos e a taxa de miss em FLASH. Permite dimensionar corretamente o tier FLASH para working sets maiores que a RAM.

    Persistência (RDB / AOF)

    `rdb_last_save_time`, `rdb_changes_since_last_save`, `aof_current_size`, `aof_rewrite_in_progress`. Deteta saves RDB falhados e bloqueios de reescrita AOF antes que impactem a recuperabilidade no reinício.

    SLOWLOG / Latência

    Contagem de comandos lentos do `SLOWLOG` mais eventos de latência interna do Redis do `LATENCY HISTORY`. Apanha a chamada `KEYS *` ou `SMEMBERS` enorme que está a bloquear threads de trabalho.

    Alerta e notificação

    Configurável condições de alerta

    Configure alertas personalizados no seu painel para ser notificado assim que as métricas dKeyDB ultrapassarem os limites que definiu.

    KeyDB painel de controlo da configuração dos gatilhos de monitorização

    Utilização de memória

    crítico

    Dispara quando a memória excede o limite.

    Lag de replicação

    crítico

    Alerta se a replicação ficar atrasada.

    Evictions de chaves

    aviso

    Dispara em taxas de eviction elevadas.

    Clientes ligados

    aviso

    Dispara quando o número de clientes se aproxima dos limites.

    01

    Importância da monitorização do KeyDB

    A arquitetura multi-thread do KeyDB lida com throughput massivo. Sem monitorização, pressão de memória e problemas de replicação podem causar perda de dados.

    • Acompanhe a memória para prevenir crashes OOM
    • Monitorize a replicação para a consistência dos dados
    • Detete evictions de chaves que afetam a cache
    • Otimize o desempenho multi-thread
    Monitorização do KeyDB
    Analítica de desempenho
    02

    Porquê escolher Xitoring

    Monitorização KeyDB sem configuração.

    • Instalação num único comando
    • Nós globais
    • Dashboard unificado
    • Alertas multicanal
    • Retenção histórica
    Visão geral
    Alertas
    Casos de uso

    Cenários comuns de monitorização do KeyDB

    Onde o KeyDB normalmente é executado hoje — e o que pode correr mal se ninguém estiver a monitorizar.

    Aplicações de alto tráfego que superaram o Redis

    O KeyDB é geralmente escolhido quando um servidor Redis já não consegue acompanhar o tráfego. Garantimos que a potência extra está realmente a ser usada — e sinalizamos os padrões que a anulam silenciosamente, para que a atualização compense como deveria.

    Aplicações que servem utilizadores em várias regiões

    Quando uma cache é executada em várias regiões e aceita escritas em todo o lado, as regiões podem silenciosamente divergir. Monitorizamos essa divergência para que os utilizadores em diferentes partes do mundo nunca vejam dados inconsistentes.

    Grandes caches que misturam memória e SSD

    Quando a cache é demasiado grande para caber na memória, o KeyDB armazena os itens mais usados na RAM e o resto no disco. Monitorizamos o equilíbrio para que a cache permaneça rápida — e para que os SSDs subjacentes não se desgastem silenciosamente com o uso intenso.

    Antes de começar

    Pré-requisitos para KeyDB

    Certifique-se de que tem tudo isto pronto — depois disso, a maioria das instalações leva 60 segundos.

    • KeyDB em execução na sua porta configurada (predefinida 6379)
    • Palavra-passe AUTH se requirepass estiver definido na sua configuração KeyDB
    • Acessibilidade de rede do Xitogent à instância KeyDB
    Guia de configuração

    Comece a minutos

    1

    Instalar o Xitogent no seu host KeyDB

    Instale o leve agente de monitorização Xitogent no host que executa o KeyDB.

    curl -s https://xitoring.com/install.sh | sudo bash -s -- --key=YOUR_API_KEY
    2

    Confirmar o acesso ao comando INFO

    O KeyDB é compatível ao nível wire com o Redis e usa o comando `INFO` para estatísticas em tempo de execução. Garanta que o KeyDB é acessível no seu endereço de bind (predefinido 6379) e forneça credenciais se `requirepass` estiver definido.

    sudo xitogent integrate
    3

    Ativar a integração do KeyDB

    Use o painel do Xitoring ou a CLI para ativar a integração do KeyDB. O Xitogent deteta automaticamente a sua instância do KeyDB e a topologia de replicação.

    4

    Configurar limiares de alerta (opcional)

    Defina limiares personalizados para uso de memória, atraso de replicação ou evictions de chaves para apanhar problemas de capacidade antes que causem cache misses ou divergência de replicação.

    5

    Confirme que está a funcionar

    Execute este comando no servidor para confirmar que o Xitogent detetou a integração. Em cerca de 30 segundos começam a chegar novas métricas ao seu painel.

    sudo xitogent status
    Comparar

    Está a considerar alternativas?

    Veja como o Xitoring se compara às alternativas para a monitorização de KeyDB — preços fixos, integrações mais profundas e um único agente que cobre toda a sua stack.

    Ver todas as comparações

    Frequentemente perguntas feitas

    Isto difere da monitorização do Redis?
    O KeyDB utiliza o protocolo Redis, mas possui métricas exclusivas de multithreading. Esta integração captura dados específicos do KeyDB.
    Quais são as versões compatíveis?
    KeyDB 5.x e 6.x.
    Como monitorizo a replicação de réplicas ativas no KeyDB?
    Com `active-replica yes` e `multi-master yes`, cada nó aceita escritas e replica para os pares. Monitorize o offset de replicação por par (`INFO replication`), o `master_link_status` em cada ligação de par, a divergência de `master_repl_offset` entre masters e qualquer taxa de `sync_partial_err`. Os conflitos em multi-master são resolvidos por last-write-wins por timestamp — alerte sobre o desvio de relógio entre nós.
    Quantos server-threads devo definir no KeyDB?
    Faça corresponder `server-threads` aos seus núcleos físicos de CPU (não hyperthreads) num host KeyDB dedicado — normalmente 4 a 8. Acima de 8 atinge retornos decrescentes devido a sobrecarga de coordenação. Monitorize a utilização de CPU por thread após uma mudança de afinação: se uma thread estiver saturada enquanto outras estão inativas, tem um padrão de ligação aderente ou chave quente que necessita de trabalho do lado da aplicação.
    O KeyDB é mesmo 5x mais rápido que o Redis?
    Os próprios benchmarks do KeyDB reivindicam 2–5x de débito vs Redis single-threaded no mesmo hardware (benchmarks independentes da InfraCloud confirmam 2–3x em cargas de trabalho típicas). O ganho aparece quando se está limitado por CPU num núcleo Redis. Para cargas de trabalho limitadas por memória ou rede, o ganho é muito menor. As métricas por thread do Xitogent permitem-lhe medir o multiplicador real na sua carga de trabalho.
    Como monitorizo o armazenamento FLASH do KeyDB?
    Quando `storage-provider flash ` está ativado, o KeyDB armazena chaves quentes em RAM e valores warm/cold em SSD. Monitorize o rácio de hit/miss do FLASH (semelhante a `keyspace_hits`/`misses` mas ao nível do tier de armazenamento), a latência de I/O do SSD e o total de bytes residentes em FLASH. Vigie a amplificação de escrita do SSD — cargas de trabalho de cache podem desgastar SSDs de consumo rapidamente; use SSDs empresariais para tiers FLASH em produção.
    O KeyDB funciona com, Prometheus e Grafana?
    Sim. O KeyDB fala RESP, pelo que o lê inalterado, o Prometheus faz scraping do exportador e os dashboards Grafana existentes (por exemplo, o dashboard ID 763) funcionam tal e qual. O Xitogent lê o `INFO` diretamente (sem necessidade de exportador), mas é compatível com ambientes que correm para visualização em Grafana.
    KeyDB vs Valkey vs Redis — qual monitorizar em 2026?
    Os três falam RESP e partilham o mesmo vocabulário de monitorização. O Redis (AGPLv3 desde 2025) é o original, agora com RedisJSON/RediSearch/RedisTimeSeries/RedisBloom na distribuição principal. O Valkey (fork BSD da Linux Foundation) suporta o AWS ElastiCache Serverless e o GCP Memorystore. O KeyDB (BSD) é a escolha multi-threaded + ativo-ativo + FLASH para cargas de trabalho específicas. O Xitoring monitoriza os três com os mesmos padrões de integração.
    Que versões do KeyDB são suportadas?
    KeyDB 5.x e 6.x são totalmente suportadas. A integração deteta automaticamente se as funcionalidades multi-threading, active-replica ou armazenamento FLASH estão ativadas e expõe as métricas específicas do KeyDB apropriadas, em cima do conjunto padrão `INFO` compatível com Redis. A compatibilidade ao nível de wire com e com o ecossistema Redis é preservada.

    Comece a monitorizar KeyDB hoje

    Configure em menos de 60 segundos. Não é necessário cartão de crédito. Estatísticas completas desde o primeiro dia.

    Iniciar período de avaliação gratuita

    Continue a explorar

    Relacionado Integrações