次の方法で共有

アクション グループ

  • [アーティクル]

Azure Monitor のデータによって、インフラストラクチャまたはアプリケーションに問題がある可能性があることが示されると、アラートがトリガーされます。 アクション グループを使用すると、アラート自体に加えて、アラートがトリガーされたときに音声通話、SMS、メールなどの通知を送信できます。 アクション グループは、アクションまたは通知設定のコレクションです。 Azure Monitor、Azure Service Health、Azure Advisor は、アクション グループを使用して、アラートについてユーザーに通知し、アクションを実行します。 この記事では、アクション グループを作成および管理する方法について説明します。

各アクションは、次で構成されます。

  • 種類: 送信された通知または実行されるアクション。 たとえば、音声通話、SMS、電子メールの送信などがあります。 また、さまざまな種類の自動アクションをトリガーすることもできます。
  • Name:アクション グループ内の一意識別子。
  • 詳細: 種類によって異なる対応する詳細。

一般に、アクション グループはグローバル サービスです。 それらをリージョンでより利用しやすくするための取り組みは開発中です。

クライアントからのグローバルな要求は、任意のリージョンのアクション グループ サービスで処理できます。 アクション グループ サービスの 1 つのリージョンがダウンした場合、トラフィックは自動的にルーティングされ、他のリージョンによって処理されます。 グローバル サービスとして、アクション グループは ディザスター リカバリー ソリューションの提供を支援します。 リージョンの要求は、可用性ゾーンの冗長性に依存します。これは、プライバシー要件を満たし、同様のディザスター リカバリー ソリューションを提供するためです。

  • 警告ルールには、最大 5 つのアクション グループを追加できます。
  • アクション グループは、特定の順序はなく、同時に実行されます。
  • 複数の警告ルールで同じアクション グループを使用できます。
  • アクション グループは、一意のアクションセットと、通知を受けるユーザーによって定義されます。 たとえば、2 つの異なるアラート ルールについて User1、User2、User3 に電子メールで通知する場合は、両方のアラート ルールに適用できるアクション グループを 1 つ作成するだけで済みます。

