Log Analytics と KQL クエリ
サービスの信頼性に注目し始めると、その信頼性がどの程度なのか (あるいはそうでないのか) を追跡する方法が必要になります。 多くの場合、このような情報はサービスのログから見つけることができるので、ログを扱うツールが必要になります。 Log Analytics は、この目的のために Azure で使用するツールです。 これにより、このデータに対してクエリを実行し、信頼性の作業に役立つ方法で表示できます。
Log Analytics のクエリ プロセスでは、Kusto クエリ言語 (KQL) でクエリが作成されます。 他のクエリ言語 (たとえば、ほとんどの人がその頭字語、SQL で認識している構造化照会言語) を使用したことがある場合は、KQL を選択しても問題はありません。 そうでない場合でも、そのしくみがわかれば、基本的な KQL クエリをごく簡単に使用できるようになります。
Log Analytics のしくみ
では、これがどのように動作するかを見てみましょう。 Log Analytics のしくみを次の図に示します。
Log Analytics のデータは、次のようなさまざまなソースから取得できます。
- Windows イベント ログ
syslog
Linux マシン- VM 上で実行されているエージェント
- ユーザーが送信を選択するカスタム ログ
- Azure リソースからのメトリック
- Application Insights からのテレメトリ情報
これらの情報はすべて、Log Analytics でテーブルと呼ばれるものに格納されます。 各テーブルは個別のデータベースと考えることができます。 テーブルから情報を取得するクエリを作成します。 このモジュールで後ほど説明する例では、主に "requests" という名前のテーブルを使用します。
Log Analytics のインターフェイス
次の図は、Log Analytics インターフェイスのさまざまな部分を示しています。
左側には、Log Analytics の使用時に今いる場所を確認できる画面のセクションがあります。 ここでは、使用している可能性のあるテーブルが示されます。また、セクションを展開すると、そのテーブル内のフィールドが一覧表示され、クエリに使用できます。 いずれかのフィールドまたはテーブル名を選択すると、クエリの構築領域にコピーされます。
クエリの構築領域は上部にあります。 ここで、クエリを指定して実行します。 そのデータの時間枠がクエリの一部として指定されていない場合は、指定できます。 一度に複数のクエリを操作する場合は、クエリを保存したり、追加のタブを開いたりできます。
ページの下部には、より有用な情報があります。 Log Analytics のこの部分には、実行した以前のクエリが表示されます。これは、以前に指定したクエリに戻る必要がある場合に役立ちます。たとえば、クエリを操作していて、何かを試行し、バックトラックの必要が生じた場合などです。
KQL クエリの作成
KQL は強力なクエリ言語です。 ここでは、使用がいかに簡単かを示すために、いくつかの基本的なクエリのみを使用してみます。 後で、より高度な機能 (一部の機械学習機能を含む) の使用について詳しく知りたい場合は、Log Analytics のチュートリアルを参照してください。
まず、単純な KQL クエリを作成してみましょう。 ほとんどすべての KQL クエリは、クエリを実行するテーブルであるデータ ソースから始まります。 そのため、"requests" テーブルからデータのクエリを実行する場合は、クエリ領域で次のように開始します。
Requests
KQL クエリの次の部分では、実行する操作をテーブルに接続します。 テーブル名とコマンドの間に、パイプ文字 (最も一般的にはスラッシュ キーの上にある、キーボード上の水平バー) を使用します。
テーブルを並べ替えて、見つかった上位 10 件のレコードを返す単純なクエリを次に示します。
Requests
|top 10
"top 10" の代わりに使用できるその他の一般的なコマンドの例を次に示します。
上位 10 件の代わりにランダムな 10 件レコードを表示する場合 (テーブルの構造を表示する場合など) は、次のコマンドを使用します。
requests |take 10
過去 30 分間に発生したレコードを表示するには、次のクエリを使用します。
requests |where timestamp > ago(30m)
もう 1 つの一般的なタスクは、データが返される順序を指定することです。 特定のフィールド (タイムスタンプ) で降順に並べ替える (たとえば、最新のデータが最初にくる) クエリの例を次に示します。
requests |sort by timestamp desc
SQL と同様に、複数の条件を設定して、どのレコードを返すかを指定できます。 追加のパイプ文字と句を使用して追加します。 パイプ文字はコマンドを分離するため、最初のコマンドの出力が次のコマンドの入力になります。 1 つのクエリに、任意の数のコマンドを含めることができます。
次は、過去 30 分間のすべての 404 応答コード レコード (たとえば、Web サービスからのすべての "ページが見つかりません" レコード) を返すクエリの例です。
requests
|where timestamp > ago(30m)
|where toint(resultCode) == 404
このクエリは、効率を最大化するために記述されています。 最初の 30 分間のレコードのみを選択すると、2 番目の句がスキャンする必要があるレコードの数が大幅に減少します。 このクエリを逆の順序で記述すると、最初にデータの最初からすべての 404 が検出されてから、最後の 30 分のデータのみになるように、その大部分が破棄されます。 複数の条件を持つクエリを記述する場合は、常に処理の順序を考慮してください。
このモジュールで後述する Log Analytics の機能に戻る前に、最後のクエリ例を示します。これは、信頼性の向上に役立ちます。 こちらは、データに基づく計算を示すクエリです。
requests
|where timestamp > ago(30m)
|summarize count() by name, URL
このクエリでは、過去 30 分間に受信した要求の概要が返されます。 そのため、Web サービスでは、GET index.html
要求が URLhttp://tailwindtraders.com
に対して 2,875 回行われていることがわかります。 このクエリの KQL には注目しません。次のユニットで使用する KQL クエリに続くとわかりやすいためです。