こんにちは、アーキテクトのやまぱんです。
今回は Log Analytics Workspace にログを転送する際にフィルタリング (具体的に言うとクエリを通して変換設定) する手順を確認してみたいと思います。ログの量を減らせます！
補足コメントや質問、いいね、拡散、是非お願いします 🥺！
間違ってたら優しく教えてください！
Too Long; Didn't Read
最近の Azure UpdateでGenerally Available: Azure Firewall now supports ingestion-time transformation in Log Analytics for flexible, cost-efficient logging がアップデートされたので、設定手順を確認してみました。
Generally Available: Azure Firewall now supports ingestion-time transformation in Log Analytics for flexible, cost-efficient logging<抄訳：一般提供開始：Azure Firewall が Log Analytics での 取り込み時変換（ingestion-time transformation） をサポート>
Azure Firewall のログを Log Analytics に送信する際、ログの取り込み時に変換処理を行えるようになりました。これにより、不要なフィールドの削除やログ形式の調整が可能になり、コスト効率が向上し、柔軟なログ管理が実現します。
リソース固有のログと Azure Diagnostics ログ について
リソース固有のテーブルでは Basic テーブル プランがサポートされます。これにより、ログ記録コストを最大 80%削減できます。
などなど、モダンな方がリソース固有テーブルです。
Azure Firewall の診断設定、リソースログにおいては以下の 3 つは Azure Diagnostics で他はリソース固有テーブルを指定します。
- Azure Firewall Application Rule (Legacy Azure Diagnostics)
- Azure Firewall Network Rule (Legacy Azure Diagnostics)
- Azure Firewall DNS Proxy (Legacy Azure)
ref :
https://learn.microsoft.com/ja-jp/azure/firewall/monitor-firewall#structured-azure-firewall-logs
いまだに診断ログ(旧呼称)で書かれている MS Learn のページがありますが、現在はリソースログと呼びます！
- 旧名称: 診断ログ（Diagnostic Logs）
- 現在の名称: リソースログ（Resource Logs）
ここでは、リソースログに統一されていますね
ワークスペース変換データ収集規則 (DCR)
今回、Log Analytics Workspace に入れる際に使う機能は、DCR(Data Collection Rukes) セクションにある、 Azure Monitor での変換 (Transformations in Azure Monitor) です。
ただし、今回利用する DCR は 通常の DCR とは異なる今回利用する ワークスペース変換データ収集規則(DCR) は、Log Analytics ワークスペースに直接適用される特別な DCR です。
- この DCR は、データ収集に DCR をまだ使用していないため変換を定義する手段がないデータに対して変換を実行するためにあります。
-
1 つの Log Analytics Workspace に 1 つのワークスペース DCR 。
一つの DCR の中で任意の数のサポートされているテーブルの変換を含める運用になります。この変換は、データが別の DCR から取得されていない限り、これらのテーブルに送信されるすべてのデータに適用されます。
つまり、通常の DCR 経由で取り込まれているようなデータ（Azure Monitor Container Insights、Application Insights、Azure Monitor Agent を利用した VM のログ、AKS クラスターのメトリクスやログなど）はワークスペース DCR に設定をしても適用されません。
DCR 経由で取り込まれるデータの具体例
- Azure Monitor Container Insights: AKS クラスターのコンテナログ、パフォーマンスメトリクス
- Application Insights: アプリケーションテレメトリ、依存関係、例外データ
- Azure Monitor Agent (AMA): Windows/Linux VM のイベントログ、パフォーマンスカウンター
- Azure Arc enabled servers: オンプレミスサーバーの監視データ
これらは独自の DCR を使用しているため、ワークスペース変換 DCR の対象外です。
詳細はAKS での DCR 設定例を参照。
-
変換のコスト
変換自体にコストはかかりません。詳細はこちら。 -
ワークスペース変換 DCR - MS Learn
Azure Monitor でのデータ収集変換
Log Analytics Workspace に入れるログをフィルタリングする 手順
はい、では早速やっていきましょう。
今回は Azure Firewall のログテーブルである、AZFWNetworkRule を例にしていきます。
1.対象の Log Analytics Workspace → 対象のテーブル (この例では AZFWNetworkRule)を右クリック → 変換の編集
2.既存または新規で DCR をつくる
おおまかな流れは以下のような感じ
-
既存のワークスペース DCR があればそれを選択、なければ新規作成
-
変換ルールを書く: スキーマと変換 → 変換エディター
今回は以下のようなクエリを書いた。条件にマッチするデータのみを残したい、ログをスリム化したい。
特定の送信元 IP：宛先 IP の組み合わせを除外
source
| where not (SourceIp == "10.100.1.7" and DestinationIp == "102.37.165.13") // 特定の組み合わせを除外
-
確認
3.作成した DCR は Azure Portal → DCR からも確認可能
まとめ
今回は Log Analytics Workspace でのログフィルタリング機能を、Azure Firewall のログを例に実装手順を確認しました。
ポイント
- 1 つのワークスペースに 1 つの DCR: ワークスペース変換 DCR はワークスペース単位で作成
- 変換コストは無料: 処理自体にコストは発生しない（Microsoft Docs 参照）
- コスト削減: 不要なログデータの除外により大幅なストレージコスト削減が可能
実運用での効果
- セキュリティ: ノイズログを除外して真の脅威に集中
- コスト管理: テラバイト級環境での効率的な運用
- 運用負荷軽減: アラート精度向上とトラブルシューティング効率化
⚠️ 注意点
- 既存データには影響せず、取り込み時のみ適用
- 通常の DCR 経由データ（Azure Monitor Agent 等）は対象外
- 変換後のデータは不可逆のため事前テストが重要
この機能により、大規模環境でのログ管理がより効率的になり、コスト最適化と運用効率化を同時に実現できます。
参考リンク
-
Microsoft の公式の方のブログでももう少し詳細に書かれている方がいました！