ログ検索アラート ルールを作成または編集する

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

監視対象のリソース、リソースからの監視データ、アラートをトリガーする条件を組み合わせて警告ルールを作成します。 次に、アクション グループとアラート処理規則を定義して、アラートがトリガーされたときに何が起こるかを決定できます。

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

Azure portal での警告ルール ウィザードへのアクセス

新しいアラート ルールを作成または編集する方法はいくつかあります。

ポータルのホーム ページから警告ルールを作成または編集する

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

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

   

特定のリソースから警告ルールを作成または編集する

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

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

   

既存の警告ルールを編集する

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

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

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

   

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

警告ルールのスコープを構成する

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

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

   

警告ルールの条件を構成する

1. [条件] タブで、[シグナル名] フィールドを選択するとき、[カスタム ログ検索] を選択するか、条件に別のシグナルを選択する場合、[すべてのシグナルを表示] を選択します。

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

   • [シグナルの種類]: [ログ検索] を選択します。
   • シグナル ソース: "カスタム ログ検索" と "ログ (保存されたクエリ)" シグナルを送信するサービス。 [シグナル名] を選択し、[適用] を選択します。

3. [ログ] ウィンドウで、アラートを作成する対象のログ イベントを返すクエリを作成します。 定義済みのアラート ルール クエリのいずれかを使用するには、[ログ] ペインの左側にある [スキーマとフィルター] ペインを展開します。 次に、[クエリ] タブを選択し、いずれかのクエリを選択します。

ログ検索警告ルール クエリの制限事項:

• ログ検索アラート ルール クエリは、"bag_unpack()"、"pivot()"、"narrow()" プラグインをサポートしていません。

• "AggregatedValue" という単語は予約語であり、ログ検索警告ルールのクエリでは使用できません。

• ログ警告ルールのプロパティ内のすべてのデータの合計サイズが 64KB を超えることはできません。

  

1. (省略可能) ADX または ARG クラスターに対してクエリを実行する場合、Log Analytics ではイベント タイムスタンプを含む列を自動的に識別できません。 クエリに時間の範囲フィルターを追加することをお勧めします。 次に例を示します。

       adx('https://help.kusto.windows.net/Samples').table    
       | where MyTS >= ago(5m) and MyTS <= now()
   

       arg("").Resources
       | where type =~ 'Microsoft.Compute/virtualMachines'
       | project _ResourceId=tolower(id), tags
   

   

   ARG または ADX のクエリを実行するログ検索アラート クエリのサンプルについては、ログ検索アラート クエリのサンプルに関するページを参照してください。

   クロス クエリ使用の制限事項を次に示します。

   • クロスサービス クエリの制限事項
   • Azure Resource Graph テーブルを Log Analytics ワークスペースと結合する
   • 政府機関向けクラウドではサポートされていません

2. [実行] を選択して、アラートを実行します。

3. [プレビュー] セクションにクエリ結果が表示されます。 クエリの編集が完了したら、[アラートの編集を続行する] を選択します。

4. [条件] タブが開き、ログ クエリが表示されます。 既定では、ルールによって過去 5 分間の結果の数がカウントされます。 要約されたクエリ結果がシステムで検出された場合、ルールは自動的にその情報で更新されます。

5. [測定] セクションで、次のフィールドの値を選択します。

   

   フィールド	説明
   測定値	ログ検索アラートでは、さまざまな監視シナリオで使用できる次の異なる 2 つのものを測定できます。 テーブル行: 返される行の数を使用して、Windows イベント ログ、Syslog、アプリケーション例外などのイベントを処理できます。 数値列の計算: 任意の数値列に基づく計算を使用して、任意の数のリソースを含めることができます。 たとえば、CPU の割合です。
   集計の種類	集計の粒度を使用して複数のレコードを 1 つの数値に集計するために、それらに対して実行される計算。 例として、合計、平均、最小、最大があります。
   集計の細分性	複数のレコードを 1 つの数値に集計する間隔。

