Groupes d’actions

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. Les alertes peuvent contenir des groupes d’actions, qui consistent en une collection de préférences de notification. 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 exécuté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.

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

  1. Accédez au portail Azure.

  2. Recherchez et sélectionnez Surveiller. Le volet Moniteur consolide tous vos paramètres et données de supervision dans une même vue.

  3. Sélectionnez Alertes, puis Groupes d’actions.

    Capture d’écran de la page Alertes du portail Azure avec le bouton Groupes d’actions mis en évidence.

  4. Sélectionnez Create (Créer).

    Capture d’écran montrant la page Groupes d’action dans le Portail Azure. Le bouton Créer est mis en évidence.

  5. 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 d’intégrité des services sont uniquement prises en charge dans les clouds publics au sein de 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 sur « Global ».

    Option Comportement
    Global 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 e-mail effectuées en raison d’alertes d’intégrité du service sont résilientes aux incidents de site en direct Azure.
    Régionale 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
    - USA Est 2
    - USA Ouest 2
    - 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.

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

    Capture d’écran montrant la boîte de dialogue Créer un groupe d’actions. Les valeurs sont visibles dans les dialogues Abonnement, Groupe de ressource, Nom du groupe d’action et Nom d’affichage.

  7. configurer les notifications. Sélectionnez Suivant : Notifications ou bien l’onglet Notifications dans la partie supérieure de la page.

  8. Définissez une liste de notifications à envoyer quand une alerte est déclenchée.

  9. Pour chaque notification :

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

      Type de notification Description 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.
      Un e-mail de notification est envoyé uniquement à l’adresse e-mail principale configurée pour l’utilisateur Microsoft Entra.
      L’e-mail est envoyé uniquement aux utilisateurs Microsoft Entra ID qui sont membres du rôle sélectionné, et non aux groupes ou principaux de service Microsoft Entra.
      Consultez E-mail.
      Entrez l’adresse e-mail principale configurée pour l’utilisateur Microsoft Entra. Consultez E-mail.
      Courrier 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 :
      * Se désabonner de toutes les alertes par SMS pour tous les groupes d’actions ou un groupe d’actions en particulier.
      * Se réabonner 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 à Azure mobile app. Pour activer les notifications Push à destination d’Azure mobile app, fournissez des informations supplémentaires sur Azure mobile app. Consultez Azure mobile app. 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, une solution de contournement consiste à configurer le groupe d’actions de sorte qu’il appelle un webhook de fournisseur d’appels vocaux qui prend en charge votre pays/région.
    2. 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.

      Capture d’écran montrant l’onglet Notifications dans la boîte de dialogue Créer un groupe d’actions. Les informations de configuration pour les notifications par e-mail sont visibles.

    3. Sélectionnez OK.

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

  11. 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 Pour plus d’informations sur les limites au niveau des charges utiles de runbook Automation, consultez Limites d’Automation.
    Hubs d'événements Une action Event Hubs publie des notifications sur Event Hubs. 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.
    ITSM Une action ITSM requiert une connexion ITSM. Pour savoir comment créer une connexion ITSM, consultez Intégration ITSM.
    Logic Apps 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.

  12. (Facultatif) Si vous souhaitez affecter une paire clé-valeur au groupe d’actions afin de catégoriser vos ressources Azure, sélectionnez Suivant : Étiquettes ou l’onglet Étiquettes. Sinon, ignorez cette étape.

    Capture d’écran montrant l’onglet Étiquettes dans la boîte de dialogue Créer un groupe d’actions. Des valeurs sont visibles dans les zones Nom et Valeur.

  13. 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. Une fois que vous avez examiné les paramètres, sélectionnez Créer pour créer le groupe d’actions.

    Capture d’écran montrant l’onglet Vérifier + créer dans la boîte de dialogue Créer un groupe d’actions. Toutes les valeurs configurées sont visibles.

    Notes

    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.

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

    Notes

    Si vous modifiez un groupe d’actions existant, enregistrez les modifications apportées au groupe d’actions avant d’effectuer le test.

  2. Dans la page du groupe d’actions, sélectionnez Tester le groupe d’actions.

    Capture d’écran montrant la page du groupe d’actions de test avec l’option Tester.

  3. Sélectionnez le type d’échantillon et les types de notifications et d’actions que vous souhaitez tester. Puis sélectionnez Test.

    Capture d’écran de la page Exemple de groupe d’actions de test avec un type de notifications par e-mail et un type d’action webhook visibles.

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

    Capture d’écran montrant la page Exemple de groupe d’actions de test. Une boîte de dialogue comprend un bouton Arrêter et demande à l’utilisateur s’il souhaite arrêter le test.

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

    Capture d’écran montrant la page Tester un groupe d’actions d’exemple montrant un test qui a échoué.

    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 exemple de jeu de référence.

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 Prise en charge Prise en charge Prise en charge
Contributeur du groupe de ressources Prise en charge Prise en charge Non applicable
Contributeur aux ressources du groupe d’actions Prise en charge Non applicable Non applicable
Contributeur Azure Monitor Prise en charge Prise en charge Non applicable
Rôle personnalisé1 Prise en charge Prise en charge Non applicable

