このブログでは、Elasticsearch 9.1 の ES|QL エディターの開発者エクスペリエンスを、OpenSearch 3.2 のイベント アナライザー (略して PPL) の PPL と比較しながら探っていきます。

違いはすぐに明らかになります。ES|QL エディターは、初心者ユーザーだけでなく、エキスパートレベルのユーザーにも力を与えるインテリジェントなオートコンプリート、コンテキスト ヘルプ、推奨クエリ、およびクラスター間クエリ サポートを提供します。ES|QL オーサリングの思慮深い設計は、たとえば最近のクエリを使用した Kibana ワークフローによる統合クエリ検査と総合的な統合にも反映されています。

対照的に、PPL にはオートコンプリート、コンテキスト ガイダンス、分散クエリに対する同等のサポートがないため、学習曲線が急峻になり、試行錯誤が増えます。

ES|QL の学習と使用を容易にする

新しいクエリ言語を使い始めると、圧倒されると感じることがよくあります。Kibana Discover に直接組み込まれた ES|QL エディターは 、 クエリの作成とデバッグをサポートするだけでなく、言語に慣れて使いこなせるようになるまでの時間を短縮することで、そのプロセスを容易にするように設計されています。エディターは日常のタスクの摩擦を軽減するのに役立つため、構文や試行錯誤からソリューションの作成に焦点を移すことができます。これらの原則と、それをエディターにどのように統合したかの詳細については、こちらをご覧ください。

このエディター エクスペリエンスは Discover に限定されません。これは再利用可能なコード モジュールであり、ダッシュボード、Kibana アラート、Kibana マップなど、 Kibana の他の部分に統合する作業が進められています。

インテリジェントなオートコンプリート: クエリ作成を高速化

ES|QL エディターのオートコンプリートは包括的で、互換性のある関数、引数、リテラル、さらにはネストされた関数の提案を提供します。これは PPL には明らかに欠けている機能です。実際、ここで概説されているように、根本から再構築されました。

ここで説明されているように、検証はユーザーが入力すると実行され、フィールドを提案し、ユーザーにエラーを通知します。これにより、ユーザーの精神的負担が軽減され、クエリ作成プロセスの早い段階でエラーを防ぐことができます。

例: このネストでは、フィールドと互換性のある関数が提案されています。

PPL がサポートしていないもの:

互換性のある関数、引数、ネストされた関数を案内するインテリジェントなオートコンプリート機能があっても、利用可能なオプションについてさらに深く理解したい場合があります。ここで、ES|QL エディターのコンテキスト ヘルプが非常に役立ち、エディター内で即時に支援が提供され、クエリの開発が明確化され、強化されます。

指先で状況に応じたヘルプ

オートコンプリートによって生成されたコマンドに関する追加情報は、Ctrl キーとスペース キーを押すことで表示されます。問題の関数、引数、またはフィールドの詳細を示すパネルがすぐに表示されます。この軽量なインタラクションにより、開発者はスムーズに作業を進めることができ、エディターを離れたり外部ドキュメントを検索したりすることなく、ジャストインタイムのガイダンスを得ることができます。これにより、構文の検索に費やす時間が削減され、よくある間違いを未然に防ぐことができます。

実際の動作は次のようになります。

PPL にはこのレベルの組み込みガイダンスがないため、ユーザーは外部のドキュメントや試行錯誤に頼ることになります。その欠如は単に機能が欠けているというだけではなく、設計哲学におけるより広範な相違を浮き彫りにしています。ES|QL は、ユーザーのデータとワークフローに適応する、思慮深くコンテキストを意識したエクスペリエンスを優先します。この違いはクエリの複雑さが増すにつれて顕著になり、ES|QL エディターは学習と本番使用の両方においてより効率的で信頼性の高い環境になります。

データのコンテキストを考慮した推奨クエリ

ES|QL エディターは、ログなどの作業中のデータに合わせて自動的に調整される推奨クエリを提供します。空白のエディターを表示する代わりに、一般的なユースケースに最も関連性の高い開始点を表示します。推奨クエリを選択すると、すぐに使用できる標準クエリが生成され、必要に応じてさらに絞り込むことができます。このアプローチにより、特に完全な構文をまだ知らない新しいユーザーにとって、クエリの開発が加速されます。

以下は、ユーザーが「変化点の検出」クエリを選択する例です。

これを PPL の経験と比較してみましょう。

対照的に、ここでの PPL は基本的なオートコンプリートのみを提供するため、コンテキストや構造なしでクエリを組み立てることになります。このガイダンスの欠如は、フラストレーションと試行錯誤につながる可能性があります。ES|QL エディターのデータ対応の推奨クエリを使用すると、日常的なタスクの構文を最初から作成したり、暗記したりする必要がなくなります。エディターは認知負荷を軽減し、エラーの防止に役立ち、クエリの構築に悩むのではなく、問題解決やクラスター間検索の実行などのより広範な目標に集中できるようにします。

