Skip to main content

​
La détection d’anomalies pour les alertes se poursuit avec les graphiques à barres

Démo par @fleon
Cela reste très expérimental. Les bandes de distribution normale utilisées pour mettre en évidence les anomalies fonctionnent bien sur les graphiques linéaires, mais sont bien plus difficiles à représenter sur les graphiques à barres. Himanshu a essayé des bandes d’erreur et même des graphiques à barres creuses pour rendre ces bandes plus visibles, mais le résultat reste chargé. Superposer une bande sous la forme d’une ligne sur une barre pleine pose le même problème : la barre domine visuellement et rend la bande difficile à distinguer. Pour l’instant, nous orienterons probablement les utilisateurs vers le graphique linéaire lorsqu’ils souhaitent examiner les bandes d’anomalie, puis reviendrons ultérieurement sur la conception du graphique à barres. Himanshu recherche des retours sur la meilleure approche avant la sortie de cette fonctionnalité.

​
Actions onclick externes pour les tables

Démo par @pulpdrew
Drew a présenté un ajout modeste mais utile aux tables de dashboard : la possibilité de lier directement des lignes à des outils externes. Les lignes de table permettent déjà d’explorer les données dans Search ou dans un autre dashboard. Cette nouveauté introduit une troisième option, « External », qui génère une URL à partir des valeurs de la ligne sélectionnée avant de l’ouvrir. Dans la démo, cliquer sur une ligne d’un catalogue de produits insérait le nom du produit dans une URL de recherche Google afin d’illustrer le concept, mais ce même mécanisme permet tout aussi bien de créer des liens vers Grafana, des runbooks internes, des systèmes de tickets ou tout autre outil acceptant des paramètres dans une URL. C’est une fonctionnalité simple, mais importante. Au lieu de considérer ClickStack comme une destination, elle en fait un élément du workflow global d’observabilité, ce qui permet de passer facilement d’un dashboard aux outils nécessaires pour poursuivre une investigation. PR associés : #2523 feat : prise en charge des liens externes via le comportement onclick des tables de dashboard

​
Profilage OTel

Démo par @SpencerTorres
Le profilage commence à faire son entrée dans ClickStack, même s’il en est clairement encore à ses débuts. Spencer a présenté un premier prototype qui ingère des échantillons de profilage OpenTelemetry, les mêmes données utilisées pour générer des graphiques en flammes et exploitées par des outils tels que pprof. À l’aide d’un dashboard Grafana alimenté par ClickHouse, il a visualisé un petit programme triant continuellement des données et examiné des blocs individuels de piles d’appels à mesure que de nouveaux échantillons de profilage arrivaient. L’implémentation reste assez rudimentaire, ce que reflète la requête. Chaque ligne combine des éléments de logs et de traces, en stockant de longs tableaux de noms de fonctions et d’adresses représentant un span ou un secteur d’un graphique en flammes. La reconstruction du format attendu par Grafana nécessite des jointures et des agrégations sur ces tableaux, tandis que l’exporter doit dérouler les frames de profilage brutes avant de les écrire dans ClickHouse. Le schéma s’appuie toujours sur des filtres de Bloom, auxquels s’ajoute désormais la recherche en texte intégral, ce qui a suscité une discussion sur la compatibilité. Puisque ClickHouse Cloud prend déjà en charge la recherche en texte intégral, l’équipe a débattu de la durée pendant laquelle la voie open source sans cette fonctionnalité devra encore être maintenue. Le travail fait actuellement l’objet d’une révision dans une PR ouverte. L’objectif est d’intégrer d’abord la fonctionnalité principale dans l’open source, avant de l’intégrer à ClickStack.

​
Saisie semi-automatique pour les sources de métriques OTel

Démo par @brandon-pereira
Brandon a présenté une petite amélioration pour simplifier l’onboarding des métriques. Lors de la création d’une source OpenTelemetry Metrics, les champs des tables de métriques sont désormais automatiquement renseignés à partir des noms de tables de la base de données sélectionnée, au lieu de devoir être sélectionnés manuellement un par un. Les métriques bénéficient ainsi de la même expérience d’onboarding que les logs et les traces. PR associés : #2524 feat(app) : remplissage automatique des listes déroulantes de tables de métriques dans le formulaire Create Source

​
Cadre d’évaluation des dashboards

Démo par @brandon-pereira
Les dashboards générés par l’IA s’améliorent, mais les évaluer à l’œil nu a ses limites. Brandon développe un cadre d’évaluation permettant de déterminer si la génération de dashboards progresse réellement et, tout aussi important, où elle présente encore des lacunes. L’évaluation demande au modèle de générer un dashboard qui met délibérément à l’épreuve un maximum de fonctionnalités, notamment des sections réductibles, des onglets, des heatmaps, des diagrammes circulaires, du SQL brut en parallèle de tiles adossées à des sources, des filtres au niveau du service et des liens de drill-down entre dashboards. Une phase de validation vérifie ensuite que tout s’est affiché et a fonctionné comme prévu. Elle a déjà permis de mettre au jour de vrais problèmes, notamment des tiles Markdown qui s’affichent systématiquement trop courtes. Elle suit également les liens de drill-down activés par la nouvelle fonctionnalité onclick de Drew afin de vérifier que la navigation vers un second dashboard généré par l’IA fonctionne correctement. À mesure que de nouvelles capacités de dashboard sont ajoutées, elles seront intégrées à l’évaluation afin que les régressions soient détectées automatiquement, sans dépendre de tests manuels. Brandon espère bientôt ouvrir une PR contenant ce cadre. PR associées : #2571 feat(hdx-eval) : ajout d’un scénario d’évaluation de création de dashboard (en cours)

​
Connexion à Prometheus

Démo par @knudtty
Aaron a présenté une première passerelle entre ClickStack et Prometheus. Une nouvelle option « Compatible avec Prometheus », dans les paramètres avancés d’une source, indique à ClickStack de traiter l’hôte configuré comme un endpoint d’API Prometheus — Thanos dans la démo — plutôt que comme une instance ClickHouse. Une fois activée, les tiles de dashboard peuvent exécuter des requêtes PromQL directement sur cet endpoint. Aaron l’a démontré avec un graphique regroupant l’utilisation du CPU sur les pods, la requête étant envoyée directement à Prometheus plutôt que traduite via ClickHouse. La démo était assez succincte, mais elle a suscité une discussion plus large sur l’expérience utilisateur. À plus long terme, l’objectif est d’assurer une prise en charge native de Prometheus dans ClickStack. Cette fonctionnalité constitue une première étape pratique, permettant aux équipes qui dépendent déjà de Prometheus de continuer à l’utiliser tout en adoptant ClickStack, plutôt que de tout faire transiter par ClickHouse dès le départ. En parallèle, nous continuons à travailler sur la prise en charge native de PromQL dans ClickHouse. PR associés : #2518 feat : ajout de la possibilité de se connecter à un datastore Prometheus externe
Dernière modification le 14 août 2026