> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-vortex-format.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Demo days - 2026-09-04
> ClickStack demo days du 2026-09-04
Nouveaux types de filtres de dashboard
*Démonstration par [@pulpdrew](https://github.com/pulpdrew)*
VIDEO
Jusqu'ici, les filtres de dashboard ne proposaient qu'un seul type de valeur : les valeurs issues d'une query, dont les options de la liste déroulante proviennent d'une colonne dans ClickHouse. Ouvrez la fenêtre modale des filtres et variables : vous disposez désormais de deux types supplémentaires.
Les valeurs statiques vous permettent de saisir vous-même les options au moment de créer le filtre : un filtre d'environnement peut ainsi proposer simplement `dev`, `staging` et `prod`, sans aucune query sous-jacente. Un filtre de liste statique n'a pas d'`expression` : il ne prend donc en charge que le mode variable et ne peut pas être converti en condition SQL pour le mode broadcast.
Les valeurs de labels PromQL, elles, récupèrent les options depuis l'endpoint `/values` d'une source PromQL. Vous choisissez le label souhaité et pouvez, si vous le voulez, le restreindre à l'aide d'un matcher, qui peut lui-même référencer d'autres variables. Les filtres deviennent ainsi interdépendants : sélectionnez un environnement et les instances proposées par le filtre suivant se limitent en conséquence, les charts PromQL se filtrant au fur et à mesure.
Ces deux types peuvent être exposés en tant que variables, ce qui signifie qu'un filtre ne se limite pas à alimenter une `WHERE` clause. Dans la démonstration, un filtre statique listant `ServiceName` et `SeverityText` sert de dimension de group-by pour un chart : choisir une valeur dans la liste déroulante modifie donc le regroupement du chart, dans n'importe quelle combinaison.
**PR associées :** [#3017](https://github.com/hyperdxio/hyperdx/pull/3017) ajout des filtres de liste de valeurs statiques aux schemas et aux API, [#3022](https://github.com/hyperdxio/hyperdx/pull/3022) rendu des champs de saisie des filtres de liste de valeurs statiques, [#3020](https://github.com/hyperdxio/hyperdx/pull/3020) autorisation de la création et de l'édition de filtres de liste statiques dans l'UI, [#3060](https://github.com/hyperdxio/hyperdx/pull/3060) prise en charge des filtres à valeurs custom statiques dans MCP, [#3053](https://github.com/hyperdxio/hyperdx/pull/3053) prise en charge des filtres de dashboard basés sur les valeurs de labels Prometheus, [#3072](https://github.com/hyperdxio/hyperdx/pull/3072) prise en charge de l'autocomplete pour les filtres de labels PromQL, [#3039](https://github.com/hyperdxio/hyperdx/pull/3039) prise en charge de bounds temporelles optionnelles sur l'endpoint des valeurs de labels Prometheus, [#3079](https://github.com/hyperdxio/hyperdx/pull/3079) prise en charge de match\[] sur les endpoints des labels et valeurs PromQL, [#3080](https://github.com/hyperdxio/hyperdx/pull/3080) prise en charge de match\[] dans les filtres de labels PromQL, [#3083](https://github.com/hyperdxio/hyperdx/pull/3083) déduplication des labels et valeurs PromQL pour éviter un crash de Mantine, [#3005](https://github.com/hyperdxio/hyperdx/pull/3005) confirmation avant l'abandon des changes non enregistrés à la fermeture de l'éditeur de filtres, [#3078](https://github.com/hyperdxio/hyperdx/pull/3078) prise en charge de la configuration des filtres de dashboard comme obligatoires, [#3093](https://github.com/hyperdxio/hyperdx/pull/3093) application optionnelle des filtres de dashboard à l'aperçu de l'éditeur de tile
Templates de légende personnalisés pour les charts PromQL
*Démonstration par [@pulpdrew](https://github.com/pulpdrew)*
VIDEO
Comme Vladimir l'a fait remarquer, les légendes PromQL étaient difficiles à lire. Par défaut, nous affichons le metric name suivi de chaque label qui diffère d'une series retournée à l'autre, ce qui, pour une query renvoyant de nombreuses series, donne une longue chaîne dans laquelle il faut cliquer pour y voir clair.
Les display settings du chart acceptent désormais un template de légende. Il s'agit d'un template Handlebars : vous référencez donc uniquement les labels qui vous intéressent et obtenez un nom de series concis, aussi bien dans la légende que dans le tooltip.
Si le template référence un label absent, cette référence s'affiche vide. Si le résultat est vide ou n'est pas unique parmi les series, nous basculons vers l'ensemble complet des labels distinctifs : impossible, donc, de se retrouver avec deux series indiscernables.
**PR associées :** [#3055](https://github.com/hyperdxio/hyperdx/pull/3055) prise en charge d'un template personnalisé pour les légendes de series PromQL
Enregistrer une plage de dates relative comme valeur par défaut d'un dashboard
*Démonstration par [@knudtty](https://github.com/knudtty)*
VIDEO
Les dashboards peuvent désormais enregistrer une plage de dates relative comme valeur par défaut. Définissez l'intervalle de temps souhaité, cliquez sur « Save Query and Filters as default », et le dashboard s'ouvrira désormais sur cette plage.
Tout l'intérêt tient aux plages relatives. Enregistrer « les 6 dernières heures » garantit que le dashboard est à jour à chaque ouverture, au lieu d'être figé sur une fenêtre fixe qui devient vite obsolète. Vous pouvez toujours modifier la plage depuis le dashboard, consulter les 7 derniers jours, quitter la page, puis revenir à la valeur par défaut enregistrée.
**PR associées :** [#3073](https://github.com/hyperdxio/hyperdx/pull/3073) les plages de dates relatives peuvent être enregistrées pour les dashboards
Alertes sans recherche enregistrée ni dashboard tile
*Démonstration par [@wrn14897](https://github.com/wrn14897)*
VIDEO
Auparavant, chaque alerte devait s'appuyer sur un élément existant : une recherche enregistrée pour les logs, ou un dashboard tile pour les metrics. Ce fonctionnement ne passe pas à l'échelle lorsqu'il faut migrer des milliers d'alertes Grafana.
Les alertes intégrées suppriment cette contrainte. Une action **Create alerte** est désormais disponible dans la barre d'actions du Chart Explorer : vous pouvez ainsi construire un chart sur des metrics ou des événements et y associer directement une alerte, sans rien enregistrer au préalable. Vous pouvez également créer une alerte intégrée depuis la page des alertes : c'est la voie à privilégier lorsque vous ne voulez justement pas rattacher l'alerte à une recherche enregistrée ou à un dashboard.
Une alerte intégrée conserve sa propre `chartConfig` dans le document de l'alerte, exactement dans la shape utilisée par un dashboard tile ; elle est donc évaluée par le même chemin de code que les alertes de tile, et non par un chemin parallèle. Cela couvre le builder et le Raw SQL pour les affichages `line`, `stacked_bar` et `number`. PromQL n'est pas encore pris en charge.
La même shape `source: 'inline'` est acceptée par l'external API v2 et par l'outil MCP `save_alert`, avec le dialect de configuration de tile v2 utilisé par les dashboards : les alertes peuvent donc être créées par programmation à grande échelle. Le routeur réutilise les converters de dashboard tile, ce qui évite que les deux surfaces divergent.
**PR associées :** [#3010](https://github.com/hyperdxio/hyperdx/pull/3010) prise en charge de la création d'alertes sans recherches enregistrées ni dashboard tiles (backend), [#3069](https://github.com/hyperdxio/hyperdx/pull/3069) UI pour créer et modifier des alertes de chart intégrées, [#3043](https://github.com/hyperdxio/hyperdx/pull/3043) prise en charge des alertes de chart dans l'external API v2 et MCP
*Démo par [@pulpdrew](https://github.com/pulpdrew)*
VIDEO
Les alertes peuvent désormais porter leur propre nom et leurs propres tags. Le formulaire d'alerte d'une dashboard tile ou d'une recherche enregistrée comporte un champ pour le nom et un champ pour les tags ; par défaut, une nouvelle alerte reprend le nom du chart ou de la recherche enregistrée et hérite des tags du dashboard ou de la recherche enregistrée auquel elle est rattachée.
Ce sont ces noms qui s'affichent sur la page des alertes, et ce sont eux qui servent à la recherche et au filtrage. Les alertes déjà présentes en base sans nom défini en dérivent malgré tout un à partir de la recherche enregistrée ou du dashboard qu'elles référencent.
Les tags renvoyés par l'endpoint `team/tags` incluent désormais les tags des documents d'alerte, en plus de ceux des dashboards et des recherches enregistrées. Sans cela, un tag utilisé uniquement par une alerte ne serait pas suggéré au moment de taguer la suivante.
Il s'agit d'une première étape vers la pagination de la page des alertes, tout en conservant la recherche et le filtrage par tag : cela suppose que le nom et les tags figurent sur le document d'alerte lui-même plutôt que de passer par un join avec les collections de dashboards et de recherches enregistrées. La pagination n'est pas encore terminée.
**PR associées :** [#3063](https://github.com/hyperdxio/hyperdx/pull/3063) persistance du displayName et des tags au niveau de l'alerte, [#3065](https://github.com/hyperdxio/hyperdx/pull/3065) prise en charge de l'écriture du displayName et des tags d'alerte, [#3067](https://github.com/hyperdxio/hyperdx/pull/3067) affichage et modification du displayName et des tags d'alerte dans l'UI, [#3092](https://github.com/hyperdxio/hyperdx/pull/3092) inclusion des tags d'alerte dans la réponse de l'API tags, [#3029](https://github.com/hyperdxio/hyperdx/pull/3029) backfill du nom et des tags d'alerte (ouverte)
Un prototype d'Explore
*Démonstration par [@elizabetdev](https://github.com/elizabetdev)*
VIDEO
**Il s'agit d'un travail exploratoire, sans engagement de livraison.**
Le prototype se présente sous la forme d'une page Explore unique qui remplacerait à la fois la page de recherche et le chart explorer. Il est à l'état de brouillon dans le dépôt HyperDX. Il pourrait remplacer ces pages, coexister avec elles comme troisième page, ou bien ne rien donner du tout.
Le problème visé est celui des allers-retours entre les deux pages actuelles. Les clients nous disent qu'emporter une question de la recherche vers le chart explorer est peu pratique : il faut souvent resélectionner la data source et reconstruire la même query de l'autre côté. Explore garde tout sur une seule page, en basculant la vue entre événements, patterns, deltas et charts au lieu de changer la page sous vos yeux.
Le deuxième axe consiste à abaisser la barrière pour les personnes qui ne maîtrisent pas les query languages. Ajouter une column à la table, trier ou choisir un group-by se font via des menus déroulants, le SQL restant disponible si vous le souhaitez. Le group-by illustre bien la limite actuelle : l'histogram de la page de recherche est groupé par code d'état sans possibilité de le modifier, si bien que toute personne souhaitant un autre regroupement doit passer par le chart explorer. Ici, vous définissez le group-by dans la vue événements, basculez vers une time series ou un chart à barres lorsque le petit histogram ne suffit plus, changez l'aggregation pour quelque chose comme `p99`, puis enregistrez le résultat dans un dashboard.
La barre de filter est un petit query builder qui masque à la fois Lucene et SQL : choisissez un field, un operator, saisissez une value, l'éditeur de query complet et les macros restant accessibles aux utilisateurs avancés. Savoir s'il est même pertinent d'avoir deux query languages fait partie des questions encore ouvertes.
Beaucoup de points restent en suspens. PromQL n'est pas encore pris en charge, et la question de savoir si les metrics ont leur place sur cette page — ou si cela en demanderait trop à une page unique — n'est pas tranchée. Le prototype se concentre sur l'expérience logs et traces.
Nous serions ravis de recevoir vos retours à ce sujet.
**PR associées :** [#2985](https://github.com/hyperdxio/hyperdx/pull/2985) Explore as search-first visualization (prototype) (ouverte)