直感的なクラスター間クエリ

ES|QL エディターのオートコンプリートは、 CCS を使用して複数のリモート クラスターを操作する場合でも、優れた性能を維持します。理由は次のとおりです。

ES|QL エディターは、クラスター間でもシームレスなオートコンプリートを提供します。

ES|QL エディターのオートコンプリートは、クラスター名だけでなく、ローカル インデックスとリモート インデックスの両方をサポートします。ここで説明されているように、これはコーディネーター ノード アーキテクチャのおかげで機能します。このアーキテクチャは、ローカル ノードに送信するクエリ プランを検証および生成し、クエリを実行して結果を集計してからユーザーに送り返すのに役立ちます。完全なリモート クラスター名を入力せずに「:」と入力すると、リモート インデックスの自動補完プロセスが開始されます。また、接頭辞に限定されるわけではありません。

これにより、命名規則を記憶したりコンテキストを切り替えたりすることなく、分散データセット全体の検出とクエリを簡単に実行できるようになります。

以下は、ユーザーが「clu:g」と入力してリモート インデックスを検索する例です。

対照的に、PPL はローカル インデックスに対して基本的な補完のみを提供し、提案はプレフィックスの一致に制限されています。リモート クラスターは手動で入力する必要があるため、エラーが発生する可能性が高まり、クエリの作成が遅くなります。

PPL はローカル インデックスに対してのみ補完を提供し、提案はプレフィックスに制限されます。

ES|QL ではさらに、負の符号を使用して直接除外できるため、探索に参加するクラスターをきめ細かく制御できます。この機能は、クラスター間の調査中に特定のデータセットを含めたり省略したりする必要があるハイブリッド環境で作業する場合に特に役立ちます。

これらの機能強化は、Elasticsearch がクラスター間検索における摩擦の軽減に重点を置いていることを反映しています。ES|QL エディターでは、分散クエリの構築と管理が容易になるため、アナリストや開発者は構文ではなく洞察に集中できます。一方、PPL ではその負担がユーザーに多く残ります。ES|QL エディターは、クラスター間クエリの作成を簡素化するだけでなく、それらのクエリの実行方法を検査するツールも提供し、複数のクラスターにわたる透明性とパフォーマンス監視を保証します。

検査ツールを使用してクロスクラスター検索の詳細を分析する

ES|QL エディターからアクセスできる検査ツールは、すべてのクラスターにわたるクエリ実行に関する明示的な情報をメタデータに提供するように設計されています。この機能は Kibana Discover で有効になっており、クエリ インスペクターから直接アクセスできるため、検索の進行状況と詳細を分析できます。これは、Cross-Cluster Search ( CCS ) にとって特に重要です。この機能を使用すると、検索の進行状況を監視し、分散データセット全体でのクエリの実行方法を把握できます。

特に複雑な分散検索の場合、クエリ実行の詳細な可視性により、最適なパフォーマンスとトラブルシューティングが可能になります。

ES|QL エディターは、個々のクエリの仕組みを理解するだけでなく、Kibana プラットフォーム全体に重要な機能を深く組み込むことでユーザー ジャーニーをさらに強化し、シームレスで中断のないワークフローを促進します。

ES|QLとKibanaによる統合クエリエクスペリエンス

クエリ駆動型分析における最も一般的な摩擦の原因の 1 つは、コンテキストの切り替えです。すでに記述したクエリを思い出す必要がある場合がよくあります。中断されるたびに集中力が途切れ、調査が遅くなります。ES|QL エディターは、Kibana 全体のクエリ履歴を統合することでこの問題に対処します。

最近のクエリ

ES|QL エディターの最近のクエリ機能を使用すると、過去の作業にすぐにアクセスできるようになり、作業の流れを維持できます。Discover の ES|QL エディターでは、過去 20 件のクエリを表示、再実行、スター付けすることができ、頻繁に使用するクエリや複雑なクエリを 1 回のクリックで実行できるようになります。保存されたクエリは Kibana 全体に引き継がれ、ダッシュボード、視覚化、アラート、マップと統合されるため、現在の画面を離れたり、コマンドを最初から再入力したりする必要はありません。これにより、反復的な作業が削減され、調査が高速化され、エラーのリスクが最小限に抑えられます。

たとえば、ユーザーは Discover の ES|QL エディターで最近のクエリを利用できます (そしてスターを付けることもできます)。

最近のクエリはダッシュボードに統合されています。

