このシナリオでは、選択したログを Cloud Logging から Splunk Enterprise または Splunk Cloud にリアルタイムでエクスポートする方法について説明します。Splunk では、オンプレミスとクラウドのデプロイメントから収集したログ、イベント、指標を検索、分析、可視化し、IT とセキュリティのモニタリングを行うことができます。Cloud Logging のログを統合することで、Splunk などの既存のパートナー サービスを統合ログ分析ソリューションとして引き続き使用できます。Splunk をオンプレミスにデプロイすることも、Google Cloud で SaaS として使用することもできます。また、ハイブリッド アプローチも可能です。
このドキュメントでは、Google Cloud からログを push または pull して、Splunk にログをエクスポートする方法を説明します。次のセクションで説明するように、ほとんどのケースでは、クラウドネイティブの push ベースのアプローチが推奨の方法です。push ベースのログ エクスポート ソリューションをデプロイする方法については、Dataflow を使用して本番環境対応のログのエクスポートを Splunk にデプロイするをご覧ください。
はじめに
Splunk でサポートされている Google Cloud データを取り込むには、次の 2 つの方法があります。
- push ベース: データは Pub/Sub to Splunk Dataflow ジョブにより Splunk HTTP Event Collector (HEC) に送信されます。
- pull ベース: データは Google Cloud Platform の Splunk アドオンにより Google Cloud APIs から取得されます。
push ベースの方法で Google Cloud データを Splunk に取り込むことをおすすめします。この方法には次のメリットがあります。
- マネージド サービス。Dataflow マネージド サービスが、ログ エクスポートなどのデータ処理タスク用に Google Cloud で必要なリソースを管理します。
- 分散ワークロード。並列処理のためワークロードが複数のワーカーに分散されます。Splunk の負荷の高いフォワーダーでデータを pull する場合とは異なり、単一障害点はありません。
- セキュリティ。データは Splunk HEC に push されるため、サービス アカウント キーの作成と管理に関連するメンテナンスやセキュリティの負担は発生しません。pull ベースの方法でも、サービス アカウント キーの作成と管理が必要になります。
- 自動スケーリング。Dataflow サービスが、受信ログの量とバックログの変動に応じてワーカー数を自動的にスケーリングします。
- フォールト トレラント。サーバーまたはネットワークで一時的な問題が発生した場合、Splunk HEC への再試行が自動的に処理されます。この方法では、配信できないログメッセージによるデータ損失を回避するため、未処理のトピック（デッドレター トピック）もサポートされます。
- シンプル。管理オーバーヘッドと、1 つ以上の Splunk フォワーダーの実行にかかるコストを回避できます。
pull ベースの方法で Google Cloud データを Splunk に取り込むほうが良い場合もあります。次のような状況が考えられます。
- Splunk のデプロイメントで Splunk HEC エンドポイントが提供されない。
- ログの数量が少ない。
- Cloud Monitoring の指標、Cloud Storage オブジェクト、少量のログを pull する場合。
- すでに 1 つ以上の Splunk フォワーダーを管理している（または、Splunk Cloud のホスト型 Inputs Data Manager を使用している）。
ロギング エクスポートの設定
次の図は、Pub/Sub による Splunk へのロギングのエクスポートを有効にする手順を示しています。
Pub/Sub トピックとサブスクリプションを設定する
エクスポートされたログを受信し、トピックにサブスクリプションを追加するための Pub/Sub トピックを設定する手順を行います。
このドキュメントでは、次の Pub/Sub トピックとサブスクリプション名を使用します。
projects/compliance-logging-export/topics/logs-export-topic
projects/compliance-logging-export/subscriptions/logs-export-subscription
すべてのサービスで監査ロギングを有効にする
管理アクティビティ監査ログは常に書き込まれます。無効にすることはできません。ただし、データアクセス監査ログ（BigQuery 用を除く）は、デフォルトで無効になっています。すべての監査ログを有効にするには、IAM ポリシーを更新するための手順に沿って、監査ポリシーのドキュメントに記載されている構成を指定します。手順は次のとおりです。
- 現在の IAM ポリシーをファイルとしてダウンロードします。
- 監査ログポリシーの JSON または YAML オブジェクトを現在のポリシー ファイルに追加します。
- 変更されたポリシー ファイルを使用して Google Cloud プロジェクト（または組織）を更新します。
以下に、すべてのサービスで監査ログを有効にする JSON オブジェクトの例を示します。
"auditConfigs": [
{
"service": "allServices",
"auditLogConfigs": [
{ "logType": "ADMIN_READ" },
{ "logType": "DATA_READ" },
{ "logType": "DATA_WRITE" },
]
},
]
ロギング エクスポートを構成する
集約エクスポートまたはログのエクスポートを設定したら、ロギング フィルタを調整して、監査ログ、仮想マシン関連のログ、ストレージログ、データベース ログをエクスポートします。次のロギング フィルタには、管理アクティビティ監査ログとデータアクセス監査ログに加えて、特定のリソースタイプのログが含まれます。
logName:"/logs/cloudaudit.googleapis.com" OR resource.type:gce OR resource.type=gcs_bucket OR resource.type=bigquery_resource
Google Cloud CLI から、gcloud logging sinks create コマンドまたは organizations.sinks.create API 呼び出しを使用して、適切なフィルタを使用したシンクを作成します。次の gcloud コマンドの例では、Pub/Sub トピック logs-export-topic が以前に作成された宛先で、この組織に対して gcp_logging_sink_pubsub という名前のシンクが作成されます。シンクにはすべての子プロジェクトが含まれ、特定の監査ログを選択するためのフィルタリングを指定します。
gcloud logging sinks create gcp_logging_sink_pubsub \
pubsub.googleapis.com/projects/compliance-logging-export/topics/logs-export-topic \
--log-filter='logName:"/logs/cloudaudit.googleapis.com" OR \
resource.type:\"gce\" OR \
resource.type=\"gcs_bucket\" OR \
resource.type=\"bigquery_resource\"' \
--include-children \
--organization=your-organization
コマンドの出力は次のようになります。
Created [https://logging.googleapis.com/v2/organizations/your-organization/sinks/gcp_logging_export_pubsub_sink]. Please remember to grant `serviceAccount:gcp-logging-export-pubsub-si@logging-oyour-organization.iam.gserviceaccount.com` Pub/Sub Publisher role to the topic. More information about sinks can be found at /logging/docs/export/configure_export
この API 呼び出しからの戻り値の serviceAccount エントリにおいて、gcp-logging-export-pubsub-si@logging-oyour-organization.iam.gserviceaccount.com という ID がレスポンスに含まれます。この ID は、エクスポート用に作成された Google Cloud サービス アカウントを表します。この ID に宛先トピックに対する公開アクセス権を付与するまで、このシンクからのログエントリのエクスポートは失敗します。詳細については、次のセクションまたはリソースのアクセス権の付与のドキュメントをご覧ください。
Pub/Sub トピックの IAM ポリシー権限を設定する
Pub/Sub パブリッシャー権限を持つ pubsub.googleapis.com/projects/compliance-logging-export/topics/logs-export-topic トピックにサービス アカウント gcp-logging-export-pubsub-si@logging-oyour-organization.iam.gserviceaccount.com を追加することにより、そのトピックに公開する権限がサービス アカウントに付与されます。これらの権限を追加するまで、シンクのエクスポートは失敗します。
サービス アカウントに権限を付与するには、次の操作を行います。
Google Cloud コンソールで、[Cloud Pub/Sub のトピック] ページを開きます。
トピック名を選択します。
[情報パネルを表示] をクリックして、Pub/Sub パブリッシャー権限を選択します。
このフィルタを使用してロギング エクスポートを作成すると、構成対象のプロジェクトの Pub/Sub トピックにログファイルの自動入力が開始されます。Cloud Monitoring の Metrics Explorer を使用すると、トピックによるメッセージの受信を確認できます。次のリソースタイプと指標を使用して、短期間に実行されたメッセージ送信オペレーションの数を確認します。エクスポートが正しく構成されていれば、このスクリーンショットのように、グラフに 1 個以上のアクティビティが表示されます。
- リソースの種類:
pubsub_topic - 指標:
pubsub/topic/send_message_operation_count
Splunk データの取り込みを設定する
オプション A: Pub/Sub を使用して Splunk Dataflow にログをストリーミングする
Pub/Sub to Splunk Dataflow テンプレートを使用して、以前に作成した Pub/Sub サブスクリプションからメッセージを pull し、ペイロードを Splunk HEC イベント形式に変換して Splunk HEC に転送する Dataflow ジョブを作成します。そのため、Splunk HEC エンドポイント URL と HEC トークンが必要です。この URL には Dataflow ジョブのネットワークからアクセスできます。まだ行っていない場合は、Splunk HEC を構成する手順を行います。
複数のワーカー間でのワークロードの同時読み込みと分散に加えて、Dataflow サービスでは、これらのリソースを管理して、Pub/Sub からの既存のメッセージ バックログと現在のワーカーの使用率に基づいてワーカー数の自動スケーリングを行います。
フォールト トレランスの観点から、Pub/Sub to Splunk Dataflow テンプレートでは、ダウンストリーム エンドポイントがダウンした場合やネットワーク接続の問題が発生した場合に、Splunk HEC への再試行（指数バックオフで）を処理します。メッセージ処理エラーが発生した場合にデータが失われないようにするために、これらのメッセージは別の Pub/Sub デッドレター トピックに転送されます。このトピックは、この Dataflow テンプレートを実行する前に作成しておく必要があります。
データを受信するように Splunk HEC エンドポイントが構成されたら、Google Cloud コンソール、Google Cloud CLI、または Dataflow API によって、Pub/Sub から Splunk Dataflow へのパイプラインを実行できます。必要に応じて、JavaScript ユーザー定義関数を適用して、Splunk に転送する前にメッセージ ペイロードを変換することもできます。
次の gcloud コマンドの例では、入力 Pub/Sub サブスクリプション logs-export-subscription で最新バージョンの Pub/Sub to Splunk Dataflow テンプレートを実行します。your-splunk-hec-token と your-splunk-hec-url は、Splunk の HEC トークンとエンドポイントに置き換えます（例: https://splunk-hec-host:8088）。
JOB_NAME=pubsub-to-splunk-$USER-`date +"%Y%m%d-%H%M%S%z"`
gcloud dataflow jobs run $JOB_NAME \
--gcs-location gs://dataflow-templates/latest/Cloud_PubSub_to_Splunk \
--max-workers 2 \
--parameters \
inputSubscription=projects/compliance-logging-export/subscriptions/logs-export-subscription,\
token=your-splunk-hec-token,\
url=your-splunk-hec-url,\
outputDeadletterTopic=projects/compliance-logging-export/topics/splunk-pubsub-deadletter,\
batchCount=10,\
parallelism=8
Cloud Monitoring の Metrics Explorer を使用して、Dataflow パイプラインでメッセージを Splunk に正常に送信していることを確認できます。次のリソースタイプと指標を使用して、短期間に正常に実行された送信イベント数と失敗した可能性があるイベント数を確認します。
- リソースの種類:
dataflow_job - 指標 1:
custom.googleapis.com/dataflow/outbound-successful-events - 指標 1:
custom.googleapis.com/dataflow/outbound-failed-events
テンプレートが正しく構成されていれば、このスクリーンショットのように、グラフに 1 個以上のアクティビティが表示されます。
オプション B: Google Cloud Platform の Splunk アドオンを使用してログを pull する
Google Cloud Platform の Splunk アドオンは、Google Cloud の Pub/Sub トピックとサービス アカウントを使用します。サービス アカウントは、アドオンが Cloud Pub/Sub のサブスクリプションを作成し、ロギング エクスポート トピックからメッセージを取り込むために使用する秘密鍵の生成で使用されます。サービス アカウントがサブスクリプションを作成し、サブスクリプションを含む Pub/Sub プロジェクトのコンポーネントの一覧を作成するには、適切な IAM 権限が必要です。
Google Cloud Platform の Splunk アドオンの設定手順を行います。アドオン手順で作成されたサービス アカウントに roles/pubsub.viewer と roles/pubsub.subscriber の Pub/Sub IAM 権限を付与します。
アドオンの構成後、ロギング エクスポートから取り込んだ Pub/Sub メッセージが Splunk に表示されます。
Cloud Monitoring の Metrics Explorer を使用すると、アドオンのサブスクリプションがメッセージを pull していることを確認できます。次のリソースタイプと指標を使用して、短期間に実行されたメッセージ pull オペレーションの数を確認します。
- リソースの種類:
pubsub_subscription - 指標:
pubsub/subscription/pull_message_operation_count
エクスポートが正しく構成されていれば、このスクリーンショットのように、グラフに 1 個以上のアクティビティが表示されます。
エクスポートされたログの使用
エクスポートされたログが Splunk に取り込まれた後、他のデータソースと同様に Splunk で次のタスクを実行できます。
- ログを検索する。
- 複雑なイベントを関連付ける。
- ダッシュボードに結果を表示する。
次のステップ
- Dataflow を使用して本番環境対応のログのエクスポートを Splunk にデプロイする。
- Splunk Connect で Anthos のログを収集する。
他のエクスポート シナリオを確認する。
Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud Architecture Center を確認します。