Azure Log Analytics のサマリールールを使ってログを集計する

はじめに

Log Analytics のサマリールール (Summary rules in Azure Monitor Log Analytics) は、2024 年 6 月にパブリックプレビューされた機能です。

執筆時点では、操作は REST 経由で提供され、その後 Bicep と Terraform でフォローされるようです。Azure CLI、Azure PowerShell、および Azure ポータルは、将来的に一般提供される予定とのこと。

Log Analytics のサマリールールとは

サマリールールを使うと、Log Analytics ワークスペースにインジェストされたログデータを定期的にあらかじめ定義したクエリに基づいて集計し、その結果を Log Analytics ワークスペースのカスタムログテーブルに送信できます。

使用例

ドキュメントでは、以下の使用例を示しています。

• 分析とレポート
  セキュリティやインシデントの分析、前月比および年次ビジネスレポートのために、大規模なデータセットと期間の分析とレポートを実行します

• 詳細ログのコスト削減
  低コストの基本ログ テーブルに必要な期間だけ保持します

• セキュリティとデータプライバシー
  共有可能な要約データのプライバシー詳細を難読化することで、プライバシーとセキュリティのためにテーブルレベルのアクセスを分離します

しくみ

集計ルールのしくみ より引用

上図のように、バッチが定期的に実行され、サマリールールで定義したクエリを集計期間ごとに実行して、その結果を指定したカスタムログテーブルに送信されます。

なお、サマリールールが取り扱えるログテーブル (クエリのソース、集計結果の送信先) は、サマリールールがデプロイされる Log Analytics ワークスペース内に限られます。

その他の制限と制約については、「制限事項と制約事項」 を確認しましょう。

サマリールールを作成

集計ルールを作成または更新するの手順に従って作成します。

この投稿では、仮想マシン (Windows) のパフォーマンス (CPU 使用率、メモリ使用量、ディスク空き容量) ¹ を 1 時間ごとに集計して、その結果をカスタムログテーブル「AggregateVMusages_CL」に送信します。

クエリを確認する

まず、Azure ポータルのログ検索で、サマリールールで定義するクエリが正常に動作することを確認します。なお、この投稿では、すべて同じカスタムログテーブルに出力するため、集計結果のカラムは揃えておきます。

以下のクエリ内の bin(TimeGenerated, 1h) は 1 時間ごとの集計結果を確認するためにあえて記述しています。
サマリールールを作成する際はクエリ実行時に集計期間が指定されるため、時間の範囲の指定は不要です。

CPU 使用率

Perf
| where CounterName == "% Processor Time"
  and ObjectName == "Processor Information"
  and InstanceName == "_Total"
| summarize AggregatedValue=avg(CounterValue) 
  by Computer, ObjectName, bin(TimeGenerated, 1h)

メモリ使用量

Perf
| where CounterName == "% Committed Bytes In Use"
| summarize AggregatedValue=avg(CounterValue) 
  by Computer, ObjectName, bin(TimeGenerated, 1h)

ディスク空き容量

Perf
| where CounterName == "% Free Space"
  and ObjectName == "LogicalDisk"
  and InstanceName == "_Total"
| summarize AggregatedValue=avg(CounterValue)
  by Computer, ObjectName, bin(TimeGenerated, 1h)

デプロイする

サマリールールのテンプレートをコピーして、カスタムテンプレートからのデプロイ から下図のようにデプロイします。

ひとつのルールにひとつのクエリを定義します。
よって、この投稿では 3 つのルール(Query はそれぞれ CPU 使用率 / メモリ使用量 / ディスク空き容量の平均値を求めるクエリを、Destination Table はすべて同じカスタムログテーブルを指定) をデプロイしました。

主要なパラメーターについては以下のとおり。その他のものについてはドキュメントをご確認ください。

パラメーター	設定内容	設定値 (例)
Workspace Name	サマリールールがデプロイされる Log Analytics ワークスペースの名前を入力する。	ws-demo202407
Query	サマリールールで実行するクエリを改行なしで入力する。時間の範囲の指定は Bin Size で指定するので、ここで指定するクエリには不要。	Perf | where CounterName == "% Processor Time" and ObjectName == "Processor Information" and InstanceName == "_Total" | summarize AggregatedValue=avg(CounterValue) by Computer, ObjectName
Bin Size	集計間隔と集計期間 (ルックバック時間の範囲) を選択する。分単位。	60
Destination Table	ターゲット (送信先) カスタムログテーブルの名前を指定する。この名前にはサフィックス _CL が必要。 ※他のルールと同じカスタムログテーブルを指定しても問題なし。	AggregateVMusages_CL

集計結果を確認する

しばらくして、サマリールールで指定した「ターゲット (送信先) カスタムログテーブル」を見ると、集計結果が登録されていることが確認できました。
この投稿では 3 つのルールをデプロイし、それぞれの Destination Table にすべて同じカスタムログテーブルを指定しましたが、すべての集計結果が問題なく登録されています。

ほぼ立ち上げたままでしたが、仮想マシンのパフォーマンスの変化も下図のように確認できました。

サマリールールの実行状況を監視する

サマリールールが正常に動作しているか監視することができます。

Log Analytics ワークスペースの診断設定で「Summary Logs (概要ログ)」にチェックを付けます。

収集先である LASummaryLogs テーブルを参照すると、サマリールールの実行状態 (Started: 開始、Succeeded: 成功、Failed: 失敗)、実行時間 (ミリ秒単位)、集計結果のレコード数などを確認することができます。

LASummaryLogs テーブルのスキーマは、以下のドキュメントをご参照ください。

まとめ

サマリールールを使ってログを集計したり、必要な情報のみを抽出したりすることで、今までの複雑だったクエリが分かりやすいものに改善されそうだと思います。

また、使用例にも挙がっていたように、容易に必要最低限の情報のみを共有 (アクセス制御) できるのはとても魅力的に感じました。

(余談ですが)
サマリールールを用いることによりログアラートでの複雑なクエリが改善 (簡素化) できるかなと思いましたが、

• 通知が (さらに) 遅延してしまう ²
• 送信先のカスタムログテーブルのプランが「Basic」だとアラート非対応。「Analytics」ならアラートに対応しているがコストがかさんでしまう

など、いろいろ懸念することがありそうなので断念。

1. Azure Log Analytics で Azure VM のパフォーマンスを分析する。 - Qiita を参考にさせていただきました。 ↩

2. インジェストの待ち時間に対して、サマリールールを実行する前の遅延時間が考慮されているため。 ↩