Splunkのインデックスって何ぞや

この記事は約15分で読めます。
sponsored link

インデックス (Index)

インデックスとは「イベントを保存するリポジトリ」のことで、ユーザーがサーチを行う際にクエリを発行する対象を指します。(新規インデックスは管理者のみ追加可能)

圧縮生データ(rawdata) vs. 参照インデックス(index files)

インデックス化されたデータは『rawdata』『index files』により構成されています。

  • 圧縮された生データ (rawdata)
  • Raw data を参照するインデックス (index files = tsidx files metadata files)

tsidx (time series index) は「イベント位置を参照するためにユニークな値を紐付けたデータ」のことです。サーチが実行される度にSplunkが tsidx をスキャンし、キーワードに一致するイベントを rawdata から取得します。また tsidx はデータモデルのサマリとしても使われており、個別の tsidx セットを作成することでデータモデルを高速化することもできます。

これらのファイルは年代順にまとまったディレクトリ(buckets)に格納され、ユーザーが設定したスケジュールに応じてアーカイブ化されます。

インデックス化 (Indexing)

インデックス化とは「データをイベントに変換するプロセス」のことで、具体的には以下のステップが実行されることを指します。

  1. 収集したデータサーチ可能なイベントに分割
  2. タイムスタンプの識別/作成
  3. メタフィールドの抽出 (e.g., host, source, sourcetype)
  4. ユーザーが定義したアクションを実行*

(e.g.) カスタムフィールドの指定、機密データのマスキング、キーの書き込み/修正、複数行イベントに対して改行ルールの適用、不要なデータの削除、特定サーバーへのルーティング

バケット (Buckets)

バケットとは「Indexes が保存されるディレクトリ/ファイルのこと」で、データの鮮度に応じて使い分けられます。Hot buckets/Warm buckets では高速なSSD、Cold buckets では低速かつ安価なストレージ (e.g., SAN, NAS) を使うのがベストプラクティスとされています。

① Hot buckets

Hot buckets とは「イベントが最初に格納されるバケット」のことで、デフォルトでは $SPLUNK_DB/db* に『90日』『750MB』『3バケット』まで保存されます。
※ $SPLUNK_DB = $SPLUNK_HOME/var/lib/splunk/defaultdb は、[Settings] > [Server settings] > [General settings] > [Path to Indexes] から確認可能です。

時間や容量がオーバーした (or Indexersが再起動された) 場合 Warm buckets へデータが移行され、バケット名は hot_v1_<id> から db_<newest_time>_<oldest_time>_<id> へ変更されます。
(e.g.) “hot_v1_10” → “db_1231231231_123123000_10”

バケット数は indexes.conf の『maxHotBuckets』で最大10バケットまで設定することが可能です。(バケット数の増加は時間順序を正しくする効果もあります)

② Warm buckets

Warm buckets とは「Hot buckets から移行されたデータを保存するバケット」のことで、デフォルトでは Hot と同じパスに『300バケット』まで保存されます。

時間や容量がオーバーした場合 Cold buckets へデータが移行され、ファイル名はそのまま場所のみ移動します。
※クラスタ構成の場合、バケット名は「db_<newest_time>_<oldest_time>_<id>_<node_id>」となります。

Hot 以外のバケット名は「db_<newest_time>_<oldest_time>_<id>」となっており、サーチ時にSplunkがこのファイル名の時間範囲をもとにイベントを探索します。

③ Cold buckets

Cold buckets とは「Warm buckets から移行された rawdata のみを保存するバケット」のことで、デフォルトでは $SPLUNK_DB/colddb に『約6年』『500GB』まで保存されます。

デフォルトでは時間や容量がオーバーした場合に削除*されますが、Frozen buckets のパスを指定してアーカイブ化 (rawdataのみを保存) することも可能です。
※データの凍結はイベント単位ではなくバケット全体となるため、90日未満のデータが削除されることもあります。

④ Frozen buckets

Frozen buckets とは「Cold buckets でアーカイブ化されたデータを保存するバケット」のことで、ユーザーが指定したパスに保存されます。(デフォルトのパスはありません)

なお Frozen buckets のデータは直接サーチで利用することはできませんが、ファイルを解凍し Thawed buckets へ保存することでサーチで利用できるようになります。

⑤ Thawes buckets

Thawed buckets とは「Frozen buckets を解凍したデータを保存するバケット」のことで、デフォルトでは $SPLUNK_DB/thrawed に保存されます。

rebuild で解凍したデータはライセンスにはカウントされず、将来的に解凍されることもありません。

