Copyright © 2016 Splunk Inc.

続・Inside Splunk -数々の高速化技術tstatsが見せる爆速サーチへの扉

Takashi Komatsubara

Splunk Ninja

免責条項

2

このプレゼンテーション中に、弊社は弊社の将来の事象または予想される業績に関する前向きな意見を述べること

があります。弊社は、かかる意見が、現在弊社が知っている要因に基づく弊社の現在の予測および推定を反映する

ものであることと、実際の事象または結果が著しく異なることがあることを皆さんにご注意いたします。実際の結果が

弊社の前向きな意見に含まれるものとは異なるようにさせる重要な要因については、SECを含む弊社の文書をお調

べください。このプレゼンテーションに含まれる前向きな意見は、生のプレゼンテーションの日時において述べられたもの

です。生のプレゼンテーションの後に見直しが行われた場合、このプレゼンテーションに現在のまたは正確な情報が含

まれないことがあります。弊社は、弊社が述べることがある前向きな意見を更新する義務を負いません。また、弊社

のロードマップに関する情報で、弊社の一般的な製品方針の概要が示されていますが、この情報は予告なしにいつ

でも変更されることがあります。これはあくまで参照用であって、契約またはその他の約定に組み込まれないものとしま

す。Splunkは、記述されている特徴または機能を開発する義務も、かかる特徴または機能を将来のリリースに含める

義務も負いません。

私は・・・

3

名前：小松原貴司

勤務先：Splunk

仕事内容: パートナー様への技術支援

趣味：大人ミュージカル、少しゴルフ

技術バックグラウンド：メールとかJavaとか

本セッションのアジェンダ1. 高速化技術のいくつか

2. Tstatsをつかう

3. デモ

本セッションの対象の方々

• みなさまは、スーパーハードコアな方か、あるいは長くSplunkを愛してくださった方々

• statsコマンドに満足している方々

• 周りの方からSplunkのコマンドについて質問を受けていらっしゃる方々

5

本セッションの後に得られるもの

• まわりのみなさんをワォ！と言わせるクエリーを書く方法を理解いただきます。

• 会社やお客様の前で、サーチ忍者としていい気持ちになれます。

• とても簡単ということを知って、とても幸せになれます。

6

高速化の方法

7

サマリーインデックス• 検索した結果を新しい別のインデックスにいれておきます。追加のライセンスはかかりません。

• 方法: – 「|collect」を最後に付け足して、格納先のインデックスを引数にしてするだけでOK– たぶん、sistatsやsitopコマンドを使いたいと思わないでしょう。これらは、あんまり役に立ちません。

– http://www.davidveuve.com/tech/how-i-do-summary-indexing-in-splunk/

• 例:– 統計的集計) ログイン回数、ユニークなホスト数、ユーザ毎/デバイス毎等のxxxx件数、といった数値

– ETL)メールのログは扱いが面倒なので抽出した結果を入れておく– ITSI でメトリックス情報を検索するのに使う

8

サマリーインデックス

• なぜ使わない?– サマリーインデックスへの操作は手作業– データが欠けていると、レポートのアウトプットを見誤るリスク

9

レポート高速化

• 保存済みサーチの結果、stats/timechart/top/chartで計算した結果を保存しておく(10分おき、1時間おき、1日おき等で指定した範囲で)

• 結果を返すときに、この高速化したデータ(保存しておいたデータ)か、あるいは生ログから検索するかは、自動で判断する

10

レポート高速化

• 方法:– 保存済みサーチの設定画面を開き、”レポート高速化”をチェックする– どういう期間を高速化するかを指定する

• 例：– エグゼクティブ向けダッシュボード、などで効果あり

11

レポート高速化

• なぜ使える?– 自動で生ログへの検索へ切り替えたり、自動でBackfillをしたり、リカバリー等がおこなわれる

– とても早い– 簡単

• なぜ使わない? – 単一のサーチジョブに使える ------->– 比較的シンプルな分析に使える ------------------>– 内部メカニズムがブラックボックスなので使いづらい --------->

12

レポート高速化利用しない時

• 統計系の検索をおこなう

• インデクサーは、自分のところで対象となるデータを返す(sumとかcountとか)

• サーチヘッドで合計処理をおこなう

13

レポート高速化利用時

• サーチヘッドが定期的に取得したデータを、自分のローカルに小さい時間単位でスライスしたデータを保存しておく。

• その後、ユーザからおなじリクエストがあった場合は、サーチヘッドのCSVから結果を返す

14

高速化ピボット

• 方法:– データモデルを作成– 高速化する– ピボットの画面からアクセスする

15

高速化ピボット

• なぜ使える?– とても簡単自動的に高速化したデータと生ログのスイッチを自動でおこなう

– データモデル高速化 = 💯 (とても高速)

• なぜ使えない?– デフォルトで全体を高速化しない ---------------->– Can’t go summariesonly in UI ----------------------->– Pivotのサーチコマンドはtstatsより分かりづらい ---->

