サーチのスキップを回避するためのヒント

サーチのスキップは多くのSplunk管理者にとって悩みの種です。サーチがスキップされるのは、通常、システムの負荷が利用可能なリソースを上回ることが原因です。この場合、システムのリソースを増強するか、負荷を軽減する必要があります。または、Splunkを適切に設定することで頻繁に発生するサーチのスキップを回避できる場合もあります。このブログでは、Splunkサーチの同時実行モデルについておさらいしてから、サーチがスキップされるさまざまな原因を特定するための体系的な方法とスキップの回避策をご紹介します。

サーチの同時実行

まずは、Splunkサーチの同時実行モデルを確認しておきましょう。主にヒストリカルサーチを対象に説明しますが、一部はリアルタイムサーチにも適用されます。

Splunkでは、システムでのサーチの同時実行数が制限されます。この制限数を「サーチスロット」と呼びましょう。スロットの目的は、サーチの負荷が利用可能なリソースを大幅に上回ってシステムのパフォーマンスが急激に悪化し、機能停止に陥るのを防ぐことです。デフォルトでは、システムの合計最大同時実行数(最大サーチスロット)は、サーチヘッド(SH)単体またはサーチヘッドクラスター(SHC)全体のCPUコア数に基づいて算出されます。

サーチスロットは、スケジュールサーチとアドホックサーチの間で共有されます。スケジュールサーチで使用できるサーチスロット数にはデフォルトで制限がありますが、アドホックサーチにはありません。つまり、アドホックサーチでは最大サーチスロットをすべて使用でき、その場合、スケジュールサーチではスロットを使用できないことになります。サーチヘッドが1つの場合のスロットの算出方法を以下に示します。サーチヘッドクラスターでも、この式に基づいて簡単に算出できます。 

合計最大同時実行数 = <max_searches_per_cpu> x SH/SHCのCPUコア数 + <base_max_searches>

スケジュールサーチの最大同時実行数 = <max_searches_perc> x 合計最大同時実行数

自動サマリー作成サーチの最大実行数 = <auto_summary_perc> x スケジュールサーチの最大同時実行数

デフォルト値：

max_searches_per_cpu=1

base_max_searches=6

auto_summary_perc=50%

max_searches_perc=50%

とはいえ、Splunk Cloud Platformには、アドホックサーチですべてのサーチスロットを使い切らないように制限できる新機能があります。

サーチのスキップ

サーチがスキップされる原因はさまざまあり、その原因を理解することは非常に重要です。次のサーチを実行すれば原因が見つかるかもしれません。

index=_internal sourcetype=scheduler savedsearch_name=* status=skipped | stats count by reason

サーチがスキップされる主な原因

1. ユーザーまたはロールのクォータ制限に達した

ユーザーまたはロールのクォータを設定している場合は、クォータ制限に達すると一部のサーチがスキップされることがあります。そもそもクォータの目的は、特定のユーザーまたは特定のロール内のすべてのユーザーが同時に実行できるサーチ数を制限することです。そのため、この場合の解決策は、該当するユーザーまたはロールのクォータを変更することです。また、スケジュールされたジョブを実行する権限がないユーザーがスケジュールサーチを実行してスキップされる場合もあります。その場合の解決策については、こちらを参考にしてください。

2. ヒストリカルスケジュールサーチの同時実行ジョブ数が最大に達した

スケジュールサーチは5分ごとなど一定の間隔で実行され、各スケジュールサーチで一度に実行できるインスタンスはデフォルトでは1つのみです。この設定はsavedsearches.confファイルの<max_concurrent>で定義され、通常はデフォルトの1よりも増やす必要はありません。何らかの理由でスケジュールサーチのジョブが次回のジョブの開始時刻よりも前に完了しなかった場合、ジョブがスキップされます。たとえば、5分間隔で実行されるサーチでジョブの完了に10分かかった場合、スキップが発生します。この問題を解決するには、まず、この原因でスキップが発生しているスケジュールサーチを特定してから、以下のいずれかの措置をとります。

• スケジュールの実行間隔をサーチの実行時間よりも長くする
• 次のいずれかの方法でサーチの実行時間を短くする
  • インデクサーへの負荷を確認し、リソースがひっ迫している場合は増強する(下図参照) 
  • リソースがひっ迫している場合の別の対策として、Workload Managementで、該当するサーチの優先度を上げて割り当てるリソースを増やし、実行が早く終わるようにする

たとえば、次のサーチを実行するかモニターコンソールを見て、インデクサーのCPU使用率を確認します。出力が下の図のようになったら、リソース不足でサーチの実行に時間がかかっているため、インデクサーのリソースを増やします。 