PPL には同等の機能は用意されていないため、ユーザーはクエリを再利用するために手動でのコピー アンド ペーストや外部メモに頼ることになります。この違いは利便性だけではありません。これは、ES|QL を Kibana エコシステム内に真に統合された言語として構築するという Elastic の戦略を反映しています。ES|QL エディターは、最近のクエリなどの機能により、日常のワークフローを効率化するだけでなく、現在テクニカル プレビューで提供されているより高度な機能の基盤も構築し、エクスペリエンスの継続的な進化を保証します。

まとめ

ES|QL は単なる構文ではありません。ユーザーがデータを検索、探索、分析する方法を改善するという Elastic の戦略を反映しています。インテリジェントなオートコンプリート、コンテキスト認識型の推奨クエリ、エディター内ガイダンス、Inspect などのツールを備えた ES|QL エディターは、学習を加速し、エラーを削減し、クラスター間分析などの複雑なワークフローを簡素化します。Kibana 全体に統合されており、クエリをダッシュボード、アラート、視覚化にシームレスに接続して、中断のないワークフローを実現します。

要約すると、ES|QL は単なる別のパイプ言語ではありません。データとの対話方法を根本的に再定義する直感的な UI と組み合わせた、思慮深く設計されたクエリ エンジンであり、OpenSearch PPL の多くの場合シーケンシャルでガイドが少ない性質とは対照的に、統合されたインテリジェントで継続的に進化するエクスペリエンスを提供します。

次は何？

このブログは ES|QL の表面的な部分のみを取り上げています。今後の投稿では、OpenSearch PPL との比較をさらに深め、地理空間、視覚化、コントロール(ダッシュボードで既に利用可能)、マルチデータ探索タブ、バックグラウンド検索、より豊富なクエリ履歴、FUSE などの今後のエディター機能について説明します。

今すぐES|QLをお試しください

無料トライアル で、完全に管理された Elasticsearch Serverless プロジェクトで ES|QL を試すことができます。8.11 以降のバージョンでも利用可能ですが、 8.19 および 9.1で最も快適にご利用いただけます。

1 つのコマンドでローカル環境で数分以内に開始できます。

本日、Elasticsearch の新しいインデックス モードである logsdb の一般提供開始を発表しました。これにより、logsdb のない Elasticsearch の最新バージョンと比較して、ログ データのストレージ フットプリントが最大 65% 削減されます。この劇的な改善により、観測性およびセキュリティ チームは、予算を超過することなく可視性を拡張しながら、すべてのデータを分析のためにすぐにアクセスできるようになります。

Logsdbはデータの順序を最適化し、synthetic _sourceで即座に非格納フィールド値を再構築することにより重複を排除します。また、高度なアルゴリズムとコーデックを使用して圧縮を改善するとともに、Elasticsearch内の列型ストレージを活用して、効率的なログのストレージと取得を実現します。

logsdbインデックスモードを使用してストレージ効率を改善し、分析を強化し、コストを削減

ログは、オブザーバビリティとセキュリティの問題を検出し修正するための重要なシグナルを提供します。AIの進歩によりテキストベースのデータの分析が容易になるにつれて、その有用性は増しており、効率的なストレージと高性能なアクセスがこれまで以上に重要になっています。

残念ながら、インフラストラクチャーやアプリケーションによって生成されるログ量の増加はコストを押し上げており、データ収集の制限、保存期間の短縮、最新データをサイロ化されたアーカイブ層に追いやったりといった、分析を妨げる妥協を強いられています。

Logsdbはこれらの課題に直接対処します。ストレージ効率が向上すれば、より多くのデータを収集でき、複雑なデータフィルタリングの手間を避けることができます。脅威ハンティング、インシデント対応、コンプライアンス要件をサポートするために、ログをより長く保持することができます。すべてのデータが常に検索可能であるため、データセットがどれほど大きくなっても、迅速に洞察を得ることができます。

logsdbインデックスモードの背後にある技術的革新

Logsdbインデックスモードは、スマートインデックスソート、synthetic _source、および高度な圧縮を使用して、ログデータのディスクフットプリントを劇的に削減します。これを実装することで、logsdbを使用しない最新バージョンのElasticsearchと比較して、ログストレージの必要量を最大65%削減できます。現在、logsdbはインデキシング時により多くのCPUを使用しますが、その効率的なストレージによって、ほとんどのお客様にとって全体的なコストが削減されます。長期的なデータ保持を必要とするお客様には、総所有コスト（TCO）が最大50%削減されることを見込んでいます。

スマート インデックス ソートにより、類似のデータを近くに配置することで、ストレージ効率が最大 30% 向上し、一部のログ データ セットでのクエリの待機時間が短縮されます。デフォルトでは、インデックスは host.name と @timestamp でソートされます。データにさらに適切なフィールドがある場合は、代わりにそれを指定することもできます。

