新しいアラート ルールを作成する

  • [アーティクル]

この記事では、アラート ルールを作成する方法について説明します。 アラートの詳細については、アラートの概要に関するページを参照してください。

以下を組み合わせてアラート ルールを作成します。

  • 監視対象のリソース。
  • リソースからのシグナルまたはテレメトリ。
  • 条件。

次に、以下を使用して、結果のアラート アクションに対してこれらの要素を定義します。

これらのアラート ルールによってトリガーされるアラートには、共通アラート スキーマを使用するペイロードが含まれています。

Azure portal で新しいアラート ルールを作成する

  1. portal で、[モニター]>[通知] の順に選択します。

  2. [+ 作成] メニューを開き [警告ルール] を選択します。

    新しいアラート ルールの作成手順を示すスクリーンショット。

  3. [リソースを選択する] ペインで、アラート ルールのスコープを設定します。 サブスクリプション、リソースの種類、リソースの場所でフィルター処理できます。

    Note

    Log Analytics ワークスペース リソースを選択した場合は、ワークスペースが複数のサブスクリプションのリソースからテレメトリを受信すると、それらのリソースに関するアラートが異なるサブスクリプションから送信されることに注意してください。

    新しいアラート ルールを作成するためのリソースの選択ペインを示すスクリーンショット。

  4. [適用] を選択します。

  5. ページの下部にある [Next: Condition] (次へ: 条件) を選択します。

  6. [条件] タブの [シグナル名] フィールドを選択すると、最もよく使用されるシグナルがドロップダウン リストに表示されます。 これらの一般的なシグナルのいずれかを選択するか、条件に別のシグナルを選択する場合は [すべてのシグナルを表示] を選択します。

  7. (省略可能) 前の手順で [すべてのシグナルを表示] を選択した場合は、[シグナルの選択] ウィンドウを使用してシグナル名を検索するか、シグナルの一覧をフィルター処理します。 フィルター条件:

    • [シグナルの種類]: 作成するアラート ルールの種類。
    • シグナル ソース: シグナルを送信するサービス。 この一覧は、選択したアラート ルールの種類に基づいて事前に設定されています。

    次の表では、各種類のアラート ルールで使用できるサービスについて説明します。

    シグナルの種類 シグナル ソース 説明
    メトリック プラットフォーム メトリック シグナルの場合、監視サービスはメトリック名前空間です。 "プラットフォーム" は、メトリックがリソース プロバイダー (つまり "Azure") によって提供されることを意味します。
    Azure.ApplicationInsights 顧客から報告されるメトリック。Application Insights SDK によって送信されます。
    Azure.VM.Windows.GuestMetrics VM ゲスト メトリック。VM で実行されている拡張機能によって収集されます。 組み込みのオペレーティング システムのパフォーマンス カウンターとカスタムのパフォーマンス カウンターを含めることができます。
    <カスタムの名前空間> カスタム メトリック名前空間。Azure Monitor メトリック API によって送信されるカスタム メトリックを含みます。
    ログ Log Analytics "カスタム ログ検索" と "ログ (保存されたクエリ)" シグナルを提供するサービス。
    アクティビティ ログ アクティビティ ログ - 管理 管理アクティビティ ログ イベントを提供するサービス。
    アクティビティ ログ - ポリシー ポリシー アクティビティ ログ イベントを提供するサービス。
    アクティビティ ログ - 自動スケーリング 自動スケーリング アクティビティ ログ イベントを提供するサービス。
    アクティビティ ログ - セキュリティ セキュリティ アクティビティ ログ イベントを提供するサービス。
    リソース ヘルス リソース ヘルス リソースレベルの正常性状態を提供するサービス。
    サービス正常性 サービス正常性 サブスクリプションレベルの正常性状態を提供するサービス。

    [シグナル名] を選択し、[適用] を選択します。

  8. 作成するアラートの種類に対応する、タブの手順に従います。

    1. [プレビュー] セクションで、選択したメトリック シグナルの結果をプレビューします。 次のフィールドの値を選択します。

      フィールド 説明
      時間の範囲 結果に含める時間範囲。 過去 6 時間から最後の週まで指定できます。
      タイム シリーズ 結果に含める時系列。

    2. [アラート ロジック] セクションでは、次のとおりです。

      フィールド 説明
      しきい値 静的な値または動的な値に基づいてしきい値を評価する必要があるかどうかを選択します。
      静的しきい値では、構成したしきい値を使用してルールが評価されます。
      動的しきい値では、機械学習アルゴリズムを使用してメトリックの動作パターンが継続的に学習され、予期しない動作に該当するしきい値が計算されます。 メトリック アラートに対する動的しきい値の使用に関する詳細についてご確認ください。
      演算子 メトリックの値をしきい値と比較するための演算子を選択します。
      動的しきい値を使用する場合、同じアラート ルールで上限と下限の両方に対するメトリックの動作に基づいて調整されたしきい値を使用できます。 次のいずれかの演算子を選択します。
      - 上限しきい値より大きい、または下限しきい値より小さい (既定値)
      - 上限しきい値より大きい
      - 下限しきい値より小さい
      集計の種類 データ ポイントに適用する集計関数 (Sum、Count、Average、Min、Max) を選択します。
      しきい値 静的しきい値を選択した場合は、条件ロジックのしきい値を入力します。
      ユニット 選択したメトリック シグナルで、バイト、KB、MB、GB などの異なる単位がサポートされている場合に、静的しきい値を選択したときは、条件ロジックの単位を入力します。
      しきい値の感度 動的しきい値を選択した場合は、感度レベルを入力します。 感度レベルは、アラートをトリガーするために必要なメトリック系列パターンからの偏差の量に影響します。
      - 高: しきい値はタイトになり、メトリック系列パターンに近い値になります。 アラート ルールは最小の偏差でトリガーされ、アラートは増えます。
      - 中: しきい値は比較的タイトではなくなり、よりバランスが取れたものになります。 高感度 (既定) の場合よりアラートが少なくなります。
      - 低: しきい値はルーズになり、メトリック系列パターンからの偏差が大きくなります。 アラート ルールは大きい偏差でのみトリガーされ、アラートは減ります。
      集計の細分性 集計型関数を使ってデータ ポイントをグループ化するために使用する間隔を選択します。 追加された時系列の最初の評価期間を見落とす可能性を減らすため、[評価の頻度] より大きい [集計の粒度] (期間) を選択します。
      評価の頻度 アラート: ルールの実行頻度を選択します。 評価のスライディング ウィンドウを生成するため、集計の粒度より小さい頻度を選択します。

    3. (省略可能) シグナルの種類によっては、[Split by dimensions] (ディメンションで分割) セクションが表示される場合があります。

      ディメンションは、メトリック値に関する追加のデータを含む、名前と値のペアです。 ディメンションを使用すると、すべてのディメンション値の集計を監視する代わりに、メトリックをフィルター処理して、特定の時系列を監視できます。

      複数のディメンション値を選択した場合は、その組み合わせによって生成される時系列ごとに独自のアラートがトリガーされ、個別に処理されます。 たとえば、ストレージ アカウントのトランザクション メトリックには、各トランザクションによって呼び出される API の名前 (GetBlob、DeleteBlob、PutPage など) を含む API 名ディメンションがある場合があります。 特定の API (集計データ) に多数のトランザクションがあるときにアラートを発生させることを選択できます。 ディメンションを使用して、特定の API のトランザクション数が多いときにのみアラートを発生させることもできます。

      フィールド 説明
      ディメンション名 ディメンションには、数値または文字列型の列を使用できます。 ディメンションを使用して、特定の時系列を監視し、生成されるアラートにコンテキストを提供します。
      Azure リソース ID 列で分割すると、指定したリソースがアラート ターゲットになります。 ResourceID 列が検出されると、自動的に選択され、発生したアラートのコンテキストがレコードのリソースに変更されます。
      演算子 ディメンションの名前と値に使用される演算子。
      ディメンション値 ディメンション値は、過去 48 時間のデータに基づいています。 カスタム ディメンション値を追加するには、[カスタム値を追加] を選択します。
      今後のすべての値を含める 選択したディメンションに追加される今後の値を含めるには、このフィールドを選択します。

    4. (省略可能) [評価するタイミング] セクションで、以下を行います。

      フィールド 説明
      確認する間隔 アラート ルールで条件が満たされているかどうかを調べる頻度を選択します。
      ルックバック期間 データがチェックされるたびに、どの程度遡って参照するかを選択します。 たとえば、1 分ごとに 5 分遡ります。

    5. (省略可能) [詳細オプション] セクションで、アラートをトリガーする特定期間内のエラー数を指定できます。 たとえば、過去 1 時間に 3 つのエラーが発生した場合にのみアラートをトリガーするように指定できます。 アプリケーション ビジネス ポリシーでこの設定を決定する必要があります。

      次のフィールドの値を選択します。

      フィールド 説明
      違反の数 アラートをトリガーする構成された時間枠内の違反の数。
      評価期間 その数の違反が発生する期間。
      次よりも前のデータを無視します この設定を使用して、動的しきい値を計算するために、メトリック履歴データの使用を開始する日付を選択します。 たとえば、リソースがテスト モードで実行されていて、運用環境に移動される場合、リソースがテストされていた間のメトリックの動作を無視したい場合があります。

    6. [Done] を選択します。

    これ以降、いつでも [レビュー + 作成] ボタンを選択できるようになります。

  9. [アクション] タブで、必要な [アクション グループ] を選択または作成します。

  10. (省略可能) アクション グループのデータ処理が特定のリージョン内で行われるようにする場合は、アクション グループを処理するリージョン (次のいずれか) で、そのアクション グループを選択できます。

    • スウェーデン中部
    • ドイツ中西部

    Note

    リージョン データ処理用のリージョンは継続的に追加されています。

    新しいアラート ルールの作成時の [アクション] タブを示すスクリーンショット。

  11. (省略可能) [カスタム プロパティ] セクションで、このアラート ルールのアクション グループを構成済みの場合は、アラート ペイロードに key:value のペアのカスタム プロパティを追加して、ペイロードにさらに情報を追加できます。 ペイロードに含めるカスタム プロパティにプロパティの [名前] と [値] を追加します。

    カスタム プロパティを使用して、共通スキーマを使用するアラート ペイロードからデータを抽出および操作することもできます。 これらの値は、アクション グループ Webhook またはロジック アプリで使用できます。

    共通スキーマから値を抽出する形式。"$" を使用し、中かっこで囲んだ共通スキーマ フィールドのパスを使用します。 (例: ${data.essentials.monitorCondition})。

    次の例では、カスタム プロパティの値を使用してペイロードのデータを利用します。

    例 1

    • 名前: "Additional Details"
    • 値: "評価 windowStartTime: ${data.alertContext.condition.windowStartTime}。 windowEndTime: ${data.alertContext.condition.windowEndTime}"
    • 結果: "AdditionalDetails:評価 windowStartTime: 2023-04-04T14:39:24.492Z。 windowEndTime: 2023-04-04T14:44:24.492Z"

    例 2

    • 名前: "アラート ${data.essentials.monitorCondition} の理由"
    • 値: "${data.alertContext.condition.allOf[0].metricName} ${data.alertContext.condition.allOf[0].operator} ${data.alertContext.condition.allOf[0].threshold} ${data.essentials.monitorCondition}。 値は ${data.alertContext.condition.allOf[0].metricValue}" です
    • 結果: 結果の例は次にようになります。
      • "アラート解決済みの理由: Percentage CPU GreaterThan5 Resolved. (CPU 使用率 GreaterThan5 解決済み。) 値は 3.585 です"
      • "アラート発生の理由: Percentage CPU GreaterThan5 Fired. (CPU 使用率 GreaterThan5 発生。) 値は 10.585 です"

  12. [詳細] タブで、[プロジェクトの詳細] を定義します。

    • [サブスクリプション] を選択します。
    • [リソース グループ] を選択します。
    • (省略可能) カスタム メトリックを監視するメトリック アラート ルールを作成し、そのスコープを次のいずれかのリージョンとして定義していて、アラート ルールのデータ処理がそのリージョン内で行われるようにするために、これらのリージョンのいずれかでアラート ルールを処理することを選択できます。
      • 北ヨーロッパ
      • 西ヨーロッパ
      • スウェーデン中部
      • ドイツ中西部

    Note

    リージョン データ処理用のリージョンは継続的に追加されています。

  13. [アラート ルールの詳細] を定義します。

    1. [重大度] を選択します。

    2. [アラート ルール名] と [アラート ルールの説明] の値を入力します。

    3. [リージョン] を選択します。

    4. (省略可能) [詳細オプション] セクションで、複数のオプションを設定できます。

      フィールド 説明
      作成時に有効化 アラート ルールの作成が完了したらすぐにその実行が開始されるようにするには、これを選択します。
      アラートを自動的に解決する (プレビュー) アラートをステートフルにする場合に選択します。 アラートがステートフルの場合、条件が満たされなくなった時点でアラートは解決されます。
      このチェック ボックスをオンにしない場合、メトリック アラートはステートレスになります。 ステートレス アラートは、すでにアラートが発生していても、条件が満たされるたびに発生します。
      ステートレス メトリック アラートの通知の頻度は、アラート ルールで構成された頻度によって異なります。
      アラートの頻度が 5 分未満: 条件が継続して満たされている間、1 分から 6 分の間に通知が 1 回送信されます。
      アラートの頻度が 5 分を超える: 条件が継続して満たされている間、構成された頻度とその頻度の 2 倍の間で通知が 1 回送信されます。 たとえば、頻度が 15 分のアラート ルールの場合、通知は 15 分から 30 分の間のどこかで送信されます。

    新しいアラート ルールの作成時の [詳細] タブを示すスクリーンショット。

  14. [タグ] タブで、アラート ルール リソースに必要なタグを設定します。

    新しいアラート ルールの作成時の [タグ] タブを示すスクリーンショット。

  15. [確認と作成] タブで、ルールが検証され、問題があれば通知されます。

  16. 検証に合格し、設定を確認したら、[作成] ボタンを選択します。

    新しいアラート ルールの作成時の [確認と作成] タブのスクリーンショット。

