現在Azure Monitorでカスタムログの収集というと、Log Analyticsエージェント(MMA/OMS)を使う方法とAzure Monitor Agent(AMA)を使う方法の2パターンが存在。しかし、MMAについては2024年8月末にリタイアとなるため、AMAを使うパターンが推奨。
AMAを利用するカスタムログの収集については、下記に方法がまとまっていましたがわかりづらい点があるためメモとして残しておく。
カスタムテーブルの作成
- DocsではPowerShellで作成する方法が紹介されている
- Azure Portalだとデータ収集ルール(DCR)とデータ収集エンドポイント(DCE)も同時に作成されてしまうので、確かに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 Monitorの画面から作成
- カスタムログの収集にはDCEの作成も必要(らしい)
- リソースを追加すると、VMにおいてマネージドIDが有効になる
ポータルは、既存のユーザー割り当て ID と共に、ターゲット リソースでシステム割り当てマネージド ID を有効にします (該当する場合)。 既存のアプリケーションでは、ユーザー割り当て ID を要求で指定しない限り、マシンでは既定でシステム割り当て ID が代わりに使用されます。
データソース
- ファイルパターンにはワイルドカードが使えるが、ディレクトリ名には使えない
- C:\DirA\DirB*log.txtのような形で表現可能
- テーブル名には既存のテーブルしか受け入れられないため、先の手順でカスタムテーブルを作成する必要がある
ログファイルの配置
- 対象VMのパスにサンプルファイルを配置
Log Analytics側での確認
- ログファイルの配置からLog Analytics側へのデータ収集は最大5分かかる
- カスタムテーブルにクエリを書いて存在を確認
おわり
- こういうエージェントによるデータ収集待ちの構成はタイムラグがつきもので、構成自体に失敗しているのかすぐにわからない点がハラハラする
Discussion