Splunk Dataflow テンプレートの新機能: ログの自動解析、UDF サポートなど

※この投稿は米国時間 2021 年 8 月 13 日に、Google Cloud blog に投稿されたものの抄訳です。

Google は昨年、お客様が大量の Google Cloud のログとイベントを Splunk Enterprise 環境や Google Cloud 上の Splunk Cloud（現在は Google Cloud Marketplace に含まれています）に簡単かつ確実にエクスポートできるよう支援するため、Pub/Sub to Splunk Dataflow テンプレートをリリースしました。このテンプレートはリリース以来、Pub/Sub to Splunk Dataflow を使用して Google Cloud データから分析情報を得るため、エンタープライズとデジタル ネイティブの両方のお客様により広く採用されています。

Google は多くのユーザーと協力して、フィードバックに対応するとともに、Splunk Dataflow テンプレートの統合とカスタマイズの労力を低減する新機能を特定して追加しました。

機能更新の一覧を示します。これらの機能について、以下でさらに詳しく解説します。

• GCP 用の Splunk アドオンとの互換性が改善された、自動ログ解析

• カスタム変換用のユーザー定義関数（UDF）の拡張性の強化

• 信頼性とフォールト トレランスの拡張

これらの更新の背後にあるのは、お客様が価値創出までの時間（TTV）を短縮できるよう、Dataflow 側の運用の複雑性と、Splunk 側でのデータ ラングリング（知識管理とも呼ばれます）を低減するというテーマです。

Google は、インフラストラクチャの管理やサードパーティのアプリケーションとの統合に費やされる時間を減らし、自社の貴重な Google Cloud データを分析して、ビジネス分析、IT、セキュリティ運用などの目的で活用する時間を増やせるよう、企業を支援したいと考えています。Splunk Dataflow パイプラインにより毎日数 TB のログをエクスポートし、重要なセキュリティ運用に活用している大手ライフ サイエンス企業のリード クラウド セキュリティ エンジニアは次のように述べています。「私たちには信頼性の高いデプロイとテストのフレームワークが実装されており、それが需要に合わせてスケーリングされるという安心感があります。心配する必要がなく、最良のインフラストラクチャと言ってよいでしょう。」

これらの機能すべてを活用するには、Splunk Dataflow テンプレートの最新版（gs://dataflow-templates/latest/Cloud_PubSub_to_Splunk）、この記事の時点ではバージョン 2021-08-02-00_RC00（gs://dataflow-templates/2021-08-02-00_RC00/Cloud_PubSub_to_Splunk）またはそれ以降に必ずアップデートしてください。

Splunk との互換性の強化

「決めなければならないのは、与えられた時間で何をするかだけだ。」

- ガンダルフ

Splunk の管理者とユーザーは、ログやフィールドの解析と抽出に掛ける時間が減り、データを分析するためにより多くの時間を使用できるようになりました。

Google Cloud Platform 用の Splunk アドオン

デフォルトでは、Pub/Sub to Splunk Dataflow テンプレートは Pub/Sub メッセージ本文のみを転送し、Pub/Sub メッセージの全体や、その属性は転送しません。テンプレートのパラメータ includePubsubMessage を true に設定すると、GCP 用の Splunk アドオンと同様に Pub/Sub メッセージ全体を含めるように動作を変更できます。

しかし、Splunk Dataflow テンプレートの以前のバージョンでは、includePubsubMessage=true の場合に Pub/Sub メッセージ本文が文字列化され、message フィールドの下にネストされます。これに対して Splunk アドオンでは、data フィールドの下に JSON オブジェクトのネストが求められます。

これにより、お客様は Splunk アドオンの構成を（props と transforms を用いて）カスタマイズしてペイロードを解析するか、spath を使用して明示的に JSON を解析することになります。その結果、データが Dataflow により push されたか、アドオンにより pull されたかによって Splunk 検索を 2 種類（マクロにより）維持することになります。これは理想的な環境とはほど遠いものです。Splunk Dataflow テンプレートが GCP 用の Splunk アドオンと互換性のある形式でメッセージをシリアル化するようになったため、この作業は必要でなくなりました。つまり、デフォルトの JSON 解析、組み込みのアドオン フィールド抽出、データの正規化を初期状態のまま使用できます。

お客様は、共通情報モデル（CIM）コンプライアンスも含め、Splunk アドオンの sourcetypes のすべてをすぐに活用できます。これらの CIM モデルは、Splunk Enterprise Security（ES）や IT Service Intelligence（ITSI）などのプレミアム アプリケーションとの互換性のため必要なもので、Splunk Dataflow パイプラインで includePubsubMessage=true を設定している限り、お客様がそれ以上の作業を行う必要はありません。

includePubsubMessage で既存のパイプラインを更新するときの注意

パイプラインを includePubsubMessage=false から includePubsubMessage=true に更新し、UDF 関数を使用している場合、UDF 実装を必ず更新してください。この関数の入力引数は、ネストした data フィールドである基礎のメッセージ本文ではなく Pub/Sub メッセージ ラッパーになりました。関数で、入力引数の JSON 解析されたバージョンを obj 変数に保存すると想定した場合、本文のペイロードは obj.data にネストされることになります。たとえば、UDF がログエントリを Cloud Logging から処理する場合、obj.protoPayload への参照を obj.data.protoPayload に更新する必要があります。

Splunk HTTP Event Collector

