Filtres de dashboard obligatoires
Démonstration par @pulpdrew
Les filtres de dashboard peuvent désormais être marqués comme obligatoires : les tiles ne se chargent alors qu’une fois qu’une valeur a été sélectionnée. Auparavant, tous les filtres étaient facultatifs, et l’ouverture d’un dashboard reposant sur une source volumineuse exécutait l’ensemble de ses tiles sans aucun filtre, avant même que vous n’ayez restreint quoi que ce soit.
La définition d’un filtre comporte un nouveau toggle obligatoire. Utilisé seul, il bloque les tiles qui utilisent réellement le filtre : celles qui le référencent en tant que variable et celles qui en reçoivent une valeur par broadcast. Dans la démo, un filtre sur le service name diffusé par broadcast vers les sources logs et traces bloquait toutes les tiles du dashboard, tandis qu’un filtre de sévérité n’existant que dans la table des logs bloquait les tiles de logs et laissait les tiles de traces se charger comme auparavant.
Une seconde option étend l’exigence à toutes les tiles du dashboard, qu’elles utilisent ou non le filtre comme variable ou qu’elles en reçoivent une valeur par broadcast. En interne, chaque type de filtre a gagné deux fields :
minSelections, où la valeur 1 signifie « obligatoire », et isGlobalRequirement pour la version applicable à l’ensemble du dashboard. minSelections est un nombre plutôt qu’un booléen, afin de laisser la porte ouverte à un plafond maxSelections correspondant et à des minimums supérieurs à 1.
Les filtres dépendants ne sont pas encore bloqués par les filtres obligatoires dont ils dépendent : un filtre dont la requête d’options référence une variable obligatoire interroge donc encore ses options avant que cette variable n’ait une valeur.
Les sélections de filtres et de variables du dashboard s’appliquent désormais aussi à l’aperçu du chart dans l’éditeur de tile, comme Brandon l’a suggéré en relisant la PR sur les filtres obligatoires. Jusqu’ici, les variables et les filtres principaux étaient propagés dans l’aperçu, mais pas les filtres broadcast, ce qui constituait une incohérence ; et avec les filtres obligatoires, un argument de performance plaide pour éditer une tile avec les mêmes filtres que ceux appliqués par le dashboard. Le toggle Apply filters est activé par défaut et vous pouvez le désactiver pour voir la tile dans les deux configurations.
Le toggle est forcé à l’état désactivé lorsqu’une alert est configurée sur la tile, car les alerts sont évaluées sans qu’aucun filtre ne soit appliqué. L’aperçu correspond ainsi à ce que l’alert interrogera réellement.
Lorsqu’un filtre obligatoire bloque l’aperçu, le message affiché dans l’éditeur de tile indique désormais qu’il faut désactiver Apply filters pour lever le blocage.
PR associées : #3078 Support configuring dashboard filters as required, #3093 Optionally apply dashboard filters to tile editor preview, #3098 Add getBlockingRequiredFilterNames, update tile editor blocked copy
Progression des requêtes en direct sur la page de recherche
Démo par @wrn14897
Auparavant, une recherche lente affichait un indicateur d’attente indéterminé pendant toute sa durée. Impossible de savoir si ClickHouse avait parcouru 5 % ou 95 % d’une plage, ni même s’il faisait quoi que ce soit — exactement la situation dans laquelle on se trouve lorsqu’une source a une primary key inadaptée à la requête. Le footer de la Results Table, ainsi que la bande de l’histogram indiquant les rows parcourues et le temps écoulé, remontent désormais les counters de progression propres à ClickHouse : depuis combien de temps la requête s’exécute, combien de rows ont été parcourues, et un pourcentage. On se rapproche de ce qu’affiche le ClickHouse CLI pendant qu’une requête diffuse ses résultats.
La progression provient du format
JSONEachRowWithProgress, qui entrelace des lignes {"progress":...} avec les rows dans le response body. Les headers menaient à une impasse : ClickHouse cesse d’émettre X-ClickHouse-Progress dès que le body a commencé, et fetch() ne peut de toute façon pas exposer les headers de façon incrémentale. Le format exige ClickHouse 25.1 ou plus récent ; il est donc sélectionné par connection en fonction de la server version remontée, les servers plus anciens ou inconnus conservant le chemin non diffusé existant.
La page de recherche récupère une time window à la fois plutôt que la plage entière d’un coup : une recherche portant sur une semaine s’exécute jour par jour et s’arrête dès qu’elle a suffisamment de rows. La progression est calculée sur l’ensemble des windows et survit délibérément aux intervalles qui les séparent : la réinitialiser à cette frontière faisait disparaître la barre et redémarrer le compteur de temps écoulé à chaque window, des dizaines de fois sur une plage d’un mois. Une window se déclare en cours à 0 % avant de commencer sa lecture, afin qu’une window tout juste ouverte ne se voie pas créditer l’intégralité de sa plage.
Cela ne concerne que la page de recherche principale. La progression est masquée pendant le suivi en direct, où la requête est relancée toutes les quelques secondes et où une barre ne ferait que clignoter. Avec la première window, très courte, une recherche qui atteint immédiatement sa LIMIT affiche environ 0 % un court instant avant que la barre disparaisse.
Ce qui est diffusé, c’est la progression, pas les résultats. Les rows arrivent toujours une window à la fois, et les renvoyer à mesure qu’elles sont parcourues nécessite une prise en charge de la diffusion côté ClickHouse, sur laquelle des travaux sont en cours — comme Jordan l’a demandé pendant l’appel. Le proxy intercalé y ajoute sa propre complexité, d’où le fait que ce ne soit pas encore en place.
La fragmentation présente une lacune connexe, remontée en retour d’expérience : l’histogram se remplit fragment par fragment, mais rien ne distingue une window encore en cours d’interrogation d’une window n’ayant retourné aucune donnée, et une indication de progression sur le chart lui-même serait utile. Cela relève d’une autre partie du code que ce changement.
PR associées : #3103 Affichage en direct de la progression des ClickHouse requêtes pendant une recherche (ouverte). Le découpage jour par jour de la recherche sur lequel la barre s’appuie est un travail plus ancien et ne fait pas partie de ce changement ; les windows de recherche incrémentales ont été intégrées dans #1125 et la fragmentation des charts dans #1233.