ES|QL（Elasticsearch Query Language）を使い始める

ES|QL（Elasticsearch Query Language）とは、Elastic®の新しい革新的なパイプ型クエリ言語です。パワフルなコンピューティング機能とアグリゲーション機能でデータの分析と調査をスピードアップするよう設計されています。 

展開中のサイバー攻撃の識別や運用上の問題の特定といった複雑な作業を、より簡単かつ効率的に行えるようになります。 

ES|QLは、大規模データセットの検索、アグリゲーション、ビジュアライゼーションをシンプル化するだけでなく、ルックアップやリアルタイム処理などの高度な機能でユーザーを支援します。しかも、これらすべての操作を、Discoverの1つの画面で行うことができます。

ユーザーが求めているのは、データを表示するだけでなく、データを効率よく活用できる手段を提供してくれるアジャイルなツールと、リアルタイムでインサイトに基づいて行動したり、取り込み後データを処理したりできる機能です。 

Elasticは、ユーザーのデータ探索エクスペリエンスを強化する取り組みを進めてきましたが、その結果たどり着いたのがES|QLへの投資でした。ES|QLは、初心者には使いやすく、エキスパートには頼もしい設計になっています。ES|QLは直感的なインターフェースで、ユーザーは多くのことを修得しなくても、すぐに利用を開始してデータを深掘りできます。自動入力とアプリ内ドキュメントにより、高度なクエリの作成も、ワークフローを中断せずに進められます。 

さらに、ES|QLは数字を見せてくれるだけでなく、それに命を吹き込んでくれます。クエリの性質に合わせて自動調整されるLensのサジェストエンジンを活用した、コンテクストに基づくビジュアライゼーションにより、インサイトを明確に把握できます。 

また、ダッシュボード機能とアラート機能への直接の統合により、エンドツーエンドで統一感のあるエクスペリエンスというElasticのビジョンが反映されています。 

要するに、ES|QLへの投資は、コミュニティの進化するニーズに対するElasitcからの直接の回答であり、より密接に連携し、インサイトにあふれ、効率的なワークフローに向けた一歩なのです。

これでDiscoverがES|QLモードになります。

ES|QLを使用すれば、包括的でパワフルなデータ探索を実行できます。Discover内でアドホックなデータ探索を実行でき、クエリビルダーから直接、アグリゲーションの作成、データの変換、データセットのエンリッチなどの作業を行えます。結果は実行したクエリに応じて、表形式かビジュアライゼーションで表示されます。

下の方で示すオブザーバビリティのためのES|QLクエリの例では、結果が表形式で表示された場合と、ビジュアライゼーションで表示された場合を掲載しています｡ 

メトリックを使用するES|QLクエリのユースケース：

上の例では、以下のソースコマンド、アグリゲーション関数、処理コマンドの使い方を紹介しています。 

fromソースコマンド（ドキュメント）

from metrics*：これにより、「metrics*」のパターンと一致するインデックスパターンからクエリが開始されます。 アスタリスク（*）はワイルドカードの役割を果たします。つまり、名前が「metrics」で始まるすべてのインデックスパターンからデータが選択されます。 

stats...byアグリゲーション（ドキュメント）、max（ドキュメント）、by（ドキュメント） 

このセグメントでは、特定の統計に基づいてデータがアグリゲーションされます。分解すると次のようになります： 

max_cpu=max(kubernetes.pd.cpu.usage.node.pct)：それぞれの「kubernetes.pod.name」ごとに最大のCPU使用率が検索され、その値が「max_cpu」という名前の新しい列に格納されます。 

max_mem = max(kubernettes.pod.memory.usage.bytes)：それぞれの「kubernetes.pod.name」ごとに最大のメモリー使用量（バイト単位）が検索され、その値が「max_mem」という名前の新しい列に格納されます。 

処理コマンド（ドキュメント）

• sort（ドキュメント） 
• limit（ドキュメント）

sort max_cpu desc：これにより、結果データの行が「max_cpu」列の値に基づいて降順に並べ替えられます。つまり、「max_cpu」の値が最も大きい行が一番上になります。 