1 Le rôle personnalisé doit disposer de l’autorisation Microsoft.Insights/createNotifications/*.

Remarque

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 :

  1. Créez un modèle sous la forme d’un fichier JSON qui décrit comment créer le groupe d’actions.
  2. 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 :

  1. Accédez au portail Azure.

  2. Dans la page Surveiller, sélectionnez Alertes.

  3. Sélectionnez Groupes d’actions.

  4. 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 du 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 de débit pour interrompre les notifications lorsque celles-ci sont envoyées en trop grand nombre à un numéro de téléphone, une adresse e-mail ou un appareil déterminés. Elle garantit que les alertes sont faciles à gérer et exploitables.

La limitation de débit s’applique aux notifications par SMS, par e-mail et aux notifications vocales. Toutes les autres actions de notification ne sont pas soumises à la limitation de débit. Pour plus d’informations sur les limites de débit, consultez Limites du service Azure Monitor.

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.

Envoyer un message au Azure Resource Manager

Lorsque vous utilisez des notifications Azure Resource Manager par e-mail, vous pouvez envoyer des e-mails aux membres du rôle d’un abonnement. L’e-mail est envoyé uniquement aux utilisateurs Microsoft Entra ID qui sont membres du rôle. L’e-mail n’est pas envoyé aux groupes ou principaux du service Microsoft Entra.

Un e-mail de notification est envoyé uniquement à l’adresse e-mail principale.

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 :

  1. Dans le portail Azure, accédez à Microsoft Entra ID.

  2. Sur la gauche, sélectionnez Tous les utilisateurs. Sur la droite, une liste d’utilisateurs s’affiche.

  3. Sélectionnez l’utilisateur dont vous voulez consulter l’e-mail principal.

    Capture d’écran montrant la page Tous les utilisateurs du Portail Azure. Les informations sur un utilisateur sont visibles mais indéchiffrables.

  4. Dans le profil utilisateur, recherchez la valeur E-mail dans les Informations de contact. Si c’est vide :

    1. En haut de la page, sélectionnez Modifier.
    2. Entrez une adresse de messagerie.
    3. En haut de la page, sélectionnez Enregistrer.

    Capture d’écran montrant la page Profil utilisateur dans le Portail Azure. Le bouton Modifier et la zone E-mail sont mis en évidence.

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 :

  1. Attribuez une entité de type Utilisateur au rôle.
  2. Effectuez l’attribution au niveau de l’abonnement.
  3. 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

Pour plus d’informations sur les limites de débit, consultez Limitation du débit pour les messages vocaux, les SMS, les e-mails, les notifications Push Azure App Service et les webhooks.

Pour des informations importantes sur l’utilisation des notifications SMS dans les groupes d’actions, consultez Comportement des alertes SMS dans les groupes d’actions.

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

Notes

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 :

REPLY Description
DISABLE <Action Group Short name> Désactive les futurs SMS en provenance du groupe d’actions
ENABLE <Action Group Short name> Réactive les SMS en provenance du groupe d’actions
STOP Désactive les futurs SMS en provenance de tous les groupes d’actions
START Réactive les SMS en provenance de tous les groupes d’actions
HELP Une réponse est envoyée à l’utilisateur avec un lien vers cet article.

Notes

Si un utilisateur a annulé son abonnement aux alertes SMS, mais est ensuite ajouté à un nouveau groupe d’actions ; il RECEVRA les alertes SMS pour ce nouveau groupe d’actions, mais restera désabonné 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

Indicatif du pays Pays ou région
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
60 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 UAE
44 Royaume-Uni
1 États-Unis

Voix

Pour des informations importantes sur les limites de débit, consultez Limitation du débit pour les messages vocaux, les SMS, les e-mails, les notifications Push Azure App Service et les webhooks.

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

Notes

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. Pour les noms de pays suivis d’un astérisque « * », les appels sont émis à partir d’un numéro de téléphone basé aux États-Unis.

Pays/régions avec support de notification vocale

Indicatif du pays Pays ou région
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
60 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

Notes

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 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 lors de leur appel :

  • Lorsqu’un webhook est appelé et que la première tentative échoue, l’appel est de nouveau tenté entre 1 et 5 fois (5 tentatives) supplémentaires, et ce à différents intervalles (5, 20, 40 secondes).
    • Le délai entre la 1re et la 2e tentative est de 5 secondes
    • Le délai entre la 2e et la 3e tentative est de 20 secondes
    • Le délai entre la 3e et la 4e tentative est de 5 secondes
    • Le délai entre la 4e et la 5e tentative est de 40 secondes
    • Le délai entre la 5e et la 6e tentative est de 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, TaskCancellationException autorisent une nouvelle tentative pour l’appel ».

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 Microsoft Entra 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.

Notes

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 sont dépréciés depuis le 30 mars 2024. Pour en savoir plus, lisez les informations de 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.

  1. 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. Pour plus d’informations sur ces autorisations, consultez Si votre API web est appelée par un service ou une application démon.

    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.

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

    1. Modifiez l’appel Connect-AzureAD du script PowerShell pour utiliser votre ID de locataire Microsoft Entra.
    2. Modifiez la variable $myAzureADApplicationObjectId du script PowerShell pour utiliser l’ID d’objet de votre application Microsoft Entra.
    3. Exécutez le script modifié.

    Remarque

    Le principal du service doit se voir attribuer un rôle de propriétaire de l’application Microsoft Entra pour pouvoir créer ou modifier l’action webhook sécurisée dans le groupe d’actions.

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

    Capture d’écran montrant la boîte de dialogue Webhook sécurisé dans le Portail Azure avec la zone ID d’objet.

Script PowerShell de webhook sécurisé

Connect-AzureAD -TenantId "<provide your Azure AD tenant ID here>"
# Define your Azure AD application's ObjectId.
$myAzureADApplicationObjectId = "<the Object ID of your Azure AD Application>"
# Define the action group Azure AD AppId.
$actionGroupsAppId = "461e8683-5575-4561-ac7f-899cc907d62a"
# Define the name of the new role that gets added to your Azure AD application.
$actionGroupRoleName = "ActionGroupsSecureWebhook"
# Create an application role with the given name and description.
Function CreateAppRole([string] $Name, [string] $Description)
{
    $appRole = New-Object Microsoft.Open.AzureAD.Model.AppRole
    $appRole.AllowedMemberTypes = New-Object System.Collections.Generic.List[string]
    $appRole.AllowedMemberTypes.Add("Application");
    $appRole.DisplayName = $Name
    $appRole.Id = New-Guid
    $appRole.IsEnabled = $true
    $appRole.Description = $Description
    $appRole.Value = $Name;
    return $appRole
}
# Get your Azure AD application, its roles, and its service principal.
$myApp = Get-AzureADApplication -ObjectId $myAzureADApplicationObjectId
$myAppRoles = $myApp.AppRoles
$actionGroupsSP = Get-AzureADServicePrincipal -Filter ("appId eq '" + $actionGroupsAppId + "'")
Write-Host "App Roles before addition of new role.."
Write-Host $myAppRoles
# Create the role if it doesn't exist.
if ($myAppRoles -match "ActionGroupsSecureWebhook")
{
    Write-Host "The Action Group role is already defined.`n"
}
else
{
    $myServicePrincipal = Get-AzureADServicePrincipal -Filter ("appId eq '" + $myApp.AppId + "'")
    # Add the new role to the Azure AD application.
    $newRole = CreateAppRole -Name $actionGroupRoleName -Description "This is a role for Action Group to join"
    $myAppRoles.Add($newRole)
    Set-AzureADApplication -ObjectId $myApp.ObjectId -AppRoles $myAppRoles
}
# Create the service principal if it doesn't exist.
if ($actionGroupsSP -match "AzNS AAD Webhook")
{
    Write-Host "The Service principal is already defined.`n"
}
else
{
    # Create a service principal for the action group Azure AD application and add it to the role.
    $actionGroupsSP = New-AzureADServicePrincipal -AppId $actionGroupsAppId
}
New-AzureADServiceAppRoleAssignment -Id $myApp.AppRoles[0].Id -ResourceId $myServicePrincipal.ObjectId -ObjectId $actionGroupsSP.ObjectId -PrincipalId $actionGroupsSP.ObjectId
Write-Host "My Azure AD Application (ObjectId): " + $myApp.ObjectId
Write-Host "My Azure AD Application's Roles"
Write-Host $myApp.AppRoles

Migrer l’action du runbook de « Compte d’identification » vers « Exécuter en tant qu’identité managée »

Remarque

L’action « Compte d’identification » Azure Automation a été mise hors service le 30 septembre 2023, ce qui affecte les actions créées avec le type d’action « Runbook Automation ». Les actions existantes liées aux runbooks « Compte d’identification » 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 :

  1. 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.)

    Capture d’écran de l’ajout d’une action de runbook à un groupe d’actions.

    Capture d’écran de la configuration de l’action runbook.

  2. Supprimer l’ancienne action de runbook qui lie à un runbook « Compte d’identification ».

  3. Enregistrer le groupe d’actions.

Étapes suivantes