Introduction aux tableaux de bord personnalisés dans Azure Data Explorer

Azure Data Explorer (ADX) est un service d'analyse entièrement géré et performant optimisé pour les requêtes ad hoc sur de grands volumes de données. Il ingère des données provenant d'une grande variété de sources et fournit une analyse en temps quasi réel en utilisant le Kusto Query Language (KQL). L'une des capacités les plus puissantes de l'ADX est la capacité de créer des tableaux de bord personnalisés qui donnent aux parties prenantes un accès immédiat aux principales métriques, tendances et anomalies sans avoir à exécuter des requêtes ad hoc à plusieurs reprises.

Les tableaux de bord personnalisés construits sur ADX peuvent servir des équipes à travers une organisation, de la surveillance des opérations à l'analyse de l'intelligence d'affaires et de la sécurité. Ils permettent aux utilisateurs de faire surface les points de données les plus pertinents, d'appliquer des filtres dynamiques, de configurer des chemins de forage et de partager des vues interactives avec d'autres.

Comprendre Azure Data Explorer et ses capacités de tableau de bord

Azure Data Explorer est conçu pour traiter les données de séries chronologiques, les journaux, la télémétrie et toutes les données structurées ou semi-structurées qui nécessitent une exploration rapide. Il peut ingérer des téraoctets de données par jour et répondre aux requêtes complexes en quelques secondes. La fonction de tableau de bord natif dans ADX est étroitement intégrée au moteur de requête, ce qui signifie que vous pouvez construire un graphique directement à partir d'une requête KQL et le mettre à jour en tant que nouveaux flux de données.