$SPLUNK_HOME/bin/splunk rebuild <bucket_directory> <index_name>

※古いインデックス/メタデータはSplunkにより自動で削除/再構築されます。

インデックス作成

新規インデックスの作成

作成方法
  • Web:[Settings] > [Indexes] > [New Index]
  • CLI:$SPLUNK_HOME/bin/splunk add index <index_name>
  • indexes.conf の直接編集
インデックスの各項目
項目名 デフォルト値 備考
Index Name 先頭を “/” or “_” で始めたり、
“kvstore” という文字を含めるのは NG。
Index Data Type Events
Home Path $SPLUNK_DB/db Hot/Warm buckets のパス
Cold Path $SPLUNK_DB/colddb Cold buckets のパス
Thawed Path $SPLUNK_DB/swaweddb アーカイブから解凍したバケットのパス
Data Integrity Check Disable ハッシュを計算
Max Size of Entire Index 500 GB Index全体の最大容量
Max Size of Hot/Warm/Cold Buckets auto (750 MB) main のような大きなIndexでは
「auto_high_volume (10 GB)」とする
Frozen Path 期限や容量がオーバーしたら削除 Frozen buckets をアーカイブする時のパス
App Search & Reporting
Tsidx Retention Policy Disable Reduction 定期的に tsidx files を削除するかどうか
Reduce tsidx files older than 7日後 削除の頻度

※指定したパスが存在しなければ新規で作成されます。

複数 Indexes を持つメリット

  • ユーザーのロールに応じたアクセス制御 (e.g., 部署ごとに分離,  機密情報の保護)
  • 様々なポリシーへの対応 (e.g., web は3ヶ月単位で削除,  security は半年でアーカイブ化)
  • サーチの高速化 (e.g., サーチ対象のデータ量を削減)

インデックスタイプ:Events vs. Metrics

  • Events indexes:あらゆるデータに対応するデフォルトのインデックスタイプ。イベントとMetrics indexesの両方が同じ順序で処理される。
  • Metrics indexes:メトリクスデータを大容量・低遅延で扱うための高度に構造化されたインデックスタイプ。Events indexesに入れるよりもパフォーマンスが高速化し、ストレージ利用率も抑えられる。

作成後の編集

作成後のインデックスは [Settings] > [Indexes] から編集できますが、ここでグレーアウトされている箇所は「indexes.conf の直接編集」が必要となります。
※クラスタ構成などでも indexes.conf の直接編集が求められます。

インデックス管理

ホスト名・パス・ディスクスペースの下限

Indexのホスト名、パス、ディスクスペースの下限は[Settings] > [Server Settings] > [General Settings] から設定することができます。

予め構成されたインデックス

予め構成されているインデックスには main, ( _ から始まる)内部インデックス の2種類があります。

  • main:外部データを保存するデフォルトのインデックス。
  • _internal:インデックス自身のログ、メトリクス。
  • _metrics:Metrics data point 形式で保存された内部ログ。
  • _audit:ファイルの変更監視。全ユーザーのサーチ履歴。
  • _introspections:システムパフォーマンス。Splunkリソースの利用率。MC用監視データ。
  • _thefishbuckets:Splunkエンジニアがデータ収集の問題を解析するためのログ。

コストの見積もり

  1. 開発環境下でインデックスから (ある一定期間) データを収集
  2. $SPLUNK_DB/db (Hot/Warm) のデータを MC : [Indexing] > [Indexes and Volumes] > [Index Details: Instance] で監視
  3. ①, ②を比較してコストを見積もる

※ビューの範囲は [All: 全期間], [Snapshot: 直近15分], [Historical: 時系列推移 (期間を指定) ] から選択できます。

データ整合性チェック

Splunkには「インデックス化されたデータのハッシュ値を計算して整合性をチェックする」という機能があり、値はハッシュファイル (e.g. l1Hashes, l2Hash) に保存されるため、後からデータの整合性を確認することができます。
※ Forwarderから転送されるハッシュ計算前のデータは SSL 化により保護してください。

データ整合性チェックは web, CLI ( check-integrity ) から有効化できます。

$SPLUNK_HOME/bin/splunk check-integrity -bucketPath <bucket_path> [-verbose]   #バケット単位で有効化
$SPLUNK_HOME/bin/splunk check-integrity -index <index_name> [-verbose]   #Index単位で有効化

ハッシュファイルを失くしてしまった場合でも CLI ( generate-has-files ) から再生成可能です。