CLI を使用して新しいアラート ルールを作成する

Azure CLI を使用して、新しいアラート ルールを作成できます。 次の例では、Azure Cloud Shell を使用しています。 Azure Monitor 用の Azure CLI コマンドの完全な一覧を確認できます。

  1. portal で Cloud Shell を選択します。 プロンプトで、次のコマンドを使用します。

    メトリック アラート ルールを作成するには、az monitor metrics alert create コマンドを使用します。 メトリック アラート ルールの作成コマンドに関する詳細なドキュメントは、メトリック アラートの CLI リファレンス ドキュメントの「az monitor metrics alert create」セクションにあります。

    VM の平均 CPU 使用率が 90% を超えているかどうかを監視する、メトリック アラート ルールを作成するには、次のようにします。

     az monitor metrics alert create -n {nameofthealert} -g {ResourceGroup} --scopes {VirtualMachineResourceID} --condition "avg Percentage CPU > 90" --description {descriptionofthealert}

PowerShell を使用して新しいアラート ルールを作成する

  • PowerShell を使用してメトリック アラート ルールを作成するには、Add-AzMetricAlertRuleV2 コマンドレットを使用します。
  • PowerShell を使用してログ アラート ルールを作成するには、New-AzScheduledQueryRule コマンドレットを使用します。
  • PowerShell を使用してアクティビティ ログ アラート ルールを作成するには、Set-AzActivityLogAlert コマンドレットを使用します。

