データ収集のあれこれ【Splunk】

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

収集可能なデータ

Splunkでは『web』『CLI』『Apps/Add-on』『inputs.conf』などを用いて、あらゆるデータに接続することが可能です。以下、代表的な5つの収集方法となります。

収集方法 データの説明
Files and directory ローカルのファイル/ディレクトリ sales.csv, /etc/system/server.log
Network events ネットワークポートから収集したイベント syslog-ng, application (over TCP/UDP)
Windows data Windowsサーバーのログ Windows Event Log, Performance Monitoring
HTTP events HECで収集したHTTPイベント
Script outputs スクリプトを実行した結果 APIs, message queue, web data

内部フィールド

Indexerにイベントを取り込んだ時点で『_raw』『_time』『_indextime (非表示)』『_cd (非表示)』『_bkt (非表示)』が内部フィールドとして取得されます。
※ _indextime, _cd, _bkt は名前を変更するか、eval で利用されない限りサーチ結果には表示されません。

_raw:生データ

# 生データの中でIPアドレスの先頭が10であるsendmailイベント
eventtype=sendmail | regex _raw=*10.\d\d\d.\d\d\d.\d\d\d\*

_time:タイムスタンプ (UNIX表記)

# test@sample.com宛に送られたメールをタイムスタンプ順に表示
sourcetype=mail to=test@sample.com | sort _time

_indextime (非表示):インデックスした時のタイムスタンプ (UNIX表記)

_cd (非表示):イベントアドレス

_bkt (非表示)バケット

デフォルトフィールド

Indexerにデータが処理される時、各イベントに『host』『index』『source』『sourcetype』『linecount』『punct』『splunk_server』『timestamp』が付与されます。

  • 収集フェーズ:host, index, source, sourcetype
  • 加工フェーズ:linecount, punct, splunk_server, timestamp

収集フェーズではデータの参照元から得たメタデータ、加工フェーズではイベント単位で変換されるデータを取得し、それぞれ input.confprops.conf 内で構成されます。

収集フェーズ

host:IPアドレス/ホスト名

# webサーバーのデータでuserAがアクセスした直近100件のイベント
host=web* eventtype=access user=userA | head 100

# "404"が含まれhost(IPアドレス)が192から始まるイベント
404 | regex host=*192.\d\d\d.\d\d\d.\d\d\d*

index:インデックス名 (default: main)

# webログを保存するindex内の、htmlファイル
index="web_log" *.html

source:ファイルパス/ネットワークポート

# /var/www/error.logのイベント
source="/var/www/error.log"

sourcetype:データ型
※ Splunkが自動で認識できなかった場合はファイル名が採用

# 全てのaccessイベント
sourcetype=access*

加工フェーズ

linecount:インデックス前のイベント行数

# index=mainで、インデックス前のデータが11行以上20行未満のイベント
index=main linecount>10 linecount<20

punct:句読点のパターン

# htmlエラーログで、[--_::]__:___:____/-..-///.___のパターンのイベント
source="*/html_error.log" punct=[--_::]__:___:____/-..-///.___

splunk_server:Splunkサーバー名
※ 複数サーバーを利用する場合に有効

# Splunkサーバーの名前がDevOpsのイベント
splunk_server=DevOps

timestamp:タイムスタンプ

# timestampが認識されなかったイベントの数を集計
timestamp=none | stats count(_raw) as count

データの追加

追加方法 説明
Upload ローカルからファイル (e.g., csv, xlsx, zip) をアップロード
Monitor インスタンス上のファイル (e.g., wmi, tcp/udp, scripts) やポートを一度/継続的に収集
Forward Forwarderからデータ (e.g., tcp/udp, scripts) を収集

※『Upload』のように一度だけインデックス化される場合、inputs.confのスタンザは作成されません

【例】Monitorでディレクトリを監視

今回は『Monitor』を選択し、データを実際に取り込むまでの流れをみていきます。
※インスタンスの再起動後にSplunkがファイルステータス、コンテンツを自動で監視します。

1. [Monitor] > [Files & Directories] > tutorialdata のディレクトリを指定

2. 『Source type』『App context』『Host』『Index』を指定

