はじめに

ステートフルなログアラートについて、検証してみました。

ステートフルなログアラートは、1 年くらい前 (2021 年 4 月 28 日) に Public Preview されました。どのような機能なのかについては、まずは以下のアップデート情報をご覧ください。

ステートフル ログ アラート - この機能が有効になっている場合、発行されたアラートは、条件が満たされなくなった時点で自動的に解決されます。これは、メトリック アラートの既定の動作に似ています。

この機能を使う機会があり、つまづいた (勘違いした？) こともあったため、どのように設定すれば「ステートフル」なログアラートを実現できるか、ここで共有できればと思います。

なお、こちらの機能はこの投稿を執筆している時点でも Public Preview です。よって、この投稿の内容は今後変更される可能性があります。

ログアラートの状態と解決

ログアラートには、アラート ルールの条件を満すたびに発生する「ステートレス アラート」と、ある条件を満たすと自動で解決する「ステートフル アラート (今回検証するもの)」の 2 種類あります。

なお、「ステートフル アラート」は、30 分間アラート ルールの条件を満たさず、かつ 3 回連続してアラート ルールの条件を満たさない場合、自動的に解決します。「ステートフル アラート」を設定するためには、「アラートを自動的に解決する」オプションを有効にします。

このように読み解くと、何も考えずにログアラートが簡単にステートフルなものになると思えますが、ステートフルにするためにはひと工夫が必要です。

検証してみる

では、さっそく試してみます。

今回は 2 つのアラート ルールを比較します。どちらも検索クエリで抽出されたレコードが 1 件以上存在したらアラートを発報するものです。また、評価の頻度はどちらも「5 分置き」に設定します。

なお、ログのアラート ルールの作成、管理については、以下のドキュメントをご参照ください。

アラート ルール (1) 測定でログ検索結果の件数を集計する

ひとつ目は、検索クエリ結果のレコードを「測定 (Measure)」で集計する方法です。
メジャーで「テーブルの行」、集計の種類で「カウント」を選択することによって、ログの検索結果の件数を集計します。

「ステートフル アラート」を使うためには、「アラートを自動的に解決する」オプションを有効にする必要があるので、アラート ルールの詳細セクションの「アラートを自動的に解決する」にチェックを付けます。

アラート ルール (2) 検索クエリでログ検索結果の件数を集計する

ふたつ目は、検索クエリでログ検索結果の件数を集計する方法です。
検索クエリ内で集計関数 (ここでは Count) を使って、ログの検索結果の件数を集計します。

前述と同様に、「アラートを自動的に解決する」にチェックを付けます。

これでアラートを発報する準備が整いました。

イベント ログを登録する

監視対象の Windows 仮想マシンで、以下のコマンドを実行してイベント ログを登録します。

EVENTCREATE /ID 999 /L application /SO systeminfo /T ERROR /D "This is Test：テストです"

イベント ビューアーでも登録したイベント ログを確認します。

それでは、アラートが発報されるまで、しばらく待ちます。

アラート受信 (1) Fired (発報)

アラート ルールの条件を満たした場合の通知 (Fired) が届きました。どちらも想定どおりですね。
以下に実際に届いた通知メール (一部) を貼っておきます。

• 【通知メール】アラート ルール (1) 測定でログ検索結果の件数を集計する

• 【通知メール】アラート ルール (2) 検索クエリでログ検索結果の件数を集計する

アラート受信 (2) Resolved (解決済み)

しばらく経つと、解決済み (Resolved) の通知が届きました。ただ届いたのは「検索クエリでログ検索結果の件数を集計する」アラート ルールのほうのみでした。

• 【通知メール】アラート ルール (2) 検索クエリでログ検索結果の件数を集計する

また、ドキュメントに記載されている例のとおり、(評価の頻度が 5 分の場合) 40 分後に解決されました。

ちなみに、「測定でログ検索結果の件数を集計する」アラート ルールのほうは全然届きません。

2 つのアラートの状態を確認する

Azure ポータルで、それぞれのアラートの状態を確認すると、以下のように解決済みの通知を受け取った (2) のほうが「解決済み」となっていることが確認できます。

ステートフルなログアラートにするためのひと工夫

前述の 2 つのアラート ルール「測定でログ検索結果の件数を集計する」と「検索クエリでログ検索結果の件数を集計する」の違いは何でしょう。

アラートを解決するには、「条件が満たされていないこと」 を明確に示す必要があります。
それではそれぞれのアラート ルールで用いた検索クエリに注目してみます。

• アラート ルール (1) 測定でログ検索結果の件数を集計するの「検索クエリ」

Event
| where EventID == 999

(1) のほうは、条件に該当するレコードが存在する場合は 1 件以上のレコードが検索結果として返ってきますが、存在しない場合は検索結果としては何も返ってきません (検索結果として「null」が返ってくる)。

• アラート ルール (2) 検索クエリでログ検索結果の件数を集計するの「検索クエリ」

Event
| where EventID == 999
| count

(2) のほうは、条件に該当するレコードの存在する場合は検索結果として「1」以上の値が返ってきます。また、存在しない場合は検索結果として「0」が返ってきます。要するに、こちらはどのような結果となっても検索結果として必ず値が返ってきます。

このように比較した結果、(2)のように「条件が満たされていないこと」を明示する必要があるということがわかります。

まとめ

• ログアラートには「ステートレス アラート」と「ステートフル アラート」の 2 種類ある。
• 「ステートレス アラート」は、アラート ルールの条件を満すたびに発報する (Fired)。
• 「ステートフル アラート」は、アラート ルールの条件を満すと発報 (Fired) し、30 分間アラート ルールの条件を満たさず、かつ 3 回連続してアラート ルールの条件を満たさない場合、自動的に解決する (Resolved)。
• 「ステートフル アラート」を設定するためには、「アラートを自動的に解決する」オプションを有効にする。
• 「ステートフル アラート」を自動的に解決させるためには、「アラート ルールの条件が満たされていないこと」を明確に示す必要がある。

その他の参考文献

以下のドキュメントもご参考ください。