Collecter un fichier texte à partir d’une machine virtuelle avec Azure Monitor

De nombreuses applications et services sur une machine virtuelle journaliront des informations sur des fichiers texte au lieu de services de journalisation standard tels que le journal des événements Windows ou Syslog. La collecte des journaux de texte personnalisés des machines virtuelles peut être effectuée à l’aide d’une règle de collecte de données (DCR) avec une source de données Journaux de texte personnalisés.

Les détails de la création de la DCR sont fournis dans Collecter des données à partir du client de machine virtuelle avec Azure Monitor. Cet article fournit des détails supplémentaires pour le type de source de données Journaux de texte personnalisé.

Remarque

Pour utiliser directement la définition DCR ou pour effectuer un déploiement avec d’autres méthodes telles que des modèles ARM, consultez les exemples de règle de collecte de données (DCR) dans Azure Monitor.

Conditions préalables

Outre les conditions préalables répertoriées dans Collect data from virtual machine client with Azure Monitor, vous avez besoin d'une table personnalisée dans un espace de travail Log Analytics pour recevoir les données. Pour plus d’informations sur les exigences de ce tableau, consultez la table de l’espace de travail Log Analytics . Notez qu’Aarch64 alma8 et rocky8 ne sont pas pris en charge.

Configurer une source de données de fichier texte personnalisée

Créez la DCR en suivant le processus décrit dans Collecte des données à partir du client de machine virtuelle avec Azure Monitor. Sous l’onglet Collecter et remettre de la DCR, sélectionnez Journaux de texte personnalisés dans la liste déroulante type de source de données .

Les options disponibles dans la configuration des journaux de texte personnalisés sont décrites dans le tableau suivant.

Réglage	Descriptif
Modèle de fichier	Identifie l’emplacement et le nom des fichiers journaux sur le disque local. Utilisez un caractère générique pour les noms de fichiers qui varient, par exemple lorsque vous créez un nouveau fichier chaque jour avec un nouveau nom. Vous pouvez entrer plusieurs modèles de fichiers séparés par des virgules. Vous pouvez utiliser des caractères génériques dans le nom de fichier et le nom du dossier de premier niveau au-dessus du nom de fichier uniquement. Exemples: - C:\Logs\MyLog.txt - C :\Logs\MyLog.txt -C:\Logs\IIS\.logs - C:\App01\AppLog.txt, C:\App02\AppLog.txt - /var/mylog.log - /var/mylog.log - /var/logs//
Nom de la table	Nom de la table cible dans l’espace de travail Log Analytics. Ce tableau doit déjà exister.
Séparateur d’enregistrements	Indique le délimiteur entre les entrées du journal. `TimeStamp` est la seule valeur autorisée actuelle. Cela recherche une date selon le format spécifié dans `timeFormat` pour identifier le début d’un nouvel enregistrement. Si aucune date au format spécifié n’est trouvée, la fin de ligne est utilisée. Pour plus d’informations, consultez les formats d’heure .
Format TimeStamp	Format d’heure utilisé dans le fichier journal, comme décrit dans les formats d’heure ci-dessous.
Transformer	Transformation de la durée d’ingestion en vue de filtrer les enregistrements ou de mettre en forme les données entrantes pour la table cible. Permet `source` de laisser les données entrantes inchangées et envoyées à la `RawData` colonne. Consultez les fichiers journaux délimités pour obtenir un exemple d’utilisation d’une transformation.

Ajouter des destinations

Les journaux de texte personnalisés peuvent uniquement être envoyés à un espace de travail Log Analytics où ils sont stockés dans la table personnalisée que vous créez. Ajoutez une destination de type Journaux Azure Monitor et sélectionnez un espace de travail Log Analytics. Vous ne pouvez ajouter qu’un seul espace de travail à une DCR pour une source de données de journal de texte personnalisée. Si vous avez besoin de plusieurs destinations, créez plusieurs DCRs. N’oubliez pas que cela enverra des données en double à chacune d’elles, ce qui entraînera des coûts supplémentaires.

Formats d’horodatage

Le tableau suivant décrit les formats de temps pris en charge dans le timeFormat paramètre de la DCR. Si une heure avec le format spécifié est incluse dans l’entrée de journal, elle sera utilisée pour identifier une nouvelle entrée de journal. Si aucune date au format spécifié n’est trouvée, la fin de ligne est utilisée comme délimiteur. Pour plus d’informations sur la façon dont ce paramètre est utilisé, consultez les fichiers journaux multilignes décrits dans Multiline log files .

