Skipped & Deferred Searchを理解する(パート1)

スケジューラとは何をするのか？

• スケジュールされた検索やアラートが設定されている場合、スケジューラはその検索が 実行されるかどうか・いつ実行するか を管理します。
• SHC環境では、スケジューラは SHCキャプテンノード 上で動作し、どのメンバーが検索を実行するかを割り当てます。キャプテンはscheduler.logにスキップや延期が記録された場合、その理由を報告します。
• スケジューラは 同時実行制限(concurrency limits)や割り当て(quota) を適用します。
• スケジューラには、スケジュールされた検索に適用される 優先順位付け・スコアリングルール があります。

なぜスケジュールされた検索がスキップまたは延期されるのか？

• 同時実行制限や割り当てに達している
• 理由はscheduler.logに記録されているため、そこを調査することが必要

Skipped (スキップ)とdeferred (延期)の違い

動作の違いはスケジューリングのモード(リアルタイムか連続)に依存します。

• リアルタイムスケジューリングモード (Real-time scheduling)
  検索は次のステータスを報告します：
  completed (完了)またはskipped (スキップ)
• 連続スケジューリングモード (Continuous scheduling)
  検索は次のステータスを報告します：
  completed (完了)またはdeferred (延期)

挙動

skipped (スキップ)

• スケジューラはscheduled_time (t0)で検索を実行しようとしますが、次のスケジュール(t1)が来るまでに実行できない場合、その時刻の検索は再試行されません。
• スケジューラは、次のスケジュール時刻(t1)が来るまで毎秒実行を試みますが、間に合わなければその検索は欠落します。

deferred (延期)

• スケジューラはscheduled_time (t0)の検索を後の時刻に再実行します。
• 実行可能になるまで毎秒試行し続け、検索を成功させます。

スケジュールモード

1. リアルタイムスケジューリング

• 最新のデータを返すことを保証します。
• スケジュールで指定された時刻に実行されるか、実行されないかのどちらかです。
• 他のリアルタイム検索が同時刻に多数設定されており、同時実行制限を超える場合はスキップされる可能性があります。
• スケジューラは連続スケジューリングよりもリアルタイムスケジューリングを優先します。

savedsearches.conf
realtime_schedule = 1

• この値が1なら、次回の実行時刻は現在時刻から計算されます。
• 一部の実行期間をスキップしても、最新の時間範囲で検索できるようにします。
• デフォルトは1 (サマリーインデックス用検索はデフォルトで0)。

2. 連続スケジューリング

• 必ずすべてのスケジュール実行が遅れてでも実行されます。
• 今実行できない場合は、他のレポートが完了した後に実行されます。

savedsearches.conf
realtime_schedule = 0

• この値が0なら、次の実行時刻は 最後に検索が実行された時間 を基準に計算します。
• 実行期間をスキップすることはありませんが、負荷によっては遅れて実行されることがあります。
• サマリーインデックス検索は連続スケジューリングがデフォルト。

limits.conf
max_continuous_scheduled_search_lookback = <期間>

• Splunk再起動後に、実行されなかった連続モードの検索を何時間分まで遡って再実行するかを指定します。
• デフォルトは24h (0なら遡りなし)。
• 古い時刻は欠落する可能性があるため、必要に応じて手動でサマリーインデックスをバックフィルします。その場合こちらを参照してください。

検索タイプ別のデフォルトスケジューリングモード

検索の優先順位

スケジューラは複数の検索が同時刻に予定されている場合、以下の順序で優先します。

1. 第一優先：アドホックな履歴検索(手動で実行する検索)

ユーザが手動で実行する履歴検索は常に最優先で実行されます。複数のアドホック検索が同時に始まり、定期的なレポートがスケジュールされている場合、一部のレポートは実行枠を譲ってスキップされることがあります。

2. 第二優先：リアルタイムスケジューリングの定期レポートやアラート

手動で設定したレポートやアラートはデフォルトでリアルタイムモードを使用します。

このサーチとレポートカテゴリーでは手動作成のレポートやアラートがスキップされるのを極力避ける為、追加の優先順位決定のルールが適用されます。より詳細な情報については以下のリンクを参照してください。

「How the scheduler prevents skipped report runs」

3. 第三優先：連続スケジューリングの定期レポート

サマリーインデックスを生成する定期レポートなど、データ収集に欠落が許されない検索で使われます。

「Real-time scheduling and continuous scheduling」

4. 最終優先：自動スケジュールされたレポート

レポート加速やデータモデル加速のプロセスで使用され、集計を更新します。

「report acceleration」

「data model acceleration」

スケジューラがスキップを減らす方法

スケジューリングルールにより、スキップされる検索を減らす仕組みがあります。

ルールと説明

1. スケジュールされたレポートに優先度スコアを適用

実行時間の平均に基づいてスコアを算出し、短時間で終わるレポートが優先して実行されます。

短時間の検索はスキップされにくくなりますが、長時間かかる検索はスキップされやすくなります(全検索に適用)。

2. リアルタイムを連続より優先

リアルタイムスケジュールの検索は連続スケジュールより優先度が高く設定されます。

リアルタイム同士でのみ競合し、連続モードの検索より先に実行されます(全検索に適用)。連続スケジュールの実行時も同じモードでのみ競合します。

