PLATFORM

データ前処理が簡単に:SPL2 for Edge Processor

Splunk Edge Processorの一般提供が開始されたというすばらしいニュースはすでにご存じかもしれません。Edge Processorは、エッジでデータをフィルタリング、変換、ルーティングするための使いやすいデータ前処理ツールです。Splunk環境のデータ管理者は、Edge Processorを使用することで、不要なデータを取り除き、機密情報をマスキングして、ペイロードを補足し、条件に従ってデータを適切な送信先に転送できます。お客様側のデータエッジに導入し、Splunk Cloud Platformから管理できるEdge Processorは、データコストを管理し、ダウンストリームで有効活用できるようにデータを前処理するために役立ちます。

さらに、Edge Processorの一般提供とともに、SPL2 for Edge Processorプロファイルの一般提供も開始されました!SPL2 for Edge Processorプロファイルは、Edge Processorでのデータの管理と変換に使用できる強力なSPL2コマンドと関数を含むサブセットで構成され、SPL2の表層の機能の一部が利用可能です。

Edge Processorでは、2つの方法で処理パイプラインを定義できます。まずは、データ管理者がEdge Processorのパイプラインエディターでポイント&クリック機能を使う方法で、これはパイプラインをすばやく簡単に作成できる点で優れています。また、同じパイプラインエディターを使い、SPL2コードエディターウィンドウでコードを直接記述して、パイプラインを非常に柔軟に作成することもできます。これによって管理者は、コードエディターでSplunk SPLのエキスパートと同じように直接SPL2言語を使用できます。SPLの文法パターンをData in motion(移動中のデータ)の変換に適用できるため、非常に便利です。こちらの方法についてもう少し詳しくご説明しましょう。

SPL2とは 

SPL2は、構文、よく使われるコマンド、調査のしやすさ、流れるような構造など、SPLのさまざまな利点を引き継ぎながら、(splunkdを介して取得した)保存済みデータだけでなく、ストリーミング中のデータも操作できます。そのため、SPLは使い慣れているがprops.confやtransforms.confの複雑なルール設定には慣れていないデータ管理者や開発者などでも、Edge Processorを使えば、今あるSPLの知識をそのままData in motion(移動中のデータ)の加工に役立てていただくことができるようになります。

SPL2は、構文、よく使われるコマンド、調査のしやすさ、流れに沿った構造など、SPLのさまざまな利点を引き継ぎながら、(splunkdを介して取得した)保存済みデータだけでなく、ストリーミング中のデータも操作できます。そのため、SPLは使い慣れているがprops.confやtransforms.confの複雑なルール設定には慣れていないデータ管理者や開発者などでも、Edge Processorを使えば、SPLの知識を活かしてData in motion(移動中のデータ)に直接適用できるようになります。

SPL2パイプラインのテンプレートsyslogデータのホスト名フィールドでIPアドレスをマスキングするSPL2パイプラインのテンプレート

 

SPL2はすでに見えないかたちで複数のSplunk製品の内部で、データの前処理、処理、サーチなどの操作に使用されています。将来的には、真に統一されたプラットフォームを実現するために、Splunkポートフォリオ全体でSPL2を利用できるようにする予定です。 

Data in motion(移動中のデータ)について前処理するニーズをよりシームレスにサポートする幅広い新機能がSPL2に導入されていることは、SPLを使い慣れた方にとって良いニュースでしょう。その一部をご紹介します。

 

  • データの型変換(キャスト)が不要です。SPL2は型付けが弱い言語で、ユーザーが必要に応じて型(カスタム型を含む)の制約を設定できます。デフォルトでは異なる型が暗黙的に変換されるため、型変換は必要ありません。そのため、受信データのフィールド形式やスキーマを心配する時間は少なくなり、適切なデータを適切な送信先に転送するための処理により多くの時間を使えます。
  • ソースと書き出し先の関数は非常に特化されたものでしたが、データセットに置き換えられました。これらのデータセットは個別に作成、権限付与、管理でき、任意の読み込み元または書き出し先に正しくマッピングでできます。これにより、データ管理者はデータのアクセスや書き出し方法をより詳細に管理しながら、パイプライン間での再利用を促進できます。

          ○  書き出し先に関するメタデータは、パイプラインの定義ではなくデータセットの設定から取得されるため、このメタデータをパイプライン内で渡す必要はありません。そのため、パイプライン定義が簡潔になり、理解しやすく再利用も容易になります。

  • 幅広いJSON操作に対応したeval関数を使ってJSONをシームレスに操作できます。ucastやその他の複雑なロジックを使用する必要はありません。 

 

SPL2 for Edge Processorプロファイルとは 

