Zenn
📑

Splunk Dashboard 検索負荷をかける前に

2021/07/11に公開
Splunk
#
foolproof
#
計算負荷
#
stack防止
tech

前提の話

ダッシュボードを運用者目線であれこれ作り込んでいくと、処理がどんどん複雑になります。
１時間のデータを意図通りに詳細表示するダッシュボードを作っていて、ふと「先月のデータ出してよ」と言われて１ヶ月のデータを入れると、、、ジョブスタック。
結構心当たりのある方も少なくないんじゃないかなと思います。
そういうケースをふせぐTIPs。

ブレーキングダッシュボード

これなんか正しい名称あるのかな。。
まぁ趣旨としては、ダッシュボード本体で複雑な処理をしてスタックする前に、分析対象になるデータ数を軽量なSPLで確認して、データ数が多いなら一旦時間範囲を指定し直させたりして踏みとどまらせるダッシュボードを間にはさみましょう、という話です。

具体的には？

以下みたいな実装をします。
ポイントとしては、想定処理データ数が想定値以内なら、本来のダッシュボードにそのままリンク。
NGなら、時間とか条件とかを再指定させてるために一回Stopさせる。

"done"エレメントの使い方の話ですね。

<form>
  <label>brake</label>
  <fieldset submitButton="false">
    <input type="time" token="field1">
      <label></label>
      <default>
        <earliest>-24h@h</earliest>
        <latest>now</latest>
      </default>
    </input>
  </fieldset>
  <row>
    <panel>
      <single>
        <search>
          <query>
| from datamodel:"internal_audit_logs.Audit"
| stats count
          </query>
          <earliest>$field1.earliest$</earliest>
          <latest>$field1.latest$</latest>
          <done>
            <condition match="$result.count$ &lt; 1">
              <set token="comment">No Log</set>
            </condition>
            <condition match="$result.count$ &gt; 100">
              <set token="comment">Too Many</set>
            </condition>
            <condition>
              <set token="comment">OK</set>
              <link>/app/search/dashboard01?form.field1.earliest=$field1.earliest$&amp;form.field1.latest=$field1.latest$</link>
            </condition>
          </done>
        </search>
        <option name="drilldown">none</option>
        <option name="refresh.display">progressbar</option>
      </single>
    </panel>
  </row>
  <row>
    <panel>
      <html>
      <h1>$comment$</h1>
      <a href="">Force Execute</a>
    </html>
    </panel>
  </row>
</form>

ちなみにリンク元（Drilldown元）はこんな。

<form>
  <label>dashboard01</label>
  <fieldset submitButton="false">
    <input type="time" token="field1">
      <label></label>
      <default>
        <earliest>-24h@h</earliest>
        <latest>now</latest>
      </default>
    </input>
  </fieldset>
  <row>
    <panel>
      <table>
        <search>
          <query>| from datamodel:"internal_audit_logs.Audit" 
| table _time host, action, info, sorce, user</query>
          <earliest>$field1.earliest$</earliest>
          <latest>$field1.latest$</latest>
        </search>
        <option name="drilldown">cell</option>
        <option name="refresh.display">progressbar</option>
        <drilldown>
          <link target="_blank">/app/search/brake?form.field1.earliest=$field1.earliest$&amp;form.field1.latest=$field1.latest$</link>
        </drilldown>
      </table>
    </panel>
  </row>
</form>

この例だと、”| from datamodel:"internal_audit_logs.Audit"の部分が軽い（はずの）処理で、これで本当に使おうとしているダッシュボードで処理するログの総量を先に計算します。
この値が大きい時（実際に試してみた感じで負荷に耐えられる数とか、サブサーチ限界の10.000を超える時）は、このダッシュボードで一回Stopして、時間を再選択させます。
総定数以下のときは、doneの処理でlinkを実行して、そのまま本来使おうとしているドリルダウン先に飛びます。この際、所定のトークンをそのまま引き渡すのを忘れずに。

まとめ

非常にシンプルなのですが、これものすごく重要です。
Splunkは一回ジョブをスタックさせてしまうと、ジョブ管理画面自体が重くなってしまってまっとうにジョブ停止がかけらんなくなります。
うっかり常時監視やってるときにやらかすと、、自分のアカウントで監視できなくなるという致命的な自体を引き起こすんですよね。。
こういう事故防止はSplunkネイティブの機能でうまいの作ってくんないかなーと思いつつ。
（すでにあったらお恥ずかしい。）

Discussion