Ingest Processor for Observability Cloud

Author Tim Hard

インフラストラクチャとアプリケーション環境がますます複雑になるにつれて、それらが生成するデータ量は大幅に増加し続けています。このデータ量と種類の増加により、実用的なインサイトを得ることが困難になり、問題の特定やトラブルシューティングの効率に影響を与える可能性があります。さらに、このデータを保存してアクセスするコストは急上昇する可能性があります。多くのデータソース、特にログとイベントは、システム運用への重要な可視性を提供します。しかし、ほとんどの場合、効果的な監視とアラートに実際に必要なのは、これらの膨大なログからのわずかな詳細情報のみです。

一般的な課題:

  • インフラストラクチャとアプリケーション環境の複雑性の増加
  • これらの環境から生成されるデータ量の大幅な増加
  • 大量のデータから実用的なインサイトを得ることの困難さ
  • 膨大なデータの保存とアクセスに関連する高いコスト
  • ログとイベントは重要な可視性を提供するが、多くの場合、必要な詳細情報はわずか

これらの課題に対処するために、Splunk Ingest Processorは強力な新機能を提供します:ログイベントをメトリクスに変換する機能です。メトリクスは保存と処理がより効率的であり、問題の迅速な特定を可能にし、それによって平均検出時間(MTTD)を短縮します。元のログやイベントを保持する必要がある場合は、S3などの安価なストレージソリューションに保存できるため、データ取り込みと検索に必要な計算の全体的なコストを削減できます。

ソリューション:

  • 可能な場合はログイベントをメトリクスに変換する
  • 必要に応じて元のログまたはイベントを安価なストレージソリューションに保持する
  • 保持されたログへのアクセスと分析にフェデレーテッド検索を活用する

成果:

  • メトリクスはより効率的に保存および処理される
  • 問題のより迅速な特定により、平均検出時間(MTTD)を短縮
  • データ取り込みと計算の全体的なコストの削減
  • 監視効率とリソース最適化の向上
  • 運用コストを削減しながらシステム運用への高い可視性を維持

このワークショップでは、Ingest ProcessorとSplunk Observability Cloudを使用して、上記で説明した課題にどのように対処できるかを実際に体験する機会があります。

Tip

