Azure の診断設定について調べておく必要があったので、メモを残しておきたいと思います。
データ収集ルール (DCR) を使用した情報の取得を検討する必要があり、基本となる情報は次のドキュメントの内容となります。
- Azure Monitor エージェントの概要
- Azure Monitor でのデータ収集ルール (DCR)
- Azure Monitor の Log Analytics ワークスペース データ エクスポート
Contents
診断設定の設定状況の確認
診断設定の設定状況ですが、次のような方法で確認することができます。
- Azure モニター のブレード → 診断設定
- リソースグループのブレード → 診断設定
これによりどのリソースに対して診断設定が行われているかを確認することが可能となり、未設定のリソースを把握することができます。
ただし、診断設定が可能なすべてのリソースが表示されているわけではないようですので、全リソースで設定がされているかの最終的なチェックとしては利用できないかもしれません。
Azuer VM の診断設定について
Azure Diagnostics 拡張機能を使用した診断情報の取得
PaaS のリソースについては、診断設定のみで完結しますが、Azure VM の診断設定については拡張機能により実現がされており Azure Diagnostics 拡張機能 (WAD / LAD) をインストールする必要があります。
この拡張機能をインストールすることで、診断設定を使用することが可能となり、診断設定で得取得可能なデータを Log Analytics ワークスペースや Azure ストレージに保存することが可能となります。
Linux の診断設定の考慮点
診断情報を容易に保存することができる便利な機能なのですが「Windows と Linux で同等の設定により情報を取得するように設定をしたい」というような要件がある場合には注意が必要となります。
Windows については現時点では特にアナウンスはないのですが、Linux の Diagnostics 拡張機能 (LAD) には Linux Diagnostic Extension 4.0 を使用して、メトリックとログを監視する のドキュメントに次の記載があります。
Python の要件
Linux Diagnostic Extension には、Python 2 が必要です。 お使いの仮想マシンで使用されているディストリビューションに Python 2 が含まれていない場合は、それをインストールします。
注意
現在、Linux Diagnostic Extensions (LAD) のすべてのバージョンを、Python 3 を既にサポートしている新しい Azure Monitoring Agent と収束する予定です。 LAD は非推奨となる予定であり、発表と承認待ちの状態です。
LAD を使用するためには、Python 2 が必要となり、現状新しく展開をするようなバージョンの Linux では標準で Python 2 はインストールされていないのではないでしょうか。
Python 2 のサポートも終了していますため、診断機能を使用するためにインストールすることもなかなか厳しくなっているのではないでしょうか。
そのため、現状で Windows と Linux の VM で同等の内容で診断ログの取得を行いたいという場合には、Azure Monitor の「データ収集ルール」(DCR) を中心としたデータ取得を検討する必要があります。
Azure Monitor エージェント拡張機能を使用した診断情報の取得
前述のとおり、Linux Diagnostics 拡張機能 (LAD) については、今後は Azure Monitor エージェント (AMA) に収束する予定となっており、Linux 環境については AMA を使用した診断情報の取得に切り替えを検討する必要があります。
Windows と Linux で同等の設定により診断情報を取得したいという場合には、Windows Diagnostics 拡張機能 (WAD) を使用して取得できる情報についても、AMA での取得を検討する必要があるのではないでしょうか。
Azure Monitor エージェントについては、Azure Monitor エージェントの概要 で情報を確認することができます。
データの収集方法については Azure Monitor エージェントを使用して仮想マシンからイベントとパフォーマンス カウンターを収集する から確認することができます。
基本的な作業の流れとしては次のようになります。
- 「データ収集ルール」 (DCR) のリソースを作成する
- 「データソース」として取得する情報と、取得先の Log Analytics ワークスペースを指定する
- 「リソース」として、取得対象となる VM を指定する
Azure Diagnostics 拡張機能と Azure Monitor エージェント拡張機能によるデータ収集の違い
この拡張機能の違いですが、大きな違いとしては「データの格納先の違い」ではないでしょうか。
Azure Diagnostics 拡張機能を使用して診断設定を行う場合、Log Analytics ワークスペースと Azure ストレージのいずれかまたは両方に情報を保存することができます。
しかし、Azure Monitor エージェント拡張機能を使用して データ収集ルール (DCR) による情報の収集となった場合、データの保存先は Log Analytics ワークスペース (プレビューで Azure Monitor メトリックも選択可能) となります。
Azure ストレージに情報を保存をすることができません。
DCR を使用する場合の Azure ストレージへのデータ保存 (アーカイブ) 方法
Log Analytics ワークスペースは頻繁に収集されるデータを長期間保存するとコストが高くなり、コストとの兼ね合いで、メトリックやログのようなデータについては直近の情報のみを保存しておくことが多いです。
長期保管用として、Log Analytics のデータを Azure ストレージにデータを保存しておきたい場合には、Log Analytics ワークスペースの データエクスポート機能 を使用して Azure ストレージにデータを保存 (アーカイブ) する必要があります。
現状、エクスポートのルールは「テーブルの内容をストレージアカウントにシンプルにエクスポート」となっており、テーブルの内容をフィルターしてエクスポートすることはできないようです。
概要 に次のように記載されており、基本動作としてはフィルターなしでエクスポートとなっていました。
データは、フィルターなしでエクスポートされます。 たとえば、SecurityEvent テーブルに対してデータ エクスポート ルールを構成すると、その構成時点から、SecurityEvent テーブルに送信されたすべてのデータがエクスポートされます。 または、エクスポートしたデータを Log Analytics ワークスペースやエクスポート先に送信する前に、受信データに適用される変換をワークスペースで構成することで、フィルター処理または変更することもできます。
また、エクスポート先のストレージのコンテナーの構成については ストレージ アカウント に記載されているように固定となっており、データをエクスポートするコンテナーやデータの収集単位 (PT5M) を明示的に変更することはできません。
Event テーブルの内容を目的に応じて格納するストレージを変更する方法の案
DCR で Windows のイベントログを Log Analytics ワークスペースに収集した場合、イベントログの情報は「Event」というテーブルに保存がされ、アプリケーション / システム / セキュリティの内容がこのテーブルにまとめられた状態で取得が行われます。
セキュリティの内容だけ、他のログとは異なるストレージに保存しておきたいというような場合、Azure Diagnostics 拡張機能を使用した診断設定であれば、セキュリティのログを出力する診断設定を新しく設定し、そのログの出力先をセキュリティ用のストレージに設定するということで実現することができるのではないでしょうか。
しかし、DCR + Log Analytics のデータエクスポートだと、そのような設定をエクスポートで行うことができません。
DCR は Log Analytics ワークスペースしか指定をすることができず、指定した Log Analytics ワークスペースの Event テーブルにイベントログのすべての情報が格納されます。
Log Analytics のデータエクスポートは、テーブルを指定してストレージにエクスポートするというものとなっており、イベントログの一部の種別の情報のみエクスポート先を変更するということができません
Logc Apps を使用した方法
ストレージへのデータエクスポートを調整する例としては、Logic Apps を使用した Log Analytics ワークスペースからストレージ アカウントへのデータのエクスポート が公開されています。
この方法は Log Analytics ワークスペースから必要となる情報を KQL で抽出し、抽出した情報の出力先として任意のストレージアカウントのコンテナーを指定することができます。
Logic Apps のリソースの作成に必要性と、コネクタの制限 により抽出対象となるデータ件数 /サイズの上限が決まっていますが、ストレージに柔軟にデータをエクスポートすることができます。
DCR の出力先の Log Analytics ワークスペースを用途ごとに分ける
Logc Apps を使用しない方法としては、DCR の取得先として指定する Log Analytics ワークスペース用途ごとに分けるということができるのではないでしょうか。
Log Analytics ワークスペースのテーブルが必要となるログしか格納されていない状態にして、エクスポートを行うという方法があるのではないでしょうか。
(例: アプリケーション / システムのイベントログと、セキュリティのイベントログを出力する DCR を別にし、出力先の Log Analytics ワークスペースを分けて、テーブルのエクスポートを行う)
Azure Monitor でのデータ収集の変換 を使用して、データの変換を行うことで、上手く対応することができないか検証してみたのですが、私が必要となる要件を満たす設定を見つけることができませんでした。
DCR の変換を検証する場合は Azure Monitor でのデータ収集ルールの構造 も参考となります。
診断ストレージの保持設定
現状、診断の設定を行い、Azure ストレージにデータを保持する場合、診断設定としては保持期間を指定することはできなくなっており、2025/09/30 で保持期間の機能はすべての環境で無効となるということがアナウンスされています。
重要
非推奨のタイムライン。
- 2023 年 3 月 31 日 ? 診断設定ストレージの保持機能は、ログ データの新しい保持規則を構成するために使用できなくなります。 これには、ポータル、CLI PowerShell、および ARM と Bicep テンプレートの使用が含まれます。 保持設定を構成した場合でも、ボータルでそれらを表示して変更することができます。
- 2024 年 3 月 31 日 ? これらを 0 に変更しない限り、API (CLI、Powershell、またはテンプレート) または Azure portal を使用して保持設定を構成することはできなくなります。 既存の保持規則は引き続き尊重されます。
- 2025 年 9 月 30 日 ? 診断設定ストレージの保持機能のすべての保持機能は、すべての環境で無効になります。
Azure ストレージに保存したデータの保持期間については、ライフサイクル管理ポリシー を使用して実装する必要があります。
診断データの格納先のテーブル名等について
診断データの格納についての基本的な情報については Azure リソース ログ データを送信する から確認をすることができます。
Log Analytics にデータを格納する際のテーブル情報については Azure Monitor リソース ログ/ログ分析テーブル / Azure Monitor ログ分析のサンプル クエリ から確認することができます。
Azure ストレージにデータを格納する場合のコンテナーの命名ルールについては、Azure Storage への送信 / Azure リソース ログの共通およびサービス固有のスキーマ から確認することができます。
SecurityEvent テーブルについて
Azure Monitor でのデータ収集の変換 などのドキュメントでは SecurityEvent (Microsoft-SecurityEvent) テーブルが例として取り上げられることがあります。
SecurityEvent に記載されていますが、このテーブルは標準のテーブルではなく、次の機能が有効になっている場合に情報が取得されます。(Defender Cloud for Server の情報の取得先として指定した Log Analytics ワークスペースでも作成されているはずです)
Azure Security Centerまたは Azure Sentinel によって Windows マシンから収集されたセキュリティ イベント。
これについては、Azure Monitor エージェントを使用して Windows セキュリティ イベントを収集するにはどうすればよいですか? にも記載がありました。
セキュリティ イベントの Log Analytics ワークスペースへの送信時に、新しいエージェントを使用して収集するには、次の 2 つの方法があります。
- Azure Monitor エージェントを使用すると、他の Windows イベントと同じように、セキュリティ イベントをネイティブに収集できます。 これらは Log Analytics ワークスペースの ‘Event’ テーブルに送信されます。
- ワークスペースで Microsoft Sentinel が有効になっている場合、セキュリティ イベントは、Azure Monitor エージェントを介して代わりに
SecurityEventテーブルに送信されます (Log Analytics エージェントを使用した場合と同じです)。 このシナリオでは、最初にソリューションを有効にする必要があります。
通常の診断設定として使用している Log Analytics ワークスペースでは SecurityEvent テーブルは存在しておらず、Windows のセキュリティのイベントログの内容については Event テーブルに格納されています。
データ収集ルールの構造では、次のような記載があります。
データが送信される
destinationプロパティに指定されたワークスペース内のテーブルを記述します。outputStreamの値は、標準の Log Analytics テーブルにデータを取り込む場合はMicrosoft-[tableName]形式、カスタム テーブルにデータを取り込む場合はCustom-[tableName]になります。 ストリームごとに許可される宛先は 1 つのみです。
SecurityEvent は 「Microsoft-SecurityEvent」として利用することができますが、初期状態としてこのテーブルは存在しておらず、該当の情報を取得するための機能の取得先として設定している Log Analytics ワークスペースのみで存在しているということになります。
仮想マシンであれば 仮想マシン に記載されているテーブルが標準で活用することができるテーブルとなるかと思います。
テーブル名だけでみると活用したいと思う名称が出てくるかと思いますが、そのテーブルを使用する機能が有効になっているかどうかは意識する必要がありそうです。