Groupes d’actions

2025-02-13

Lorsque les données Azure Monitor indiquent qu’il peut y avoir un problème avec votre infrastructure ou votre application, une alerte est déclenchée. Vous pouvez utiliser un groupe d’actions pour envoyer une notification telle qu’un appel vocal, un SMS, un push ou un e-mail lorsque l’alerte est déclenchée en plus de l’alerte elle-même. Un groupe d’actions est une collection de préférences en matière d’actions ou de notifications. Azure Monitor, Azure Service Health et Azure Advisor se servent des groupes d’actions pour notifier les utilisateurs à propos de l’alerte et effectuer une action. Cet article vous indique comment créer et gérer les groupes d’actions.

Chaque action se compose des éléments suivants :

Type : notification envoyée ou action effectuée. Par exemple, l’envoi d’un appel vocal, d’un SMS ou d’un e-mail. Vous pouvez également déclencher différents types d’actions automatisées.
Name : identificateur unique au sein du groupe d’actions.
Détails :détails correspondants qui varient selon le type.

En général, un groupe d’actions est un service mondial. Nous nous efforçons actuellement de les rendre davantage disponibles à l’échelon régional.

Les demandes en provenance des clients du monde entier peuvent être traitées par les services de groupe d’actions de n’importe quelle région. Si une région du service de groupe d’actions est indisponible, le trafic est automatiquement routé et traité dans d’autres régions. En tant que service global, un groupe d’actions permet de fournir une solution de récupération d’urgence. Les demandes régionales s’appuient sur la redondance de zone de disponibilité pour répondre aux exigences de confidentialité et offrir une solution de reprise d’activité similaire.

Vous pouvez ajouter jusqu’à cinq groupes d’actions à une règle d’alerte.
Les groupes d’actions sont exécutés simultanément, sans ordre spécifique.
Plusieurs règles d’alerte peuvent utiliser le même groupe d’actions.
Les groupes d’actions sont définis par l’ensemble unique d’actions et les utilisateurs à avertir. Par exemple, si vous souhaitez notifier l’utilisateur(-trice) 1, l’utilisateur(-trice) 2 et l’utilisateur(-trice) 3 par e-mail pour deux règles d’alerte différentes, vous ne devez créer qu’un seul groupe d’action que vous pouvez appliquer aux deux règles d’alerte.

Créer un groupe d’actions sur le portail Azure

Accédez au portail Azure.
Recherchez et sélectionnez Moniteur. Le volet Moniteur consolide tous vos paramètres et données de supervision dans une même vue.
Sélectionnez Alertes, puis Groupes d’actions.
Sélectionnez Create (Créer).

Configurez les paramètres de base du groupe d’actions. Dans la section Détails du projet :

Sélectionnez les valeurs pour Abonnement et Groupe de ressources.
Sélectionnez la région.

Remarque

Les alertes de fonctionnement des services sont uniquement prises en charge dans les clouds publics dans la région mondiale. Pour que les groupes d’actions fonctionnent correctement en réponse à une alerte d’intégrité du service, la région du groupe d’actions doit être définie comme Globale.

Choix	Comportement
Mondial	Le service des groupes d’actions détermine l’emplacement où le groupe d’actions doit être stocké. Le groupe d’actions est conservé dans au moins deux régions pour garantir la résilience régionale. Les actions peuvent être traitées dans n’importe quelle zone géographique. Les actions vocales, par SMS et par e-mail effectuées à la suite d’alertes d’intégrité du service sont résilientes aux incidents en direct sur Azure.
Régional	Le groupe d’actions est stocké dans la région sélectionnée. Le groupe d’actions est redondant interzone. Utilisez cette option si vous souhaitez vous assurer que le traitement de votre groupe d’actions soit effectué dans une limite géographique spécifique. Vous pouvez sélectionner l’une de ces régions pour le traitement régional des groupes d’actions : • USA Est • USA Ouest • Est des États-Unis 2 • USA Ouest2 • USA Centre Sud • USA Centre Nord • Suède Centre • Allemagne Centre-Ouest • Inde Centre • Inde Sud Nous ajoutons continuellement d’autres régions pour le traitement des données régionales des groupes d’actions.

Choix

Comportement

Mondial

Le service des groupes d’actions détermine l’emplacement où le groupe d’actions doit être stocké. Le groupe d’actions est conservé dans au moins deux régions pour garantir la résilience régionale. Les actions peuvent être traitées dans n’importe quelle zone géographique.

Les actions vocales, par SMS et par e-mail effectuées à la suite d’alertes d’intégrité du service sont résilientes aux incidents en direct sur Azure.

Régional

Le groupe d’actions est stocké dans la région sélectionnée. Le groupe d’actions est redondant interzone. Utilisez cette option si vous souhaitez vous assurer que le traitement de votre groupe d’actions soit effectué dans une limite géographique spécifique.

Vous pouvez sélectionner l’une de ces régions pour le traitement régional des groupes d’actions :
• USA Est
• USA Ouest
• Est des États-Unis 2
• USA Ouest2
• USA Centre Sud
• USA Centre Nord
• Suède Centre
• Allemagne Centre-Ouest
• Inde Centre
• Inde Sud

Nous ajoutons continuellement d’autres régions pour le traitement des données régionales des groupes d’actions.

