Demo Days - 2026-07-31

Démo par @pulpdrew La prise en charge initiale des métriques d’histogrammes exponentiels OpenTelemetry est désormais disponible. Vous pouviez déjà enregistrer l’une de ces métriques sur une source, mais il n’était pas possible de l’interroger. Les décomptes et les quantiles sont désormais pris en charge dans le générateur de requêtes. Les histogrammes exponentiels sont similaires aux histogrammes à compartiments explicites, mais les limites de leurs compartiments sont calculées à partir de puissances de deux, au lieu d’être stockées pour chaque compartiment. L’échelle détermine la puissance de deux utilisée. Une échelle plus élevée produit des compartiments plus petits, tandis que le décalage déplace les limites vers des multiples plus élevés ou plus faibles. Le décompte de chaque compartiment indique le nombre d’observations qui se situent dans cette plage. Max, min, sum et avg restent non pris en charge, comme dans l’implémentation existante des histogrammes explicites. Ces champs sont facultatifs dans le modèle de données OpenTelemetry, nous ne présumons donc pas de leur présence. Comme le montre la démo, le SQL généré est long et peu élégant. Ses performances sont acceptables et il n’épuise pas la mémoire, mais il ne s’agit que d’une prise en charge fonctionnelle initiale. L’optimisation des performances est la prochaine étape, et un schéma mis à jour est déjà en cours de préparation, ce qui devrait accélérer considérablement ces requêtes. Pour l’instant, seul le type d’affichage des séries temporelles est correctement rendu. Cela est cohérent avec le type de métrique d’histogramme existant. PR associés : #2687 feat : Afficher les métriques d’histogrammes exponentiels dans la liste déroulante des noms de métriques, #2697 feat : Implémenter quantile+sum pour les métriques d’histogrammes exponentiels, #2705 feat : Prendre en charge les histogrammes exponentiels dans MCP, #2707 fix : Prendre en charge le regroupement des agrégations de quantiles d’histogramme sur des colonnes autres que des attributs Démo par @pulpdrew Les graphiques SQL bruts affichent désormais un avertissement lorsque des macros attendues sont manquantes. Cette modification fait suite à un cas de support où une personne créant un grand nombre de graphiques SQL bruts obtenait sans cesse des résultats déroutants. Les requêtes de dashboard doivent inclure les macros de filtres et de table source. Les graphiques de séries temporelles doivent également inclure les macros d’intervalle de temps et d’intervalle. Auparavant, ces vérifications n’étaient effectuées qu’après l’ajout d’une alerte à la tuile. Elles s’appliquent désormais à chaque graphique SQL brut : supprimer une macro affiche donc un avertissement dans l’éditeur au lieu de générer ultérieurement un graphique déroutant. La validation tient également compte des dépendances de chaque macro. Les macros de table source et de filtres nécessitent qu’une source soit sélectionnée, même si les graphiques SQL bruts n’en ont pas besoin par ailleurs. L’utilisation de l’une ou l’autre de ces macros sans sélectionner de source produit donc une erreur plutôt qu’un avertissement. Il s’agit d’une petite modification, mais elle devrait faciliter l’identification des problèmes liés au SQL brut sans devoir contacter le support. PR associées : #2742 feat: avertissement sur les paramètres/macros manquants dans SQL Editor Démo par @pulpdrew L’équipe LogHouse souhaitait disposer d’un moyen plus stable de créer des liens vers les sources. Elle gère l’environnement de logging de ClickHouse Cloud et provisionne les sources par programmation à l’aide d’une infrastructure as code. Les ID des sources changent lorsqu’une source est recréée et diffèrent selon les environnements de développement, de staging et de production, ce qui rend fragile tout lien reposant sur un ID. Comme elle crée des liens vers ClickStack depuis des systèmes d’alerting et Grafana, maintenir un ensemble distinct d’ID de sources pour chaque environnement n’était pas pratique. Le paramètre d’URL source accepte désormais un nom de source en plus d’un ID. Les noms sont définis lors du provisionnement des sources, ce qui permet au même lien de fonctionner dans tous les environnements. Cette prise en charge a d’abord été ajoutée à la page de recherche. Une PR ultérieure l’étend à toutes les pages comportant un paramètre de source, notamment l’explorateur de graphiques, la carte des services, les sessions, le dashboard des services et le dashboard Kubernetes. La plupart des discussions qui ont suivi ont porté sur la facilité de découverte. Il s’agit en pratique d’une API d’URL, et il est peu probable que les utilisateurs la découvrent par hasard. Une option consisterait à utiliser les noms plutôt que les ID par défaut, mais les collisions de noms rendent cette approche risquée. Parmi les autres suggestions figuraient l’exposition de liens via un bouton de partage, leur génération par les agents via MCP et une documentation adéquate de l’API d’URL. Les intervalles de temps relatifs bénéficieraient de la même documentation. Les références fondées sur les noms pourraient également être étendues aux dashboards. Un workflow d’infrastructure as code pourrait alors provisionner les sources, importer les dashboards et tout connecter automatiquement. Les importations de dashboards via l’UI font déjà correspondre les sources par nom ; l’écart restant concerne donc principalement les workflows programmatiques. PR associées : #2746 feat: Accepter les noms de sources en plus des ID dans les paramètres d’URL, #2758 feat: Prendre en charge les liens profonds par nom de source sur des pages supplémentaires Démo par @elizabetdev Des travaux sont en cours pour déterminer où placer les paramètres d’affichage des graphiques. La modification initiale les a intégrés à droite de l’éditeur de tuile, au lieu de les ouvrir dans un panneau latéral distinct. Auparavant, l’éditeur de tuile était une fenêtre modale et Display Settings s’ouvrait dans un panneau latéral par-dessus. Une seule pression sur Échap fermait les deux, et un panneau latéral superposé à une fenêtre modale n’a jamais semblé approprié. La PR s’est compliquée lorsqu’il a également fallu empiler les paramètres des séries par-dessus. Nous avons donc pris du recul et commencé à examiner la page dans son ensemble. Le travail en est encore à l’étape de la maquette filaire. La conception actuelle place les paramètres dans un panneau ancré et applique automatiquement les modifications, ce qui permet d’en voir le résultat en temps réel sans appuyer sur le bouton Apply. L’objectif est d’achever la refonte avant de la réintégrer dans la PR existante. L’implémentation actuelle est considérée comme un prototype, notamment parce que la nouvelle conception modifie également certaines parties de la page du dashboard. PR associées : #2721 feat(dashboards): déplacer l’éditeur de tuile vers un panneau latéral avec panneau de paramètres ancré Démo par @elizabetdev Il s’agit d’une première exploration d’une page Explore unifiée qui pourrait à terme remplacer Search, les recherches enregistrées et Chart Explorer par un point d’entrée unique. Le déploiement s’appuie sur les enseignements tirés de la refonte de la visionneuse de traces. Plutôt que de modifier l’expérience de tous les utilisateurs d’un coup, la nouvelle page serait proposée derrière un indicateur de fonctionnalité à un petit groupe d’utilisateurs. Cette période permettrait d’identifier et de corriger les problèmes avant un déploiement plus large. Si l’idée ne fonctionne pas, elle restera une expérimentation et ne sera pas livrée. Ce serait un résultat tout à fait acceptable. La page commence par le choix d’un type de signal. Le choix des traces, des logs ou des métriques adapte le reste de l’expérience en conséquence. Sélectionner les logs, par exemple, donne accès à la vue en liste, aux modèles d’événements, aux séries temporelles et aux autres visualisations actuellement disponibles dans Chart Explorer. Une investigation devrait pouvoir se poursuivre sans changer de page. Vous pouvez commencer par une liste, passer à un nombre ou à une table regroupée, ajouter le résultat à un dashboard, puis écrire une requête personnalisée si vous avez besoin de davantage de contrôle. Plusieurs idées plus modestes sont également incluses, la plupart inspirées par les retours des utilisateurs. L’éditeur de requêtes fonctionnerait davantage comme l’éditeur SQL, ce qui supprimerait les différences actuelles de comportement de saisie semi-automatique. Les erreurs et les avertissements apparaîtraient pendant la modification, au lieu d’attendre l’exécution de la requête. Les colonnes disposeraient d’un sélecteur dédié. Au moins un utilisateur n’avait pas réalisé que modifier la clause SELECT déterminait les colonnes affichées dans la table. Avec le sélecteur, cliquer sur un champ met à jour le SQL et permet de trier selon ce champ. La clause SELECT reste disponible pour les utilisateurs avancés. Les vues enregistrées seraient également présentes sur la page, ce qui permettrait d’explorer sans enregistrer, puis d’enregistrer la vue actuelle directement sur place. Le SQL généré serait affiché intégré. De nombreux éléments manquent encore, notamment certaines des visualisations actuellement disponibles dans Chart Explorer. La conception continuera d’évoluer à mesure que ces éléments seront ajoutés. PR associés : aucun pour l’instant, il s’agit d’une exploration plutôt que d’une fonctionnalité livrée Démo par @teeohhem La liaison des filtres de dashboard a été fusionnée. Nous l’avons d’abord présentée sous forme d’ébauche il y a plusieurs mois, puis mise en pause afin d’en évaluer les implications en matière de performances. La liaison modifie la structure des requêtes de dashboard et ne tire pas toujours le meilleur parti des vues matérialisées. Elle sera donc proposée sous forme de bouton bascule facultatif plutôt que d’être activée par défaut. Lorsque la liaison est activée, le choix d’une valeur dans un filtre restreint les valeurs disponibles dans les autres. La sélection d’un service ne conserve que les valeurs de gravité associées à ce service. La sélection d’un ID de trace ne conserve que les ID de trace parents associés. Cela empêche les utilisateurs de choisir des combinaisons qui ne renvoient aucune donnée. Une PR de suivi rend la liaison sensible à la source. Les filtres sont regroupés par source, avec des icônes de chaîne entre les filtres voisins susceptibles de se restreindre mutuellement. Sur un dashboard comportant deux filtres de journaux et deux filtres de traces, les filtres qui interagissent devraient être clairement identifiables. Le cas d’utilisation initial concernait le dashboard Kubernetes. La sélection d’un pod ne devrait conserver que les déploiements et les nœuds contenant ce pod. Les valeurs restreintes sont récupérées de manière différée à l’ouverture d’une liste déroulante, ce qui limite le coût des recherches supplémentaires. La discussion a laissé deux questions ouvertes. Le paramètre est actuellement stocké par utilisateur dans le stockage du navigateur. Il ressortait de l’appel que les utilisateurs souhaiteront à terme l’enregistrer au niveau du dashboard. Dans ce cas, il pourrait être préférable de ne conserver la préférence au niveau utilisateur que temporairement, plutôt que de la mettre ultérieurement en concurrence avec le comportement au niveau du dashboard. L’autre question concerne le comportement des filtres dépendants pendant le chargement de leurs valeurs. La sélection d’une valeur affiche actuellement un état de chargement dans la liste déroulante dépendante au lieu de la bloquer, bien que le comportement avec un second filtre dépendant doive encore être vérifié. La préférence était de maintenir les filtres utilisables pendant que le filtrage s’affine et d’indiquer que la liste n’a pas fini de se mettre à jour. Une personne qui connaît déjà la valeur qu’elle souhaite ne devrait pas avoir à attendre les métadonnées. PR associées : #2423 feat(dashboards) : valeurs de filtre en cascade (à facettes), #2760 feat(dashboards) : conserver le bouton bascule de liaison des filtres et clarifier la liaison au sein d’une source Démo par @MikeShi42 La plus petite PR de la semaine est aussi un bon exemple d’un désagrément qui mérite d’être corrigé. Le panneau latéral d’une ligne s’ouvrait toujours sur l’onglet Overview, conçu autour des champs de logs OpenTelemetry. Pour les logs qui ne sont pas au format OTel, cet onglet affiche très peu d’informations utiles. Il fallait donc basculer vers Column Values chaque fois que vous ouvriez une ligne. Le panneau mémorise désormais le dernier onglet utilisé et le rouvre la prochaine fois. Il n’y a rien à configurer. Les utilisateurs non-OTel qui basculent vers Column Values y resteront, tandis que ceux qui utilisent Overview conservent le comportement existant. PR associées : #2752 feat(app): mémoriser le dernier onglet du panneau latéral utilisé entre les ouvertures