SPL2では、幅広いデータ操作がサポートされます。SPL2 for Edge Processorプロファイルは、SPL2言語のサブセットで、Edge Processorから使用できます。現時点でEdge Processorの主な用途には、データ送信の管理、機密データのマスキング、フィールドの補足、適切な送信先で使用できるようにするためのデータの前処理などがあります。SPL2 for Edge Processorプロファイルは、これらの用途をシームレスなユーザーエクスペリエンスで実現するためのSPL2コマンドとeval関数に対応しています。SPL2プロファイルについて詳しくはこちら、SPL2コマンドの製品ごとの互換性についてはこちら、SPL2 eval関数の製品ごとの互換性についてはこちらをご覧ください。

Edge ProcessorでのSPL2の使い方

Edge Processorパイプラインは、ソースからデータを読み込み、そのデータに対して一連の処理を実行して、処理後のデータを送信先に書き込むロジックで構成されます。パイプラインはすべてSPL2で定義します(Edge Processorのコードエディターでコードを直接記述する方法と、パイプライン作成用のGUIを介して間接的に作成する方法があります)。SPL2パイプラインでは、同じようなタイプのデータに関連することの多いすべての変換操作をまとめて定義します。

パイプラインの基本的な構文は次のようになります。

$pipelinefrom $source |  | into $destination;

 

SPL2で定義したEdge Processorパイプラインの例を次に示します。

 

$pipelinefrom $source | rex field=_raw /user_id=(?P[a-zA-Z0-9]+)/ | into $destination;

 

このSPL2パイプラインは複数のコンポーネントに分けられます。

 

  • $pipeline:任意のEdge Processorノードまたはクラスターに適用するパイプラインステートメントの定義です。ドル記号($)が示すとおりこれはパラメーターであり、代入(=)演算子の右側にあるすべての要素がこの左側のパラメーターに代入されます。

          ○  注:非常に長くて複雑なパイプラインの場合は、次の疑似SPL2コードのようにパイプラインを複数のセグメントに分けることもできます。


$pipeline_part_1 = from $source | where … | rex field=_raw /fieldA… fieldB… fieldC…

 


$pipeline = from $pipeline_part_1 | eval … | into $destination;

 

  • from $source$sourceという名前のデータセット変数で指定されているデータセットからデータを読み込むことを示します。Edge Processorのデータ設定パネルを使って、処理するデータを表すデータセットをこの変数に割り当てることができます。この場合、$sourceは、Edge Processorの管理ページで設定できる事前設定済みのソースタイプを示します。
  • rex field…:_rawフィールドからuser_idフィールドを抽出するための正規表現です。Edge ProcessorではRE2形式の正規表現のみがサポートされ、PCREはサポートされないことに注意してください。
  • into $destination:このパイプラインでは$destinationという名前のデータセット変数で指定されている送信先にデータを書き込むことを示します。Edge Processorデータ設定パネルを使って、SplunkインデックスやS3バケットなど特定のデータセットをこの変数に割り当てることができます。

お気づきかもしれませんが、今回のSPL2と既存のSPLにはいくつかの違いがあります。まず、SPL2では、単一の式だけでなく式の代入を使用できます。各サーチに名前を割り当て、それらを変数として扱い、すべてを連結して単一の実行可能ユニットを構成できます。また、データセットからの読み込みだけでなく、データセットへの書き出しもサポートされます(構文もやや異なります)。データセットには、インデックス、S3バケット、フォワーダー、ビューなど、さまざまな要素を指定できます。多くの場合、書き込み先にはSplunkインデックスを指定することになるでしょう。SPL2とSPLの違いについて詳しくは、こちらをご覧ください。

次に、パイプラインが1つのソースタイプに制約されない場合について考えてみましょう。この場合は、all_data_readyという名前のデータセット(すべてのEdge Processor受信データをまとめたもの)からデータを読み込み、任意のソースタイプのロジックを適用します。


$pipelinefrom $all_data_ready | where sourcetype=”WMI:WinEventLog:*” | rex field=_raw /user_id=(?P[a-zA-Z0-9]+)/ | into $destination;
  • where sourcetype=”WMI:WinEventLog:*” :パイプで入力されたデータをフィルタリングして指定のソースタイプと一致するイベントだけを残します。このパイプラインの以降の操作はこのソースタイプに対してのみ実行されます。

SPL2でデータ前処理を簡素化する方法

ここまでで、SPL2が単に一連のコマンドと関数を提供するだけでなく、強力なデータ処理シナリオの実現というコンセプトを中核に据えた言語であることがわかってきたかと思います。実際、Edge Processorには、次の図に示すように、いくつかの一般的なデータ前処理のユースケースに対応した、すぐに使えるSPL2パイプラインテンプレートが用意されています。