ARM テンプレートを使用して新しいアラート ルールを作成する

Azure Resource Manager テンプレート (ARM テンプレート) を使用すると、すべての環境でアラート ルールを一貫して構成できます。

  1. 次のリソースの種類を使用して、新しいリソースを作成します。
    • メトリック アラートの場合: Microsoft.Insights/metricAlerts
    • ログ アラートの場合: Microsoft.Insights/scheduledQueryRules
    • アクティビティ ログ、サービス正常性、およびリソース正常性アラートの場合: microsoft.Insights/activityLogAlerts

    Note

    • Azure Log Analytics ワークスペース リソースの種類 (Microsoft.OperationalInsights/workspaces) のメトリック アラートは、他のメトリック アラートとは異なる方法で構成されます。 詳細については、「ログのメトリック アラートのリソース テンプレート」を参照してください。
    • ターゲット リソースと同じリソース グループを使用してメトリック アラートを作成することをお勧めします。
  2. これらのサンプル ARM テンプレートからいずれかのテンプレートをコピーします。
  3. テンプレート ファイルを編集してアラートに適した情報を含め、ファイルを <your-alert-template-file>.json として保存します。
  4. 対応するパラメーター ファイルを編集してアラートをカスタマイズし、<your-alert-template-file>.parameters.json として保存します。
  5. Azure Monitor でサポートされているメトリックのいずれかの値を使用して、metricName パラメーターを設定します。
  6. PowerShell または CLI を使用してテンプレートをデプロイします。

