初めてのAzure Log AnalyticsとKQL クエリ
Azureにはリソースのログを収集・分析するサービスとしてLog Analyticsがあります。
今回は、Log Analyticsを利用し始める方向けに、概要からワークスペースのリソース作成、設定までの手順や、KQL(Kusto Query Language)クエリを使ったログ検索方法を紹介しています。
Azure Log Analyticsの概要では、収集対象のログや設定方法、テーブルプラン、課金についても確認しています。
KQLクエリを使ったログ検索では、where演算子などを利用した検索条件の絞り込み方法についても紹介しています。
※本記事では、Kusto Query LanguageをKQLとして表記しています。
- 1. Azure Log Analyticsの概要、収集対象ログ、テーブルプラン、課金
- 2. Log Analytics ワークスペースのリソースを作成する手順
- 3. Log Analytics ワークスペースでKQL使ってログを検索する方法
- 3.1. Log Analytics ワークスペースでのKQLクエリ実行方法
- 3.2. 条件に合致するレコードに絞り込みする場合はwhere 演算子
- 3.3. 必要な列(項目)のみ出力する場合はproject 演算子
- 3.4. 並び替え(ソート)する場合はsort 演算子もしくはorder 演算子
- 3.5. where 演算子を使って検索対象時間の範囲を指定できる
- 3.6. 検索結果の表示件数を指定する場合はlimit 演算子もしくはtake 演算子
- 3.7. 既存の列は残したまま新しい列を追加する場合はextend 演算子
- 3.8. 検索結果をグラフ表示する場合はrender 演算子
- 3.9. 検索結果はエクスポートできる(CSVでダウンロード)
- 4. 最後に
Azure Log Analyticsの概要、収集対象ログ、テーブルプラン、課金
Azure Log Analyticsの概要
Azure Monitor Logsは、Azure Monitor のログデータプラットフォーム。収集・保存・分析の基盤です。
そして、Log Analyticsのデータを収集・管理するためのAzureリソースが、Log Analytics ワークスペースになります。
Log Analytics ワークスペース内のテーブルにデータを保管します。
Azure上のリソースだけではなく、Azure以外のリソースやアプリケーションからログ データを収集することができます。
収集したログを、KQL(Kusto Query Language)でクエリを実行・分析するためのAzure Portal上のツールがLog Analyticsです。
KQLを使用してログデータの表示、分析やグラフ化して表示できます。またAzure Monitorのアラートルールの条件などにも利用できます。
Azure Monitor の Log Analytics の概要
簡易モードを使用すると、ワンクリックでログ検索することができます。
ログ収集には診断設定やAzure Monitorエージェントを使う
Azure上のリソースで診断設定や、仮想マシンにインストールされたAzure Monitor Agentなどを通じて、Log Analyticsワークスペースへログ収集できます。
Azure Monitor Agentと、データ収集ルール(Data Collection Rule)を組み合わせることで、Windows イベントログなどを収集することもできます。
オンプレミスの仮想マシンなども、Azure Monitor Agentをインストールすることで、Log Analyticsワークスペースでログを収集できます。
その他にも、ログインジェストAPI(Logs Ingestion API)や、Azure Event Hubsから取り込むこともできます。
Azure Monitor のログ インジェスト API
チュートリアル: Azure Event Hubs から Azure Monitor ログにイベントを取り込む
※記事執筆時点では、Azure Event Hubsからの取り込みはプレビュー機能となっています。
※エージェントからLog Analytics ワークスペースへのデータ転送にはHTTPSが使用されます。アクセス許可設定が必要となります。
Log Analyticsワークスペースへの収集対象ログ
Log Analyticsワークスペースには、Azureリソースのメトリックやアクティビティログだけではなく、仮想マシンのOSログなど、多種多様なログを収集できます。
App Service、Cosmos DB、Front Door、Application GatewayなどのAzureサービスやPaaSのログも収集できます。
Windows OSの場合は、Windowsのイベントログ、IIS (W3CIISLog) のログ、Windows Firewallログなども収集可能です。
Microsoft Entra IDの監査ログやサインインログも収集されます。
Microsoft SentinelはLog Analyticsワークスペースをデータ基盤として利用し、各種コネクタを通じてログの取り込みと分析を行います。
Application Gatewayのアクセスログの確認方法については、こちらで紹介しています。
https://www.tama-negi.com/2019/07/15/azure-application-gatew...アクテビティログの収集設定手順やログ検索方法については、こちらで紹介しています。
テーブルプランの概要
ログはLog Analytics ワークスペースのテーブルに収集されます。
テーブルプランは、テーブルごとに利用用途に合わせてコスト最適化できる仕組みです。
データ保管やクエリ検索などに差があります。
テーブルプランには、Analytics、基本(Basic)、補助(Auxiliary)の3種類があります。
基本(Basic)をサポートするテーブルは限定されています。
Azure Monitor ログの Basic テーブル プランをサポートするテーブル
なお、現時点では補助(Auxiliary)は、API を使ってカスタム テーブルを作成するときのみに指定できます。
インタラクティブ保持期間とは、Log Analytics のテーブルで即座にクエリ・アラート・可視化に使える期間のことです。
期間を過ぎたデータは同じテーブル内で長期保持(アーカイブ)に移り、検索ジョブなどで取り出してから分析します。
| 項目 | Analytics | 基本(Basic) | 補助(Auxiliary) |
| 主な利用用途 | 継続監視・リアルタイム分析・検知など、頻度が高く高度な検索を行いたい場合に利用します。 | 障害対応時のみに利用するなど、検索頻度が低い場合に利用します。 | 監査用のデータ保管など、ログの保管が目的で検索をほとんど行わない場合に利用します。 |
| 取り込みコスト | ×(標準) | △(Analyticsよりは安価) | 〇(最安) |
| クエリ課金 | × | 〇(GBスキャン課金) | 〇(GBスキャン課金) |
| クエリ性能/使い勝手 | 〇(複数テーブルを横断した分析も可能) | △(検索速度は良いが単一テーブルのみの検索） | ×(監査用途でリアルタイムは不向き） |
| アラート | 〇 | △(Simple Log Alertsのみ) | × |
| Insights（組み込み分析） | 〇 | × | × |
| Azure Monitor Dashboards | 〇 | ×(Workbooks/Grafanaは可) | ×(Workbooks/Grafanaは可) |
| エクスポート | 〇 | 〇 | × |
| リストア | 〇 | 〇 | × |
| 検索ジョブ (Search jobs) |
〇 | 〇 | 〇 |
| データ保持 | 既定31日(一部テーブルは90日） インタラクティブ保持期間は最大730日 |
既定30日(既定の期間は無料) 30日を過ぎたログはアーカイブ保管 |
保持期間を指定 |
| KQL/クエリ制限 | ほぼ制限なし | 制限あり(単一テーブル) (join/search/findなど利用不可） |
制限あり(単一テーブル) (join/search/findなど利用不可） |
| 変更可否 | Analytics⇄Basic切替可 (週1回まで) |
Analytics⇄Basic切替可 (週1回まで) |
× (テーブル作成時に指定) |
すべてのテーブルプランについて、最大12年保持することができます。テーブル単位でログ保持期間を指定します。
90日間保持可能なテーブルについては、こちらに記載があります。
基本(Basic)テーブルでは過去30日間の検索時間範囲がサポートされます。
それ以降のデータを検索する場合は、検索ジョブを使用します。
なお、補助(Auxiliary)の場合は、保持期間分データについて通常のクエリ検索がサポートされています。
課金の概要
Azure MonitorのLog Analytics ワークスペースでは、データ取り込み、データ保持、データエクスポートなどで課金が発生します。
Azure Monitor の価格
Azure Monitor ログのコストの計算とオプション
一方でLog Analyticsを使用したクエリ検索はテーブルプランにより課金が異なります。
Analyticsテーブルでは発生しませんが、Basicおよび補助テーブルの場合には別途課金が発生します。
Azure Monitor ログの基本および補助テーブルのデータのクエリを実行する
ログ保管についても、既定の期間を超えた場合は別途課金が発生します。
既定の期間は、基本(Basic)、補助(Auxiliary)が30日、Analyticsは31日になります。
なお、一部データについては既定の期間が90日となります。
その他にも、アーカイブされた長期保管のログ検索時に利用する、ジョブの検索についても課金が発生します。
なお、データリストアの最小単位が2TB/12時間からとなっており、課金額が大きくなっているので注意が必要です。
また、1日あたり100GB以上のデータ取り込みを行う場合は、リソース予約(予約容量プラン)を利用することでコストを抑えることも可能です。
| 項目 | 単位 | 条件 | 備考 |
| データ取り込み(Ingestion) | GB | ワークスペースへ送信されたログデータ量 |
送信したログデータ量に基づいて課金されます。 |
| データ保持(Retention) | GB・日 | 既定保持期間超過分のデータ保持期間 | 既定の保持期間を超過したデータに対しては、日単位で課金されます。 データ保持に関する課金は、テーブルプランによって異なります。 既定の保持期間は、基本(Basic)および補助(Auxiliary)が30日、Analyticsは31日です。 一部のテーブルは既定で90日間データを保持します。 Sentinelを有効化した場合やApplication Insightsでは90日となります。 |
| KQLクエリ | Basic/AuxiliaryはGBスキャン課金 | インタラクティブ保持期間内のデータに対するクエリ | インタラクティブ保持期間内のログに対するクエリ課金です。 Analyticsテーブルの場合は、インタラクティブ保持期間内のデータに対するクエリには課金が発生しません。 BasicおよびAuxiliaryテーブルの場合は、クエリ時にスキャンしたデータ量に応じて課金されます。 |
| 検索ジョブ (Search Jobs) |
GBスキャン課金（アクセス日単位） | 長期期間保持ログおよびBasic/Auxiliaryからデータを取り出しログに対するクエリ |
長期保持データに対する検索ジョブは、指定期間に取り込まれたデータ量のスキャンGB数に基づいて課金されます。 |
| データリストア(Restore) | 復元したデータ量と稼働時間 | ホットキャッシュに指定期間分の復元したデータ量 | 指定期間のデータをホットキャッシュに復元し、高性能なクエリを可能にする機能です。 復元したデータ量とアクティブ時間に基づいて課金されます。 最小課金は2TB・12時間で、超過分は比例して課金されます。 Auxiliaryテーブルはリストア非対応で、BasicおよびAnalyticsテーブルのみ対応しています。 |
| データエクスポート(Data Export) | エクスポートしたJSONバイト数 | Storage/Event Hubsへ継続エクスポートしたデータ量 | 選択したテーブルをストレージやEvent Hubsに継続的にエクスポートする機能です。 エクスポートされたJSONデータのバイト数に基づいて課金が発生します。 Auxiliaryテーブルは非対応です。 保存先サービスの料金は別途発生します。 |
※必ず最新の価格表をご確認ください。
※Log AnalyticsでKQLクエリの実行結果をCSVなどのファイルとして手動でエクスポートする場合には、課金が発生しません。
—広告—
Log Analytics ワークスペースのリソースを作成する手順
Log Analytics ワークスペースのリソース作成手順
設定項目は、サブスクリプション、リソースグループ、ワークスペース名、作成する地域(リージョン)です。
取得対象のAzureリソースとは異なるリージョンでも利用可能ですが、同じリージョンに配置することが推奨されます。
同じリージョンに配置することで、リージョン間のデータ転送コストや遅延を回避できます。
| Log Analytics ワークスペースの作成手順 | |
|
Log Analytics ワークスペースのメニューで作成を選択します。 |
 |
|
基本設定画面が表示されます。 ※地域(リージョン)は、収集対象のAzureリソースと同じリージョンに作成することが推奨されます。 |
 |
|
確認画面が表示されます。 |
 |
※今回、タグは設定していません。利用環境に合わせて適時設定します。
テンプレートスペックを利用してLog Analytics ワークスペースのリソースを作成する手順については、こちらで紹介しています。
データ取り込み量や課金を確認する方法
Azure Portalで、Log Analyticsワークスペースのデータ取り込み量や課金状況を確認できます。
| 使用量と推定コストの表示方法 | |
|
設定にある使用量と推定コストから確認できます。 |
 |
※画面例は従量課金制の場合です。また、ログ収集設定してから期間が短いため情報が少なくなっております。
データ取り込み量の日次上限設定手順
Log Analyticsワークスペースでは、データ取り込み量の上限を設定することができます。
上限は1日あたりの取り込み量で指定します。
Log Analytics ワークスペースの日次上限を設定する
設定した上限に達すると、その日のログ取り込みが停止します。
取り込み停止後に発生したデータはワークスペースに保存されず、欠落するため、上限設定を利用する際は十分に注意が必要です。
また、上限到達からログ取り込み停止までにタイムラグが発生する場合があることにも注意が必要です。
| 日次上限の設定方法 | |
|
使用量と推定コストのメニューに、日次上限の設定項目があります。
|
 |
※補助 (Auxiliary) プランのテーブルは上限設定の対象外となります。
※課金対象外のテーブル (AzureActivityなど) も上限設定の対象外となります。
データ保持期間の設定手順
Log Analyticsワークスペースのデータ保持期間を延長することができます。
記事記載時点では、最大730日(保有期間731日)まで延長が可能です。
なお、データ保持期間を延長した場合、追加のストレージ課金が発生するため注意が必要です。
また、テーブルごとに保持期間を設定することもできます。
| データ保持期間の設定方法 | |
|
使用量と推定コストのメニューに、データ保持期間の設定項目があります。 |
 |
—広告—
Log Analytics ワークスペースでKQL使ってログを検索する方法
今回は、仮想マシンの分析情報(VM insights)で取得された値を例に、ログ検索を行っています。
VM Insightsで取得されるデータについては、こちらで紹介しています。
Log Analytics ワークスペースでのKQLクエリ実行方法
Log Analytics ワークスペースでのログ検索にはKQL(Kusto Query Language)を使います。
Kusto 照会言語の概要
KQL quick reference
検索には簡易モード(Simple mode)と、KQLモードがあります。
Log Analytics 単純モードを使用してデータを分析する
Log Analyticsワークスペースのリソースメニューからログを選択すると、検索を実行できます。
1度に取得できるログ件数には上限(50万レコード)があります。
なお、検索ジョブの場合の上限は、結果セットごとに1億レコードとなっています。
Azure Portal上で表示できる件数にも上限があります。
最大30,000レコードまでとなります。
| KQLのクエリ実行方法 | ||
|
Log Analyticsワークスペースのログから検索することができます。 |
|
|
|
簡易モードの場合は、取得対象のテーブルを選択します。 実行ボタンをクリックするとクエリが実行され、ログの取得結果が表示されます。 ログを選択して、ログの詳細を表示することができます。 |
|
|
【簡易モード(Simple mode)の例】 |
||
【KQLモードの例】 |
||
 |
||
条件に合致するレコードに絞り込みする場合はwhere 演算子
条件に合致するレコードに絞り込みする場合は、where 演算子を使います。
絞り込み条件は、以下の通りにしています。
-
- 仮想マシンはvm-01を対象とする
- メトリックはディスク空き容量率(FreeSpacePercentage)を対象とする
- ディスク領域はCドライブを対象とする
また、where 演算子はクエリ内で早めに使用して、レコードを絞り込むことが推奨されています。
CPU 使用率の高い関数を使用する前にレコードを早期にフィルター処理する
| where 演算子で絞り込みを行う | ||
|
仮想マシン名で絞り込みを行います。 例: where Computer == “絞り込む値" 絞り込みを行う項目名には、仮想マシン名が含まれるComputerを使用します。 |
|
|
 |
||
|
where 演算子は、and条件と組み合わせて利用することができます。 検索結果を確認すると、"vm-01″かつ取得メトリックが"LogicalDisk"のレコードのみが取得されていることがわかります。 |
|
|
|
|
||
|
ディスク空き容量に関するレコードに絞り込むため、where Name == “FreeSpacePercentage"という条件をand条件としてクエリに追加します。
|
|
|
|
|
||
|
ドライブ情報はTagsに含まれています。 一致条件に関する演算子については、こちらを参照してください。
|
|
|
|
|
||
※Computer列は仮想マシンのホスト名を示します。Azure Portal上の仮想マシン名と一致しない場合があります。
※今回のクエリは一例です。仮想マシン名で絞り込みを行う場合、Resource列を利用する方法もあります。
リソースIDからリソース名を抽出する方法については、こちらで紹介しています。
IPアドレスで絞り込みを行う場合のKQL例については、こちらで紹介しています。
必要な列(項目)のみ出力する場合はproject 演算子
検索結果のすべての項目(列)が必ずしも必要とは限りません。
project 演算子を使うことで、必要な情報だけに絞り込み結果を見やすくすることができます。
project 演算子を使うと、項目(列)の表示順も指定できます。
| project 演算子を使って項目を選択 | ||
|
project 演算子を使って、TimeGenerated, Computer, Tags, Name, Valに絞り込みます。 検索結果を見ると、出力内容の項目が絞り込まれていることが確認できます。また、表示順も指定した通りになっています。
|
|
|
|
|
||
並び替え(ソート)する場合はsort 演算子もしくはorder 演算子
検索結果時系列に並べたいなどの場合には、sort 演算子もしくはorder 演算子を使います。
ソート順の設定は以下のようになります。
-
- asc : 昇順 (小さい値から大きい値へ、または過去から現在の時間へ)
- desc : 降順 (大きい値から小さい値へ、または現在から過去の時間へ)
デフォルトはdesc(降順)になります。
※sort 演算子とorder 演算子は同じ動作になります。
| order 演算子で並び替え | ||
|
order by 並び替え項目で出力結果を並び替え(ソート)できます。TimeGeneratedで並び替えると、時間の降順で表示されていることが確認できます。 ※order by 項目(列)名1、項目(列)名2のように、複数の項目(列)を組み合わせて並び変えすることもできます。
|
|
|
|
|
||
※わかりやすくするため、例はdescを使用しています。
where 演算子を使って検索対象時間の範囲を指定できる
検索対象時間の範囲を指定する場合は、where 演算子を使用します。
-
- 検索時間制限の例
- where TimeGenerated > ago(時間)
- where TimeGenerated between (datetime(YYYY-MM-HHT hh:mm:ss.0000000Z) .. datetime(YYYY-MM-HHT hh:mm:ss.0000000Z))
- 検索時間制限の例
時間範囲を指定することで、検索対象のログ件数が限定されるため、クエリの実行速度が速くなります。
なお、デフォルトの検索範囲は過去24時間です。
| 検索時間範囲を制限 | ||
|
where TimeGenerated >(または<など) ago(時間)で検索範囲を指定できます。 ※ago関数は、d(日)、h(時間)、m(分)、s(秒)などの単位で指定できます。
|
|
|
|
|
||
検索結果の表示件数を指定する場合はlimit 演算子もしくはtake 演算子
検索結果の取得件数を制限したい場合には、limit 演算子もしくはtake 演算子を使います。
take 演算子とlimit演算子は同じ動作になります。
※時間範囲を指定する場合やソート条件を指定する場合は、limit 演算子やtake 演算子よりも先に指定します。
| 検索結果表示件数を制限 | ||
|
limit 件数で表示件数を制限できます。
|
|
|
|
|
||
※ソートと取得件数の上限を同時に指定する場合は、top演算子も利用できます。
既存の列は残したまま新しい列を追加する場合はextend 演算子
既存の列を残したまま新しい列を追加する場合には、extend 演算を使います。
extend 演算は計算して利用することができます。
例えば、日本時間とUTC時間両方表示するといったことができます。
| 列を追加して表示 | ||
|
extend 追加する列名で指定します。 ※追加する列名は任意で指定できます。
|
|
|
|
|
||
|
Azure Portalを利用している場合は、プルダウンでTimeGeneratedの表示時刻を選択できます。 |
|
|
検索結果をグラフ表示する場合はrender 演算子
検索結果をグラフで表示する場合は、render演算子を使用します。
render演算子をクエリの最後に追加することで、検索結果をグラフやチャート形式で表示できます。
さまざまなグラフ形式を指定できます。
| 検索結果をグラフで表示 | ||
|
render演算子の後にグラフ形式を指定します。
|
|
|
|
|
||
|
areachartを指定した場合です。 |
|
|
検索結果はエクスポートできる(CSVでダウンロード)
検索結果をCSV形式などでエクスポートできます。
検索結果画面の共有から、CSVファイルをエクスポートして保存できます。
| 検索結果をエクスポート | |
| 共有から検索結果をエクスポートすることができます。 エクスポート先にはCSVやPower BIなどが表示されます。 CSVへのエクスポートでは、すべての列を含めるか、表示している検索結果の列のみを含めるかを選択できます。 |
 |
Logic Appsを利用して定期的にストレージアカウント(BLOBコンテナー)にログ検索結果を保管する方法については、こちらで紹介しています。
—広告—
最後に
初めてのLog Analyticsということで、Log Analyticsの概要からワークスペースのリソース作成や設定までの手順を確認しました。
また、KQL(Kusto Query Language)を利用してログ検索を行う手順についても確認しました。
引き続き、いろいろ試してみたいと思います。
Log Analytics ワークスペースの削除については、こちらで紹介しています。
ログの転送状況の監視方法については、こちらで紹介しています。