Le groupe d’actions est enregistré dans l’abonnement, la région et le groupe de ressources que vous sélectionnez.

Dans la section Détails de l’instance, entrez des valeurs dans Nom du groupe d’actions et Nom d’affichage. Le nom d’affichage est utilisé à la place du nom complet du groupe d’actions lorsque le groupe est utilisé pour envoyer des notifications.
configurer les notifications. Sélectionnez Suivant : Notifications ou bien l’onglet Notifications dans la partie supérieure de la page.
Définissez une liste de notifications à envoyer quand une alerte est déclenchée.

Pour chaque notification :

Sélectionnez le Type de notification, puis complétez les champs appropriés pour cette notification. Options disponibles :

Type de notification	Descriptif	Champs
Envoyer un e-mail au rôle Azure Resource Manager	Envoyez un e-mail aux membres de l’abonnement, en fonction de leur rôle. Consultez E-mail.	Entrez l’adresse e-mail principale configurée pour l’utilisateur Microsoft Entra. Consultez E-mail.
Messagerie électronique	Assurez-vous que votre filtrage d’e-mail et tous les services de prévention contre les programmes malveillants et le courrier indésirable sont correctement configurés. Les e-mails sont envoyés à partir des adresses e-mail suivantes : • azure-noreply@microsoft.com • azureemail-noreply@microsoft.com • alerts-noreply@mail.windowsazure.com	Entrez l’adresse e-mail à laquelle la notification doit être envoyée.
sms	Les notifications par SMS prennent en charge la communication bidirectionnelle. Ce SMS contient les informations suivantes : • Nom court du groupe d’actions auquel cette alerte a été envoyée • Titre de l’alerte. Un utilisateur peut répondre à un SMS pour : • Désinscrivez-vous de toutes les alertes SMS pour tous les groupes d’actions ou un seul groupe d’actions. • Réinscrire aux alertes • Demander de l’aide. Pour plus d’informations sur les réponses aux SMS prises en charge, consultez Réponses aux SMS.	Entrez le Code pays et le Numéro de téléphone du destinataire des SMS. Si vous ne pouvez pas sélectionner le code de votre pays/région dans le Portail Azure, cela signifie que les SMS ne sont pas pris en charge pour votre pays/région. Si votre indicatif de pays/région n’est pas disponible, vous pouvez voter pour que votre pays/région soit ajouté sur Partagez vos idées. En attendant que votre pays soit pris en charge, une solution de contournement consiste à configurer le groupe d’actions de sorte qu’il appelle un webhook de fournisseur de SMS tiers qui prend en charge votre pays/région.
Notifications Push d’application Azure	Envoyez des notifications à l’application mobile Azure.	Dans le champ Adresse e-mail du compte Azure, entrez l’adresse e-mail que vous utilisez comme ID de compte au moment de configurer Azure mobile app.
Voix	Notification vocale.	Entrez le Code pays et le Numéro de téléphone du destinataire de la notification. Si vous ne pouvez pas sélectionner le code de votre pays/région sur le portail Azure, cela signifie que les notifications vocales ne sont pas prises en charge pour votre pays/région. Si votre indicatif de pays/région n’est pas disponible, vous pouvez voter pour que votre pays/région soit ajouté sur Partagez vos idées. En attendant que votre pays soit pris en charge, configurez le groupe d'actions pour qu'il utilise un webhook d'un fournisseur tiers d'appels vocaux qui prend en charge votre pays/région.

Si vous le souhaitez, activez le Schéma d’alerte commun. Le schéma d’alerte commun est une charge utile d’alerte extensible et unifiée unique qui peut être utilisée dans tous les services d’alerte d’Azure Monitor. Pour plus d’informations sur le schéma commun, consultez Schéma d’alerte commun.
Sélectionnez OK.

Configurez des actions. Sélectionnez Suivant : Actions. ou sélectionnez l’onglet Actions en haut de la page.

Définissez une liste d’actions à déclencher quand une alerte est déclenchée. Sélectionnez un type d’action et attribuez un nom à chaque action.

