Créer des paramètres de diagnostic dans Azure Monitor

Article
10/31/2023

Créez et modifiez des paramètres de diagnostic dans Azure Monitor pour envoyer des journaux et métriques de plateforme Azure vers différentes destinations telles que les journaux d’activité Azure Monitor, le stockage Azure ou Azure Event Hubs. Vous pouvez vous aider de différentes méthodes pour utiliser les paramètres de diagnostic, tels que le Portail Azure, Azure CLI, PowerShell et Azure Resource Manager.

Important

La stratégie de rétention définie dans les paramètres de diagnostic est désormais déconseillée et ne peut plus être utilisée. Utilisez la Stratégie de cycle de vie du stockage Azure pour gérer la durée de conservation de vos journaux. Pour plus d’informations, consultez Migrer la rétention du stockage des paramètres de diagnostic vers la gestion de cycle de vie du Stockage Azure

Vous pouvez configurer des paramètres de diagnostic sur le portail Azure à partir du menu Azure Monitor ou du menu de la ressource.

L’endroit où vous configurez les paramètres de diagnostic dans le portail Azure dépend de la ressource :
- Pour une ressource unique, cliquez sur Paramètres de diagnostic sous Analyse dans le menu de la ressource.
- Pour une ou plusieurs ressources, dans le menu Azure Monitor, sous Paramètres, sélectionnez Paramètres de diagnostic, puis la ressource.
- Pour le journal d’activité, dans le menu Azure Monitor, cliquez sur Journal d’activité, puis sur Exporter les journaux d’activité. Veillez à désactiver toute configuration héritée pour le journal d’activité. Pour obtenir des instructions, consultez Désactiver les paramètres existants.
S’il n’existe aucun paramètre sur la ressource que vous sélectionnez, vous êtes invité à créer un paramètre. Sélectionnez Ajouter le paramètre de diagnostic.

Si des paramètres sont définis pour la ressource, la liste des paramètres déjà configurés s’affiche. Pour ajouter de nouveaux paramètres, sélectionnez Ajouter un paramètre de diagnostic. Vous pouvez également sélectionner Modifier le paramètre pour modifier un paramètre existant. Chaque paramètre ne peut pas avoir plus d’un type de destination.
Si votre paramètre n’a pas de nom, nommez-le.
Journaux et métriques à router : pour les journaux, choisissez un groupe de catégories ou cochez la case de chaque catégorie de données que vous souhaitez envoyer aux destinations spécifiées plus tard. La liste des catégories varie pour chaque service Azure. Choisissez AllMetrics si vous souhaitez aussi stocker les métriques dans des journaux Azure Monitor.
Détails de la destination : activez la case à cocher pour chaque destination. Les options s’affichent pour que vous puissiez ajouter plus d’informations.
1. envoyer à l’espace de travail Log Analytics: sélectionnez votre abonnement et l’espace de travail Log Analytics où vous souhaitez envoyer les données. Si vous n’avez pas d’espace de travail, vous devez en créer un avant de continuer.
2. Archiver dans un compte de stockage : sélectionnez votre Abonnement et le Compte de stockage où stocker les données.
  
  Conseil
  
  Utilisez la Stratégie de cycle de vie du stockage Azure pour gérer la durée de conservation de vos journaux. La stratégie de conservation définie dans les paramètres de diagnostic est désormais dépréciée.
3. Stream vers un event Hub: spécifiez les critères suivants :
  - Abonnement : abonnement auquel appartient le hub d’événements.
  - Espace de noms Event Hub : si vous n’en avez pas, vous devez en créer un.
  - Nom Event Hub (facultatif) : nom auquel envoyer toutes les données. Si vous ne spécifiez pas de nom, un hub d’événements est créé pour chaque catégorie de journal. Si vous envoyez plusieurs catégories, vous pouvez spécifier un nom pour limiter le nombre de hubs d’événements créés. Pour plus d’informations, consultez Quotas et limites Azure Event Hubs.
  - Nom de la stratégie Event Hub (aussi facultatif) : une stratégie définit les autorisations dont dispose le mécanisme de diffusion en continu. Pour plus d’informations, consultez Fonctionnalités Event Hubs.