16

復習

17

イベントはどう保存されている?

18

バケット、インデックス、インデクサー

インデクサーインデックスバケットイベント(論理的なグルーピング)

イベントはどう保存されている?

19

バケットのエージングプロセス

ホット/ウォームストレージ コールドストレージ

アーカイブストレージ● 早いストレージ

● 最近のデータ

● 遅い “バルク” のストレージ

● 古いデータ

● 過去/コンプライアンスデータ

● オンライン(検索可能)/オフライン

削除

-あるいは-

バケットの中には何がある?

20

.tsidx

journal.gz

ブルームフィルタ

バケットの中には何がある?

21

イベントはここに来る

Journal.gzは、圧縮され、小さく、

多量のスライスされたデータから構成される

収集された生のデータは、スライス単位で保存される– 1つのスライスは、最大128KB程度の未圧縮のデータから成る

Journal.gz

journal.gz

バケットの中には何がある?

22

TSIDX

生のイベント

Jim likes Mickey

Suzie likes Donald

Pat likes Pluto

言葉 ポスティングリスト

Donald 1

Jim 0

likes 0,1,2

Mickey 0

Pat 2

Pluto 2

Suzie 1

ポスティング値

シークアドレス

0 34

1 87

2 132

レキシコン 値の配列

生のイベントからの、ユニークな言葉が、レキシコンとして書き込みされる

ポスティングリストを見れば、特定語句がどの配列値に存在しているのか

がわかる

シークアドレスは、対象イベントが

journal.gz内の位置

アドレスを示している

*本資料は、わかりやすいようにかなり簡素化して表記しています。

Lexicon(レキシコン) と dictionary はどう違うのですか？>lexicon＝語彙（ごい）、ギリシャ語・ヘブライ語・アラビア語などの辞書>dictionary＝辞書・辞典

Walklexコマンドでtsidxファイルの中を見てみる

• /opt/splunk/bin/splunk cmd walklex 1457540473-1457196480-3287925045170504614.tsidx "" | tr-s " " | cut -d" " -f3 | grep "::" | awk -F "::" '{print $1;}' | sort | uniq -c

23

TSIDXへのtstats

24

tstats

• 生データではなく、tsidxというインデックスファイルに統計処理をおこなう

• 方法:– 引数は違うが、普通のstatsコマンドとよく似ている– | tstats count where index=* groupby index sourcetype

25

tstats

• なぜ使える?– めちゃくちゃ早い– summaries_only=t を指定するとtsidxでのみ検索

26

通常のサーチ文からtstatsへ

Rawindex=* | stats count by index, sourcetype

Tstats| tstats count where index=* groupby index, sourcetype

27

普通のデータモデルからtstatsへ

Raw tag=network tag=traffic | stats dc(dest_ip) by src_ip

Tstats| tstats dc(All_Traffic.dest_ip) from datamodel=Network_Trafficgroupby All_Traffic.src_ip

28

tstatsで whereをつかってみる

• 以下のように普通にしていすればよい– Where index=* sourcetype=pan_traffic OR sourcetype=pan:traffic

• tstatsコマンドをつかって、panインデクサで、10.1.1.1のものを数える– | tstats count where index=pan 10.1.1.1

29

tstatsでgroup byをつかってみる

• Stats コマンドと同じ– | tstats count where index=* groupby source, index

• _timeとspanを指定すると、時間のフィルタリングをかなり早い– | tstats count where earliest=-24h index=* groupby index _time span=1h

30

Real World Customer

31

Splunk(x) -インデックスにサーチをかけてみた

• 社内のSplunkにおいて、どんなデータ種類(sourcetype）はいっているか確認したい

• _raw: index=* earliest=-24h | bucket _time span=1h | stats count by sourcetype, _time

– Time to complete: 68,476 seconds (19 hours)

• tstats: | tstats count where index=* groupby sourcetype _time span=1h

– Time to complete: 6.19 seconds

• 11倍です。

• サーチ分も短くなった: 18 文字

32

応用例) データの取り込み遅延をあぶり出す_indextimeフィールド

• 以下の例は、すこしだけ複雑です| tstats count min(_time) as min_time max(_time) as max_time where

[| stats count as search | eval search="_indextime>" . relative_time(now(), "-7d") | table search]

index=* groupby _indextime

| eval lag=_indextime - (min_time + max_time) / 2

| eval _time = _indextime

| timechart avg(lag)

33

時間についての注意

_time は、tstatsにとって特別です。以下の点をお気をつけください。

• Avgを_tme, range(_time)は、指定してはいけない。You can’t do avg(_time) or range(_time)

• Minとmaxは利用可能

34

Copyright © 2016 Splunk Inc.

Demo!

35

index=* | bucket _time span=1h | stats count by sourcetype, _time| tstats count where host=* by sourcetype, _time

THANK YOU