4
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

Splunkダッシュボード表示速度の改善方法

Last updated at Posted at 2022-05-20

はじめに

Splunkダッシュボード表示において、全てのパネルが表示されるまで遅いと感じた場合の改善方法について、まとめてみたいと思います。

前提

  • Splunk Enterpriseバージョン
    • v8.2.2
  • Splunk Dashboard
    • Classic Splunk Dashboards (Simple XML)

改善方法例

主な改善方法として、以下の対応が考えられます。

  • サーチの作りに関する観点
    • 各パネルで実行するサーチ文の見直し
    • サーチ高速化機能の活用
  • ダッシュボードの作りに関する観点
    • 1ダッシュボードにおけるパネル数の削減
    • パネル間での共通サーチ処理の集約 (Base Search/Post-process Search) ★
    • 実行済サーチ結果の表示 (スケジュールサーチ/loadjobコマンド) ★

本稿では、★を対象として設定方法を説明します。

パネル間での共通サーチ処理の集約

同一ダッシュボード内において、対象データや処理内容の一部が共通したサーチを複数実行している場合、共通するサーチ処理を1処理にまとめることで、サーチ処理におけるリソース消費の低減を狙います。

Base Search/Post-process Search

共通するサーチを"Base Search"、個別のサーチを"Post-process Search"として定義します。

  • Base Search

    • 共通するサーチ内容を定義
    • Post-process Searchに渡すことが可能なイベント数に制限有り (上限500,000件)
    • statsコマンド等、Transformingコマンドの使用を推奨
  • Post-process Search

    • Base Searchのサーチ結果に対して追加で実行するサーチ内容を定義

設定例

以下のダッシュボード/パネルを対象として、設定例を記載します。
※あくまで設定を説明するための例となりますので、サーチ自体に改善すべきポイントも存在します。
[パネルA]

index=_internal source=*splunkd.log
| stats count by component, log_level
| stats sum(count) AS count by log_level

[パネルB]

index=_internal source=*splunkd.log
| stats count by component, log_level
| search log_level=error
| stats sum(count) AS count by component

① 両パネルで共通するサーチ文(Base Search)を抽出

index=_internal source=*splunkd.log
| stats count by component, log_level

② ダッシュボードのソース編集画面を開く
 image.png

③ ダッシュボード共通設定範囲にBase Search定義を追記

<dashboard>
  <label>Test Dashboard</label>
  <search id="baseSearch01">
      <query>
        index=_internal source=*splunkd.log | stats count by component, log_level
      </query>
  </search>
…(略)

④ 各パネル設定範囲にPost-process Search定義を追記
[パネルA]

…(略)
  <chart>
       <title>Event count by log level</title>
       <search base="baseSearch01">
           <query>
             stats sum(count) AS count by log_level
           </query>
       </search>
  </chart>
…(略)

[パネルB]

…(略)
  <chart>
       <title>Error event count by component</title>
       <search base="baseSearch01">
           <query>
             search log_level=error | stats sum(count) AS count by component
           </query>
       </search>
  </chart>
…(略)

⑤ ダッシュボード設定を保存

⑥ ダッシュボード表示して結果を確認
 image.png

実行済サーチ結果の表示

ダッシュボード表示時にサーチを実行するのではなく、サーチ自体を予め決められたタイミングで事前実行させておきます。そのサーチ結果をダッシュボード表示時に参照することにより、ダッシュボード表示時におけるサーチ所要時間の短縮を狙います。
仕組みの性質上、本対応は、直近のデータを対象としたサーチには不向きとなります。

スケジュールサーチによる実行/loadjobコマンドによる結果参照

対象のサーチをスケジュールサーチ(レポート)として定義します。
Splunkの仕組みとして、スケジュールサーチの実行結果は、Splunk上に一定期間保存されます。スケジュールサーチの場合、デフォルト設定における保存期間は、スケジュールサーチ実行間隔の2倍(実行間隔が1日であれば2日間保存)となります。
ダッシュボード上では、loadjobコマンドを利用し、スケジュールサーチの実行結果を参照するサーチ文を定義します。

スケジュールサーチの実行結果はSplunk上に保存されるため、その分ディスクを消費します。念のため、ディスクの空き容量を考慮した上で、設定をお願いします。

設定例

① レポートの作成
 image.png
② 作成したレポートに対してスケジュール設定を追加
 image.png
③ ジョブ一覧にて実行結果が表示されることを確認 (スケジュール設定によるサーチ実行後)
 image.png
④ ダッシュボード-パネル設定にて当該スケジュールサーチの結果を参照するクエリを指定 (loadjobコマンド)
 image.png

同じレポートに対して複数のサーチ結果が保存されている場合は、最新のサーチ結果のみが参照されます。

⑤ ダッシュボード上でサーチ結果が表示されることを確認
 image.png

参考

4
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?