index=_introspection host=idx* component=Hostwide | eval total_cpu_usage = 'data.cpu_system_pct' + 'data.cpu_user_pct' | timechart span=10m perc95(total_cpu_usage) by host

^{インデクサーのCPU使用率が高いことを示す図}

3. 自動サマリー作成サーチの同時実行数が最大に達した

前述のとおり、サマリー作成サーチの同時実行数には制限があり、その数はlimits.confファイルの<auto_summary_perc>で定義されます。この設定を75%に上げることで、スケジュールサーチ全体の制限の中で自動サマリー作成サーチが占める割合を増やして、サーチがスキップされるのを防ぐことができます。

また、スキップされるサーチの開始時刻が、0分や30分など、常に決まっている場合は、同じ時刻に開始されるスケジュールサーチが多すぎる可能性もあります。その場合は解決策として、<allow_skew>または<schedule_window>を設定して、スケジューラーでサーチの実行時刻を最適化できるようにします。この2つの設定については、Paul Lucasによるブログ「Schedule Windows vs. Skewing (スケジュールウィンドウとスケジュールスキューのどちらを使うべきか)」が参考になります。 

4. インスタンスまたはクラスターでのヒストリカルスケジュールサーチの同時実行数が最大に達した

これは、サーチがスキップされる最も一般的な原因です。この場合、利用可能なすべてのサーチスロットが使われ、新しいサーチをスケジュールできないことでスキップが発生します。

4a. 同じ時刻に開始されるスケジュールサーチが多すぎる 

サーチのスケジュールが特定の時刻(午後1:00、午後1:15、午後1:30など)に集中していないかどうかを確認します。集中している場合は、前述のように、こちらのブログを参考に<allow_skew>または<schedule_window>を設定します。

4b. アドホックサーチがサーチスロットを占領している

前述のとおり、アドホックサーチではデフォルトで、利用可能なすべてのサーチスロットを使用できるため、スケジュールサーチで使用できるスロットがなくなる場合があります。この問題が起きているかどうかを確認するには、次のサーチを実行してスキップに特定のパターンがあるかどうかをチェックします。その後、よくスキップされるサーチの開始時刻にアドホックサーチが多数実行されていないかどうかを確認します。アドホックサーチが原因の場合は、アドミッションルールの新機能を使って、合計最大同時実行数の中でアドホックサーチが占める割合を制限します。 
 

index=_internal sourcetype=scheduler savedsearch_name=* status=skipped | bin _time=1h | stats count by _time

4c. インデクサーリソースの使用率(P95)が80%を超えている

サーチの大部分はインデクサー上で実行されます。サーチ数が多すぎるかサーチを適切に作成できていない(それによりキャッシュが大量に消費される)、またはデータ取り込みの負荷が高い場合、インデクサーがボトルネックになってサーチに時間がかかることがあります。これにより、サーチスロットが長時間占有され、新しいサーチを実行できなくなってスキップが発生します。この問題が起きているかどうかを確認するには、上記のサーチを実行してスキップに特定のパターンがあるかどうかをチェックします。その後、よくスキップされるサーチの実行中にインデクサーのCPU使用率が過度に上がっていないかどうかを確認します。インデクサーがボトルネックになっている場合は、インデクサー層のキャパシティを増やします。

^{スキップされたサーチ数とインデクサーの負荷の相関関係を示す図}

4d. 合計最大同時実行数の制限が低すぎる

ワークロード環境によっては、デフォルトの最大同時実行数の制限が低すぎることがあります。特にITSI Appなど短いサーチが多い場合は、<max_searches_per_cpu>を2～5の範囲で段階的に上げてデフォルトの制限を緩和するのも一つの手段です。この設定を変更する前に、インデクサーとサーチヘッドのCPU使用率が十分に低いこと(P95で50～60%以下)を確認してください。

4e. スケジュールサーチの最大同時実行数の制限が低すぎる

スケジュールサーチの同時実行数はデフォルトで、合計最大同時実行数の50%に制限されます。同時に実行するアドホックサーチがそれほど多くない場合は、<max_searches_perc>を75%以上に上げてもよいでしょう。この場合、後からアドホックサーチが増えてスケジュールサーチを圧迫するようになったときは、前述のように新機能を使ってアドホックサーチを制限する必要があります。

最後に、サーチのスキップを減らすために重要なのは、システムのボトルネックを見つけることです。ボトルネックには、ソフトウェアの設定関連といったソフト的なものもあれば、システムリソースの制限などのハード的なものもあります。いずれにしても、その特定がサーチのスキップ問題を効率的に解決するための鍵です。ボトルネックがわかったら、Splunkシステムでのサーチのスキップ状況を分析し、上記の回避策のいずれかでスキップ率を低減できるかどうかを確認しましょう。

このブログはこちらの英語ブログの翻訳、山村 悟史によるレビューです。