高速化したデータモデルとサマリーインデックスによるサーチ時間の短縮

Splunkの小人たち

Splunkのレポートやダッシュボードの表示を何分も待っていたりしませんか？

そのような運用をしている場合は、高速化したデータモデルやサマリーインデックスの活用を検討してください。

高速化したデータモデルやサマリーインデックスは、グリム童話の「小人の靴屋」の小人たちのような存在であり、本来あなたがやらなければいけない仕事をあなたのいない間にやっておいてくれます。

具体的には、高速化したデータモデルの場合はあなたのいない間に生データから使いそうな部分を抽出してリストにしておいてくれますし、サマリーインデックスの場合はあなたのいない間に前処理としてデータの抽出や集計をしておいてくれるので、あなたがレポートやダッシュボードを表示する時にはいちいちすべての生データを読み込んで集計しないでも結果を表示できます。

ただし、グリム童話の小人と違って、高速化したデータモデルやサマリーインデックスは、事前にそれらの設定をしておかないといけなかったり、働いていてくれている間にCPUやメモリを消費したり、やってくれた結果を保存しておくためにディスクを消費したりします。

1人目の小人：高速化したデータモデル

1人目の小人である高速化したデータモデルについて説明する前に、まずは(高速化していない)データモデルについて説明します。

データモデルは、SPLを使用しないでも特定のデータを集計して表やグラフとして表示できるようにする仕組みです。ユーザーはSplunkに取り込まれた特定のデータを、Web画面上でExcelのピボットテーブルのように操作して表やグラフを作成し、それらをレポートやダッシュボードパネルとして保存することができます。

データモデルは複数のデータセットからなり、データセットはExcelのテーブルのように特定の列(フィールド)を持った行(イベント)の集まりです。ユーザーは(あらかじめナレッジマネージャが作成した)データセットを使用してピボットテーブルを作成することができます。

ナレッジマネージャによるデータセットの作成の仕方には下記の3種類があります。

• イベント データセット
• サーチ データセット
• トランザクション データセット

このうちサーチ データセットとトランザクション データセットはレポートやダッシュボードの高速化に使用できないため、このブログではイベント データセットについてのみ説明します。

イベント データセットは制約(検索条件)とフィールド定義を持ちます。制約で指定した検索条件に適合するイベントのうち、フィールド定義で指定したフィールドを対象としてピボットテーブルを作成することができます。

また、既存のイベント データセットをもとに子データセットを作成することができます。子データセットは親データセットの制約やフィールド定義を継承し追加の制約を持つため、親データセットのサブセットとなります。孫データセットや曾孫データセットを作成することもできます。

ここではSplunk Enterprise Securityでも使用しているCIM(Common Information Model)のAuthenticationデータモデルを例にピボットテーブルの作成方法を説明します。

AuthenticationデータモデルにはAuthenticationデータセット(データモデルと同名)を最上位のデータセットとしていくつかのデータセットが定義され、それぞれ検索条件に合致した認証ログが含まれています。

Authenticationデータセットを指定してピボットテーブルを作成し、図のように指定する事で日次の認証結果を簡単に表示することができます。

また、この表を簡単にグラフ化することもできます。

ここまでデータモデルについて説明してきましたが、データモデルは設定画面で高速化のチェックボックスをチェックするだけでピボットテーブルの検索時間を短縮することができます。

その理由は、データモデルを高速化しない場合は圧縮された生データを解凍してフィールドの抽出を行ってからでないとデータの集計ができませんが、データモデルを高速化した場合はデータセットで定義したフィールドの内容をサマリーとして圧縮された生データとは別のリストに保存する処理がバックグラウンドで動くため、ピボットテーブルの表示時にはそのリストを読み込むだけで集計を開始できるからです。

また、データモデルはピボットテーブルの作成に使用するだけでなく、tstatsコマンドを使用する事で通常の検索におけるstatsコマンドのように集計を行うこともできます。

例えば、下記のSPLではbotsv3インデックスの認証ログから日次の認証結果を表示できますが、

tstatsコマンドを使用すると、これと同様の結果を下記のSPLで表示できます。

また、Authenticationデータモデルを高速化し、下記のようにtstatsコマンドにsummariesonly=trueオプションを指定することで検索時間を短縮できます。

