https://www.splunk.com
  • Splunkサイト
    • Splunk Answers
    • ブログ
    • Community
    • .conf
    • Developers
    • Documentation
    • Splunk.com
    • Splunkbase
    • サポート
    • トレーニング
    • User Groups
    • ビデオ
https://www.splunk.com
  • ブログ
  • カテゴリー
    カテゴリー
    • .conf & .conf Go
    • お客様 & コミュニティ
    • DevOps
    • 業種・業界
    • IT
    • 経営陣
    • Learn
    • パートナー
    • データプラットフォーム
    • セキュリティ
    • Splunk for Good
    • Splunk Life
    • Tips
    Category Spot Image
    電子書籍
    外形監視のベストプラクティス Synthetic Monitoringの紹介

    Webサイトのパフォーマンスが広告収入、ユーザーエンゲージメント、SEOランキングに与える影響、外形監視を使ったソリューションを紹介

    詳細はこちら
  • ライター
    ライター
    • Splunk
    • Guest
    • Huaibo Zhao
    • 臼杵 真矢
    • 江藤 愛
    • 大谷 和紀
    • 大森 明央
    • 岡 大
    • 甲斐 逸郎
    • 加藤 教克
    • 肥垣津 雄日
    • 近藤 洋平
    • 塚本 政彦
    • 長島 広隆
    • 仲間 力
    • 野村 健
    • 福澤 公之
    • 藤盛 秀憲
    • 松本 志恆
    • 村田 達宣
    • 矢崎 誠二
    • 山内 一洋
    • 山村 悟史
    • 横田 聡
    • Gary Steele
    • Spiros Xanthos
    • Garth Fort
    • Simon Davies
    • Ryan Kovar
    • Jane Wong
    • ライター一覧
    Author Spot Image
    電子書籍
    SIEM導入ガイド

    適切なSIEMソリューションがどのように役立つかを解説した最新版

    電子書籍を読む
  • メール配信
  • 無料トライアル
https://www.splunk.com 無料トライアル
ブログ
カテゴリー
  • .conf & .conf Go
  • お客様 & コミュニティ
  • DevOps
  • 業種・業界
  • IT
  • 経営陣
  • Learn
  • パートナー
  • データプラットフォーム
  • セキュリティ
  • Splunk for Good
  • Splunk Life
  • Tips
ライター
  • Splunk
  • Guest
  • Huaibo Zhao
  • 臼杵 真矢
  • 江藤 愛
  • 大谷 和紀
  • 大森 明央
  • 岡 大
  • 甲斐 逸郎
  • 加藤 教克
  • 肥垣津 雄日
  • 近藤 洋平
  • 塚本 政彦
  • 長島 広隆
  • 仲間 力
  • 野村 健
  • 福澤 公之
  • 藤盛 秀憲
  • 松本 志恆
  • 村田 達宣
  • 矢崎 誠二
  • 山内 一洋
  • 山村 悟史
  • 横田 聡
  • Gary Steele
  • Spiros Xanthos
  • Garth Fort
  • Simon Davies
  • Ryan Kovar
  • Jane Wong
  • ライター一覧
メール配信
Splunkサイト
  • Splunk Answers
  • ブログ
  • Community
  • .conf
  • Developers
  • Documentation
  • Splunk.com
  • Splunkbase
  • サポート
  • トレーニング
  • User Groups
  • ビデオ
PLATFORM

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

Share:

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インデックスの認証ログから日次の認証結果を表示できますが、

SPL 説明 実行時間
index=botsv3 tag=authentication botsv3インデックスから認証ログを検索 9.056秒
i fillnull value="unknown" action 認証結果がNULLの場合は”unknown”を代入
timechart span=1d count by action 各認証結果の数を日次で集計

サーチ結果

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

SPL 説明 実行時間
| tstats count from datamodel=Authentication.Authentication where index=botsv3 by _time span=1d Authentication.action AuthenticationデータモデルのAuthenticationデータセットのデータのうちbotsv3インデックスにあるものを対象に各認証結果の数を日次で集計 8.111秒
| xyseries _time Authentication.action count 表をピボットして縦軸に日付を横軸に認証結果の数を表示

tstatsコマンドを使用したサーチ結果

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

SPL 説明 実行時間
| tstats summariesonly=true count from datamodel=Authentication.Authentication where index=botsv3 by _time span=1d Authentication.action AuthenticationデータモデルのAuthenticationデータセットのデータのうちbotsv3インデックスのサマリーにあるものを対象に各認証結果の数を日次で集計 0.582秒
| xyseries _time Authentication.action count 表をピボットして縦軸に日付を横軸に認証結果の数を表示

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 説明 実行時間
index=botsv3 sourcetype=ps botsv3インデックスからpsコマンドの実行ログを検索 8.575秒
| stats sum(pctCPU) as pctCPU by _time host process_name 時刻/ホスト名/プロセス名毎にCPU使用率の合計値を集計
| bin span=1d _time 時刻を日付毎に集約
| stats max(pctCPU) as pctCPU by _time host process_name 日付/ホスト名/プロセス名毎にCPU使用率の最大値を集計
| eval time=strftime(_time, "%Y-%m-%d"), host_name=host 日付を文字列に変換
ホスト名のフィールド名を変更
| table time host_name process_name pctCPU 日付/ホスト名/プロセス名/CPU使用率をテーブルとして出力
| where pctCPU > 20 CPU使用率が20%を超えるものを抽出

