Azure Log Analytics

解決する課題

VM・PaaS・コンテナー・アプリと、ログの出どころがバラバラだと、障害調査のたびに複数の場所を行き来することになります。Log Analytics は、これらのログを 1 つのワークスペースに集めて、共通のクエリ言語で横断的に調べられるようにします。

• 散らばったログを一元的に集約して横断検索したい
• 大量のログから特定の事象を絞り込み・集計したい（エラー件数、レイテンシ分布など）
• ログを起点にアラートやダッシュボードへつなげたい
• 監査やトラブルシュートのために一定期間ログを保持したい

Log Analytics は Azure Monitor の一部であり、Azure Monitor の「ログ」機能の格納先・分析エンジンに当たります。AWS でいえば、ログ収集の CloudWatch Logs と、その上で検索・集計する CloudWatch Logs Insights をまとめた位置づけです。

主要概念と用語

• Log Analytics ワークスペース: ログ データの格納先となる中核リソース。リージョン単位で作成し、保持・アクセス制御・課金の境界になる（CloudWatch のロググループ群をまとめた器に近い）
• KQL（Kusto 照会言語）: ログを検索・絞り込み・集計するためのクエリ言語。パイプ演算子でテーブルを段階的に絞り込む（CloudWatch Logs Insights のクエリ言語に相当）
• テーブル: ログの種類ごとの格納単位。リソース ログやプラットフォーム ログ、カスタム ログがそれぞれテーブルとして保持される
• TimeGenerated: 各レコードが持つタイムスタンプ列。時間範囲でのフィルターや時系列集計の基準になる
• テーブル プラン: テーブルごとに選べる取り込み区分（Analytics / Basic / Auxiliary など）。取り込みコストとクエリの自由度・保持の扱いが変わる
• データ収集元: 診断設定（リソース ログ）、Azure Monitor Agent と Data Collection Rule（VM のゲスト ログ・syslog）、Application Insights などから取り込まれる
• 保持とアーカイブ: テーブル単位で対話的に検索できる保持期間と、低コストで長期保管するアーカイブを使い分ける

仕様・制限・クォータ

• ワークスペースはリージョン リソース。複数ワークスペースをまたいだクエリは可能だが、どこに集約するかは設計時に方針を決める
• 保持はテーブル単位で設定でき、対話的な保持と、その後の長期アーカイブを組み合わせられる。既定の保持日数を超える分は課金対象になる
• テーブル プラン（Analytics / Basic / Auxiliary）により、フルクエリが可能か、絞り込み中心の低コスト取り込みか、といった性質が変わる
• KQL クエリには結果行数や実行時間などの実行上限がある。大量データは時間範囲や集計で絞ってから扱う
• リソース ログは既定では収集されない。各リソースで診断設定を有効化して初めてワークスペースへ流れる
• 具体的な保持日数・取り込み上限・料金などの数値は変動するため、要件に直結する場合は公式ドキュメントで最新値を確認すること

内部の仕組み

Log Analytics の実体は、Azure Monitor のログ プラットフォームを支える Kusto（Azure Data Explorer 系）エンジン上のデータ ストアです。取り込まれたログはテーブルに列指向で格納され、KQL で高速に検索・集計できます。

データの流れは大きく 3 経路です。1 つ目は各 Azure リソースの診断設定経由のリソース ログ、2 つ目は VM などの**Azure Monitor Agent と Data Collection Rule（DCR）**経由のゲスト ログや syslog、3 つ目は Application Insights などアプリ層からのテレメトリです。いずれもワークスペース内の対応するテーブルに格納され、TimeGenerated を軸に時系列として扱えます。

KQL クエリはテーブルを起点に、フィルター・射影・集計をパイプでつないで段階的に絞り込みます。クエリ結果はアラート ルールの評価、ブックやダッシュボードでの可視化、Managed Grafana 連携など、後段の機能から共通して利用されます。

設計パターン / ベストプラクティス

• 集中ワークスペース: サブスクリプション横断で 1〜数個のワークスペースに集約し、RBAC とコスト・保持方針を一元的に統制する
• テーブル プランの使い分け: 高頻度に検索する運用ログは Analytics、ほぼ保管目的のログは Basic / Auxiliary に振り分けて取り込みコストを最適化する
• 保持はテーブル単位で最適化: 重要テーブルだけ長めに保持し、長期保管はアーカイブへ寄せる
• 取り込み段階で絞る: Verbose ログを全リソースから無制限に送らず、必要なテーブル・レベルに絞ってからワークスペースへ流す
• KQL を再利用: よく使うクエリは関数（保存済みクエリ）化し、アラートやブックから共有する

運用・監視

• ログが来ない → 多くは診断設定が未構成。VM のゲスト ログなら Azure Monitor Agent と DCR の割り当て、マネージド ID の権限を確認する
• クエリが遅い・上限に当たる → 時間範囲を狭め、集計で行数を減らす。フルテキストの広範な検索を避け、列を指定して絞る
• 取り込み量が急増 → どのテーブルが伸びているかを把握し、Verbose ログの送りすぎや不要テーブルを点検する
• ワークスペース自体の使用状況やクエリ性能も、ワークスペース内のメタデータ的なテーブルから KQL で監視できる

コスト

課金は主にログ取り込み量（GB）と保持・アーカイブで発生します。プラットフォーム メトリクスと違い、ログは取り込んだ分だけコストになるため、何をどれだけ入れるかの設計が効きます。

セキュリティ

• ワークスペースへのアクセスは Microsoft Entra ID と Azure RBAC で制御する。ワークスペース全体だけでなく、リソース コンテキストやテーブル レベルでのアクセス制御も可能
• データは保存時に暗号化される。要件に応じて **Customer-Managed Key（CMK）**を Key Vault で管理できる
• エージェントや収集の認証にはマネージド ID を使い、資格情報のハードコードを避ける
• 機密ログを含む場合はテーブル レベル RBAC で参照範囲を絞り、必要なら Microsoft Sentinel（SIEM）連携で脅威検知へ拡張する

Well-Architected の観点

• オペレーショナル エクセレンス: ログを集約し KQL で横断分析できることで、障害調査と原因特定が速くなる。クエリやブックを共有資産化して運用を標準化する
• アラートやダッシュボードの信頼できる単一の情報源として機能し、属人化を防ぐ
• 取り込み・保持の設計はコスト最適化と直結するため、運用の質とコストを両立させる観点で見直す

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# Log Analytics ワークスペースを作成
az monitor log-analytics workspace create \
  --resource-group demo-rg \
  --workspace-name demo-law \
  --location japaneast

# 作成したワークスペースの ID（GUID）を取得
az monitor log-analytics workspace show \
  --resource-group demo-rg \
  --workspace-name demo-law \
  --query customerId -o tsv

# リソースのログ/メトリクスをワークスペースへ送る診断設定を作成
az monitor diagnostic-settings create \
  --name app-to-law \
  --resource "/subscriptions/<sub-id>/resourceGroups/demo-rg/providers/Microsoft.Web/sites/demo-app" \
  --workspace demo-law \
  --logs '[{"category":"AppServiceHTTPLogs","enabled":true}]'

# KQL で直近の重大度の高いトレースを 1 時間ごとに集計
az monitor log-analytics query \
  --workspace <workspace-id> \
  --analytics-query "AppTraces | where TimeGenerated > ago(1d) | where SeverityLevel >= 3 | summarize count() by bin(TimeGenerated, 1h)"