Format de l’heure	Exemple :
`ISO 8601` ¹	2024-10-29T18:28:34Z
`yyyy-MM-ddTHH:mm:ssk`	2024-10-29T18:28:34Z 2024-10-29T18:28:34+01:11
`YYYY-MM-DD HH:MM:SS`	2024-10-29 18:28:34
`M/D/YYYY HH:MM:SS AM/PM`	10/29/2024 06:28:34 PM
`Mon DD, YYYY HH:MM:SS`	29 octobre 2024 18:28:34
`yyMMdd HH:mm:ss`	241029 18:28:34
`ddMMyy HH:mm:ss`	291024 18:28:34
`MMM d HH:mm:ss`	29 octobre 18:28:34
`dd/MMM/yyyy:HH:mm:ss zzz`	14/octobre 2024:18:28:34 -00

¹ horodatages ISO 8601 avec précision de fraction décimale/sous-seconde ne sont pas pris en charge.

Exigences du fichier texte et meilleures pratiques

Le fichier collecté par Azure Monitor doit répondre aux exigences suivantes :

Le fichier doit être stocké sur le lecteur local de l’ordinateur agent dans le répertoire surveillé.
Le fichier doit utiliser un encodage ASCII ou UTF-8. D’autres formats, tel UTF-16, ne sont pas pris en charge.
Vous devez ajouter les nouveaux enregistrements à la fin du fichier et ne pas remplacer les anciens enregistrements. L’écrasement va entraîner une perte de données.

Voici un exemple de fichier texte personnalisé classique qui peut être collecté par Azure Monitor. Bien que chaque ligne commence par une date, cela n’est pas obligatoire, car la fin de ligne sera utilisée pour identifier chaque entrée si aucune date n’est trouvée.

2024-06-21 19:17:34,1423,Error,Sales,Unable to connect to pricing service.
2024-06-21 19:18:23,1420,Information,Sales,Pricing service connection established.
2024-06-21 21:45:13,2011,Warning,Procurement,Module failed and was restarted.
2024-06-21 23:53:31,4100,Information,Data,Nightly backup complete.

Respectez les recommandations suivantes pour ne perdre aucune donnée et ne rencontrer aucun problème de performances :

Ne ciblez pas plus de 10 répertoires avec des fichiers journaux. Les performances peuvent être réduites si vous interrogez un trop grand nombre de répertoires.
Nettoyer les fichiers journaux du répertoire surveillé de manière continue. Le suivi de nombreux fichiers journaux peut entraîner une augmentation de l’utilisation de la mémoire et du processeur de l’agent. Attendez au moins deux jours pour permettre à tous les journaux d’activité d’être traités.
Ne renommez pas un fichier qui correspond au modèle d’analyse de fichier en utilisant un autre nom qui correspond également au modèle d’analyse de fichier. Cette opération entraîne l’ingestion de données en double.
Ne renommez ni ne copiez pas de fichiers journaux volumineux qui correspondent au modèle d’analyse de fichier dans le répertoire surveillé. Si vous devez l’effectuer, ne dépassez pas 50 Mo par minute.

Table d’espace de travail Log Analytics

Chaque entrée du fichier journal est collectée à mesure qu’elle est créée et envoyée à la table spécifiée dans un espace de travail Log Analytics. La table personnalisée dans l’espace de travail Log Analytics qui recevra les données doit exister avant de créer la DCR.

Le tableau suivant décrit les colonnes obligatoires et facultatives dans la table d’espace de travail. La table peut inclure d’autres colonnes, mais elles ne seront pas remplies, sauf si vous analysez les données avec une transformation, comme décrit dans les fichiers journaux délimités.

Colonne	Type	Obligatoire ?	Descriptif
`TimeGenerated`	date/heure	Oui	Cette colonne contient l’heure à laquelle l’enregistrement a été généré et est requis dans toutes les tables. Cette valeur est automatiquement renseignée lorsque l’enregistrement est ajouté à l’espace de travail Log Analytics. Vous pouvez remplacer cette valeur à l'aide d'une transformation pour définir `TimeGenerated` sur une valeur provenant de l'entrée de journal.
`RawData`	ficelle	Oui ¹	Intégralité de l’entrée de journal dans une même colonne. Vous pouvez utiliser une transformation pour décomposer ces données en plusieurs colonnes avant de les envoyer à la table.
`Computer`	ficelle	Non	Si la table inclut cette colonne, elle est renseignée avec le nom de l’ordinateur à partir duquel l’entrée de journal a été collectée.
`FilePath`	ficelle	Non	Si la table inclut cette colonne, elle est remplie avec le chemin d’accès au fichier journal à partir duquel l’entrée du journal a été collectée.

¹ La table n’a pas besoin d’inclure une RawData colonne si vous utilisez une transformation pour analyser les données en plusieurs colonnes.

Lorsqu’elles sont collectées à l’aide des paramètres par défaut, les données de l’exemple de fichier journal indiqué ci-dessus s’affichent comme suit lorsqu’elles sont récupérées avec une requête de journal.

Créer une table personnalisée

