
Google Cloud のデータを Pull ベースで取り込む
2025年3月19日にSplunkさんのパートナー向けワークショップが開催されました。
Google Cloudのデータ取り込みに関するハンズオンで実施した内容についてご紹介したいと思います。
ハンズオンの内容は以下で公開されています。
今回のブログでは、「lab1」の内容をご紹介します。
「lab1」では、Pullベースのデータ収集アーキテクチャで、Splunk Cloud から Google Cloud API を叩きに行って、データの取得を行います。
さらにPullベースの以下の3つのパターンについて実践します。
- 各リソースからのメタデータ(ワークショップでは Compute Engine のメタデータ)
- Cloud Monitoring 経由でのメトリクス
- Cloud Logging 経由での監査ログ
ワークショップ手順では、これらの3つのパターンを Google Cloud 側の設定、Splunk 側の設定に分けて一気にやっていますが、当ブログでは仕組みを確認するために1パターンずつに分解して、ご紹介します。
(手順や設定内容も一部変更しています。)
Compute Engine のメタデータ
アーキテクチャイメージは以下の通りです。
Splunk Cloud の Add-on が Compute Engine のメタデータを参照するREST APIを叩いて、データを定期的に取得します。

Compute Engine API Reference:
まず、最初にGoogle Cloudで設定を行います。
Compute Engine でバーチャルインスタンスを1台立てている前提で始めます。
IAMと管理 でサービスアカウントを作成します。

サービスアカウント名とサービスアカウントIDを入力

ロールはCompute 閲覧者を選択します。
ロール選択時に検索する時はroles/compute.viewerで探すと良いです。
必要なロールについては、下記のドキュメントから確認が可能です。
Configure the Google Cloud Platform service permissions - Splunk Add-on for Google Cloud Platform

サービスアカウント で作成したサービスアカウントを選択し、鍵で新しい鍵を作成します。
JSONで作成します。

次にSplunk Cloudで操作します。
Splunk Add-on for Google Cloud PlatformのConfiguration > Google Credentials > Add を選択します。
(Add-onは別途インストールしておきます。)

任意の名前、アカウントタイプをService Accountにし、先ほど作成したサービスアカウントのクレデンシャル情報をテキストで開き、JSONをコピペします。

InputsのCreate New Input > Resource Metadata 、その配下の Compute Engine を選択します。

Name、先ほど設定したCredential、Project、Zonesを選択します。
(あらかじめ1台のCompute Engineインスタンスを立てています。そのインスタンスのZoneを選択してください)
取得する項目はデフォルトで、Indexはgcpというインデックスをあらかじめ作って設定しました。
Sourcetypeはgoogle:gcp:resource:metadaに設定します。

しばらくするとデータが収集されるので、Search & Reportingを開いて検索します。
先ほど設定したindexとsourcetypeを指定して検索すると、データが取得できていることが確認できました。
index=gcp sourcetype="google:gcp:resource:metadata"

左側で Add-on で自動識別されたフィールドに注目して、kindを見ると、いくつかの種類のメタデータを取得してきていることが確認できます。
中でも、compute#instanceに注目してみます。

compute#instanceをダブルクリックすると、検索条件が追加されるので見てみます。
起動中のインスタンスの情報が出力されました。

さらに情報を詳しく見ていくと、ディスクライセンス、インスタンスタイプ、ネットワーク情報、サービスアカウントなどが確認できます。




この辺りを分析していくと良い情報がとれそうです。
Compute Engine のメトリクス
次に Compute Engine のメトリクスを取得します。
アーキテクチャとしては以下のようなイメージです。

Google Cloudで設定します。
IAMと管理 の IAM で前の手順で作成したサービスアカウントを編集し、ロールを追加します。
ロールはモニタリング閲覧者を選択します。
ロール選択時に検索する時はroles/compute.viewerで探すと良いです。

次にSplunk Cloudで操作します。
Inputs の Create New Input > Cloud Monitoring を選択します。