6. (省略可能) [ディメンション別に分割] セクションでは、ディメンションを使用して、トリガーされた警告のコンテキストの指定に役立てることができます。

   

   ディメンションとは、追加のデータを含むクエリ結果の列です。 ディメンションを使用すると、警告ルールによってクエリ結果がディメンション値別にグループ化され、各グループの結果が個別に評価されます。 条件が満たされた場合、ルールはそのグループの警告を発生させます。 アラート ペイロードには、アラートをトリガーした組み合わせが含まれます。

   警告ルールごとに最大 6 つのディメンションを適用できます。 ディメンションにできるのは文字列または数値の列のみです。 数値または文字列型ではない列をディメンションとして使用したい場合は、それをクエリで文字列または数値に変換する必要があります。 複数のディメンション値を選択した場合は、その組み合わせによって生成される時系列ごとに独自のアラートがトリガーされ、個別に処理されます。

   たとえば次のような点です。

   • ディメンションを使用して Web サイトまたはアプリを実行している複数のインスタンスで CPU 使用率を監視できます。 各インスタンスは個別に監視され、CPU 使用率が構成された値を超える各インスタンスに対する通知が送信されます。
   • また、スコープ内の複数のリソースに適用される条件が必要な場合は、ディメンションごとに分割しない決断をすることも可能です。 たとえば、リソース グループ スコープ内の少なくとも 5 台のマシンで CPU 使用率が構成された値を超えていたら警告を発生させたい場合には、ディメンションは使用しません。

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

   • リソース ID 列: 一般に、警告ルールのスコープがワークスペースの場合、警告はワークスペースで発生します。 影響を受ける Azure リソースごとに個別の警告が必要な場合は、次のことを行うことができます。
     • ARM の [Azure リソース ID] 列をディメンションとして使う (このオプションを使うと、[Azure リソース ID] 列をディメンションとしてワークスペースでアラートが発生することに注意してください)。
     • Azure リソース ID プロパティでこれをディメンションとして指定します。これにより、クエリによって返されるリソースが警告のターゲットになるため、警告はワークスペースではなく、仮想マシンやストレージ アカウントなど、クエリによって返されるリソースに対して発生します。 このオプションを使用すると、ワークスペースが複数のサブスクリプション内のリソースからデータを取得する場合に、警告ルール サブスクリプションとは異なるサブスクリプションのリソースに対して警告をトリガーできます。

   フィールド	説明
   ディメンション名	ディメンションには、数値または文字列型の列を使用できます。 ディメンションを使用して、特定の時系列を監視し、生成されるアラートにコンテキストを提供します。
   演算子	ディメンションの名前と値に使用される演算子。
   ディメンション値	ディメンション値は、過去 48 時間のデータに基づいています。 カスタム ディメンション値を追加するには、[カスタム値を追加] を選択します。
   今後のすべての値を含める	選択したディメンションに追加される今後の値を含めるには、このフィールドを選択します。

7. [アラート ロジック] セクションで、次のフィールドの値を選択します。

   

   フィールド	説明
   演算子	クエリの結果は、数値に変換されます。 このフィールドで、しきい値と数値を比較するために使用する演算子を選択します。
   しきい値	しきい値の数値。
   評価の頻度	クエリの実行頻度。 1 分から 1 日 (24 時間) の任意の値に設定できます。

   Note

   1 分間のアラート ルールの頻度を使用するには、いくつかの制限があります。 アラート ルールの頻度を 1 分に設定すると、クエリを最適化するために内部操作が実行されます。 サポートされていない操作が含まれている場合、この操作によってクエリが失敗するおそれがあります。 クエリがサポートされない最も一般的な理由を次に示します。

   • クエリに search、union *、または take (limit) 操作が含まれている
   • クエリに ingestion_time() 関数が含まれている
   • クエリで adx パターンが使われている
   • クエリが、他のテーブルを呼び出す関数を呼び出している

   ARG または ADX のクエリを実行するログ検索アラート クエリのサンプルについては、ログ検索アラート クエリのサンプルに関するページを参照してください

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

   

   [アラートをトリガーする違反の数] の下にある、以下のフィールドの値を選択します。

   フィールド	説明
   違反の数	アラートをトリガーする違反の数。
   評価期間	その数の違反が発生する期間。
   クエリの時間の範囲のオーバーライド	アラートの評価期間をクエリの時間範囲と異なるものにしたい場合は、ここに時間範囲を入力します。 アラートの時間範囲は、最大 2 日間に制限されています。 クエリに時間範囲が 2 日より長い ago コマンドが含まれている場合でも、2 日間の最大時間範囲が適用されます。 たとえば、クエリ テキストに ago(7d) が含まれている場合でも、クエリは最大 2 日間のデータのみをスキャンします。 クエリでアラート評価よりも多くのデータが必要な場合は、時間の範囲を手動で変更できます。 クエリに ago コマンドが含まれている場合は、自動的に 2 日 (48 時間) に変更されます。

   Note

   ユーザーまたは管理者が Azure Policy に [Log Analytics ワークスペースを介した Azure ログ検索アラートではカスタマー マネージド キーを使用する必要がある] を割り当てた場合は、[Check workspace linked storage] (ワークスペースのリンクされたストレージの確認) を選択する必要があります。 そうしないと、ポリシー要件を満たしていないため、ルールの作成は失敗します。

9. プレビューのグラフには、時間の経過に伴うクエリ評価の結果が表示されています。 ディメンションで分割して得られた固有のアラートで、グラフの期間を変更したり、異なる時系列を選択したりできます。

   

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

警告ルールのアクションを構成する

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

   

