本記事について
Azure Log Analytics や Microsoft Sentinel を活用するにあたり、よくある課題がエージェントやコネクターで取り込めないログの格納です。従来は Log Analytics エージェントのカスタムログ機能が多く使われていましたが、こちらはスケーラビリティなどいくつかの課題がありました。そんな中、新しくリリースされた Azure Monitor Agent (AMA) と Data Collection Rule (DCR) ベースのテキストログ収集は、より高いスケーラビリティがあり、今後カスタムログを取りこむ方式としてメインの方法となっていくことが予想されます。この機能は、新しい Log Ingest API をベースにしており、この API は呼び出しの最大サイズやデータ量が明確に定義されていて、より安心してご活用いただけます。
AMA と DCR ベースのテキストログの取り込みの方法については、下記公式ドキュメントにて基本的なことは書かれています。
また、公式ドキュメントで分かりにくい点など、Zenn の下記の記事でその設定方法の詳細が解説されています。
本記事では、上記の記事の内容を踏まえたうえで、この新しくリリースされた Azure Monitor Agent (AMA) と Data Collection Rule (DCR) ベースのテキストログ収集について、特に活用するにあたり抑えておきたいポイントを見ていきます。
AMA と DCR ベースのテキストログで、おさえておくべきポイント
ポイントは下記の3点になります。
- デフォルトの取り込み先は、TimeGenerated と RawData の２列。
- TimeGenerated 列は、Azure Log Analytics が自動的に格納。
- RawData 列にすべてのデータが入るが、Log Analytisc エージェントのカスタムログと異なり、設定時に区切りなどの設定を入れられず、またファイルの先頭行もログのレコードとして格納されてしまう。
これらの特徴のため、デフォルトのテーブルそのままでデータを扱うのがやや難しくなっています。本記事では、Log Analytics の関数機能を使って、ログ格納後に別のテーブル名としてデータを扱う方法を合わせて見ていきます。
AMA と DCR ベースのテキストログによるログデータの取り込み
今回は、例として下記のようなコンマ区切りのログファイル (.log) を収集することを考えます。
Time, User, Result
2023-03-25 14:42:00, Yoshiaki Oi, Success
2023-03-25 17:12:00, Taro Maikuro, Failure
まず、カスタムログ用のテーブルを作成します。上記の２記事では、どちらも PowerShell にてテーブルを作成していますが、本記事では Portal の画面で作成していくことにします。
事前準備として、Log Analytics ワークスペースと同じリージョンにデータ収集エンドポイントを作っておきます。これは Log Ingest API を利用するサービスでは必要になるコンポーネントです。Azure Monitor でデータ収集エンドポイントへ進み、作成をクリックし、リソース名やリソースグループ名を入力して作ります。
次に、Log Analytics ワークスペースの画面で、新しいカスタムログ (DCR) を選択します。
基本タブでは、テーブル名やデータ収集ルール、データ収集エンドポイントを設定します。データ収集ルールを新規で作る場合はリソースグループと名前を設定します。
次のスキーマと変換では、下記のような JSON ファイルを手元で作りアップロードします。
{
"TimeGenerated": "2023-01-01 00:00:00",
"RawData": "string"
}
次へ進み、作成します。
次に、作成されたデータ収集ルールを変更します。Azure Monitor のデータ収集ルールに行きます。そして、さきほど作成したデータ収集ルールをクリックします。
まずリソースタブでテキストログのソースとなるサーバーを選びます。
次にデータソースで、＋追加をクリックします。
データソースの種類をカスタムテキストログにすると諸々の入力項目が出てきます。ファイルパターンはログファイルのパスを指定します。ファイル名はアスタリスクの利用も可能です。テーブル名は、さきほど作成したもの (入力値に_CLを付けたもの) になります。Transform は今回はそのままにしておきます。
ターゲットは送り先の Log Analytics ワークスペースを選びます。これでデータソースを追加します。以下のように追加されます。
Azure 側の準備はこれで完了です。対象のサーバーに収集したいログファイルを準備します。
数分待つと対象のテーブルにデータが格納されています。
ここでさきほどのポイントで触れたように、TimeGenerated には Azure Monitor が入れた時間、RawData にすべてのログデータが入っていること、ログの先頭行も一レコード扱いされていることをそれぞれ確認できます。これらに対処する方法のひとつとして、次に関数機能を見ていきます。
関数機能によるテーブルの整理
Log Analytics の関数機能は、クエリから別のクエリを呼び出すための機能です。
予め特定のテーブルを整理するクエリを関数として登録しておくと、その関数名をあたかもテーブル名のようにクエリを書くことができます。
今回は下記のクエリを関数として保存しておきます。
CustomLogTest1_CL
| parse RawData with TimeGenerated_raw "," User "," Result
| extend TimeGenerated = todatetime(TimeGenerated_raw)
| where TimeGenerated_raw != "Time" and isnotempty(TimeGenerated_raw)
| project-away TimeGenerated_raw, RawData
ここでこの関数は、parse 句により、TimeGenerated_raw, User, Result という３つの列を抽出して作っています。コンマ区切りのデータであれば、parse 句だけでも十分扱えるかと思います。ただ、TimeGenerated は TimeGenerated 列に datetime 型データとして取り込みたいので別途処理をし、不要になった RawData 列は削除しています。また、先頭行の削除はいろいろなクエリの下記方ができるかと思いますが、上記では where 句で削除しています。
そして、関数名を CustomLogTest1 として保存します。
あとは、CustomLogTest1 とクエリを打つだけできれいに整形されたデータを取得できます。
最後に
本記事では、AMA と DCR ベースのテキストログの取り込みと関数機能を使ったテーブルの整理の方法を見ていきました。本記事の内容が Azure Log Analytics や Sentinel を活用する際の一助となれば幸いです。
また、姉妹編として、Log Ingest API を使って、Rest API 経由でカスタムログを取りこむ方法についても合わせて記事を公開しました。サーバーからではなく、Azure Functions などコードを使ってログ取り込みが行いたい場合はこちらをご参照ください。
＊本稿は、個人の見解に基づいた内容であり、所属する会社の公式見解ではありません。また、いかなる保証を与えるものでもありません。正式な情報は、各製品の販売元にご確認ください。