はじめに

Azureを基盤として採用する場合には、各サービスやシステムのログをLogAnalyticsWorkspace(以下、ワークスペース)に保管していくことになると思います。そこで、基盤構築チームではワークスペースのスキーマ設計をしていくことになります。
しかし、なかなかワークスペースの設計については「事例などがネットに転がっていない！」と思いましたので、本記事ではでワークスペースにおけるスキーマ設計のノウハウを詰め込みます。

目次

保管されるログの種類
カスタムテーブルのスキーマ設定パターン
- SimpleTable
- ParsedTable
設計上の4つのTips
まとめ

保管されるログの種類

ワークスペースへ保管されるログの種類について、ここで整理しておきます。まずは、ログ出力のリソースとしては以下存在します。

ログの種類	リソース	ログの収集方式
Azureサービスのリソースログ	LogicApps、AzureFirewall等のAzureサービス	診断設定
Azureサービスのメトリック	AppService、CosmosDB等のAzureサービス	診断設定
Syslog、イベントログ	仮想マシン、AzureArc対応サーバー(オンプレ)	データ収集ルール
カスタムテキストログ	仮想マシン、AzureArc対応サーバー(オンプレ)	データ収集ルール
カスタムメトリック	仮想マシン、AzureArc対応サーバー(オンプレ)	データ収集ルール
仮想マシンのパフォーマンス	仮想マシン、AzureArc対応サーバー(オンプレ)	VMInsight
アプリケーションのパフォーマンス	仮想マシン、AzureArc対応サーバー(オンプレ)、AppService、LogicApps等	ApplicationInsight
セキュリティのログ	MicrosoftDefenderForCloud、Sentinel等	MDFCのエクスポート設定、Sentinelの設定等

基本的に「カスタムテキストログ」以外はワークスペースへ自動でテーブルが作成されますので、特にテーブル設計を意識することはありません。

カスタムテーブルの設計パターン

前項で紹介した「カスタムテキストログ」においては、構築時にカスタムテーブルの設計・構築が必要です。テーブル設計においては、公式でも紹介されている以下２パターンについて解説します。

参考：MS Learn|Azure Monitor エージェントを使用してテキストファイルからログを収集する

SimpleTable

テキストログは特に加工せずにRowDataとして保管する。取得元のファイルパスをFilePath、ホスト名をComputer、収集日時をTimegeneratedとして保持する。

メリット

データ収集ルールやカスタムテーブルの設計が楽ちん
設計がシンプルなので、保守運用であまり困らない
ログ検索は「Contains演算子」を使用すれば、任意の文字列で検索可能なので気にしなくて良い

デメリット

ログを集計するときに長いクエリを書く必要性が発生する
アラート設定でクエリが長くなり、レスポンススピードに懸念が出る

設定方法

TransformKQLでは「source」を指定します。テーブル作成時に、RowData、FilePath、Computer、Timegeneratedといった列を作成しておきます。中身はTransformKQLで指定しなくてもログ収取時に自動で挿入されていきます。詳細は以下、参照して下さい。
参考：MS Learn|Azure Monitor エージェントを使用してテキストファイルからログを収集する

ParsedTable

上記のSimpleTableに加えて、RowData内のテキストログにおいて特定のキーワードのみ摘出して別カラムとして保持する。

メリット

アラート設計に合わせて絡む設計をすることで、レスポンススピードの向上が図れる
ブック作成やログ集計において、クエリが短くなり書きやすい
ログ検索のクエリがシンプルになり書きやすい＋レスポンスの向上が図れる

デメリット

データ収集ルールとテーブル設計がとてもめんどくさい
ログの出力方式が変わったりすると、メンテナンスが必要になり保守工数がかかる

設計上の4つのTips

ここでは実際に設計をしていて気づいたことや、気を付けるべきことを記載しておきます。

ワークスペースは最小に！

ワークスペースは基本的に最小数で設計することがMicrosoftによって推奨されています。これは、私としても管理を楽にするうえでお勧めです。ログを検索するときにワークスペースが分かれていては、いちいちワークスペースを切り替える必要性も出てきて面倒です。
ただし、分けたほうがいい「２つの理由」があります。

①権限管理をしたい場合

１つのサブスクリプション内で複数のシステムが稼働している場合は、ログの閲覧可能な範囲をユーザーによって権限で分けたいケースがあるかと思います。ワークスペースではテーブルごとでの権限設定も可能ですが、基本的にはワークスペースを分けて権限管理をした方が運用は楽です。

②Sentinelを利用する場合

一方で、Sentinelの設定をすることで、ワークスペースの金額が1.5倍にも膨れてしまいます。なので、Sentinel用にワークスペースは基本的には分けましょう。そしてできることなら、Sentinelのログ保持期間は長くても30日程度にしておくことをお勧めします。

データの保持期間は運用方法を決める

データの保持期間の設定箇所は主に以下２点があります。

ワークスペースのデータ保持設定
テーブルごとのデータ保持設定

考え方は、「初期設計フェーズ」と「運用フェーズ」で変わってきます。
■ 初期設計フェーズ
基本的には「ワークスペースのデータ保持設定」で十分かと思います。その上で、明らかに膨大になるであろうログ（フローログやFirewallのアクセス拒否等）のみ保持期間を短くしておきましょう。

■ 運用フェーズ
運用の中で毎月、コストの確認をしましょう。各テーブルにおけるログの使用量は「推定量とコスト」から簡単に確認ができます。確認結果を踏まえ、運用の中でテーブルごとでの保持期間を変更して最適化していくことが大切です。また、運用チーム主体で進められる手順を確立しておくようにしましょう。

カラム名は一貫性を大事に！

テーブルを分けても同じような目的のカラム名は極力統一しましょう。例えば、HTTPサーバー系のMessageログであればHTTPリクエストの内容は全てのテーブルにおいて「HttpRequest」で統一しましょう。

アラートのクエリを意識する

個人的には、テーブル設計において基本的に前述の「SimpleTable」を採用すべきと考えていますが、アラートのレスポンス性能向上のためにカラムを切ることが経験上ありました。
例えば、アプリケーションのログでログステータスが「Error」という文字列を条件にアラートを発報したいのであれば、TransformKQLを使用して、ログステータスだけ別カラムへ格納しておくと便利で性能向上にもつながります。また、Error件数の集計をする際もクエリが短くなりとても便利です。ただし、TransformKQLも癖があるのでやや組むのが大変です。
参考：MSLearn | Supported KQL features in Azure Monitor transformations