アクティビティ ログ アラート ARM テンプレートの追加プロパティ

Note

  • アクティビティ ログ アラートは、サブスクリプション レベルで定義されます。 1 つのアラート ルールを複数のサブスクリプションに対して定義することはできません。
  • 新しいアクティビティ ログ アラート ルールがアクティブになるまで最大 5 分かかる場合があります。

アクティビティ ログ アラートの ARM テンプレートには、条件フィールドの追加プロパティが含まれています。 Resource Health、Advisor、および Service Health フィールドには、追加のプロパティ フィールドがあります。

フィールド 説明
resourceId アラートが生成されるアクティビティ ログ イベントで影響を受けるリソースのリソース ID。
category アクティビティ ログ イベントのカテゴリ。 使用可能な値は Administrative、ServiceHealth、ResourceHealth、Autoscale、Security、Recommendation、または Policy です。
caller アクティビティ ログ イベントの操作を実行したユーザーのメール アドレスまたは Azure Active Directory 識別子。
レベル アラート対象のアクティビティ ログ イベントのアクティビティのレベル。 使用可能な値は Critical、Error、Warning、Informational、または Verbose です。
operationName アクティビティ ログ イベントの操作の名前。 使用可能な値は Microsoft.Resources/deployments/write です。
resourceGroup アクティビティ ログ イベントで影響を受けるリソースのリソース グループの名前。
resourceProvider 詳細については、「Azure リソース プロバイダーと種類」を参照してください。 リソース プロバイダーを Azure サービスにマップされるリストについては、「Resource providers for Azure services」 (Azure サービスのリソースプロバイダー) を参照してください。
status アクティビティ イベントの操作の状態を説明する文字列。 可能な値は Started、In Progress、Succeeded、Failed、Active、または Resolved です。
subStatus 通常、このフィールドは、対応する REST 呼び出しの HTTP 状態コードです。 このフィールドには、サブステータスを表す他の文字列を含めることもできます。 HTTP 状態コードの例としては、OK (HTTP 状態コード: 200)、No Content (HTTP 状態コード: 204)、Service Unavailable (HTTP 状態コード: 503) などがあります。
resourceType イベントの影響を受けたリソースの種類。 たとえば Microsoft.Resources/deployments です。