Type d'action	Détails
Runbook Automation	Utilisez Automation Runbook pour automatiser les tâches en fonction des métriques. Par exemple, arrêtez les ressources lorsqu’un certain seuil est atteint dans le budget associé. Pour des informations sur les limites des charges utiles du runbook Automation, consultez Limites d’Automation.
Hubs d'événements	Une action Event Hubs publie des notifications sur Event Hubs. Il s’agit du seul type d’action qui prend en charge Azure Private Link et le périmètre de sécurité réseau (NSP). Pour plus d’informations sur Event Hubs, consultez Azure Event Hubs : une plateforme de streaming Big Data et un service d’ingestion d’événements. Vous pouvez vous abonner au flux de notification d’alerte à partir de votre récepteur d’événements.
Fonctions	Appelle un point de terminaison de déclencheur HTTP existant dans des fonctions. Pour plus d’informations, consultez Azure Functions. Lorsque vous définissez l’action de la fonction, le point de terminaison du déclencheur HTTP de la fonction et la clé d’accès sont enregistrés dans la définition de l’action, par exemple `https://azfunctionurl.azurewebsites.net/api/httptrigger?code=<access_key>`. Si vous modifiez la clé d’accès de la fonction, vous devez supprimer et recréer l’action de la fonction dans le groupe d’actions. Votre point de terminaison doit prendre en charge la méthode HTTP POST. La fonction doit avoir accès au compte de stockage. Si elle n’y a pas accès, les clés ne sont pas disponibles et l’URI de la fonction n’est pas accessible. En savoir plus sur la restauration de l’accès au compte de stockage.
Gestion des services informatiques (ITSM)	Une action ITSM requiert une connexion ITSM. Pour savoir comment créer une connexion ITSM, consultez Intégration ITSM.
Applications logiques	Vous pouvez utiliser Azure Logic Apps pour créer et personnaliser des workflows d’intégration et personnaliser vos notifications d’alerte.
Webhook sécurisé	Lorsque vous utilisez une action de webhook sécurisé, vous devez utiliser Microsoft Entra ID pour sécuriser la connexion entre votre groupe d’actions et votre point de terminaison, qui est une API web protégée. Consultez Configurer l’authentification pour un webhook sécurisé. Un webhook sécurisé ne prend pas en charge l’authentification de base. Si vous utilisez l’authentification de base, utilisez l’action Webhook.
Webhook	Si vous utilisez l’action webhook, votre point de terminaison de webhook cible doit être en mesure de traiter les différentes charges utiles JSON émises par différentes sources d’alerte. Vous ne pouvez pas passer des certificats de sécurité via une action de webhook. Pour utiliser l’authentification de base, vous devez transmettre vos informations d’identification par l’URI. Si le point de terminaison du webhook attend un schéma spécifique, par exemple le schéma Microsoft Teams, utilisez le type d’action Logic Apps pour manipuler le schéma d’alerte de sorte qu’il réponde aux attentes du webhook cible. Pour plus d’informations sur les règles utilisées pour tenter de nouveau des actions de webhook, consultez Webhook.

Capture d’écran montrant l’onglet Actions dans la boîte de dialogue Créer un groupe d’actions. Plusieurs options sont visibles dans la liste Type d’action.

(Facultatif) Si vous souhaitez affecter une paire clé-valeur au groupe d’actions pour catégoriser vos ressources Azure, sélectionnez Suivant : Balises ou onglet Balises . Sinon, ignorez cette étape.
Sélectionnez Vérifier + créer pour passer en revue vos paramètres. Cette étape vérifie rapidement vos entrées pour vous assurer que vous avez entré toutes les informations requises. En cas de problème, ceux-ci sont signalés ici. Après avoir examiné les paramètres, sélectionnez Créer pour créer le groupe d’actions.

Remarque

Lorsque vous configurez une action pour notifier une personne par e-mail ou SMS, cette personne reçoit une confirmation indiquant qu’elle a été ajoutée au groupe d’actions.

Tester un groupe d’actions sur le portail Azure

Au moment de créer ou de mettre à jour un groupe d’actions sur le Portail Azure, vous pouvez tester le groupe d’actions.

Créez un groupe d’actions sur le portail Azure.

Remarque

Le groupe d’actions doit être créé et enregistré avant le test. Si vous modifiez un groupe d’actions existant, enregistrez les modifications apportées au groupe d’actions avant d’effectuer le test.
Dans la page du groupe d’actions, sélectionnez Test.
Sélectionnez le type d’échantillon et les types de notifications et d’actions que vous souhaitez tester. Puis sélectionnez Test.
Si vous fermez la fenêtre ou sélectionnez Retour pour tester l’installation pendant que le test est en cours d’exécution, le test s’arrête et vous n’obtenez pas les résultats du test.
Une fois le test terminé, un état de test de Réussite ou d’Échec s’affiche. Si le test a échoué et que vous voulez obtenir plus d’informations, sélectionnez Afficher les détails.

Vous pouvez utiliser les informations de la section Détails de l’erreur pour comprendre le problème. Vous pouvez ensuite modifier, enregistrer les modifications et tester à nouveau le groupe d’actions.

Lorsque vous exécutez un test et sélectionnez un type de notification, vous recevez un message avec « Test » dans l’objet. Les tests fournissent un moyen de vérifier que votre groupe d’actions fonctionne comme prévu avant de l’activer dans un environnement de production. Tous les détails et les liens des notifications de test par e-mail proviennent d'un ensemble de référence d'exemple.

Exigences de rôles pour les groupes d’actions de test

Le tableau suivant décrit les exigences d’appartenance aux rôles nécessaires pour la fonctionnalité des actions de test :

Appartenance au rôle	Groupe d’actions existant	Groupe de ressources existant et nouveau groupe d’actions	Nouveau groupe de ressources et nouveau groupe d’actions
Collaborateur de l’abonnement	Pris en charge	Pris en charge	Pris en charge
Contributeur du groupe de ressources	Pris en charge	Pris en charge	Non applicable
Contributeur aux ressources du groupe d’actions	Pris en charge	Non applicable	Non applicable
Contributeur Azure Monitor	Pris en charge	Pris en charge	Non applicable
Rôle personnalisé ¹	Pris en charge	Pris en charge	Non applicable