4. Envoyer à la solution partenaire: vous devez d’abord installer Azure Native ISV Services dans votre abonnement. Les options de configuration varient selon le partenaire. Pour plus d’informations, consultez Vue d’ensemble d’Azure Native ISV Services.
Si le service prend en charge le mode spécifique à la ressource et diagnostics Azure, une option permettant de sélectionner la table de destination s’affiche lorsque vous sélectionnez l’espace de travail Log Analytics comme destination. Vous devez généralement sélectionner spécifique à une ressource, car la structure de la table offre plus de flexibilité et des requêtes plus efficaces.
Sélectionnez Enregistrer.

Après quelques instants, le nouveau paramètre apparaît dans la liste des paramètres pour cette ressource. Les journaux sont diffusés en continu vers les destinations spécifiées, car de nouvelles données d’événement sont générées. Un délai de 15 minutes peut s’écouler entre le moment où un événement est émis et celui où il s’affiche dans un espace de travail Log Analytics.

Pour créer un paramètre de diagnostic avec Azure PowerShell, utilisez l’applet de commande New-AzDiagnosticSetting. Pour obtenir une description des paramètres de celle-ci, consultez sa documentation.

Important

Vous ne pouvez pas utiliser cette méthode pour un journal d’activité. Utilisez plutôt la méthode Créer un paramètre de diagnostic dans Azure Monitor à l’aide d’un modèle Resource Manager pour créer un modèle Resource Manager et le déployer avec PowerShell.

L’exemple de cmdlet PowerShell suivant crée un paramètre de diagnostic pour l’ensemble des journaux d’activité, ou pour les journal d’audit, et des métriques d’un coffre de clés en utilisant un espace de travail Log Analytics.

$KV= Get-AzKeyVault -ResourceGroupName <resource group name> -VaultName <key vault name>
$Law= Get-AzOperationalInsightsWorkspace -ResourceGroupName <resource group name> -Name <workspace name>  #LAW name is case sensitive

$metric = @()
$log = @()
$metric += New-AzDiagnosticSettingMetricSettingsObject -Enabled $true -Category AllMetrics
# For all available logs, use:
$log = New-AzDiagnosticSettingLogSettingsObject -Enabled $true -CategoryGroup allLogs  
# or, for audit logs, use:
$log = New-AzDiagnosticSettingLogSettingsObject -Enabled $true -CategoryGroup audit    
New-AzDiagnosticSetting -Name 'KeyVault-Diagnostics' -ResourceId $KV.ResourceId -WorkspaceId $Law.ResourceId -Log $log -Metric $metric -Verbose

Pour créer un paramètre de diagnostic avec Azure CLI, utilisez la commande az monitor diagnostic-settings create. Pour une description des paramètres de cette commande, consultez sa documentation.

Important

L’exemple de commande suivant crée un paramètre de diagnostic utilisant les trois destinations. La syntaxe est légèrement différente en fonction de votre client.