サーチ結果

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

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

SPL 説明 実行時間
index=botsv3 sourcetype=ps botsv3インデックスからpsコマンドの実行ログを検索 11.877秒
(バックグラウンドで実行されるため表示待ち無し)
| stats sum(pctCPU) as pctCPU by _time host process_name 時刻/ホスト名/プロセス名毎にCPU使用率の合計値を集計
| bin span=1d _time 時刻を日付毎に集約
| stats max(pctCPU) as pctCPU by _time host process_name 日付/ホスト名/プロセス名毎にCPU使用率の最大値を集計
| eval time=strftime(_time, "%Y-%m-%d"), host_name=host 日付を文字列に変換
ホスト名のフィールド名を変更
| table time host_name process_name pctCPU 日付/ホスト名/プロセス名/CPU使用率をテーブルとして出力
| collect index=ps_summary 結果をps_summaryインデックスにサマリーインデックスとして保存

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

SPL 説明 実行時間
index=ps_summary ps_summaryインデックスからサマリーインデックスを検索 1.627秒
| table time host_name process_name pctCPU 日付/ホスト名/プロセス名/CPU使用率をテーブルとして出力
| where pctCPU > 20 CPU使用率が20%を超えるものを抽出

サマリーインデックスを使用したサーチ結果

ここでは全体のイメージを掴んでいただくために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人目の小人であるサマリーインデックスを比較したのが下記の表です。

  高速化したデータモデル サマリーインデックス
特徴

元のイベントも保持しておく必要があるため、比較的短期間の大量のイベントを集計するのが得意。

どのように集計するかはレポート毎に変える事ができるため柔軟性が高い。

元のイベントとは独立した保持期間を設定できるため、長期間のイベントを集計するのが得意。

集計単位(日次であれば1日)あたりのデータ件数が多ければ多いほど高速化の効率が良い。

SPL修正の必要性 tstatsを使用して修正する必要がある。 サマリーインデックスを作成するSPLと利用するSPLに分割する必要がある。
管理

Web UIで有効にすると、初期構成が行われ、以後5分毎に新しいイベントについてサマリーが自動的に更新される。

必要に応じてサマリーを再構成することができる。

サマリーインデックスを作成するSPLをスケジュールサーチとして登録してサマリーインデックスを作成する必要がある。

スケジュールがスキップされた場合のデータ抜けや、何らかの理由によるデータ重複は、手作業で対応する必要がある。

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

まとめ

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

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

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

 

August 10, 2023
福澤 公之
Posted by

福澤 公之

2022年Splunk Services Japan合同会社入社。パートナー担当のセールスエンジニアとして活動中。

Related Posts

SPLUNK ON TWITTER
  • @Splunk
  • @splunkanswers
  • @SplunkforGood
  • @SplunkDocs
  • @splunkdev
  • @splunkgov
SPLUNK ON FACEBOOK
  • @Facebook
SPLUNK ON INSTAGRAM
  • Follow us on Instagram
SPLUNK ON LINKEDIN
  • Follow us on LinkedIn
SPLUNK ON YOUTUBE
  • Subscribe to our Channel
SPLUNK ON SLIDESHARE
  • Follow us on SlideShare
Splunk製品
  • Splunk Cloud Platform
  • Splunk Enterprise
  • Splunk IT Service Intelligence
  • Splunk On-Call
  • Splunk Enterprise Security
  • Splunk SOAR
  • Splunk Infrastructure Monitoring
  • Splunk APM
ソリューション
  • オブザーバビリティ
  • セキュリティ
  • プラットフォーム
お客様事例
リソース
  • E-book
  • アナリストレポート
  • ホワイトペーパー
  • ウェビナー
  • ビデオ
お問い合わせ
  • サポート
  • 営業へのお問い合わせ
Splunk Sites
  • Splunk Answers
  • 日本語ブログ
  • Community
  • .conf
  • Developers
  • Documentation
  • Splunkbase
  • SplunkLive!
  • T-shirt Store
  • トレーニング
  • User Groups
Splunk
Sitemap | Privacy
© 2005-2023 Splunk Inc. All rights reserved.
Splunk、Splunk>およびTurn Data Into Doingは、米国およびその他の国におけるSplunk Inc.の商標または登録商標です。他のすべてのブランド名、製品名、または商標は、それぞれの所有者に帰属します。