また、Splunk HEC の "fields" メタデータを使用して Splunk のカスタム インデックス時間フィールド抽出を設定したいという希望もお客様から寄せられています。このため Google は、この最後に残っている Splunk HEC メタデータ フィールドのサポートを追加しました。これにより、これらのインデックス時間フィールドの抽出を、受信側（Splunk インデクサーまたはヘビー フォワーダー）でノントリビアルな props と transforms を構成せず、送信側（Dataflow パイプライン）で簡単に設定できます。一般的な使用事例として、Cloud Logging からのメタデータ フィールド、具体的には project_id や instance_id などのリソースラベルをインデックスに登録し、固有のプロジェクト ID とインスタンス ID に基づく Splunk 検索と相互関連付けを高速化できます。resource.labels オブジェクトを使用して HEC フィールドのメタデータを設定する方法のサンプル UDF については、Dataflow UDF のスタートガイドに関するブログの「パターン 2: 変換イベント」にある例 2.2 をご覧ください。

ユーティリティ UDF による拡張性の強化

「わかりません。できれば当てずっぽうは避けたいんです。」

- フロド

Splunk Dataflow を使えば、Dataflow や Apache Beam プログラミングについて知らなくてもパイプラインの出力形式を修正できます。開発環境のセットアップも行う必要はありません。メタデータ フィールドの追加によるイベントの拡張、一部のプライベートなフィールドの削除、必要のないイベントの除外、またはイベントのルーティング先のインデックスといった Splunk メタデータの設定を行うことも可能です。

パイプラインをデプロイするときは、ユーザー定義関数（UDF）を参照できます。これは、イベントをその場で変換するための小さな JavaScript コードのスニペットです。こうした UDF の利点は、Dataflow テンプレート コード自体の変更、再コンパイル、保守を行わずにテンプレート パラメータとして構成可能なことです。言い換えれば、UDF は低レベルのテンプレートの詳細を抽象化しながら、データ形式をカスタマイズするための簡単なフックとして機能するのです。

UDF を作成するとき、UDF による Dataflow テンプレートの拡張に記載されているユーティリティ UDF の 1 つを基にすれば、当て推量で作業せずに済みます。この記事には、UDF のテストとデプロイの実践的なガイドも含まれています。

信頼性とエラー処理の改善

「盤は置かれ、駒は動き出した。ようやくこのときが来た。この時代で最大の戦いだ。」

- ガンダルフ

最後に重要な点として、最新の Dataflow テンプレートによりパイプラインのフォールト トレランスが改善され、Dataflow オペレーターのトラブルシューティング作業が簡素化されます。

特に、Splunk Dataflow テンプレートの再試行機能（指数バックオフ付き）が拡張され、過渡的な Splunk サーバーエラー（例: サーバーがビジー）に加えて、過渡的なネットワーク障害（例: 接続のタイムアウト）も対象となりました。従来は、これらのイベントはパイプラインにより直ちにデッドレター トピックにドロップされていました。これによりデータ消失が防止されますが、デッドレターに保管されている未配信メッセージを再試行するパイプライン オペレーターに不必要な負担をかける結果となっていました。新しい Splunk Dataflow テンプレートでは、可能なら再試行を行い、問題が恒久的な場合（例: Splunk HEC トークンが無効）や再試行の最大制限時間（15 分）が経過した場合のみメッセージをデッドレター トピックにドロップすることで、このオーバーヘッドが最小化されます。可能な Splunk 配信エラーの内訳については、Google の Splunk Dataflow リファレンス ガイドの配信のエラータイプをご覧ください。

最後に、UDF を採用してパイプラインの動作を前のセクションに示したようにカスタマイズするお客様が増えているため、Google は、JavaScript 構文エラーなど UDF ベースのエラーのロギングを改善するため投資しました。従来は、これらのエラーをトラブルシューティングするにはデッドレター トピックの未配信メッセージを検査する必要がありました。これらのエラーを、Cloud Console の Dataflow ジョブページから直接、ワーカーログで参照できるようになりました。ログ エクスプローラで使用できるクエリの例を示します。

また、Cloud Monitoring でアラート ポリシーを、このような UDF エラーが発生するごとにアラートを発するように設定し、デッドレター トピックのメッセージ ペイロードを確認してさらに検証することもできます。その後で、ソースログ シンク（該当する場合）を修正して、想定外のログを除外するか、それらのログを正しく処理するよう UDF 関数のロジックを変更できます。

次のステップ

「家を去り、目の前には世界が広がり、影を抜けて夜のとばりまで、星々の輝くまでには多くの道を歩まなくてはならぬ。」

- J. R. R. Tolkien

Splunk Dataflow の最新の拡張機能について概要を紹介しました。Google の目標は、ログの集約とエクスポートの運用上のオーバーヘッドを最小化し、お客様が重要なログからリアルタイムで見識を得ることに集中できるようにすることです。

まずは Google のリファレンス ガイドで、Dataflow を使用して本番で使用できるログを Splunk にエクスポートする機能をデプロイする手順をご確認ください。関連する Splunk Dataflow Terraform モジュールを利用して、ログのエクスポートのデプロイを自動化し、これらのサンプル UDF 関数で Splunk への配信前にログを（必要なら）即座にカスタマイズできます。

Splunk Dataflow の他の拡張機能については、Google の Dataflow テンプレート用の GitHub リポジトリをご覧ください。上述のすべての機能はお客様のご意見に基づき改善しております。引き続き機能のリクエストを GitHub リポジトリの問題点として、または Cloud Console から直接サポートケースとしてお寄せください。

謝辞

Splunk 社の Matt Hite 氏に、プロダクトの共同開発における密接な協力と、共同のお客様に対するサービスでのパートナーシップについて感謝申し上げます。

-ソリューション アーキテクト Roy Arsan