¹ Le rôle personnalisé doit avoir l’autorisation Microsoft.Insights/ActionGroups/* ajoutée, ce qui permettra également à l’utilisateur de mettre à jour et de supprimer le groupe d’actions. Pour ajouter des restrictions afin que l’utilisateur puisse uniquement tester le groupe d’actions, ajoutez ce qui suit sous l’onglet JSON pour le rôle personnalisé :

{
    "properties": {
        "roleName": "",
        "description": "",
        "assignableScopes": [
            "/subscriptions/{subscription-id}/resourceGroups/{resource-group-name}"
        ],
        "permissions": [
            {
                "actions": [
                    "Microsoft.Insights/ActionGroups/*"
                ],
                "notActions": [
                    "Microsoft.Insights/ActionGroups/write",
                    "Microsoft.Insights/ActionGroups/delete"
                ],
                "dataActions": [],
                "notDataActions": []
            }
        ]
    }
}

Remarque

Vous pouvez exécuter un nombre limité de tests par période. Pour vérifier les limites qui s’appliquent dans votre cas, consultez Limites du service Azure Monitor.
Lorsque vous configurez un groupe d’actions dans le portail, vous pouvez refuser ou désactiver le schéma d’alerte commun.
- Pour rechercher des exemples de schémas communs pour tous les types d’exemples, consultez Définitions de schéma d’alerte commun pour le groupe d’actions de test.
- Pour rechercher des définitions d’alerte de schéma non commun, consultez les définitions de schéma d’alerte non commun pour le Groupe d'actions de test.

Créer un groupe d’actions avec un modèle Resource Manager

Vous pouvez utiliser un modèle Azure Resource Manager pour configurer les groupes d’action. À l’aide de modèles, vous pouvez configurer automatiquement des groupes d’actions qui peuvent être réutilisés dans certains types d’alertes. Ces groupes d’actions vous assurent que toutes les parties concernées sont averties lorsqu’une alerte est déclenchée.

Étapes élémentaires :

Créez un modèle sous la forme d’un fichier JSON qui décrit comment créer le groupe d’actions.
Déployez le modèle à l’aide de n’importe quelle méthode de déploiement.

Modèles Resource Manager de groupe d’actions

Pour créer un groupe d’actions à l’aide d’un modèle Resource Manager, vous créez une ressource de type Microsoft.Insights/actionGroups. Puis, renseignez toutes les propriétés associées. Voici deux exemples de modèles qui créent un groupe d’actions.

Le premier modèle vous explique comment créer un modèle Resource Manager pour un groupe d’actions où les définitions d’action sont codées de manière irréversible dans le modèle. Le second modèle vous décrit comment créer un modèle qui utilise les informations de configuration du webhook comme paramètres d’entrée lorsque le modèle est déployé.

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "actionGroupName": {
      "type": "string",
      "metadata": {
        "description": "Unique name (within the Resource Group) for the Action group."
      }
    },
    "actionGroupShortName": {
      "type": "string",
      "metadata": {
        "description": "Short name (maximum 12 characters) for the Action group."
      }
    }
  },
  "resources": [
    {
      "type": "Microsoft.Insights/actionGroups",
      "apiVersion": "2021-09-01",
      "name": "[parameters('actionGroupName')]",
      "location": "Global",
      "properties": {
        "groupShortName": "[parameters('actionGroupShortName')]",
        "enabled": true,
        "smsReceivers": [
          {
            "name": "contosoSMS",
            "countryCode": "1",
            "phoneNumber": "5555551212"
          },
          {
            "name": "contosoSMS2",
            "countryCode": "1",
            "phoneNumber": "5555552121"
          }
        ],
        "emailReceivers": [
          {
            "name": "contosoEmail",
            "emailAddress": "devops@contoso.com",
            "useCommonAlertSchema": true

          },
          {
            "name": "contosoEmail2",
            "emailAddress": "devops2@contoso.com",
            "useCommonAlertSchema": true
          }
        ],
        "webhookReceivers": [
          {
            "name": "contosoHook",
            "serviceUri": "http://requestb.in/1bq62iu1",
            "useCommonAlertSchema": true
          },
          {
            "name": "contosoHook2",
            "serviceUri": "http://requestb.in/1bq62iu2",
            "useCommonAlertSchema": true
          }
        ],
         "SecurewebhookReceivers": [
          {
            "name": "contososecureHook",
            "serviceUri": "http://requestb.in/1bq63iu1",
            "useCommonAlertSchema": false
          },
          {
            "name": "contososecureHook2",
            "serviceUri": "http://requestb.in/1bq63iu2",
            "useCommonAlertSchema": false
          }
        ],
        "eventHubReceivers": [
          {
            "name": "contosoeventhub1",
            "subscriptionId": "replace with subscription id GUID",
            "eventHubNameSpace": "contosoeventHubNameSpace",
            "eventHubName": "contosoeventHub",
            "useCommonAlertSchema": true
          }
        ]
      }
    }
  ],
  "outputs":{
      "actionGroupId":{
          "type":"string",
          "value":"[resourceId('Microsoft.Insights/actionGroups',parameters('actionGroupName'))]"
      }
  }
}

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "actionGroupName": {
      "type": "string",
      "metadata": {
        "description": "Unique name (within the Resource Group) for the Action group."
      }
    },
    "actionGroupShortName": {
      "type": "string",
      "metadata": {
        "description": "Short name (maximum 12 characters) for the Action group."
      }
    },
    "webhookReceiverName": {
      "type": "string",
      "metadata": {
        "description": "Webhook receiver service Name."
      }
    },    
    "webhookServiceUri": {
      "type": "string",
      "metadata": {
        "description": "Webhook receiver service URI."
      }
    }    
  },
  "resources": [
    {
      "type": "Microsoft.Insights/actionGroups",
      "apiVersion": "2021-09-01",
      "name": "[parameters('actionGroupName')]",
      "location": "Global",
      "properties": {
        "groupShortName": "[parameters('actionGroupShortName')]",
        "enabled": true,
        "smsReceivers": [
        ],
        "emailReceivers": [
        ],
        "webhookReceivers": [
          {
            "name": "[parameters('webhookReceiverName')]",
            "serviceUri": "[parameters('webhookServiceUri')]",
            "useCommonAlertSchema": true
          }
        ]
      }
    }
  ],
  "outputs":{
      "actionGroupResourceId":{
          "type":"string",
          "value":"[resourceId('Microsoft.Insights/actionGroups',parameters('actionGroupName'))]"
      }
  }
}

Gérer les groupes d’actions

Après avoir créé un groupe d’actions, vous pouvez l’afficher dans le portail :

Accédez au portail Azure.
Dans la page Surveiller, sélectionnez Alertes.
Sélectionnez Groupes d’actions.
Sélectionnez le groupe d’actions que vous souhaitez gérer. Vous pouvez :
- Ajouter, modifier ou supprimer des actions.
- Supprimer le groupe d’actions.

Limites de service pour les notifications

Un numéro de téléphone ou une adresse de messagerie peuvent être inclus dans des groupes d’actions de divers abonnements. Azure Monitor utilise la limitation du débit pour suspendre les notifications lorsque trop de notifications sont envoyées à un numéro de téléphone, une adresse e-mail ou un appareil particulier. La limitation du débit garantit que les alertes sont faciles à gérer et exploitables.

La limitation du débit s’applique aux notifications sms, vocales, push et par e-mail. Toutes les autres actions de notification ne sont pas soumises à la limitation de débit. La limitation de la fréquence s’applique à tous les abonnements, La limitation de débit s’applique dès lors que le seuil est atteint, même si les messages sont envoyés à partir de plusieurs abonnements. Lorsqu’une adresse e-mail est soumise à la limitation de débit, une notification est envoyée pour indiquer que la limitation de débit a été appliquée et à quel moment elle arrivera à expiration.

Pour plus d’informations sur les limites de débit, consultez Limites du service Azure Monitor.

Envoyer un message au Azure Resource Manager

Lorsque vous utilisez le gestionnaire de ressources Azure pour les notifications par e-mail, vous pouvez envoyer des e-mails aux membres d'un rôle d'abonnement. L’Email est envoyé aux membres utilisateur ou groupe Microsoft Entra ID du rôle. Cela inclut la prise en charge des rôles attribués via Azure Lighthouse.

Remarque

Les groupes d’actions ne prennent en charge que l'envoi d'e-mails aux rôles suivants : Propriétaire, Contributeur, Lecteur, Contributeur de surveillance, Lecteur de surveillance.

Si votre adresse e-mail principale ne reçoit pas de notifications, configurez l’adresse e-mail pour l’action Envoyer un e-mail au rôle Azure Resource Manager :

Dans le portail Azure, accédez à Microsoft Entra ID.
Sélectionnez Utilisateurs dans le menu de gauche pour afficher une liste de tous les utilisateurs.
Sélectionnez l’utilisateur dont vous voulez consulter l’e-mail principal.
Dans le profil utilisateur sous Propriétés, examinez les informations de contact pour obtenir une valeur e-mail . Si c’est vide :
1. En haut de la page, sélectionnez Modifier les propriétés.
2. Entrez une adresse de messagerie.
3. En haut de la page, sélectionnez Enregistrer.

Vous pouvez avoir un nombre limité d’actions d’e-mail par groupe d’actions. Pour vérifier les limites qui s’appliquent dans votre cas, consultez Limites du service Azure Monitor.

Lorsque vous configurez le rôle Resource Manager :

Affectez une entité de type Utilisateur ou Groupe au rôle.
Effectuez l’attribution au niveau de l’abonnement.
Vérifiez qu’une adresse e-mail est configurée pour l’utilisateur dans son profil Microsoft Entra.

Remarque

La réception de notifications par un client peut prendre jusqu’à 24 heures après l’ajout d’un nouveau rôle Azure Resource Manager à son abonnement.

sms

Vous pouvez avoir un nombre limité d’actions SMS par groupe d’actions.

Pour plus d’informations sur les limites de débit, consultez Limites du service Azure Monitor.
Pour plus d’informations sur l’utilisation de notifications SMS dans des groupes d’actions, consultez le tableau de l’étape 9 dans Créer un groupe d’actions dans le portail Azure.

Remarque

Si vous ne pouvez pas sélectionner le code de votre pays/région dans le Portail Azure, cela signifie que les SMS ne sont pas pris en charge pour votre pays/région. Si votre indicatif de pays/région n’est pas disponible, vous pouvez voter pour que votre pays/région soit ajouté sur Partagez vos idées. En attendant, comme solution de rechange, configurez votre groupe d’actions pour appeler un webhook auprès d’un fournisseur SMS tiers qui offre un support dans votre pays/région.

Réponses aux SMS

Ces réponses sont prises en charge pour les notifications par SMS. Le destinataire des SMS peut répondre aux SMS avec ces valeurs :

RÉPONDRE	Descriptif
DÉSACTIVER `<Action Group Short name>`	Désactive les futurs SMS en provenance du groupe d’actions
ACTIVER `<Action Group Short name>`	Réactive les SMS en provenance du groupe d’actions
ARRÊTER	Désactive les futurs SMS en provenance de tous les groupes d’actions
DÉMARRER	Réactive les SMS à partir de tous les groupes d’actions
AIDE	Une réponse est envoyée à l’utilisateur avec un lien vers cet article.

Remarque

Si un utilisateur s’est désinscrit des alertes SMS et est ensuite ajouté à un nouveau groupe d’actions, il reçoit des alertes SMS pour ce nouveau groupe d’actions, mais reste désinscrit de tous les groupes d’actions précédents.

Vous pouvez avoir un nombre limité d’actions d’application Azure par groupe d’actions.

Pays/régions avec support de notification par SMS

Code pays	Pays
61	Australie
43	Autriche
32	Belgique
55	Brésil
1	Canada
56	Chili
86	Chine
420	République tchèque
45	Danemark
372	Estonie
358	Finlande
33	France
49	Allemagne
852	Région administrative spéciale de Hong Kong
91	Inde
353	Irlande
972	Israël
39	Italie
81	Japon
352	Luxembourg
soixante	Malaisie
52	Mexique
31	Pays-Bas
64	Nouvelle-Zélande
47	Norvège
351	Portugal
1	Porto Rico
40	Roumanie
7	Russie
65	Singapour
27	Afrique du Sud
82	Corée du Sud
34	Espagne
41	Suisse
886	Taïwan
971	Émirats arabes unis
44	Royaume-Uni
1	États-Unis

Voix

Vous pouvez avoir un nombre limité d’actions vocales par groupe d’actions. Pour découvrir plus d’informations sur les limites de débit, consultez Limites du service Azure Monitor.

Remarque

Si vous ne pouvez pas sélectionner le code de votre pays/région dans le Portail Azure, cela signifie que les appels vocaux ne sont pas pris en charge pour votre pays/région. Si votre indicatif de pays/région n’est pas disponible, vous pouvez voter pour que votre pays/région soit ajouté sur Partagez vos idées. En attendant, comme solution de rechange, configurez votre groupe d’actions pour appeler un webhook auprès d’un fournisseur d’appels vocaux tiers qui offre un support dans votre pays/région. Si un pays est marqué avec un astérisque (*), les appels proviennent d’un numéro de téléphone basé aux États-Unis.

Pays/régions avec support de notification vocale

Code pays	Pays
61	Australie
43	Autriche
32	Belgique
55	Brésil
1	Canada
56	Chili
86	Chine*
420	République tchèque
45	Danemark
372	Estonie
358	Finlande
33	France
49	Allemagne
852	Hong Kong (R.A.S.)
91	Inde*
353	Irlande
972	Israël
39	Italie*
81	Japon*
352	Luxembourg
soixante	Malaisie
52	Mexique
31	Pays-Bas
64	Nouvelle-Zélande
47	Norvège
351	Portugal
40	Roumanie*
7	Russie*
65	Singapour
27	Afrique du Sud
82	Corée du Sud
34	Espagne
46	Suède
41	Suisse
886	Taïwan*
971	Émirats arabes unis*
44	Royaume-Uni
1	États-Unis

Pour plus d’informations sur la tarification des pays/régions pris en charge, consultez la tarification Azure Monitor.

Webhook

Remarque

Si vous utilisez l’action webhook, votre point de terminaison de webhook cible doit être en mesure de traiter les différentes charges utiles JSON émises par différentes sources d’alerte. Le point de terminaison de webhook doit également être accessible au public. Vous ne pouvez pas passer des certificats de sécurité via une action de webhook. Pour utiliser l’authentification de base, vous devez transmettre vos informations d’identification par l’URI. Si le point de terminaison du webhook attend un schéma spécifique, par exemple, le schéma Microsoft Teams, utilisez l’action Logic Apps pour transformer le schéma d’alerte afin de répondre aux attentes du webhook cible.

Les groupes d’actions du webhook suivent généralement ces règles lorsqu'ils sont appelés :

Lorsqu’un webhook est appelé, si le premier appel échoue, il est retenté au moins 1 fois plus de temps et jusqu’à 5 fois (5 nouvelles tentatives) à différents intervalles de retard (5, 20, 40 secondes).

Tentatives Retarder

Entre le 1er et le 2e 5 secondes

Entre le 2e et le 3e 20 secondes

Entre le 3e et le 4e 5 secondes

Entre le 4e et le 5e 40 secondes

Entre le 5e et le 6e 5 secondes
Si les tentatives d’appel du webhook échouent, aucun groupe d’actions n’appelle le point de terminaison pendant 15 minutes.
La logique de nouvelle tentative considère que l’appel peut faire l’objet d’une nouvelle tentative. Les codes d’état 408, 429, 503, 504 ou HttpRequestException, WebException autorisent TaskCancellationException de réessayer l’appel.

Tentatives	Retarder
Entre le 1er et le 2e	5 secondes
Entre le 2e et le 3e	20 secondes
Entre le 3e et le 4e	5 secondes
Entre le 4e et le 5e	40 secondes
Entre le 5e et le 6e	5 secondes

Configurer l’authentification pour un webhook sécurisé

L’action de webhook sécurisé s’authentifie auprès de l’API protégée en utilisant une instance de principal de service dans le locataire Microsoft Entra de l’application Microsoft Entra « AZNS AAD Webhook ». Pour que le groupe d’actions fonctionne, ce principal de service de webhook Microsoft Entra doit être ajouté en tant que membre d’un rôle sur l’application Microsoft Entra cible qui accorde l’accès au point de terminaison cible.

Pour obtenir une vue d’ensemble des applications et des principaux de service Microsoft Entra, consultez Présentation de la plateforme d’identités Microsoft (v2.0). Suivez ces étapes pour tirer parti de la fonctionnalité de webhook sécurisée.

Remarque

L’authentification de base n’est pas prise en charge pour SecureWebhook. Pour utiliser l’authentification de base, vous devez utiliser Webhook.

Si vous utilisez l’action webhook, votre point de terminaison de webhook cible doit être en mesure de traiter les différentes charges utiles JSON émises par différentes sources d’alerte. Si le point de terminaison du webhook attend un schéma spécifique, par exemple, le schéma Microsoft Teams, utilisez l’action Logic Apps pour transformer le schéma d’alerte afin de répondre aux attentes du webhook cible.

Remarque

Les modules Azure AD et MSOnline PowerShell seront dépréciés à partir du 30 mars 2024. Pour en savoir plus, consultez la mise à jour de la dépréciation. Passé cette date, la prise en charge de ces modules est limitée à une assistance de migration vers le SDK et les correctifs de sécurité Microsoft Graph PowerShell. Les modules déconseillés continueront de fonctionner jusqu’au 30 mars 2025.

Nous vous recommandons de migrer vers Microsoft Graph PowerShell pour interagir avec Microsoft Entra ID (anciennement Azure AD). Pour explorer les questions courantes sur la migration, reportez-vous au FAQ sur la migration. Remarque : Les versions 1.0.x de MSOnline peuvent connaître une interruption après le 30 juin 2024.

Créez une application Microsoft Entra pour votre API web protégée. Pour plus d’informations, consultez API web protégée : inscription d’application. Configurez votre API protégée pour qu’elle soit appelée par une application démon et exposez les autorisations de l’application, et non les autorisations déléguées.

Remarque

Configurez votre API web protégée pour qu’elle accepte les jetons d’accès V2.0. Pour plus d’informations sur ce paramètre, consultez Manifeste de l’application Microsoft Entra.
Pour permettre au groupe d’actions d’utiliser votre application Microsoft Entra, utilisez le script PowerShell qui suit cette procédure.
Remarque
- Le rôle d’administrateur de l’application Microsoft Entra doit vous être attribué pour exécuter ce script.
- Le principal de service doit être affecté à un rôle propriétaire de l’application Microsoft Entra pour pouvoir créer, modifier ou tester l’action webhook sécurisée dans le groupe d’actions.
Configurez l’action webhook sécurisée.
1. Copiez la valeur $myApp.ObjectId qui se trouve dans le script.
2. Dans la définition d’action webhook, dans la zone ID d’objet, entrez la valeur que vous avez copiée.

Script PowerShell de webhook sécurisé

Remarque

Prérequis : installer le Kit de développement logiciel (SDK) Microsoft Graph PowerShell

Procédure à suivre pour l’exécution

Copiez et collez le script suivant sur votre ordinateur.
Remplacez votre tenantId et le ObjectID dans l'enregistrement de votre application.
Enregistrer sous *.ps1
Ouvrez la commande PowerShell à partir de votre ordinateur et exécutez le script *.ps1 .

Write-Host "================================================================================================="
$scopes = "Application.ReadWrite.All"
$myTenantId = "<<Customer's tenant id>>"
$myMicrosoftEntraAppRegistrationObjectId = "<<Customer's object id from the app registration>>"
$actionGroupRoleName = "ActionGroupsSecureWebhook"
$azureMonitorActionGroupsAppId = "461e8683-5575-4561-ac7f-899cc907d62a" # Required. Do not change.

Connect-MgGraph -Scopes $scopes -TenantId $myTenantId

Function CreateAppRole([string] $Name, [string] $Description)
{
    $appRole = @{
        AllowedMemberTypes = @("Application")
        DisplayName = $Name
        Id = New-Guid
        IsEnabled = $true
        Description = $Description
        Value = $Name
    }
    return $appRole
}

$myApp = Get-MgApplication -ApplicationId $myMicrosoftEntraAppRegistrationObjectId
$myAppRoles = $myApp.AppRoles
$myActionGroupServicePrincipal = Get-MgServicePrincipal -Filter "appId eq '$azureMonitorActionGroupsAppId'"

Write-Host "App Roles before addition of new role.."
foreach ($role in $myAppRoles) { Write-Host $role.Value }

if ($myAppRoles.Value -contains $actionGroupRoleName)
{
    Write-Host "The Action Group role is already defined. No need to redefine.`n"
    # Retrieve the application again to get the updated roles
    $myApp = Get-MgApplication -ApplicationId $myMicrosoftEntraAppRegistrationObjectId
    $myAppRoles = $myApp.AppRoles
}
else
{
    Write-Host "The Action Group role is not defined. Defining the role and adding it."
    $newRole = CreateAppRole -Name $actionGroupRoleName -Description "This is a role for Action Group to join"
    $myAppRoles += $newRole
    Update-MgApplication -ApplicationId $myApp.Id -AppRole $myAppRoles

    # Retrieve the application again to get the updated roles
    $myApp = Get-MgApplication -ApplicationId $myMicrosoftEntraAppRegistrationObjectId
    $myAppRoles = $myApp.AppRoles
}

$myServicePrincipal = Get-MgServicePrincipal -Filter "appId eq '$($myApp.AppId)'"

if ($myActionGroupServicePrincipal.DisplayName -contains "AzNS AAD Webhook")
{
    Write-Host "The Service principal is already defined.`n"
    Write-Host "The action group Service Principal is: " + $myActionGroupServicePrincipal.DisplayName + " and the id is: " + $myActionGroupServicePrincipal.Id
}
else
{
    Write-Host "The Service principal has NOT been defined/created in the tenant.`n"
    $myActionGroupServicePrincipal = New-MgServicePrincipal -AppId $azureMonitorActionGroupsAppId
    Write-Host "The Service Principal is been created successfully, and the id is: " + $myActionGroupServicePrincipal.Id
}

# Check if $myActionGroupServicePrincipal is not $null before trying to access its Id property
# Check if the role assignment already exists
$existingRoleAssignment = Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $myActionGroupServicePrincipal.Id | Where-Object { $_.AppRoleId -eq $myApp.AppRoles[0].Id -and $_.PrincipalId -eq $myActionGroupServicePrincipal.Id -and $_.ResourceId -eq $myServicePrincipal.Id }

# If the role assignment does not exist, create it
if ($null -eq $existingRoleAssignment) {
    Write-Host "Doing app role assignment to the new action group Service Principal`n"
    New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $myActionGroupServicePrincipal.Id -AppRoleId $myApp.AppRoles[0].Id -PrincipalId $myActionGroupServicePrincipal.Id -ResourceId $myServicePrincipal.Id
} else {
    Write-Host "Skip assigning because the role already existed."
}

Write-Host "myServicePrincipalId: " $myServicePrincipal.Id
Write-Host "My Azure AD Application (ObjectId): " $myApp.Id
Write-Host "My Azure AD Application's Roles"
foreach ($role in $myAppRoles) { Write-Host $role.Value }

Write-Host "================================================================================================="

Migrer l'action Runbook de « Exécuter en tant que compte » vers « Exécuter en tant qu'identité gérée »

Remarque

Le compte Azure Automation Run as a été retiré le 30 septembre 2023, ce qui affecte les actions créées avec le type d’action Automation Runbook. Les actions existantes liées aux runbooks Exécuter en tant que compte ne seront pas prises en charge après la mise hors service. Toutefois, ces runbooks continuent à s’exécuter jusqu’à l’expiration du certificat « Exécuter en tant que » du compte Automation.

Pour vous assurer de pouvoir continuer à utiliser les actions de runbook, vous devez :

Modifier le groupe d’actions en ajoutant une nouvelle action avec le type d’action « Runbook Automation » et choisir le même runbook dans la liste déroulante. (Les cinq runbooks de la liste déroulante ont été reconfigurés sur le serveur principal pour s’authentifier à l’aide de l’identité managée au lieu du compte d’identification. L’identité managée affectée par le système dans le compte Automation serait activée avec le rôle Contributeur de machine virtuelle au niveau de l’abonnement qui serait attribué automatiquement.)
Supprimer l’ancienne action de runbook qui lie à un runbook « Compte d’identification ».
Enregistrer le groupe d’actions.

Étapes suivantes

Obtenez une vue d’ensemble des alertes et découvrez comment recevoir des alertes.
Découvrez-en plus sur le Connecteur ITSM.
Découvrez le schéma de webhook des alertes du journal d’activité.

Partager via

Groupes d’actions

Créer un groupe d’actions sur le portail Azure

Tester un groupe d’actions sur le portail Azure

Exigences de rôles pour les groupes d’actions de test

Créer un groupe d’actions avec un modèle Resource Manager

Modèles Resource Manager de groupe d’actions

Gérer les groupes d’actions

Limites de service pour les notifications

Envoyer un message au Azure Resource Manager

sms

Réponses aux SMS

Pays/régions avec support de notification par SMS

Voix

Pays/régions avec support de notification vocale

Webhook

Configurer l’authentification pour un webhook sécurisé

Script PowerShell de webhook sécurisé

Procédure à suivre pour l’exécution

Migrer l'action Runbook de « Exécuter en tant que compte » vers « Exécuter en tant qu'identité gérée »

Étapes suivantes

Commentaires

Ressources supplémentaires