Comment inspecter une instance Redis depuis un client desktop

Redis n'est pas une base relationnelle. Pas de schéma, pas de tables, pas de requêtes SQL pour explorer ce qui est dedans. C'est l'intérêt du moteur, mais en debug ou en exploration ça change la manière de l'inspecter. Quand une clé manque, quand un TTL semble incohérent, quand on cherche à comprendre la consommation mémoire d'un namespace, on ouvre rarement Datadog ou Prometheus. On ouvre un client.

Ce guide passe en revue les outils desktop courants pour inspecter une instance Redis, les opérations critiques à connaître, et l'approche choisie dans QoreDB.

Le point de départ : redis-cli

redis-cli reste l'outil de référence. Il est livré avec Redis, il parle tous les dialectes du protocole, et il sait afficher ce qui se passe en direct via MONITOR ou PSUBSCRIBE.

Pour l'inspection ponctuelle il fait le job : TYPE clé, TTL clé, MEMORY USAGE clé, OBJECT ENCODING clé. Pour scanner un namespace, SCAN 0 MATCH user:* COUNT 100 répond immédiatement.

La limite n'est pas technique, c'est l'ergonomie. Lister 50 hashs en CLI, c'est lisible. Parcourir 5000 hashs avec des champs imbriqués, beaucoup moins. Comparer plusieurs sorted sets, encore moins. Les clients desktop ne remplacent pas redis-cli, ils prennent le relais quand la quantité ou la structure dépasse ce que le terminal expose proprement.

SCAN, pas KEYS

Avant de parler de clients, un point qui revient dans toutes les bonnes pratiques Redis : KEYS * est bloquant. Sur une instance de production, ça peut figer l'event loop pendant plusieurs secondes. SCAN est itératif, non bloquant, et c'est l'opération que tout client sérieux doit utiliser pour énumérer les clés.

Un client desktop qui appelle KEYS * pour peupler son arbre est un client à éviter sur une instance partagée. SCAN avec un curseur, un MATCH et un COUNT raisonnable est l'approche correcte. C'est ce que font Redis Insight et la plupart des clients modernes, et c'est aussi ce que QoreDB utilise pour la navigation.

Tour d'horizon des clients desktop

Redis Insight est le client officiel publié par Redis Ltd. Il couvre les types natifs, le profiler, l'analyse mémoire, et expose les modules JSON, Search et TimeSeries. C'est l'outil le plus complet pour une équipe qui fait du Redis intensif et utilise Redis Stack.

Another Redis Desktop Manager est un client cross-platform open source basé sur Electron. Plus léger que Redis Insight, il couvre les types natifs et les opérations courantes. C'est un bon outil pour de l'inspection rapide.

DBeaver propose un plugin Redis. DBeaver est conçu pour le SQL, et le clé-valeur s'y prête moins naturellement. Le plugin fonctionne pour des inspections simples mais ne tire pas parti des opérations spécifiques à Redis comme MEMORY USAGE ou OBJECT ENCODING.

redis-cli avec tmux reste une option valide pour les sysadmins qui préfèrent rester dans le terminal. Combiné avec less ou jq pour parser des strings JSON, ça suffit pour beaucoup d'usages.

Les opérations critiques à connaître

Un client desktop n'a pas besoin de tout faire. Il doit faire correctement les opérations utiles en debug et en exploration.

Lister les bases. Redis a 16 bases numérotées par défaut (0 à 15). Switcher entre elles via SELECT n et afficher DBSIZE pour chaque permet d'identifier rapidement où se trouvent les données.

Énumérer par préfixe. SCAN 0 MATCH user:* COUNT 500 itéré jusqu'à curseur 0. Affichage progressif des résultats sans bloquer l'UI.

Inspection par type. Une string c'est GET. Un hash c'est HGETALL ou HSCAN. Une list c'est LRANGE. Un set c'est SSCAN. Un sorted set c'est ZRANGE WITHSCORES. Un stream c'est XRANGE. Le client doit appeler TYPE clé d'abord, puis la bonne commande de lecture.

TTL. Afficher TTL ou PTTL pour chaque clé, distinguer expire défini, jamais expirant, et clé expirée mais pas encore collectée par le ramasse-miette.

Memory profiling. MEMORY USAGE clé donne la taille réelle en bytes. Sur un namespace de 100 000 clés, agréger par préfixe permet d'identifier ce qui pèse.

INFO. Les sections memory, clients, replication et persistence donnent souvent plus d'information qu'un dashboard pour comprendre une situation atypique.

Comment QoreDB intègre Redis

QoreDB intègre Redis comme un driver natif dans le même client que PostgreSQL, MySQL, MongoDB, SQLite et SQL Server. L'objectif n'est pas de remplacer Redis Insight pour qui fait du Redis Stack à temps plein. L'objectif est qu'un développeur qui jongle entre plusieurs bases ait Redis dans la même fenêtre que ses autres connexions.

Le driver utilise SCAN pour la navigation, appelle TYPE pour adapter la vue, expose TTL et MEMORY USAGE, et bascule entre les bases via SELECT. Les types natifs (string, hash, list, set, sorted set, stream) sont affichés dans une grille tabulaire adaptée à chaque type.

Les commandes sont classifiées en read, mutation et dangerous. Les commandes destructrices (FLUSHALL, FLUSHDB, SHUTDOWN, EVAL, MIGRATE) sont soumises aux garde-fous d'environnement comme pour les bases SQL : bloquées en Prod par défaut, soumises à confirmation explicite ailleurs.

La grille de résultats est virtualisée, donc parcourir un hash de 50 000 champs ne sature pas l'UI. L'audit log capture chaque commande envoyée avec son empreinte normalisée, ce qui aide à reconstruire ce qui a été fait pendant une session de debug.

Ce qu'il faut retenir

Inspecter Redis depuis un client desktop est moins normalisé qu'avec une base SQL. Il n'y a pas d'équivalent à JDBC, chaque outil interprète la navigation à sa manière. Le bon réflexe est de vérifier que le client utilise SCAN plutôt que KEYS, qu'il appelle TYPE avant d'afficher une clé, et qu'il distingue clairement les opérations dangereuses des opérations de lecture. Tout le reste est confort et productivité.