Azure portal でアクション グループを作成する

  1. Azure ポータルにアクセスします。

  2. [モニター] を検索して選択します。 [モニター] ウィンドウでは、すべての監視設定とデータが 1 つのビューにまとめられています。

  3. [アラート] を選択し、[アクション グループ] を選択します。

    [アクション グループ] ボタンが強調されている、Azure portal の [アラート] ページのスクリーンショット。

  4. ［作成］ を選択します

    Azure portal の [アクション グループ] ページを示すスクリーンショット。[作成] ボタンが強調表示されている。

  5. 基本アクション グループ設定を構成します。 [プロジェクトの詳細] セクションで、次の手順を実行します。

    • [サブスクリプション] と [リソース グループ] の値を選択します。
    • リージョンを選択します。

    Note

    Service Health アラートは、グローバル リージョン内のパブリック クラウドでのみサポートされます。 Service Health アラートに応答してアクション グループが適切に機能するには、アクション グループのリージョンが "グローバル" として設定されている必要があります。

    オプション 動作
    グローバル アクション グループ サービスは、アクション グループを格納する場所を決定します。 リージョンの回復性を確保するために、アクション グループは少なくとも 2 つのリージョンに保持されます。 アクションの処理は、任意の地理的リージョンで実行できます。

    サービス正常性アラートの結果として実行される音声、SMS、電子メールのアクションは、Azure のライブ サイト インシデントに対して回復性があります。
    地域 アクション グループは、選択したリージョン内に格納されます。 アクション グループはゾーン冗長です。 アクション グループの処理が確実に特定の地理的境界内で実行されるようにするには、このオプションを使用します。 アクション グループのリージョン処理には、以下のリージョンのいずれか 1 つを選択できます。
    - 米国東部
    - 米国西部
    - 米国東部 2
    - 米国西部 2
    - 米国中南部
    - 米国中北部
    - スウェーデン中部
    - ドイツ中西部
    - インド中部
    - インド南部
    アクション グループのリージョン データ処理用のリージョンは継続的に追加されています。

    アクション グループは、選択したサブスクリプション、リージョン、リソース グループに保存されます。

  6. [インスタンスの詳細] セクションで、[アクション グループ名] と [表示名] の値を入力します。 表示名は、グループを使用して通知を送信するときに、完全なアクション グループ名の代わりに使用されます。

    [アクション グループの作成] ダイアログを示すスクリーンショット。[サブスクリプション]、[リソース グループ]、[アクション グループ名]、[表示名] ボックスに値が表示されている。

  7. 通知を構成します。 [次へ: 通知] を選択するか、ページの上部にある [通知] タブを選択します。

  8. アラートがトリガーされたときに送信する通知の一覧を定義します。

  9. 通知ごとに次の手順を実行します。

    1. [通知の種類] を選択し、その通知の適切なフィールドに入力します。 使用可能なオプションは次のとおりです。

      通知の種類 説明 フィールド
      電子メールの Azure Resource Manager のロール それぞれのロールに基づいて、サブスクリプション メンバーに電子メールを送信します。
      「電子メール」を参照してください。      		 Microsoft Entra ユーザー用に構成されたプライマリ メール アドレスを入力します。 「電子メール」を参照してください。
      Email メール フィルタリングとマルウェア/スパム防止サービスが適切に構成されていることを確認します。 電子メールは、次の電子メール アドレスから送信されます。
      * azure-noreply@microsoft.com
      * azureemail-noreply@microsoft.com
      * alerts-noreply@mail.windowsazure.com      		 通知を送信するメール アドレスを入力します。
      sms SMS 通知では双方向通信がサポートされます。 SMS には、次の情報が含まれています。
      * このアラートの送信先のアクション グループの短い名前
      * アラートのタイトル。
      ユーザーは、次のことを行うために SMS に応答できます。
      * すべてのアクション グループまたは単一のアクション グループのすべての SMS アラートの登録を解除。
      * アラートへの再登録
      * サポートの要求。
      サポートされている SMS の返信の詳細については、「SMS の返信」を参照してください。      		 SMS 受信者の国番号と電話番号を入力します。 Azure portal で国/地域コードを選択できない場合、SMS は国/地域ではサポートされていません。 国/地域コードが利用できない場合は、アイデアを共有するで国/地域を追加するために投票できます。 お客様の国がサポートされるまでの回避策として、お客様の国/地域をサポートするサード パーティの SMS プロバイダーに Webhook を呼び出すようにアクション グループを構成します。
      Azure アプリのプッシュ通知 Azure mobile app に通知を送信します。 Azure mobile app へのプッシュ通知を有効にするための詳細については、Azure mobile app に関するページを参照してください。 [Azure アカウントの電子メール] フィールドに、Azure mobile app を構成するときにアカウント ID として使用するメール アドレスを入力します。
      音声 音声通知です。 通知の受信者の国番号と電話番号を入力します。 Azure portal で国/地域コードを選択できない場合、音声通知はご利用の国/地域ではサポートされていません。 国/地域コードが利用できない場合は、アイデアを共有するで国/地域を追加するために投票できます。 お客様の国がサポートされるまでの回避策として、お客様の国/地域をサポートするサード パーティの音声通話プロバイダーに Webhook を呼び出すようにアクション グループを構成します。

    2. 共通アラート スキーマを有効にするかどうかを選択します。 共通アラート スキーマは、Azure Monitor のすべてのアラート サービスで使用できる、拡張可能で統合された単一のアラート ペイロードです。 共通スキーマの詳細については、「共通アラート スキーマ」を参照してください。

      [アクション グループの作成] ダイアログの [通知] タブを示すスクリーンショット。電子メール通知の構成情報が表示されている。

    3. [OK] を選択します。

  10. アクションを構成します。 [次へ: アクション] を選択します。 または、ページの上部にある [アクション] タブを選択します。

  11. アラートがトリガーされたときにトリガーするアクションの一覧を定義します。 アクションの種類を選択し、各アクションの名前を入力します。

    アクションの種類 詳細
    Automation Runbook Automation Runbook を使用して、メトリックに基づいてタスクを自動化します。 たとえば、関連付けられている予算の特定のしきい値が満たされたときにリソースをシャットダウンします。 Automation Runbook ペイロードの制限の詳細については、「Automation の制限」を参照してください。
    Event Hubs Event Hubs アクションは、通知を Event Hubs に発行します。 Event Hubs の詳細については、「Azure Event Hubs - ビッグ データ ストリーミング プラットフォームとイベント インジェスト サービス」 を参照してください。 イベント受信者からアラート通知ストリームをサブスクライブできます。
    関数 関数で既存の HTTP トリガー エンドポイントを呼び出します。 詳細については、Azure Functions に関するページを参照してください。
    関数アクションを定義すると、関数の HTTP トリガーエンドポイントとアクセスキーがアクション定義に保存されます (https://azfunctionurl.azurewebsites.net/api/httptrigger?code=<access_key> など)。 関数のアクセス キーを変更する場合は、アクション グループで関数アクションを削除して再作成する必要があります。
    エンドポイントで HTTP POST メソッドがサポートされている必要があります。
    関数は、ストレージ アカウントへのアクセス権を持っている必要があります。 アクセス権がない場合、キーを使用できず、関数の URI にアクセスできません。
    ストレージ アカウントへのアクセスの復元についてはこちらを参照してください。
    ITSM ITSM アクションには ITSM 接続が必要です。 ITSM 接続の作成方法については、「 ITSM 統合」 を参照してください。
    ロジック アプリ Azure Logic Apps を使用して、統合用のワークフローを構築およびカスタマイズしたり、アラート通知をカスタマイズしたりできます。
    セキュリティで保護された Webhook セキュリティで保護された Webhook アクションを使用する場合、Microsoft Entra ID を使用して、アクション グループとエンドポイント (保護された Web API) 間の接続をセキュリティで保護する必要があります。 セキュリティで保護された Webhook の認証の構成に関するセクションを参照してください。 セキュリティで保護された Webhook では、基本認証はサポートされていません。 基本認証を使用している場合は、Webhook アクションを使用します。
    Webhook Webhook アクションを使用する場合、ターゲット Webhook エンドポイントは、さまざまなアラート ソースが出力する、さまざまな JSON ペイロードを処理できる必要があります。
    Webhook アクションを介してセキュリティ証明書を渡すことはできません。 基本認証を使用するには、URI で資格情報を渡す必要があります。
    Webhook エンドポイントが特定のスキーマ (Microsoft Teams スキーマなど) を必要とする場合は、Logic Apps アクションの種類を使用して、ターゲット Webhook の想定に合わせてアラート スキーマを操作する必要があります。
    Webhook アクションの再試行に使用される規則の詳細については、「Webhook」を参照してください。

    [アクション グループの作成] ダイアログの [アクション] タブを示すスクリーンショット。[アクション タイプ] リストに複数のオプションが表示されている。

  12. (省略可能。) ご自分の Azure リソースを分類するためにキーと値のペアをアクション グループに割り当てる場合は、[次へ: タグ] または [タグ] タブを選択します。それ以外の場合は、この手順をスキップします。

    [アクション グループの作成] ダイアログの [タグ] タブを示すスクリーンショット。[名前] ボックスと [値] ボックスに値が表示されている。

  13. [確認 + 作成] を選んで、設定を確認します。 この手順では、入力をすばやく確認して、必要な情報がすべて入力されていることを確認します。 問題がある場合は、ここで報告されます。 設定を確認したら、[作成] を選択してアクション グループを作成します。

    [アクション グループの作成] ダイアログの [確認と作成] タブを示すスクリーンショット。構成済みのすべての値が表示されている。

    注意

    電子メールまたは SMS でユーザーに通知するようアクションを構成すると、ユーザーは自分がアクション グループに追加されたことを示す確認メッセージを受け取ります。

Azureポータルでアクショングループをテストする。

Azure portal でアクション グループを作成または更新する場合、アクション グループを [テスト] できます。

  1. Azure portal でアクション グループを作成します。

    Note

    アクション グループは、テスト前に作成して保存する必要があります。 既存のアクション グループを編集している場合、テストする前にアクション グループへの変更を保存してください。

  2. [アクション グループ] ページで、[テスト アクション グループ] を選択します。

    [テスト] オプションが表示されているアクション グループのテスト ページを示すスクリーンショット。

  3. テストするサンプルの種類と、通知の種類とアクションの種類を選択します。 次に、[テスト] を選択します。

    電子メールの通知タイプと Webhook アクション タイプが表示されている [テスト サンプル アクション グループ] ページを示すスクリーンショット。

  4. テストの実行中にウィンドウを閉じるか、[テスト設定に戻る] を選択すると、テストは停止し、テスト結果は表示されません。

    [テスト サンプル アクション グループ] ページを示すスクリーンショット。ダイアログには [停止] ボタンがあり、テストを停止するかどうか確認している。

  5. テストが完了すると、成功または失敗のいずれかのテスト状態が表示されます。 テストが失敗し、詳細情報を取得する場合は、[詳細の表示] を選択ます。

    失敗したテストを示す [テスト サンプル アクション グループ] ページを示すスクリーンショット。

    [エラーの詳細] セクションの情報を使用して問題を把握できます。 その後、アクション グループを編集し、変更を保存し、再度テストできます。

    テストを実行して通知の種類を選択すると、件名に 「Test」 というメッセージが表示されます。 テストは、運用環境でアクション グループを有効にする前に、アクション グループが期待どおりに動作することを確認する方法を提供します。 発生したアラートについての Test 電子メール通知のすべての詳細とリンクは、参照用のサンプル セットです。

テスト アクション グループのロール要件

次の表では、 テスト アクション 機能に必要なロール メンバーシップの要件について説明します。

ロールのメンバーシップ 既存のアクション グループ 既存のリソース グループと新しいアクション グループ 新しいリソース グループと新しいアクション グループ
サブスクリプションの共同作成者 サポートされています サポート対象 サポートされています
リソース グループの共同作成者 サポートされています サポートされています 該当なし
アクション グループ リソースの共同作成者 サポートされています 該当なし 該当なし
Azure Monitor 共同作成者 サポートされています サポートされています 適用なし
カスタム ロール1 サポートされています サポートされています 適用なし

1 カスタム ロールには、Microsoft.Insights/createNotifications/* アクセス許可が必要です。

Note

  • ユーザーがこの通知を生成するための適切なアクセス許可を持つ上記のロール メンバーシップのメンバーでない場合、アクション グループをテストするために必要な最小限のアクセス許可は "Microsoft.Insights/createNotifications/*" です
  • 期間ごとに実行できるテストの数は限られています。 ご自分の状況に適用される制限をチェックするには、「Azure Monitor サービスの制限」を参照してください。
  • ポータルでアクション グループを構成する場合は、共通のアラート スキーマをオプトインまたはオプトアウトできます。

Resource Manager テンプレートを使用したアクション グループの作成

Azure Resource Manager テンプレート を使用し、アクション グループを構成できます。 テンプレートを使用することで、特定の種類のアラートで再利用できるアクション グループを自動的に設定できます。 このようなアクション グループを使用することで、アラートがトリガーされたときに、すべての適切な関係者が通知を確実に受け取ることができます。

基本的な手順は次のとおりです。

  1. アクション グループの作成方法が記述された JSON ファイルとしてテンプレートを作成します。
  2. 任意のデプロイ方法を使用してテンプレートをデプロイします。

アクション グループの Resource Manager テンプレート

Resource Manager テンプレートを使用してアクション グループを作成するには、Microsoft.Insights/actionGroups 型のリソースを作成します。 次に、関連するすべてのプロパティを入力します。 次に、アクション グループを作成するサンプル テンプレートを 2 つ示します。

1 つ目のテンプレートでは、アクション グループ用の Resource Manager テンプレートを作成する方法を説明します。テンプレートにはアクション定義がハードコーディングされます。 2 つ目のテンプレートでは、テンプレートのデプロイ時に入力パラメータとして webhook 構成情報を受け取るテンプレートを作成する方法を説明します。

{
  "$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'))]"
      }
  }
}

アクション グループの管理

アクション グループを作成した後、ポータルで表示できます。

  1. Azure ポータルにアクセスします。

  2. [監視] ページで、[アラート] を選択します。

  3. [アクション グループ] を選択します。

  4. 管理するアクション グループを選択します。 次のようにすることができます。

    • アクションの追加、編集、または削除。
    • アクション グループの削除。

通知のサービス制限

電話番号またはメール アドレスを、多数のサブスクリプションのアクション グループに含めることができます。 Azure Monitor では、特定の電話番号、メール アドレス、またはデバイスに送信される通知が多すぎる場合に、通知を一時的に停止するレート制限が使用されています。 レート制限によって、アラートを管理しやすくなりアクション可能な状態が保証されます。

レート制限は、SMS、音声、電子メールの通知に適用されます。 その他のすべての通知アクションは、レート制限を受けません。 レート制限はすべてのサブスクリプションに対して適用されます。 メッセージが複数のサブスクリプションから送信された場合であっても、しきい値に達するとただちにレート制限が適用されます。 メール アドレスがレート制限を受ける場合、レート制限が適用されたこと、およびレート制限の有効期限を伝える通知が送信されます。

レート制限の詳細については、「Azure Monitor サービスの制限」を参照してください。

メール アドレスの Azure Resource Manager

メール通知に Azure Resource Manager を使用すると、サブスクリプションのロールのメンバーに電子メールを送信できます。 電子メールは、ロールの Microsoft Entra ID ユーザーまたはグループ メンバーに送信されます。 これには、Azure Lighthouse を介して割り当てられたロールのサポートが含まれます。

Note

アクション グループでは以下のロールへのメール送信のみがサポートされます: 所有者、共同作成者、閲覧者、監視共同作成者、監視閲覧者。

プライマリ メールに通知が届かない場合は、Email Azure Resource Manager ロールのメール アドレスを設定します。

  1. Azure portal で、[Microsoft Entra ID] に移動します。

  2. 左側の [すべてのユーザー] を選択ます。 右側に、ユーザーの一覧が表示されます。

  3. "メインの電子メール" を確認したいユーザーを選択します。

    Azure portal の [すべてのユーザー] ページを示すスクリーンショット。1 人のユーザーに関する情報が表示されているが、はっきり判読できない。

  4. ユーザー プロファイルで、[連絡先情報] にある 電子メール の値を確認します。 空白の場合:

    1. ページの上部にある [編集] を選択します。
    2. 電子メール アドレスを入力します。
    3. ページの最上部で [保存] を選択します。

    Azure portal のユーザー プロファイル ページを示すスクリーンショット。[編集] ボタンと [電子メール] ボックスが強調表示されている。

アクショングループごに制限された数の電子メール アクションを保持できます。 ご自分の状況に適用される制限をチェックするには、「Azure Monitor サービスの制限」を参照してください。

Resource Manager の役割を設定する場合は、次のようになります。

  1. User または Group 型のエンティティをロールに割り当てます。
  2. サブスクリプション レベルで割り当てを行います。
  3. Microsoft Entra プロファイル でユーザーの電子メール アドレスが構成されていることを確認します。
  • ユーザーがこの通知を生成するための適切なアクセス許可を持つ上記のロール メンバーシップのメンバーでない場合、アクション グループをテストするために必要な最小限のアクセス許可は "Microsoft.Insights/createNotifications/*" です
  • 期間ごとに実行できるテストの数は限られています。 自分の状況に適用される制限をチェックするには、「Azure Monitor サービスの制限」をご覧ください。
  • ポータルでアクション グループを構成する場合は、共通のアラート スキーマをオプトインまたはオプトアウトできます。

Note

顧客がサブスクリプションに新しい Azure Resource Manager ロールを追加した後、通知の受信を開始するまでに最大 24 時間かかる場合があります。

SMS

アクショングループごに制限された数の SMS アクションを保持できます。

Note

Azure portal で国/地域コードを選択できない場合、SMS は国/地域ではサポートされていません。 国/地域コードが利用できない場合は、アイデアを共有するで国/地域を追加するために投票できます。 その間、回避策として、お住まいの国/地域でサポートを提供するサードパーティの SMS プロバイダーに Webhook を呼び出すようにアクショングループを構成します。

SMS の返信

これらの返信は、SMS 通知でサポートされています。 SMS の受信者は、こちらの値を使用して SMS に返信できます。

応答 説明
DISABLE <Action Group Short name> そのアクション グループからのそれ以上の SMS を無効にします
ENABLE <Action Group Short name> そのアクション グループからの SMS を再度有効にします
STOP すべてのアクション グループからのそれ以上の SMS を無効にします
START すべてのアクション グループからの SMS を再度有効にします
HELP この記事へのリンクが記載された応答がユーザーに送信されます。

注意

SMS アラートの登録を解除したユーザーが新しいアクション グループに追加されると、その新しいアクション グループの SMS アラートを受け取りますが、以前のすべてのアクション グループの登録は解除されたままになります。 アクショングループごに制限された数の Azure app アクションを保持できます。

SMS 通知がサポートされている国およびリージョン

国番号 国
61 オーストラリア
43 オーストリア
32 ベルギー
55 ブラジル
1 Canada
56 チリ
86 中国
420 チェコ共和国
45 デンマーク
372 エストニア
358 フィンランド
33 フランス
49 ドイツ
852 中華人民共和国香港特別行政区
91 インド
353 アイルランド
972 イスラエル
39 イタリア
81 日本
352 ルクセンブルク
60 マレーシア
52 メキシコ
31 オランダ
64 ニュージーランド
47 ノルウェー
351 ポルトガル
1 プエルトリコ
40 ルーマニア
7 ロシア
65 シンガポール
27 南アフリカ
82 韓国
34 スペイン
41 スイス
886 台湾
971 UAE
44 イギリス
1 United States

音声

アクショングループごに制限された数の音声アクションを保持できます。 レート制限に関する重要な情報については、「Azure Monitor サービスの制限」を参照してください。

Note

Azure portal で国/地域コードを選択できない場合、音声通話はご利用の国/地域ではサポートされていません。 国/地域コードが利用できない場合は、アイデアを共有するで国/地域を追加するために投票できます。 その間、回避策として、お住まいの国/地域でサポートを提供するサードパーティの音声通話プロバイダーに Webhook を呼び出すようにアクション グループを構成します。 国名が '*' でマークされている場合は、米国ベースの電話番号から発信されます。

Voice 通知がサポートされている国およびリージョン

国番号 国
61 オーストラリア
43 オーストリア
32 ベルギー
55 ブラジル
1 Canada
56 チリ
86 中国*
420 チェコ共和国
45 デンマーク
372 エストニア
358 フィンランド
33 フランス
49 ドイツ
852 香港特別行政区*
91 インド*
353 アイルランド
972 イスラエル
39 イタリア*
81 日本*
352 ルクセンブルク
60 マレーシア
52 メキシコ
31 オランダ
64 ニュージーランド
47 ノルウェー
351 ポルトガル
40 ルーマニア*
7 ロシア*
65 シンガポール
27 南アフリカ
82 韓国
34 スペイン
46 スウェーデン
41 スイス
886 台湾*
971 アラブ首長国連邦*
44 イギリス
1 United States

サポートされている国/地域の価格の詳細については、「Azure Monitor の価格」を参照してください。

Webhook

Note

Webhook アクションを使用する場合、ターゲット Webhook エンドポイントは、さまざまなアラート ソースが出力する、さまざまな JSON ペイロードを処理できる必要があります。 Webhook エンドポイントにもパブリックにアクセスできる必要があります。 Webhook アクションを介してセキュリティ証明書を渡すことはできません。 基本認証を使用するには、URI で資格情報を渡す必要があります。 Webhook エンドポイントが特定のスキーマ (Microsoft Teams スキーマなど) を必要とする場合は、Logic Apps アクションを使用して、ターゲット Webhook の想定に合わせてアラート スキーマを変換する必要があります。 Webhook アクション グループでは通常、呼び出されたときに次の規則に従います。

  • Webhook の呼び出し時、最初の呼び出しが失敗した場合、少なくとも 1 回の再試行、さらにさまざまな待ち時間間隔 (5、20、40 秒) で最大 5 回の再試行が行われます。
    • 1 回目から 2 回目の試行までの待ち時間は 5 秒です
    • 2 回目から 3 回目の試行までの待ち時間は 20 秒です
    • 3 回目から 4 回目の試行までの待ち時間は 5 秒です
    • 4 回目から 5 回目の試行までの待ち時間は 40 秒です
    • 5 回目から 6 回目の試行までの待ち時間は 5 秒です
  • Webhook を呼び出そうとする試みが失敗した場合、アクション グループは 15 分間エンドポイントを呼び出しません。
  • 再試行ロジックは、呼び出しを再試行できることを前提としています。 状態コード: 408、429、503、504、または HttpRequestException、WebException、TaskCancellationException では、呼び出しを再試行できます。

セキュリティで保護された Webhook の認証を構成する

セキュリティで保護された Webhook アクションは、"AZNS Microsoft Entra Webhook" Microsoft Entra アプリケーションの Microsoft Entra テナントにあるサービス プリンシパル インスタンスを使用して、保護された API に対して認証します。 アクション グループを機能させるには、この Microsoft Entra Webhook サービス プリンシパルを、ターゲット エンドポイントへのアクセスを許可するターゲット Microsoft Entra アプリケーションのロールのメンバーとして追加する必要があります。

Microsoft Entra アプリケーションとサービス プリンシパルの概要については、Microsoft ID プラットフォーム (v2.0) の概要に関するページを参照してください。 次の手順に従って、セキュリティで保護された Webhook 機能を利用します。

Note

SecureWebhook では基本認証はサポートされていません。 基本認証を使用するには、Webhook を使用する必要があります。 Webhook アクションを使用する場合、ターゲット Webhook エンドポイントは、さまざまなアラート ソースが出力する、さまざまな JSON ペイロードを処理できる必要があります。 Webhook エンドポイントが特定のスキーマ (Microsoft Teams スキーマなど) を必要とする場合は、Logic Apps アクションを使用して、ターゲット Webhook の想定に合わせてアラート スキーマを変換する必要があります。

Note

Azure AD および MSOnline PowerShell モジュールは、2024 年 3 月 30 日の時点で非推奨となります。 詳細については、非推奨の最新情報を参照してください。 この日以降、これらのモジュールのサポートは、Microsoft Graph PowerShell SDK への移行支援とセキュリティ修正プログラムに限定されます。 非推奨になるモジュールは、2025 年 3 月 30 日まで引き続き機能します。

Microsoft Entra ID (旧称 Azure AD) を使用するには、Microsoft Graph PowerShell に移行することをお勧めします。 移行に関する一般的な質問については、「移行に関する FAQ」を参照してください。 注: バージョン 1.0.x の MSOnline では、2024 年 6 月 30 日以降に中断が発生する可能性があります。

  1. 保護された Web API 用の Microsoft Entra アプリケーションを作成します。 詳細については、「保護された Web API: アプリの登録」 を参照してください。 デーモン アプリによって呼び出されるように保護された API を構成し、委任されたアクセス許可ではなく、アプリケーションのアクセス許可を公開します。 これらのアクセス許可の詳細については、「Web API がサービスまたはデーモン アプリによって呼び出された場合」 を参照してください。

    Note

    V2.0 アクセス・トークンを受け入れるように保護された Web API を構成します。 この設定の詳細については、「Microsoft Entra アプリ マニフェスト」を 参照してください。

  2. アクション グループが Microsoft Entra アプリケーションを使用できるようにするには、次の手順にフォローする PowerShell スクリプトを使用します。

    Note

    このスクリプトを実行するには、Microsoft Entra アプリケーション管理者ロールが割り当てられている必要があります。

    1. PowerShell スクリプトの Connect-AzureAD 呼び出しを変更して、Microsoft Entra テナント ID を使用します。
    2. PowerShell スクリプトの $myAzureADApplicationObjectId 変数を変更して、Microsoft Entra アプリケーションのオブジェクト ID を使用します。
    3. 変更したスクリプトを実行します。

    Note

    アクション グループでセキュリティで保護された Webhook アクションを作成または変更できるようにするには、Microsoft Entra アプリケーションの所有者ロールをサービス プリンシパルに割り当てる必要があります。

  3. セキュリティで保護された Webhook アクションを構成します。

    1. スクリプト内の $myApp.ObjectId 値をコピーします。
    2. Webhook アクション定義の [オブジェクト ID] ボックスに、コピーした値を入力します。

    [Object ID] ボックスが表示されている Azure portal の [セキュリティで保護された Webhook] ダイアログを示すスクリーンショット。

Secure Webhook PowerShell スクリプト

Note

前提条件: Microsoft Graph PowerShell SDK をインストールする

実行方法

  1. 以下のスクリプトをコピーしてコンピューターに貼り付けます
  2. tenantId と、アプリ登録の ObjectID を置き換えます
  3. *.ps1 として保存します
  4. コンピューターから PowerShell コマンドを開き、*.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 "================================================================================================="

Runbook アクションを "アカウントとして実行" から "マネージド ID として実行" に移行する

Note

Azure Automation の "アカウントとして実行" は 2023 年 9 月 30 日に廃止されました。これは、アクションの種類が "Automation Runbook" で作成されたアクションに影響します。 "アカウントとして実行" の Runbook にリンクしている既存のアクションは、廃止後はサポートされなくなります。 ただし、それらの Runbook は、Automation アカウントの "実行" 証明書の有効期限までは引き続き実行されます。 Runbook アクションの使用を継続できるようにするには、以下を行う必要があります。

  1. アクションの種類が "Automation Runbook" の新しいアクションを追加してアクション グループを編集し、ドロップダウンから同じ Runbook を選択します。 (ドロップダウンの 5 つの Runbook はすべて、"アカウントとして実行" の代わりにマネージド ID を使用して認証するようにバックエンドで再構成されました。Automation アカウントのシステム割り当てマネージド ID は、サブスクリプション レベルの VM 共同作成者ロールで有効化されて自動的に割り当てられます。)

    アクション グループに Runbook アクションを追加するスクリーンショット。

    Runbook アクションの構成のスクリーンショット。

  2. "アカウントとして実行" Runbook にリンクされている古い Runbook アクションを削除します。

  3. アクション グループを保存します。

次のステップ