次の方法で共有

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

  • [アーティクル]

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

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

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

前提条件

アラート ルールを作成または編集するには、次のアクセス許可が必要です。

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

Azure portal でアラート ルール ウィザードにアクセスする

アラート ルールを作成または編集するには、複数の方法があります。

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

  1. Azure Portal で、[モニター] を選択します。
  2. 左側のペインで、[アラート] を選びます。
  3. [+ 作成]>[アラート ルール] を選択します。

ポータルのホーム ページからアラート ルールを作成する手順を示すスクリーンショット。

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

  1. Azure portal でリソースに移動します。
  2. 左側のペインで、[アラート] を選びます。
  3. [+ 作成]>[アラート ルール] を選択します。
  4. アラート ルールの範囲は、選択したリソースに設定されます。 アラート ルールの条件の設定を続けます。

選んだリソースからアラート ルールを作成する手順を示すスクリーンショット。

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

  1. Azure portal で、ホーム ページまたは特定のリソースから、左側のペインの [アラート] を選びます。

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

  3. 編集するアラート ルールを選んでから、[編集] を選びます。

    既存のログ検索警告ルールの編集手順を示すスクリーンショット。

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

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

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

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

  2. 適用を選択します。

アラート ルールの条件を構成する

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

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

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

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

    ログ検索アラート ルール クエリについては、次の制限に注意してください。

    • ログ検索アラート ルール クエリでは、bag_unpack()、pivot()、narrow() はサポートされていません。
    • ログ検索アラート ルール クエリでは、ago() は timespan リテラルでのみサポートされています。
    • AggregatedValue は予約語です。 ログ検索アラート ルールのクエリでは使用できません。
    • ログ検索アラート ルールのプロパティ内の全データの合計サイズは、64 KB を超えることはできません。
    • ログ検索アラートの KQL クエリでカスタム関数を定義する際は、now() などの相対時間句を含む関数コードに注意する必要があります。 ログ検索アラートの KQL クエリ自体において定義されていない相対時間句があるカスタム関数では、クエリ結果に不整合が生じ、アラート評価の精度と信頼性が影響を受ける要因となる場合があります。 そのため、次のようになります。
      • アラートが正確かつタイムリーに行われるよう、常にログ検索アラートの KQL クエリ内にある相対時間句を直接定義します。
      • 関数内で時間範囲が必要な場合は、パラメーターとして渡し、関数で使用します。

    新しいログ検索アラート ルールの作成時のクエリ ペインを示すスクリーンショット。

  4. (省略可能) Azure Data Explorer または Azure Resource Graph クラスターのクエリを実行する場合、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

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

    Azure Data Explorer と Resource Graph のサンプル ログ検索アラート クエリを使用できます。

    クロスサービス クエリは、政府機関向けクラウドではサポートされていません。 制限について詳しくは、クロスサービス クエリの制限事項に関する記事と、「Azure Resource Graph テーブルを Log Analytics ワークスペースと結合する」をご覧ください。

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

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

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

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

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

    新しいログ検索アラート ルールの作成時の測定オプションを示すスクリーンショット。

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

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

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

    次に例を示します。

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

    一般に、アラート ルールのスコープがワークスペースの場合、アラートはワークスペースで発生します。 影響を受ける Azure リソースごとに個別の警告が必要な場合は、次のことが可能です。

    • Azure Resource Manager の [Azure リソース ID] 列をディメンションとして使います。 このオプションを使うと、アラートは [Azure リソース ID] 列をディメンションとしてワークスペースで発生します。

    • [Azure リソース ID] プロパティで、ディメンションとしてアラートを指定します。 このオプションを使うと、クエリが返すリソースがアラートのターゲットになります。 その場合、アラートは、ワークスペースではなく、仮想マシンやストレージ アカウントなど、クエリが返すリソースに対して発生します。

      このオプションを使うと、ワークスペースが複数のサブスクリプションのリソースからデータを取得する場合に、アラート ルール サブスクリプションとは異なるサブスクリプションのリソースに対してアラートをトリガーできます。

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

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

    新しいログ検索アラート ルールでディメンションによって分割するためのセクションを示すスクリーンショット。

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

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

    新しいログ検索アラート ルールでのアラート ロジックのセクションを示すスクリーンショット。

    Note

    頻度は、アラートが毎日実行される特定の時刻ではありません。 どれくらい頻繁にアラート ルールが実行されるかです。

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

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

    Azure Data Explorer と Resource Graph のサンプル ログ検索アラート クエリを使用できます。

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

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

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

    新しいログ検索アラート ルールの詳細オプションのセクションを示すスクリーンショット。

    Note

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

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

    新しいアラート ルールのプレビューを示すスクリーンショット。

  13. 完了 を選択します。 アラート ルールの条件を構成したら、アラート ルールの詳細を構成してアラートの作成を完了できます。また、必要に応じて、アラート ルールにアクションとタグを追加することもできます。