このワークショップを進める最も簡単な方法は以下を使用することです:

  • このページの右上にある左右の矢印(< | >
  • キーボードの左(◀️)および右(▶️)カーソルキー
Last Modified 2026/02/13

Ingest Processor for Observability Cloudのサブセクション

はじめに

この テクニカル なSplunk Observability Cloud向けIngest Processor1 ワークショップでは、Splunk Enterprise CloudでIngest Processorを実際に操作する機会があります。

ワークショップモジュールを簡素化するために、事前設定されたSplunk Enterprise Cloudインスタンスが提供されます。

このインスタンスは、Ingest Processorパイプラインを作成するためのすべての要件が事前に設定されています。

このワークショップでは、Ingest Processorを使用して充実したログをメトリクスに変換し、それらのメトリクスをSplunk Observability Cloudに送信するメリットを紹介します。このテクニカルワークショップを終える頃には、Splunk Enterprise CloudにおけるIngest Processorの主要な機能と能力、およびIngest Processorパイプライン内の宛先としてSplunk Observability Cloudを使用する価値について十分に理解できるようになります。

事前設定された Splunk Enterprise Cloud インスタンスにアクセスする方法については、以下の手順を参照してください。

Splunk Ingest Processor Architecture Splunk Ingest Processor Architecture


  1. Ingest Processor は、Splunk Cloud Platformデプロイメント内で動作するデータ処理機能です。Ingest Processorを使用して、データフローの設定、データ形式の制御、インデックス作成前の変換ルールの適用、および宛先へのルーティングを行います。 ↩︎

Last Modified 2026/02/13

1. はじめにのサブセクション

ワークショップ環境への接続方法

  1. Splunk Enterprise CloudインスタンスのURLを取得する方法
  2. Splunk Observability Cloudワークショップ組織にアクセスする方法

1. Splunk Cloud インスタンス

このワークショップ全体で使用される3つのインスタンスが、すでにプロビジョニングされています:

  1. Splunk Enterprise Cloud
  2. Splunk Ingest Processor (SCS Tenant)
  3. Splunk Observability Cloud

Splunk Enterprise CloudとIngest Processorインスタンスは Splunk Show でホストされています。ワークショップに招待された場合、Splunk Show のイベントへの招待メールを受け取っているはずです。または、ワークショップの開始時にイベントへのリンクが提供されます。

splunk.com の認証情報を使用してSplunk Showにログインしてください。このワークショップのイベントが表示されるはずです。イベントを開いて、Splunk CloudおよびIngest Processorインスタンスの詳細を確認してください。

Note

Splunk Showイベントの詳細に記載されている User Id をメモしてください。この番号は、Kubernetesデータの検索とフィルタリングに使用する sourcetype に含まれます。これは共有環境であるため、他の参加者のデータに影響を与えないよう、提供された参加者番号のみを使用してください。

Splunk Show Instance Information Splunk Show Instance Information

2. Splunk Observability Cloud インスタンス

Splunk Observability Cloudワークショップ組織にアクセスするためのメールも受け取っているはずです(スパムフォルダを確認する必要があるかもしれません)。メールを受け取っていない場合は、ワークショップのインストラクターにお知らせください。環境にアクセスするには、Join Now ボタンをクリックしてください。

Splunk Observability Cloud Invitation Splunk Observability Cloud Invitation

Important

ワークショップ開始時刻前にイベントにアクセスした場合、インスタンスがまだ利用できない可能性があります。ご心配なく、ワークショップが始まると提供されます。

さらに、Splunk Observability Cloudワークショップ組織に招待されています。招待には環境へのリンクが含まれています。まだSplunk Observability Cloudアカウントをお持ちでない場合は、作成を求められます。すでにお持ちの場合は、インスタンスにログインすると、利用可能な組織にワークショップ組織が表示されます。

Last Modified 2026/02/13

Ingest Processor の仕組み

システムアーキテクチャ

Ingest Processorサービスの主要コンポーネントには、Ingest Processorサービスとデータ処理をサポートするSPL2パイプラインが含まれます。以下の図は、Ingest Processorソリューションのコンポーネントがどのように連携するかの概要を示しています:

Splunk Ingest Processor Architecture Splunk Ingest Processor Architecture

Ingest Processor サービス

Ingest Processorサービスは、Splunkがホストするクラウドサービスです。これはデータ管理エクスペリエンスの一部であり、さまざまなデータ取り込みと処理のユースケースに対応するサービスセットです。

Ingest Processorサービスを使用して、以下のことができます:

  • 各Ingest Processorが受信したデータをどのように処理してルーティングするかを決定するSPL2パイプラインを作成して適用する
  • 処理したいデータの種類を識別し、Ingest Processorがそのデータを個別のイベントに分割およびマージする方法を決定するソースタイプを定義する
  • Ingest Processorが処理済みデータを送信する宛先への接続を作成する
パイプライン

パイプラインは、SPL2で記述されたデータ処理命令のセットです。パイプラインを作成する際、どのデータを処理するか、どのように処理するか、結果をどこに送信するかを指定する専用のSPL2ステートメントを記述します。パイプラインを適用すると、Ingest Processorはそれらの命令を使用して、Splunkフォワーダー、HTTPクライアント、ロギングエージェントなどのデータソースから受信したすべてのデータを処理します。

各パイプラインは、Ingest Processorが受信するすべてのデータのサブセットを選択して処理します。たとえば、受信データからソースタイプ cisco_syslog のイベントを選択し、Splunk Cloud Platformの指定されたインデックスに送信するパイプラインを作成できます。この選択されたデータのサブセットはパーティションと呼ばれます。詳細については、Partitions を参照してください。

Ingest Processorソリューションは、IngestProcessor プロファイルの一部であるコマンドと関数のみをサポートしています。Ingest Processor用のパイプラインを記述するために使用できる特定のSPL2コマンドと関数の詳細については、Ingest Processor pipeline syntax を参照してください。IngestProcessor プロファイルが他のSPL2プロファイルと比較して異なるコマンドと関数をどのようにサポートするかの概要については、SPL2 Search Reference の以下のページを参照してください:

Last Modified 2026/02/13

Ingest Pipeline の作成

シナリオ概要

このシナリオでは、組織のSplunk Enterprise Cloud環境の管理を担当するSplunk管理者の役割を担います。最近、社内のアプリケーションチームと協力して、重要なマイクロサービスアプリケーションを監視するために、OpenTelemetryを使用してSplunk APMとInfrastructure MonitoringでKubernetes環境を計装しました。

Kubernetes環境からのログも収集され、Splunk Enterprise Cloudに送信されています。これらのログには以下が含まれます:

  • Podログ(アプリケーションログ)
  • Kubernetes Events
  • Kubernetes Clusterログ
    • Control Plane Nodeログ
    • Worker Nodeログ
    • Auditログ

Splunk管理者として、収集しているデータが最適化されていることを確認し、可能な限り効率的な方法で分析できるようにしたいと考えています。このアプローチを採用することで、トラブルシューティングが加速され、ライセンスの効率的な利用が確保されます。

これを達成する1つの方法は、Ingest Processorを使用して充実したログをメトリクスに変換し、それらのメトリクスの宛先としてSplunk Observability Cloudを使用することです。これにより、ログの収集がより効率的になるだけでなく、新しく作成されたメトリクスをSplunk Observabilityで使用できるようになり、Splunk APMデータ(トレース)やSplunk Infrastructure Monitoringデータと相関させて、追加のトラブルシューティングコンテキストを提供できます。Splunk Observability Cloudはストリーミングメトリクスパイプラインを使用しているため、メトリクスに対してリアルタイムでアラートを設定でき、問題の特定を高速化できます。さらに、Metrics Pipeline Management機能を使用して、集約、不要なフィールドの削除、重要度の低いまたは不要なメトリクスのアーカイブによってデータをさらに最適化できます。

次のステップでは、Kubernetes AuditログをObservability Cloudに送信されるメトリクスに変換するIngest Processor Pipelineを作成します。

Last Modified 2026/02/13

3. Ingest Pipeline の作成のサブセクション

Splunk Cloud へのログイン

このセクションでは、Kubernetes AuditログをSplunk Observability Cloudワークショップ組織に送信されるメトリクスに変換するIngest Pipelineを作成します。開始する前に、Splunk Showイベントの詳細に記載されているSplunk CloudおよびIngest Processor SCS Tenant環境にアクセスする必要があります。

前提条件: Splunk Enterprise Cloudへのログイン

1. Splunk Showイベントの詳細に記載されている Ingest Processor Cloud Stack URLを開きます。

Splunk Cloud Instance Details Splunk Cloud Instance Details

2. Connection infoで Stack URL リンクをクリックして、Splunk Cloudスタックを開きます。

Splunk Cloud Connection Details Splunk Cloud Connection Details

3. admin ユーザー名とパスワードを使用してSplunk Cloudにログインします。

Splunk Cloud Login Splunk Cloud Login

4. ログイン後、プロンプトが表示されたら、利用規約に同意して OK をクリックします。

Splunk Cloud Login Splunk Cloud Login

5. Splunk Showイベントの詳細に戻り、Ingest Processor SCS Tenantを選択します。

Ingest Processor Connection Details Ingest Processor Connection Details

6. Console URL をクリックして Ingest Processor SCS Tenant にアクセスします。

Note

Single Sign-On (SSO) Splunk Data Managementサービス(‘SCS Tenant’)とSplunk Cloud環境の間でSingle Sign-on (SSO) が設定されているため、すでにSplunk Cloudスタックにログインしている場合は、Splunk Data Managementサービスにも自動的にログインされます。認証情報の入力を求められた場合は、Splunk ShowイベントのSplunk Cloud Stackに記載されている認証情報を使用してください(‘Splunk Cloud Stack’ セクションに記載されています)。

Last Modified 2026/02/13

Kubernetes Audit ログの確認

このセクションでは、収集されているKubernetes Auditログを確認します。イベントが非常に充実していることがわかります。これにより、チャート作成が非効率になる可能性があります。これに対処するために、Ingest ProcessorでIngest Pipelineを作成し、これらのイベントをSplunk Observability Cloudに送信されるメトリクスに変換します。これにより、イベントをより効率的にチャート化し、Splunk Observability Cloudのリアルタイムストリーミングメトリクスを活用できるようになります。

演習: Ingest Pipelineの作成

1. Splunk Showワークショップの詳細に記載されているURLを使用して、Ingest Processor Cloud Stack インスタンスを開きます。

2. AppsSearch and Reporting に移動します。

Search and Reporting Search and Reporting

3. 検索バーに、以下のSPL検索文字列を入力します。

Note

USER_ID をSplunk Showインスタンス情報に記載されているUser IDに置き換えてください。

### Replace USER_ID with the User ID provided in your Splunk Show instance information
index=main sourcetype="kube:apiserver:audit:USER_ID"

4. Enter を押すか、緑色の虫眼鏡をクリックして検索を実行します。

Kubernetes Audit Log Kubernetes Audit Log

Note

これで、環境のKubernetes Auditログが表示されるはずです。イベントがかなり充実していることに注目してください。利用可能なフィールドを探索し、どの情報がメトリクスとディメンションの良い候補になるか考え始めてください。自問してください:どのフィールドをチャート化したいか、それらのフィールドをどのようにフィルタリング、グループ化、または分割したいか?

Last Modified 2026/02/13

Ingest Pipeline の作成

このセクションでは、Kubernetes AuditログをSplunk Observability Cloudワークショップ組織に送信されるメトリクスに変換するIngest Pipelineを作成します。

演習: Ingest Pipelineの作成

1. Splunk Showイベントで提供された接続情報を使用して、Ingest Processor SCS Tenant を開きます。

Launch Splunk Cloud Platform Launch Splunk Cloud Platform

Note

Ingest Processor SCS Tenant を開いた際、ウェルカムページに移動した場合は、Splunk Cloud Platform の下にある Launch をクリックして、Ingest Pipelineを設定するData Managementページに移動してください。

Launch Splunk Cloud Platform Launch Splunk Cloud Platform

2. Splunk Data Managementコンソールから PipelinesNew pipelineIngest Processor pipeline を選択します。

New Ingest Processor Pipeline New Ingest Processor Pipeline

3. Ingest Processor設定ページの Get started ステップで、Blank Pipeline を選択し、Next をクリックします。

Blank Ingest Processor Pipeline Blank Ingest Processor Pipeline

4. Ingest Processor設定ページの Define your pipeline’s partition ステップで、Partition by sourcetype を選択します。= equals Operatorを選択し、値として kube:apiserver:audit:USER_ID を入力します(USER_IDを割り当てられたUser IDに置き換えてください)。Apply をクリックします。

Add Partition Add Partition

5. Next をクリックします。

6. Ingest Processor設定ページの Add sample data ステップで、Capture new snapshot を選択します。Snapshot nameに k8s_audit_USER_ID と入力し(USER_IDを割り当てられたUser IDに置き換えてください)、Capture をクリックします。

Capture Snapshot Capture Snapshot

7. 新しく作成したスナップショット(k8s_audit_USER_ID)が選択されていることを確認し、Next をクリックします。

Configure Snapshot Sourcetype Configure Snapshot Sourcetype

8. Ingest Processor設定ページの Select a metrics destination ステップで、show_o11y_org を選択します。Next をクリックします。

Metrics Destination Metrics Destination

9. Ingest Processor設定ページの Select a data destination ステップで、splunk_indexer を選択します。Specify how you want your events to be routed to an index の下で、Default を選択します。Done をクリックします。

Event Routing Event Routing

10. Pipeline search field で、デフォルトの検索を以下に置き換えます。

Note

メトリクス名の UNIQUE_FIELD を、Observability Cloud でメトリクスを識別するために使用する一意の値(イニシャルなど)に置き換えてください。

/*A valid SPL2 statement for a pipeline must start with "$pipeline", and include "from $source" and "into $destination".*/
/* Import logs_to_metrics */
import logs_to_metrics from /splunk/ingest/commands
$pipeline =
| from $source
| thru [
        //define the metric name, type, and value for the Kubernetes Events
        //
        // REPLACE UNIQUE_FIELD WITH YOUR INITIALS
        //
        | logs_to_metrics name="k8s_audit_UNIQUE_FIELD" metrictype="counter" value=1 time=_time
        | into $metrics_destination
    ]
| eval index = "kube_logs"
| into $destination;
SPL2が初めてですか?

SPL2クエリが行っていることの内訳は以下の通りです:

  • まず、Kubernetesイベントをメトリクスに変換するために使用される組み込みの logs_to_metrics コマンドをインポートしています。
  • 右側に表示されている、kube:apiserver:audit sourcetypeからの任意のイベントであるソースデータを使用しています。
  • 次に、thru コマンドを使用して、ソースデータセットを次のコマンド(この場合は logs_to_metrics)に書き込みます。
  • メトリクス名(k8s_audit)、メトリクスタイプ(counter)、値、タイムスタンプがすべてメトリクスに提供されていることがわかります。イベントが発生した回数をカウントしたいため、このメトリクスには値として1を使用しています。
  • 次に、into $metrics_destintation コマンドを使用してメトリクスの宛先を選択します。これはSplunk Observability Cloud組織です。
  • 最後に、生のログイベントを別の宛先(この場合は別のインデックス)に送信できるため、アクセスが必要になった場合に保持されます。

11. 右上隅の Preview ボタン Preview Button Preview Button をクリックするか、CTRL+Enter(MacではCMD+Enter)を押します。Previewing $pipeline ドロップダウンから $metrics_destination を選択します。Splunk Observability Cloudに送信されるメトリクスのプレビューが表示されていることを確認します。

Preview Pipeline Preview Pipeline

12. 右上隅の Save pipeline ボタン Save Pipeline Button Save Pipeline Button をクリックします。パイプライン名に Kubernetes Audit Logs2Metrics USER_ID と入力し、Save をクリックします。

Save Pipeline Dialog Save Pipeline Dialog

13. 保存をクリックすると、新しく作成したパイプラインを適用するかどうか尋ねられます。Yes, apply をクリックします。

Apply Pipeline Dialog Apply Pipeline Dialog

Note

Ingest Pipelineは現在Splunk Observability Cloudにメトリクスを送信しているはずです。次のセクションで再び使用するため、このタブを開いたままにしておいてください。

次のステップでは、Splunk Observability Cloudで作成したメトリクスを表示して、パイプラインが動作していることを確認します。

Last Modified 2026/02/13

Observability Cloud でのメトリクス確認

Kubernetes Auditログをメトリクスに変換してSplunk Observability Cloudに送信するIngest Pipelineが設定されたので、メトリクスが利用可能になっているはずです。メトリクスが収集されていることを確認するには、以下の手順を完了してください:

演習: Splunk Observability Cloudでのメトリクス確認

1. ワークショップ用に招待された Splunk Observability Cloud 組織にログインします。右上隅の + アイコン → Chart をクリックして、新しいチャートを作成します。

Create New Chart Create New Chart

2. 新しく作成したチャートの Plot Editor で、Ingest Pipeline の設定時に使用したメトリクス名を入力します。

Review Metric Review Metric

Info

Ingest Pipelineで作成したメトリクスが表示されるはずです。次のセクションで再び使用するため、このタブを開いたままにしておいてください。

次のステップでは、Ingest Pipelineを更新してメトリクスにディメンションを追加し、アラートとトラブルシューティングのための追加コンテキストを得られるようにします。

Last Modified 2026/02/13

パイプラインの更新とメトリクスの可視化

コンテキストの重要性

前のセクションでは、生のKubernetes Auditログを確認し、それらをメトリクスに変換してSplunk Observability Cloudに送信するIngest Processor Pipelineを作成しました。

このパイプラインが定義されたことで、Splunk Observability Cloudで新しいメトリクスを収集しています。これは素晴らしいスタートですが、特定の期間におけるKubernetes Auditイベントの総数を示す単一のメトリクスしか表示されません。イベントタイプ、ユーザー、レスポンスステータスなどでメトリクスを分割できるようにディメンションを追加すると、はるかに価値が高くなります。

このセクションでは、Ingest Processor Pipelineを更新して、収集されているメトリクスにKubernetes Auditログからの追加ディメンションを含めます。これにより、Auditログの特定の側面をさらにフィルタリング、グループ化、可視化、アラート設定できるようになります。メトリクスを更新した後、ログに関連付けられたさまざまなタイプのアクションのステータスを示す新しいダッシュボードを作成します。

Last Modified 2026/02/13

4. パイプラインの更新とメトリクスの可視化のサブセクション

Ingest Pipeline の更新

演習: Ingest Pipelineの更新

1. 前のステップで作成したIngest Pipelineの設定ページに戻ります。

Ingest Pipeline Ingest Pipeline

2. 生のKubernetes Auditログからメトリクスにディメンションを追加するには、パイプライン用に作成したSPL2クエリの logs_to_metrics 部分を以下に置き換えて更新します:

Note

メトリクス名フィールド(name="k8s_audit_UNIQUE_FIELD")を、元のパイプラインで指定した名前に更新してください。

| logs_to_metrics name="k8s_audit_UNIQUE_FIELD" metrictype="counter" value=1 time=_time dimensions={"level": _raw.level, "response_status": _raw.responseStatus.code, "namespace": _raw.objectRef.namespace, "resource": _raw.objectRef.resource, "user": _raw.user.username, "action": _raw.verb}
Note

SPL2クエリの dimensions フィールドを使用して、生のイベントからのディメンションをSplunk Observability Cloudに送信されるメトリクスに追加できます。この場合、イベントのレスポンスステータス、名前空間、Kubernetesリソース、ユーザー、およびverb(実行されたアクション)を追加しています。これらのディメンションを使用して、より詳細なダッシュボードとアラートを作成できます。

Splunk Observability Cloudでコンテキスト伝播と関連コンテンツを活用できるように、サービス全体で共通のタグを追加することを検討してください。

更新されたパイプラインは以下のようになります:

/*A valid SPL2 statement for a pipeline must start with "$pipeline", and include "from $source" and "into $destination".*/
/* Import logs_to_metrics */
import logs_to_metrics from /splunk/ingest/commands
$pipeline =
| from $source
| thru [
        //define the metric name, type, and value for the Kubernetes Events
        //
        // REPLACE UNIQUE_FIELD WITH YOUR INITIALS
        //
        | logs_to_metrics name="k8s_audit_UNIQUE_FIELD" metrictype="counter" value=1 time=_time dimensions={"level": _raw.level, "response_status": _raw.responseStatus.code, "namespace": _raw.objectRef.namespace, "resource": _raw.objectRef.resource, "user": _raw.user.username, "action": _raw.verb}
        | into $metrics_destination
    ]
| eval index = "kube_logs"
| into $destination;

3. 右上隅の Preview ボタン Preview Button Preview Button をクリックするか、CTRL+Enter(MacではCMD+Enter)を押します。Previewing $pipeline ドロップダウンから $metrics_destination を選択します。Splunk Observability Cloudに送信されるメトリクスのプレビューが表示されていることを確認します。

Ingest Pipeline Dimensions Ingest Pipeline Dimensions

4. プレビューテーブルのdimensions列にディメンションが表示されていることを確認します。テーブルをクリックすると、dimensionsオブジェクト全体を表示できます。

Ingest Pipeline Dimensions Review Ingest Pipeline Dimensions Review

5. 右上隅の Save pipeline ボタン Save Pipeline Button Save Pipeline Button をクリックします。「You are editing an active pipeline」モーダルで Save をクリックします。

Save Updated Pipeline Save Updated Pipeline

Note

このパイプラインはすでにアクティブであるため、行った変更はすぐに有効になります。追加したディメンションを使用して、メトリクスは複数のメトリクス時系列に分割されるはずです。

次のステップでは、Kubernetes Auditイベントからの異なるディメンションを使用して可視化を作成します。

Last Modified 2026/02/13

Kubernetes Audit イベントメトリクスの可視化

メトリクスにディメンションが追加されたので、イベントの verb ディメンションを使用して、さまざまなKubernetesアクションの健全性を示すチャートを作成します。

演習: Kubernetes Auditイベントメトリクスの可視化

1. 前のセクションで作成したチャートを閉じた場合は、右上隅の + アイコン → Chart をクリックして、新しいチャートを作成します。

Create New Chart Create New Chart

2. 新しく作成したチャートの Plot Editor で、メトリクス名フィールドに k8s_audit* と入力します。ここでワイルドカードを使用して、取り込まれているすべてのメトリクスを表示できるようにします。

Review Metric Review Metric

3. 1つから多くのメトリクスへの変化に注目してください。これは、パイプラインを更新してディメンションを含めた時点からの変化です。このメトリクスが利用可能になったので、アクションにエラーが関連付けられているかどうかを示すようにチャートを調整しましょう。

Metric Timeseries Metric Timeseries

まず、response_status フィールドで利用可能なHTTPレスポンスコードを使用して、成功しなかったKubernetesイベントのみにフィルタリングします。レスポンスコードが 409(競合を示す、たとえばすでに存在するリソースを作成しようとした場合)または 503(リクエストに対してAPIが応答しなかった場合)のイベントのみが必要です。

4. チャートのプロットエディタで Add filter をクリックし、フィールドに response_status を使用し、値として 409.0503.0 を選択します。

次に、resourceaction、および response status でグループ化されたイベントの総数を計算する関数をチャートに追加します。これにより、どのアクションと関連するリソースにエラーがあったかを正確に確認できます。これで、成功しなかったKubernetesイベントのみを見ています。

5. Add analyticsSumSum:Aggregation をクリックし、Group by フィールドに resourceaction、および response_status を追加します。

Add Metric Filters Add Metric Filters

6. 上部のボタンにあるチャートタイプを使用して、チャートを heatmap に変更します。Plot editor の隣にある Chart options をクリックします。Group by セクションで response_status を選択し、次に action を選択します。Color thresholdAuto から Fixed に変更します。青い + button をクリックして、別のしきい値を追加します。Down arrow を Yellow に、Middle を orange に変更します。Up arrow は red のままにします。middle threshold に 5 を、upper threshold に 20 を入力します。

Configure Thresholds Configure Thresholds

7. チャートの右上隅にある青い Save as… Preview Button Preview Button ボタンをクリックします。チャートの名前を入力します(例:Kubernetes Audit Logs - Conflicts and Failures)。

Chart Name Chart Name

8. Choose a dashboardNew dashboard を選択します。

New Dashboard New Dashboard

9. 後で簡単に見つけられるように、イニシャルを含むダッシュボード名を入力します。Save をクリックします。

New Dashboard Name New Dashboard Name

10. 作成した新しいダッシュボードが選択されていることを確認し、Ok をクリックします。

Save New Dashboard Save New Dashboard

これで、作成したチャートを含む新しいKubernetes Audit Eventsダッシュボードに移動するはずです。Kubernetesクラスターで実行されているアプリケーションからのアプリケーションエラーとレスポンスタイム、またはpod phase、podメモリ使用率などの他のKubernetesメトリクスなど、環境内の他のメトリクスから新しいチャートを追加できます。これにより、クラスターイベントからアプリケーションの健全性まで、Kubernetes環境の相関ビューが得られます。

Audit Dashboard Audit Dashboard

チャートの可視化ボックスの右上にある3つのドット ... を使用して、このチャートのコピーを作成します。

Copy chart button Copy chart button

UIの右上にある + アイコンを使用して、作業中の同じダッシュボードに貼り付けます。

Paste chart into dashboard Paste chart into dashboard

貼り付けたチャートをクリックして、可視化を Column チャートに変更します。

Change to column chart visualization Change to column chart visualization

SUMを resourcenamespace のみに変更します(フィルターは問題のあるコードのみにフィルタリングします)。

Group chart by resource and namespace Group chart by resource and namespace

Chart optionsでタイトルを Kubernetes Audit Logs - Conflicts by Namespace に変更します。

Change chart title Change chart title

Save をクリックして閉じます。

Save and close chart Save and close chart

演習: Kubernetes Auditログに基づくディテクターの作成

Conflicts by Namespaceチャートで、小さなベルアイコンをクリックし、New detector from chartを選択します。

Bell icon to create detector Bell icon to create detector

名前を選択し、Create alert rule をクリックします。

Enter name for alert rule Enter name for alert rule

Alert conditionで Static Threshold をクリックし、Proceed to Alert Settings をクリックします。

Select static threshold condition Select static threshold condition

Threshold20 を入力します。

Enter threshold value Enter threshold value

このアラートの受信者は選択しないので、Activate をクリックし、Activate Alert RuleSave を選択します。

Activate alert rule and save Activate alert rule and save

右上の Save を最後にもう一度クリックして、ディテクターを保存します。

Final save for detector Final save for detector

ダッシュボードに戻ると、チャートに関連付けられたディテクターが、チャート上の点灯したベルアイコンで示されているのが確認できます。

Detector bell icon on chart Detector bell icon on chart

演習: Splunk Cloud - Dashboard Studioで時系列データを可視化する

時系列メトリクスがSplunk Observability Cloudデータストアに取り込まれたので、Splunk Cloudでこれらの時系列メトリクスを簡単に可視化できます!

Splunk Cloudインスタンスで Dashboards に移動し、Create New Dashboard を選択します。

Create new dashboard in Splunk Cloud Create new dashboard in Splunk Cloud

ダッシュボードのタイトル、権限、Dashboard Studio を選択し、任意のLayout Modeを選択します。 Create をクリックします。

Dashboard title and layout options Dashboard title and layout options

Dashboard Studioでチャートアイコンをクリックし、Column を選択します。

Select column chart in Dashboard Studio Select column chart in Dashboard Studio

Select data sourceCreate splunk observability cloud metric search を選択します。

Choose observability cloud metric search as data source Choose observability cloud metric search as data source

新しいデータソースの名前を選択し、Search for metric or metadata の下にある Content Import リンクをクリックします。

チャートのURLをコピーして Content URL フィールドに貼り付けます。

Paste chart URL and import Paste chart URL and import

Import をクリックします。

Chart imported to dashboard Chart imported to dashboard

Chart visible in dashboard Chart visible in dashboard

チャートのサイズをダッシュボードに合わせて調整します。

Resize chart in dashboard Resize chart in dashboard

チャートの Configuration の右側にある Interactions を展開し、Add Interaction をクリックします。

Expand interactions and add interaction Expand interactions and add interaction

Splunk ObservabilityのダッシュボードからURLをコピーします。

Apply interaction settings Apply interaction settings

On clickLink to custom URL を選択し、ソースデータに簡単に戻れるようにSplunk Observability CloudのダッシュボードのURLを追加します。 また、使いやすいナビゲーションのために Open in new tab を選択します。

Interaction added Interaction added

右上の Save をクリックしてダッシュボードを保存します。

Save dashboard in Splunk Cloud Save dashboard in Splunk Cloud

チャートのColumnまたは名前をハイライトしてクリックします。

Click column or name in chart Click column or name in chart

Splunk Observabilityに戻ることが通知されます。Continue をクリックします。

Continue navigation to Splunk Observability Continue navigation to Splunk Observability

これで、Splunk Cloudから対応するSplunk Observabilityダッシュボードに戻りました。

Last Modified 2026/02/13

まとめ

このワークショップでは、Splunk Ingest Pipelines を使用して詳細なログイベントを実用的なメトリクスに変換することで、Kubernetesログ管理を最適化するプロセス全体を体験しました。まず、Kubernetes Auditログをメトリクスに効率的に変換するパイプラインを定義し、重要な情報を保持しながらデータ量を大幅に削減しました。次に、生のログイベントが長期保持とより深い分析のためにS3に安全に保存されることを確認しました。

Kubernetes Audit Event Kubernetes Audit Event

次に、生のイベントから主要なディメンションを追加してこれらのメトリクスを強化する方法を示し、特定のアクションとリソースにドリルダウンできるようにしました。エラーに焦点を当てるためにメトリクスをフィルタリングし、リソースとアクションごとに分類するチャートを作成しました。これにより、問題が発生している場所をリアルタイムで正確に特定できるようになりました。

Ingest Pipeline Ingest Pipeline

Splunk Observability Cloud のリアルタイムアーキテクチャにより、これらのメトリクスは問題が検出された瞬間にアラートをトリガーでき、平均検出時間(MTTD)を大幅に短縮できます。さらに、このチャートを新規または既存のダッシュボードに簡単に保存して、重要なメトリクスの継続的な可視性と監視を確保する方法を示しました。

Audit Dashboard Audit Dashboard

このアプローチの価値は明確です:Ingest Processor を使用してログをメトリクスに変換することで、データ処理を効率化し、ストレージコストを削減するだけでなく、Splunk Observability Cloud を使用してリアルタイムで問題を監視し対応する能力も得られます。これにより、コンプライアンスやより深い分析のために元のログを保持してアクセスする能力を維持しながら、問題解決の高速化、システム信頼性の向上、およびより効率的なリソース利用が実現します。

Happy Splunking!

Dancing Buttercup Dancing Buttercup