Variables de dashboard dans PromQL et Lucene
Démo par @pulpdrew
Les variables de dashboard fonctionnent désormais dans les charts PromQL, avec autocomplete des références de variables et avertissements en cas de variables manquantes ou d’usage non pris en charge, comme les macros ou les références nécessitant des guillemets. Un aperçu PromQL généré s’affiche à côté du panneau generated SQL existant : il montre la requête avec vos sélections actuelles déjà substituées.
Les variables Lucene prennent désormais en charge les exact matches. Auparavant,
ServiceName:$service était étendu en ServiceName:("add" OR "cart"). Une correspondance de field Lucene sans guillemets étant une correspondance de substring, cela donnait ServiceName ILIKE '%add%' OR ServiceName ILIKE '%cart%'. Vous pouviez donc sélectionner deux services et en obtenir quatre.
En plaçant la variable entre guillemets, ServiceName:"$service" est désormais étendu en (ServiceName:"add" OR ServiceName:"cart"), ce qui fait correspondre exactement chaque valeur sélectionnée. Ce comportement est identique à celui déjà en place pour les correspondances de field entre guillemets sans variables. L’autocomplete suggère également la forme entre guillemets.
Le drill-down depuis un tooltip de chart ou une ligne de table vers la page Search étend désormais les variables et les macros avant la navigation. La page Search ne comprend pas les variables : transmettre un $service brut donnait auparavant des résultats incorrects ou une erreur de requête. Les macros sans sélection sont étendues en (1=1) : le rendu est un peu inélégant dans le champ WHERE de la page Search, mais la requête reste valide.
Les sélections de filters sont maintenant indexées par nom de variable plutôt que par expression. Deux filters utilisant la même expression, comme ServiceName provenant de sources différentes, ne partagent plus la même sélection.
Appuyer sur Escape pendant l’édition d’un filter demande désormais confirmation avant d’abandonner les modifications, comme Brandon l’avait suggéré. Auparavant, fermer un tooltip pouvait faire perdre toute l’édition en cours.
Les variables de dashboard sont passées en production cette semaine. Le feature toggle a disparu, et la documentation publique couvre les formes de référence et les macros.
PR associées : #2994 substitution des variables dans les charts PromQL, #2995 ajout des completions pour les variables PromQL, #2997 affichage d’avertissements en cas d’usage invalide des variables PromQL, #2998 ajout de l’aperçu PromQL généré, #2987 distribution des références de variables Lucene en exact match, #3008 extension des variables avant la navigation vers la page Search via drill-down, #2963 prise en charge des valeurs de filter de dashboard indexées par variable, #2964 persistance et lecture du state des filters indexés par variable, #3005 confirmation avant d’abandonner les modifications non enregistrées à la fermeture de l’éditeur de filter, #3009 suppression du feature toggle des variables de dashboard
Liens de spans, dans les deux sens
Démo par @karl-power
Les liens de spans sont consultables depuis un certain temps, mais uniquement du côté consumer. Chaque lien apparaissait sous la forme d’une action « Open trace », sans possibilité de partir d’un span producteur pour retrouver les spans qui pointent vers lui. Un utilisateur en avait fait la demande dans une issue GitHub.
La section Span Links affiche désormais le nom, le service, la durée et le timestamp de chaque span cible. Il est ainsi plus simple de choisir parmi plusieurs liens sans avoir à les ouvrir un par un. « Open trace » reste le fallback lorsque le span cible est introuvable.
Une nouvelle section « Linked from » répertorie les spans qui pointent vers le span courant. Vous pouvez donc suivre le lien d’un consumer vers son producteur et y retrouver le consumer listé.
Suivre un lien vers le span précédent dans le fil d’Ariane vous ramène à cette entrée : passer d’un span lié à l’autre n’ajoute donc pas sans cesse de doublons. S’il existe d’autres entrées entre les deux, la navigation ajoute une nouvelle entrée comme d’habitude.
Le lookup inverse recherche les rows dont les liens de spans contiennent l’ID du span sélectionné, puis vérifie la correspondance du trace ID. Les lookups par trace ID bénéficient de l’index bloom filter sur cette colonne, mais le lookup inverse nécessite un parcours et peut s’avérer plus lent sur des tables de traces volumineuses que dans la démonstration. Si cela pose problème, nous pourrons ajouter un index sur l’ID du span lié, comme le suggèrent les commentaires du code.
PR associées : #3011 ajout des liens de spans inverses, affichage du détail des liens de spans
L’observability des LLM prête à l’emploi
Démonstration par @wrn14897
De nombreuses équipes envoient déjà la telemetry de leurs LLM et de leurs agents de code vers ClickStack, mais aucune prise en charge spécifique n’existait : ni rendu des conversations, ni suivi des tokens ou des coûts, ni analytics des modèles.
Un dashboard LLM vient désormais compléter les préréglages existants pour ClickHouse, Kubernetes et les services. Il couvre la consommation de tokens, le coût, les appels de modèles, les appels d’outils, les cache hits et les temps de réponse, avec une ventilation par utilisateur lorsqu’un attribute utilisateur est présent.
Il exploite vos traces et logs existants au moment de la requête, sans imposer de schema fixe, de tables dédiées ni de processing à l’ingestion. La telemetry reposant sur les conventions courantes, OpenLLMetry ou OpenInference est prise en charge, y compris les données issues des SDK OpenAI et Anthropic, du SDK Vercel AI, de LangChain, de Claude Code et d’opencode. Cela vaut aussi pour la telemetry que vous avez déjà collectée.
Une vue de latency fait remonter en tête les spans liés à l’IA, ce qui facilite l’identification d’un appel de modèle lent sans avoir à parcourir le reste de la trace.
La vue des sessions regroupe les spans par conversation. Ouvrez une session pour consulter ses spans, puis sélectionnez-en un pour en afficher le détail, y compris le prompt s’il a été enregistré. C’est utile pour le debugging d’une exécution d’agent, et vous pouvez rechercher dans les logs avec le même filter de session.
La portée est volontairement plus restreinte que celle d’un outil d’observability dédié aux LLM tel que Langfuse, qui prend également en charge les évaluations et bien plus encore. Elle répond aux besoins courants de monitoring — taux d’error, coût, tokens et latency — à partir de la telemetry déjà présente dans ClickStack.
PR associées : #2990 dashboard d’observability des LLM, vue de conversation des spans et sessions
Explorer les metrics dans l’éditeur de chart
Démo par @MikeShi42
Choisir une metric supposait de parcourir une liste plate pouvant compter jusqu’à 3 000 noms par kind. L’autocomplete est utile lorsque vous savez déjà à peu près ce que vous cherchez, mais le besoin de pouvoir naviguer est revenu à plusieurs reprises dans les retours.
Un contrôle « Browse metrics », placé à côté du sélecteur de metric, ouvre désormais un explorateur : le catalog à gauche, les détails de la metric sélectionnée à droite. Les noms de metric sont découpés au niveau des dots et des underscores pour former une arborescence. Les segments n’ayant qu’un seul child sont regroupés afin d’éviter des clics inutiles. Les columns
Metric, Type et Unit restent alignées à tous les niveaux. Vous pouvez effectuer une recherche dans l’ensemble du catalog ou basculer vers une liste plate.
Auparavant, l’unité, la description et les tags n’étaient accessibles qu’après avoir sélectionné une metric, dans un panneau replié sous la ligne de series. Le volet de détails vous permet de les consulter avant de choisir, afin de voir ce que votre déploiement émet et selon quels tags vous pouvez grouper. Cliquez sur « Use metric » pour appliquer votre choix à la series en cours d’édition.
Le contrôle reste discret pour l’instant, le temps que la fonctionnalité se stabilise.
PR associées : #3000 ajout d’un metrics explorer à l’éditeur de chart, #3025 diffusion en stream des noms de metric depuis le primary index (ouverte), #3054 améliorations UX du dropdown des metrics
Volume de logs pour les requêtes SQL brutes dans Grafana
Demo par @SpencerTorres
Un petit changement visuel qui a demandé plus de travail que prévu.
Dans Grafana, les requêtes de logs construites dans le requête builder affichent un histogramme de volume au-dessus des résultats, car le plugin sait quelles columns utiliser. La même requête dans le SQL Editor, elle, n’affichait aucun histogramme : le plugin était incapable de déterminer quelles columns vous aviez sélectionnées. Dans Explore, vous obteniez à la place l’histogramme par rows de Grafana, plafonné par le
LIMIT de la requête et sans tenir compte de l’intervalle de temps sélectionné.
Le plugin supprime désormais les clauses ORDER BY et LIMIT finales, encapsule votre SQL sous forme de table dérivée et agrège sur l’ensemble de l’intervalle de temps. La suppression du LIMIT est déterminante ici : le conserver limiterait le comptage aux rows renvoyées par la requête d’origine.
L’histogramme reflète vos filters SQL et se met à jour lorsque vous modifiez l’intervalle de temps. Cela vaut aussi bien pour le SQL que vous écrivez vous-même que pour les requêtes ouvertes via « Edit as SQL » dans le requête builder.
Il subsiste probablement des cas limites où le requête rewrite ne fonctionnera pas.
PR associées : grafana/clickhouse-datasource#2141 affichage du volume de logs pour les requêtes du SQL Editor (ouverte)
Notification channels sur les pages d’alertes
Démonstration par @jordan-simonovski
Une alerte peut notifier jusqu’à dix webhooks, mais la liste des alertes et l’en-tête de détail n’affichaient que le premier, étiqueté « Webhook » au lieu de son nom. Tous deux lisaient encore le champ legacy à canal unique.
L’envoi vers plusieurs cibles fonctionnait, mais l’affichage laissait croire que les canaux supplémentaires n’avaient pas été enregistrés.
La liste et l’en-tête de détail affichent désormais chaque canal configuré par son nom. L’ajout et la suppression de canaux sont également facilités, y compris pour les webhooks et les integrations incident.io. Le temps de notification est enregistré par cible, ce qui permet de repérer une integration lente.
Les canaux configurés sont désormais notifiés directement. Auparavant, ils étaient convertis en mentions de webhook, puis ajoutés au message body. Des notifications pouvaient ainsi être perdues : si le body contenait déjà assez de mentions ponctuelles pour atteindre le cap par événement, les canaux configurés de l’alerte étaient ignorés.
Avec ces contrôles supplémentaires, la page devenait chargée. Les actions de row, dont l’export et Terraform, sont désormais regroupées dans un menu unique.
PR associées : #3001 afficher chaque cible de notification sur les pages d’alertes, #2991 afficher chaque notification channel sur la ligne de résumé, #2984 notifier directement les canaux configurés, sans passer par des chaînes de mention, #2961 empêcher les mentions en échec de consommer des slots de notification, #3003 attribuer le temps de notification d’alerte à chaque cible, #3002 doter chaque row des pages d’alertes des mêmes contrôles de fin de ligne, #3016 regrouper l’en-tête de détail d’alerte dans le menu de row partagé
Affichage de dizaines de milliers d’alertes
Démo par @pulpdrew
L’évaluation des alertes a été testée avec 16 000 alertes simultanées et tient parfaitement la charge. En revanche, l’ouverture de la page des alertes avec un tel volume la faisait tomber.
La liste est désormais virtualisée et peut afficher 16 000 alertes. Le chargement reste lent, car toutes les alertes sont récupérées et filtrées côté client. Une pagination est en cours de développement pour y remédier.
La modification inclut également un script permettant de générer (seed) puis de supprimer un grand nombre d’alertes dans MongoDB, ce qui facilite les tests de la page à cette échelle en local.
PR associées : #3012 virtualisation de la liste de la page des alertes
Masquage des API keys derrière un affichage à la demande
Demo par @brandon-pereira
Les credentials s’affichaient en clair un peu partout dans l’application. La page Team Settings montrait l’API key d’ingestion complète, et les extraits d’installation MCP intégraient la clé d’accès personnelle directement dans la commande. Dans les deux cas, le risque d’exposition lors d’un partage d’écran ou d’une capture d’écran était réel.
Les clés sont désormais masquées par défaut, avec un contrôle permettant de les afficher au besoin. Un composant partagé assure ce comportement pour la clé d’ingestion, la clé d’accès personnelle et les extraits d’installation MCP, y compris ceux proposés par la communauté.
La copie récupère toujours la valeur réelle : vous n’avez donc pas besoin d’afficher une clé pour la copier. Le même changement arrivera prochainement dans l’onboarding de ClickStack Cloud.
PR associées : #2988 masquage des secrets dans les extraits d’API key et d’installation MCP grâce à un composant partagé RevealSnippet
Notes de version dans le produit
Démo par @jordan-simonovski
Le panneau « Nouveautés » du menu Aide s’appuyait sur les jeux de modifications de chaque PR, en retenant les entrées portant le préfixe
feat:. Résultat : la version v2.36.0 mentionnait trois fois les variables de dashboard, mais omettait les formules et le travail sur les alertes, qui constituaient pourtant les principaux changements de cette version.
Il lit désormais le fichier CHANGELOG.md racine, rédigé et relu dans le cadre de la PR de release. Le générateur de release fournit également le titre principal de chaque version affiché dans le panneau. En dessous figurent les changements incompatibles, les nouvelles fonctionnalités, les corrections de bogues et les améliorations, avec des liens vers le changelog.
Le bouton Aide scintille désormais lorsque des notes de version n’ont pas encore été lues, grâce à un SVG animé sans JavaScript.
Le suivi des éléments non lus demandait lui aussi une correction. Il reposait sur la version de build de l’application : les déploiements incluant un SHA court git ou un numéro de build d’intégration continue déclenchaient donc le scintillement à chaque déploiement, même en l’absence de nouvelle version. Il s’appuie à présent sur la dernière version publiée figurant dans le changelog.
Le format des notes de version évolue également : attendez-vous donc à voir davantage de ce contenu apparaître dans le panneau.
PR associées : #2993 construire « Nouveautés » à partir des notes de version générées, #3042 indexer le scintillement des Nouveautés sur la version publiée, et non sur le build, #3007 émettre un avertissement distinct en cas d’échec d’une requête de marqueur de version