『Source type』:今回用いる tutorialdata には様々な用途のデータが含まれるので、[Automatic]を選択することでデータタイプ (e.g., web, sales) 毎に source type が自動で振り分けられるようにしました。
『App context』:指定したアプリのフォルダに inputs.conf を配置します。デフォルトでは [Search & Reporting] が指定されており、この場合 SPLUNK_HOME/etc/apps/search/local/ に inputs.conf が配置されます。
『Host」:デフォルトでは「IPアドレス/ホスト名」ですが独自に設定することも可能です。3番目の[Segment in path]は file path の “/” 区切りのn番目を採用します。[Regular expression on path], [Segment in path] はそれぞれ inputs.conf の host_regex, host_segment に記述されます。
『Index』:保存先のインデックスを指定します。(default: main)

3. Reviewで入力項目を確認すれば完了

4. (option) 実際にサーチ画面からデータを確認

こちらが私の環境で tutorialdata を読み込んだ結果となります。先ほどの手順以外には特に何もしていませんが、Spulnkが生ログから自動でフィールドを検出していることが確認できます。(画面左下)

Network / Script / Windows のデータを収集【Splunk】
Splunkでの高度なデータ収集 前回の記事では、データ収集の1つの方法として『ディレクトリの監視』を取り上げました。そこで今回は別の方法である『Network (TCP/UDP)』『Script』...

inputs.conf (収集)

inputs.conf 解説【Splunk】
inputs.conf とは inputs.conf とは「データの収集に関する構成ファイル」のことで、メタデータ (e.g., host, source, index) の追加/編集/削除などを定...

props.conf (処理)

props.conf 解説【Splunk】
props.conf とは props.conf とは「データの処理 (e.g., inputs, indexing, searching) に関する構成ファイル」のことで、host, source...

transforms.conf (変換)

transforms.conf 解説【Splunk】
transforms.conf とは transforms.conf とは「データの変換 (e.g., overriding, anonymizing) を正規表現で指定した構成ファイル」のことで、...

カスタムフィールド

カスタムフィールドはサーチ時に追加することが推奨されていますが、conf filesで指定したフィールド*をインデックス時に抽出することもできます。
※フィールドは props.conf (HF/Indexer), transforms.conf (HF/Indexer), fields.conf (SH) で指定。

サーチ前にフィールド抽出が行われ、不要なヘッダー/コメントを削除でき、他のApp/Add-onでも利用できるというメリットがある一方『ストレージ容量の増加』『サーチ対象の増加』『柔軟性の低下 (静的なフィールド)』などがデメリットとして挙げられます。

構造化データのフィールド抽出

構造化データの場合、例えばHFの props.conf で INDEXED_EXTRACTION を指定することで、Splunkがそのタイプに適した抽出を行います。
※構造化データはIndexer側で処理されないので、Forwarder側でフィルタリングやマスキングなどを行う必要があります。

[source::.../sample.csv]
INDEXED_EXTRUCTION = csv   # csv,tsv,psv,w3c,json,hecから選択
HEADER_FIELD_LINE_NUMBER = 2   # 2行目以降を読み込む

fields.conf

fields.conf とは「フィールドの扱い (e.g., multi-value, indexed/extracted fields) に関する構成ファイル」のことで、props.conf の定義をより柔軟にすることができます。(HF, Indexerが対象)

# transform.conf
[web_error]
REGEX =  device_id=\[w+\](?[^:]+)
FORMAT = err_code::$1
WRITE_META = true   # インデックス時のフィールド(メタデータ)として書き込み

# fields.conf
[err_code]
INDEXED = true   # err_codeのフィールドをインデックス時に作成

Lookups で外部データを結合

定義可能なデータタイプ

Lookups はサーチ時に外部のデータを結合する機能で『File-based』『External』『KV Store』『Geospatial』の4種類のデータを定義できます。

種類 データソース 説明
File-based CSV /lookups にある csv file
KV Store KV Store collection KV Store Collection にあるKey/Value
External 外部ソース (e.g., DNS server) /bin にある python script, executable
Geospatial KMZ, KML /lookups にある kmz, kml file

KV Store vs. CSV file

