SPLのコマンドタイプを学ぶ～効率的なサーチの実行順序とその調査方法～

Splunkでは、サーチを実行する際に独自言語であるSPL(Search Processing Language)を使用します。

SPLのコマンドは、処理の内容によっていくつかのタイプに分類することができます。特に複数のサーバーでSplunkシステムを構成している分散環境では、SPLのタイプによって、どのコンポーネントで重い処理が実行されるかを理解しておかないと、非効率的なサーチを作成してしまう恐れもあります。

今回は、SPLのタイプについてそれぞれ解説し、効率的なサーチの実行順序とその調査ツールであるSearch Job Inspectorの使い方をお伝えします。

StreamingコマンドとNon-Streamingコマンド

SPLのタイプは、大きく分けるとStreamingコマンドとNon-Streamingコマンドの二つに分けられます。そしてその中から更に六つのタイプに分類できます。以下の通りです。

• Streaming
  • Distributable Streaming
  • Centralized Streaming
• Non-Streaming
  • Transforming
  • Generating
  • Orchestrating
  • Dataset processing
    

まず、Streamingコマンドと、Non-Streamingコマンドの違いについて解説します。

1-1. Streamingコマンド

Streamingコマンドは、個別のイベントごとにデータへの処理を行うコマンドです。例えば、evalコマンドやheadコマンドはStreamingコマンドです。

これらのコマンドは、基本的には、一つのデータ(イベント)を入力すると、それに対して一つのデータ(イベント)を出力するコマンドであると表現できます。もし順序性を考慮する必要がなければ、全てのイベントが揃うまで待たず、一つ一つのイベントに対して処理を行うことができます。これがStreamingコマンドの重要な特徴です。

これらStreamingコマンドは更に、イベント順序性を考慮する必要がないDistributable Streamingコマンドと、データの順序性を考慮する必要があるCentralized Streamingコマンドに分けることができます。

最も重要なタイプがDistributable Streamingコマンドです。このタイプに分類されるコマンドは、Indexer側で分散処理ができるという点で、効率的なサーチを実行できるコマンドになります。後でより詳しく説明します。

1-2. Non-Streamingコマンド

これに対して、Non-Streamingコマンドは、その名の通りStreamingコマンド以外のコマンドです。Streamingコマンドと区別するためにこのような呼び方をしています。

より詳細については、Transforming、Generating、Orchestrating、Dataset processingコマンドのそれぞれの説明を読んでください。

詳細なコマンドタイプの説明

次に、より詳細に各コマンドタイプについて説明します。

2-1. Distributable Streamingコマンド

Streamingコマンドのうち、イベント順序性を考慮する必要がないコマンドを、Distributable Streamingコマンドと呼びます。eval、rex、renameなどが例です。このコマンドは、サーチ実行時、複数のIndexerから取り出した一件一件のイベントに対して、個別にすぐ処理を行うことができます。

このため、分散構成で多数のIndexerから構成されている環境の場合、各Indexerで並列処理を行った後、その結果をSearch Headで集約してユーザーに表示する、といった流れでサーチが実行されます。(必ずしもIndexerで処理しなければならないわけではありません。すでにサーチ結果がSearch Headで集約された後の場合は、Distributable StreamingコマンドもSearch Headで処理することになります)

Indexerで処理を分散処理できるのが、Distributable Streamingコマンドの特徴であり最大のメリットです。Distributable Streamingコマンドの一覧は以下にあります。SPLを書く際にこれらコマンドを使う場合は、できる限りSPLの先頭に配置し、Indexerが分散処理できるようにしてみてください。

• Streaming commands(「Notes」列がDistributable streamingであるコマンドを参照してください)

2-2. Centralized Streamingコマンド

Streamingコマンドのうち、イベント順序性を考慮する必要があるコマンドを、Centralized Streamingコマンドと呼びます。head、transactionなどが例です。

このコマンドは、Distributable Streamingコマンドとは異なり、順序性が重要となるため、一度Search Headにイベントを集約してから処理を行う必要があります。Search Headが処理を行う必要があるため、分散環境であってもDistributable Streamingコマンドのように並列処理はできません。

2-3. Transformingコマンド

入力データを変換して、新しいデータセットを生成するコマンドをTransformingコマンドと呼びます。stats、chart、tableなどが例です。これらコマンドを使用すると、イベントはデータ構造が変換され、データテーブル形式に変化します。データテーブル形式のデータ化は、可視化に便利です。

これらのコマンドも、Centralized Streamingコマンドと同様に並列処理ができず、一度Search Headにイベントを集約してから処理を行う必要があります。

2-4. Generatingコマンド

新しいデータを生成するコマンドをGeneratingコマンドと呼びます。search、rest、makeresultsなどが例です。サーチコマンドの先頭で省略されているsearchは、実はGeneratingコマンドです。これらコマンドは、通常パイプ(|)をコマンドの前につけて、“| rest <URL>”などの使い方をします。これらコマンドはSearch Headから実行されます。