名前、Credentials、プロジェクト、Monitored Projectsを入力します。
Cloud Monitor Metricsでは取りたいメトリクスを取得しますが、今回は Compute Engine のメトリクスを対象にしてみました。
compute.googleapis.com/instance/.* というように 「.*」 とすると、以下のメトリクス全てを対象にすることができました。
その他、インターバル、 取得対象開始日、任意のindexを設定します。

しばらくするとデータが収集されます。メトリクスの収集は少し時間がかかるみたいです。体感で5分程度でログが現れたような気がします。
Search & Reportingを開いて検索します。
先ほど設定したindexとsourcetypeを指定して検索すると、データが取得できていることが確認できました。
index=gcp sourcetype="google:gcp:monitoring"

どんなメトリクスが取れているのか確認したいので、左側のフィールドからmetric.typeを見ると、Top10のメトリクスが表示されます。全部で29個収集できているようです。

とここで気づいたのですが、メトリクスの場合 index を明示的に metrics 用のものに取り込むことで時系列のデータプロットを簡単に可視化することができるのですが、Add-on 側のマニュアルにはそのようなことは一切書かれていません。
(ワークショップでもその点には、特に言及がなかった)
なので、Cloud Monitoring のメトリクスはイベントとして取り込まれているようです。
ログイベントと同様のSQLクエリを使ってメトリクスを可視化するのは可能ですが、時系列で流れてくるメトリクスの分析はしづらいので、この収集方法ではそういった用途では向いていなさそうです。
Splunk Ovserbability Cloud 側で取り込むと良さそうなのですが、ライセンスが異なるのでまたの機会に試してみようと思います。
Google Cloud Platform (GCP) Monitoring Solutions | Splunk
Cloud Logging 監査ログ + OSログ
最後に、監査ログ(Cloud Audit Logs)、Compute EngineのOSログを Cloud Logging 経由で取得します。
アーキテクチャイメージは以下の通りです。

Google Cloudで設定します。
まず、最初に Pub/Sub を設定します。
Pub/Sub の トピック でトピックを作成します。

トピック名を入力して、デフォルトのサブスクリプションを追加する にチェックを入れて、残りはデフォルトで作成します。
トピックの作成と同時にサブスクリプションが作成されることになります。

サブスクリプションの画面でもサフィックスに"-sub"の名前で作成されていることが確認できました。

次に、Cloud Logging の設定を行います。
Cloud Logging では、ログルーターという機能を利用して、Cloud Logging が収集したログを次のサービスに流すことができます。
やっていきます。
オブザーバビリティ ロギング の ログルーター でシンクを作成します。

シンク名を入力して、次へ進みます。

ログルーターで送る先を選ぶことができます。Splunk を選びます。

先ほど作成したトピックを選択して、そのままシンクを作成します。
ここで、シンクに含めるログを選択して、取得するログを限定することができます。
今回は、特にフィルタリングせずに設定しています。

下記のブログに、「監査ログ (Cloud Audit Logs)」の各種ログタイプのについて触れていますので、そちらで概要をつかんでいただくことも可能です。
Splunkさん主催 Google Cloud のデータ取り込みワークショップに参加してみた! | DevelopersIO
公式ドキュメント参考:
Cloud Audit Logs overview | Cloud Logging | Google Cloud
公式ドキュメント参考:
Ops エージェントの概要 | Cloud Logging | Google Cloud
次に IAMと管理 の IAM で前の手順で作成したサービスアカウントを編集し、ロールを追加します。
ロールはPub/Sub 閲覧者、とPub/Sub サブスクライバーを選択し、保存します。
ロール選択時に検索する時はroles/pubsub.viewer、roles/pubsub.subscribeで探すと良いです。

続いて、Splunk側の操作になります。
Inputs の Create New Input > Cloud Pub/Sub を選択します。