アラート ルールのアクションを構成する

[アクション] タブでは、必要に応じて、アラート ルールのアクション グループを選択または作成できます。

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

アラート ルールの詳細を構成する

  1. [詳細] タブの [プロジェクトの詳細] で、[サブスクリプション] と [リソース グループ] の値を選びます。

  2. [アラート ルールの詳細] で:

    1. [重大度] の値を選びます。

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

      Note

      ID を使うルールでは、[アラート ルール名] の値にセミコロン (;) 文字を含めることはできません。

    3. [リージョン] の値を選びます。

  3. [ID] セクションで、ログ検索アラート ルールがログ クエリの送信時の認証に使う ID を選びます。

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

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

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

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

    マネージド ID について詳しくは、Azure リソース用マネージド ID に関する記事をご覧ください。

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

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

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

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

    フィールド 説明
    作成時に有効化 アラート ルールの作成が終わったらすぐにその実行が開始されるようにするには、このオプションを選びます。
    アラートを自動的に解決する アラートをステートフルにするには、このオプションを選びます。 アラートがステートフルの場合、特定の時間範囲で条件が満たされなくなった時点でアラートは解決されます。 時間の範囲は、アラートの頻度によって異なります。
    1 分: アラート条件が 10 分間満たされていません。
    5 から 15 分: 警告の条件が 3 つの頻度の期間にわたって満たされていません。
    15 分から 11 時間: 警告の条件が 2 つの頻度の期間にわたって満たされていません。
    11 ～ 12 時間: アラート条件が 1 つの頻度の期間に満たされていません。

    ステートフルなログ検索アラートには次の制限があることに注意してください。
    アクションのミュート アラート アクションが再度トリガーされるまでの待機時間を設定するには、このオプションを選びます。 表示される [アクションのミュート期間] フィールドで、アラートが発生してから再度アクションをトリガーするまでの待機時間を選びます。
    ワークスペースのリンクされたストレージを確認する アラートに対するワークスペースのリンクされたストレージが構成されている場合、このオプションを選びます。 リンクされたストレージが構成されていない場合、ルールは作成されません。

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

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

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

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

    Note

    • カスタム プロパティはアラートのペイロードに追加されますが、メール テンプレートや Azure portal のアラートの詳細には表示されません。

    新しいアラート ルールを作成するカスタム プロパティを示すスクリーンショット。

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

    この例では、ウィンドウの開始時間とウィンドウの終了時間に関連するデータを含む [追加情報] タグを作成します。

    • 名前: Additional Details
    • 値: Evaluation windowStartTime: ${data.alertContext.condition.windowStartTime}. windowEndTime: ${data.alertContext.condition.windowEndTime}
    • 結果は次のとおりです。AdditionalDetails:Evaluation windowStartTime: 2023-04-04T14:39:24.492Z. windowEndTime: 2023-04-04T14:44:24.492Z

    この例では、アラートが解決または発生した理由についてのデータを追加します。

    • 名前: Alert ${data.essentials.monitorCondition} reason
    • 値: ${data.alertContext.condition.allOf[0].metricName} ${data.alertContext.condition.allOf[0].operator} ${data.alertContext.condition.allOf[0].threshold} ${data.essentials.monitorCondition}. The value is ${data.alertContext.condition.allOf[0].metricValue}
    • 考えられる結果:
      • Alert Resolved reason: Percentage CPU GreaterThan5 Resolved. The value is 3.585
      • Alert Fired reason": "Percentage CPU GreaterThan5 Fired. The value is 10.585

警告ルール タグを構成する

[タグ] タブでは、必要に応じて、アラート ルール リソースに必要なタグを設定できます。

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

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

  1. [確認と作成] タブで、ルールが検証されます。 問題がある場合は、元に戻って修正します。

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

    新しいアラート ルールを確認および作成するためのタブを示すスクリーンショット。

関連するコンテンツ