Bases de données
    Mis à jour le mai 2026
    KeyDB logo

    KeyDB Suivi

    Surveillez en temps réel et sans aucune configuration les opérations KeyDB par seconde, l'utilisation de la mémoire, l'état de la réplication et les performances multithread.

    Commencer l'essai gratuitConsulter les documents

    Pourquoi surveiller ? KeyDB?

    KeyDB est une version dérivée de Redis, hautement performante et multithread, offrant un débit supérieur. La surveillance de KeyDB garantit un nombre optimal d'opérations par seconde, une utilisation rationnelle de la mémoire et une réplication fiable au sein de votre couche de données en mémoire.

    Détection automatique via Xitogent
    Surveillance des opérations par seconde
    Utilisation mémoire et fragmentation
    Métriques de performances multithread
    Suivi du lag de réplication
    Surveillance des clients connectés
    Suivi des évictions de clés
    Intervalles de collecte d'1 minute
    Compatible au niveau du fil avec et l'ensemble de l'écosystème d'outillage Redis
    Intervalles de collecte des métriques d'une minute par défaut
    Qu'est-ce que le monitoring KeyDB ?

    Le monitoring KeyDB, expliqué

    Le monitoring KeyDB détecte la pression mémoire, la divergence de réplication (en particulier dans les configurations multi-master actif-actif), la saturation de threads et les problèmes du niveau de stockage FLASH avant qu'ils n'impactent les performances de cache ou ne provoquent une dérive de données entre réplicas. Parce que KeyDB est un remplaçant direct de Redis avec des capacités supplémentaires (multi-threading, actif-actif, niveau SSD FLASH), bien le monitorer signifie suivre à la fois l'ensemble standard de métriques Redis ET les signaux spécifiques à KeyDB. Xitoring découvre automatiquement votre KeyDB, lit INFO plus l'état par thread, et achemine les alertes vers Slack, PagerDuty, Telegram ou votre astreinte existante.

    Indicateurs

    Ce que nous surveillons

    Ops/sec

    Total des opérations par seconde.

    Utilisation mémoire

    Mémoire utilisée par rapport à la mémoire disponible.

    Clients connectés

    Connexions client actives.

    Lag de réplication

    Octets en retard par rapport au master en réplication.

    Évictions de clés

    Clés évincées en raison de la pression mémoire.

    Taux de hit

    Ratio de cache hit vs miss.

    rejected_connections

    Tentatives de connexion abandonnées parce que `maxclients` a été atteint. Toute croissance signale des fuites du pool de connexions côté app ou des pics de trafic.

    État Active-Replica

    Lorsque `active-replica yes` est configuré, met en évidence l'offset de réplication et l'état d'acceptation des écritures par réplica — critique pour les déploiements multi-master où chaque nœud accepte les écritures.

    Lag d'offset de réplication

    `master_repl_offset` moins `slave_repl_offset` par réplica. Un lag soutenu signifie qu'un réplica n'arrive pas à suivre — généralement réseau ou CPU côté réplica.

    Hit/Miss du niveau FLASH

    Lorsque `storage-provider flash` est activé (niveau SSD spécifique à KeyDB), met en évidence la répartition des objets hot/warm/cold et le taux de miss FLASH. Vous permet de dimensionner correctement le niveau FLASH pour les working sets plus grands que la RAM.

    Persistance (RDB / AOF)

    `rdb_last_save_time`, `rdb_changes_since_last_save`, `aof_current_size`, `aof_rewrite_in_progress`. Détecte les sauvegardes RDB échouées et les blocages de réécriture AOF avant qu'ils n'impactent la récupérabilité au redémarrage.

    SLOWLOG / Latence

    Nombre de commandes lentes depuis `SLOWLOG` plus les événements de latence Redis-internes depuis `LATENCY HISTORY`. Capte l'unique appel `KEYS *` ou `SMEMBERS` énorme qui bloque les threads workers.

    Déclencheurs et alertes

    Configurables déclencheurs d'alerte

    Configurez des déclencheurs personnalisés dans votre tableau de bord pour être averti dès que les indicateurs d{name}s dépassent les seuils que vous avez définis.

    KeyDB tableau de bord de configuration des déclencheurs de surveillance

    Utilisation mémoire

    crucial

    Se déclenche lorsque la mémoire dépasse le seuil.

    Lag de réplication

    crucial

    Alerte si la réplication prend du retard.

    Évictions de clés

    avertissement

    Se déclenche sur un taux d'éviction élevé.

    Clients connectés

    avertissement

    Se déclenche lorsque le nombre de clients approche les limites.

    01

    Importance de la surveillance KeyDB

    L'architecture multithread de KeyDB gère un débit massif. Sans surveillance, la pression mémoire et les problèmes de réplication peuvent provoquer une perte de données.

    • Suivez la mémoire pour éviter les crashs OOM
    • Surveillez la réplication pour la cohérence des données
    • Détectez les évictions de clés impactant le cache
    • Optimisez les performances multithread
    Surveillance KeyDB
    Analytique de performances
    02

    Pourquoi choisir Xitoring

    Surveillance KeyDB sans configuration.

    • Installation en une commande
    • Nœuds mondiaux
    • Tableau de bord unifié
    • Alertes multicanaux
    • Conservation historique
    Vue d'ensemble
    Alertes
    Cas d'usage

    Scénarios courants de monitoring KeyDB

    Où KeyDB fonctionne généralement aujourd'hui — et ce qui pourrait mal tourner si personne ne surveille.

    Applications à fort trafic qui ont dépassé Redis

    KeyDB est généralement choisi lorsqu'un serveur Redis ne peut plus suivre le trafic. Nous nous assurons que la puissance supplémentaire est réellement utilisée — et signalons les schémas qui l'annulent discrètement, afin que la mise à niveau porte ses fruits comme prévu.

    Applications servant des utilisateurs dans plusieurs régions

    Lorsqu'un cache fonctionne dans plusieurs régions et accepte des écritures partout, les régions peuvent discrètement diverger. Nous surveillons cette dérive afin que les utilisateurs de différentes parties du monde ne voient jamais de données incohérentes.

    Grands caches qui mélangent mémoire et SSD

    Lorsque le cache est trop grand pour tenir en mémoire, KeyDB stocke les éléments les plus utilisés dans la RAM et le reste sur disque. Nous surveillons l'équilibre afin que le cache reste rapide — et que les SSD sous-jacents ne s'usent pas discrètement à cause d'une utilisation intensive.

    Avant de commencer

    Prérequis pour KeyDB

    Assurez-vous d'avoir tout cela en place — la plupart des installations sont une affaire de 60 secondes une fois ces conditions réunies.

    • KeyDB tournant sur son port configuré (par défaut 6379)
    • Mot de passe AUTH si requirepass est défini dans votre configuration KeyDB
    • Accessibilité réseau de Xitogent vers l'instance KeyDB
    Guide d'installation

    Commencez par procès-verbal

    1

    Installer Xitogent sur votre hôte KeyDB

    Installez l'agent de monitoring léger Xitogent sur l'hôte qui exécute KeyDB.

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

    Confirmer l'accès à la commande INFO

    KeyDB est compatible avec Redis et utilise la commande `INFO` pour les statistiques runtime. Assurez-vous que KeyDB est accessible sur son adresse de bind (par défaut 6379) et fournissez les identifiants si `requirepass` est défini.

    sudo xitogent integrate
    3

    Activer l'intégration KeyDB

    Utilisez le tableau de bord Xitoring ou la CLI pour activer l'intégration KeyDB. Xitogent détecte automatiquement votre instance KeyDB et sa topologie de réplication.

    4

    Configurer les seuils d'alerte (facultatif)

    Définissez des seuils personnalisés pour l'utilisation mémoire, le retard de réplication ou les évictions de clés afin de détecter les problèmes de capacité avant qu'ils ne causent des cache misses ou des divergences de réplication.

    5

    Vérifier que tout fonctionne

    Exécutez cette commande sur le serveur pour confirmer que Xitogent a bien détecté l'intégration. De nouvelles métriques apparaîtront sur votre tableau de bord dans environ 30 secondes.

    sudo xitogent status
    Comparer

    Vous envisagez des alternatives ?

    Découvrez comment Xitoring se positionne face aux alternatives pour la surveillance de KeyDB — tarifs forfaitaires, intégrations plus poussées et un seul agent pour couvrir tout votre stack.

    Voir toutes les comparaisons

    Souvent a posé des questions

    Est-ce différent de la surveillance de Redis ?
    KeyDB utilise le protocole Redis, mais dispose de métriques multithread spécifiques. Cette intégration permet de collecter des données propres à KeyDB.
    Quelles versions sont prises en charge ?
    KeyDB 5.x et 6.x.
    Comment monitorer la réplication active-replica de KeyDB ?
    Avec `active-replica yes` et `multi-master yes`, chaque nœud accepte les écritures et les réplique vers ses pairs. Monitorez l'offset de réplication par pair (`INFO replication`), `master_link_status` sur chaque connexion entre pairs, la divergence `master_repl_offset` entre masters et tout taux `sync_partial_err`. Les conflits en multi-master sont résolus par dernière écriture gagnante selon timestamp — alertez sur la dérive d'horloge entre nœuds.
    Combien de server-threads dois-je définir dans KeyDB ?
    Faites correspondre `server-threads` à vos cœurs CPU physiques (pas les hyperthreads) sur un hôte KeyDB dédié — typiquement 4 à 8. Au-delà de 8, on atteint des rendements décroissants à cause du surcoût de coordination. Monitorez l'utilisation CPU par thread après un changement de tuning : si un thread est saturé alors que les autres sont inactifs, vous avez un schéma de connexion collante ou de clé chaude à corriger côté application.
    KeyDB est-il vraiment 5x plus rapide que Redis ?
    Les propres benchmarks de KeyDB annoncent 2 à 5x de débit vs Redis mono-threadé sur le même matériel (les benchmarks indépendants d'InfraCloud confirment 2 à 3x sur les charges typiques). Le gain apparaît lorsque vous êtes CPU-bound sur un cœur Redis. Pour les charges memory-bound ou network-bound, le gain est bien plus faible. Les métriques par thread de Xitogent vous permettent de mesurer le multiplicateur réel sur votre charge.
    Comment monitorer le stockage FLASH de KeyDB ?
    Lorsque `storage-provider flash ` est activé, KeyDB stocke les clés chaudes en RAM et les valeurs tièdes/froides sur SSD. Monitorez le ratio hit/miss FLASH (similaire à `keyspace_hits`/`misses` mais au niveau du stockage), la latence I/O SSD et le total d'octets résidents en FLASH. Surveillez l'amplification d'écriture SSD — les charges de cache peuvent user rapidement les SSD grand public ; utilisez des SSD entreprise pour les niveaux FLASH en production.
    KeyDB fonctionne-t-il avec, Prometheus et Grafana ?
    Oui. KeyDB parle RESP, donc le lit sans modification, Prometheus scrape l'exportateur, et les dashboards Grafana existants (par ex. dashboard ID 763) fonctionnent tels quels. Xitogent lit `INFO` directement (sans exportateur nécessaire) mais est compatible avec les environnements qui en exécutent un pour la visualisation Grafana.
    KeyDB vs Valkey vs Redis — lequel monitorer en 2026 ?
    Les trois parlent RESP et partagent le même vocabulaire de monitoring. Redis (AGPLv3 depuis 2025) est l'original, désormais avec RedisJSON/RediSearch/RedisTimeSeries/RedisBloom dans la distribution principale. Valkey (fork BSD de la Linux Foundation) propulse AWS ElastiCache Serverless et GCP Memorystore. KeyDB (BSD) est le choix multi-threadé + actif-actif + FLASH pour des charges spécifiques. Xitoring monitore les trois avec les mêmes patterns d'intégration.
    Quelles versions de KeyDB sont prises en charge ?
    KeyDB 5.x et 6.x sont entièrement pris en charge. L'intégration détecte automatiquement si le multi-threading, l'active-replica ou les fonctionnalités de stockage FLASH sont activés et met en évidence les métriques spécifiques à KeyDB appropriées par-dessus l'ensemble `INFO` compatible Redis standard. La compatibilité fil-à-fil avec et l'écosystème Redis est préservée.

    Commencer à surveiller KeyDB aujourd'hui

    Configuration en moins de 60 secondes. Aucune carte bancaire requise. Statistiques complètes dès le premier jour.

    Commencer l'essai gratuit

    Continuez à explorer

    Connexes Intégrations