2-5. Orchestratingコマンド

サーチプロセス全体を管理するコマンドをOrchestratingコマンドと呼びます。require、localopなどが例です。これらのコマンドは、Splunkが実行するサーチプロセスを管理するため、サーチの結果には影響を与えません。これらコマンドはSearch Headから実行されます。

2-6. Dataset Processingコマンド

サーチ結果に対して処理を行うコマンドをDataset Processingコマンドと呼びます。sort、tail、fillnullなどが例です。

これらのコマンドは、サーチ結果のソートやフィルタリングなどを行います。例えば、sortやdedupコマンドは、データセットをソートしたり、重複を排除したりします。これらコマンドはSearch Headから実行されます。

効率的なサーチを実行するための考慮事項

例えば、以下のサーチを考えてみます。

【ケース1】

index=main sourcetype=access_combined_wcookie
| stats count by clientip
| rename clientip as sourceIp
| table sourceIp, count

実は、上記のサーチは分散環境では非効率な可能性があります。その理由は、Distributable Streamingコマンドであるrenameを、Transformingコマンドであるstatsの後に使用してしまっているためです。

Distributable Streamingコマンドは、Indexerで分散処理ができるコマンドです。しかし上記の例では、Transformingコマンド(stats)を先に使用してしまっています。この場合、statsを適用する時に、全イベントがSearch Head側に集約されてしまいます。このため、rename処理を実行するのはSearch Headになってしまい、並列処理ができず、Search Headが単独で処理を行うことになってしまいます。

(ただし、statsコマンドを実行した後のイベントの数が非常に少ない場合は、statsコマンドを実行した後にrenameを実行した方が効率的な場合もあります。今回はclientipの数が多く、rename処理にも時間がかかるケースを想定します)

Distributable StreamingコマンドをIndexerで並列処理させるためには、以下のように順序を変えるとよいです。

【ケース2】

index=main sourcetype=access_combined_wcookie
| rename clientip as sourceIp
| stats count by sourceIp
| table sourceIp, count

この順序であれば、renameコマンドはIndexerで並列処理され、その後、Search Headでイベントが集約されてstats処理が行われます。

Distributable Streamingコマンドは、できる限りSPLの先頭で使用するほうがよいコマンドです。

Search Job Inspectorによるサーチジョブの調査

サーチの実行状況を調査するために有用なツールに、Search Job Inspectorがあります。今回、このツールを使用して、サーチジョブの実行結果について調査してみます。Search Job Inspectorは、サーチ実行後、「ジョブ」-「ジョブの調査」を選択すると起動できます。

またはメニューバーから「アクティビティ」-「ジョブ」を選択してから調査したいジョブの「アクション」-「ジョブ」-「ジョブの調査」を選択しても起動可能です。

【サーチ実行後の「ジョブ」からの起動】

Search Job Inspectorを起動すると、上部にサーチの結果が表示されます。このバーに、サーチによって得られた結果の数、サーチを実行した際にスキャンしたイベントの数、かかった時間が表示されています。

【ケース1】のサーチジョブ結果

【ケース2】のサーチジョブ結果

上記を見れば分かる通り、【サーチ1】では、1.7倍の時間がかかってしまっていることがわかります。(ただし、サーチ時間は実行タイミングによって多少変化します)

Search Job Inspectorを使うと、他にもサーチジョブ効率化のヒントとなる情報がわかります。サーチジョブ結果の「サーチジョブのプロパティ」を見ると、ユーザーが指定したSPLをSplunkがどう解釈し、実際に実行したサーチがわかります。

【ケース1】のサーチジョブのプロパティ

【ケース2】のサーチジョブのプロパティ

remoteSearchは、Search Headから見たリモートサーバー、つまりIndexerで実行されたサーチを示しています。reportSerachというのが、Search Head自身が実行したサーチです。上記を見ると、ケース1では、Search Headで“rename clientip as sourceIp”という処理を行っており、Search Headで行う処理量が多いことがわかります。

これ以外にも、Search Job Inspectorでは、サーチジョブを実行した際、どのコンポーネントの処理にどれくらい時間がかかっているのかなどが視覚的に分かる機能もあります。特定のサーチ処理に時間がかかっており、改善を検討したい場合に便利なツールですので、ぜひ使用してみてください。

まとめ

今回、Splunk SPLのコマンドのタイプと、実際にサーチジョブの結果を調査するためのツールであるSearch Job Inspectorについてご紹介しました。

サーチを効率化する上で重要なことを端的にまとめると、Distributable Streamingコマンドがある場合は、できる限りSPLの先頭で実行し、Indexer側で並列処理できるように工夫するとよい場合がある、ということと、必要に応じてSearch Job Inspectorなどのツールを使ってジョブの実行状況を調査する、ということです。

興味がある方は、ぜひ以下の参考リンク先もお読みいただき、SplunkのコマンドタイプやSearch Job Inspectorの使い方について学んでみてください。

• Types of commands
• Command types
• Write better searches
• View search job properties