Pour spécifier le mode spécifique à la ressource si le service le prend en charge, ajoutez le paramètre export-to-resource-specific avec la valeur true.`

az monitor diagnostic-settings create  \
--name KeyVault-Diagnostics \
--resource /subscriptions/<subscription ID>/resourceGroups/<resource group name>/providers/Microsoft.KeyVault/vaults/mykeyvault \
--logs    '[{"category": "AuditEvent","enabled": true}]' \
--metrics '[{"category": "AllMetrics","enabled": true}]' \
--storage-account /subscriptions/<subscription ID>/resourceGroups/<resource group name>/providers/Microsoft.Storage/storageAccounts/<storage account name> \
--workspace /subscriptions/<subscription ID>/resourcegroups/<resource group name>/providers/microsoft.operationalinsights/workspaces/<log analytics workspace name> \
--event-hub-rule /subscriptions/<subscription ID>/resourceGroups/<resource group name>/providers/Microsoft.EventHub/namespaces/<event hub namespace>/authorizationrules/RootManageSharedAccessKey \
--event-hub <event hub name> \
--export-to-resource-specific true

Le modèle JSON suivant fournit un exemple de création d’un paramètre de diagnostic pour envoyer tous les journaux d’audit à un espace de travail Log Analytics. N’oubliez pas que apiVersion peut changer en fonction de la ressource dans l’étendue.

Fichier de modèle

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "scope": {
        "type": "string"
    },
    "workspaceId": {
        "type": "string"
    },
    "settingName": {
        "type": "string"
    }
},
  "resources": [
    {
      "type": "Microsoft.Insights/diagnosticSettings",
      "apiVersion": "2021-05-01-preview",
      "scope": "[parameters('scope')]",
      "name": "[parameters('settingName')]",
      "properties": {
       "workspaceId": "[parameters('workspaceId')]",
      "logs": [
             {
            "category": null,
            "categoryGroup": "audit",
            "enabled": true
          }
        ]
      }
    }
  ]
  }

Fichier de paramètres

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "settingName": {
        "value": "audit3"
    },
    "workspaceId": {
      "value": "/subscriptions/<subscription id>/resourcegroups/<resourcegroup name>/providers/microsoft.operationalinsights/workspaces/<workspace name>"
    },
    "scope": {
      "value": "Microsoft.<resource type>/<resourceName>"
    }
  }
}

Résolution des problèmes

Voici quelques conseils pour la résolution de ce problème.

La catégorie de métrique n’est pas prise en charge

Quand vous déployez un paramètre de diagnostic, vous recevez un message d’erreur du type « La catégorie de métrique ’xxxx’ n’est pas prise en charge ». Vous pouvez voir cette erreur même si votre déploiement précédent a réussi.

Le problème se produit lors de l’utilisation d’un modèle Resource Manager, de l’API REST, de la CLI ou d’Azure PowerShell. Les paramètres de diagnostic créés via le portail Azure ne sont pas affectés, car seuls les noms des catégories prises en charge sont présentés.

Le problème est dû à une modification récente de l’API sous-jacente. Les catégories de métriques autres que AllMetrics ne sont pas prises en charge et ne l’ont jamais été, à l’exception de quelques services Azure spécifiques. Par le passé, les autres noms de catégorie étaient ignorés lors du déploiement d’un paramètre de diagnostic. Le backend Azure Monitor redirigeait ces catégories vers AllMetrics. À compter de février 2021, le back-end a été mis à jour et vérifie maintenant spécifiquement que la catégorie de métriques fournie est exacte. Ce changement a entraîné l’échec de certains déploiements.

Si vous recevez cette erreur, mettez à jour vos déploiements en y remplaçant tous les noms de catégories de métriques par AllMetrics pour résoudre le problème. Si le déploiement cumulait déjà plusieurs catégories, une seule catégorie avec la référence AllMetrics doit être conservée. Si le problème persiste, contactez le support Azure sur le Portail Azure.

Le paramètre disparaît en raison de la présence de caractères non ASCII dans resourceID

Les paramètres de diagnostic ne prennent pas en charge les ID de ressource avec des caractères non ASCII. Par exemple, considérez le terme « Preproducción ». Comme il n’est pas possible de renommer des ressources dans Azure, la seule option consiste donc à créer une nouvelle ressource sans caractères non ASCII. Si les caractères se trouvent dans le nom d’un groupe de ressources, vous pouvez déplacer les ressources dans un nouveau groupe. Sinon, vous devez recréer la ressource.

Possibilité de données dupliquées ou supprimées

Chaque effort est fait pour garantir que toutes les données de journal sont envoyées correctement à vos destinations, mais il n’est pas possible de garantir un transfert de données de 100 % des journaux entre les points de terminaison. Les nouvelles tentatives et d’autres mécanismes sont en place pour contourner ces problèmes et tenter de garantir que les données de journal arrivent au point de terminaison.

Créer des paramètres de diagnostic dans Azure Monitor

Résolution des problèmes

La catégorie de métrique n’est pas prise en charge

Le paramètre disparaît en raison de la présence de caractères non ASCII dans resourceID

Possibilité de données dupliquées ou supprimées

Étapes suivantes

Ressources supplémentaires