メトリック警告ルールを作成または編集する

メトリック アラート ルールを作成するには、次のアクセス許可が必要です。

• アラート ルールのターゲット リソースに対する読み取りアクセス許可。
• アラート ルールが作成されるリソース グループに対する書き込みアクセス許可。 Azure portal からアラート ルールを作成する場合は、そのアラート ルールが同じリソース グループ (ターゲット リソースが存在している) に既定で作成されます。
• アラート ルールに関連付けられているアクション グループに対する読み取りアクセス許可 (該当する場合)。

次のステップを実行します。

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

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

   

次のステップを実行します。

1. ポータルで、リソースに移動します。

2. 左側のウィンドウで [警告] を選択した後に、[+作成]>[警告ルール] を選択します。

   

次のステップを実行します。

1. ポータルで、ホーム ページまたは特定のリソースから、左側のウィンドウの [警告] を選択します。

2. 警告ルールを選択します。

3. 編集したい警告ルールを選択した後に、[編集] を選択します。

   

4. 警告ルールのタブのいずれかを選択して設定を編集します。

次のステップを実行します。

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

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

   

次のステップを実行します。

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

   

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

   • [シグナルの種類]: 作成するアラート ルールの種類。
   • シグナル ソース: シグナルを送信するサービス。

   次の表では、メトリック警告ルールで使用できるサービスについて説明します。

   シグナル ソース	説明
   プラットフォーム	メトリック シグナルの場合、監視サービスはメトリック名前空間です。 "プラットフォーム" は、メトリックがリソース プロバイダー (つまり "Azure") によって提供されることを意味します。
   Azure.ApplicationInsights	顧客から報告されるメトリック。Application Insights SDK によって送信されます。
   Azure.VM.Windows.GuestMetrics	VM ゲスト メトリック。VM で実行されている拡張機能によって収集されます。 組み込みのオペレーティング システムのパフォーマンス カウンターとカスタムのパフォーマンス カウンターを含めることができます。
   <カスタムの名前空間>	カスタム メトリック名前空間。Azure Monitor メトリック API によって送信されるカスタム メトリックを含みます。

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

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

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

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

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

5. (省略可能) ディメンションによる分割を構成できます。

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

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

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

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

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

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

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

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

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

次のステップを実行します。

1. [Actions](アクション) タブを選択します。

2. 必要なアクション グループを選択または作成します。

   

次のステップを実行します。

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

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

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

   

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

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

5. (省略可能) カスタム メトリックを監視するメトリック アラート ルールを作成し、そのスコープを次のいずれかのリージョンとして定義していて、アラート ルールのデータ処理がそのリージョン内で行われるようにするために、これらのリージョンのいずれかでアラート ルールを処理することを選択できます。

   • 北ヨーロッパ
   • 西ヨーロッパ
   • スウェーデン中部
   • ドイツ中西部

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

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

7. (省略可能) [カスタム プロパティ] セクションで、この警告ルールにアクション グループが含まれている場合、アラート通知ペイロードに含める独自のプロパティを追加できます。 これらのプロパティは、Webhook、Azure 関数、ロジック アプリのアクションなど、アクション グループによって呼び出されるアクションで使用できます。

   カスタム プロパティは、静的テキスト、アラート ペイロードから抽出された動的値、またはその両方の組み合わせを使用して、キーと値のペアとして指定されます。

   アラート ペイロードから動的値を抽出するための形式は ${<path to schema field>} です。 例: ${data.essentials.monitorCondition}。

   警告ルール用に構成されたアクション グループで共通スキーマが使用されているかどうかに関係なく、共通アラート スキーマの形式を使用して、ペイロードのフィールドを指定します。

   Note

   • 共通スキーマは、カスタム構成を上書きします。 カスタム プロパティと共通スキーマの両方を使用することはできません。
   • カスタム プロパティはアラートのペイロードに追加されますが、メール テンプレートや Azure portal のアラートの詳細には表示されません。
   • Service Health アラートはカスタム プロパティをサポートしていません。

   

   次の例では、カスタム プロパティの値を使用して、共通のアラート スキーマを使用するペイロードのデータを利用します。

   例 1

   この例では、"ウィンドウの開始時間" と "ウィンドウの終了時間" に関連するデータを含む "Additional Details" タグを作成します。

   • 名前: "Additional Details"
   • 値: "Evaluation 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 です"

次のステップを実行します。

1. [タグ] タブを選択します。

2. アラート ルール リソースに必要なタグを設定します。

   

次のステップを実行します。

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

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

   

メトリック アラート ルール名の次の制限をご検討ください。

• メトリック アラート ルール名は、作成後に変更 (名前変更) できません。
• メトリック アラート ルール名は、リソース グループ内で一意である必要があります。
• メトリック警告ルール名に次の文字を含めることはできません: * # & + : <> ? @ % { } \ /
• メトリック アラート ルール名の末尾の文字をスペースやピリオドにすることはできません。
• 結合されたリソース グループ名とアラート ルール名は、252 文字を超えることはできません。

複数の条件を含むメトリック アラート ルールでディメンションを使用する場合の制限事項

メトリック アラートでは多次元メトリックに対するアラートがサポートされ、複数の条件 (アラート ルールごとに最大 5 つ) の定義がサポートされます。

複数の条件を含むアラート ルールでディメンションを使用する場合は、次の制約を検討してください。

• 各条件内では、ディメンションごとに 1 つの値のみを選択できます。

• [現在および将来の値をすべて選択する] オプションは使用できません。 アスタリスク (*) を選択します。

• 異なる条件で構成されているメトリックで同じディメンションがサポートされている場合、構成されるディメンションの値は、関連する条件のこれらのすべてのメトリックに対して同じ方法で明示的に設定する必要があります。

  次に例を示します。

  • ストレージ アカウントで定義され、次の 2 つの条件を監視するメトリック アラート ルールを考えてみます。
    • 合計 トランザクション> 5
    • 平均 SuccessE2ELatency> 250 ミリ秒
  • 最初の条件を更新し、ApiName ディメンションが "GetBlob" と等しいトランザクションのみを監視したいと考えています。
  • Transactions と SuccessE2ELatency のメトリックではどちらも ApiName ディメンションがサポートされているため、両方の条件を更新して、 値を含む ApiName"GetBlob" ディメンションをそれらに指定する必要があります。