現在Azure Monitorでカスタムログの収集というと、Log Analyticsエージェント(MMA/OMS)を使う方法とAzure Monitor Agent (AMA)を使う方法の2パターンが存在します。しかし、MMAについては2024年8月末にリタイアとなるため、AMA を利用するのが現在の推奨です。
AMAを利用するカスタムログの収集については、MSLearn[1] に方法がまとまっていましたが、わかりづらい点があるためメモとして記載しておきます。
カスタムテーブルの作成
MSLearn ではPowerShellで作成する方法が紹介されています。しかしながら、Azure portal から作成するとデータ収集ルール (DCR) およびデータ収集エンドポイント (DCE) も同時に作成されてしまうため、PowerShell のコマンドでテーブルの作成を行う方が意図した挙動になると思います。
PowerShell で次のコマンドを実行します。必要に応じて適宜名称変更等を行ってください。
$tableParams = @'
{
"properties": {
"schema": {
"name": "{TableName}_CL",
"columns": [
{
"name": "TimeGenerated",
"type": "DateTime"
},
{
"name": "RawData",
"type": "String"
}
]
}
}
}
'@
Invoke-AzRestMethod -Path "/subscriptions/{subscription}/resourcegroups/{resourcegroup}/providers/microsoft.operationalinsights/workspaces/{WorkspaceName}/tables/{TableName}_CL?api-version=2021-12-01-preview" -Method PUT -payload $tableParams
コマンド実行後きちんとテーブルが作成されていることを確認します。現時点ではまだ何も設定していないので、テーブルのスキーマだけが作成された状態です。
DCR の作成
Azure portal で DCR を作成します。カスタムログの収集には DCE が必要となります。事前に作成しておきましょう。リソースとして VM を追加すると、VM のマネージド ID が有効になります。
ポータルは、既存のユーザー割り当て ID と共に、ターゲット リソースでシステム割り当てマネージド ID を有効にします (該当する場合)。 既存のアプリケーションでは、ユーザー割り当て ID を要求で指定しない限り、マシンでは既定でシステム割り当て ID が代わりに使用されます。
データソース
ファイル名にはワイルドカードが使えるが、ディレクトリ名にはワイルドカードが使えません。つまり、対象ファイルを C:\DirA\DirB\*log.txt のような形で表現可能ということです。
例えば、Docker コンテナーのログを監視したい場合には、/var/lib/docker/containers/${container_id}/${container_id}-json.log を監視したくなりますが、ディレクトリ名にワイルドカードが使えないため、${container_id} の部分をどのように全取得するのかは実装を考える必要があります。Docker のログをテキストではなくホスト マシン上の Syslog に指定するのも一案かと思います。本筋ではないので深入りはしません。
テーブル名には既存のテーブルしか受け入れられないため、先にカスタムテーブルを作成する必要があります。
ログファイルの配置
対象 VM の設定したファイル パスにサンプル ファイルを配置します。
Log Analytics ワークスペースでの確認
ログ ファイルの配置から Log Analytics 側へのデータ収集は最大5分かかる 2 時間ほどかかる場合があるようです[2]。検証には時間と心の余裕が必要です。
カスタムテーブルにクエリを書いて存在を確認します。
おわり
こういうエージェントによるデータ収集待ちの構成はタイムラグがつきもので、構成自体に失敗しているのかすぐにわからない点が難しいポイントです。時間と心に余裕のあるうちに検証をするか、早めにサポートに相談しましょう。
Discussion