警告ルールの詳細を構成する

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

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

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

   

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

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

      Note

      ID を使用するルールでは、警告ルール名に ";" という文字を含めることはできないことにご注意ください

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

   4. [ID] セクションで、ログ クエリを送信するためにログ検索アラート ルールが使用する ID を選びます。 この ID は、アラート ルールでログ クエリを実行するときに認証に使用されます。

      ID を選ぶときは、次の点に注意してください。

      • Azure Data Explorer にクエリを送信する場合は、マネージド ID が必要です。
      • アラート ルールに関連するアクセス許可を表示または編集できるようにする場合は、マネージド ID を使用します。
      • マネージド ID を使用しない場合、アラート ルールのアクセス許可は、ルールが最後に編集された時点で、ルールを編集した最後のユーザーのアクセス許可に基づきます。
      • マネージド ID を使用すると、ルールを最後に編集したユーザーにルールのスコープに追加されたすべてのリソースに対するアクセス許可がないためにルールが想定どおりに機能しない状況を回避できます。

      ルールに関連付けられている ID には、次のロールが必要です。

      • クエリで Log Analytics ワークスペースにアクセスする場合、ID には、クエリによってアクセスされるすべてのワークスペースに対する閲覧者ロールが割り当てられている必要があります。 リソース中心のログ検索アラートを作成する場合、アラート ルールは複数のワークスペースにアクセスする可能性があり、ID にはそのすべてに対する閲覧者ロールが必要です。
      • ADX または ARG クラスターに対してクエリを実行する場合、クエリによってアクセスされるすべてのデータ ソースに対して閲覧者ロールを追加する必要があります。 たとえば、クエリがリソース中心の場合、そのリソースに対する閲覧者ロールが必要です。
      • クエリでリモート Azure Data Explorer クラスターにアクセスする場合は、その ID が割り当てられている必要があります。
        • クエリによってアクセスされるすべてのデータ ソースの閲覧者ロール。 たとえば、クエリで adx() 関数を使ってリモート Azure Data Explorer クラスターを呼び出す場合、その ADX クラスターに対する閲覧者ロールが必要です。
        • クエリでアクセスするすべてのデータベースに対するデータベース閲覧者。

      マネージド ID の詳細については、Azure リソース用マネージド ID に関するページを参照してください。

      アラート ルールで使用される ID に対して、次のいずれかのオプションを選びます。

      ID	説明
      None	アラート ルールのアクセス許可は、ルールが編集された時点で、ルールを編集した最後のユーザーのアクセス許可に基づいています。
      システム割り当てマネージド ID	Azure では、このアラート ルールの新しい専用 ID が作成されます。 この ID はアクセス許可を持たず、ルールが削除されると自動的に削除されます。 ルールを作成した後、クエリに必要なワークスペースとデータ ソースにアクセスするために、この ID にアクセス許可を割り当てる必要があります。 アクセス許可の割り当ての詳細については、「Azure portal を使用して Azure ロールを割り当てる」を参照してください。
      ユーザー割り当てマネージド ID	アラート ルールを作成する前に、ID を作成し、ログ クエリに適したアクセス許可をそれに割り当てます。 これは通常の Azure ID です。 複数のアラート ルールで 1 つの ID を使用できます。 この ID は、ルールが削除されるときに削除されません。 この種類の ID を選ぶと、ルールに関連付けられている ID を選ぶためのペインが開きます。

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

   フィールド	説明
   作成時に有効化	アラート ルールの作成が完了したらすぐにその実行が開始されるようにするには、これを選択します。
   アラートを自動的に解決する (プレビュー)	アラートをステートフルにする場合に選択します。 アラートがステートフルの場合、特定の時間範囲で条件が満たされなくなった時点でアラートは解決されます。 時間の範囲は、アラートの頻度によって異なります。 1 分: アラート条件が 10 分間満たされていません。 5 ～ 15 分: アラート条件が 3 つの頻度の期間にわたって満たされていません。 15 分～ 11 時間: アラート条件が 2 つの頻度の期間にわたって満たされていません。 11 ～ 12 時間: アラート条件が 1 つの頻度の期間に満たされていません。 ステートフルなログ検索アラートには、次の制限があることに注意してください。 - 評価ごとに最大 300 個のアラートをトリガーできます。 - fired アラート条件で最大 5,000 個のアラートを設定できます。
   アクションのミュート	アラート アクションが再度トリガーされるまでの待機時間を設定するには、これを選択します。 このチェック ボックスを選択すると、アラートが発生してから再度アクションをトリガーするまでの待機時間を選択するための [アクションのミュート期間] フィールドが表示されます。
   ワークスペースのリンクされたストレージの確認	アラートのログ ワークスペースのリンクされたストレージが構成されているかどうかを選択します。 リンクされたストレージが構成されていない場合、ルールは作成されません。

4. (省略可能) [カスタム プロパティ] セクションで、この警告ルールにアクション グループが含まれている場合、アラート通知ペイロードに含める独自のプロパティを追加できます。 これらのプロパティは、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. [タグ] タブで、アラート ルール リソースに必要なタグを設定します。

   

警告ルールを確認して作成する

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

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

   

次のステップ

• ログ検索アラート クエリのサンプル
• アラート インスタンスの表示と管理