<p><!--META
{
"title": "Azure Monitor KQLクエリ活用術",
"primary_category": "クラウド>Azure",
"secondary_categories": ["KQL", "監視"],
"tags": ["AzureMonitor", "KQL", "LogAnalytics", "AzureCLI", "RBAC", "Sentinel"],
"summary": "Azure MonitorのKQLクエリを最大限に活用し、アーキテクチャから運用、セキュリティ、コスト最適化までを解説します。",
"mermaid": true,
"verify_level": "L0",
"tweet_hint": {"text":"Azure MonitorのKQLクエリ活用術を徹底解説！アーキテクチャ、設定、運用、セキュリティ、コスト最適化まで、クラウドアーキテクト視点で深掘りします。#AzureMonitor #KQL #Azure","hashtags":["#AzureMonitor","#KQL"]},
"link_hints": [
"https://learn.microsoft.com/ja-jp/azure/data-explorer/kusto/query/index",
"https://learn.microsoft.com/ja-jp/azure/azure-monitor/logs/design-logs-deployment",
"https://learn.microsoft.com/ja-jp/azure/azure-monitor/overview/monitor-costs"
]
}
-->
本記事は<strong>Geminiの出力をプロンプト工学で整理した業務ドラフト（未検証）</strong>です。</p>
<h1 class="wp-block-heading">Azure Monitor KQLクエリ活用術</h1>
<p>クラウド環境の健全性を維持し、問題発生時に迅速に対応するためには、堅牢な監視システムが不可欠です。Azure Monitorは、Azureリソースからテレメトリデータを収集し、可視化、分析、アラート機能を提供する包括的な監視ソリューションです。その中核をなすのが、Kusto Query Language (KQL) です。本記事では、KQLクエリを最大限に活用するためのアーキテクチャ設計から運用、セキュリティ、コスト最適化までを、クラウドアーキテクトの視点から解説します。</p>
<h2 class="wp-block-heading">1. KQLクエリとAzure Monitorアーキテクチャ</h2>
<h3 class="wp-block-heading">KQLとは</h3>
<p>KQLは、Azure Data Explorerのために開発された強力なクエリ言語であり、Azure MonitorのLog Analytics、Application Insights、Microsoft Sentinelなどでログデータを分析するために使用されます。直感的で読みやすい構文を持ち、大量の構造化・非構造化データを高速に処理できます。</p>
<h3 class="wp-block-heading">Log Analyticsワークスペースの役割</h3>
<p>Log Analyticsワークスペースは、Azure Monitorで収集されたすべてのログデータが保存される論理的なリポジトリです。複数のAzureリソースやオンプレミスサーバーからのログを集約し、KQLクエリによって横断的に分析することが可能になります。ワークスペースの設計は、データ主権、アクセス制御、コストに大きく影響するため、慎重に行う必要があります[1]。</p>
<h3 class="wp-block-heading">データ収集の流れ</h3>
<p>Azure Monitorは、さまざまなデータソースからログとメトリックを収集します。仮想マシンからのエージェント、Azureリソースの診断設定、Application Insights SDKなどがデータを収集し、Log Analyticsワークスペースへとストリーミングします。これらのデータは、特定のテーブル（例：<code>Heartbeat</code>, <code>AzureActivity</code>, <code>Perf</code>）に格納され、KQLクエリで参照できるようになります。</p>
<h3 class="wp-block-heading">KQLクエリ実行フロー</h3>
<p>以下に、KQLクエリがAzure Monitor内でどのように実行されるかを示すフローチャートを示します。</p>
<div class="wp-block-merpress-mermaidjs diagram-source-mermaid"><pre class="mermaid">
flowchart TD
A["Azureリソース"] -->|診断設定/エージェント| B("データ収集サービス");
B -->|ログ転送| C["Log Analytics Workspace"];
C -->|KQLクエリ実行| D{"クエリエンジン"};
D -->|結果表示| E["Azure Portal/API"];
E -->|アラート設定| F["Azure Monitor アラート"];
E -->|ダッシュボード/ブック| G["可視化"];
F -->|アクション実行| H["アクション グループ"];
A["Azureリソース"] -- |VM、App Service、DBなど| A;
C["Log Analytics Workspace"] -- |データリポジトリ| C;
E["Azure Portal/API"] -- |KQLの結果閲覧| E;
F["Azure Monitor アラート"] -- |ログクエリアラート| F;
G["可視化"] -- |監視ビュー/カスタムダッシュボード| G;
H["アクション グループ"] -- |メール、SMS、Webhook、ITS連携など| H;
</pre></div>
<h2 class="wp-block-heading">2. 実践！ KQLクエリ設定手順</h2>
<h3 class="wp-block-heading">Log Analyticsワークスペースの作成</h3>
<p>まず、ログデータを格納するためのLog Analyticsワークスペースを作成します。
以下はAzure CLIを使用した作成例です。</p>
<div class="codehilite">
<pre data-enlighter-language="generic"># 変数設定
RESOURCE_GROUP="my-loganalytics-rg"
WORKSPACE_NAME="my-prod-logworkspace"
LOCATION="japaneast" # 例: 東日本リージョン
SKU="PerGB2018" # 例: 従量課金モデル
# リソースグループの作成（もし存在しない場合）
az group create --name $RESOURCE_GROUP --location $LOCATION
# Log Analyticsワークスペースの作成
az monitor log-analytics workspace create \
--resource-group $RESOURCE_GROUP \
--workspace-name $WORKSPACE_NAME \
--location $LOCATION \
--sku $SKU \
--retention-time 30 # データ保持期間を30日に設定（日単位）
</pre>
</div>
<p>[2] この際、データ保持期間（<code>--retention-time</code>）はコストに直結するため、要件に合わせて設定します。</p>
<h3 class="wp-block-heading">データソースの接続とログの収集</h3>
<p>ワークスペース作成後、監視対象のリソースからログを収集するように設定します。例えば、Azure VMからはLog Analyticsエージェント、Azureリソースからは診断設定を通じてログを送信します。</p>
<h3 class="wp-block-heading">基本的なクエリの記述と実行</h3>
<p>Log AnalyticsワークスペースでKQLクエリを実行するには、Azure PortalのLog Analyticsワークスペースにある「ログ」ブレードを使用します。</p>
<div class="codehilite">
<pre data-enlighter-language="generic">// 過去1時間のログエントリを検索し、上位100件を表示
AzureActivity
| where TimeGenerated > ago(1h)
| limit 100
// 特定のイベントIDのセキュリティイベントを検索
SecurityEvent
| where EventID == 4624 // ログオン成功イベント
| where TimeGenerated > ago(7d)
| project TimeGenerated, Account, Computer, Activity
| sort by TimeGenerated desc
</pre>
</div>
<p>これらのクエリは、特定の条件でログをフィルタリングし、必要な列だけを抽出 (<code>project</code>) し、並べ替え (<code>sort</code>) を行う基本的な例です。</p>
<h3 class="wp-block-heading">クエリの保存とダッシュボードへのピン留め</h3>
<p>頻繁に使用するクエリは保存し、Azureダッシュボードにピン留めすることで、監視状況を素早く確認できます。これにより、チーム全体の運用効率が向上します。</p>
<h2 class="wp-block-heading">3. 効果的な運用監視のためのKQL</h2>
<h3 class="wp-block-heading">ログクエリによる監視とアラート設定</h3>
<p>KQLクエリは、閾値ベースのアラート設定に非常に有効です。特定の条件に合致するログエントリが一定期間内に発生した場合にアラートを発火させることができます[7]。</p>
<div class="codehilite">
<pre data-enlighter-language="generic"># Log AnalyticsワークスペースIDとリソースグループ名
$workspaceId = (az monitor log-analytics workspace show --resource-group $RESOURCE_GROUP --workspace-name $WORKSPACE_NAME --query id -o tsv)
$resourceGroup = $RESOURCE_GROUP
# KQLクエリアラートを作成
az monitor scheduled-query create `
--resource-group $resourceGroup `
--name "HighCPUUsageAlert" `
--scopes $workspaceId `
--condition "min override=1 count of query where Computer == 'MyVM' and CounterName == '% Processor Time' and CounterValue > 90" `
--condition-period 5m ` # 過去5分間のデータ
--condition-frequency 5m ` # 5分ごとに評価
--action-groups "/subscriptions/<YOUR_SUBSCRIPTION_ID>/resourceGroups/<ACTION_GROUP_RG>/providers/microsoft.insights/actiongroups/<ACTION_GROUP_NAME>" `
--enabled true `
--severity 2 ` # 警告
--description "VM 'MyVM' のCPU使用率が90%を超えました。" `
--evaluation-frequency 5m ` # 評価頻度
--target-resource-type "Microsoft.OperationalInsights/workspaces" # ターゲットリソースの種類
</pre>
</div>
<p>上記の例では、特定のVMのCPU使用率が90%を超えた場合にアラートを発火させる設定を示しています。<code><YOUR_SUBSCRIPTION_ID></code>, <code><ACTION_GROUP_RG></code>, <code><ACTION_GROUP_NAME></code>はご自身の環境に合わせて置き換える必要があります。</p>
<h3 class="wp-block-heading">パフォーマンス分析と傾向把握</h3>
<p>KQLを使用して、リソースのパフォーマンスメトリック（CPU、メモリ、ディスクI/Oなど）の傾向を時系列で分析できます。これにより、将来のキャパシティプランニングやパフォーマンス最適化の意思決定に役立てることができます。</p>
<h3 class="wp-block-heading">トラブルシューティングと根本原因分析</h3>
<p>問題発生時には、KQLクエリを用いて関連するログを迅速に検索し、エラーメッセージ、イベントログ、アプリケーションログなどを相関分析することで、根本原因を特定する時間を大幅に短縮できます。</p>
<h3 class="wp-block-heading">SLO/SLA遵守のためのレポート</h3>
<p>KQLクエリは、サービスレベル目標 (SLO) やサービスレベルアグリーメント (SLA) の遵守状況を監視し、定期的なレポートを生成するためにも利用できます。例えば、サービス可用性、エラーレート、応答時間などの主要な指標を計算し、目標値と比較するクエリを作成できます。</p>
<h2 class="wp-block-heading">4. KQLクエリとセキュリティ</h2>
<h3 class="wp-block-heading">Azure RBACによるアクセス制御</h3>
<p>Log Analyticsワークスペースへのアクセスは、Azure Active Directory (現在はMicrosoft Entra ID) とAzure ロールベースのアクセス制御 (RBAC) によって厳密に管理されます[4]。</p>
<ul class="wp-block-list">
<li><p><strong>監視閲覧者 (Monitoring Reader)</strong>: ログデータと監視設定の閲覧のみを許可します。</p></li>
<li><p><strong>監視共同作成者 (Monitoring Contributor)</strong>: 監視設定（アラート、ダッシュボードなど）の作成・編集を許可しますが、ログデータの直接的な変更はできません。</p></li>
<li><p><strong>Log Analytics 共同作成者 (Log Analytics Contributor)</strong>: Log Analyticsワークスペースの構成変更やログデータのクエリ実行、アラート設定などを許可します。</p></li>
</ul>
<p>組織のセキュリティポリシーに基づき、最小特権の原則に従ってこれらのロールを適用することが重要です。カスタムロールを作成し、特定のデータテーブルへのアクセスを制限することも可能です。</p>
<h3 class="wp-block-heading">機密データの保護</h3>
<p>Log Analyticsワークスペースに送信されるログには、個人情報 (PII) や機密情報が含まれる可能性があります。KQLクエリを実行する際には、これらのデータが意図せず漏洩しないよう、クエリ結果のフィルタリングや、エクスポートされたデータの適切な管理が求められます[5]。データのマスキングや匿名化を実装することも検討すべきです。</p>
<h3 class="wp-block-heading">セキュリティイベントの監視と検出</h3>
<p>KQLは、セキュリティイベントを監視し、異常なアクティビティや潜在的な脅威を検出するための強力なツールです。Microsoft Entra IDのサインインログ、Azure Activityログ、セキュリティイベントログなどを組み合わせたクエリを作成することで、不審なログイン試行、権限昇格、リソースへの不正アクセスなどを早期に発見できます。</p>
<h3 class="wp-block-heading">Azure Sentinelとの連携</h3>
<p>Azure Sentinelは、MicrosoftのクラウドネイティブなSIEM (Security Information and Event Management) ソリューションです。Log Analyticsワークスペースをデータソースとして利用し、KQLを駆使して脅威ハンティング、セキュリティインシデントの検出、調査、対応を自動化します。</p>
<h2 class="wp-block-heading">5. コスト最適化のためのKQL</h2>
<h3 class="wp-block-heading">Log Analyticsの課金モデル理解</h3>
<p>Azure Monitorの課金は、主にLog Analyticsワークスペースへの<strong>データインジェスト量</strong>と<strong>データ保持期間</strong>に基づいて行われます[3]。</p>
<ul class="wp-block-list">
<li><p><strong>データインジェスト</strong>: 収集されたログデータの容量 (GB単位) に応じて課金されます。</p></li>
<li><p><strong>データ保持</strong>: 保持期間を超過したデータは自動的に削除されますが、指定された保持期間内のデータストレージに対して課金されます。</p></li>
</ul>
<h3 class="wp-block-heading">データインジェスト量の監視と削減</h3>
<p>KQLクエリを使用して、Log Analyticsワークスペースへのデータインジェスト量を定期的に監視し、コストの予期せぬ増加を避けることができます。</p>
<div class="codehilite">
<pre data-enlighter-language="generic">// 過去7日間の各データ型ごとのインジェスト量をGB単位で集計
Usage
| where Is =="Data"
| where StartTime >= ago(7d)
| summarize BillableDataGB = sum(Quantity) / 1000 by DataType
| render piechart
</pre>
</div>
<p>このクエリで、どのデータタイプが最も多くのインジェスト量を占めているかを把握し、不要なログの収集停止やフィルタリングを検討します。</p>
<h3 class="wp-block-heading">データ保持期間の最適化</h3>
<p>要件に応じて、データの保持期間を短縮することでコストを削減できます。コンプライアンス要件を満たしつつ、必要最低限の期間に設定することが重要です。長期保存が必要なデータは、Log AnalyticsワークスペースからAzure Storageアカウントへエクスポートする構成を検討します[6]。</p>
<h3 class="wp-block-heading">コミットメント層の活用</h3>
<p>Log Analyticsワークスペースは、従量課金 (Pay-As-You-Go) のほかに、コミットメント層 (Commitment Tiers) を提供しています。一定のデータインジェスト量をコミットすることで、従量課金よりもGBあたりの単価が安くなります。月間の平均インジェスト量に基づいて適切なコミットメント層を選択することで、大幅なコスト削減が期待できます。</p>
<h2 class="wp-block-heading">6. KQLクエリ活用の落とし穴と対策</h2>
<h3 class="wp-block-heading">非効率なクエリによるパフォーマンス問題</h3>
<p>複雑な結合 (<code>join</code>) や集計 (<code>summarize</code>)、広範な期間指定は、クエリの実行時間を増加させ、Log Analyticsのクエリリソースを消費する可能性があります。</p>
<ul class="wp-block-list">
<li><p><strong>対策</strong>:</p>
<ul>
<li><p>必要なデータのみをフィルタリング (<code>where</code>) してから処理する。</p></li>
<li><p><code>project</code> や <code>project-away</code> を使って必要な列のみに絞る。</p></li>
<li><p><code>extend</code> や <code>parse</code> を多用しすぎない。</p></li>
<li><p><code>has</code> 演算子 (<code>has_cs</code> を含む) は <code>contains</code> よりも高速な場合が多い。</p></li>
</ul></li>
</ul>
<h3 class="wp-block-heading">データの欠落や不整合</h3>
<p>データ収集エージェントの問題、診断設定の誤構成、ネットワークの問題などにより、ログデータがLog Analyticsワークスペースに到達しない、あるいは不完全な状態で格納されることがあります。</p>
<ul class="wp-block-list">
<li><p><strong>対策</strong>:</p>
<ul>
<li><p>Log Analyticsエージェントのハートビート (<code>Heartbeat</code> テーブル) を監視する。</p></li>
<li><p>診断設定の構成を定期的に確認する。</p></li>
<li><p>データソース側でのログ生成状況と、Log Analyticsでの受信状況を比較するクエリを作成する。</p></li>
</ul></li>
</ul>
<h3 class="wp-block-heading">権限管理の複雑化</h3>
<p>複数のLog Analyticsワークスペースやリソースグループにまたがる権限設定は、管理が複雑になりがちです。</p>
<ul class="wp-block-list">
<li><p><strong>対策</strong>:</p>
<ul>
<li><p>ワークスペースの設計段階で、一元管理と分離のバランスを考慮する[2]。</p></li>
<li><p>Azure BlueprintsやAzure Policyを活用し、RBAC割り当てを自動化・標準化する。</p></li>
<li><p>カスタムロールは必要最小限に留め、組み込みロールを優先する。</p></li>
</ul></li>
</ul>
<h3 class="wp-block-heading">学習コストと継続的なスキルアップ</h3>
<p>KQLは強力ですが、その全機能を習得するには一定の学習が必要です。常に最新のKQL機能やベストプラクティスを追い続けることが求められます。</p>
<ul class="wp-block-list">
<li><p><strong>対策</strong>:</p>
<ul>
<li><p>Microsoft Learnなどの公式ドキュメントで継続的に学習する。</p></li>
<li><p>KQLチートシートやサンプルクエリを活用する。</p></li>
<li><p>チーム内でKQLに関する知識共有会を定期的に開催する。</p></li>
</ul></li>
</ul>
<h2 class="wp-block-heading">7. まとめ</h2>
<p>Azure MonitorにおけるKQLクエリは、クラウド環境の監視と運用のための最も強力なツールの一つです。本記事では、そのアーキテクチャから具体的な設定手順、効果的な運用監視、セキュリティの考慮事項、そしてコスト最適化戦略に至るまで、多角的な視点からKQLの活用術を解説しました。</p>
<p>Log Analyticsワークスペースの適切な設計、Azure RBACによる厳密なアクセス制御、効率的なクエリ記述、そしてコスト意識を持ったデータ管理は、KQLを最大限に活用するための鍵となります。これらのプラクティスを導入することで、Azure環境の可観測性を高め、問題解決の迅速化、セキュリティ態勢の強化、そして運用コストの最適化を実現できるでしょう。継続的な学習と実践を通じて、KQLのスキルを磨き、安定したクラウド運用を実現してください。</p>
<hr/>
<p><strong>参照情報（JST: 2024年7月26日時点）</strong>
[1] KQL (Kusto Query Language) の概要 | Microsoft Learn. <code>https://learn.microsoft.com/ja-jp/azure/data-explorer/kusto/query/index</code> (Microsoft Learn, 2024年7月25日更新)
[2] Azure Monitor の Log Analytics ワークスペースを設計する | Microsoft Learn. <code>https://learn.microsoft.com/ja-jp/azure/azure-monitor/logs/design-logs-deployment</code> (Microsoft Learn, 2024年7月25日更新)
[3] Azure Monitor のコストと使用量 | Microsoft Learn. <code>https://learn.microsoft.com/ja-jp/azure/azure-monitor/overview/monitor-costs</code> (Microsoft Learn, 2024年7月25日更新)
[4] Azure Monitor でロールベースのアクセス制御を使用する | Microsoft Learn. <code>https://learn.microsoft.com/ja-jp/azure/azure-monitor/roles-permissions-security</code> (Microsoft Learn, 2024年7月25日更新)
[5] Azure Monitor でログ クエリをセキュリティ保護する | Microsoft Learn. <code>https://learn.microsoft.com/ja-jp/azure/azure-monitor/logs/queries-security</code> (Microsoft Learn, 2024年7月25日更新)
[6] Azure Monitor でのログ データのエクスポート | Microsoft Learn. <code>https://learn.microsoft.com/ja-jp/azure/azure-monitor/logs/logs-export-portal</code> (Microsoft Learn, 2024年7月25日更新)
[7] Azure Monitor のアラートの概要 | Microsoft Learn. <code>https://learn.microsoft.com/ja-jp/azure/azure-monitor/alerts/alerts-overview</code> (Microsoft Learn, 2024年7月25日更新)</p>
本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
Azure Monitor KQLクエリ活用術
クラウド環境の健全性を維持し、問題発生時に迅速に対応するためには、堅牢な監視システムが不可欠です。Azure Monitorは、Azureリソースからテレメトリデータを収集し、可視化、分析、アラート機能を提供する包括的な監視ソリューションです。その中核をなすのが、Kusto Query Language (KQL) です。本記事では、KQLクエリを最大限に活用するためのアーキテクチャ設計から運用、セキュリティ、コスト最適化までを、クラウドアーキテクトの視点から解説します。
1. KQLクエリとAzure Monitorアーキテクチャ
KQLとは
KQLは、Azure Data Explorerのために開発された強力なクエリ言語であり、Azure MonitorのLog Analytics、Application Insights、Microsoft Sentinelなどでログデータを分析するために使用されます。直感的で読みやすい構文を持ち、大量の構造化・非構造化データを高速に処理できます。
Log Analyticsワークスペースの役割
Log Analyticsワークスペースは、Azure Monitorで収集されたすべてのログデータが保存される論理的なリポジトリです。複数のAzureリソースやオンプレミスサーバーからのログを集約し、KQLクエリによって横断的に分析することが可能になります。ワークスペースの設計は、データ主権、アクセス制御、コストに大きく影響するため、慎重に行う必要があります[1]。
データ収集の流れ
Azure Monitorは、さまざまなデータソースからログとメトリックを収集します。仮想マシンからのエージェント、Azureリソースの診断設定、Application Insights SDKなどがデータを収集し、Log Analyticsワークスペースへとストリーミングします。これらのデータは、特定のテーブル（例：Heartbeat, AzureActivity, Perf）に格納され、KQLクエリで参照できるようになります。
KQLクエリ実行フロー
以下に、KQLクエリがAzure Monitor内でどのように実行されるかを示すフローチャートを示します。
flowchart TD
A["Azureリソース"] -->|診断設定/エージェント| B("データ収集サービス");
B -->|ログ転送| C["Log Analytics Workspace"];
C -->|KQLクエリ実行| D{"クエリエンジン"};
D -->|結果表示| E["Azure Portal/API"];
E -->|アラート設定| F["Azure Monitor アラート"];
E -->|ダッシュボード/ブック| G["可視化"];
F -->|アクション実行| H["アクション グループ"];
A["Azureリソース"] -- |VM、App Service、DBなど| A;
C["Log Analytics Workspace"] -- |データリポジトリ| C;
E["Azure Portal/API"] -- |KQLの結果閲覧| E;
F["Azure Monitor アラート"] -- |ログクエリアラート| F;
G["可視化"] -- |監視ビュー/カスタムダッシュボード| G;
H["アクション グループ"] -- |メール、SMS、Webhook、ITS連携など| H;
2. 実践！ KQLクエリ設定手順
Log Analyticsワークスペースの作成
まず、ログデータを格納するためのLog Analyticsワークスペースを作成します。
以下はAzure CLIを使用した作成例です。
# 変数設定
RESOURCE_GROUP="my-loganalytics-rg"
WORKSPACE_NAME="my-prod-logworkspace"
LOCATION="japaneast" # 例: 東日本リージョン
SKU="PerGB2018" # 例: 従量課金モデル
# リソースグループの作成（もし存在しない場合）
az group create --name $RESOURCE_GROUP --location $LOCATION
# Log Analyticsワークスペースの作成
az monitor log-analytics workspace create \
--resource-group $RESOURCE_GROUP \
--workspace-name $WORKSPACE_NAME \
--location $LOCATION \
--sku $SKU \
--retention-time 30 # データ保持期間を30日に設定（日単位）
[2] この際、データ保持期間（--retention-time）はコストに直結するため、要件に合わせて設定します。
データソースの接続とログの収集
ワークスペース作成後、監視対象のリソースからログを収集するように設定します。例えば、Azure VMからはLog Analyticsエージェント、Azureリソースからは診断設定を通じてログを送信します。
基本的なクエリの記述と実行
Log AnalyticsワークスペースでKQLクエリを実行するには、Azure PortalのLog Analyticsワークスペースにある「ログ」ブレードを使用します。
// 過去1時間のログエントリを検索し、上位100件を表示
AzureActivity
| where TimeGenerated > ago(1h)
| limit 100
// 特定のイベントIDのセキュリティイベントを検索
SecurityEvent
| where EventID == 4624 // ログオン成功イベント
| where TimeGenerated > ago(7d)
| project TimeGenerated, Account, Computer, Activity
| sort by TimeGenerated desc
これらのクエリは、特定の条件でログをフィルタリングし、必要な列だけを抽出 (project) し、並べ替え (sort) を行う基本的な例です。
クエリの保存とダッシュボードへのピン留め
頻繁に使用するクエリは保存し、Azureダッシュボードにピン留めすることで、監視状況を素早く確認できます。これにより、チーム全体の運用効率が向上します。
3. 効果的な運用監視のためのKQL
ログクエリによる監視とアラート設定
KQLクエリは、閾値ベースのアラート設定に非常に有効です。特定の条件に合致するログエントリが一定期間内に発生した場合にアラートを発火させることができます[7]。
# Log AnalyticsワークスペースIDとリソースグループ名
$workspaceId = (az monitor log-analytics workspace show --resource-group $RESOURCE_GROUP --workspace-name $WORKSPACE_NAME --query id -o tsv)
$resourceGroup = $RESOURCE_GROUP
# KQLクエリアラートを作成
az monitor scheduled-query create `
--resource-group $resourceGroup `
--name "HighCPUUsageAlert" `
--scopes $workspaceId `
--condition "min override=1 count of query where Computer == 'MyVM' and CounterName == '% Processor Time' and CounterValue > 90" `
--condition-period 5m ` # 過去5分間のデータ
--condition-frequency 5m ` # 5分ごとに評価
--action-groups "/subscriptions/<YOUR_SUBSCRIPTION_ID>/resourceGroups/<ACTION_GROUP_RG>/providers/microsoft.insights/actiongroups/<ACTION_GROUP_NAME>" `
--enabled true `
--severity 2 ` # 警告
--description "VM 'MyVM' のCPU使用率が90%を超えました。" `
--evaluation-frequency 5m ` # 評価頻度
--target-resource-type "Microsoft.OperationalInsights/workspaces" # ターゲットリソースの種類
上記の例では、特定のVMのCPU使用率が90%を超えた場合にアラートを発火させる設定を示しています。<YOUR_SUBSCRIPTION_ID>, <ACTION_GROUP_RG>, <ACTION_GROUP_NAME>はご自身の環境に合わせて置き換える必要があります。
パフォーマンス分析と傾向把握
KQLを使用して、リソースのパフォーマンスメトリック（CPU、メモリ、ディスクI/Oなど）の傾向を時系列で分析できます。これにより、将来のキャパシティプランニングやパフォーマンス最適化の意思決定に役立てることができます。
トラブルシューティングと根本原因分析
問題発生時には、KQLクエリを用いて関連するログを迅速に検索し、エラーメッセージ、イベントログ、アプリケーションログなどを相関分析することで、根本原因を特定する時間を大幅に短縮できます。
SLO/SLA遵守のためのレポート
KQLクエリは、サービスレベル目標 (SLO) やサービスレベルアグリーメント (SLA) の遵守状況を監視し、定期的なレポートを生成するためにも利用できます。例えば、サービス可用性、エラーレート、応答時間などの主要な指標を計算し、目標値と比較するクエリを作成できます。
4. KQLクエリとセキュリティ
Azure RBACによるアクセス制御
Log Analyticsワークスペースへのアクセスは、Azure Active Directory (現在はMicrosoft Entra ID) とAzure ロールベースのアクセス制御 (RBAC) によって厳密に管理されます[4]。
監視閲覧者 (Monitoring Reader): ログデータと監視設定の閲覧のみを許可します。
監視共同作成者 (Monitoring Contributor): 監視設定（アラート、ダッシュボードなど）の作成・編集を許可しますが、ログデータの直接的な変更はできません。
Log Analytics 共同作成者 (Log Analytics Contributor): Log Analyticsワークスペースの構成変更やログデータのクエリ実行、アラート設定などを許可します。
組織のセキュリティポリシーに基づき、最小特権の原則に従ってこれらのロールを適用することが重要です。カスタムロールを作成し、特定のデータテーブルへのアクセスを制限することも可能です。
機密データの保護
Log Analyticsワークスペースに送信されるログには、個人情報 (PII) や機密情報が含まれる可能性があります。KQLクエリを実行する際には、これらのデータが意図せず漏洩しないよう、クエリ結果のフィルタリングや、エクスポートされたデータの適切な管理が求められます[5]。データのマスキングや匿名化を実装することも検討すべきです。
セキュリティイベントの監視と検出
KQLは、セキュリティイベントを監視し、異常なアクティビティや潜在的な脅威を検出するための強力なツールです。Microsoft Entra IDのサインインログ、Azure Activityログ、セキュリティイベントログなどを組み合わせたクエリを作成することで、不審なログイン試行、権限昇格、リソースへの不正アクセスなどを早期に発見できます。
Azure Sentinelとの連携
Azure Sentinelは、MicrosoftのクラウドネイティブなSIEM (Security Information and Event Management) ソリューションです。Log Analyticsワークスペースをデータソースとして利用し、KQLを駆使して脅威ハンティング、セキュリティインシデントの検出、調査、対応を自動化します。
5. コスト最適化のためのKQL
Log Analyticsの課金モデル理解
Azure Monitorの課金は、主にLog Analyticsワークスペースへのデータインジェスト量とデータ保持期間に基づいて行われます[3]。
データインジェスト量の監視と削減
KQLクエリを使用して、Log Analyticsワークスペースへのデータインジェスト量を定期的に監視し、コストの予期せぬ増加を避けることができます。
// 過去7日間の各データ型ごとのインジェスト量をGB単位で集計
Usage
| where Is =="Data"
| where StartTime >= ago(7d)
| summarize BillableDataGB = sum(Quantity) / 1000 by DataType
| render piechart
このクエリで、どのデータタイプが最も多くのインジェスト量を占めているかを把握し、不要なログの収集停止やフィルタリングを検討します。
データ保持期間の最適化
要件に応じて、データの保持期間を短縮することでコストを削減できます。コンプライアンス要件を満たしつつ、必要最低限の期間に設定することが重要です。長期保存が必要なデータは、Log AnalyticsワークスペースからAzure Storageアカウントへエクスポートする構成を検討します[6]。
コミットメント層の活用
Log Analyticsワークスペースは、従量課金 (Pay-As-You-Go) のほかに、コミットメント層 (Commitment Tiers) を提供しています。一定のデータインジェスト量をコミットすることで、従量課金よりもGBあたりの単価が安くなります。月間の平均インジェスト量に基づいて適切なコミットメント層を選択することで、大幅なコスト削減が期待できます。
6. KQLクエリ活用の落とし穴と対策
非効率なクエリによるパフォーマンス問題
複雑な結合 (join) や集計 (summarize)、広範な期間指定は、クエリの実行時間を増加させ、Log Analyticsのクエリリソースを消費する可能性があります。
対策:
必要なデータのみをフィルタリング (where) してから処理する。
project や project-away を使って必要な列のみに絞る。
extend や parse を多用しすぎない。
has 演算子 (has_cs を含む) は contains よりも高速な場合が多い。
データの欠落や不整合
データ収集エージェントの問題、診断設定の誤構成、ネットワークの問題などにより、ログデータがLog Analyticsワークスペースに到達しない、あるいは不完全な状態で格納されることがあります。
権限管理の複雑化
複数のLog Analyticsワークスペースやリソースグループにまたがる権限設定は、管理が複雑になりがちです。
対策:
ワークスペースの設計段階で、一元管理と分離のバランスを考慮する[2]。
Azure BlueprintsやAzure Policyを活用し、RBAC割り当てを自動化・標準化する。
カスタムロールは必要最小限に留め、組み込みロールを優先する。
学習コストと継続的なスキルアップ
KQLは強力ですが、その全機能を習得するには一定の学習が必要です。常に最新のKQL機能やベストプラクティスを追い続けることが求められます。
7. まとめ
Azure MonitorにおけるKQLクエリは、クラウド環境の監視と運用のための最も強力なツールの一つです。本記事では、そのアーキテクチャから具体的な設定手順、効果的な運用監視、セキュリティの考慮事項、そしてコスト最適化戦略に至るまで、多角的な視点からKQLの活用術を解説しました。
Log Analyticsワークスペースの適切な設計、Azure RBACによる厳密なアクセス制御、効率的なクエリ記述、そしてコスト意識を持ったデータ管理は、KQLを最大限に活用するための鍵となります。これらのプラクティスを導入することで、Azure環境の可観測性を高め、問題解決の迅速化、セキュリティ態勢の強化、そして運用コストの最適化を実現できるでしょう。継続的な学習と実践を通じて、KQLのスキルを磨き、安定したクラウド運用を実現してください。
参照情報（JST: 2024年7月26日時点）
[1] KQL (Kusto Query Language) の概要 | Microsoft Learn. https://learn.microsoft.com/ja-jp/azure/data-explorer/kusto/query/index (Microsoft Learn, 2024年7月25日更新)
[2] Azure Monitor の Log Analytics ワークスペースを設計する | Microsoft Learn. https://learn.microsoft.com/ja-jp/azure/azure-monitor/logs/design-logs-deployment (Microsoft Learn, 2024年7月25日更新)
[3] Azure Monitor のコストと使用量 | Microsoft Learn. https://learn.microsoft.com/ja-jp/azure/azure-monitor/overview/monitor-costs (Microsoft Learn, 2024年7月25日更新)
[4] Azure Monitor でロールベースのアクセス制御を使用する | Microsoft Learn. https://learn.microsoft.com/ja-jp/azure/azure-monitor/roles-permissions-security (Microsoft Learn, 2024年7月25日更新)
[5] Azure Monitor でログ クエリをセキュリティ保護する | Microsoft Learn. https://learn.microsoft.com/ja-jp/azure/azure-monitor/logs/queries-security (Microsoft Learn, 2024年7月25日更新)
[6] Azure Monitor でのログ データのエクスポート | Microsoft Learn. https://learn.microsoft.com/ja-jp/azure/azure-monitor/logs/logs-export-portal (Microsoft Learn, 2024年7月25日更新)
[7] Azure Monitor のアラートの概要 | Microsoft Learn. https://learn.microsoft.com/ja-jp/azure/azure-monitor/alerts/alerts-overview (Microsoft Learn, 2024年7月25日更新)
コメント