テンプレート

テンプレートを使用する以外にも、以下の方法でSPL2を使用してデータ前処理を簡素化できます。

複数のステージにまたがる複雑なパイプラインを複数のコンポーネントに論理的に分割する

SPL2では、組み立て、デバッグ、論理的な分割がしやすいように、複数のステージにまたがるパイプラインを定義できます。SPL2モジュール内でステートメントの代入を後続の処理で変数として使用することで、データ管理者はデータ前処理ルールをモジュール式に組み立てることができます。

$capture_and_filter = from $all_data_ready | where sourcetype=”WinEventLog:*”

 

$extract_fields = from $capture_and_filter | rex field = _raw /^(?P.*?),(?P.*?),(?P

 

$indexed_fields = from $extract_fields | eval dest_ip = ip, raw_mac = mac, signature_id = msdhcp_id, user = msdhcp_user

 

$quarantine_logic = from $indexed_fields | eval quarantine_info = case(qresult==0, "NoQuarantine", qresult == 1, "Quarantine", qresult == 2, "Drop Packet", qresult == 3, "Probation", qresult == 6, "No Quarantine Information")

 

$pipeline = from $quarantine_logic | into $destination

ここでは、このパイプラインの処理ステージとして「$capture_and_filter」、「$extract_fields」、「$indexed_fields」、「$quarantine_logic」の4つを定義し、それぞれ次のステージにつないでいます。そして最後の「$pipeline」で最終結果を送信先に書き込んでいます。「$pipeline」を実行すると、内部ですべてのステージが連結されて、想定どおりにパイプラインが機能します。一方で、モジュール全体は一定のレベルで論理的に分割され、読みやすくなっています。 

複雑にネストしたJSONイベントを簡単に複数値フィールドに変換してから複数行イベントとして取り出す

SplunkでJSONを扱ったことがあれば、その厄介さはご存じでしょう。props.confでmvindexmvzipevalmvexpandsplit、場合によってはSEDCMDを延々と組み合わせることになります。

SPL2では、expand()コマンドとflatten()コマンドを使って、同じことが今までになく簡単にできます。この2つのコマンドは組み合わせて使うことが多く、まずexpandで、値の配列を含むフィールドを展開して、配列内の各オブジェクトを含む個別の行を生成してから、flattenを使って、オブジェクト内のキーと値のペアをイベント内の個別のフィールドに格納するという処理を必要な回数だけ繰り返します。

例として、単一のイベントとして渡された次のJSONを、$json_dataという名前のデータセットとして処理する場合を考えてみましょう。インデックス時に欠落していたタイムスタンプを作成し、ネストした各スタンザを個別のイベントに取り出します。

{
        "key": "Email",
        "value": "john.doe@bar.com"
      },
      {
        "key": "ProjectCode",
        "value": "ABCD"
      },
      {
        "key": "Owner",
        "value": "John Doe"
      },
      {
        "key": "Email",
        "value": "jane.doe@foo.com"
      },
      {
        "key": "ProjectCode",
        "value": "EFGH"
      },
      {
        "key": "Owner",
        "value": "Jane Doe"
      }
}

このままで何の前処理もしなければ、JSON本文にすべてのフィールドが詰め込まれた1つのイベントが渡されます。

イベント

 

しかし、次のSPL2を使えば、簡単にこのJSONをフラット化してタイムスタンプを付加できます。

$pipeline = FROM $json_data as json_dataset | eval _time = now()
 | expand json_dataset | flatten json_dataset | into $destination

これにより、1つのJSONイベントから複数のイベントが取り出され、次のように各フィールドに格納されます。

フィールド

 

Edge ProcessorでSPL2を始めましょう

Edge Processorで使われるSPL2は非常に強力で、このブログ記事がお伝えするのはほんの一部です!SPL2やSPL2 for Edge Processorプロファイルにご興味がある場合は、ぜひお試しください。まずは、担当のアカウントチームにご相談いただくか、splunk-usergroups Slackから会話を始めてみてください。

このブログはこちらの英語ブログの翻訳、岡 大によるレビューです。

Aditya Tammana
Posted by

Aditya Tammana

Aditya is a Senior Product Manager at Splunk. While he focuses on the SPL2 search language currently, he has been deeply involved in core splunkd, Dashboards, and storage in the past. He loves to eat his way through as many countries as possible, document the process, and attempt to recreate that food at home (with mixed success). He once Splunked his dog using the Fitbit Add-on for Splunk to keep an eye on his health patterns.

TAGS
Show All Tags
Show Less Tags