limit 10：これにより、出力件数が並び替え後の上位10件の行に制限されます。 

このクエリをまとめると以下のようになります。 

• インデックスパターンを使用して、すべてのメトリックインデックスのデータをグループ化
• データをアグリゲーションし、それぞれのKubernetesポッドについて、最大CPU使用率と最大メモリー使用量を検索
• アグリゲーション済みデータを最大CPU使用率に基づいて降順に並び替え
• CPU使用率で上位10件の行のみ出力

コンテクストに基づくビジュアライゼーション：DiscoverでES|QLクエリを記述すると、Lensのサジェストエンジンによるビジュアル表示が行われます。どのようなビジュアライゼーションが行われるかはクエリの性質によって決まり、メトリック、ヒストグラム、ヒートマップなどがあります。 

下の画像には、「max_cpu」、「avg_mem」「kubernetes.pod.name」の各列を含む先ほどのクエリの結果が、棒グラフ形式と表形式でビジュアル表示されています。

オブザーバビリティと時系列データを使用したES|QLクエリのユースケースの例： 

上のクエリでは、以下のソースコマンド、アグリゲーション関数、処理コマンド、関数の使い方を紹介しています。 

fromソースコマンド（ドキュメント）

from apache-logs：これにより「apache-logs」という名前のインデックスからクエリが開始されます。 このインデックスにはApache Webサーバーのトラフィックに関連するログエントリーが含まれています。 

where（ドキュメント）

where url.original==”/login”：「url.original」フィールドが「/login」と等しいレコードのみに絞り込まれます。 つまり、ここではログイン試行かログインページへのアクセスに関連するログエントリーだけを見たいということです。 

eval（ドキュメント）とauto_bucket（ドキュメント）

eval time_buckets =... ：これにより「time_buckets」という名前の新しい列が作成されます。 

「auto_bucket」関数は、人間にとってわかりやすいバケットを作成し、行ごとに、その行が属するバケットに対応する日時の値を返します。 

「@timestamp」は、各ログエントリーのタイムスタンプが含まれるフィールドです。 

「50」はバケットの数です。 

「2023-09-11T21:54:05.000Z」：バケット化の開始時間です。

「2023-09-12T00:40:35.000Z」：バケット化の終了時間です。 

これは、「2023-09-11T21:54:05.000Z」から「2023-09-12T00:40:35.000Z」までのログエントリーが等間隔で50分割され、各エントリーがタイムスタンプに基づいて特定の間隔に関連付けられることを意味します。 

ここでは、正確な目標バケット数を指定するのではなく、指定した目標バケット数を上限として自分のニーズを満たせるように範囲を指定します。得られるバケット数を増やすには、auto_bucketに設定する範囲を狭くしてください。 

stats...byアグリゲーション（ドキュメント）、count（ドキュメント）、by（ドキュメント） 

stats login_attempts = count(user.name) by time_buckets, user.name：ログイン試行の回数を計算するためにデータがアグリゲーションされます。そのために、「user.name」（ログインを試行したユニークユーザーを表します） の発生回数がカウントされます。

カウントは「time_buckets」（作成した間隔）と「user.name」の両方でグループ化されます。 つまり、時間バケットごとに、各ユーザーがログインを試行した回数が表示されます。 

sort（ドキュメント） 

Sort login_attempts desc：最後に、アグリゲーションの結果が「login_attempts」列に基づいて降順で並び替えられます。つまり、ログイン試行回数が最も多い結果が一番上に表示されます。 

このクエリをまとめると以下のようになります。

• 「apache-logs」インデックスからデータを選択
• ログインページに関連するログエントリーに絞り込み
• 絞り込んだエントリーを特定の間隔にバケット化
• それぞれの間隔について、ユニークユーザーごとにログイン試行回数をカウント
• 結果をログイン試行回数が多い順に並び替え

下の画像には、「login_attempts」、「time_buckets」「user.name」の各列を含む先ほどのクエリの結果が、棒グラフ形式と表形式でビジュアル表示されています。

