Envoyer des journaux de ressources Azure aux espaces de travail Log Analytics, à Event Hubs ou à Stockage Azure
Les journaux de ressources Azure sont des journaux de plateforme qui fournissent des insights sur les opérations effectuées dans une ressource Azure. Le contenu des journaux de ressources est différent pour chaque type de ressource. Les journaux de ressources ne sont pas collectés par défaut. Pour collecter les journaux de ressources, vous devez activer et configurer les paramètres de diagnostic, ou utiliser des règles de collecte de données. Pour plus d’informations sur les règles de collecte de données, consultez Règles de collecte de données dans Azure Monitor. Cet article décrit le paramètre de diagnostic nécessaire à chaque ressource Azure pour envoyer ses journaux de ressources aux espaces de travail Log Analytics, à Event Hubs ou à Stockage Azure.
Envoyer à l’espace de travail Log Analytics
Envoyez les journaux de ressources à un espace de travail Log Analytics pour activer les fonctionnalités des journaux Azure Monitor, où vous pouvez :
- Mettre en corrélation les données des journaux de ressources avec d’autres données de supervision collectées par Azure Monitor.
- Consolider les entrées de journal de plusieurs ressources, abonnements et locataires Azure en un seul endroit pour les analyser ensemble.
- Utiliser les requêtes de journal pour effectuer des analyses complexes et obtenir des insights profonds sur les données de journal.
- Utilisez des alertes de recherche de journaux avec une logique d’alerte complexe.
Créez un paramètre de diagnostic pour envoyer des journaux de ressources à un espace de travail Log Analytics. Ces données sont stockées dans des tables comme décrit dans Structure des journaux Azure Monitor. Les tables utilisées par les journaux de ressources dépendent du type de ressource et du type de collecte que la ressource emploie. Il existe deux types de modes de collecte des journaux de ressources :
- Diagnostics Azure : toutes les données sont écrites dans la table AzureDiagnostics.
- Spécifique de la ressource : les données sont écrites dans des tables individuelles pour chaque catégorie de la ressource.
Spécifique à la ressource
Pour les journaux utilisant le mode spécifique aux ressources, des tables individuelles dans l’espace de travail sélectionné sont créées pour chaque catégorie de journal sélectionnée dans le paramètre de diagnostic. Les journaux spécifiques aux ressources présentent les avantages suivants par rapport aux journaux de diagnostic Azure :
- Elle facilite l’utilisation des données dans des requêtes de journal.
- Elle améliore la détectabilité des schémas et de leur structure.
- Elle améliore les performances aux niveaux de la latence d’ingestion et des durées de requêtes.
- Elle permet d’accorder des droits de contrôle d’accès en fonction du rôle Azure sur une table spécifique.
Pour obtenir une description des journaux et des tables spécifiques aux ressources, consultez Catégories de journaux de ressources prises en charge pour Azure Monitor
Mode Diagnostics Azure
En mode Diagnostics Azure, toutes les données des paramètres de diagnostic sont collectées dans la table AzureDiagnostics. Cette méthode héritée est utilisée aujourd’hui par une minorité de services Azure. De nombreuses ressources envoyant des données à la même table, le schéma de celle-ci constitue le sur-ensemble des schémas des différents types de données collectés. Pour plus d’informations sur la structure de cette table et son fonctionnement avec ce nombre potentiellement important de colonnes, consultez Informations de référence AzureDiagnostics.
La table AzureDiagnostics contient le resourceId de la ressource qui a généré le journal, la catégorie du journal, l’heure de génération du journal ainsi que les propriétés spécifiques aux ressources.
Sélectionner le mode de collecte
La plupart des ressources Azure écrivent des données dans l’espace de travail dans les modes Diagnostics Azure ou Spécifique de la ressource, sans vous laisser le choix. Pour plus d’informations, consultez Schémas commun et spécifique d’un service pour les journaux de ressources Azure.
À terme, tous les services Azure vont utiliser le mode spécifique à la ressource. Dans le cadre de cette transition, certaines ressources vous permettront de sélectionner un mode dans le paramètre de diagnostic. Spécifiez le mode Spécifique de la ressource pour tout nouveau paramètre de diagnostic, car ce mode facilite la gestion des données. Il peut également vous aider à éviter des migrations complexes ultérieurement.
Notes
Pour un exemple définissant le mode de collecte à l’aide d’un modèle Resource Manager, consultez Exemples de modèles Resource Manager pour les paramètres de diagnostic dans Azure Monitor.
Vous pouvez modifier un paramètre de diagnostic existant sur le mode Spécifique à la ressource. Dans ce cas, les données déjà collectées restent dans la table AzureDiagnostics jusqu’à leur suppression conformément au paramètre de rétention pour l’espace de travail. Les nouvelles données sont collectées dans la table dédiée. Utilisez l’opérateur union pour interroger les données dans les deux tables.
Consultez régulièrement le blog Mises à jour Azure pour vous tenir informé des annonces relatives aux services Azure prenant en charge le mode Spécifique de la ressource.
Envoyer à Azure Event Hubs
Envoyez des journaux de ressources à un hub d’événements pour les envoyer hors d’Azure. Par exemple, des journaux de ressources pourraient être envoyés à un SIEM tiers ou à d’autres solutions Log Analytics. Les journaux de ressources en provenance de hubs d’événements sont consommés au format JSON avec un élément records contenant les enregistrements de chaque charge utile. Le schéma dépend du type de ressource, comme décrit dans Schémas commun et spécifique du service pour les journaux de ressources Azure.
L’exemple suivant de données de sortie provient d’Azure Event Hubs pour un journal de ressource :
{
"records": [
{
"time": "2019-07-15T18:00:22.6235064Z",
"workflowId": "/SUBSCRIPTIONS/AAAA0A0A-BB1B-CC2C-DD3D-EEEEEE4E4E4E/RESOURCEGROUPS/JOHNKEMTEST/PROVIDERS/MICROSOFT.LOGIC/WORKFLOWS/JOHNKEMTESTLA",
"resourceId": "/SUBSCRIPTIONS/AAAA0A0A-BB1B-CC2C-DD3D-EEEEEE4E4E4E/RESOURCEGROUPS/JOHNKEMTEST/PROVIDERS/MICROSOFT.LOGIC/WORKFLOWS/JOHNKEMTESTLA/RUNS/08587330013509921957/ACTIONS/SEND_EMAIL",
"category": "WorkflowRuntime",
"level": "Error",
"operationName": "Microsoft.Logic/workflows/workflowActionCompleted",
"properties": {
"$schema": "2016-04-01-preview",
"startTime": "2016-07-15T17:58:55.048482Z",
"endTime": "2016-07-15T18:00:22.4109204Z",
"status": "Failed",
"code": "BadGateway",
"resource": {
"subscriptionId": "AAAA0A0A-BB1B-CC2C-DD3D-EEEEEE4E4E4E",
"resourceGroupName": "JohnKemTest",
"workflowId": "2222cccc-33dd-eeee-ff44-aaaaaa555555",
"workflowName": "JohnKemTestLA",
"runId": "08587330013509921957",
"location": "westus",
"actionName": "Send_email"
},
"correlation": {
"actionTrackingId": "3333dddd-44ee-ffff-aa55-bbbbbbbb6666",
"clientTrackingId": "08587330013509921958"
}
}
},
{
"time": "2019-07-15T18:01:15.7532989Z",
"workflowId": "/SUBSCRIPTIONS/AAAA0A0A-BB1B-CC2C-DD3D-EEEEEE4E4E4E/RESOURCEGROUPS/JOHNKEMTEST/PROVIDERS/MICROSOFT.LOGIC/WORKFLOWS/JOHNKEMTESTLA",
"resourceId": "/SUBSCRIPTIONS/AAAA0A0A-BB1B-CC2C-DD3D-EEEEEE4E4E4E/RESOURCEGROUPS/JOHNKEMTEST/PROVIDERS/MICROSOFT.LOGIC/WORKFLOWS/JOHNKEMTESTLA/RUNS/08587330012106702630/ACTIONS/SEND_EMAIL",
"category": "WorkflowRuntime",
"level": "Information",
"operationName": "Microsoft.Logic/workflows/workflowActionStarted",
"properties": {
"$schema": "2016-04-01-preview",
"startTime": "2016-07-15T18:01:15.5828115Z",
"status": "Running",
"resource": {
"subscriptionId": "AAAA0A0A-BB1B-CC2C-DD3D-EEEEEE4E4E4E",
"resourceGroupName": "JohnKemTest",
"workflowId": "dddd3333-ee44-5555-66ff-777777aaaaaa",
"workflowName": "JohnKemTestLA",
"runId": "08587330012106702630",
"location": "westus",
"actionName": "Send_email"
},
"correlation": {
"actionTrackingId": "ffff5555-aa66-7777-88bb-999999cccccc",
"clientTrackingId": "08587330012106702632"
}
}
}
]
}
Envoyer à Stockage Azure
Envoyez des journaux de ressources au service Stockage Azure pour les y conserver à des fins d’archivage. Une fois que vous avez créé le paramètre de diagnostic, un conteneur de stockage est créé dans le compte de stockage dès qu’un événement se produit dans l’une des catégories de journaux activées.
Remarque
Une alternative à l’archivage consiste à envoyer le journal des ressources à une table de votre espace de travail Log Analytics avec une conservation à long terme à bas prix.
Les objets blob présents dans le conteneur utilisent la convention d’affectation de noms suivante :
insights-logs-{log category name}/resourceId=/SUBSCRIPTIONS/{subscription ID}/RESOURCEGROUPS/{resource group name}/PROVIDERS/{resource provider name}/{resource type}/{resource name}/y={four-digit numeric year}/m={two-digit numeric month}/d={two-digit numeric day}/h={two-digit 24-hour clock hour}/m=00/PT1H.json
L’objet blob d’un groupe de sécurité réseau peut avoir un nom similaire à l’exemple suivant :
insights-logs-networksecuritygrouprulecounter/resourceId=/SUBSCRIPTIONS/a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1/RESOURCEGROUPS/TESTRESOURCEGROUP/PROVIDERS/MICROSOFT.NETWORK/NETWORKSECURITYGROUP/TESTNSG/y=2016/m=08/d=22/h=18/m=00/PT1H.json
Chaque objet blob PT1H.json contient un objet JSON avec des événements provenant de fichiers journaux qui ont été reçus pendant l’heure spécifiée dans l’URL de l’objet blob. Pendant cette heure, les événements sont ajoutés au fichier PT1H.json à mesure qu’ils sont reçus, quelle que soit la date à laquelle ils ont été générés. La valeur de minute m=00 dans l’URL est toujours 00 car les objets blob sont créés toutes les heures.
Dans le fichier PT1H.json, chaque événement est stocké au format suivant. Il utilise un schéma de niveau supérieur courant mais est unique pour chaque service Azure, comme décrit dans Schéma des journaux de ressources.
Notes
Les journaux sont écrits dans des objets blob en fonction de l’heure à laquelle ils ont été reçus, quelle que soit l’heure à laquelle ils ont été générés. Cela signifie qu’un objet blob donné peut contenir des données de journal ne concernant pas l’heure spécifiée dans l’URL de l’objet blob. Lorsqu’une source de données comme Application Insights prend en charge le chargement de données de télémétrie obsolètes, un objet blob peut contenir des données datant des précédentes 48 heures.
Au début de chaque nouvelle heure, il est possible que les journaux existants soient toujours en cours d’écriture dans l’objet blob de l’heure précédente, et que les nouveaux journaux soient écrits dans l’objet blob de la nouvelle heure.
{"time": "2016-07-01T00:00:37.2040000Z","systemId": "a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1","category": "NetworkSecurityGroupRuleCounter","resourceId": "/SUBSCRIPTIONS/AAAA0A0A-BB1B-CC2C-DD3D-EEEEEE4E4E4E/RESOURCEGROUPS/TESTRESOURCEGROUP/PROVIDERS/MICROSOFT.NETWORK/NETWORKSECURITYGROUPS/TESTNSG","operationName": "NetworkSecurityGroupCounters","properties": {"vnetResourceGuid": "{12345678-9012-3456-7890-123456789012}","subnetPrefix": "10.3.0.0/24","macAddress": "000123456789","ruleName": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/testresourcegroup/providers/Microsoft.Network/networkSecurityGroups/testnsg/securityRules/default-allow-rdp","direction": "In","type": "allow","matchedConnections": 1988}}
Intégrations partenaires d’Azure Monitor
Les journaux de ressources peuvent également être envoyés à des solutions partenaires entièrement intégrées dans Azure. Pour obtenir la liste de ces solutions et des détails sur leur configuration, consultez Intégrations partenaires d’Azure Monitor.