KV Store は collection.conf の直接編集、または [Settings] > [Lookups] > [Add new] > [KV Store] から作成することができ、CSVファイルと比較して以下のようなメリット/デメリットがあります。

種類 Pros/Cons 説明
KV Store メリット ・レコード単位での挿入/更新ができる
・書き込み時にデータタイプを指定できる
・Field accelerationsを定義できる
・Data CollectionにREST APIでアクセスできる
デメリット ・大文字/小文字の区別がない
CSV メリット ・ファイルサイズが小さく変更がほとんどない場合に最適
・手動で変更がしやすい
・Excelなどで連携しやすい
・大文字/小文字の区別がある
デメリット ・複数ユーザーのアクセスロック機能がない
・編集操作の際にファイルを全て書き直す必要がある
・REST API でアクセスできない

サーチコマンドと利用例

lookup:サーチ結果に対してフィールドを追加するコマンド。

# ユーザーが所属するグループを追加
# usertogroup: transform.confで定義されたlookup tableのスタンザ
# user,group: lookup table内のフィールド
# local_user: サーチ結果内にあるフィールド
# user_group: サーチ結果に上書きするフィールド
...| lookup usertogroup user as local_user OUTPUT group as user_group

inputlookup:lookup table のコンテンツをサーチで利用するコマンド。

# /system/lookups or /apps/<app_name>/lookups にあるcsvを読み込み
| inputlookup users.csv

outputlookup:サーチ結果を lookup table file, KV Store collection に書き込むコマンド。

# "usergroup"という名前のlookup tableをtransform.confへ書き込み
| outputlookup user.csv

データの完全性・再インデックス化

完全性チェック (fishbucket)

fishbucket とは「収集するデータの完全性 (欠落/重複など) に関する監視ログが保存された index」のことで、データ収集のトラブル時にSplunkエンジニアがログ(index = _thefishbuckets)を調査するために用いられます。
※ _thefishbuckets は全てのSplunkインスタンスの $SPLUNK_DB/fishbucket に存在します。

なお、fishbucket は『ファイルの場所 (Head)』『最後にインデックス化を行った場所 (Tail)』などで構成されています。

再インデックス化 (Re-index)

Forwarder (or DS) の Fishbucket checkpoint を消去することで、収集ファイルの監視をリセットし、(インスタンス再起動後) 再度インデックス化を実行行うことができます。

<手順>

1. Re-index前のイベントデータを削除

2. Forwarderの inputs.conf を編集 (※既存のデータに対して変更は適用されません)

3. stop でSplunkインスタンスを停止

$SPLUNK_HOME/bin/splunk stop

4. btprobe で指定したファイルの監視設定をリセット

$SPLUNK_HOME/bin/splunk cmd btprobe -d $SPLUNK_HOME/var/lib/splunk/fishbucket/splunk_private_db --file <file_path> --reset

(option) 4’:$SPLUNK_DB/fishbucketのファイルを手動で削除、または clean でfishbucketを丸ごと削除
※再インデックス化されるデータはライセンスにカウントされるので、利用には細心の注意を払ってください。

$SPLUNK_HOME/bin/splunk clean eventdate -index _thefishbucket

5. Splunkインスタンスを起動

$SPLUNK_HOME/bin/splunk start

References

What data can I index? – Splunk Documentation

Use default fields – Splunk Documentation

Monitor files and directories with inputs.conf – Splunk Documentation

inputs.conf – Splunk Documentation

props.conf – Splunk Documentation

transforms.conf – Splunk Documentation

fields.conf – Splunk Documentation

What is fish bucket thing? – Splunk blogs

How to reindex data from a forwarder – Splunk community

Monitor Splunk Enterprise files and directories with the CLI – Splunk Documentation

Configure custom fields at search time – Splunk Documentation

Configure inline extractions – Splunk Documentation

Configure advanced extractions with field transforms – Splunk Documentation

About lookups – Splunk Documentation

Define a KV Store lookup in Splunk Web – Splunk Documentation

Use configuration files to create a KV Store collection in Splunk Enterprise – Splunk dev

lookup – Splunk Documentation

inputlookup – Splunk Documentation

outputlookup – Splunk Documentation