アクティビティ ログのフィールドの詳細については、「Azure アクティビティ ログのイベント スキーマ」を参照してください。

アクティビティ ログ アラート ルールを [アクティビティ ログ] ウィンドウから作成する

既に発生したアクティビティ ログ イベントと同様に、今後のイベントに対してアクティビティ ログ アラートを作成することもできます。

  1. portal で、[アクティビティ ログ] ペインに移動します。

  2. 目的のイベントをフィルター処理または検索します。 次に、[アクティビティ ログ アラートの追加] を選択してアラートを作成します。

    アクティビティ ログ イベントからのアラート ルールの作成を示すスクリーンショット。

  3. [アラート ルールの作成] ウィザードが開きます。アラート ルールのスコープと条件が、前に選択したアクティビティ ログ イベントに従って既に設定されています。 必要に応じて、この段階でスコープと条件を編集および変更できます。 既定では、新しいルールの正確なスコープと条件は、元のイベント属性からコピーされます。 たとえば、既定では、イベントが発生した正確なリソースと、イベントを開始した特定のユーザーまたはサービス名の両方が、新しいアラート ルールに挿入されます。

    アラート ルールをより汎用的にする場合は、適宜スコープと条件を変更します。 「Azure portal で新しいアラート ルールを作成する」セクションの手順 3 から 9 を参照してください。

  4. 「Azure portal で新しいアラート ルールを作成する」の残りの手順に従います。

ログ アラート ルールの作成エクスペリエンスの変更

現在のアラート ルール ウィザードは、以前のエクスペリエンスとは異なります。

  • 以前は、トリガーされたアラートのペイロードと、関連する通知に検索結果が含まれていました。 Webhook ペイロードには 1,000 件のフィルター処理されていない結果が含まれていたのに対し、電子メールにはフィルター処理されていない結果から 10 行しか含まれていませんでした。 適切なアクションを決定できるように、アラートに関する詳細なコンテキスト情報を取得するには、次のようにします。
    • ディメンションを使用することをお勧めします。 ディメンションによって、アラートを発生した列の値が提供され、アラートの発生理由とその問題の解決方法のコンテキストが得られます。
    • ログを調査する必要があるときは、アラートにある、ログ内の検索結果へのリンクを使用します。
    • 生の検索結果、または他の高度なカスタマイズが必要な場合は、Azure Logic Apps を使用してください。
  • 新しいアラート ルール ウィザードでは、JSON ペイロードのカスタマイズはサポートされていません。
    • 新しい API でカスタム プロパティを使用して、アラートによってトリガーされる Webhook アクションに、静的パラメーターとそれに関連する値を追加します。
    • より高度なカスタマイズを行う場合は、Logic Apps を使用します。
  • 新しいアラート ルール ウィザードでは、メールの件名のカスタマイズはサポートされていません。
    • 多くの場合、ユーザーは、Log Analytics ワークスペースを使用する代わりに、カスタムのメールの件名を使用して、アラートが発生したリソースを指定します。 新しい API を使用し、リソース ID 列を使用して、目的のリソースのアラートをトリガーします。
    • より高度なカスタマイズを行う場合は、Logic Apps を使用します。

次のステップ

アラート インスタンスの表示と管理