Cette page décrit Calíope 1.7, la version que je construis en ce moment. La 1.6 est sur l'App Store pour Mac, iPad, iPhone, Apple Watch, Apple TV et Apple Vision Pro. Le changelog indique dans quelle version chaque fonction est arrivée.
Ajoute un bouton « Ouvrir dans Calíope » à chaque sujet. Ne fonctionne qu'avec l'app installée.
Comment parcourir, lire et modifier les clés d’un serveur Redis.
Où le trouver : Espace de travail › Outils › Clés
S'applique à :RedisValkey 8.0+
L’explorateur affiche à gauche les clés de la base, regroupées par préfixe, et à droite le détail de celle que vous choisissez.
Comment les clés sont parcourues
Calíope les demande avec SCAN, par lots, et jamais avec KEYS : KEYS parcourt toute la base d’un coup et, comme Redis traite les commandes une par une, il ne répond à personne d’autre tant que cela dure. Le pied indique combien de clés ont été parcourues et si le parcours est terminé ou s’il reste des clés ; Charger plus de clés demande le lot suivant. Dans un cluster, chaque nœud primaire est parcouru et le pied indique combien ont répondu ; s’il en manque un, il le nomme avec son motif.
Le champ du haut est un motif MATCH —app:*, *:1001—, pas une recherche par contenu, et le serveur l’applique dès que vous cessez de taper.
Les groupes sont faits par Calíope, pas par le serveur
Redis n’a pas de dossiers : chaque clé est un nom plat. Les groupes viennent du découpage des noms par le caractère du menu Séparateur de la barre (:, /, ., | ou Aucun : liste plate), et le serveur n’en sait rien. Le séparateur se choisit pour chaque session, et chaque groupe indique combien de clés en dépendent. Au clavier, les flèches parcourent la liste et → et ← ouvrent et ferment le groupe choisi ; sur l’iPhone, toucher une clé ouvre son détail.
Type et expiration
Chaque clé porte son type, avec son glyphe et son nom, et son expiration, qui décompte dans le détail. Sans expiration et N’existe plus ne sont pas la même chose : la première est une clé qui dure jusqu’à ce que quelqu’un la supprime ; la seconde, une clé qui a expiré, ou qu’un autre client a supprimée, après avoir été parcourue.
Le détail
Sous la clé, le type et l’expiration viennent la taille —Longueur en octets, Champs ou Éléments—, l’Encodage interne et la Mémoire, puis la Valeur. La taille est demandée avant le contenu : une grande valeur se lit par morceaux, et un bouton charge le suivant. Dans une liste, chaque élément porte son Indice, car dans Redis la position fait partie de la donnée ; un ensemble prévient qu’il n’a pas d’ordre ; un ensemble trié affiche chaque Membre à côté de son Score, du plus petit au plus grand ; et un stream affiche d’abord ses propres données —première et dernière entrée, dernier id généré, plus grand id supprimé—, puis ses groupes de consommateurs avec leurs entrées en attente et leur retard, et enfin ses Entrées. Une valeur qui n’est pas en UTF-8 s’affiche en hexadécimal, et les caractères de contrôle, échappés.
Ce qui peut être modifié
Sur la clé choisie, depuis la barre et depuis le menu contextuel de la liste : Expiration… (ou Retirer l’expiration, si la clé expire) ; Renommer…, qui prévient si le nom existe déjà et n’écrase l’autre clé qu’avec Remplacer ; et Supprimer la clé…, qui demande toujours confirmation et nomme la clé, son type et sa taille. La touche Supprimer mène à cette même question, et, en dehors du Mac, le balayage de la ligne vers la gauche.
Dans la valeur : Modifier la valeur… sur une chaîne, qui conserve son expiration ; Ajouter un champ…, Modifier… et Retirer sur un hash ; Modifier… d’une position dans une liste ; Ajouter un membre… et Retirer sur un ensemble ; et Ajouter un membre…, Modifier… —qui change le score— et Retirer sur un ensemble trié. Retirer le dernier élément prévient que Redis supprime la clé dès qu’elle est vide. Chaque changement apparaît en place, sans recharger la liste, et reste dans le journal de ce que Calíope a exécuté.
L’expiration propre d’un champ
Depuis Redis 7.4 et Valkey 9, un champ de hash peut expirer de son côté, sans que la clé expire. Si le serveur le permet, la ligne d’un champ qui expire dit quand sous sa valeur, et Expiration… dans son menu définit ou retire celle de ce champ. Attention en modifiant la valeur d’un champ qui expire : le serveur retire son expiration quand il est réécrit, et la feuille prévient avant d’enregistrer. Avec un serveur plus ancien, il n’y a ni ligne ni action.
Une valeur binaire ne se modifie pas, ni une valeur de plus de 64 Kio, ni un stream. Et il n’y a ni vidage de la base ni suppression par motif : on supprime une clé à la fois, en sachant laquelle.
Profils ouverts avec Calíope 1.4
Un profil Redis synchronisé avec un appareil qui a encore Calíope 1.4 y est lu comme MariaDB sur le même port, car cette version ne connaît pas Redis ; si vous l’enregistrez depuis cet appareil, il est réécrit ainsi sur tous les vôtres. On le récupère en choisissant de nouveau Redis dans le profil : ni le serveur ni le mot de passe ne sont perdus.
Avec une étiquette d’environnement
Si l’étiquette du profil est en lecture seule, l’explorateur ne propose ni expiration, ni renommage, ni suppression, et la visionneuse ne propose ni modifier, ni ajouter, ni retirer : on ne fait que lire. Si elle confirme les écritures, chaque changement demande d’abord, avec l’étiquette devant, et supprimer ou retirer, qui demandaient déjà, la nomment dans leur question et ne demandent pas deux fois.
Ce que montre le panneau du serveur Redis et comment lire chaque chiffre.
Où le trouver : Espace de travail › Outils › Serveur
S'applique à :RedisValkey 8.0+
Le panneau montre l’état du serveur Redis tel que INFO le publie. Il se relit tout seul toutes les 2 secondes tant qu’il est à l’écran, et Actualiser le relit aussitôt. Sous chaque chiffre figure le champ d’INFO d’où il vient, pour que vous puissiez le comparer avec redis-cli.
Les six cartes Mémoire utilisée est used_memory, avec la limite (maxmemory) et le pourcentage, ou sans limite si maxmemory vaut 0 ; en dessous, ce que fait le serveur quand il est plein, et le pic.
Fragmentation est la mémoire que le processus occupe dans le système divisée par celle qu’il utilise. Au-dessus de 1, le processus occupe plus qu’il n’utilise : des trous que l’allocateur de mémoire n’a pas encore rendus. En dessous de 1, cela signifie souvent qu’une partie des données est dans le fichier d’échange, et c’est pire.
Taux de succès et Clés expirées sont cumulés depuis le démarrage du serveur, pas depuis la dernière lecture : un taux qui bouge à peine ne dit pas qu’il n’y a pas d’échecs en ce moment. Les clés expirées sont accompagnées des clés évincées faute de mémoire.
Clients connectés se mesure par rapport à maxclients, qui n’apparaît pas si le serveur n’autorise pas CONFIG. Si vous comparez avec redis-cli, vous en verrez un de plus là-bas : redis-cli lui-même.
Opérations par seconde sont calculées par le serveur (instantaneous_ops_per_sec), pas par Calíope, et changent d’un instant à l’autre.
Quand la mémoire ou les clients dépassent 90 % de leur limite, la carte indique Proche de la limite, avec un glyphe en plus de la couleur.
Persistance
Indique si AOF est activé, quelles sauvegardes RDB sont programmées (save), quand a eu lieu la dernière sauvegarde —avec date, heure et fuseau— et combien de modifications ne sont pas encore sauvegardées ; une sauvegarde échouée apparaît comme telle, avec son glyphe. Si AOF est désactivé et qu’aucune sauvegarde n’est programmée, la carte ne dit que cela, car le serveur perd toutes ses données s’il redémarre. S’il charge son instantané depuis le disque, il le dit d’abord : tant que ce n’est pas fini, les chiffres ne sont pas ceux du serveur en marche.
Pub/sub
Une photo prise à chaque lecture, pas un flux : Calíope ne s’abonne à aucun canal et n’affiche aucun message. Il liste les canaux qui ont des abonnés en ce moment, avec leur nombre, et les abonnements par motif. Si le serveur ne laisse pas la connexion utiliser PUBSUB, la carte le dit.
Serveur
Le pied donne la version, précédée du nom du produit, le mode, le rôle, le protocole (RESP2 ou RESP3) et la durée de fonctionnement. Dans un cluster, le panneau concerne un seul nœud, et le pied le nomme.
Valkey
Avec Valkey, la version vient de valkey_version : là, redis_version porte un numéro de compatibilité (7.2.4) qui n’est pas celui du serveur. Le mode vient de server_mode, car Valkey ne publie pas redis_mode.
Ce que mesure l’analyseur de mémoire, ce qu’il coûte au serveur et pourquoi sa somme ne correspond pas à used_memory.
Où le trouver : Espace de travail › Outils › Mémoire
S'applique à :RedisValkey 8.0+
Analyser parcourt les clés de la base avec SCAN, mesure chacune avec MEMORY USAGE et additionne ce qu’il a mesuré par préfixe, en coupant les noms sur le même séparateur que l’explorateur (: si vous n’en avez pas choisi un autre). Le serveur ne connaît pas ces groupes : c’est Calíope qui les construit.
Ce que cela coûte
Mesurer, c’est une lecture par clé, et dans une grande base c’est une vraie charge pour un serveur qui traite les commandes une à une. C’est pourquoi le parcours avance page par page, a un plafond et peut être arrêté. Le plafond se choisit avant d’analyser, dans le menu du plafond à côté de Analyser : de 10 000 à 5 000 000 clés, et 500 000 si vous ne le changez pas. Pendant qu’il tourne, le bouton devient Arrêter, qui figure aussi dans le panneau Activité, et fermer l’onglet ou la session l’arrête. Jusqu’à la fin, l’analyse précédente reste affichée. Dans un cluster, il parcourt chaque primaire et additionne.
Une estimation, pas un compte exact
Une chaîne est mesurée exactement. Une liste, un hash, un ensemble, un ensemble trié ou un stream sont mesurés par échantillonnage : le serveur regarde cinq éléments et estime le reste (SAMPLES 5). Si l’analyse s’est arrêtée au plafond ou si vous l’avez arrêtée, l’écran prévient que c’est un échantillon, avec un glyphe en plus du texte.
La grille Préfixe, Mémoire, Clés et Part : la part est celle de ce qui a été mesuré, pas de la base. Le menu de tri, juste à côté, trie par mémoire ou par clés, du plus grand au plus petit ; quand la grille a la place pour ses colonnes, on trie aussi en touchant l’en-tête de la colonne ; empilée, l’en-tête n’est pas dessiné. Les groupes s’ouvrent avec le chevron, ou avec → et ← au clavier. En haut, le chiffre dit toujours de quoi il s’agit —ce qu’occupent les clés mesurées— et, en dessous, si ce sont toutes les clés de la base (DBSIZE).
Pourquoi la somme ne correspond pas à used_memory
La somme des clés est toujours inférieure à la mémoire que le serveur dit utiliser (used_memory), et ce n’est pas une erreur de mesure. used_memory compte aussi ce que le serveur occupe pour lui-même —un serveur vide utilise déjà près de 1 Mo (used_memory_startup)—, les tampons des clients et de la réplication, et les clés de toutes les bases, alors que l’analyse ne parcourt que celle de la session. Le chiffre le plus proche est used_memory_dataset, qui retire la part fixe, et même lui inclut les autres bases. Avec peu de clés l’écart est énorme ; avec beaucoup, la somme s’en approche.
Ce que note le journal des commandes lentes de Redis, pourquoi son seuil est en microsecondes et ce qui se passe quand on le vide.
Où le trouver : Espace de travail › Outils › Commandes lentes
S'applique à :RedisValkey 8.0+
Le serveur note chaque commande dont l’exécution dépasse un seuil (SLOWLOG), et cet onglet affiche ce qu’il a noté. La durée est celle du travail du serveur : elle ne compte ni le réseau ni l’attente dans la file. L’onglet se relit tout seul toutes les 5 secondes tant qu’il est visible, et Actualiser le relit aussitôt.
Le seuil est en microsecondes
Dans Redis, le seuil (slowlog-log-slower-than) s’écrit en microsecondes, et non en secondes ou en millisecondes comme dans les autres moteurs : 10 000 µs font 10 ms, la valeur d’origine de Redis. En haut, la carte Journal du serveur le dit en une phrase, avec le nombre d’entrées qu’il garde (slowlog-max-len, 128 si personne ne l’a changé). Un seuil de 0 note toutes les commandes, même les rapides ; un seuil négatif éteint le journal, et la liste vide le dit alors : ce n’est pas la même chose que « aucune commande n’a dépassé le seuil ». Dans un cluster, la carte nomme le nœud : chaque nœud tient son propre journal, et celui-ci est celui du nœud du profil.
Une fenêtre, pas un historique
Le journal ne garde que les dernières entrées : quand une nouvelle arrive et qu’il est plein, la plus ancienne sort. Ce que vous voyez, c’est ce que le serveur conserve maintenant, pas tout ce qui a été lent depuis son démarrage.
Changer les réglages Modifier les réglages… ouvre une feuille avec Ce qui est noté (Ce qui dépasse le seuil, Tout ou Rien), Seuil (µs) et Entrées gardées. C’est écrit avec CONFIG SET puis relu, et ce qui s’affiche ensuite est ce que le serveur dit avoir. Ce n’est pas enregistré dans son fichier de configuration : un redémarrage remet ce que dit ce fichier.
La liste
Sur le Mac, c’est une grille avec Début (horloge du serveur), Durée, Commande et Client — cette dernière seulement si le serveur envoie le client —, triée en cliquant sur l’en-tête. En dehors du Mac, c’est une liste, et l’ordre se choisit dans le menu de tri de la barre : Plus récentes ou Plus lentes. Le champ Filtrer par commande ou client filtre ce qui a déjà été lu, sans revenir au serveur. Le serveur garde au plus 32 arguments de chaque commande et coupe chacun à 128 octets, et il le dit dans la commande elle-même (... (N more arguments)) : Calíope l’affiche tel quel. Un AUTH apparaît masqué.
Le détail d’une entrée
En choisissant une entrée — sur le Mac, il apparaît sous la grille ; en dehors du Mac, en la touchant, dans une feuille —, on voit la commande entière, l’heure avec son fuseau (l’horloge est celle du serveur), la durée en ms et en µs, l’adresse et le nom du client, et le numéro de l’entrée. Copier la commande la copie ; Ouvrir dans la console la laisse écrite dans la console, sans l’exécuter. Les deux sont aussi dans le menu contextuel, et sur le Mac un double-clic ou Retour ouvrent la console.
Vider Vider le journal, dans la barre, efface toutes les entrées du serveur (SLOWLOG RESET). Il demande d’abord, en disant combien partent, comptées à ce moment-là avec SLOWLOG LEN. C’est irréversible.
Avec une étiquette d’environnement
Si l’étiquette du profil est en lecture seule, Modifier les réglages… et Vider le journal n’y sont pas : les réglages et les entrées se lisent sans se modifier. Si elle confirme les écritures, modifier les réglages demande d’abord, avec l’étiquette devant, et vider la nomme dans sa question.
Qui est connecté au serveur Redis, ce que signifient connecté, inactif et les indicateurs, et ce qui se passe quand on déconnecte un client.
Où le trouver : Espace de travail › Outils › Clients
S'applique à :RedisValkey 8.0+
Cet onglet affiche ce que répond CLIENT LIST : chaque connexion ouverte sur le serveur, qu’elle vienne d’une application, de redis-cli ou de Calíope lui-même. La liste se relit toute seule toutes les 5 secondes tant qu’elle est visible, et Actualiser la relit aussitôt. Le champ Filtrer par nom, adresse ou commande filtre ce qui a déjà été lu —nom, adresse, dernière commande, utilisateur, bibliothèque et ID— sans revenir au serveur. Dans un cluster, la liste est celle du nœud du profil, et un avis le dit : chaque nœud a ses propres clients.
Les colonnes
Sur le Mac, c’est une grille avec Client, ID, Adresse, Connecté, Inactif, Base, Dernière commande, Indicateurs et Mémoire, que l’on trie en cliquant sur l’en-tête ; Utilisateur et Bibliothèque n’apparaissent que si une connexion les fournit (l’utilisateur ACL existe depuis Redis 6 ; la bibliothèque, depuis Redis 7.2 et seulement si le client s’est présenté). En dehors du Mac, chaque client est une ligne avec ces mêmes données, étiquetées, et l’ordre se choisit dans le menu de tri de la barre : Par ID, Les plus inactifs, Connectés le plus récemment ou Le plus de mémoire.
Connecté et inactif, ce n’est pas pareil Connecté (age) compte les secondes depuis l’ouverture de la connexion ; Inactif (idle), les secondes depuis sa dernière commande. Une connexion de pool est connectée depuis des heures et inactive depuis quelques secondes ; une connexion inactive depuis longtemps est ouverte sans rien faire, et occupe pourtant de la mémoire sur le serveur. Un client bloqué en attente de données —un BLPOP, par exemple— accumule aussi de l’inactivité pendant qu’il attend, et sa dernière commande le dit. Mémoire (tot-mem) est ce que la connexion occupe sur le serveur, tampons d’entrée et de sortie compris.
Les indicateurs Indicateurs (flags) s’affiche tel que l’écrit le serveur, une lettre par indicateur. Les plus courants : N, aucun en particulier (une connexion normale) ; b, bloquée en attente de données (BLPOP, XREAD BLOCK…) ; P, abonnée à pub/sub ; x, dans un MULTI pas encore exécuté ; S, une réplique connectée à ce serveur ; M, le primaire, sur la connexion qu’une réplique garde avec lui ; et O, un client en MONITOR.
Les connexions de Calíope sont dans la liste
Calíope est aussi un client, donc ses connexions apparaissent dans la liste, avec le nom Caliope et la bibliothèque caliope ; leur dernière commande est en général la lecture elle-même (client|list). Elles sont marquées d’un symbole et de l’étiquette Cette session, et on ne peut pas les déconnecter d’ici : les fermer fermerait la session. Calíope les reconnaît à leur ID, pas à leur nom : une autre instance de Calíope connectée au même serveur porte le même nom, et celle-là est bien un autre client.
Déconnecter Déconnecter… ferme la connexion du client sélectionné (CLIENT KILL ID). Il demande toujours d’abord, en nommant le client, son adresse, son ID et sa dernière commande, et en prévenant que ce qu’il avait en cours —une transaction, un abonnement ou une commande bloquée— est perdu ; on confirme avec Déconnecter. Sur le Mac, on y arrive par la barre et par le menu contextuel ; en dehors du Mac, par le menu contextuel et en balayant la ligne vers la gauche, ce qui demande sans déconnecter. Ensuite, la ligne disparaît sur place et un avis le dit. Le client peut se reconnecter —beaucoup de pools le font tout seuls—, et il réapparaît alors à la lecture suivante avec un autre ID. Le menu contextuel propose aussi Copier l’adresse.
Quand le serveur répond 0
Si le client était déjà parti entre la lecture et la confirmation, le serveur répond qu’il a fermé 0 connexion. Ce n’est pas un échec : Calíope dit qu’il n’était plus connecté et retire la ligne.
Avec une étiquette d’environnement
Si l’étiquette du profil est en lecture seule, la déconnexion n’est pas proposée. Si elle confirme les écritures, la question de déconnexion nomme l’étiquette.
Comment saisir et lire une commande dans la console Redis, quelles commandes elle n’exécute pas et pourquoi, et lesquelles demandent de taper leur nom d’abord.
Où le trouver : Espace de travail › Outils › Console
S'applique à :RedisValkey 8.0+
La console envoie à Redis la commande que vous tapez, par la même session que les autres onglets. Exécuter —ou Entrée— l’exécute ; sur le Mac, Option+Entrée coupe la ligne sans l’exécuter —une longue commande tient sur plusieurs, et le saut compte comme une espace—, et en dehors du Mac la touche Retour exécute toujours. La ligne est découpée comme dans redis-cli : les arguments sont séparés par des espaces, et les guillemets simples ou doubles regroupent en un seul ce qui contient des espaces ; entre guillemets doubles, \n, \t et \xHH sont acceptés. Un guillemet resté ouvert n’est pas envoyé, et la sortie dit pourquoi.
L’historique
La flèche haut rappelle la commande précédente quand le curseur est sur la première ligne, et la flèche bas la suivante quand il est sur la dernière ; les boutons Commande précédente de l’historique et Commande suivante de l’historique font de même sans clavier. Il garde les 200 dernières lignes, y compris celles que la console n’a pas exécutées, sans répéter deux fois de suite la même. Effacer vide la sortie, pas l’historique. La sortie, l’historique et ce qui est en cours de saisie sont toujours là quand vous changez d’onglet et revenez.
Lire une réponse
- Un statut comme OK ou PONG s’affiche tel quel.
- Un entier est précédé de (entier).
- Un texte est toujours entre guillemets, avec les caractères de contrôle échappés comme dans redis-cli ("a\r\nb") ; un texte qui n’est pas en UTF-8 s’affiche en hexadécimal, avec sa longueur en octets.
- (nul) signifie l’absence de valeur, et ce n’est pas la même chose que la chaîne vide, qui s’affiche "".
- Une liste est numérotée, et une liste vide affiche (tableau vide). Une table —ce que renvoient HGETALL ou CONFIG GET— s’affiche en paires numérotées champ => valeur. Un ensemble porte un en-tête qui indique combien de membres il a et qu’ils n’ont pas d’ordre, et ses membres sont à puces, sans numéro.
- Une erreur s’affiche en rouge, avec un glyphe et (erreur) devant, et avec le préfixe que lui donne le serveur (WRONGTYPE, ERR…).
- Une réponse de plus de 2000 lignes est coupée, et l’avis renvoie à « Clés », qui parcourt les clés page par page.
Dans un cluster, chaque réponse indique qui a répondu : le primaire du slot de la première clé ou, si la commande n’a pas de clé, le nœud du profil. Une commande sans clé —DBSIZE, INFO— ne compte que ce nœud.
Ce que la console n’exécute pas, et pourquoi
Chaque refus s’affiche dans la sortie avec son motif, et la commande n’atteint jamais le serveur. En dessous, « Ce qu’il ne faut pas faire » ouvre le sujet du Manuel du DBA qui explique pourquoi :
- KEYS parcourt toutes les clés d’un coup et bloque le serveur pendant ce temps. Pour chercher des clés, utilisez « Clés », qui les parcourt page par page avec SCAN.
- MONITOR dégrade le serveur tant qu’il tourne et ne peut pas être arrêté de l’extérieur.
- SUBSCRIBE, PSUBSCRIBE et SSUBSCRIBE feraient arriver les messages du canal mêlés aux réponses des autres commandes. Les canaux actifs et leurs abonnés sont dans « Serveur ».
- SHUTDOWN arrête le serveur.
- DEBUG a des sous-commandes qui figent ou font tomber le serveur (DEBUG SLEEP, DEBUG SEGFAULT).
- RESET et HELLO changent le protocole sous la connexion que Calíope utilise, et CLIENT REPLY OFF ou SKIP cessent de répondre : l’ordre suivant attendrait sa réponse pour toujours. SYNC et PSYNC font de la connexion un lien de réplique, qui reçoit tout ce qui s’écrit sur le serveur.
- SELECT laisserait l’interface afficher une base et en lire une autre : la base se choisit avec le sélecteur de l’outil.
- MULTI, EXEC, DISCARD, WATCH et UNWATCH : une transaction vit sur une seule connexion, et la console envoie chaque ligne par celle qui est libre, si bien que les ordres suivants pourraient partir sur une autre et la transaction resterait ouverte. Pour plusieurs ordres exécutés ensemble, sans rien entre eux, il y a EVAL avec un script.
- Une commande qui attend une donnée —BLPOP, BRPOP, BLMOVE, BZPOPMIN, XREAD … BLOCK, WAIT…— avec un délai de 0, c’est-à-dire une attente sans fin, ou de plus de 10 secondes (plus de 10000 millisecondes dans XREAD BLOCK, WAIT et WAITAOF) : pendant qu’elle attend, elle garde l’une des connexions qu’utilisent tous les outils de la session. Avec un délai plus court, elle s’exécute.
Celles qui demandent de taper leur nom FLUSHDB et FLUSHALL effacent toutes les clés —de la base, ou de toutes les bases— et ne peuvent pas être annulées ; REPLICAOF, SLAVEOF, CLUSTER RESET et CLUSTER FAILOVER changent la topologie, et d’autres clients peuvent perdre l’accès à leurs données. Pour celles-ci, une bande apparaît au-dessus du champ, qui dit ce qui va être effacé ou changé et sur quel serveur, avec un champ où l’on tape le nom de la commande —sans tenir compte des majuscules— et un bouton qui reste inactif tant qu’il n’est pas tapé. Annuler la laisse sans l’envoyer, et la sortie le dit.
Tout le reste s’exécute, y compris EVAL, CONFIG SET et CLIENT KILL. Ce qui s’exécute va dans le journal des commandes, avec le mot de passe d’AUTH masqué.
Cette liste vit dans le code de Calíope, à un seul endroit, et tout chemin qui exécute une commande que vous avez tapée la consulte : si elle change, ce sujet change avec elle.
Avec une étiquette d’environnement
Si l’étiquette du profil protège la session, Calíope demande au serveur ce que chaque commande écrit (COMMAND INFO, une fois par nom dans la session). Écrit ce que le serveur marque comme écriture, y compris EVAL, dont il déclare les clés en lecture et écriture, ainsi que ce que le serveur ne connaît pas. Si l’étiquette est en lecture seule, cela n’est pas envoyé et la sortie nomme l’étiquette ; si elle confirme les écritures, cela ne s’exécute qu’en tapant le nom de la commande, comme FLUSHDB, et la question nomme l’étiquette. Ce qui est administratif et modifie le serveur sans toucher aux clés, sans que le serveur le marque comme écriture — CONFIG SET, CLIENT KILL, REPLICAOF, SLOWLOG RESET, SCRIPT FLUSH, ACL SETUSER, SAVE… —, Calíope le compte quand même comme écriture ; CONFIG GET et CLIENT LIST, qui lisent, s’exécutent comme d’habitude.
Ce que montre la topologie d’une session Redis : primaires, répliques et fragments, pourquoi le retard se mesure en octets, ce que sont les slots, ce que veut dire un cluster en échec et ce que dit Sentinel.
Où le trouver : Espace de travail › Outils › Topologie
S'applique à :RedisValkey 8.0+
La topologie montre comment le serveur de la session est monté. Un cluster s’affiche comme Cluster ; un nœud isolé qui a des répliques, comme Nœud autonome et sa réplication. En haut, un résumé : combien de nœuds répondent —dans un cluster, aussi combien de primaires ; avec un nœud isolé, combien de répliques il a— et ceux qui ne répondent pas, nommés par leur adresse. En dessous, Diagramme dessine une boîte par nœud, regroupées par fragment, avec le primaire en haut et ses répliques en dessous, et Nœuds donne la même chose dans un tableau. Elle se relit toute seule toutes les 5 secondes tant qu’elle est à l’écran, et Actualiser la relit aussitôt.
Le retard se mesure en octets, pas en secondes
Une réplique Redis ne confirme pas une heure : elle confirme jusqu’à quel octet du flux de réplication elle a reçu. La colonne Retard (octets) est donc la position du primaire moins celle de la réplique. Calíope lit le primaire deux fois, avant d’interroger qui que ce soit et à la fin : ce qu’il a avancé entre les deux lectures est le plancher, et en dessous la réplique apparaît À jour, car cet écart ne se distingue pas du temps qu’il faut pour interroger une autre machine. Ce n’est qu’au-dessus qu’elle apparaît En retard. Le lag= que Redis écrit à côté de chaque réplique dans INFO replication est autre chose : les secondes depuis sa dernière confirmation.
Quand un primaire redémarre, il commence un nouveau flux, et sa réplique n’a pas de retard mesurable tant qu’elle ne s’est pas resynchronisée : le tableau indique Sur un autre flux de réplication que son primaire et le retard « non mesuré (autre flux) », au lieu d’afficher 0 octet. Si la réplique a perdu le lien avec son primaire, elle apparaît Liaison avec son primaire coupée.
Les slots
Un cluster répartit les clés sur 16384 slots : chaque clé tombe dans l’un d’eux selon le CRC16 de son nom, et chaque primaire sert une plage. Le nombre est fixe et petit à dessein : la carte de quel primaire sert chaque slot circule entre les nœuds à chaque battement, et doit rester petite. La colonne Emplacements donne la plage de chaque primaire, et le résumé dit combien des 16384 ont un propriétaire.
Quand le cluster échoue
« État du cluster : fail » veut dire que le cluster n’accepte plus de commandes : des slots n’ont plus de primaire vivant pour les servir, parce qu’un primaire est tombé sans réplique pour le remplacer, ou que plusieurs sont tombés à la fois. Un nœud qui ne répond pas apparaît Ne répond pas, avec l’erreur technique à côté, et rien d’autre n’est affirmé à son sujet : ni son rôle ni son retard.
Sentinel
Une session ouverte sur Sentinel montre ce que dit la sentinelle : chaque primaire qu’elle surveille, avec ses répliques dessous, et les sentinelles, celle de la session en premier et comme Sentinelle. Aucun n’est interrogé : l’état de chacun est celui que publie Sentinel —en panne, en basculement ou bon, avec son dernier PING réussi—. Le retard de ses répliques dit « sans décalage (Sentinel ne le publie pas) » : Sentinel ne publie pas le décalage du primaire, et sans lui il n’y a pas de soustraction. Pour voir ce retard en octets, ouvrez la session sur le primaire.
Avec VoiceOver, le tableau est l’alternative au diagramme : chaque ligne est lue une fois, avec le nom de chaque colonne devant sa valeur.
Ce qu’est un rapport Redis, quels champs il a et ce qu’il coûte au serveur : un parcours des clés à chaque exécution.
Où le trouver : Espace de travail › Outils › Rapports
S'applique à :RedisValkey 8.0+
Un rapport Redis n’a pas de requête : c’est un parcours des clés transformé en tableau, avec une ligne par clé. On le crée avec Nouveau rapport dans une session Redis, et à la place de l’éditeur de texte apparaissent ses champs.
Ce que vous choisissez Motif est un glob sur le nom de la clé (app:*, session:??, user:[ab]*) ; vide, c’est toutes. Type ne garde que les clés de ce type. Colonnes active key, type, ttl, memory, encoding et length, qui sortent dans l’ordre où vous les activez ; dans Champs de hash, chaque champ, séparé par des virgules, est une colonne de plus avec la valeur de ce champ d’un hash, vide sur une clé qui n’est pas un hash ou qui ne l’a pas. Plafond de lignes dit combien de lignes au maximum ; vide, c’est le plafond du moteur.
Ce que cela coûte
Chaque fois que vous appuyez sur Exécuter, Calíope parcourt avec SCANtoutes les clés qui correspondent au motif — sur un cluster, sur chaque primaire — et seulement ensuite demande les colonnes des lignes gardées. Le plafond coupe les lignes, pas le parcours : avec un motif large sur une base de millions de clés, le rapport prend du temps même s’il en demande dix. Arrêter l’arrête avant la page suivante du parcours.
Le tableau
Les lignes sortent triées par clé, si bien que deux exécutions donnent le même tableau ; s’il y en a plus que le plafond, on garde les premières dans cet ordre, et le tableau indique qu’il a été coupé. Dans un cluster, si un slot change de propriétaire pendant le parcours —une migration—, le parcours entier est repris ; si le cluster continue de déplacer des slots pendant trois parcours de suite, le rapport échoue et le dit au lieu de donner un tableau auquel pourraient manquer des clés. memory est ce que répond MEMORY USAGE : sur une collection, c’est une estimation par échantillonnage. Une clé ou un champ qui ne sont pas en UTF-8 sortent comme 0x… avec leur longueur, et leur colonne est marquée comme binaire.
Paramètres
Un paramètre s’écrit $$nom dans le motif et se déclare avec Déclarer les paramètres. Sa valeur est cherchée telle quelle : un * dans la valeur est un astérisque, pas un joker. Elle s’écrit selon son type déclaré, et une valeur qui n’est pas de ce type est refusée avant l’exécution.
Le reste Exporter l’enregistre dans n’importe quel format du menu, PDF compris, et Historique garde chaque exécution, avec ses lignes ou avec son échec. Un rapport Redis ne s’exécute que dans une session Redis : dans une autre, l’outil dit que le rapport n’est pas de cette session et ne le laisse pas exécuter. Il se planifie avec Planifier comme les autres : le planificateur ouvre sa propre connexion depuis le profil.
Si une lecture échoue après une bonne, le panneau continue d’afficher les chiffres précédents sous un avis qui précise qu’ils ne sont pas actuels.
Où le trouver : Espace de travail › Outils › Serveur
S'applique à :RedisValkey 8.0+
Si une lecture d’INFO échoue après une lecture réussie, le panneau ne se vide pas : il continue d’afficher les chiffres précédents sous un avis avec l’erreur, qui précise qu’ils ne sont pas actuels. L’avis disparaît à la lecture réussie suivante.
Si la première lecture échoue, il n’y a rien d’antérieur à afficher : l’erreur apparaît avec Réessayer. Si l’échec vient d’une coupure de la connexion, Calíope la signale en plus comme toute autre coupure.
Si une analyse échoue après une analyse terminée, l’analyseur continue d’afficher le résultat précédent sous un avis avec la raison.
Où le trouver : Espace de travail › Outils › Mémoire
S'applique à :RedisValkey 8.0+
Si une analyse échoue après une analyse terminée, l’analyseur ne se vide pas : il continue d’afficher le résultat précédent sous un avis avec la raison.
Sans aucun résultat antérieur, l’erreur apparaît avec Réessayer, qui relance l’analyse avec le même plafond de clés.
Si une lecture du journal échoue après une bonne, l’onglet continue d’afficher les entrées précédentes sous un avis avec l’erreur.
Où le trouver : Espace de travail › Outils › Commandes lentes
S'applique à :RedisValkey 8.0+
Si une lecture de SLOWLOG échoue après une lecture réussie, l’onglet continue d’afficher les entrées précédentes sous un avis avec l’erreur, qui précise qu’elles ne sont pas actuelles. L’avis disparaît à la lecture réussie suivante, qui arrive d’elle-même au bout de 5 secondes. Un échec au vidage du journal apparaît dans le même avis.
Si la première lecture échoue, il n’y a rien d’antérieur à afficher : l’erreur apparaît avec Réessayer. Si l’échec vient d’une coupure de la connexion, Calíope la signale en plus comme toute autre coupure.
Si une relecture échoue après une bonne, l’onglet continue d’afficher la liste précédente sous un avis avec la raison.
Où le trouver : Espace de travail › Outils › Clients
S'applique à :RedisValkey 8.0+
Si une relecture de CLIENT LIST échoue après une lecture réussie, l’onglet continue d’afficher la liste précédente sous un avis avec la raison, qui précise qu’elle n’est pas actuelle.
Si la première lecture échoue, il n’y a rien d’antérieur à afficher : l’erreur apparaît avec Réessayer. Si l’échec vient d’une coupure de la connexion, Calíope la signale en plus comme toute autre coupure.
Si la connexion est coupée avant la réponse, la ligne reste dans la sortie avec la raison, et une confirmation en attente est abandonnée.
Où le trouver : Espace de travail › Outils › Console
S'applique à :RedisValkey 8.0+
Si la connexion est coupée avant l’arrivée de la réponse, la ligne reste dans la sortie avec la raison de la coupure et une icône d’éclair, et Calíope signale la coupure comme toute autre. Une confirmation en attente est abandonnée.
Une erreur renvoyée par le serveur, comme -ERR, n’est pas ce cas : c’est une réponse, qui apparaît comme une erreur dans la sortie.
Mots-clés : Redis, console, pas de réponse, coupure, connexion
Si une relecture échoue, l’onglet continue d’afficher la topologie précédente sous un avis ; et si aucun nœud ne renvoie la carte du cluster, il dessine celle lue à l’ouverture de la session.
Où le trouver : Espace de travail › Outils › Topologie
S'applique à :RedisValkey 8.0+
Si une relecture échoue après une lecture réussie, l’onglet continue d’afficher la topologie précédente sous un avis avec la raison, qui précise qu’elle n’est pas actuelle.
Si aucun nœud ne renvoie la carte du cluster, l’onglet dessine celle que la session a lue à l’ouverture, sous un avis qui précise qu’elle peut ne plus être à jour.
Si la première lecture échoue, il n’y a rien d’antérieur à afficher : l’erreur apparaît avec Réessayer. Si l’échec vient d’une coupure de la connexion, Calíope la signale en plus comme toute autre coupure. Une fois la session fermée, rien n’est signalé.