Google Cloud のデータを Pull ベースで取り込む

Google Cloud のデータを Pull ベースで取り込む

Google Cloud から Pullベースで取り込む代表的な3パターンのハンズオンを実施しました。取り込み設定と、取り込んだデータの検索方法についてご紹介します。
Clock Icon2025.03.28

2025年3月19日にSplunkさんのパートナー向けワークショップが開催されました。
Google Cloudのデータ取り込みに関するハンズオンで実施した内容についてご紹介したいと思います。

ハンズオンの内容は以下で公開されています。
今回のブログでは、「lab1」の内容をご紹介します。

GCP-GDIMacGyver/content/Lab1_gcpaddon/lab_1_overview.en.md at main · therealtrex/GCP-GDIMacGyver · GitHub

「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を叩いて、データを定期的に取得します。

vscode-paste-1743124025576-5q4w9lhsk8u.png

Compute Engine API Reference:
https://cloud.google.com/compute/docs/reference/rest/v1

まず、最初にGoogle Cloudで設定を行います。
Compute Engine でバーチャルインスタンスを1台立てている前提で始めます。

IAMと管理 でサービスアカウントを作成します。

vscode-paste-1743123364028-8f1cos4c8b6.png

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

vscode-paste-1743049058083-m66en4zib5q.png

ロールはCompute 閲覧者を選択します。
ロール選択時に検索する時はroles/compute.viewerで探すと良いです。

必要なロールについては、下記のドキュメントから確認が可能です。
Configure the Google Cloud Platform service permissions - Splunk Add-on for Google Cloud Platform

vscode-paste-1743123495812-rx7yay1ado.png

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

vscode-paste-1743049303797-alfto4m4oie.jpeg

次にSplunk Cloudで操作します。

Splunk Add-on for Google Cloud PlatformConfiguration > Google Credentials > Add を選択します。
(Add-onは別途インストールしておきます。)

vscode-paste-1743049655472-zkpczvyph0p.png

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

vscode-paste-1743049808632-miitiwzox2.png

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

vscode-paste-1743049973910-bw3gnen864n.png

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

vscode-paste-1743050505278-5pbk332wbfm.png

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

index=gcp sourcetype="google:gcp:resource:metadata"

vscode-paste-1743053327510-ge4yoxzrr4s.png

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

vscode-paste-1743053404557-bhb7cyahw57.png

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

vscode-paste-1743053777524-t7rmnn25ds.png

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

vscode-paste-1743054134969-zgxzqvsgfn.jpeg

vscode-paste-1743054148498-j5mvwcmohxa.png

vscode-paste-1743054155934-huqg7aamg2.png

vscode-paste-1743054170067-2a6wtl00fak.jpeg

この辺りを分析していくと良い情報がとれそうです。

Compute Engine のメトリクス

次に Compute Engine のメトリクスを取得します。
アーキテクチャとしては以下のようなイメージです。

vscode-paste-1743124010785-e3bp8wkykud.png

Google Cloudで設定します。
IAMと管理IAM で前の手順で作成したサービスアカウントを編集し、ロールを追加します。

ロールはモニタリング閲覧者を選択します。
ロール選択時に検索する時はroles/compute.viewerで探すと良いです。

vscode-paste-1743060618150-vm30c1zzgt.png

次にSplunk Cloudで操作します。

InputsCreate New Input > Cloud Monitoring を選択します。

vscode-paste-1743122181420-xtxts39a5pj.png

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

vscode-paste-1743122467551-a7xzuc2u2wf.png

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

index=gcp sourcetype="google:gcp:monitoring"

vscode-paste-1743122799304-4cci4y8w4fq.png

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

vscode-paste-1743122966037-ivezb1pngi.png

とここで気づいたのですが、メトリクスの場合 index を明示的に metrics 用のものに取り込むことで時系列のデータプロットを簡単に可視化することができるのですが、Add-on 側のマニュアルにはそのようなことは一切書かれていません。
(ワークショップでもその点には、特に言及がなかった)

なので、Cloud Monitoring のメトリクスはイベントとして取り込まれているようです。
ログイベントと同様のSQLクエリを使ってメトリクスを可視化するのは可能ですが、時系列で流れてくるメトリクスの分析はしづらいので、この収集方法ではそういった用途では向いていなさそうです。