名前、Credentials、プロジェクト、先ほど作成したトピック、任意のindex、 Source Typeにgoogle:gcp:pubsub:messageを設定します。

しばらくするとデータが収集されるので、Search & Reportingを開いて検索します。
先ほど設定したindexとsourcetypeを指定して検索すると、データが取得できていることが確認できました。
index=gcp sourcetype="google:gcp:pubsub:message"
さらにdata.logNameに注目してみると、Syslogなどが確認でき、Ops エージェント 経由のOSログが見れていることが分かります。

また、監査ログ系のエントリについては、それぞれ別のソースタイプで入ってくるようです。
Add-on の設定コンフィグの中身を確認して見てみたのですが、それぞれ以下のようなソースタイプに裏で変換されているようです。
| 監査ログ種別 | ソースタイプ |
|---|---|
| 管理アクティビティ | google:gcp:pubsub:audit:admin_activity |
| システムイベント | google:gcp:pubsub:audit:system_event |
| ポリシー拒否 | google:gcp:pubsub:audit:policy_denied |
| データアクセス | google:gcp:pubsub:audit:data_access |
| 透明性ログ | google:gcp:pubsub:access_transparency |
| 特定できなかった。。(補足後述) | google:gcp:pubsub:platform |
Google Cloud 側でいくつか設定変更を加えた後、indexだけを指定してSplunkで検索してみます。
index=gcp
sourcetypeを見てみると、google:gcp:pubsub:audit:admin_activity、google:gcp:pubsub:audit:system_event、google:gcp:pubsub:platformの3つが出力されていました。

まず、google:gcp:pubsub:audit:admin_activityを選択して、見てみます。
index=gcp sourcetype="google:gcp:pubsub:audit:admin_activity"

「管理アクティビティ」は、主にGoogle Cloudのリソースへの変更系のログが記録されています。
data.protoPayload.serviceNameのフィールドに注目してみると、ざくっと以下のリソースへの変更履歴があったことが分かります。

この辺りのログを分析していくことで、どんな変更があったのか把握していくことができそうです。
次に、google:gcp:pubsub:audit:system_eventを検索します。
index=gcp sourcetype="google:gcp:pubsub:audit:system_event"

「システムイベント」のログになりますので、ユーザーが行ったイベントではないGoogle Cloud側のアクションでのリソース変更履歴が記録されます。
data.protoPayload.methodNameのフィールドに注目してみると、Compute Engine へのスケジュールされたスナップショットが作成されていたことが分かります。

最後に、google:gcp:pubsub:platformを検索します。
index=my_gcp sourcetype="google:gcp:pubsub:platform"

どういった種別のログか想像がつかなかったので、いくつかのフィールドを確認します。
data.resource.typeを確認すると、Compute Engine のインスタンスと、ネットワークサービスに該当するのでしょうか?

それから、data.logNameを確認すると、sheilded_vm_integrity(整合性検証機能)に関するもの、networkanalyzer(ネットワークアナライザ)に関するもの、が該当しているように思います。

こちらについては、私の Google Cloud への理解不足もあり、どんなタイプのログなのかまで特定できませんでした。
分析について
ワークショップの講義では、Google Cloud のログ分析に関する参考リンクを教えていただきました。
それぞれのサービスごとに、Cloud Logging ログエクスプローラーでのクエリサンプルが紹介されています。
どういった観点で分析するかの参考として非常に有益なGoogle Cloudの公式ドキュメントになります。
Sample queries | Cloud Logging | Google Cloud
CSA(Community Security Analytics) では、セキュリティ観点での重要なイベントや分析クエリがまとまっています。
該当するログを発生させる方法と、その時のログを検索するクエリとの両軸で確認できるので、非常に勉強になりそうです。
まとめ
以上、2025年3月19日にSplunkさんのパートナー向けワークショップで実施したハンズオン「lab1」の内容についてお送りしました。
Splunkで Google Cloud のログ分析をやってみたいなと思った時に参考にしていただけると幸いです。