3. スキップされた検索の優先度を引き上げる

スキップが発生した場合、優先度スコアを改善して、今後実行される可能性を高めます。

特に実行頻度が低い検索は、実行頻度がより高い検索が同じ回数スキップした時よりも大きく優先順位があがります(全検索に適用)。

4. スケジュールウィンドウの設定

検索の開始時刻に柔軟性を持たせるため、サーチが時刻どおりにスタートすることが厳格に必要とされない場合は、ウィンドウ期間を設定します。

設定された期間内では優先順位が一時的に下がり、その時点で順位の高いサーチを先に実行します。設定された期間が終わりに近づくにつれて徐々に優先順位が上がり、サーチが実行されます(デフォルトでは無効、必要に応じて設定)。

同時実行制限の計算方法(limits.conf / Search Head & Search Head Cluster)

単体Search Head (スタンドアロン構成)

最大合計検索数 = (max_searches_per_cpu × CPUの数) + base_max_searches

• max_searches_per_cpu : 1 CPUコアあたりの最大同時実行検索数
• base_max_searches : ベースとなる追加の検索許容量(固定値)

Search Head Cluster (SHC)

クラスタ全体の総同時実行検索数(アドホック + スケジュール検索)

( max_searches_per_cpu × CPUの数 + base_max_searches ) × クラスタメンバー数

クラスタ全体の同時実行「スケジュール検索」数

( ( max_searches_per_cpu × CPU数 + base_max_searches ) × max_searches_perc ) × クラスタメンバー数

クラスタ全体の同時実行「自動サマリ化検索」数

( ( ( max_searches_per_cpu × CPU数 + base_max_searches ) × max_searches_perc ) × auto_summary_perc ) × クラスタメンバー数

数値例

3ノードSHC、各メンバーが8 CPUコアの場合：

1. 総検索数

(1 × 8 + 6) × 3 = 42

2. スケジュール検索数

( (1 × 8 + 6) × 0.5 ) × 3 = 21

3. 自動サマリ化検索数

( ((1 × 8 + 6) × 0.5) × 0.5 ) = 3.5 → 切り捨てて 3、× 3 = 9

CPUの確認例

• SHCキャプテンノードで検出される仮想CPU数によって計算されます。ログ例：

01-31-2019 14:53:21.086 -0500 INFO loader - Detected 8 (virtual) CPUs, 8 CPU cores, and 7822MB RAM

• REST APIでの確認例：

| rest splunk_server=<captain> /services/server/info | table splunk_server numberOfVirtualCores

• 現在の検索同時実行制限の確認例：

| rest splunk_server=<captain> "/services/server/status/limits/search-concurrency?cluster_wide_quota=1" | table max*

同時実行制限に達した場合の具体例

例1

• scheduled_time (例: 00:00)に実行されようとするが、スケジューラの同時実行枠がすでに限界に達している。
  
• スケジューラは毎秒実行を再試行し、空きができ次第その検索を実行する。
• レイテンシ(latency)は予定時刻と実際の開始時刻の差。
• スケジューリングモード：リアルタイム
• タイプ：定期検索(scheduled)

例2

• scheduled_time (00:00)に実行されようとするが、スケジューラの同時実行枠が限界に達している。
• 毎秒再試行するが、次のスケジュール時刻までに実行できず、その時刻の検索は永久にスキップされる。
• スケジューリングモード：リアルタイム
• タイプ：定期検索(scheduled)
  

例3

• scheduled_timeに実行されようとするが、同時実行枠が限界に達しているためスキップされる。
• 次のスケジュール時刻で検索が実行され、その際に過去の範囲までデータを加速(bucket acceleration)することで、以前スキップされた期間も結果に含まれる。
• レポート加速・データモデル加速検索はこの挙動を取るため、スキップに対して耐性があり優先度が低めに設定される。
• スケジューリングモード：リアルタイム
• タイプ：自動集計(auto-summarization)
  

例4

• scheduled_time (00:00)に実行されようとするが、同時実行枠が限界に達している。
• 毎秒再試行し、後の時刻に空きができたら実行される(延期に該当)。
• スケジューラはscheduled_time (00:00)を記録しており、後の時刻に実行された場合にもサマリーインデックスに空白が発生しないように対象時刻を遡って実行される。
• 例：00:10の予定検索が多少遅れて実行されるケース。
• スケジューリングモード：連続
• タイプ：サマリーインデックス
  

挙動のまとめ(review)

• リアルタイムモード + 定期検索(scheduled)

  • 実行開始が遅れる場合はscheduler.logにdelayedが記録されることがある(savedSplunkerコンポーネントがDEBUGモードの場合)。
  • 次の予定時刻まで再試行し、間に合わなければ当該時刻のサーチはスキップされる。

• リアルタイムモード + 自動集計(auto-summarization)

  • スキップされた場合でも次回の実行で過去の範囲を加速します。耐性あり、優先度は低い。

• 連続モード + サマリーインデックス

  • 実行できない場合は延期され、空きができ次第後から実行されます。サマリーインデックスの欠落を防ぐため実行時刻を記録して管理。

パート2では、検索がスキップまたは延期される場合の主な原因やベストプラクティス、トラブルシューティングを解説します。