Splunk Ovserbability Cloud 側で取り込むと良さそうなのですが、ライセンスが異なるのでまたの機会に試してみようと思います。
Google Cloud Platform (GCP) Monitoring Solutions | Splunk
https://www.splunk.com/en_us/solutions/gcp-monitoring.html

Cloud Logging 監査ログ + OSログ

最後に、監査ログ(Cloud Audit Logs)、Compute EngineのOSログを Cloud Logging 経由で取得します。
アーキテクチャイメージは以下の通りです。

vscode-paste-1743123996403-fghmgvxbo8p.png

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

vscode-paste-1743118731854-3shj88qhnnw.png

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

vscode-paste-1743118848898-xnk94xotjsl.png

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

vscode-paste-1743119042121-lmhc29t2mbn.png

次に、Cloud Logging の設定を行います。
Cloud Logging では、ログルーターという機能を利用して、Cloud Logging が収集したログを次のサービスに流すことができます。
やっていきます。

オブザーバビリティ ロギングログルーター でシンクを作成します。

vscode-paste-1743119316223-hxxrkygyyom.png

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

vscode-paste-1743119130480-vzc7wi7t4i.jpeg

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

vscode-paste-1743119461604-p3h9bv8fq1p.png

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

vscode-paste-1743120563894-9hn7z15q2ar.png

下記のブログに、「監査ログ (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.viewerroles/pubsub.subscribeで探すと良いです。

vscode-paste-1743120986192-3t9rz6lkqof.png

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

vscode-paste-1743121257068-uoqz6ltccs.png

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

vscode-paste-1743121446523-cvpgcrzobnn.png

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

index=gcp sourcetype="google:gcp:pubsub:message"

さらにdata.logNameに注目してみると、Syslogなどが確認でき、Ops エージェント 経由のOSログが見れていることが分かります。

vscode-paste-1743127961567-yrx6vk1te3d.png

また、監査ログ系のエントリについては、それぞれ別のソースタイプで入ってくるようです。
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_activitygoogle:gcp:pubsub:audit:system_eventgoogle:gcp:pubsub:platformの3つが出力されていました。

vscode-paste-1743129419873-p3mgugrfvk.png

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

index=gcp sourcetype="google:gcp:pubsub:audit:admin_activity"

vscode-paste-1743129766805-4e71dto9hsi.png

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

vscode-paste-1743129920371-xhxgy0316jf.png

この辺りのログを分析していくことで、どんな変更があったのか把握していくことができそうです。

次に、google:gcp:pubsub:audit:system_eventを検索します。

index=gcp sourcetype="google:gcp:pubsub:audit:system_event"

vscode-paste-1743130258925-s0quitsyodj.png

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

vscode-paste-1743130638011-57bs96omg.png

最後に、google:gcp:pubsub:platformを検索します。

index=my_gcp sourcetype="google:gcp:pubsub:platform"

vscode-paste-1743130837305-yjvp8ltesin.png

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

vscode-paste-1743131392136-l8dd04a2l6q.png

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

vscode-paste-1743131645806-h9jn8yvpzcb.png

こちらについては、私の Google Cloud への理解不足もあり、どんなタイプのログなのかまで特定できませんでした。

分析について

ワークショップの講義では、Google Cloud のログ分析に関する参考リンクを教えていただきました。

それぞれのサービスごとに、Cloud Logging ログエクスプローラーでのクエリサンプルが紹介されています。
どういった観点で分析するかの参考として非常に有益なGoogle Cloudの公式ドキュメントになります。

Sample queries  |  Cloud Logging  |  Google Cloud

CSA(Community Security Analytics) では、セキュリティ観点での重要なイベントや分析クエリがまとまっています。
該当するログを発生させる方法と、その時のログを検索するクエリとの両軸で確認できるので、非常に勉強になりそうです。

GitHub - GoogleCloudPlatform/security-analytics: Community Security Analytics provides a set of community-driven audit & threat queries for Google Cloud

まとめ

以上、2025年3月19日にSplunkさんのパートナー向けワークショップで実施したハンズオン「lab1」の内容についてお送りしました。
Splunkで Google Cloud のログ分析をやってみたいなと思った時に参考にしていただけると幸いです。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.