Si la table de destination n’existe pas encore, vous devez la créer avant de créer la DCR. Consultez Créer une table personnalisée pour différentes méthodes pour créer une table.

Par exemple, vous pouvez utiliser le script PowerShell suivant pour créer une table personnalisée pour recevoir les données d’un journal de texte personnalisé. Cet exemple ajoute également les colonnes facultatives.

$tableParams = @'
{
    "properties": {
        "schema": {
               "name": "{TableName}_CL",
               "columns": [
                    {
                        "name": "TimeGenerated",
                        "type": "DateTime"
                    }, 
                    {
                        "name": "Computer",
                        "type": "string"
                    },
                    {
                        "name": "FilePath",
                        "type": "string"
                    },
                    {
                        "name": "RawData",
                        "type": "string"
                    }
              ]
        }
    }
}
'@

Invoke-AzRestMethod -Path "/subscriptions/{subscription}/resourcegroups/{resourcegroup}/providers/microsoft.operationalinsights/workspaces/{workspace}/tables/MyTable_CL?api-version=2021-12-01-preview" -Method PUT -payload $tableParams

Fichiers de journal à lignes multiples

Certains fichiers journaux peuvent contenir des entrées qui s’étendent sur plusieurs lignes. Si chaque entrée de journal commence par une date, cette date peut être utilisée comme délimiteur pour définir chaque entrée de journal. Dans ce cas, les lignes supplémentaires seront jointes dans la RawData colonne.

Par exemple, le fichier texte de l’exemple précédent peut être mis en forme comme suit :

2024-06-21 19:17:34,1423,Error,Sales,
Unable to connect to pricing service.
2024-06-21 19:18:23,1420,Information,Sales,
Pricing service connection established.
2024-06-21 21:45:13,2011,Warning,Procurement,
Module failed and was restarted.
2024-06-21 23:53:31,4100,Information,Data,
Nightly backup complete.

Si le format YYYY-MM-DD HH:MM:SS d’horodatage est utilisé dans la DCR, les données sont collectées de la même façon que l’exemple précédent. Les lignes supplémentaires sont incluses dans la RawData colonne. Si un autre format d’horodatage a été utilisé qui ne correspond pas à la date de l’entrée de journal, chaque entrée est collectée sous la forme de deux enregistrements distincts.

Fichiers journaux délimités

De nombreux fichiers journaux de texte ont des entrées avec des colonnes délimitées par un caractère tel qu’une virgule. Au lieu d’envoyer l’entrée entière à la RawData colonne, vous pouvez analyser les données en colonnes distinctes afin que chacune puisse être remplie dans la table de destination. Utilisez une transformation avec la fonction fractionnée pour effectuer cette analyse.

L’exemple de fichier texte ci-dessus est délimité par des virgules, et les champs peuvent être décrits comme suit : Time, , Code, Severity, Moduleet Message. Pour analyser ces données en colonnes distinctes, ajoutez chacune des colonnes à la table de destination et ajoutez la transformation suivante à la DCR.

Important

Avant d’ajouter cette transformation à la DCR, vous devez ajouter ces colonnes à la table de destination. Vous pouvez modifier le script PowerShell ci-dessus pour inclure les colonnes supplémentaires lors de la création de la table. Vous pouvez également utiliser le portail Azure comme décrit dans Ajouter ou supprimer une colonne personnalisée pour ajouter les colonnes à une table existante.

Les détails notables de la requête de transformation sont les suivants :

La requête génère des propriétés qui correspondent chacune à un nom de colonne dans la table cible.
Cet exemple renomme la Time propriété dans le fichier journal afin que cette valeur soit utilisée pour TimeGenerated. Si cela n'était pas fourni, alors TimeGenerated serait rempli avec le temps d'ingestion.
split retourne des données dynamiques : vous devez utiliser des fonctions comme tostring et toint pour convertir les données dans le type scalaire qui convient.

source | project d = split(RawData,",") | project TimeGenerated=todatetime(d[0]), Code=toint(d[1]), Severity=tostring(d[2]), Module=tostring(d[3]), Message=tostring(d[4])

La récupération de ces données avec une requête de journal retourne les résultats suivants.

Résolution des problèmes

Si vous ne collectez pas les données attendues, appliquez les étapes suivantes.

Vérifiez que les données sont écrites dans le fichier journal en cours de collecte.
Vérifiez que le nom et l’emplacement du fichier journal correspondent au modèle de fichier spécifié.
Vérifiez que le schéma de la table cible correspond au flux entrant ou que vous utilisez une transformation qui convertit le flux entrant dans le schéma qui convient.
Pour vérifier que l’agent est opérationnel et que les données sont reçues, consultez Vérifier l’opération.

Étapes suivantes

En savoir plus sur l’agent Azure Monitor
En savoir plus sur les règles de collecte de données.

Rétroaction

Cette page vous a-t-elle été utile ?

Last updated on 2025-05-07