高度な圧縮により、Zstandard 圧縮 (Zstd)、デルタ エンコーディング、ランレングス エンコーディング、および自動的に選択されるその他のスマート コーデックを通じて、ログなどのテキストを多く含むデータのストレージ要件が大幅に削減されます。圧縮とパフォーマンスが最適化された列形式で保存される Doc-values により、並べ替え、集計、スクリプト用のフィールド値を効率的に保存および取得できます。

合成 _source を使用すると、組織は _source フィールドを破棄し、オンデマンドでそれを完全にまたは部分的に再構築することで、ストレージのニーズをさらに 20 ～ 40% 削減できます。この機能では、インデックス作成と検索により多くの計算が必要になる場合もありますが、テストでは測定可能な純効率の向上がもたらされることが示されています。Synthetic _source は、ほぼ 2 年間のメトリクスを使用した本番環境での使用に基づいて構築されており、ほぼすべてのフィールド タイプのサポートを含む、ログの多数の機能強化が行われています。

結果として得られるストレージの節約は、インデックスライフサイクルの各フェーズに渡って反映されます。ホットティアでのストレージ削減が65％である場合、ウォーム、コールド、フローズンティアでも同様に65%の削減が適用され、スナップショットをバケットストレージに保存する際のフットプリントも削減されます。

可視性を妥協しない：オブザーバビリティとセキュリティのためにすべてのログを保持

ログはインフラストラクチャとアプリケーションの可視性の基盤であり、監視とトラブルシューティングのための最も単純で基本的なシグナルを提供します。しかし、ログの量の増加に伴い、コストが上昇しています。この課題により、お客様は複雑なフィルタリングおよび管理ポリシーを導入する必要に迫られたり、データを早期に削除したり、データを取り出して分析できる状態にするには1日以上かかるストレージに関連ログを格納することを余儀なくされています。完全で、簡単に検索でき、アクセス可能なデータセットがなければ、問題を見つけて解決することは大幅に困難になります。

Logsdb インデックス モードは、検索可能なスナップショットや自動インポートなどの画期的な Elasticsearch 機能を基盤として構築されており、運用チームとセキュリティ チームの次のような問題点に対処します。

コストの削減: Logsdb はログのストレージ フットプリントを最大 65% 削減し、組織がより多くのデータを保持しながらストレージ費用を削減できるようにします。これにより、ホットからフローズンまですべてのストレージ層でコストが削減され、このデータを使用する観測性およびセキュリティ チームの生産性が向上します。

貴重なデータを保存: Logsdb はすべてのログ データを保存し、追加のツールや複雑なフィルターに頼ることなく運用効率を向上させます。合成 _source などの機能を使用すると、ソース ドキュメント全体を保存せずにデータの値を保持できます。

可視性の拡張: Logsdb は、観測性、セキュリティ、履歴データ用の個別のサイロなしで、1 つのプラットフォーム上のすべてのデータへの効率的なアクセスを提供します。サイト信頼性エンジニア (SRE) にとっては、メトリック、トレース、ビジネス データとともにログを分析できるため、問題解決が迅速化されます。同様に、セキュリティ オペレーション センター (SOC) チームにとっては、盲点を排除することで調査と修復が加速されます。

データへのアクセスを合理化: Logsdb を使用すると、SRE チームはトラブルシューティング、傾向分析、分析のために実用的なデータを効率的に保持できます。同様に、SOC チームは、法外なコストをかけずに、調査や脅威ハンティングのためにすべてのデータを迅速に検索できます。

Logsdbはあなたの環境に対応しています

Elasticsearch logsdb インデックス モードは、バージョン 8.17 以降、Elastic Cloud Hosted および Self-Managed のお客様に一般提供され、 Elastic Cloud Serverlessのログではデフォルトで有効になっています。

基本的なlogsdbの機能（スマートインデックスソートや高度な圧縮を含む）は、Standard、Gold、Platinumライセンスをお持ちの組織で利用可能です。ストレージ要件をさらに削減する完全なlogsdb機能（synthetic _sourceを含む）は、サーバーレスのお客様およびエンタープライズライセンスをお持ちの組織で利用可能です。

Elasticsearch logsdb の動作

Logsdbを使用すると、データの収集範囲を狭めたり、データを破棄したりサイロ化したりすることなく、すべてのログデータを保持し、運用効率を向上させることができます。スマートインデックスソート、高度な圧縮、synthetic _sourceなどの機能を活用して、必要なデータを予算内で保持し、分析することができます。

自分で体験してみませんか？Elastic を無料でお試しください。

本記事に記述されているあらゆる機能ないし性能のリリースおよびタイミングは、Elasticの単独裁量に委ねられます。現時点で提供されていないあらゆる機能ないし性能は、すみやかに提供されない可能性、または一切の提供が行われない可能性があります。