Demo days - 2026-08-15

Démo par @pulpdrew Les variables de tableau de bord constituent la principale nouveauté de cette semaine. Elles s’appuient sur le modèle de filtres déjà utilisé par les tableaux de bord : tout filtre existant ou nouveau peut être mis à disposition sous forme de variable. Par défaut, une variable utilise le nom d’affichage du filtre. Si ce nom contient des caractères spéciaux ou si deux filtres partagent le même nom d’affichage, vous pouvez attribuer un nom de variable personnalisé. Ce nom reste inchangé si le filtre est renommé par la suite. La page de configuration affiche le nom à utiliser pour la référence et, une fois la variable activée, il apparaît également dans l’infobulle du filtre. Les graphiques en SQL brut prennent en charge plusieurs façons d’utiliser les variables. $__filter($var) développe la sélection actuelle pour une variable. C’est l’équivalent, pour une seule variable, de la macro existante $__filters, qui développe tous les filtres. L’ajout le plus intéressant est $__conditionalAll(condition, $var). Son premier argument est une condition et le second, une variable. Lorsque la variable a une sélection, la condition est incluse dans la requête. En l’absence de sélection, l’expression entière devient 1 = 1 et n’a aucun effet sur le filtrage. Cela permet d’effectuer des mappages entre sources. Un tableau de bord peut mapper les codes d’état des traces vers error ou info, ce qui permet à un filtre de niveau de gravité défini sur une table de logs de filtrer une table de traces. Sélectionnez error au niveau du tableau de bord pour que la requête de traces filtre les statuts d’erreur. L’autocomplétion suggère toutes les variables disponibles et les formats qu’elles prennent en charge. À la suite d’une suggestion de Brandon, elle affiche désormais le développement réel en ligne à partir de la sélection actuelle. Les suggestions de macros incluent également leur développement, et une nouvelle section de documentation explique le rôle de chaque macro. La validation détecte les références à des variables inexistantes et les macros appelées avec des arguments incorrects. Les graphiques créés avec le builder utilisent la même substitution de variables dans la plupart des champs modifiables, pour les entrées SQL comme Lucene. Les variables fonctionnent dans WHERE, GROUP BY, HAVING et ORDER BY, avec la même autocomplétion et la même validation. Les champs Lucene prennent en charge les variables, mais pas les macros. Les champs du builder SQL proposent les macros liées aux variables plutôt que l’ensemble complet disponible en SQL brut. Les alertes ont une règle stricte : chaque variable est évaluée avec sa valeur vide. Si une requête d’alerte référence des variables, l’éditeur vous avertit avant de l’enregistrer. L’aperçu et le SQL généré affichent le développement vide, y compris sur la page de détail de l’alerte, et la tâche d’alerte applique ces valeurs vides lors de son exécution. La configuration des variables reste conditionnée par NEXT_PUBLIC_ENABLE_DASHBOARD_VARIABLES. Lorsqu’aucune variable n’est configurée, le comportement du tableau de bord reste inchangé. PR associés : #2836 ajoute la configuration des variables de filtre, #2873 substitue les variables dans les graphiques en SQL brut, #2874 autocomplétion et validation des variables SQL de tableau de bord, #2901 prend en charge les variables de tableau de bord dans les tuiles du builder de graphiques, #2910 développe les variables en valeurs vides dans les requêtes d’alerte, #2923 prend en charge les requêtes de valeurs de variables dépendantes, #2937 prend en charge les macros imbriquées et les références à des variables dans les macros, #2944 ajoute les variables de tableau de bord à l’API externe Démo par @wrn14897 Jusqu’à présent, une alerte n’offrait qu’une bande d’historique. Il n’y avait pas grand-chose à examiner pour comprendre ce qu’elle faisait réellement. La nouvelle page de détail affiche chaque évaluation. Pour les alertes groupées, elle indique quel groupe s’est déclenché et quelle valeur a franchi le seuil. Chaque entrée inclut également la durée de la requête ClickHouse, ainsi que la configuration de l’alerte. La colonne des buckets remplis a posteriori mérite quelques explications. Lorsqu’une évaluation est manquée, l’exécution suivante comble cette lacune en traitant le bucket manquant. La présence de buckets remplis a posteriori signifie donc que l’alerte est en retard. Une requête ClickHouse lente laisse désormais une trace visible au lieu de retarder discrètement les évaluations suivantes. Les marqueurs du graphique s’alignent sur le début du bucket évalué, ce qui permet de mieux voir quand l’alerte s’est déclenchée et quand elle est revenue à l’état OK. Vous pouvez également modifier ou supprimer une alerte directement depuis la page de détail. Il n’est plus nécessaire de revenir à la fenêtre modale de recherche enregistrée ou à l’éditeur de tuile du tableau de bord. L’ajout d’une plus grande partie de la configuration de l’alerte à cette page est encore à l’étude. La page reste derrière NEXT_PUBLIC_ENABLE_ALERT_DETAILS. PR associés : #2833 modèle de lecture des évaluations d’alerte et GET /alerts/:id/evaluations, #2834 persistance des erreurs d’évaluation des alertes et des analytics dans AlertHistory, #2835 page de détail d’une alerte avec historique des évaluations, #2928 alignement des marqueurs du graphique d’alerte sur le début du bucket évalué, #2931 possibilité de modifier et supprimer des alertes depuis la page de détail de l’alerte Démo par @brandon-pereira Les alertes déclenchées disposent désormais d’un bouton Investiguer. Cliquez dessus pour lancer une investigation dans un notebook depuis la page des alertes ou la page de détail d’une alerte. L’objectif à terme est de lancer automatiquement ces investigations lorsqu’une alerte se déclenche. Le bouton constitue une étape intermédiaire utile, et non la forme finale envisagée. Chaque outil du serveur MCP ClickStack inclut désormais des indications d’annotation. Auparavant, le serveur ne signalait pas qu’un outil était en lecture seule tandis qu’un autre modifiait ou supprimait des données. L’ajout de readOnlyHint et destructiveHint fournit aux clients suffisamment d’informations pour traiter ces outils différemment. Les opérations de lecture peuvent se poursuivre sans interruption, tandis que les actions destructrices peuvent attendre une approbation explicite. La suppression d’une alerte en est l’exemple évident. Vous devriez être invité à confirmer avant qu’elle ne soit effectuée. La dernière modification concerne les outils que les agents choisissent en premier lieu. L’utilisation de clickstack_sql avait augmenté à mesure que l’ensemble d’outils s’élargissait, faute de politique de sélection claire. Les agents recouraient au SQL brut même lorsque les outils de création étaient mieux adaptés. Cela a des implications qui vont au-delà de l’exactitude des requêtes. Le SQL brut crée des tuiles de résultats statiques. Les outils de création, clickstack_table, clickstack_timeseries et clickstack_search, produisent des tuiles que vous pouvez explorer et à partir desquelles vous pouvez pivoter. Le MCP oriente désormais les agents en priorité vers ces outils de création et réserve le SQL brut aux requêtes qu’ils ne peuvent véritablement pas exprimer. Les scores d’évaluation se sont sensiblement améliorés après cette modification. PR associés : #2838 ajoute des annotations aux outils MCP (readOnlyHint, etc.), #2840 oriente les agents vers les outils de création de requêtes plutôt que vers le SQL brut, #2870 oriente les agents de tableau de bord vers des filtres de tuiles par série. Le bouton Investiguer lui-même n’a pas de PR publique associée. Démo par @wrn14897 Auparavant, afficher plusieurs métriques sur un même graphique nécessitait d’exécuter une requête ClickHouse par série, puis de fusionner les jeux de résultats dans Node ou dans le navigateur. Un graphique comportant N séries générait N requêtes. Les graphiques à plusieurs séries sont désormais compilés en une seule requête SQL. Chaque série devient une CTE, puis ClickHouse les fusionne à la fin. Les ratios suivent le même principe : les deux séries sont produites dans une seule requête et le ratio est calculé dans la projection finale. La réduction du nombre de requêtes constitue le bénéfice immédiat. Cette même structure de requête pose également les bases des formules de métriques. Une formule nécessite que chaque série soit disponible sous forme de colonnes dans une même relation afin de pouvoir être exprimée dans le SELECT final. C’est désormais exactement ce que produit le compilateur, et les travaux sur les formules suivent déjà. Cette modification a révélé une régression. Les tuiles à plusieurs séries ne s’affichaient pas lorsqu’elles combinaient des agrégations produisant des flottants et des entiers. Il suffisait de combiner un quantile d’histogramme, qui renvoie un Float64, avec un count d’histogramme, qui renvoie un Int64, pour la déclencher. Le UNION ALL composé et le pivot faisaient passer chaque série par la même colonne, ce qui amenait ClickHouse à élargir le type en Variant(Float64, Int64). Ce cas est désormais corrigé. PR associées : #2858 étendre la couverture des tests d’entiers pour la fusion de métriques à plusieurs séries, #2859 déplacer vers ClickHouse le calcul de fusion des métriques à plusieurs séries, #2907 couverture des tâches d’alerte pour les tuiles de métriques à plusieurs séries, #2916 corriger les graphiques de métriques à plusieurs séries mélangeant des agrégations de flottants et d’entiers, #2872 modèle d’expression de formule, #2908 afficher les formules dans la requête de métriques composée, #2909 interface de l’éditeur de graphiques pour les formules de métriques Démo par @pulpdrew Les tests des variables de tableau de bord ont révélé une régression distincte : l’autocomplétion Lucene avait discrètement cessé de fonctionner presque partout. La page de recherche était le seul endroit où elle fonctionnait encore. L’autre modification concerne la page Join Team, où les utilisateurs invités définissent leur mot de passe. La page n’affichait pas les exigences de mot de passe, alors que le backend les appliquait. La saisie d’une valeur non valide affichait un message générique « Le mot de passe n’est pas valide » et laissait l’utilisateur deviner la politique appliquée. Ces exigences sont désormais visibles. L’examen du composant partagé qui les affiche a également révélé deux divergences avec le backend : les caractères spéciaux pris en compte et la longueur maximale du mot de passe. Les deux ont été corrigées. PR associés : #2902 rétablit l’autocomplétion Lucene, #2904 affiche les exigences de mot de passe sur la page Join Team