ただし、summariesonly=trueオプションを指定すると、最近取り込まれてまだサマリーに記録されていないデータは集計対象とならないため、高速化したデータモデルを使用しない場合に比べて検索結果のリアルタイム性が失われるというデメリットが生じます。

上記3つのSPLの実行時間ですが、通常のSPLが9.056秒、高速化しないtstatsが8.111秒かかりましたが、高速化したtstatsは0.582秒で表示できました。通常のSPLでフェッチしたイベント件数は2,386件なのでデータ件数が増えるとこの差がどんどん広がっていくのが想像いただけると思います。

これが1人目の小人がしてくれる仕事です。

高速化したデータモデルについては、英語ですがこちらに情報があります。

また、日本語字幕付きの無料eLearningコースがあります。

2人目の小人：サマリーインデックス

2人目の小人であるサマリーインデックスは、名前にインデックスという文字列が含まれているため特別なインデックスと思われがちですが、SPLによる検索結果をイベントとして保存しておくための仕組みであり、一度作成してしまえば後は通常のイベントと同じものです。

このようなイベントを格納するためのインデックスとして、デフォルトでsummaryという名前のインデックスが用意されていますが、この他のインデックスに保存することも可能です。

また、サマリーインデックスの特徴として、イベントのsourcetypeに自動的にstash(日本語でヘソクリの意)という値が設定される点と、取り込みライセンスの容量としてカウントされないという点が挙げられます。

サマリーインデックスによる検索の高速化は、まず検索を2段階に分割し、前段の処理の結果をサマリーインデックス(イベント)として保存しておき、そのサマリーインデックス(イベント)を対象として後段の処理を実行してレポートやダッシュボードを表示し、実際にユーザーが体感する検索時間(後段の検索時間のみ)を短縮することで実現します。

例えば、botsv3インデックスのpsコマンドの実行ログから、各プロセス(同名のプロセスが同一ホスト内で複数同時に実行している場合はその合計)のCPU使用率の各日の最大値が20%を超えるものを抽出するSPLは下記のようになります。

このSPLを2段階に分割すると、サマリーインデックスを作成するSPL (事前にps_summaryインデックスを作成する必要あり)とサマリーインデックスを検索して表示するSPLになります。

サマリーインデックスを作成するSPL (事前にps_summaryインデックスを作成する必要あり)

サマリーインデックスを検索して表示するSPL

ここでは全体のイメージを掴んでいただくためにcollectコマンドを使用してサマリーインデックスを一括で作成しましたが、実際にはこの例では前日分のpsコマンドの実行ログを集計するスケジュールサーチを日次で実行してサマリーインデックスの作成を行います。

サマリーインデックスを作成する周期は要件や設計によって変わりますが、いずれにしてもサマリーインデックスを使用しない場合に比べてリアルタイム性が失われるというデメリットが生じます。

SPLの実行時間ですが、分割前のSPLは8.575秒かかりましたが、分割後の後段の表示に使用するSPLは1.627秒で表示できました。分割前のSPLでフェッチしたイベント件数は2,073件なのでデータ件数が増えるとこの差がどんどん広がっていくのが想像いただけると思います。

これが2人目の小人がしてくれる仕事です。

サマリーインデックスについては、英語ですが下記に情報があります。

• Using summary indexing to accelerate searches
• Use summary indexing for increased search efficiency

小人たちの役割分担

1人目の小人である高速化したデータモデルと2人目の小人であるサマリーインデックスを比較したのが下記の表です。

上記を参考に高速化したデータモデルとサマリーインデックスを使い分けてください。

まとめ

Splunkの小人たちにうまく仕事をしてもらうことで、レポートやダッシュボードの表示にかかる時間を短縮し、運用ユーザーの生産性を向上しましょう。これにより問題の発見や解決に掛かる時間を短縮でき、レジリエンスを向上することも可能です。

なお、例で使用したbotsv3インデックスは下記からダウンロードできますので、実際に動作を試していただくことができます(リンク先の指示に従って指定のAdd-onもインストールしてください)。

GitHub - splunk/botsv3: Splunk Boss of the SOC version 3 dataset