Envoyer les données des journaux de ressources Azure

  • Article

Les journaux de ressources Azure sont des journaux de plateforme qui fournissent des insights sur les opérations qui ont été effectuées au sein d’une ressource Azure. Le contenu des journaux de ressources varie en fonction du service Azure et du type de ressource. Les journaux de ressources ne sont pas collectés par défaut. Cet article décrit le paramètre de diagnostic requis pour chaque ressource Azure afin d’envoyer ses journaux de ressources à différentes destinations.

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 collection que la ressource utilise :

  • 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

Dans ce mode, les tables individuelles de l’espace de travail sélectionné sont créées pour chaque catégorie sélectionnée dans le paramètre de diagnostic. Nous recommandons cette méthode pour les raisons suivantes :

  • 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.

À terme, tous les services Azure migreront vers le mode spécifique de la ressource.

L’exemple ci-dessous crée trois tables :

  • Table Service1AuditLogs

    Fournisseur de ressources Category Un B C
    Service 1 AuditLogs x1 y1 z1
    Service 1 AuditLogs x5 y5 z5
    ...

  • Table Service1ErrorLogs

    Fournisseur de ressources Category D E F
    Service 1 ErrorLogs q1 w1 e1
    Service 1 ErrorLogs q2 w2 e2
    ...

  • Table Service2AuditLogs

    Fournisseur de ressources Category G H I
    Service 2 AuditLogs j1 k1 l1
    Service 2 AuditLogs j3 k3 l3
    ...

Mode Diagnostics Azure

Dans ce mode, toutes les données, quel que soit le paramètre de diagnostic, sont collectées dans la table AzureDiagnostics. La plupart des services Azure utilisent actuellement cette méthode héritée. 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.

Prenons un exemple dans lequel des paramètres de diagnostic sont collectés dans le même espace de travail pour les types de données suivants :

  • Les journaux d’audit du service 1 ont un schéma constitué des colonnes A, B et C.
  • Les journaux des erreurs du service 1 ont un schéma constitué des colonnes D, E et F.
  • Les journaux d’audit du service 2 ont un schéma constitué des colonnes G, H et I.

La table AzureDiagnostics ressemble à l’exemple suivant :

ResourceProvider Category Un B C D E F G H I
Microsoft.Service1 AuditLogs x1 y1 z1
Microsoft.Service1 ErrorLogs q1 w1 e1
Microsoft.Service2 AuditLogs j1 k1 l1
Microsoft.Service1 ErrorLogs q2 w2 e2
Microsoft.Service2 AuditLogs j3 k3 l3
Microsoft.Service1 AuditLogs x5 y5 z5
...

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.

Screenshot that shows the Diagnostics settings mode selector.

Remarque

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/00000000-0000-0000-0000-000000000000/RESOURCEGROUPS/JOHNKEMTEST/PROVIDERS/MICROSOFT.LOGIC/WORKFLOWS/JOHNKEMTESTLA",
            "resourceId": "/SUBSCRIPTIONS/00000000-0000-0000-0000-000000000000/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": "00000000-0000-0000-0000-000000000000",
                    "resourceGroupName": "JohnKemTest",
                    "workflowId": "243aac67fe904cf195d4a28297803785",
                    "workflowName": "JohnKemTestLA",
                    "runId": "08587330013509921957",
                    "location": "westus",
                    "actionName": "Send_email"
                },
                "correlation": {
                    "actionTrackingId": "29a9862f-969b-4c70-90c4-dfbdc814e413",
                    "clientTrackingId": "08587330013509921958"
                }
            }
        },
        {
            "time": "2019-07-15T18:01:15.7532989Z",
            "workflowId": "/SUBSCRIPTIONS/00000000-0000-0000-0000-000000000000/RESOURCEGROUPS/JOHNKEMTEST/PROVIDERS/MICROSOFT.LOGIC/WORKFLOWS/JOHNKEMTESTLA",
            "resourceId": "/SUBSCRIPTIONS/00000000-0000-0000-0000-000000000000/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": "00000000-0000-0000-0000-000000000000",
                    "resourceGroupName": "JohnKemTest",
                    "workflowId": "243aac67fe904cf195d4a28297803785",
                    "workflowName": "JohnKemTestLA",
                    "runId": "08587330012106702630",
                    "location": "westus",
                    "actionName": "Send_email"
                },
                "correlation": {
                    "actionTrackingId": "042fb72c-7bd4-439e-89eb-3cf4409d429e",
                    "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.

Notes

Une autre stratégie d’archivage consiste à envoyer le journal des ressources à un espace de travail Log Analytics avec une stratégie d’archivage.

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/00000000-0000-0000-0000-000000000000/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": "46cdbb41-cb9c-4f3d-a5b4-1d458d827ff1","category": "NetworkSecurityGroupRuleCounter","resourceId": "/SUBSCRIPTIONS/s1id1234-5679-0123-4567-890123456789/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/ s1id1234-5679-0123-4567-890123456789/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.

Étapes suivantes