SplunkのMachine Data Lakeを試してみた
はじめに
Splunkに取り込むログが増えるほど、「全部をIndexに入れ続けるべきか」という悩みが出てきます。検索やアラートに使うログもあれば、念のため残しておきたいだけのログもあります。
Splunk Cloud Platform の Machine Data Lake（MDL）は、取り込んだログをいったん低コストなオブジェクトストレージ上の raw table に保持し、検索や分析が必要になったものだけを昇格（promotion）して使う機能です。
この記事では、すでにSplunk Cloudへ取り込んでいるAWS CloudTrailのログを raw table に入れ、Analytics table と Splunk index の2種類に昇格して、それぞれの検索結果の違いを確認します。
前提条件
今回の検証は、AWS CloudTrailのログがすでにSplunk Cloudへ取り込まれている環境で行っています。
- 取り込み設定: Data Inputs で、CloudTrailを取り込み済み
- 取り込み構成: CloudTrail → CloudWatch Logs → Amazon Data Firehose → HEC（Splunk）
- MDLの設定前の取り込み先: Splunk index（
index=aws） - 検証環境: Splunk Cloud Platform 10.7
図の下側にある、Universal Forwarder を入れた EC2 は、記事の最後の補足で使います。
Machine Data Lakeを構成する用語
Machine Data Lakeには、独自の概念と用語があります。検証に入る前に、まずこれらの用語を整理します。
データの保持先と昇格
| 用語 | 内容 |
|---|---|
| raw table | 取り込んだデータの保持先。検索に使えるフィールドは host、source、sourcetype、_time、_raw（イベント本文）の5つ |
| 昇格（promotion） | raw table から必要なデータだけを、新しい dataset として切り出すこと。元の raw データは消えない |
| Analytics table | 昇格先の1つ。選んだフィールドで分析検索をする。列指向（Iceberg ベース） |
| Splunk index | 昇格先の1つ。Splunk の検索、ダッシュボード、アラートで使う |
| 静的昇格 / ストリーミング昇格 | 指定した期間のデータを1回だけ昇格する / 開始後に届くデータを継続して昇格する |
この記事では、静的昇格を使います。
raw tableへのデータ取り込み
raw table へのデータ取り込み経路には、Direct routing と Pipeline routing の2つがあります。
| Direct routing | Pipeline routing | |
|---|---|---|
| 振り分ける場所 | 送信元（UF、HEC など）の設定 | Splunk Cloud 側（raw table の landing 定義） |
| 送信元の設定変更 | 必要（宛先の index に raw table を指定） | 不要（既存の取り込み設定のまま） |
| 向いている場面 | 新規のデータソース | すでにSplunk Cloudに届いているデータを、段階的に切り替えたい |
さらに、raw table へ振り分けたデータを、これまで使っていた Splunk index にも残すかどうかを選べます。
| 内容 | |
|---|---|
| MDLのみ | 一致したイベントは raw table にだけ入る |
| dual routing | raw table と、既存の Splunk index の両方に入る |
今回は、すでに取り込み済みのCloudTrailを扱うため、Pipeline routing（MDLのみ） で進めます。Direct routing は、記事の最後に補足として触れます。
検証の全体像
次の流れで進めます。
CloudTrail（取り込み済み）
→ raw table（landing 定義で振り分け）
├ Analytics table へ昇格 → 検索
└ Splunk index へ昇格 → 検索
1. raw tableを作成して、CloudTrailを取り込む
最初に raw table を作成し、Pipeline routing の設定を行います。
データセットの作成を始める
Catalog の「作成」から「データセット」を選びます。
データストアには「Machine Data Lake (MDL)」を選びます。
名前と保持期間を決める（Define dataset）
Define dataset では、次の項目を設定します。
- データセットの名前: 例
test_machine_data_lake - Retention: 1 Year
- Promotion limits
- Max data retention for static promotions: 1 Year
- Max rolling window for streaming promote: 1 Year。ストリーミング昇格で選べる最大のローリングウィンドウで、ウィンドウの外のデータは昇格先から削除される。元の raw table の保持期間には影響しない
※保持期間やPromotionリミットは要件に合わせて設定します
アクセス権限を設定する（Configure permissions）
Configure permissions では、アクセスさせるユーザーやロールを指定します。今回は sc_admin としています。
CloudTrailを振り分ける設定をする（Define data landing）
ここが、Pipeline routing の設定にあたるステップです。Pipeline routing（landing 定義）を使うには、Ingest Processor の初回セットアップ（アクセス申請、サービスアカウントの作成、テナントと Splunk Cloud Platform の接続）が必要です。
Define data landing では、Ingest Processor の process_data パイプラインで、landing 定義を構成します。
Partition に「Divert data to raw table」を選び、条件を sourcetype equals aws:cloudtrail にしています。すでにSplunk Cloudに届いているイベントのうち、sourcetype が aws:cloudtrail のものを raw table へ振り分ける設定です。
今回は「MDLのみ」の設定で検証しました。この設定にすると、一致したCloudTrailのイベントは、これまでの取り込み先である index=aws に流れなくなります。
※raw table と既存の index の両方に残したい場合は、dual routing を使います
内容を確認して作成する（Review）
最後の Review で、設定を確認して「Create Dataset」を押します。
raw tableにCloudTrailが入ったことを確認する
作成した raw table に、CloudTrailのイベントが入りました。sourcetype は aws:cloudtrail です。
2. raw tableを検索してみる
raw table は、index= に raw table の名前を指定して検索します。
index=test_machine_data_lake
なお、raw table は SPL2 でしか検索できませんでした。公式ドキュメントにも、raw 検索は SPL2 で行うと書かれています（Key Machine Data Lake terms）。
先ほどの画面のとおり、表示されるフィールドは host、source、sourcetype、_time、_raw の5つだけです。CloudTrailの eventName や eventSource といった項目は、フィールドとして認識されません。また、結果は「統計情報」タブにだけ出て、「イベント」タブは 0 件になります。
視覚エフェクトも使えないようです。
並び順は保証されない
raw table の検索結果は、時刻順に並ぶとは限りません。2ページ目を見ると、05:20:57 の次が 05:22:23、その次が 05:08:10 になっています。
時刻順に並べたいときは、sort を使います。
index=test_machine_data_lake
| sort _time
_raw の中を検索する
_raw の文字列に対する検索はできます。eventName が ListInstances のイベントを探す例です。
index=test_machine_data_lake _raw="*\"eventName\":\"ListInstances\"*"
5件が見つかりました。フィールドとしては認識されなくても、文字列として絞り込めます。
全件の検索時間
5:00〜6:00 の時間範囲で、全件（747件）を取得する検索を実行しました。ジョブ調査の runDuration は 17.851 秒でした。かなり少ないデータ量での検証だったため、KB、MB単位の検索であればさらに検索時間がかかりそうな予感はします。
ここまでの確認で分かるとおり、raw table は、データ内の文字列検索くらいは可能です。一方で、並び順が保証されず、項目ごとの集計もできませんし、検索スピードも遅いため繰り返し使う検索や分析には向いていないことが分かります。そこで、必要なデータを昇格します。
補足: rexで _raw から抽出して集計する
昇格する前でも、rex で _raw から項目を抽出すれば、集計はできます。eventName ごとの件数を数える例です。
index=test_machine_data_lake
| rex field=_raw /"eventName":"(?<eventName>[^"]+)"/
| stats count() by eventName
eventName が118種類見つかり、AssumeRole が242件で最多でした。ただし、この rex を検索のたびに書く必要があります。頻繁に使う項目は、昇格するときにフィールドにしておくほうが楽です。
3. CloudTrailをAnalytics tableへ昇格する
まず、Analytics table に昇格します。Catalog で raw table を選び、「Promote」を押します。
設定画面では、昇格の種類を4つから選びます。
- 静的な Splunk インデックス
- 静的な分析テーブル
- ストリーミング Splunk インデックス
- ストリーミング分析テーブル
今回は「静的な分析テーブル」を選び、時間範囲を 2026/11/10 の 05:00〜06:00、フィルターを sourcetype = aws:cloudtrail にしました。
次のプレビュー画面で、昇格するデータの内容を確認できます。この時点では、フィールドは host、source、sourcetype、_time、_raw の5つだけです。
Analytics table では、昇格するフィールドを選ぶ必要があります。Actions を追加すると、フィールドの抽出やマスクなどの処理を選べます。
CloudTrailはJSONなので、「Extract JSON fields from _raw」を選びます。すると、フィールドが28個になりました。
最後に、昇格後のデータセット名を test_machine_data_lake_promoted_cloudtrail にして、プロモーションを開始します。
進み具合は、Catalog の「プロモーションジョブ」タブで確認できます。最初は Pending で、しばらくすると「完了」になりました。
昇格後のデータセットの概要です。データストアは Machine Data Lake、種類は mdl_promoted になっています。
4. Analytics tableで検索してみる
Analytics table も、index= に名前を指定して検索します。
index=test_machine_data_lake_promoted_cloudtrail
Analytics table も、raw table と同じく SPL2 でしか検索できませんでした。
747件が見つかりました。raw table と同じく、結果は「統計情報」タブにだけ出て、「イベント」タブは 0 件です。違うのは、昇格時に抽出した項目が、列として並ぶことです。
項目ごとの集計
eventName が Get で始まるイベントを、eventSource ごとに数えます。
index=test_machine_data_lake_promoted_cloudtrail eventName="Get*"
| stats count() by eventSource
13件の結果が出て、s3.amazonaws.com が154件で最多でした。「視覚エフェクト」タブで、棒グラフにもできます。
イベントは表示されない
eventName="Get*" だけで検索すると、184件が見つかります。ただし、「イベント」タブには「結果は見つかりませんでした」と出て、結果は「統計情報」タブに表示されます。
Analytics table は、イベントとして1件ずつ眺める使い方ではなく、集計や分析に向いています。
並び順
Analytics table も、sort を付けないと、時刻順には並びません。12ページ目では、05:49:37 の次が 05:24:51 に戻っています。
| sort _time を付けると、時刻の昇順になります。
全件の検索時間
raw table と同じ条件（時間範囲 5:00〜6:00）で、全件（747件）を取得する検索を実行しました。ジョブ調査の runDuration は 3.519 秒でした。
raw table の 17.851 秒と比べると、昇格した Analytics table のほうが短い時間で検索できています。
5. 同じCloudTrailをSplunk Indexへ昇格する
同じ raw table から、今度は Splunk index へ昇格します。昇格の種類で「静的な Splunk インデックス」を選び、時間範囲とフィルターは同じ条件にしました。
プレビューでは、Analytics table のときのようなフィールド抽出のための Actions の追加は不要です。
データセット名を test_machine_data_lake_promoted_cloudtrail_tsindex にして、プロモーションを開始します。
昇格ジョブが作成され、最初は Pending になります。完了となるまでしばらく待ちます。
6. Splunk Indexで検索してみる
Splunk index も、index= に名前を指定して検索します。
index=test_machine_data_lake_promoted_cloudtrail_tsindex
raw table や Analytics table と違い、Splunk index は SPL でも検索できました。
「イベント」タブに747件のイベントが表示されました。JSONが自動で展開され、eventName や eventSource などの項目が、左のフィールド一覧に並びます。昇格時にフィールドを抽出する操作は、不要でした。
並び順は、時刻の降順（新しい順）です。
全件の検索時間
全件（747件）を取得する検索の runDuration は 0.862 秒でした。
raw table / Analytics table / Splunk index の違い
ここまでの検証で分かった違いをまとめます。
| 項目 | raw table | Analytics table | Splunk index |
|---|---|---|---|
| 集計できる軸 | host / source / sourcetype / _time。_raw 内の項目は rex で抽出すれば可 |
昇格時に抽出したJSON自動認識（28フィールド） | Splunk TA等で自動で抽出された項目 |
| 昇格時のフィールド抽出 | － | 必要（JSON抽出） | 不要 |
| 検索結果の見え方 | 統計情報タブのみ | 統計情報タブと視覚エフェクト | 全て（イベント・パターン・統計情報・視覚エフェクト） |
| 検索言語 | SPL2 のみ | SPL2 のみ | SPL でも検索可 |
| 時間での並び順 | ランダム | ランダム | 降順 |
| 全件（747件）取得の検索時間 | 17.851 秒 | 3.519 秒 | 0.862 秒 |
使い分けの目安は、次のとおりです。
- raw table: データが入っているかの確認や、文字列での絞り込み
- Analytics table: 項目を選んで、集計や分析をしたいとき
- Splunk index: イベントを1件ずつ見たり、監視、ダッシュボードやアラートに使ったりするとき
補足: UFからDirect routingでraw tableへ送る
ここまでは、すでにSplunk Cloudに届いているデータを、Pipeline routing で raw table へ振り分けました。新しくデータソースを追加するときは、送信元の設定で、直接 raw table を宛先にする Direct routing も使えます。
Universal Forwarder（UF）の場合は、入力の index に、raw table のリソース名を指定します。リソース名は、~.federated.<raw table名> の形式です。UFでは、outputs.conf を変更する必要はありません。
今回は、UFの inputs.conf に、次のようなスクリプト入力を設定しました。ausearch で読みやすい形に変換した auditd のログを、rlog.sh で読み取る設定です。
# This script reads the auditd logs translated with ausearch
[script://./bin/rlog.sh]
sourcetype = auditd
source = auditd
interval = 60
disabled = 0
index = ~.federated.test_machine_data_lake
index に、先ほどの raw table のリソース名（~.federated.test_machine_data_lake）を指定しているのがポイントです。この1行で、送信先が raw table になります。
Linux の監査ログ（auditd）をUFから送ったところ、同じ raw table test_machine_data_lake に入りました。
このとき、raw table の landing 定義は、何も変更していません。landing 定義は、CloudTrail を振り分けるための sourcetype equals aws:cloudtrail だけのままです。UFから送った auditd は、landing 定義とは関係なく、送信元の設定だけで raw table に入っています。
つまり、この raw table には、Pipeline routing（CloudTrail）と Direct routing（auditd）の、2つの経路からデータが入っています。
まとめ
Machine Data Lake を、取り込み済みのCloudTrailで試してみました。
まずは raw table に溜めておき、使い道が決まったデータだけを、用途に合わせた昇格先に切り出すという使い方がSplunk上だけで手軽に設定できることが分かりました。
「とりあえず全部Indexへ」ではなく、データごとに保持先と使い方を選べるようになり、Splunkでのデータ戦略がとりやすくなったと感じました。必要なときに、より安価にデータを使いやすくなることも期待できそうです。
Splunkで扱うログが増えて、保持や検索のコストが気になっている方の参考になれば幸いです。
参考リンク
- Get started with Machine Data Lake
- Create a Machine Data Lake raw table
- Choose how to route data to Machine Data Lake
- First-time setup instructions for the Ingest Processor solution
- Prepare a data source for Machine Data Lake
- Machine Data Lake prerequisites
- Onboarding and promoting data with Cisco Data Fabric powered by the Splunk platform（Splunk Lantern）
- Promote data to an analytics table
- Promote data to a Splunk index
- Search Machine Data Lake data from the Catalog
- Data ingestion mechanisms and intervals in Data Manager
- Specific differences between SPL and SPL2
- sort command: Overview, syntax, and usage（SPL2）
- rex command: Overview, syntax, and usage（SPL2）