$SPLUNK_HOME/bin/splunk generate-hash-files -bucketPath <bucket_path> [-verbose]   #バケット単位で再生成
$SPLUNK_HOME/bin/splunk generate-hash-files -index <index_name> [-verbose]   #Index単位で再生成

index.conf

index.conf とは「インデックスを定義するファイル」のことで、/var/lib/splunk/indexes とは離れたディレクトリ(/etc/system/local, /etc/apps/<app_name>/local) に存在します。

[index_name]
homePath = /ssd/splunk/marketing/db
coldPath = /var/lib/splunk/marketing/colddb
homePath = /var/lib/splunk/marketing/thaweddb
maxDataSize = auto_high_volume   #10GB
maxTotalDataSizeMB = 102400      #100GB
enableDataIntegrityControl = 0   #整合性チェックOFF
lastChanceIndex = unknown_index  
#存在しないインデックスへイベントが送られた際に"unknown_index"へデータを転送する設定(デフォルトでは空)

バックアップ設定

増分バックアップ

Splunkでは重要なデータ (e.g., conf file, user files) や Warm buckets (+ Cold buckets) の増分バックアップを定期的に取得することが推奨されています。

Hot buckets には常にリアルタイムデータが書き込まれているため、Splunkを停止しない限りバックアップを実行できません。一方、スナップショット (メタデータのキャプチャ) は取得できるので、そちらは定期的に取得されると良いかと思います。
※スナップショットの場合、元データが破損するとデータを復旧させることができません。

フルバックアップ

Indexerのアップグレード前にはIndexerを停止し、Hot/Warm/Cold のフルバックアップを取得することが推奨されています。(増分バックアップで取得していないファイルのみが対象です)
※ファイルが大きすぎる場合はスナップショットのみでOKです。

インデックスの削除

インデックス化されたデータやIndexesを削除したい場合、主に4つの方法があります。
※一度削除したデータは永久に復元できないためSplunkでは推奨されていません。

[方法1] delete を用いてサーチ対象から除外

サーチ画面で delete を用いると「特定のデータをサーチ対象から除外」することができます。ただし、データはIndexesに保存され続けるため、バケットの負荷が軽くなることはありません。

また delete を実行するには “delete_by_keyword” の権限が必要で、デフォルトでは “can_delete” というロールにのみ付与されています。(デフォルトでは管理者にも付与されていません)

index=test_index | delete   #"test_index"という名前のindexesをサーチ対象から除外

[方法2] clean を用いて Indexes 内の全てのイベントを削除

clean を用いると「Indexes内の全てのイベントを削除」することができます。

$SPLUNK_HOME/bin/splunk stop   #indexerの停止

$SPLUNK_HOME/bin/splunk clean eventdate   #全てのindexesのデータを削除(利用には最新の注意を払って下さい)
$SPLUNK_HOME/bin/splunk clean eventdate -index <index_name>   #指定したindexのデータを削除

[方法3] remove を用いて Indexes 自体を削除 / disable で無効化

remove を用いるとIndexes自体を削除でき、disable を使うとデータを消去せずにIndexesを無効化することができます。
※この操作はweb: [Settings] > [Indexxes] や indexes.conf の直接編集でも実行できます。

$SPLUNK_HOME/bin/splunk remove index <index_name>    #指定したindexを削除
$SPLUNK_HOME/bin/splunk disable index <index_name>   #指定したindexを無効化(データは残る)

[方法4] リタイヤメントポリシーに基づく削除

ユーザー自身がアーカイブパスを設定しておらず、”時間の経過や容量がオーバーした” 場合 Cold buckets のIndexesが削除されます。(デフォルトでは約6年間/500GB)

[main]
frozenTimePeriodInSecs = 15552000   #180日後にデータを削除 (容量オーバーの場合は180日未満でも削除されます)

References

Indexes, indexers, and indexer clusters – Splunk Documentation

rawdata file – Splunk Documentation

index files – Splunk Documentation

tsidx file – Splunk Documentation

indexes.conf – Splunk Documentation

About managing indexes – Splunk Documentation

Create custom indexes – Splunk Documentation

Configure index storage – Splunk Documentation

Remove indexes and indexed data – Splunk Documentation

How the indexers store indexes – Splunk Documentation

Archive indexed data – Splunk Documentation

Restore archived indexed data – Splunk Documentation

Back up indexed data – Splunk Documentation

Estimate your storage requirement – Splunk Documentation

Manage data integrity- Splunk Documentation

Non-clustered bucket issues – Splunk Documentation