Les tableaux de bord ADX sont composés de tiles[ – visualisations individuelles telles que des graphiques en ligne, des diagrammes de colonnes, des diagrammes à secteurs, des diagrammes de dispersion, des tables et des cartes à valeurs multiples. Chaque carrelage est soutenu par une ou plusieurs requêtes KQL qui définissent sa source de données.

Contrairement aux outils BI d'usage général, les tableaux de bord ADX sont optimisés pour la vitesse et le streaming en temps réel. Ils utilisent le même moteur de requête distribué qui alimente le cluster ADX, donc même les regroupements complexes rendent rapidement.

Préparation de vos données pour la consommation de tableau de bord

Ingestion des données et conception du schéma

Avant de pouvoir créer un tableau de bord, les données doivent être ingérées dans un cluster ADX. ADX prend en charge plusieurs méthodes d'ingestion : Hubs d'événements pour les données de streaming, stockage de Blob Azure pour le chargement par lots, connecteurs Logstash et Apache Kafka, et ingérer directement en utilisant le SDK Kusto.

Pour les graphiques de séries chronologiques, assurez-vous d'avoir une colonne de type . Pour les ventilations par catégories, utilisez . Les mesures numériques doivent être dans des colonnes appropriées pour l'agrégation (somme, moyenne, nombre). ADX prend également en charge les schémas dynamiques via le type de données , qui peut stocker des objets JSON – ces champs sont utiles pour la télémétrie par événement où la charge utile varie.

Après ingestion, lancez des requêtes KQL exploratoires dans l'interface web ADX pour valider la qualité des données, vérifier les valeurs nulles et comprendre la distribution des valeurs. Il est beaucoup plus facile d'affiner le schéma tôt que de corriger les incohérences après la construction d'un tableau de bord.

Transformations de données pour tableaux de bord

Parfois, les données brutes doivent être remodelées avant qu'elles ne soient utilisables dans un tableau de bord. Vous pouvez créer des vues matérialisées[ ou des politiques [ en ADX pour pré-agréger les données, réduire la latence des requêtes et simplifier les requêtes de tableau de bord. Par exemple, si vos données de vente arrivent en millions de lignes par heure, une vue matérialisée qui regroupe les ventes par catégorie de produits toutes les 5 minutes fera charger presque instantanément les carreaux de tableau de bord.

Une autre technique consiste à utiliser stored functions – des fonctions KQL réutilisables qui encapsulent la logique complexe. Les fonctions stockées peuvent être appelées à partir de requêtes de tableau de bord, en maintenant les définitions de carrelage propres et maintenables.

Écrire Kusto interroge ce qui alimente votre tableau de bord

Principes fondamentaux de KQL pour les tableaux de bord

Chaque dashboard est animé par une ou plusieurs requêtes KQL. Le Kusto Query Language est un langage en lecture seule, orienté table qui supporte le filtrage, le regroupement, l'assemblage, lebinage du temps et les fonctions statistiques. Pour un dashboard, la requête doit renvoyer un jeu de résultats qui peut être visualisé – typiquement une table avec des colonnes pour les valeurs d'axe, les séries et les mesures.

Une simple requête de séries chronologiques pourrait ressembler à ceci :

StormEvents
| where StartTime between (datetime(2007-01-01) .. datetime(2007-12-31))
| summarize TotalDamage = sum(DamageProperty) by bin(StartTime, 1d)
| render timechart

L'opérateur à la fin indique au moteur de tableau de bord ADX comment afficher les données. Dans la configuration des carreaux de tableau de bord, vous pouvez choisir explicitement le type de visualisation, de sorte que vous pouvez omettre l'opérateur et définir le type de tableau dans les paramètres des carreaux. Cette séparation vous donne plus de contrôle sur le style, comme les couleurs et les étiquettes d'axe.

Optimisation des requêtes pour les performances du tableau de bord

La réactivité du tableau de bord dépend fortement des performances de la requête. Voici les principales techniques d'optimisation :

  • Utiliser filtering hâtive – gammes de temps de poussée, filtres d'entités et autres prédicats aussi loin que possible dans le pipeline de requête. Le moteur ADX peut princer des shards qui ne contiennent pas de données pertinentes.
  • Limitez l'ensemble de résultats – ne retournez pas des millions de lignes au tableau de bord. Utilisez pour agréger, et envisagez d'utiliser ou pour les vérifications de la santé mentale.
  • Leverage résultats en cache – ADX cache automatiquement les résultats de la requête pour les carreaux de tableau de bord pour une durée configurable (par défaut 5 minutes). Si vos données ne changent pas rapidement, augmentez la durée de vie du cache pour réduire la charge.
  • Utiliser vues matérialisées[ pour les agrégations précalculées, comme indiqué précédemment.
  • Évitez avec des fonctions utilisateur chères – si possible, précalculez les colonnes dérivées pendant l'ingestion.

Tester les requêtes dans l'interface utilisateur web ADX avant de les intégrer dans les tableaux de bord est une pratique optimale. Surveiller les délais d'exécution des requêtes et ajuster en conséquence.

Étape par étape: Construire un tableau de bord personnalisé dans Azure Data Explorer

Étape 1 – Accédez à l'interface du tableau de bord

Naviguez dans votre cluster ADX dans le portail Azure. Sous la section -Data, sélectionnez Dashboards. Si vous ne voyez pas l'option, assurez-vous que votre version de cluster supporte les tableaux de bord (tous les nouveaux clusters le font). Vous pouvez également utiliser l'interface utilisateur web ADX (dataexplorer.azure.com) pour créer des tableaux de bord sans abonnement Azure pour les petits ensembles de données.

Étape 2 – Créer un nouveau tableau de bord et ajouter des carreaux

Cliquez sur + Nouveau tableau de bord et donnez-lui un nom significatif. Vous verrez une toile vide. Cliquez sur + Ajouter Tile pour commencer. Dans l'éditeur de carrelage, écrivez ou collez une requête KQL. Par exemple, une requête qui compte les erreurs par service au cours des dernières 24 heures:

Logs
| where Timestamp > ago(24h)
| where Level == "Error"
| summarize Count = count() by ServiceName
| render columnchart

Après avoir lancé la requête, l'aperçu des tuiles affiche un graphique. Vous pouvez ensuite configurer la tuile :

  • Titre – donner un nom lisible par l'homme.
  • Visualisation – choisir parmi la ligne, la colonne, la barre, la zone, la tarte, la dispersion, le diagramme de temps, la table et les visuels personnalisés.
  • Tarif – définissez le filtre de temps par défaut.
  • Paramètres – vous pouvez définir des paramètres de niveau de tableau de bord (p. ex. environnement, région) et les relier aux requêtes de carrelage en utilisant la syntaxe KQL=.

Ajoutez plus de tuiles pour d'autres mesures. Vous pouvez redimensionner et réarranger les tuiles en les faisant glisser sur la toile.

Étape 3 – Ajouter les paramètres et filtres du tableau de bord

Les paramètres rendent les tableaux de bord interactifs. Allez dans les paramètres du tableau de bord (icône de la ligne de bord) et ajoutez des paramètres comme (dropdown: Production, Staging, Dev) ou (relative ou absolue). Reliez chaque paramètre aux requêtes de tuiles pertinentes en se référant à . Pour les plages de dates dynamiques, utilisez des fonctions KQL comme .

Étape 4 – Configurer le perçage et le filage croisé

Par exemple, en cliquant sur une barre dans un tableau de bord, vous pouvez naviguer vers un tableau de bord détaillé filtré par ce service. Le filtrage croisé est également possible : la sélection d'une valeur dans une tuile peut filtrer automatiquement d'autres tuiles sur le même tableau de bord. Pour activer le filtrage croisé, assurez-vous que les requêtes de tuiles utilisent les mêmes noms de paramètres ou comptent sur les propriétés partagées du filtre croisé.

Étape 5 – Enregistrer, publier et partager

Une fois votre tableau de bord terminé, enregistrez-le. Vous pouvez publier le tableau de bord pour le rendre accessible aux autres utilisateurs de votre organisation. Sous le menu Partager, générer une URL en lecture seule qui peut être intégrée dans un portail ou envoyée par courriel. Vous pouvez également télécharger le modèle de tableau de bord (JSON) pour le contrôle de la version ou pour une autre grappe.

Amélioration des tableaux de bord avec fonctionnalités avancées

Actualisation des données en temps réel

Pour les tableaux de bord opérationnels, les mises à jour en temps réel sont critiques. Les tableaux de bord ADX rafraîchissent automatiquement les données en fonction de la plage de temps de la tuile et des paramètres du cache de requête. Vous pouvez configurer un intervalle de rafraîchissement automatique (par exemple, toutes les 1 minutes) sur les paramètres du tableau de bord. Combiné avec l'ingestion de streaming depuis Event Hubs, cela crée une expérience de surveillance en temps quasi réel.

Thèmes et visuels personnalisés

Au-delà des types de cartes intégrés, ADX prend en charge des visuels personnalisés alimentés par le langage du Charticulator (dans l'éditeur de tableau de bord ADX). Vous pouvez créer des visualisations complexes comme des cartes de chaleur, des graphiques de bouffées de soleil et des graphiques réseau.

Alerte à l'intégration

Si les tableaux de bord sont parfaits pour la surveillance visuelle, vous pouvez avoir besoin d'alertes pour les seuils critiques. L'ADX se connecte aux alertes Azure Monitor : vous pouvez créer une règle d'alerte basée sur une requête KQL qui fonctionne périodiquement. Lorsqu'une anomalie est détectée, l'alerte peut déclencher un courriel, un webhook ou une fonction Azure. Vous pouvez alors lier l'alerte à une tuile de tableau de bord afin que les opérateurs puissent cliquer sur l'alerte et être directement pris en charge par la vue pertinente du tableau de bord.

Intégrer les tableaux de bord dans les applications personnalisées

Vous pouvez intégrer des tableaux de bord ADX dans vos propres applications web en utilisant un iframe ou le SDK ADX. L'URL intégrée prend en charge les paramètres de requête pour l'authentification et le filtrage. Cela permet aux équipes de produits d'exposer les analyses en direct à des clients externes ou des portails internes sans construire de couche de visualisation séparée. Pour plus de détails, reportez-vous à la documentation Azure Data Explorer intégrée aux tableaux de bord.

Sécurité et contrôle d'accès pour les tableaux de bord

La sécurité des données doit être une priorité lorsque l'on partage des tableaux de bord entre les équipes ou à l'extérieur. ADX fournit un contrôle d'accès à grain fin au niveau du cluster, de la base de données et de la table en utilisant Role-Based Access Control (RBAC).

  • Dashboard Admin – peut créer, modifier, supprimer et publier des tableaux de bord.
  • Dashboard Viewer – ne peut voir que les tableaux de bord publiés.

Lorsque vous partagez un tableau de bord via URL, cette URL est sécurisée par l'authentification Azure AD. Les utilisateurs doivent être connectés avec une identité Microsoft (compte de travail ou d'école) et ont obtenu un accès au visionneur. Vous pouvez également restreindre la visibilité des données en utilisant Row-Level Security (RLS)[ dans les fonctions KQL, en veillant à ce que les différents utilisateurs ne voient que les lignes qu'ils sont autorisés à voir. Par exemple, un tableau de bord de vente peut filtrer par région en fonction du domaine de messagerie du visionneur.

Pour les environnements sensibles, vous pouvez limiter les capacités d'exportation (par exemple, désactiver le téléchargement de CSV à partir de carreaux) via les paramètres de politique. Audit logs suit qui a accédé au tableau de bord et quand. Il est recommandé de revoir régulièrement l'accès et de révoquer les autorisations pour les utilisateurs qui n'en ont plus besoin.

Meilleures pratiques pour les tableaux de bord de production

Optimisation des performances

  • Utiliser des tableaux pré-agrégés (vues matérialisées) pour les mesures de haute cardinalité.
  • Définir les valeurs par défaut – commencer par les 7 derniers jours au lieu de toutes les données.
  • Limitez le nombre de tuiles sur un tableau de bord à 20-30 pour éviter les problèmes de concordance des requêtes.
  • Utiliser sharded des tableaux de bord – diviser les mesures en plusieurs tableaux de bord par domaine d'activité (opérations, finances, sécurité) au lieu d'un tableau de bord géant.

Mise en page logique et lisibilité

  • Ensemble des tuiles liées au groupe: placer des résumés en haut, des ventilations détaillées ci-dessous.
  • Utiliser un codage de couleur uniforme – par exemple, vert pour des mesures saines, rouge pour des questions critiques.
  • Inclure un titre et description[ pour chaque carrelage afin que les téléspectateurs comprennent ce qu'ils regardent.
  • Tirer parti des cartes à valeur multiple pour les indicateurs de performance clés (ICP) – valeur actuelle, variation dans le temps et étincelle.

Entretien et cycle de vie

  • Gardez les requêtes dans le contrôle de version (fonctions stockées ou fichiers de requêtes externes).
  • Documenter les sources de données qui alimentent chaque tableau de bord et les transformations qui y sont apportées.
  • Planifier des examens réguliers avec les intervenants pour enlever les carreaux inutilisés et en ajouter de nouveaux.
  • Surveiller l'utilisation et le coût des requêtes ADX; les tableaux de bord qui sont rarement vus peuvent consommer inutilement des ressources.

Intégration des tableaux de bord Azure Data Explorer avec d'autres services Azure

Les tableaux de bord ADX fonctionnent bien dans un écosystème analytique Azure plus grand. Voici les modèles d'intégration communs:

  • ] – Vous pouvez intégrer des dashboards ADX dans les cahiers de travail d'Azure Monitor pour une expérience de surveillance informatique unifiée.
  • Power BI – Pour les capacités BI avancées, vous pouvez utiliser le connecteur ADX dans Power BI pour importer les résultats de requêtes et construire des rapports interactifs.
  • Azure DevOps – Utilisez des tableaux de bord pour surveiller les taux de défaillance de construction, la fréquence de déploiement ou les résultats de tests de performance en interrogeant les données d'Application Insights stockées dans ADX.
  • Azure Logic Apps and Functions – Automatise les déclencheurs de tableau de bord ou génère des résumés par e-mail en utilisant des workflows sans serveur qui interrogent ADX et envoient le résultat.

Pour une plongée plus profonde dans les modèles d'intégration, voir le guide d'intégration Azure Data Explorer et Power BI.

Conclusion

Les tableaux de bord personnalisés d'Azure Data Explorer permettent aux organisations de transformer la télémétrie brute en informations exploitables avec un minimum de latence. En suivant le processus structuré décrit ci-dessus – de la préparation de données et de l'écriture de requêtes KQL efficaces à la conception de tuiles interactives et à la sécurisation de l'accès – vous pouvez construire des tableaux de bord qui permettent aux équipes de prendre des décisions plus rapides et axées sur les données.

La flexibilité des tableaux de bord ADX, associée à l'évolutivité du moteur d'analyse sous-jacent, en fait un excellent choix pour la surveillance en temps réel, l'analyse exploratoire et les rapports opérationnels. À mesure que vos données augmentent et que vos besoins commerciaux évoluent, le même cadre de tableau de bord peut être étendu avec de nouveaux paramètres, des visuels avancés et une intégration avec l'écosystème Azure plus large.

Pour des références supplémentaires, consultez le ].