AzureDiagnostics

Stocke les journaux de ressources pour les services Azure qui utilisent le mode Azure Diagnostics. Les journaux de ressources décrivent le fonctionnement interne des ressources Azure.

Le journal des ressources de chaque service Azure possède un ensemble unique de colonnes. La table AzureDiagnostics comprend les colonnes les plus courantes utilisées par les services Azure. Si un journal des ressources contient une colonne qui n’existe pas encore dans la table AzureDiagnostics, cette colonne est ajoutée la première fois que les données sont collectées. Si le nombre maximal de 500 colonnes est atteint, les données des colonnes supplémentaires sont ajoutées à une colonne dynamique.

Les services Azure qui utilisent le mode spécifique aux ressources stockent des données dans une table spécifique à ce service et n’utilisent pas la table AzureDiagnostics. Pour plus d’informations sur les différences, consultez les journaux des ressources Azure. Consultez ressources en mode Diagnostics Azure pour les services qui utilisent Diagnostics Azure.

Colonne AdditionalFields

Contrairement à d’autres tables, AzureDiagnostics est beaucoup plus susceptible de dépasser la limite de 500 colonnes imposée pour n’importe quelle table d’un espace de travail Log Analytics en raison d’un large éventail de ressources Azure capables d’envoyer des données à cette table. Pour vous assurer qu’aucune donnée n’est perdue en raison du nombre de colonnes actives dépassant cette limite de 500 colonnes, la création de colonnes AzureDiagnostics est gérée de différentes manières par d’autres tables.

La table AzureDiagnostics de chaque espace de travail contient au minimum 200 colonnes. Pour les espaces de travail créés avant le 19 janvier 2021, la table contient également toutes les colonnes déjà en place avant cette date. Lorsque les données sont envoyées à une colonne qui n’est pas déjà en place :

• Si le nombre total de colonnes dans AzureDiagnostics dans l’espace de travail actuel ne dépasse pas 500, une nouvelle colonne est créée comme avec n’importe quelle autre table.
• Si le nombre total de colonnes est supérieur ou égal à 500, les données excédentaires sont ajoutées à une colonne de conteneur de propriétés dynamique appelée AdditionalFields en tant que propriété.

Exemple

Pour illustrer ce comportement, imaginez qu’à partir de (date de déploiement) la table AzureDiagnostics dans notre espace de travail se présente comme suit :

Ressource qui envoie des données à AzureDiagnostics puis ajoute une nouvelle dimension à ses données qu’ils appellent NewInfo1. Étant donné que la table comporte toujours moins de 500 colonnes, la première fois qu’un événement se produit qui contient des données pour cette nouvelle dimension ajoute une nouvelle colonne à la table :

Vous pouvez retourner ces nouvelles données dans une requête simple :

AzureDiagnostics | where NewInfo1_s == "xyz"

À une date ultérieure, une autre ressource envoie des données à AzureDiagnostics qui ajoute de nouvelles dimensions appelées NewInfo2 et NewInfo3. Étant donné que la table a atteint 500 colonnes dans cet espace de travail, les nouvelles données entrent dans la colonne AdditionalFields :

Vous pouvez toujours interroger ces données, mais vous devez l’extraire du conteneur de propriétés à l’aide de l’un des opérateurs de propriétés dynamiques dans KQL :

AzureDiagnostics
| where AdditionalFields.NewInfo2 == "789" and AdditionalFields.NewInfo3 == "qwerty"

Conseils sur l’utilisation de la AdditionalFields colonne

Bien que les meilleures pratiques de requête telles que le filtrage toujours par heure comme la première clause de la requête soient suivies, il existe d’autres recommandations que vous devez prendre en compte lors de l’utilisation de AdditionalFields :

• Vous devez taper des données decast avant d’effectuer d’autres opérations sur celle-ci. Par exemple, si vous avez une colonne appelée Perf1Sec_i et une propriété dans AdditionalFields appelée Perf2Sec et que vous souhaitez calculer le nombre total de perf en ajoutant les deux valeurs, vous pouvez utiliser ce qui suit : AzureDiagnostics | extend TotalPerfSec = Perf1Sec_i + toint(AdditionalFields.Perf2Sec) | ....
• Utilisez where clauses pour réduire le volume de données au plus petit possible avant d’écrire une logique complexe pour améliorer considérablement les performances. TimeGenerated est une colonne qui doit toujours être réduite à la plus petite fenêtre possible. Dans le cas d’AzureDiagnostics , un filtre supplémentaire doit toujours être inclus en haut de la requête autour des types de ressources interrogés à l’aide de la colonne ResourceType .
• Lors de l’interrogation de grands volumes de données, il est parfois plus efficace d’effectuer un filtre sur AdditionalFields dans son ensemble plutôt que de l’analyser. Par exemple, pour de grands volumes de données, AzureDiagnostics | where AdditionalFields has "Perf2Sec" est souvent plus efficace que AzureDiagnostics | where isnotnull(toint(AdditionalFields.Perf2Sec)).

Ressources utilisant le mode Diagnostics Azure

Les services suivants utilisent le mode diagnostics Azure pour leurs journaux de ressources et envoient des données à la table Diagnostics Azure. Pour plus d’informations sur cette configuration, consultez les journaux des ressources Azure.

mode Diagnostics Azure ou mode spécifique aux ressources

Les services suivants utilisent le mode diagnostics Azure ou le mode spécifique aux ressources pour leurs journaux de ressources en fonction de la configuration des paramètres de diagnostic. Lorsque vous utilisez un mode spécifique aux ressources, ces ressources n’envoient pas de données à la table AzureDiagnostics. Pour plus d’informations sur cette configuration, consultez les journaux des ressources Azure.

Colonnes de table AzureDiagnostics