Principes fondamentaux de Log Analytics et KQL

Un espace de travail Log Analytics est le magasin de données central d’Azure Monitor pour les données de journal et de télémétrie. Lorsque vous configurez les paramètres de diagnostic sur une ressource Azure, les journaux et métriques structurés sont acheminés vers l’espace de travail. Vous pouvez ensuite interroger ces données à l’aide du langage de requête Kusto (KQL). Un espace de travail possède sa propre stratégie de conservation (30 jours par défaut, jusqu’à 730 jours) et ses propres contrôles d’accès.

Chaque ressource Azure peut émettre des journaux de diagnostic — des enregistrements détaillés d’opérations telles que les appels d’API, les événements d’authentification et l’exécution de requêtes. Vous les activez via les paramètres de diagnostic de la ressource, en spécifiant votre espace de travail Log Analytics comme destination. Les catégories de journaux courantes incluent AuditEvent pour Key Vault, AppServiceHTTPLogs pour App Service et NetworkSecurityGroupFlowEvent pour les NSG.

Le langage de requête Kusto (KQL) est un langage de requête en lecture seule destiné à l’analyse des données de journal. Une requête KQL se lit de gauche à droite comme un pipeline : commencez par un nom de table, puis faites passer les données par des opérateurs à l’aide du symbole (|). Les opérateurs courants incluent where pour filtrer, project pour sélectionner des colonnes, summarize pour agréger et order by pour trier. KQL est sensible à la casse pour les noms de colonnes, mais pas pour les mots-clés.

L’opérateur where filtre les lignes à l’aide d’expressions booléennes. Vous pouvez combiner les conditions avec and, or et not. L’opérateur has effectue une recherche insensible à la casse, respectant les limites des mots, dans les chaînes, tandis que contains effectue une recherche de sous-chaîne. L’opérateur in vérifie l’appartenance à une liste. Utilisez ago() pour exprimer des plages temporelles relatives telles que ago(1h) ou ago(7d).

L’opérateur summarize calcule des agrégations sur les lignes. Les fonctions d’agrégation courantes incluent count(), sum(), avg(), max(), min() et dcount() pour compter les valeurs distinctes. Vous pouvez regrouper les données selon une ou plusieurs colonnes à l’aide de la clause by. La fonction bin() arrondit les horodatages à des intervalles pour l’agrégation de séries temporelles.

KQL prend en charge join pour mettre en corrélation des données provenant de plusieurs tables. Le type de jointure par défaut est innerunique, mais vous pouvez spécifier inner, leftouter, rightouter ou fullouter. Un modèle courant consiste à joindre AzureActivity et AzureMetrics afin de mettre en corrélation les changements administratifs avec les baisses de performances. L’opérateur lookup constitue une solution plus légère pour enrichir les lignes à partir d’une petite table de référence.

Après avoir écrit une requête dans le portail Log Analytics, vous pouvez afficher les résultats sous forme de graphique temporel, de graphique à barres, de diagramme circulaire ou de tableau à l’aide de l’opérateur render. Vous pouvez également épingler n’importe quel résultat de requête à un tableau de bord Azure ou l’enregistrer dans un classeur. La commande render timechart transforme une requête summarize de série temporelle en graphique linéaire instantané pour analyser les tendances.

Les alertes de recherche dans les journaux exécutent une requête KQL selon une planification et se déclenchent lorsque le résultat satisfait une condition, par exemple lorsque le nombre de résultats est supérieur à zéro ou qu’une colonne numérique dépasse un seuil. Elles sont plus flexibles que les alertes de métriques, car vous pouvez interroger toutes les données de journal réparties dans plusieurs tables. La fréquence d’évaluation et la fenêtre temporelle sont configurables indépendamment : par exemple, exécuter la requête toutes les 5 minutes sur les 15 dernières minutes.

Azure Monitor stocke les journaux dans des tables connues. AzureActivity enregistre les opérations au niveau de l’abonnement. SecurityEvent contient les journaux de sécurité Windows provenant des VM équipées de l’agent Log Analytics. Heartbeat indique la connectivité de l’agent (une ligne par minute pour chaque VM connectée). AppRequests, AppExceptions et AppDependencies proviennent de Application Insights. Il est essentiel de connaître ces noms de tables pour rédiger des requêtes opérationnelles efficaces.

La tarification de Log Analytics comporte deux éléments : l’ingestion des données (par GB ingéré) et la conservation des données (les 30 premiers jours sont gratuits, puis la conservation est facturée par GB et par mois au-delà de la valeur par défaut). Vous pouvez réduire les coûts en filtrant les catégories de journaux trop verbeuses avant l’ingestion, en utilisant Basic Logs pour les données volumineuses et peu utiles à un tarif réduit, et en archivant les données anciennes dans Azure Data Explorer ou un stockage froid pour une conservation à long terme à des fins de conformité.

Les espaces de travail Log Analytics prennent en charge deux modèles de contrôle d’accès. En mode workspace-context, un utilisateur disposant d’un accès en lecture à l’espace de travail peut interroger toutes les tables. En mode resource-context, un utilisateur peut interroger uniquement les journaux émis par les ressources pour lesquelles il dispose de l’autorisation RBAC de lecture, même sans accès explicite à l’espace de travail. Le mode resource-context est recommandé pour les grandes organisations dans lesquelles différentes équipes sont responsables de ressources différentes.

Testez votre compréhension des concepts de Microsoft Azure Fundamentals (AZ-900) présentés dans cette leçon.

Dans cette leçon, vous avez appris que les espaces de travail Log Analytics centralisent les données des journaux de diagnostic provenant des ressources Azure, que les opérateurs KQL tels que where, summarize et render permettent de filtrer, d’agréger et de visualiser les journaux, et que les alertes de recherche dans les journaux déclenchent des réponses automatisées lorsqu’un résultat de requête KQL satisfait une condition définie. Nous allons maintenant découvrir Application Insights pour la télémétrie au niveau de l’application.