ES|QLのビジュアライゼーションは、DiscoverとDashboard内で編集できます。Lensに移動することなくスピーディに編集でき、シームレスに変更を加えられます。 

ここでは、ワークフローをひととおり確認できる動画と、ステップガイドを掲載しています。

1. ES|QLクエリを記述する

2. クエリの性質に応じてコンテクストに基づくビジュアライゼーションが表示される

3. ビジュアライゼーションをインライン編集する

4. Dashboardに保存する

5. Dashboardでビジュアライゼーションを編集できるようになる

手順1. ES|QLクエリを記述する。この例ではメトリックビジュアライゼーションを生成するクエリを使用します。

手順2. クエリの性質に応じて、コンテクストに基づくビジュアライゼーション（この例ではメトリックビジュアライゼーション）が表示される。鉛筆のアイコンを選択すると、インライン編集モードに移行します。

手順3. インライン編集モードでビジュアライゼーションを編集する

上の例では、ビジュアライゼーションを動的カラーモードにするために［Dynamic］（動的）に切り替えています。

使用する色の範囲を定義することもできます。

手順4. Dashboardに保存する

手順5. Dashboardでビジュアライゼーションを編集できるようになる

ES|QLを使用して、集計値をしきい値に設定したオブザーバビリティアラートやセキュリティアラートを作成できます。切り分けられたインシデントではなく意味のあるトレンドに注目することで誤検知が減り、検知精度を高めて実用的な通知を受け取ることができます。 

ここでは、DiscoverでES|QLアラートのルールタイプを作成する方法に絞って解説します。 

新しいアラートのルールタイプは、既存のElasticsearchルールタイプに基づいて利用できます。このルールタイプでは、ES|QLに搭載された新しい機能をすべて活用でき、アラートの新しいユースケースの可能性が広がります。

新しいタイプでは、定義したES|QLクエリに基づいてアラートを1件だけ生成し、ルールを保存する前にクエリの結果をプレビューで確認できます。クエリで空の結果が返された場合は、アラートは生成されません。

アラート用のクエリの例：

手順1. ［Alert］（アラート）をクリックし、［Create search threshold rule］（検索しきい値ルールの作成）を選択します。 ES|QLアラートのルールタイプの作成は、クエリバーでES|QLクエリを定義した後でも、ES|QLクエリを定義する前でも開始できます。クエリの定義後に作成を開始する場合には、クエリが自動的に［Create Alert］（アラートの作成）フライアウトに貼り付けられるというメリットがあります。 

手順2. ES|QLアラートのルールタイプの定義を始めます。

手順3. アラートのルールタイプクエリをテストします。［Test query］（クエリのテスト）をクリックすると、貼り付けられたES|QLクエリを繰り返しテストできます。 結果は表形式でプレビュー表示されます。 

手順4. コネクターを設定して［Save］（保存）をクリックします。 これでES|QLアラートのルールタイプが作成されました。

enrichコマンド（ドキュメント）を使用すると、クエリデータセットを別のデータセットのフィールドでエンリッチし、選択したポリシーのコンテクストに合ったサジェスト（一致するフィールドやエンリッチされた列のヒント表示など）で補完できます。

下のenrichを使用したクエリの例では、クエリを介してエンリッチポリシー「servers-to-project」が使用され、name、server_hostname、costでデータセットがエンリッチされています。

また、簡単にエンリッチポリシーを作成できるように、概要やエンリッチポリシー作成ウィザードも追加されました。 

エンリッチポリシーの概要は、［Stack Management］（スタックの管理）>［Index Management］（インデックスの管理）の順に移動した先の、［Enrich Policies］（エンリッチポリシー）というタブのところにあります。

画像には、上のクエリで使用されている「servers-to-project」というエンリッチポリシーが見えます。

新しいエンリッチポリシーは、［Create enrich policy］（エンリッチポリシーの作成）をクリックすると作成できます。エンリッチポリシーを作成して実行すると、すぐにDiscoverのES|QLクエリで使用できるようになります。

エンリッチポリシーについて詳しくはこちらを、ES|QLのenrichコマンドについてはこちらをご覧ください。