Splunk 5.0.2
サーチマニュアル
作成：2013 年 3 月 13 日 午前 8 時 5 分
Copyright (c) 2013 Splunk Inc. All Rights Reserved
Table of Contents
はじめに
8
サ ー チマニュアルにようこそ
PDF を作成
8
8
サ ー チの 概 要
8
サ ー チについて
サ ー チの種類
サ ー チとナレッジ
Splunk Web、 CLI、または REST API による 索
8
8
9
9
サ ー チパイプラインについて
9
サ ー チ言語について
サ ー チ言語のコンポ ー ネント
サ ー チの詳細
サ ー チコマンドの種類
10
10
10
10
サ ー チ言語の構文について
引用符とエスケ ー プ文字
フィ ー ルド
11
11
11
サ ー チアシスタントについて
サ ー チアシスタントを使用してサ ー チ作成時にデ ー タを表示
サ ー チアシスタントの設定の 更
12
12
12
サ ー チジョブ調査によるサ ー チプロパティの表示
サ ー チジョブ調査の使用
ジョブ調査で分かること
サ ー チジョブ調査の出力例
回答
12
12
13
16
16
サ ー チに合わせたサ ー チモ ー ドの設定
高速モ ー ドの選
詳細モ ー ドの選
スマ ー トモ ー ドの選
16
17
17
17
実 行中のサ ー チへのアクション
18
より良いサ ー チの作成
サ ー チの種類
サ ー チでのフィ ー ルドの使用
デ ー タの要約
サ ー チジョブ調査の使用
19
19
19
20
20
イベントの取得
20
イベントの取得について
イベント、イベントデ ー タ、およびフィ ー ルド
20
21
サ ー チコマンドの使用
キ ー ワ ー ド、フレ ー ズ、ワイルドカ ー ド
論理演算式
フィ ー ルド式
CASE() と TERM() を使ったフレ ー ズの照合
21
21
22
22
22
フィ ー ルドを使ったイベントの取得
23
インデックスおよび分散サ ー チピアからのイベントの取得
1 つまたは複 数 のインデックスサ ー チの指定
1 つまたは複 数 のサ ー チピアにまたがるサ ー チ
目的のイベントが見つかりませんか？
23
23
24
25
類似イベントの分類とグル ー プ化
サ ー チの新規イベントタイプとしての保存
typelearner を使った新規イベントタイプの 出
タグを使った類似イベントのグル ー プ化と 索
25
25
26
26
タイムラインを使ったイベントパタ ー ンの調査
タイムラインのスケ ー ルの 更
イベントを調査するためのズ ー ムイン /アウト
27
27
28
時間範 の指定
28
サ ー チにおける時間範 について
28
サ ー チに適用する時間範 の選
カスタム時間範 の定義
選 できる時間範 のカスタマイズ
29
29
30
サ ー チへの時間修飾子の指定
絶 時間範 の指定
相 時間範 の指定
相 時間修飾子の例
相 時間オフセットのチェ ー ン例
相 時間修飾子を使ったサ ー チ例
30
30
30
31
32
32
サ ー チへのリアルタイム時間範 ウィンドウの指定
リアルタイム修飾子の構文
「全時間」リアルタイムサ ー チ
リアルタイムバックフィル
32
32
32
33
サ ー チ結果のレポ ー ト
33
レポ ー トコマンドについて
33
レポ ー トコマンド入門
リアルタイムレポ ー ト
33
34
時間ベ ー スのグラフの作成
34
時間ベ ー スではないグラフの作成
34
多い /少ないフィ ー ルド値のビジュアル化
複 な top コマンドの例
34
35
サマリ ー 統計情報を表示するレポ ー トの作成
35
サ ー チでの 関 連、統計的相 関 、および差異の調査
35
複 数 のデ ー タシリ ー ズを持つグラフの作成
シナリオ
明
36
36
36
複 数 日の時間ごとの合計の比較
シナリオ
解決策
37
37
37
リアルタイムのサ ー チとレポ ー ト
38
リアルタイムサ ー チとレポ ー トについて
リアルタイムサ ー チの仕組み
38
38
Splunk Web でのリアルタイムサ ー チとレポ ー ト
Splunk Web でのリアルタイムサ ー チ
Splunk Web でのリアルタイムレポ ー ト
39
39
39
CLI でのリアルタイムサ ー チとレポ ー ト
39
リアルタイムサ ー チとレポ ー トの、予想されるパフォ ー マンスと 既 知 40
の制限事項
インデックス作成のスル ー プット
40
リアルタイムサ ー チウィンドウ
40
リアルタイムサ ー チの利用の制限方法
41
indexes.conf でリアルタイムサ ー チを無 効 にする
41
ユ ー ザ ー またはロ ー ルに してリアルタイムサ ー チを無 効 にする 41
リアルタイムサ ー チの制限の設定
41
リアルタイムサ ー チのインデクサ ー 制限の設定
41
統計の算出
42
統計の算出について
42
st at s コマンドおよび 関数 の使用
42
st at s と eval 式および 関数 の使用
例 1：一致したイベントとの一意の 数
42
42
サ ー チ結果へのスパ ー クラインの追加
stats および chart コマンドでのスパ ー クラインの使用
43
43
フィ ー ルドの評 価 と操作
45
フィ ー ルドの評 価 と操作について
45
eval コマンドおよび 関数 の使用
45
ルックアップを使ったルックアップテ ー ブルからのフィ ー ルドの追加 45
サ ー チコマンドによるフィ ー ルドの抽出
正規表現を使ったフィ ー ルドの抽出
サ ー チ結果のフィ ー ルド値抽出の 強 制
フォ ー ムテンプレ ー トに基づいたイベントからのフィ ー ルドの
抽出
45
46
46
46
複 数 値フィ ー ルドの操作と評 価
複 数 値フィ ー ルドの操作
複 数 値フィ ー ルドの評 価
46
47
47
イベントの相 関
48
イベントの相 関 について
48
時間を使ったイベント間の 関 係の識別
48
サブサ ー チについて
サブサ ー チの例
サブサ ー チのパフォ ー マンス
サブサ ー チコマンドの結果出力設定
回答
48
48
49
49
49
サブサ ー チを使ったイベントの相 関
49
サブサ ー チ結果のフォ ー マットの 更
サ ー チおよびクエリ ー フィ ー ルド
例
50
50
50
トランザクションについて
トランザクションサ ー チ
トランザクションの代わりに stats を使用する場合
トランザクションおよびマクロサ ー チ
51
51
51
51
イベントの識別とトランザクションへのグル ー プ化
transaction のサ ー チオプション
51
52
トランザクションサ ー チの例
53
将来 のイベントの予測
53
Splunk による予測分析について
予測コマンド
付加的および 加的シ ー ズナリティ
53
53
53
その他のサ ー チ方法
53
サ ー チマクロの作成と編集
Splunk Web でのサ ー チマクロの作成
保存 みサ ー チおよびアドホックサ ー チへのマクロの適用
例 - サ ー チマクロとトランザクションの組み合わせ
54
54
54
54
カスタムサ ー チコマンドの作成
55
この章について
55
サ ー チコマンドスタイルガイド
カスタムサ ー チコマンドの命名規則
引 数 の 処 理およびチェック方法
エラ ー の 処 理
サブパイプラインを取るコマンド
55
55
56
56
56
サ ー チコマンドの作成
サ ー チコマンドの種類
入力の 処 理
出力の送信
エラ ー処 理
56
57
57
57
57
Splunk へのカスタムコマンドの追加
新しいスタンザの作成
Splunk の再起動
58
58
58
カスタムコマンドへのアクセス制御
Splunk Web で編集できる項目
設定ファイルで編集できる項目
59
59
59
カスタムサ ー チコマンドの例
59
外部化されたサ ー チエラ ー 文字列
60
外部化されたサ ー チエラ ー
サ ー チエラ ー 文字列
エラ ー 文字列の上書きまたは定義
60
60
60
サ ー チの例と手引き
61
この章の 内 容
61
複 数 のデ ー タシリ ー ズのレポ ー ト
はじめに
シナリオ
明
61
61
61
61
異なる日の時間別合計の比較
はじめに
シナリオ
解決策
その他の情報
62
62
62
62
62
Windows ディスク使用量の監視とアラ ー ト
63
動的フィ ー ルドのサイズの算出
シナリオ
明
63
63
63
はじめに
サ ー チマニュアルにようこそ
システム内のすべてのデータを取り込んだら、それをどのように取り扱いますか？まず、Splunk の強力なサーチ
機能を使用して、定義されている一部のフィールドだけではなく、いろいろな情報を探してみましょう。時間によ
るサーチと単語によるサーチを組み合わせられます。IT インフラ内のあらゆるレイヤのエラーを 索して設定の 更
を追跡し、システム障害の発生を防止してください。
このマニュアルでは、サーチ言語の概要および Splunk でのサーチの作成方法について 明していきます。
サーチに関する情報をご覧になる前に、以下の事項を確認してください。
ローカルマシンまたはリモートサーバー上のデータにアクセスできる。Splunk へのデータの取り込みの詳細
は、『Getting Data In Manual』を参照してください。
Splunk でのインデックスの働きを理解している。詳細は、『Managing Indexers Manual』を参照してくださ
い。
フィールドとソースタイプやイベントタイプなどのナレッジオブジェクトを理解している。ナレッジオブ
ジェクトの詳細は、『Knowledge Manager Manual』を参照してください。
サーチ App およびサーチ/レポートダッシュボードの使用法を理解している。Splunk が初めての方は、ぜひ
『Splunk チュートリアル』をご覧ください。データの追加、データのサーチ、簡単なレポートやダッシュ
ボードの作成方法などが詳細に 明されています。
Splunk のサーチコマンドや利用できる引数の一覧については、『Search Reference Manual』を参照してくださ
い。
PDF を 作 成
このマニュアルの PDF 版が欲しい場合は、このページの目次の左下にある赤い [Download the Search Manual
as PDF] リンクをクリックしてください。PDF 版のマニュアルがその場で作成されます。作成された PDF は後で
利用するために保存、印刷することができます。
サ ー チの 概 要
サ ー チについて
この章ではサーチの概要、Splunk サーチの構造、サーチ言語とその構文、サーチの作成とトラブルシューティン
グに役立つツール、およびより良いサーチの作成に関するヒントなどを 明していきます。
サ ー チの種類
サーチ言語とその構文の詳細を学習する前に、まず自分の目的が何なのかを確認しておきましょう。一般的には、
Splunk にデータを取り込んだら、以下のような作業を行います。
インデックスを作成したデータを調査して詳細を把握する、または問題の主原因を特定する。
サーチ結果を表形式またはその他の視 的な形式のレポートで表示する。
このために、raw イベントサーチとレポート生成サーチの 2 種類のサーチが存在しています。
raw イ ベ ン ト サ ー チ
raw イベントサーチは、インデックスから単にイベントを取得するサーチで、一般的には問題の分析を行う場合に
実行されます。このようなサーチの例として、エラーコードのチェック、イベントの相関付け、セキュリティ上の
問題の調査、障害の分析などが げられます。一般的にこのようなサーチにはサーチコマンドは含まれず (search 自
体を除く)、サーチ結果は raw イベントの一覧になります。
raw イベントサーチの詳細は、本マニュアルの「イベントの取得」の章にある「イベントの取得について」
を参照してください。
レポート生成サーチ
レポート生成サーチは、一連の結果に してある種の統計的な計算を実行するサーチです。これらは、まずイン
8
デックスからイベントを取得して、それを 1 つまたは複数のサーチコマンドに渡すタイプのサーチです。これらの
サーチは常にフィールドと最低 1 つの統計コマンドのセットを必要としています。この例としては、 日のエラー
イベント数の取得、特定ユーザーのログイン回数のカウント、フィールド値の 95 番目のパーセンタイルの算出な
どが げられます。
サーチ構造の詳細は、「サーチパイプラインについて」を参照してください。
サーチコマンドでできる操作の詳細は、「サーチ言語について」を参照してください。
このマニュアルの「 索結果のレポート」にあるレポート生成の詳細は、「レポートコマンドについて」を参
照してください。
サ ー チとナレッジ
サーチを実行するにつれて、そのパターンを理解したり、サーチ可フィールドとして役立つその他の情報が分かっ
てくることでしょう。新たなデータのインデックスを作成するにつれて、これらの新規フィールドを認識するよう
に Splunk を設定したり、サーチに じて新たなフィールドを作成することができます。どのような場合でも、イベ
ントデータのフィールド、イベント、およびトランザクションに関するこのナレッジを使用、追加、編集できま
す。このナレッジの収集は、効率的なサーチの作成や詳細なレポートの構築に役立ちます。
Splunk Web、 CLI、または REST API による 索
サーチを手動で実行するにはどうしたら良いのでしょうか？一般的には、Splunk Web のサーチ App からサーチを
実行します。しかし、コマンドラインインターフェイス (CLI) や REST API からサーチを実行することもできま
す。どの方法を使用するのが最適なのかは、サーチ目的によって異なります。
Splunk Web でサーチを実行する場合は、サーチ App を使用することになり、サーチモード (高速、詳細、スマー
ト) によりサーチ処理を制御します。Splunk は選 したモードに じて、デフォルト以外のフィールドを自動的に発
見、抽出して、それをイベントリストまたはテーブルとして返し、次にイベントタイムラインの生成に必要な計算
を実行します。イベントタイムラインの計算では、ユーザーがタイムライン上のバーをクリックした時にデータを
提供できるように、バケツが作成されてイベントとフィールドの統計情報がディスパッチディレクトリに保持され
ます。そのため、コストが非常に高くなります。
詳細は、この章の「サーチに合わせたサーチモードの設定」を参照してください。
CLI または REST API のサーチジョブエンドポイントを使用してサーチを作成、実行する場合は、splunkweb を介
さず直接 splunkd でサーチの処理が行われます。これらのサーチでは、イベントタイムラインの算出、生成が行わ
れないため、Splunk Web と比べて大幅にサーチ処理が高速化されます。その代わり、CLI のサーチ結果は、サー
チの種類に じて raw イベントリストまたはテーブルとして表示されます。
詳細は、『サーチリファレンスマニュアル』の「CLI サーチについて」を参照してください。
REST API については、『REST API Reference Manual』の「Creating searches using the REST API」を参
照してください。
サ ー チパイプラインについて
Splunk サーチを 明するための用語「サーチパイプライン」をすでにご存じかもしれません。サーチパイプライン
は、Splunk サーチの構造を表しています。これは、パイプ文字「|」を使って複数のコマンドを連続的に結合しま
す。パイプ文字は、あるコマンド (パイプの左側) の出力または結果を、次のコマンド (パイプの右側) の入力とし
て使用することを表しています。これにより、目的の結果が得られるまでパイプラインの各ステップでデータを調
節または追加することができます。
Splunk サーチは、パイプラインの先頭にあるサーチ単語から開始されます。これらのサーチ単語は、インデック
スから取得するイベントを示す、キーワード、フレーズ、論理演算式、キー/値のペアなどです。
詳細は、「イベントの取得について」を参照してください。
次に取得されたイベントは、パイプ文字を使って次のサーチコマンドに入力として渡されます。サーチコマンド
は、インデックスから取得したイベントに する処理を Splunk に指示します。たとえば、コマンドを使って不要な
情報のフィルタリング、追加情報の抽出、新しいフィールドの評価、統計情報の算出、結果の並べ替え、グラフの
作成などを行います。一部のコマンドには、それに関連した関数や引数が用意されています。これらの関数と引数
により、結果の処理方法や処理 象フィールドなどを指定できます。たとえば、グラフの作成方法、算出する統計
情報、評価 象フィールドなどを指定できます。また、句を使ってサーチ結果をグループ化できるコマンドも用意
されています。
サーチコマンドでできる操作の詳細は、「サーチ言語について」を参照してください。
すべてのサーチコマンドの一覧については、『Search Reference』マニュアルを参照してください。このマ
ニュアルには、各サーチコマンドおよびその構文と使用法が記載されています。
9
サ ー チ言語について
サ ー チ言語のコンポ ー ネント
Splunk サーチ処理言語 (SPL)は、あらゆるサーチコマンドおよびその関数、引数、句を網羅しています。サーチ
コマンドは、インデックスから取得したイベントに する処理を Splunk に指示します。たとえば、コマンドを使っ
て不要な情報のフィルタリング、追加情報の抽出、新しいフィールドの評価、統計情報の算出、結果の並べ替え、
グラフの作成などを行います。
一部のサーチコマンドには、それに関連した関数や引数が用意されています。これらの関数や引数を使って、結果
の処理方法や処理 象フィールドを指定します。たとえば、関数を使ってグラフ内のデータのフォーマット、算出
する統計情報の指定、評価 象フィールドの指定などを行えます。また、句を使ってサーチ結果をグループ化でき
るコマンドも用意されています。
サ ー チの詳細
サーチコマンドがデータをどのように処理するかを理解するための例として、コマンドはインデックス作成された
すべてのデータをビジュアル化するために役立ちます。各サーチコマンドは、表の形状を定義します。
たとえば、以下のサーチコマンドについて見てみましょう。
sourcetype=syslog ERROR | top user | fields - percent
ディスクはインデックス作成されたすべてのデータを、列を持つ一定サイズのテーブルの列はフィールドを、行は
イベントを表しています。最初の中間結果テーブルでは、行数が少なくなっています。これは、サーチ単語
「sourcetype=syslog ERROR」に一致したインデックスから取得された、イベントのサブセットを表していま
す。2 番目の中間結果テーブルでは、列が減少しています。これは、イベントを上位 10 人のユーザーに限定し、
ユーザー、カウント、および割合を表示する「top user」コマンドの結果を表しています。次に、「fields percent」で、割合を表示する列が削除され、目的の情報のみを含む最終結果テーブルが表示されます。
サ ー チコマンドの種類
サーチコマンドは、ストリーミング/非ストリーミングコマンドまたはレポートコマンドになります。
ス ト リ ー ミ ン グ /非 ス ト リ ー ミ ン グ コ マ ン ド
ストリーミングコマンドは、インデクサー上で実行され、インデックスデータのサブセットに並列的に適用できま
す。ストリーミングコマンドは、サーチが返した各イベントに 換処理を適用します。たとえば、regex コマンドは
ストリーミングコマンドで、サーチ時にフィールドを抽出してそれをイベントに追加します。
一方、非ストリーミングコマンドは常に集中処理されます。このコマンドはサーチヘッドで実行され、そのレベル
で利用できるデータセット全体を分析し、そのセットからサーチ結果の出力を取り出します。
現在 Splunk で提供されているストリーミングコマンドは、bucket (明示的に span= で呼び出された場合)、
convert、eval、extract (kv)、fields、lookup (local=t でない場合)、mvexpand、multikv、rename、regex、
replace、rex、search、strcat、tags、および typer です。
レポートコマンド
レポートコマンドは、各イベントの特定のセル値を数値に 更します。それらの情報は、統計目的で使用できま
す。レポートコマンドは、サーチ結果のデータを 棒、横棒、折れ線、面、および円グラフなどの視 エフェクトが
必要とするデータ構造に 換するために用いられます。
レポートコマンドには、chart、timechart、stats、top、rare、contingency、および highlight などが含まれていま
す。
10
サ ー チ言語の構文について
サーチは、パイプ (|) 文字で区切られた一連のコマンドから成り立っています。各パイプ文字の直後の、空白文字
で区切られた最初の文字列がコマンドになります。各コマンドの残りの文字列は、そのコマンドに じた方法で処
理されます。
引用符とエスケ ー プ文字
一般的に、空白文字、カンマ、パイプ、引用符、角括弧を含むフレーズやフィールド値は、引用符で む必要があ
ります。引用符の数は偶数でなければなりません。文字列の最初に引用符を指定したら、その文字列の終了を表す
引用符も指定する必要があります。例：
のようなサーチは、文字列「error」を含むイベント数を 索します。
のようなサーチは、error、1 つのパイプ、stats、および count がその
順番で含まれている raw イベントを返します。
error | stats count
... | search "error | stats count"
また、論理演算子やフィールド/値のペアなどが、サーチ時に元の意味で解釈されないように、そのようなキー
ワードやフレーズを引用符で むことも可能です。例：
キーワード AND を論理演算子として解釈せずにサーチする場合： error "AND"
フィールド/値のペアをフレーズとしてサーチする場合： error "startswith=foo"
円記号 (\) は、引用符、パイプ、および円記号自身をエスケープ処理する場合に使用します。円記号によるエス
ケープシーケンスは、引用符内でも展開されます。例：
サーチ内に「\|」と指定すると、このパイプ文字は 2 つのコマンドの区切り文字ではなく、処理 象のパイプ
文字としてコマンドに渡されます。
「\"」と指定すると引用符がそのまま文字としてコマンドに渡されます。たとえば、文字通りの引用符を 索
したり、rex を使ってフィールド内に引用符を 入する場合に使用します。
「\\」と指定すると、文字通りの円記号がコマンドに渡されます。
認識されない円記号のシーケンスは 更されません。
たとえば、サーチ文字列内に「\s」とある場合、これは既知のエスケーブシーケンスではないため「\s」とし
てコマンドに渡されます。
しかし、「\\s」と指定した場合、「\\」は既知のエスケープシーケンスで「\」に 換されるため、「\s」とし
てコマンドに渡されます。
例
例 1： myfield は 6 の値から作成されます。
... | eval myfield="6"
例 2： myfield は " の値から作成されます。
... | eval myfield="\""
例 3： myfield は \ の値から作成されます。
... | eval myfield="\\"
例 4：引用符の数が偶数でないため、エラーが発生します。
... | eval myfield="\"
フィ ー ルド
Splunk のサーチパイプライン内を通過するイベントと結果は、フィールドの集合体として存在しています。基本
的にフィールドは、_time はイベントの時刻、source はファイル名、などのように Splunk のインデックスに由来
しています。また、イベントタイプ、タグ、rex コマンドを使った正規表現による抽出、stats コマンドの合計値な
ど、サーチ時にさまざまなソースから取得することも可能です。
特定のイベントに して、特定のフィールド名が存在することも、存在しないこともあります。存在する場合、単
一値または複数の値が含まれている可能性があります。各値はテキスト文字列です。値は正の長さを持つ (文字列
またはテキスト) か、または長さ 0 (空文字列または "") になります。
たとえば、数字はその数字を表す単なる文字列です。たとえば、数字 10 の値を持つフィールドは、文字 1 と文字
0 を含む文字列「10」になります。数値を取得するコマンドは、計算のために内部で自動的に文字を数値に 換し
11
ます。
Splunk マニュアルおよびメッセージでは、以下の用語を使用しています。
ヌルフィールド
ヌルフィールドは、特定の結果やイベントに存在しないフィールドです。サーチ内のその他のイベントまた
は結果に、このようなフィールド値が存在していることがあります。たとえば、サーチコマンド fillnull は、
サーチ内の他のイベントや結果に存在しているフィールドが見つからないイベントや結果に、フィールドと
デフォルト値を追加するために用いられます。
空のフィールド
空のフィールドは、単一の空文字列を値に持つフィールドです。
空の値
空文字列 ""、または長さ 0 の文字列です。
複数値フィールド
複数の値を持つフィールドです。ヌルフィールド以外のフィールドは、文字列のリストを保有しています。
一般的には、1 つの値を持つリストになります。リストに複数のエントリが存在している場合に、それを複
数値フィールドと呼んでいます。詳細は、『サーチマニュアル』の「複数値を持つフィールドの操作と評
価」を参照してください。
サ ー チアシスタントについて
Splunk のサーチ言語は多彩で、さまざまなサーチコマンド、引数、および関数が用意されています。すべてのコ
マンドを理解している訳ではなく、またデータからどのような情報が抽出されているのか分からないために、サー
チの作成に多少時間がかかるかもしれません。
サ ー チアシスタントを使用してサ ー チ作成時にデ ー タを表示
サーチの作成時に、使用するサーチコマンドや引数を知っておく必要はありません。サーチアシスタントがそれを
提案してくれます。
サーチバーに文字を入力すると、サーチアシスタントがそれに合わせた先行入力テキストまたは文脈上適切なテキ
ストを表示します。このような文脈上のテキストは、データの内容に基づいて表示されます。入力を続ける
と、[一致する単語] に表示される項目がそれに じて 化します。
サーチアシスタントには、サーチ用語に一致する項目数も表示されます。この値は、Splunk から返されるサーチ
結果数の目安になります。データ内に当該の用語またはフレーズが存在していない場合、サーチアシスタントには
表示されません。
サ ー チアシスタントの設定の 更
サーチアシスタントはサーチバーから呼び出される Python エンドポイントで、サーチバーの下側にスライドされ
るパネルに表示される HTML を返します。サーチアシスタントは searchbnf.conf からその 明と構文情報を取得し
ます。このファイルには、すべての Splunk サーチコマンドとその構文が定義されています。また、提案する
フィールドの表示に fields.conf を使用したり、ユーザーに既存の保存 みサーチと似ていることを知らせるため
に savedsearches.conf を使用したりもしています。
サーチアシスタントの動作は、SearchBar モジュールの UI 設定で 更することができます。これらの設定は、デ
フォルトでサーチアシスタントを表示するかどうか (autoOpenAssistant)、先行入力を使用するかどうか
(useTypeahead)、コマンドのヘルプを表示するかどうか (showCommandHelp)、サーチ履歴を表示するかどうか
(showCommandHistory)、およびフィールド情報を表示するかどうか (showFieldInfo) を定義します。これらのモ
ジュールの詳細は、『Module Reference』を参照してください。
サ ー チジョブ調査によるサ ー チプロパティの表示
サーチジョブ調査は、サーチの処理状況や Splunk が時間をもっとも費やしている所を確認するためのツールで
す。ここでは、サーチジョブ調査を使ったサーチパフォーマンスのトラブルシューティング、およびイベントタイ
プ、タグ、ルックアップなどのナレッジオブジェクトの働きについて 明していきます。
サ ー チジョブ調査の使用
過去のサーチ結果が存在している限り (期限切れでない限り)、サーチジョブ調査でサーチジョブを調査することが
できます。サーチが動作している必要はありません。
サーチを調査するには：
12
1. サーチを実行します。
2. タイムラインの上部にある、[i] ボタンをクリックします。
新しいブラウザウィンドウにサーチジョブ調査が表示されます。
過去のサーチ結果のプロパティを表示するには：
サーチ ID (SID) がある場合、URL を使って過去のサーチ結果を調査できます。サーチの SID は、ジョブ管理で確
認できます (右上の [ジョブ] リンクをクリック)。または、Splunk のディスパッチディレクトリ
$SPLUNK_HOME/var/run/splunk/dispatch にも記載されています。ジョブ管理の詳細は、『Knowledge Manager
Manual』の「Supervise your search jobs with the Job Manager」を参照してください。
サーチジョブ調査ウィンドウで URI パスに注目すると、文字列の最後に以下のような文字列が付いているのが分
かります。
.../inspector?sid=1299600721.22&namespace=search
および namespace は SID 番号およびそれが属する App 名を表しています。ここでは、SID は 1299600721.22
になります。
sid
過去のサーチ結果の SID を URI パスの sid= の後に入力して、Return キーを押してください。サーチを表示する
ために十分な 限を持っている限り、それを調査することができます。
さて、何を調査しますか？
ジョブ調査で分かること
サーチの実行中、ジョブ調査には 2 種類のパネルが表示されます。[実行コスト] には、サーチのコンポーネントに
関する情報、およびサーチの総合的なパフォーマンスにおいて各コンポーネントが与える影響が表示されま
す。[サーチジョブのプロパティ] には、ジョブのその他の特徴が表示されます。サーチ完了時にジョブ調査は、見
つかった結果数およびサーチ完了までにかかった時間を通知します。サーチ完了後、ジョブ調査の画面上部にはエ
ラーメッセージも表示されます。大部分の情報は簡単に理解できますが、このセクションではパネルをもう少し詳
細に 明していきます。
実行コスト
[実行コスト] パネルでは、サーチ-時間イベント処理アクションに関連する特定のコンポーネントのパフォーマン
ス上の影響に注目することで、サーチ効率のトラブルシューティングを行えます。このパネルには、コンポーネン
トのテーブル、それぞれの期間 (秒)、サーチ実行時の各コンポーネントの起動回数、各コンポーネントの入出力イ
ベント数が表示されます。コンポーネントはアルファベット順に表示され、実行したサーチによってその数は異な
ります。以下の表は、個別のサーチコマンドおよび分散サーチコンポーネントの意義について 明しています。(こ
れらは、単にキーワードサーチを実行した場合に表示されるコンポーネントです。)
サーチコマンドコンポーネント
名
明
Splunk は、サーチに一致するインデックスフィールドを含むイベントを識別
すると、イベント自体を調査してその他の基準に一致するかどうかを判断し
ます。これらは同時に処理されます。順次処理されるのではありません。
command.search
command.search.index - raw データ内の読み取り場所を判断するため
に、TSIDX ファイルの調査にかかった時間を示します。
command.search.rawdata - raw データファイルから実際のイベントを読
み取るまでにかかった時間を示します。
command.search.typer - イベントタイプの識別にかかった時間を示しま
す。
command.search.kv - イベントへのフィールド抽出の適用にかかった時
間を示します。
command.search.fieldalias - props.conf に基づいた、フィールド名の 更
にかかった時間を示します。
command.search.lookups - 既存のフィールドに基づいて、新しいフィー
ルドを作成するためにかかった時間を示します (フィールドルックアッ
プを実行)。
command.search.filter - 一致しないイベントのフィルタリングにかかっ
た時間を示します (たとえば、フィールドとフレーズ)。
command.search.typer - イベントへのイベントタイプの割り当てにか
かった時間を示します。
command.search.tags - イベントへのタグの割り当てにかかった時間を
13
示します。
使用するコマンドのタイプと、呼び出し、入力数/出力数に表示される項目数には関係があります。イベントを生
成するサーチの場合、入力数は 0 で、出力数はある程度のイベント数 X になると予測できます。サーチがサーチ
の生成とフィルタリングの両方を行う場合、フィルタリングには入力 (生成サーチの出力 X と等しい) および出力
= X となります。合計数は、入力 = X、出力 = 2*X になり、呼び出し回数は倍になります。
分散サーチコンポーネント名
dispatch.createProviderQueue
明
すべてのサーチピアに接続する時間。
引数のパーシングとサブサーチ評価に消費された時間。これは、使用される
各サーチコマンドによりさらに詳細に分けられます。
dispatch.evaluate
dispatch.evaluate.search - search コマンドが実行されたことを示しま
す。
dispatch.fetch
サーチピアからのイベントの待機または取得に費やされた時間。
dispatch.preview
プレビュー結果の生成に費やされた時間。
dispatch.process_remote_timeline サーチピアが生成したタイムラインのデコードに費やされた時間。
dispatch.stream.local
サーチのストリーミング部でサーチヘッドが費やした時間。
dispatch.timeline
タイムラインとフィールドサイドバー情報の生成に費やされた時間。
サーチジョブのプロパティ
[サーチジョブのプロパティ] フィールドはアルファベット順に表示されます。
パラメータ名
明
cursorTime
以降にイベントがスキャンされていない、もっとも早い時間。進捗状況を示
すために使用できます。doneProgress の 明を参照してください。
delegate
保存 みサーチに して、ユーザーが開始したジョブを指定します。デフォルト
はスケジューラーになります。
diskUsage
使用されている合計ディスクスペース量 (バイト)。
dispatchState
サーチの状態。QUEUED、PARSING、RUNNING、PAUSED、
FINALIZING、FAILED、または DONE になります。
サーチのおおよその進捗状況を示す、0 1.0 の数字。
doneProgress
doneProgress = (latestTime a€“ cursorTime) / (latestTime a€“ earliestTime)
dropCount
リアルタイムサーチのみ。rt_queue_size のために破棄された、見込みイベン
ト数 (デフォルトは 100000)。
earliestTime
サーチジョブの開始が設定されたもっとも早い時間。進捗状況を示すために
使用できます。doneProgress の 明を参照してください。
eai:acl
App およびユーザーレベルの 限を記述します。たとえば、App がグローバル
に共有されているかどうか、サーチを実行または表示できるユーザーなどを
記述します。
eventAvailableCount
エクスポートに利用できるイベント数。
eventCount
サーチが返したイベント数。
eventFieldCount
サーチ結果で見つかったフィールド数。
eventIsStreaming
このサーチのイベントをストリーム配信するかどうかを示します。
eventIsTruncated
サーチのイベントが保管されていないため、サーチのイベントエンドポイン
トから利用できないかどうかを示します。
eventSearch
任意の 換コマンド前のサーチ全体のサブセット。タイムラインおよびイベン
トエンドポイントは、サーチのこの部分の結果を表しています。
eventSorting
このサーチのイベントがソートされているかどうか、およびソート順序を示
します (asc = 昇順、desc = 降順、none = 未ソート)。
14
isDone
サーチが完了したかどうかを示します。
isFailed
サーチ実行時に致命的なエラーがあったかどうかを示します。たとえば、
サーチ文字列に無効な構文があった場合にそれを示します。
isFinalized
サーチが完了 (実際の終了前に停止) されたかどうかを示します。
isPaused
サーチが一時停止されたかどうかを示します。
isPreviewEnabled
プレビューが有効になっているかどうかを示します。
isRealTimeSearch
サーチがリアルタイムサーチかどうかを示します。
isRemoteTimeline
リモートタイムライン機能が有効になっているかどうかを示します。
isSaved
サーチジョブが保存されているかどうかを示します。ジョブが最後に表示ま
たは選 されてから 7 日間、過去のサーチ結果をディスクに保管します。デ
フォルト値の 7 日間に優先する値を設定するには、limits.conf の
default_save_ttl の値を追加または 更します。
isSavedSearch
スケジューラーを使って実行する保存 みサーチかどうかを示します。
isZombie
サーチを実行しているプロセスは dead になったけれども、サーチが完了され
ていないかどうかを示します。
keywords
このサーチが使用するすべての肯定キーワード。肯定キーワードとは、NOT
句内にはないキーワードです。
label
このサーチが作成したカスタム名。
latestTime
サーチジョブの開始が設定されたもっとも い時間。進捗状況を示すために使
用できます。doneProgress の 明を参照してください。
numPreviews
このサーチジョブで現在までに生成されたプレビュー数。
messages
エラーとデバッグメッセージ。
performance
実行コストの他の表記法です。
remoteSearch
各サーチピアに送信されるサーチ文字列。
reportSearch
レポートコマンドが使用された場合のレポート 象サーチ。
request
サーチが splunkd に送信する GET 引数。
resultCount
サーチが返す結果数合計。別の言い方をすれば、スキャンしたイベント数
(scanCount で表される) の中で、実際にサーチ単語に一致したサブセット。
resultIsStreaming
サーチの最終結果をストリーミングを使って利用できるかどうかを示します
(たとえば、 換操作なし)。
resultPreviewCount
最新のプレビュー結果の結果行数。
runDuration
サーチ完了までにかかった時間 (秒)。
scanCount
スキャンされたまたはディスクから読み込まれたイベント数。
search
サーチ文字列。
searchProviders
通信したすべてのサーチピアのリスト。
sid
サーチ ID 番号。
statusBuckets
最大タイムラインバケツ数。
ttl
有効期間、またはサーチジョブの完了後、それが失効するまでの時間。
サーチに関するその他の情報へのリンクを示します。これらのリンクは利用
できない場合もあります。
その他の情報
タイムライン
フィールドサマリー
search.log
注意：サーチパフォーマンスのトラブルシューティングを行う場合、scanCount と resultCount のコストの違いを
正しく理解しておくことが重要です。デンスサーチの場合、scanCount と resultCount は等しくなります
(scanCount = resultCount)。スパースサーチの場合、scanCount は resultCount よりも大幅に大きな値になります
(scanCount >> resultCount)。サーチパフォーマンスを測定する際には、resultCount/時間の比ではさほど正確には
15
表せません。scanCount/時間の比を使用してください。一般的に、scanCount/秒のイベントレートが 10,000
20,000 イベント/秒の場合に、パフォーマンスは良好とみなされます。
デバッグメッセージ
サーチにエラーがある場合、これらのメッセージはサーチジョブ調査ウィンドウの上部に、DEBUG メッセージと
して表示されます (以前のバージョンでは、ダッシュボードのバナーとして表示されていた)。たとえば、結果に一
部のフィールドが存在しない場合、デバッグメッセージがその旨を通知します。
注意：サーチ完了までは、これらのメッセージは表示されません。
サ ー チジョブ調査の出力例
全時間実行した dedup サーチの実行コスト例を以下の示します。
* | dedup punct
[実行コスト] パネルのサーチコマンドコンポーネントは、以下のような感じで表示されます。
command.search コンポーネントおよびその下にある項目は、サーチの search コマンド部のパフォーマンス上の
影響を表しています (パイプ文字の前のすべて)。
command.prededup は、dedup コマンドに渡す前の search コマンドの結果処理のパフォーマンス上の影響を表し
ています。command.prededup の入力カウントは、command.search の出力カウントと一致し、command.dedup
の入力カウントは command.prededup の出力カウントと一致しています。この場合、command.dedup の出力カウ
ントは、サーチ完了時に返されるイベント数と一致していなければなりません ([サーチジョブのプロパティ] の下
の resultCount の値)。
回答
何か質問がありますか？「Splunk Answers」から、Splunk コミュニティに寄せられた、サーチジョブ調査の使用
方法に関する質問と回答をご覧ください。
サ ー チに合わせたサ ー チモ ー ドの設定
サーチモードセレクタを使って、ご自分のニーズに合わせたサーチを利用することができます。設定内容に じ
て、サーチで利用できるすべてのデータを表示したり (サーチ時間が長くなる)、さまざまな方法でサーチを高速
化/能率化したりすることができます。
サーチモードセレクタは、サーチバーの右上角にあります。[スマート] (デフォルト)、[高速]、および [詳細] モード
を利用できます。
16
高速および詳細モードは、サーチモードの両極を為しています。デフォルトのスマートモードは、実行するサーチ
の種類に じてこれらのモードを切り替えます。保存 みサーチを初めて実行する場合は、スマートモードで実行さ
れます。
高速モ ー ドの選
[高速] を選 した場合、パフォーマンスが優先され、重要ではないフィールドやイベントデータは無視されます。こ
の場合、サーチですべての候補データが返される訳ではありません。必要なデータのみが返されます。高速モード
を使用する場合の Splunk の動作を以下に示します。
フィールド 出を無効にします。フィールド 出は、Splunk がデフォルトフィールド以外の、host、source、
およびsourcetype などのフィールドの抽出に使用するプロセスです。これは、Splunk がデフォルトフィー
ルドとサーチの要件を たすために必要なフィールド (特定のフィールドをサーチする場合、それらのフィー
ルドが抽出される) の情報のみを返すことを表しています。
レポートサーチの実行時に、サーチ結果をレポート結果テーブルまたはビジュアル化でのみ表示します (レ
ポートコマンドを含むサーチ)。高速モードでは、レポートコマンドを含まないサーチについては、イベント
リストとイベントタイムラインのみが表示されます。
詳細モ ー ドの選
詳細モードを選 した場合、サーチ完了に時間がかかる場合でも、サーチにレポートコマンドが含まれている場合
でも、Splunk は可能なすべてのフィールドとイベントデータを返します。詳細サーチモードを使用する場合の
Splunk の動作を以下に示します。
可能なすべてのフィールドを 出します。これには、デフォルトのフィールド、自動サーチ-時間フィールド
抽出、およびすべてのユーザー定義のインデックス-時間およびサーチ-時間フィールド抽出が含まれていま
す。 出されたフィールドは、左側のサイドバーに表示されます。
結果のイベントリストビューを返して、サーチタイムラインを生成する。サーチにレポートコマンドが含ま
れている場合は、レポートテーブルと視 エフェクトも生成します。
レポートサーチを利用したいけれども、レポートに必要なフィールドが分からない場合、または正しいイベントを
要約しているかどうかを 証したい場合には、詳細モードを使用します。
注意：サーチを詳細モードで実行する場合、レポート高速化の恩恵は受けられません。サーチの保存時に [Turn
on acceleration] (高速化をオンにする) を選 したらサーチが高速化された場合に、そのサーチを詳細モードに切り
替えると、サーチ速度は くなり、高速化機能を利用しない場合と同じになります。
レポート高速化機能は、10 万件を超えるイベントに してレポートコマンドを利用したサーチを実行するような、
完了までに時間がかかるサーチを前提に設計されています。詳細は、『Knowledge Manager Manual』の「Save
searches and share search results」を参照してください。
スマ ー トモ ー ドの選
スマートモードはデフォルトのサーチモードです。また、保存 みサーチを初めて実行する場合に使用されるモー
ドでもあります。実行するサーチに して最良の結果を得ることを目的に設計されています。単にイベントをサー
チする場合、必要なすべてのイベントの情報が取得されます。レポートサーチを実行する場合、Splunk は完全性
よりも速度を重視して、レポート結果テーブルや視 エフェクトを直接提供します。
レポートコマンドを含まないスマートモードサーチを実行する場合、Splunk は詳細モードのように動作します。
たとえば：
可能なすべてのフィールドを 出します。
フルイベントリストおよびイベントタイムラインを生成します。レポートコマンドが必要なため、イベント
テーブルや視 エフェクトは表示されません。
17
レポートコマンドを含むスマートモードサーチを実行する場合、Splunk は高速モードのように動作します。たと
えば：
フィールド 出を無効にします。
イベントリストとイベントタイムラインの生成に時間を費やさず、レポート結果テーブルや視 エフェクトに
直接移動します。
レポートコマンドやレポートサーチの詳細は、『サーチマニュアル』の「レポートコマンドについて」を参照して
ください。
実 行中のサ ー チへのアクション
Splunk は、処理中のサーチを管理し、レポートやダッシュボードを作成するための一連のコントロールが用意さ
れています。サーチ実行中、これらのコントロールはサーチバーの下に青いボタンで表示されます。以下のような
コントロールがあります。
バックグラウンドに送信：フォアグラウンドで他の作業を行っている間、サーチを「バックグラウンド」に
移動します。バックグラウンドのサーチが完了したら、その旨が通知されます。バックグラウンドのサーチ
ジョブへのアクセスおよびその結果の確認は、[ジョブ] ページから行えます。
一時停止/再開：実行中のサーチを一時停止します。長い時間がかかるサーチを実行中に、一時的にそれを停
止するような場合に役立ちます。[再開] をクリックしてサーチを 続したり、[完了] をクリックしてサーチを
完了 (以下を参照) したりすることができます。
完了：サーチが完全に終了する前に処理を停止します。その時点までに取得した結果が表示されます。完了
させた結果を使ってレポートを作成できます。
キャンセル：処理中のサーチをキャンセルして、結果をすべて削除します。[ジョブ] ページには、最近キャ
ンセルされたサーチの一覧が表示されます。ただし、結果は削除されているため、[表示] リンクは表示され
ません。
ジョブ調査：サーチジョブ調査を開きます。これは、サーチの内容や Splunk が時間をもっとも費やしてい
る所を確認するためのツールです。サーチの実行中またはサーチ完了後にこの操作を行えます。詳細は、
「サーチジョブ調査の使用」を参照してください。
印刷：サーチ完了後、現在のページの結果タイムラインとイベントリストを印刷することができます。
バックグラウンドに移動したサーチの追跡、キャンセル、アラートなどの [ジョブ] ページの使用方法については、
『Knowledge Manager Manual』の「Supervise Your Search Jobs with the Job Manager」を参照してください。
[作成] オプションを使って以下の項目を作成できます。
ダッシュボードパネル...：サーチに基づいてダッシュボードパネルを生成し、それを新たなまたは既存
のダッシュボードに追加する場合にクリックします。ダッシュボードの詳細は、『Splunk データのビジュア
ル化マニュアル』の「UI を使ったダッシュボードの作成と編集」を参照してください。
アラート...：サーチに基づくアラートを定義する場合にクリックします。アラートは保存 みサーチをバック
グラウンドで実行します (スケジュールまたはリアルタイムで)。サーチでアラートに設定した条件と一致す
る結果が返されると、アラートが生成されます。詳細は、『アラートマニュアル』の「アラートについて」
を参照してください。
レポート...：長い時間がかかるサーチを実行しており、サーチが実際に完了する前にそれに基づくレポー
トを定義したい場合は、これをクリックしてレポートビルダーを起動し、レポートの定義を開始することが
できます。レポートビルダーの起動後もサーチは続行されます。レポートには、返されたイベントデータが
すべて反映されます。詳細は、『Splunk データのビジュアル化マニュアル』の「レポートビルダーによるレ
ポートの定義」を参照してください。
イベントタイプ...：イベントタイプを使って、共通の特徴を持つイベントを分類することができます。パイ
プ演算子またはサブサーチが含まれていないサーチは、このオプションを使ってイベントタイプとして保存
できます。詳細は、『Knowledge Manager Manual』の「About event types」および「Define and maintain
event types in Splunk Web」を参照してください。
スケジュールサーチ...：サーチ実行時に 回アクション (サーチ結果を特定の人々にメール送信するなど) を実
行するスケジュール みサーチを作成する場合に選 します。詳細は、『Knowledge Manager Manual』の
「Define scheduled searches」を参照してください。
18
より良いサ ー チの作成
このトピックでは、効率的なサーチを作成するために役立つ簡単なルールを 明していきます。サーチ速度には多
くの要因が影響します。サーチ 象のデータ量、サーチの内容、同時にサーチを実行するユーザー数に できるデプ
ロイ環境かどうかなど、さまざまな要因が考えられます。サーチ速度を最適化するために大切なのは、Splunk が
必要な作業以外を行わないようにすることです。
サ ー チの種類
サーチ最適化の推 事項は、実行するサーチの種類およびサーチ 象データの特徴によって異なります。一般的に
は、イベントの取得やレポートの生成など、何をするかに基づいてサーチを区別します。データセット内で目的の
イベントが頻繁に発生しているような場合、それを「デンスサーチ」と呼んでいます。データセット内で目的のイ
ベントが滅多に存在しない場合は、それを「スパースサーチ」と呼んでいます。
詳細は、「サーチについて」を参照してください。
raw イ ベ ン ト サ ー チ
raw イベントサーチは、取得したイベントを処理することなく、Splunk インデックスからそのままイベントを返
します。基本的にインデックスからイベントを取得する際には、目的のイベントのみを取得するように適切な指定
を行うことが大切です。そのためには、イベント固有のキーワードおよびフィールド/値のペアを使用します。大
量のデータにスパースサーチを実行する場合、同じデータセットにデンスサーチを行う場合と比べて時間がかかる
ことに注意してください。
最初からできる限りサーチを絞り込んで、ディスクから取得するデータ量を最低限に抑えるようにしてくだ
さい。たとえば、Web アクセスイベントのみに注目する場合は、当該データの特定のホスト、インデック
ス、またはソースタイプのみにサーチを制限します。
一度に複数のタイプのデータにまたがるサーチを行うことがほとんどない場合は、各データタイプを異なる
インデックスで分割し、サーチを特定のインデックスに限定します。たとえば、あるインデックスには Web
アクセスデータを、別のインデックスにはファイアウォールデータを保管します。複数のインデックスの設
定方法、および異なるインデックスのサーチ方法を参照してください。
サーチを特定の時間ウィンドウに限定します。たとえば、数分前に発生したエラーの原因を調査する場合
は、過去 1 週間 (-1w) ではなく過去 1 時間 (-1hr) のデータをサーチします。「サーチの時間範 について」を
参照してください。
レポート生成サーチ
レポート生成サーチは、インデックスから取得したイベントに して、さらなる処理を行います。結果セットに し
て 1 つまたは複数の統計関数を利用した、フィルタリング、 換、およびその他の操作を行えます。この処理はメ
モリー内で行われるため、ディスクから取得するイベント数を限定するほど、サーチが高速に行われます。
レポートを作成する場合、タイムラインビューではなく詳細グラフビューからサーチを開始してくださ
い。タイムラインビューでは、タイムラインの計算と作成のために大量の処理が行われます。詳細グラフ
ビューでサーチを実行すると、プレビューは無効になるため、それに伴う処理上のオーバーヘッドを減らせ
ます。
レポートはフィールドに依存しており、フィールドのすべての最適化ルールが適用されます。
情報密度
raw イベントを取得するにせよレポートを作成するにせよ、サーチ 象の情報がスパースなのかまたはデンスなの
かを考慮する必要があります。
スパースサーチは、大量のデータセット内で滅多に発生しない単一のイベントを 索するサーチです。これは
「干し草の山から 1 本の針を見つける」サーチと比喩されることもあります。たとえば、特定の IP アドレス
やエラーコードを探すサーチなどが げられます。スパースサーチを実行する際には、サーチ (タイムライン)
ビューを使用してください。このビューは、イベントからできる限りの関連情報の抽出を試みるため、独自
のイベントの 索に役立ちます。
デンスサーチは、多数のイベントをスキャン、レポートするサーチです。たとえば、発生したエラー数のカ
ウントや特定のホストからのすべてのイベントの 索などが げられます。大量のデータにまたがってイベント
をレポートするデンスサーチを実行する際には、詳細グラフビューを使用してください。このビューは、す
べてのフィールド情報を処理するのではなく、サーチを完了するために必要な情報のみを処理するように最
適化されています。
サ ー チでのフィ ー ルドの使用
サーチ時に抽出されるフィールドではなく、すでに抽出されているフィールド (インデックスが作成されたフィー
19
ルド) を使用すると、フィールドによるサーチを高速化できます。
データを効率的にサーチ、フィルタリングするために、できる限りインデックスが作成されたフィールドお
よびデフォルトのフィールドを活用してください。インデックス時に、Splunk は各イベントに共通の一連の
デフォルトフィールドを抽出します。これらのフィールドには、host、source、および sourcetype が含まれ
ます。サーチではできる限りこれらのフィールドを使ってデータをフィルタリングしてください。そうする
ことにより、必要最低限のデータのみを処理できます。たとえば、Web アクセスエラーに関するレポートを
作成する場合、レポートコマンドを実行する前に特定のエラーのみをサーチします。
sourcetype=access_* (status=4* OR status=5*) | stats count by status
サーチ時にフィールドを抽出すると、処理上のオーバーヘッドが生じます。サーチで追加のフィールドが不
要な場合は、サーチモードの設定でフィールド 出を無効にして、タイムラインビューでのパフォーマンスを
向上するか、または fields コマンドを使って結果に必要なフィールドのみを指定してください。
ただし、フィールド 出を無効にすると、サーチを実現するために必要なフィールド (サーチ 象の特定のフィールド
など)、および 、_time、host、source、sourcetype などのデフォルトフィールド以外のフィールドの自動抽出は
行われません。イベントから可能性がある各フィールドを抽出する手間がなくなるため、サーチの実行は高速化さ
れます。
デフォルトで [サーチモード] は、[スマート] に設定されています。レポートコマンドを使用するサーチ、データに
存在しているフィールドが分からないサーチ、サーチを絞り込むために追加フィールドが必要な場合などは、これ
を [詳細] に設定してください。
サーチモードの設定の詳細は、このマニュアルの「サーチを調整するためのサーチモードの設定」を参照してくだ
さい。
フィールドおよびフィールド抽出の詳細は『Knowledge Manager Manual』を、fields コマンドについては
『Search Reference Manual』を参照してください。
デ ー タの要約
大量のデータセットに してサーチを行う場合、非常に時間がかかることがあります。大量のデータに して定期的
にレポートを生成する場合は、サマリーインデックスを使って、レポートでもっとも頻繁に使用する値を事前に算
出してください。保存 みサーチをスケジュールして定期的に指標を収集し、raw データの代わりに要約したデー
タをレポートします。
レポート効率を向上するためのサマリーインデックスの使用方法に関する記事を参照してください。
サ ー チジョブ調査の使用
サーチジョブ調査は、サーチのパフォーマンスに関する問題のトラブルシューティング、およびイベントタイプ、
ルックアップ、その他のサーチ内コンポーネントなどのナレッジオブジェクトの実行コストの理解に利用できる
ツールです。このツールは、サーチの最適化方法をより良く判断できるように、サーチの動作を解析します。
詳細は、「サーチジョブ調査の使用方法」を参照してください。
イベントの取得
イベントの取得について
Splunk でサーチを実行する場合、サーチコマンドを使ってサーチ単語に一致するイベントデータを 索します。こ
れらのサーチ単語は、インデックスから取得するイベントを示す、キーワード、フレーズ、論理演算式、フィール
20
ド名/値のペアなどです。
イベントの取得方法の詳細は、「サーチコマンドの使用」を参照してください。
イベントデータが異なるインデックスや複数の分散サーチピア間にパーティション分割されている場合もありま
す。
複数のインデックスやサーバーにまたがるサーチについては、「インデックスおよび分散サーチピアからの
イベントの取得」を参照してください。
時刻でフィルタリングを行うと、タイムラインを使ってイベントの集合にズームインする場合でも、サーチ自体に
時間範 を適用する場合でも、イベントの取得が高速化されます。
詳細は、「タイムラインを使ったイベントパターンの調査」を参照してください。
詳細は、「サーチの時間範 について」を参照してください。
イベント、イベントデ ー タ、およびフィ ー ルド
一般的に「イベントデータ」とは、Splunk のインデックスに追加された後のデータを表しています。イベント自
体は、単一のアクティビティレコードまたはこのイベントデータのインスタンスです。たとえば、ログファイル内
の単一のログエントリが 1 つのイベントになります。Splunk は個別のイベントを、その時間情報により分割しま
す。あるイベントと他のイベントはタイムスタンプで区別されます。
イベントの例を以下に示します。
172.26.34.223 - - [01/Jul/2005:12:05:27 -0700] "GET /trade/app?action=logout HTTP/1.1" 200 2953
イベントには、情報のペア、またはフィールドが含まれています。データを追加してインデックスを作成すると、
Splunk は自動的にいくつかのフィールド (イベントのホストやデータソースの種類など) を抽出します。
サ ー チコマンドの使用
Splunk サーチを実行するには search コマンドを使用する必要があります。サーチパイプラインの先頭にこのコマ
ンドは暗示されています。実際にコマンドを起動する必要はありませんが、それを使用していることになります。
キーワード、フレーズ、フィールド、論理演算式、比較式を使って、Splunk インデックスから取得するイベント
を 密に指定することができます。デフォルトでは、キーワードとフレーズを使ってサーチを実行する場合、デー
タ内の raw イベントフィールド _raw に して照合が行われて、一致するイベントが取得されます。_time や tag な
どのフィールドをサーチ修飾子として追加していくと、_raw フィールドから抽出された情報に して、それらの照
合が行われます。
キ ー ワ ー ド、フレ ー ズ、ワイルドカ ー ド
キーワードや引用符で まれたフレーズ (またはサーチ修飾子以外の任意の語句) を含む文字列をサーチする場合、
Splunk は _raw フィールドと照合して、一致するイベントや結果を探します。キーワードとフレーズの例を以下に
示します。
web
error
web error
"web error"
引用符で まれたフレーズ "web error" は、その前のサーチとは異なることに注意してください。web error をサー
チした場合、「web」または「error」のいずれか、および「web」と「error」の両方を含むイベントが返されま
す。"web error" でサーチした場合は、フレーズ「web error」を含むイベントのみが返されます。
Splunk サーチ言語は、正規表現をサポートしています。もっとも単純な正規表現が、ワイルドカードのアスタリ
スク (*) です。* は、文字列内の任意の数の文字列と一致します。* でサーチを実行すると、それは「すべてにマッ
チ」を意味しており、上限値に至るまですべてのイベントが返されます。文字列の一部に * を使用すると、その文
字列に基づいて照合が行われます。例：
は、myhost1、myhost.ny.mydomain.com、myeventtype などに一致します。
は、myhost、yourhost などに一致します。
*host* は、host1、myhost3、yourhost27.yourdomain.com などに一致します。
my*
*host
目的のイベントに特有のサーチ単語を指定すれば、より良好な結果を得ることができます。たとえば、「denied」
(拒否) でサーチを実行するよりも、「access denied」 (アクセス拒否) の方が良い結果を得られます。イベントの
90% に「error」と言う単語が存在しているけれども、「sshd」は 5% にしか存在していない場合 (そして目的のイ
ベントには両方の単語が必要な場合)、サーチに「sshd」を入れるとより効率的に 索を行えます。
21
論理演算式
Splunk は論理演算子 AND、OR、および NOT をサポートしています。演算子は大文字でなければなりません。複数
の単語の間には、常に AND 演算子が存在するものとみなされます。つまり、web error は web AND error と同じ
です。
括弧を使って論理演算式をグループ化することができます。Splunk は論理演算式を次の順序で評価します。ま
ず、括弧内の式が評価されます。次に、OR 句が評価されます。最後に AND または NOT 句が評価されます。
web client error NOT (403 OR 404)
注意：一般的に包含条件の方が除外条件よりも良好な結果を得られます。"access denied" (アクセス拒否) の方が
NOT "access granted" (「アクセス許可」の否定) よりも素早く結果を得られます。
フィ ー ルド式
データの追加時に、Splunk は情報のペアを抽出して、それをフィールドとして保存します。一部のフィールドは
すべてのイベントに共通ですが、そうではないフィールドも存在しています。サーチ単語にフィールドを追加する
と、特定のイベントをより正確に探し出せます。
特定の HTTP ステータスエラーに関する Web アクセスログをサーチする場合、「web error 404」でサーチする代
わりに、以下のようにフィールドを使ってサーチを行えます。
status=404
詳細は、「フィールドを使ったイベントの取得」を参照してください。
ワイルドカードを使った複数フィールド値との照合
ワイルドカード文字のアスタリスクを使って、複数のフィールド値と照合することもできます。たとえば、以下の
サーチを実行すると、HTTP ステータス 400、401、402 などを持つイベントが返されます。
status=40*
比較演算子を使ったフィールド値の照合
比較演算子を使って、特定の値または一連のフィールド値を照合できます。
演算子
例
結果
=
field=foo
!=
field!=foo 「foo」と完全一致しない複数値フィールドの値。
<
field<x
値が x 未 の数値フィールド値。
>
field>x
値が x を超える数値フィールド値。
<=
field<=x
値が x 以下の数値フィールド値。
>=
field>=x
値が x 以上の数値フィールド値。
「foo」と完全一致する複数値フィールドの値。
たとえば、delay フィールドの値が 10 を超えるイベントを 索するには、以下のように指定します。
delay > 10
CASE() と TERM() を使ったフレ ー ズの照合
Splunk インデックス内の特定の用語またはフレーズをサーチする場合、CASE() または TERM() ディレクティブを
使って用語全体との完全一致を 索します。
CASE は、大文字小文字が一致する用語やフィールド値のサーチを実行します。
TERM は、一般的に副区切り文字として認識される文字 (ピリオドやアンダースコアなど) が含まれている場
合でも、括弧内のすべての文字を単一の単語とみなして照合を行います。
デフォルトでは、副区切り文字を含む文字列をサーチする場合、それはフレーズとして取り扱われます。サブ文字
列 (副区切り文字間の文字列) を論理積で連結した文字列に してサーチが実行され、その後結果が後処理でフィル
タリングされます。たとえば、IP アドレス 127.0.0.1 をサーチする場合、Splunk では 127 AND 0 AND 1 がサーチ
されます。
22
文字列全体がさほど一般的ではない場合でも、これらのサブ文字列の論理積が頻繁に登場する場合、このような
サーチは効率的ではありません。
そこで TERM(127.0.0.1) と指定してサーチを実行すると、この IP アドレスが単一の単語として取り扱われて、
raw データとの照合が行われます。
TERM は、文字列に副区切り文字が含まれており、それがスペースやカンマなどの主区切り文字で区切られてい
るような場合に特に役立ちます。実際に TERM は、主区切り文字で区切られている文字列には適用されません。
以下に例を示します。
Splunk がイベントを サーチ可セグメントに分割する方法の詳細は、『Getting Data In Manual』の「About
segmentation」を参照してください。
例
TERM(127.0.0.1) は以下のような raw データに一致します。
127.0.0.1 - admin
ただし、以下のようなデータは一致とみなしません。
ip=127.0.0.1 - user=admin
これは、「=」が副区切り文字で、イベントの IP アドレス部が「ip, 127, 0, 1, ip=127.0.0.1」のようにインデック
スが作成されるからです。
データが以下のような場合：
ip 127.0.0.1 - user admin
TERM(user admin) を実行しても、結果は返されません。スペースは主区切り文字のため、Splunk はフレーズ
「user admin」を単一の単語としてインデックス作成することはありません。
フィ ー ルドを使ったイベントの取得
フィールドは、イベントデータ内のサーチ可能な名前と値のペアです。データのインデックスを作成する際に、
Splunk は自動的にフィールドを抽出して、イベントデータに分かりやすいラベルを追加します。これらのフィー
ルドを使ってサーチを行ったり、フィールドを編集したり、他のナレッジを抽出してカスタムフィールドとして保
存したりすることができます。
インデックスおよび分散サ ー チピアからのイベン
トの取得
新しいインデックスの作成、サーチピアの追加、データの保管場所の管理はいつでも行えます。異なる複数のイン
デックスや分散サーチピアにまたがってデータを分割している場合、1 回に 1 つのインデックスやサーバーに し
てサーチを実行する必要はありません。複数のインデックスやサーバーに して一度にサーチを実行できます。
1 つまたは複 数 のインデックスサ ー チの指定
Splunk 管理者は、ユーザーがサーチするデフォルトのインデックスを設定することができます。ユーザーのロー
ルや 限に基づいて、1 つまたは複数のインデックスにアクセスさせることができます。たとえば、メインインデッ
クスのサーチのみを行えるようにすることも、公開されているすべてのインデックスのサーチを行えるようにする
ことも可能です。ユーザーはサーチを行う際に、これらのインデックスのサブセットを指定します (個別のイン
デックスまたは複数のインデックスに して)。ユーザーとロールの設定方法の詳細は、『Securing Splunk』の
「About users and roles」を参照してください。
インデックスの管理と複数インデックスの設定については、『インデクサーとクラスタの管理マニュアル』の「イ
ンデックスの管理について」を参照してください。
Splunk Web を 介 し た イ ン デ ッ ク ス ア ク セ ス の 制 御
[管理] >> [アクセス制御] >> [ロール] に移動します。ユーザーに割り当てられているロールを選 します。次の画面
の下部に、インデックスコントロールが記載されています。特定のロールが利用できるインデックスやデフォルト
のサーチインデックスなどを設定することができます。
構文
23
フィールド名と値を指定する場合と同じ方法で、複数のサーチ 象インデックスを指定できます。この場合、
フィールド名は index、フィールド値は特定のインデックス名になります。
index=<indexname>
ワイルドカード * を使って複数のインデックスを指定できます。たとえば、「mail」と「main」の両方のインデッ
クスをサーチする場合は、次のように指定します：
index=mai*
また、括弧を使って各インデックスに して異なるサーチを適用することもできます。詳細は例 3 を参照してくだ
さい。
注意：サーチバーに「index=」と入力する場合、ロールと 限に基づいて、先行入力にはサーチ可能なすべてのイ
ンデックスが表示されます。
例
例 1：すべての公開インデックスに してサーチを実行します。
index=*
例 2：すべての公開インデックスおよび内部インデックスに してサーチを実行します。
index=* OR index=_*
例 3：異なるサーチを異なるインデックスに分割します。この例では、3 つの異なるインデックス main、
_internal、および mail をサーチします。ここで、3 つのインデックスすべてに して「error」とマッチするイベン
トを探しますが、それに加えて main では「warn」、mail では「failed」とマッチするエラーを探します。
(index=main (error OR warn)) OR (index=_internal error) OR (index=mail (error OR failed))
例 4：異なる分散 Splunk サーバー上の複数のインデックスにまたがってサーチを実行します。
(splunk_server=local index=main 404 ip=10.0.0.0/16) OR (splunk_server=remote index=mail user=admin)
1 つまたは複 数 のサ ー チピアにまたがるサ ー チ
サーチヘッドから分散サーチを実行する場合、デフォルトではサーチを特定のサーチピア (インデクサーノード)
に制限することができます。これは、保存 みサーチやスケジュール みサーチでも可能です。Splunk サーチピアの
名前は、[splunk_server] フィールドの値として保存されます。分散サーチの詳細は、『Distributed Deployment
manual』の「About distributed search」を参照してください。
サーチピアを指定しない場合は、アクセス があるすべてのサーチピアが利用されます。アクセスできるデフォル
トのピアは、自分のプロファイルに関連付けられているロールと 限によって決まります。この設定は、Splunk 管
理者が行います。詳細は、『Securing Splunk』の「About users and roles」を参照してください。
特定のピアにサーチを制限する機能は、あるサーチピアの 延時間が大きく、デフォルトではそれを 象にサーチし
たくないような場合などに役立ちます。1 つまたは複数のサーチピアを指定すると、それらのサーバーのみがサー
チに含められます。
その他のフィールド名と値を指定する場合と同じ方法で、複数のサーチピアを指定できます。この場合、フィール
ド名は「splunk_server」、フィールド値は特定の分散ピア名になります。
splunk_server=<peer_name>
注意：サーチ元の Splunk インスタンス (サーチヘッド自身) を表すために値「local」を使用することができます。
splunk_server=local
フィールド名では大文字と小文字が区別されることに注意してください。大文字小文字が違っていると、その
フィールド名は認識されません。
例
例 1：指定したサーチピアから結果を返します。
error (splunk_server=NYsplunk OR splunk_server=CAsplunk) NOT splunk_server=TXsplunk
例 2：分散サーチピア「foo」または「bar」で、異なるインデックスをサーチします。
(splunk_server=foo index=main 404 ip=10.0.0.0/16) OR (splunk_server=bar index=mail user=admin)
24
目的のイベントが見つかりませんか？
Splunk に入力を追加すると、その入力はその時点で利用している App に追加されます。一部の App は、入力デー
タを独自のインデックスに書き込みます (たとえば、UNIX 版および Linux 版 Splunk App は、「os」インデックス
を使用します)。
Splunk に取り込んだはずのデータが見つからない場合は、適切なインデックスを使用しているかどうかを確認し
てください。使用しているロールに して、デフォルトインデックスのリストに App 固有のインデックスを追加し
なければならないこともあります。ロールの詳細は、『Securing Splunk』のロールに関するトピックを参照して
ください。
類似イベントの分類とグル ー プ化
イベントはイベントタイプとは異なっています。イベントは、データの単一のインスタンスです。たとえば、1 つ
のログエントリがイベントになります。イベントタイプは、イベントにラベルを付けてグループ化するために用い
られる分類方法です。
イベントに するイベントタイプ名は、イベントの eventtype と呼ばれる複数値フィールドに設定されます。これ
らのイベントグループ (例：SSH ログイン) は、任意のフィールド値と同じ方法でサーチできます。
ここでは、イベントの分類方法 (サーチをイベントタイプして保存) およびタグ付きフィールドのサーチ方法につ
いて 明していきます。イベントの詳細、Splunk のイベントの認識方法、インデックス作成時のイベントの処理方
法などについては、『Getting Data In Manual』の「Overview of event processing」を参照してください。
重要：サーチパイプラインをイベントタイプとして保存することはできません。つまり、サーチをイベントタイプ
として保存する場合、それにサーチコマンドを入れることはできません。
サ ー チの新規イベントタイプとしての保存
基本的に、イベントデータをサーチする場合、不要なイベントをすべて除去することになります。サーチ結果は類
似の特徴を持つイベントの集合になり、それらに総称名を指定することができます。
たとえば、異なるホストマシン上の失敗したログインを頻繁にサーチする場合、それらのイベントに するイベン
トタイプを保存して、failed_login と言う名前を付けられます。
"failed login" OR "FAILED LOGIN" OR "Authentication failure" OR "Failed to authenticate user"
このサーチをイベントタイプとして保存するには：
1. [作成] をクリックして、[イベントタイプ...] を選 します。
2. [イベントタイプとして保存] で、サーチに名前を指定します。このサーチ例では、「failed_login」と名付けま
す。
必要に じて、[サーチ文字列] フィールドを 更することができます。このフィールドには、先ほど実行したサーチ
が自動的に入力されています。
また、必要に じて [タグ] フィールドに、イベントタイプに適用するタグのリストを追加することもできます。詳
25
細は、後述のイベントタイプへのタグ設定に関する 明を参照してください。
3. [保存] をクリックするとイベントタイプ名が保存されます。
これで、任意のフィールドをサーチするのと同じ方法で、イベントタイプにマッチするすべてのイベントを手 に
サーチできるようになります。
たとえば、特定のホストマシン上の失敗したログインを調査することができます。
host=target eventtype=failed_login
また、疑わしいユーザーのアクティビティを調査することもできます。
user=suspicious eventtype=failed_login
typelearner を使った新規イベントタイプの 出
任意のサーチを typelearner コマンドに渡すと、Splunk が提案するイベントタイプを確認できます。デフォルト
で、typelearner はサーチ結果となるイベントの句読点を比較し、類似の句読点や単語を持つイベントをグループ
化します。
イベントをグループ化するために、異なるフィールドを指定することができます。typelearner は任意のフィール
ドと同じように機能します。結果は、このフィールドとフレーズを共通に保有する、一連のイベント (サーチ結果
からの) になります。
詳細と例については、『Search Command Reference』の「typelearner」を参照してください。
タグを使った類似イベントのグル ー プ化と 索
データ内で、関連するフィールド値でイベントをグループ化している場合があります。これらのフィールドのグ
ループを効率的にサーチするために、フィールド値にタグを割り当てることができます。抽出された任意のフィー
ルドに、1 つまたは複数のタグを割り当てられます (イベントタイプ、ホスト、ソース、またはソースタイプを含
む)。
イベントタイプには、それに関連する 1 つまたは複数のタグを割り当てられます。サーチをイベントタイプとして
保存する際に、またはイベントタイプ管理 ([管理] > [イベントタイプ])から、これらのタグを追加できます。この
ウィンドウのイベントタイプリストから、編集するイベントタイプを選 します。
イベントタイプにタグを追加したら、任意のタグのサーチと同じ方法でサーチを実施することができます。ファイ
アウォールイベントのサーチをイベントタイプ firewall_allowed として保存し、ログインイベントのサーチをイ
ベントタイプ login_successful として保存した場合を考えてみましょう。これらのイベントタイプにタグ
「allow」を設定しておけば、サーチを使って両方のイベントタイプのイベントを取得できます。
tag::eventtype="allow"
フィールド/値のペアにタグを設定することができます。また、フィールド名のエイリアスを設定することもでき
ます。タグの使用方法の詳細は、『Knowledge Manager Manual』の「Tag and alias field values in Splunk Web」
を参照してください。
タグ設定した値のサーチ
タグのサーチには 2 種類の方法があります。任意のフィールドの値に関連するタグをサーチする場合は、以下の構
文を使用できます。
tag=<tagname>
特定のフィールドの値に関連するタグをサーチする場合は、以下の構文を使用できます。
tag::<field>=<tagname>
ワイルドカードを使用したタグのサーチ
イベントタイプやタグを含め、キーワードやフィールド値をサーチする場合、ワイルドカード文字のアスタリスク
(*) を使用することができます。
たとえば、各種 IP アドレスに して複数のイベントタイプタグがある場合 (IP-src や IP-dst など)、以下のように
指定してそれらのすべてをサーチすることができます。
tag::eventtype=IP-*
26
タグに「local」を含むすべてのホストを性する場合は、以下のようにタグをサーチします。
tag::host=*local*
タグのないイベントタイプを持つイベントをサーチする場合は、論理演算式を使用します。
NOT tag::eventtype=*
タイムラインを使ったイベントパタ ー ンの調査
タイムラインは、各時点で発生したイベント数を視 的に表したものです。これは、時間の 過に伴うイベントの分
布を表しています。バー上にカーソルを移動すると、そのイベント数が表示されます。バーをクリックすると、そ
の時刻にドリルダウンできます。この方法でドリルダウンしても新たなサーチは実行されません。単に前のサーチ
から結果をフィルタリングするだけです。タイムラインを使ってイベントのパターンまたはクラスタを強調表示し
たり、イベントアクティビティのピーク (アクティビティのスパイク) を調査したりすることができます。
タイムラインオプションは、タイムラインの上にあります。ズームイン/アウトして、グラフのスケールを 更する
ことができます。タイムラインがさほど重要ではなく、イベントの表示領域を やしたい場合は、タイムラインを
折りたたむことも可能です。必要に じてそれをクリックして復元することができます。
タイムラインのスケ ー ルの 更
タイムラインは、線形または 数 (log) の 2 種類のスケールで表示できます。
以下の画像は、線形スケールでの第 2 四半期のすべてのイベントに するサーチ結果を表しています。
以下の画像は、 数スケールでの第 2 四半期のすべてのイベントに する同じサーチ結果を表しています。
27
イベントを調査するためのズ ー ムイン /アウト
ズームイン/アウトにより、注目する時間を 更することができます。たとえば、ズームインすることにより、タイ
ムラインのバーが時間から分に 化します。バーをクリックすると、その時点のイベントにドリルダウンします。
ズームアウトすると、たとえば時間単位から分単位ではなく、日単位のイベントに 化します。
タイムライン内の一連のバーをマウスでクリックアンドドラッグします。
サーチ結果が更新され、選 した時間範 内に発生したイベントのみが表示されます。
[ズームイン] をクリックすると、選 した期間のイベントのみを表示するように、タイムラインが更新されま
す。
タイムライン内の 1 つのバーをクリックします。
サーチ結果が更新され、選 したポイントの時点で発生したイベントのみが表示されます。
この場合も、[ズームイン] をクリックするとタイムラインが更新され、選 した時点のイベントのみが表示さ
れます。
タイムライン内のすべてのバーを選 する場合は (前の選 を取り消す)、[すべて選 ] をクリックします。このオプ
ションは、1 つまたは複数のバーを選 後、[ズームイン] または [ズームアウト] を選 する前にのみ利用できます。
時間範 の指定
サ ー チにおける時間範 について
28
何が問題なのかを特定する場合、時間が非常に重要になります。何か問題が起きた場合、正確に何が起きたのか分
からなくても、何らかの問題があると感じることもあるでしょう。同時刻に発生したイベントを調査することで、
結果間の相互関係を見つけ出し、主原因を特定する手がかりにできるかもしれません。あまりにも長期間のデータ
を調査することは、システムリソースを無駄にし、また結果が膨大で処理しきれなくなってしまいます。
この章では、サーチへの時間の追加方法を 明していきます。
時間範 メニューからの選
サーチへの時間修飾子の指定
リアルタイムサーチでのウィンドウの指定
サ ー チに適用する時間範 の選
サーチを実行する期間を指定するには、[時間範 ] メニューを使用します。
カスタム時間範 の定義
カスタムの日付範 を指定する場合は、ドロップダウンメニューから [カスタム時間...] を選 します。
次にポップアップウィンドウから [日付] を選 します。日付範 を手動入力することも、カレンダーポップアップか
ら選 することもできます。
たとえば、第二四半期 (4 月 6 月) に発生したイベントのみに注目する場合に、日付範 を選 します。
時間範 メニューは、選 した日付範 を示します。タイムラインには、選 した時間範 のみが表示されていることが
分かります。
注意：サーバーとは別のタイムゾーンで作業を行っている場合、時間ベースのサーチでは、インデックスが作成さ
れたサーバーからのイベントのタイムスタンプが用いられます。
カスタム相 時間範 の定義
1. タイムレンジピッカーで、[カスタム時間...] を選 します。
2. [範 タイプ] オプションから [相 ] を選 します。
3. [もっとも早い時刻] に値を入力します。
29
注意：またこのウィンドウを使って、もっとも早い時刻値のサーチ言語相当、および有効範 を確認することもで
きます。
選 できる時間範 のカスタマイズ
Splunk には、ビルトインの時間範 が用意されています。Splunk 管理者は一連の時間範 をカスタマイズして、そ
れをサーチ時にドロップダウンメニューから選 させることができます。時間範 の設定方法については、『管理マ
ニュアル』の「times.conf リファレンス」を参照してください。
サ ー チへの時間修飾子の指定
サーチを実行または保存する場合、以下の属性を使って絶 /相 時間範 を指定することができます。
earliest=<time_modifier>
latest=<time_modifier>
絶 時間範 の指定
正確な時間範 を指定する場合、time_modifier の構文は %m/%d/%Y:%H:%M:%S になります。. たとえば、2009 年 10
月 19 日午前 12 時 2009 年 10 月 27 日午前 12 時の時間範 は、以下のように指定します。
earliest=10/19/2009:0:0:0 latest=10/27/2009:0:0:0
「earliest」属性のみを指定した場合、デフォルトで「latest」は現在の時刻 (now) になります。一般的に、
「earliest」を指定せずに「latest」を指定することはありません。
サーチまたは保存 みサーチに時間範 を指定した場合、その値はドロップダウンメニューで選 した値に優先しま
す。ただし、サーチ文字列に直接指定した時間範 は、サブサーチには適用されません (ドロップダウンで選 した時
間範 が適用されます)。
相 時間範 の指定
時間の量を示す文字列を使って相 時間を指定することができます (整数と単位)。また、必要に じて「スナップ」
時間単位を使用することもできます。例：[+|-]<time_integer><time_unit>@<time_unit>。また、相 時間を指定
する際には、現在の時刻を表す now を使用できます。
1. 文字列は、時間量のオフセットを示すプラス (+) またはマイナス (-) 記号で開始します。
2. 時間量を数字と単位で定義します。1 つの時間量を指定する場合は、数字を省略できます。たとえば、「s」は
「1s」、「m」は「1m」と同じ扱いになります。サポートしている時間単位を以下に示します。
秒：s、sec、secs、second、seconds
分：m、min、minute、minutes
時間：h、hr、hrs、hour、hours
日：d、day、days
週：w、week、weeks
月：mon、month、months
四半期：q、qtr、qtrs、quarter、quarters
年：y、yr、yrs、year、years
30
3. スナップ (snap to) 時間単位を使用して、時間量を切り捨てた最寄りの時間またはもっとも い時間を指定するこ
とができます。このためには、時間量とスナップ (snap to) 時間単位を、「@」文字で区切ります。
相 時間修飾子は、「スナップ」時間単位としてのみ定義できます。たとえば、特定の曜日にスナップするには、
日曜日の場合は @w0、月曜日の場合は @w1 などのように指定します。
スナップ時間単位を指定しない場合、Splunk は自動的に秒にスナップします。
特殊時間単位
これらの省略形は、時間単位の特殊な事例とスナップ時間オフセットのために予約されています。
時間単位
明
earliest=0
(および latest!=0) の場合、サーチの開始時刻は UTC エポック 0 になります。
および latest=now または latest=<a large number> の場合、サーチは全時間実行
されます。違いは：
earliest=0
0
latest=now
を指定した場合、将来のイベントは返されません (デフォルト)。
を指定すると、将来のイベントが返されます。
latest=<a big number>
注意：将来のイベントとは、現在の時刻 now よりも後のタイムスタンプを持つイベントを指し
ています。
now
現在の時刻：
@q, @qtr, or
もっとも間近な四半期の開始 (1 月 1 日、4 月 1 日、7 月 1 日、10 月 1 日) にスナップします。
@quarter
w0, w1, w2,
曜日にスナップすることを指定します。日曜日は w0、月曜日は w1 のように指定します。週
にスナップする場合 (@w または @week)、日曜日にスナップまたは @w0 と同じことになります。
w3, w4, w5,
and w6
時間にスナップの詳細
最寄りのまたは一番 い時間にスナップする場合、Splunk は常に後方にスナップまたはもっとも い時間に切り捨て
た値 (指定時間以降ではない) にスナップします。たとえば、11:59:00 で時間に「スナップ」した場合、12 時では
なく 11 時にスナップします。
スナップ量の前に時間オフセットを指定しない場合、Splunk は「現在の時刻を指定された時間量にスナップ」す
るものと解釈します。たとえば、現在時刻が金曜日の午後 11 時 59 分で、土曜日にスナップするために @w6 を使
用した場合、結果は前の土曜日の午前12時 01 分になります。
相 時間修飾子の例
これらの例では、現在の時刻が 2009 年 2 月 5 日水曜日の午後 1 時 37 分 5 秒であると仮定しています。また、サ
マータイム境界のために、24h が常に 1d と同じになる訳ではないことに注意してください。
時間修飾子
明
結果となる時間
同等の修飾子
now
現在の時刻
Wednesday, 05 February 2009, 01:37:05 PM now
-60m
60 分前
Wednesday, 05 February 2009, 12:37:05 PM -60m@s
-1h@h
1 時間前、時間へ
Wednesday, 05 February 2009, 12:00:00 PM
-1d@d
昨日
Tuesday, 04 February 2009, 12:00:00 AM
-24h
24 時間前 (昨日)
Tuesday, 04 February 2009, 01:37:05 PM
-7d@d
7 日前、今日から 1 週間前 Wednesday, 28 January 2009, 12:00:00 AM
-7d@m
7 日前、分境界にスナップ Wednesday, 28 January 2009, 01:37:00 PM
@w0
今週の開始日
Sunday, 02 February 2009, 12:00:00 AM
+1d@d
明日
Thursday, 06 February 2009, 12:00:00 AM
+24h
今から 24 時間後、明日
Thursday, 06 February 2009, 01:37:05 PM
31
-24h@s
+24h@s
相 時間オフセットのチェ ー ン例
より詳細な相 時間定義を行うために、オフセットを「チェーン」することができます。
時間修飾子
@d-2h
明
結果となる時間
今日の開始 (午前 0 時) にスナップし、そこから 2 時間差し引きます。 昨晩の午後 10 時
-mon@mon+7d 1 ヶ月前の月の初日の午前 0 時にスナップして、7 日間を加算
先月の 8 日 (午前 0 時)
相 時間修飾子を使ったサ ー チ例
例 1：週の初めから現在の時刻 (now) までのサーチの Web アクセスエラー。
eventtype=webaccess error earliest=@w0
このサーチは、今週日曜日の午前 0 時から現在の時刻までの、マッチするイベントを返します。もちろん、この
サーチを月曜日の正午に実行したら、36 時間分のデータに該当するイベントしか返されません。
例 2：今週の営業日 (月 金) の Web アクセスエラー。
eventtype=webaccess error earliest=@w1 latest=+7d@w6
このサーチは、今週月曜日の午前 0 時から今週金曜日午後 11 時 59 分までの、マッチするイベントを返します。
このサーチを月曜日の正午に実行したら、12 時間分のデータに該当するイベントしか返されません。一方、この
サーチを金曜日に実行すれば、月曜日から金曜日の現在の時刻までのイベントが返されます。ただし、タイムライ
ンには週の営業日全体が表示されます。
例 3：先週の営業日からの Web アクセスエラー。
eventtype=webaccess error earliest=-7d@w1 latest=@w6
このサーチは、先週月曜日午前 0 時から、先週金曜日午後 11 時 59 分までの、マッチするイベントを返します。
サ ー チへのリアルタイム時間範 ウィンドウの指定
履歴サーチの時間境界は、サーチ実行時の時間に設定されます。リアルタイムサーチでは、時間境界は常時更新さ
れ、デフォルトで結果はサーチ開始時から累積されます。また、過去 30 秒などのように、時間範 がスライドして
いくウィンドウとなる時間範 を指定することもできます。スライドウィンドウを指定した場合、Splunk はその時
間量を使ってデータを蓄積します。たとえば、スライドウィンドウが 5 分間の場合、最初の 5 分間が 過するまで
はデータを参照することができません。この動作に優先させて、通常のリアルタイムサーチを実行する前に、初期
ウィンドウに履歴データをバックフィルすることができます (後述の「リアルタイムバックフィル」を参照)。
リアルタイム修飾子の構文
サーチをリアルタイムに実行するには、時間範 リストに事前定義されているリアルタイムのタイムレンジウィン
ドウを選 するか、または [カスタム時間...] で [リアルタイム] を選 して、独自のリアルタイムウィンドウを指定し
ます。
リアルタイムサーチの時間範 の構文は履歴サーチと同じですが、相 時間指定子の前に「rt」を付ける必要がありま
す (rt<時間修飾子>：rt[+|-]<time_integer><time_unit>@<time_unit>)。時間修飾子の構文は、「サーチへの時間
修飾子の指定」を参照してください。
これらの値は、サーチ言語内から (サーチ文字列でインラインに) 使用するようには設計されていませ
ん。times.conf 内で (タイムレンジピッカーにオプションを追加するため)、保存 みサーチダイアログ内でもっとも
早い/もっとも い時間範 を指定する場合、または直接 REST API を使って Splunk のバックエンドサーチエンジン
にアクセスする場合にも、これらの値を使用することができます。
リアルタイムサーチでタイムレンジウィンドウを使用する場合、直前に発生した一部のイベントが表示されない場
合があります。これは、イベントのタイムスタンプとイベント到着時刻の間の 延時間が原因で、想定通りの動作
です。タイムレンジウィンドウはイベントの到着時刻ではなく、イベント内のタイムスタンプに しているため、
時間ウィンドウ後に到着したイベントが表示されることはありません。
「全時間」リアルタイムサ ー チ
32
設定された時間ウィンドウ (30 秒、1 分、2 時間) 内で行われるリアルタイムサーチと「全時間」が設定されたリ
アルタイムサーチの間には、わずかな違いがあることに注意してください。
ウィンドウを使用するリアルタイムサーチでは、サーチ内のイベントはウィンドウから外れると消えてしま
います。また、サーチジョブ作成時刻よりも新しいイベントは、発生時にウィンドウに表示されます。
「全時間」リアルタイムサーチの場合、ウィンドウはイベント全体にまたがっています。そのため、ウィン
ドウに登場したイベントが消えることはありません。サーチジョブ作成時刻よりも新しいイベントは、発生
時に表示されます。
また、標準的なサーチでは、サーチで指定した時間範 内のイベントが消えることはありません。また、最新
のイベントは常にジョブ作成時刻よりも前になります (将来の日付のタイムスタンプを持つイベントを含む
サーチを除く)。
リアルタイムバックフィル
リアルタイムウィンドウを使用するサーチの場合，初期ウィンドウに履歴データをバックフィルするように設定で
きます。これは、2 つの手順を利用した単一のサーチとして実行します。まず、イベントをバックフィルするため
のサーチを行い、その次に通常のリアルタイムサーチを実行します。リアルタイムバックフィルにより、リアルタ
イムダッシュボードには開始時点から、時間の 過に伴う正確な視 エフェクトや統計的指標が表示されます。
リアルタイムバックフィルを有効にするには、limits.conf の [realtime] スタンザを使用します。
[realtime]
default_backfill = <bool>
* Specifies if windowed real-time searches should backfill events
* Defaults to true
サ ー チ結果のレポ ー ト
レポ ー トコマンドについて
サーチ文字列に直接レポートコマンドを追加して、レポートを生成し、サーチ結果を要約することができます。
レポ ー トコマンド入門
ここでは、レポートコマンドの主な分類と、サーチへの使用例を 明していきます。
主なレポートコマンド：
X 軸に使用するフィールドを指定
できます。
timechart：「傾向の推移」レポートを作成するために用いられます。常に _time が X 軸になります。
top：フィールドで一番多い値を表すグラフを表示します。
rare：フィールドで一番少ない値を表すグラフを表示します。
stats、eventstats、および streamstats：サマリー統計情報を表示するレポートを生成します。
associate、correlate、および diff：データのフィールド間の関連、相関、差異を表すレポートを作成しま
す。
chart：描画する任意のデータのシリーズを表示できるグラフ。グラフの
注意：以下の例で示すように、レポートコマンドは常にサーチコマンドの後にパイプ文字 (|) を使って指定しま
す。
chart、timechart、stats、eventstats、および streamstats
はすべて、統計関数と連携動作するように設計され
ています。統計関数には、以下のようなものがあります。
count、distinct count
mean、median、mode
min、max、range、percentiles
standard deviation、variance
sum
first occurrence、last occurrence
統計関数の詳細および使用例については、『Search Reference Manual』の「Functions for stats, chart, and
timechart」を参照してください。一部の統計関数は、timechart コマンドしか利用できません。
注意：レポートコマンドを使ったサーチはすべて、特定構造のデータを生成します。Splunk で利用できるグラフ
に じて、これらのデータ構造を特定の方法で設定する必要があります。たとえば、横棒グラフ、 棒グラフ、折れ
33
線グラフ、面グラフを生成できるサーチでも、円グラフは作成できないことがあります。詳細は、『データのビ
ジュアル化マニュアル』の「視 エフェクトのデータ構造要件」を参照してください。
リアルタイムレポ ー ト
リアルタイムサーチを使って、サマリーインデックスを使わずに、大量のデータからリアルタイムに指標を算出す
ることができます。ただし、ライブで 続的にデータストリームをレポートしているため、イベントストリームの
入力に伴ってタイムラインが更新され、テーブルやグラフはプレビューモードでしか表示できません。また、リア
ルタイムでの使用に適したサーチコマンドが存在しています (例：streamstats および rtorder)。
時間ベ ー スのグラフの作成
統計的な傾向の推移を表示するグラフを作成するには、timechart コマンドを使用します。このグラフでは、X 軸
に時間が使用されます。必要に じて他のフィールドでデータを分割することができます。この場合、split by
フィールドの各一意の値が、グラフに別個のシリーズとして表示されます。一般的にこれらのレポートは、折れ線
グラフまたは面グラフとして表示されますが、 棒グラフを使用することも可能です。
たとえば、このレポートは内部 Splunk ログデータを使って、Splunk プロセスによるインデックス作成の平均ス
ループット (インデックスの kbps) の推移を、プロセッサ別にビジュアル化します。
index=_internal "group=thruput" | timechart avg(instantaneous_eps) by processor
時間ベ ー スではないグラフの作成
任意のデータシリーズを表示できるグラフを作成するには、chart コマンドを使用します。timechart コマンドと
違い、chart コマンドで作成するグラフは任意のフィールドを X 軸として使用できます。over キーワードを使っ
て、X 軸に使用するフィールドを指定します。
注意：over キーワードは、chart コマンド固有のキーワードです。たとえば、これを timechart コマンドに使用す
ることはできません。すでに _time が X 軸に使用するデフォルトフィールドとして決められています。
たとえば、以下のレポートは Web アクセスデータを使用して、各平日の一意のビジター数平均を表します。
index=sampledata sourcetype=access* | chart avg(clientip) over date_wday
必要に じて他のフィールドでデータを分割することができます。この場合、split by フィールドの各一意の値が、
グラフに別個のシリーズとして表示されます。サーチに split by 句を指定する場合、over 句は split by 句の前に配
置してください。
以下のレポートは、指定期間内に各 clientip が処理したキロバイト数を host で分割したグラフを 生成します。
生成されたグラフでは、Y 軸に kb が、X 軸に clientip が使用されます。 延値はホストにより区分されます。レ
ポートビルダーを使ってこのレポートを積み上げ横棒グラフとして表示することができます。
index=sampledata sourcetype=access* | chart sum(kb) over clientip by host
別の例：サーバーでヒットした HTTP および HTTPS リクエストを区分した積み上げ横棒グラフを作成する場合を
考えてみましょう。この場合、まず着信ポート番号または着信 URL リクエストを含むサーチ時フィールド抽出の
ssl_type を作成します (これらの情報がログに記 されていると仮定)。サーチは以下のようになります。
sourcetype=whatever | chart count over ssl_type
レポートビルダーを使ってこのレポートを積み上げ横棒グラフとして表示することができます。
多い /少ないフィ ー ルド値のビジュアル化
top および rare コマンドを使って、もっとも多い値およびもっとも少ない値を表すグラフを作成できます。
この一連のコマンドは、ファイアウォール情報を調査して、システムが使用した上位 100 件の宛先ポートを表示
します。
index=sampledata | top limit=100 dst_port
一方以下のコマンドは、同じファイアウォールデータセットを使用して、拒否数がもっとも少ないソースポートを
示すレポートを生成します。limit を指定しない場合、デフォルトで top または rare で表示される値数は 10 件で
す。
index=sampledata action=Deny | rare src_port
34
複 な top コマンドの例
2 つのフィールドを持つ監視 象システムのアラートログから、インデックスを作成する場合を考えてみましょう。
msg
は CPU at 100% のようなメッセージです。
は、log01 のようなメッセージを生成するホストです。
mc_host
およびそれを送信した mc_host の値の上位値を表示するレポートを生成して、以下のようなテーブルを取得す
るにはどうしたら良いでしょうか？
msg
mc_host 別メッセージ
CPU at 100%
log01
log02
log03
ログファイルアラート
host02
host56
host11
このためには、mc_host 当たりの message のトップ値を探し (limit=1 を使って 1 件のみを返す)、次にメッセージ
count の降順に sort を実行します。
サマリ ー 統計情報を表示するレポ ー トの作成
フィールドに関連するサマリー統計を表示するレポートを生成するには、stats および eventstats レポートコマン
ドを使用します。
コマンドを有効活用するためには、split by 句を指定する必要があります。たとえば、以下のレポートコマ
ンドでは十分な情報が得られません。
stats
sourcetype=access_combined | stats avg(kbps)
これはソースタイプが access_combined のすべてのイベントの平均 kbps を算出しますが、単一の値です。結果と
なるグラフには、1 つの列しか表示されません。
このような場合 split by フィールドを利用することで、当該フィールドの統計情報を記載したレポートを生成する
ことができます。以下のレポートは、access_combined ログを調査して、ホスト別の平均スループット (kbps) を取
得する 棒グラフを生成します。
sourcetype=access_combined | stats avg(kbps) by host
コマンドのもう少し洗練された例を見ていきましょう。以下のレポートは、Splunk プロセスを CPU 使用率
の降順に表示します。
stats
index=_internal "group=pipeline" | stats sum(cpu_seconds) by processor | sort sum(cpu_seconds) desc
各イベントに関係するコマンドの集計結果のみが、各イベントにインラインに追加されることを除き、eventstats
コマンドは stats とまったく同じ働きをします。
eventstats
結果のフィールド名を指定するには、as 引数を追加します。これを利用すれば、前述の最初の例で
操作の結果を含む新規フィールド名を「avgkbps」にすることができます。
eventstats avg(kbps)
sourcetype=access_combined | eventstats avg(kbps) as avgkbps by host
この一連のコマンドを実行すると、kbps を含む各 sourcetype=access_combined イベントに、新しい avgkbps
フィールドが追加されます。avgkbps の値は、当該イベントの平均 kbps になります。
また、Splunk はその一連のコマンドを使って、ソースタイプが access_combined の全イベントの平均 kbps をホス
ト別に表示するグラフを生成します。
サ ー チでの 関 連、統計的相 関 、および差異の調査
35
サーチ結果の各フィールド値間の関連、類似性、差異を 索するには、associate、correlate、および diff コマンド
を使用します。
associate コマンドは、フィールド値のペアを使って相互に関連するイベントを判別します。たとえば、あるイベ
ントに「http://www.google.com/」の referer_domain があり、別のイベントに同じ URL 値の referer_domain があ
る場合、それらは関連していると判断されます。
コマンドにより得られた結果は、supcnt、supfreq、および improv 引数でチューニングできます。これ
らの引数の詳細は、『Search Reference Manual』の Associate コマンドに関連するページを参照してください。
associate
たとえば以下のレポートは、アクセスソースタイプをサーチして、最低 3 つのフィールド/フィールド-値のペアの
関連を持つイベントを判別します。
sourcetype=access* | associate supcnt=3
correlate コマンドは、フィールド間の統計的相関を算出します。このコマンドは cocur 操作を使って、同じ結果
セットに して 2 つのフィールドが存在する割合 (パーセント) を算出します。
以下のレポートは、eventtype=goodaccess の全イベントをサーチして、それらの全フィールド間の共起相関を算
出します。
eventtype=goodaccess | correlate type=cocur
diff コマンドは、2 つのサーチ結果間の差異を比較する場合に使用します。デフォルトでこのコマンドは、attribute
引数で特定のフィールド属性を指定しない限り、選 したサーチ結果の raw テキストが比較されます。
たとえば、以下のレポートはサーチで返された 44 番目と 45 番目のイベントに注目し、その IP アドレス値を比較
します。
eventtype=goodaccess | diff pos1=44 pos2=45 attribute=ip
複 数 のデ ー タシリ ー ズを持つグラフの作成
Splunk のレポートコマンドには、グラフ (または時間グラフ) に複数のデータシリーズを定義する直接的な方法が
ありません。ただし、stats コマンドと xyseries コマンドを組み合わせれば、複数のデータシリーズを定義する
ことが可能です。
コマンドと timechart コマンドは両方とも、グラフ作成用に表形式のデータを返します。X 軸はそれぞれ任
意のフィールドまたは _time になります。これらのコマンドと split-by フィールドを使用すると、各列が split-by
フィールドの一意の値を示す表が出力されます。
chart
一方 stats コマンドは、各行が group-by フィールドの、単一で一意の値の組み合わせを示す表を生成します。次
に xyseries コマンドを使って、グラフ化用のデータシリーズを再定義することができます。
たいていの場合は、「... | chart n by x,y」の結果を「... | stats n by x,y | xyseries x y n」を使ってシミュレーション
できます。(timechart と同等の結果は x = _time.)
シナリオ
アプリケーションサーバーのクラスタからのデータについてレポートを作成する場合を考えてみましょう。各サー
バーから収集されたイベントには、アクティブなセッション数や前回の更新後に処理されたリクエスト数などの情
報が含まれており、applications_servers インデックスに配置されています。セッションや負荷の分布を確認で
きるように、各サーバーインスタンスとインスタンス当たりのセッション数を同じ時間グラフに表示します。
理想的なのは、以下のような時間グラフレポートを実行、生成することです。
index=application_servers | timechart sum(handledRequests) avg(sessions) by source
しかし、時間グラフは複数のデータシリーズをサポートしていないため、代わりに以下のようなサーチを実行する
必要があります。
index=application_servers | stats sum(handledRequests) as hRs, avg(sessions) as ssns by _time,source |
eval s1="handledReqs sessions" | makemv s1 | mvexpand s1 | eval
yval=case(s1=="handledReqs",hRs,s1=="sessions",ssns) | eval series=source+":"+s1 | xyseries
_time,series,yval
明
36
... | stats sum(handledRequests) as hRs, avg(sessions) as ssns by _time,source
これは、stats コマンドを使って各ソース値の統計を算出しています。handledRequests 値の合計は hRs と名付
け、sessions の平均は ssns と名付けます。
... | eval s1="handledReqs sessions" | makemv s1 | mvexpand s1
また、eval コマンドを使って、stats コマンドからの各結果に単一値フィールド「s1」を追加します。次に、
makemv コマンドで sl を複数値フィールドに 換します。このフィールドで、最初の値は「handleReqs」、2 番目
の値は「sessions」になります。次に mvexpand で、s1 の各値に して個別のシリーズを作成します。
... | eval yval=case(s1=="handledReqs",hRs,s1=="sessions",ssns)
これは、eval コマンドを使って新たなフィールド yval を定義し、マッチしたケースに基づいて値を割り当てま
す。s1 の値が「handledReqs」の場合、yval には「hRs」が割り当てられます。また、s1 の値が「sessions」の
場合、yval には「ssns」が割り当てられます。
... | eval series=source+":"+s1
これは eval コマンドを使って新たな series フィールドを定義します。このフィールドは、host および s1 フィー
ルドの値を連結します。
... | xyseries _time,series,yval
最後に xyseries コマンドを使って、X 軸が _time、Y 軸が yval で、シリーズで定義されたデータを利用したグラフ
を作成します。
複 数 日の時間ごとの合計の比較
は傾向の推移を表すグラフを作成するための優れた手段ですが、できることに 密な境界制限が存在して
います。状況によっては、柔軟性に優れる chart コマンドの方が適している場合もあります。
timechart
ここでは、複数の日数に渡って収集された値を比較するための、chart の使用例を取り上げます。このような処理
は、timechart では行えません。
シナリオ
ほぼ同一の 2 つのサーチがあります。どちらも 24 時間の期間における P フィールドの時間ごとの合計値を表示し
ます。ただし、片方のサーチは過去 10 日間の期間をカバーしており、もう一方は 過去 9 日間の期間をカバーして
いると言う違いがあります。
サーチ 1：
earliest=-10d latest=-9d | timechart span="1h" sum(P)
サーチ 2：
earliest=-9d latest=-8d | timechart span="1h" sum(P)
ここでは、これらの 2 つのサーチ結果を組み合わせた棒グラフを作成し、10 日前の午後 3 時の P の合計と 9 日前
の午後 3 時の P の合計を並べて表示します。
解決策
コマンドでは、この目的を実現することはできません。しかし、chart コマンドを使用すれば簡単にこ
の目的を達成できます。両方の日をカバーするサーチを設定し、サーチイベント内で見つかった一意の date_hour
および date_day の各組み合わせに して、［sum of P］ (P の合計) 列を作成します。
timechart
サーチは以下のようになります。
earliest=-10d latest=-8d | chart sum(P) by date_hour date_day
これは、24 スロットを持つ単一のグラフを作成します。各スロットが、その日の各時間を表しています。各ス
ロットにはレポートの時間範 がカバーしている、2 日間の時間後との合計を比較するための 2 つの列が含まれて
います。
レポートサーチの詳細および作成方法については、『User Manual』の「Use reporting commands」を参照してく
ださい。
37
および timechart 関数の詳細については、『Search Reference Manual』の「Functions for stats, chart, and
timechart」を参照してください。
chart>
リアルタイムのサ ー チとレポ ー ト
リアルタイムサ ー チとレポ ー トについて
リアルタイムサーチとレポートでは、イベントのインデックスが作成される前にイベントをサーチし、イベントの
入力に伴ってレポートをプレビューすることができます。
バックグラウンドで 続的に実行されるリアルタイムサーチに基づくアラートを作成できます。このようなリアル
タイムアラートにより、スケジュール みサーチに基づくアラートよりもタイムリーに通知することができます。
詳細は、『アラートマニュアル』の「アラートについて」を参照してください。
また、ダッシュボードエディタ、パネルエディタ、シンプル XML を使って、カスタムダッシュボードにリアルタ
イムサーチ結果およびレポートを表示することもできます。ビジュアルダッシュボードエディタの詳細は、『デー
タのビジュアル化マニュアル』の「UI による簡単なダッシュボードの作成」を参照してください。
ビジュアルダッシュボードエディタよりも高度な機能を提供するリアルタイムダッシュボードの使用方法について
は、『Developer manual』の「Build a real-time dashboard」を参照してください。
注意：Splunk をそのままの設定で利用する場合、管理者ロールを持つユーザーのみがリアルタイムサーチを実
行、保存することができます。ロールの管理とユーザーへの割り当てについては、『Securing Splunk』の「Add
and edit roles」を参照してください。
リアルタイムサ ー チの仕組み
リアルタイムサーチでは、インデックス処理のために Splunk にイベントが入力されると、それに してサーチが行
われます。リアルタイムサーチを開始すると、Splunk はサーチのマッチ候補であることを示す、インデックス-時
間フィールドを含む到着イベントをスキャンします。これらのイベントは、UI 内でスキャンしたイベントとして
識別されます。この数は累積値で、サーチ起動時からスキャンしたすべてのイベントの合計を表しています。
リアルタイムサーチを実行すると、Splunk は定期的にスキャンしたイベントをサーチ基準に して評価して、実際
のマッチを探します。これらのイベントは UI で、一致したイベントとして識別されます。この値は、サーチに定
義したスライドしていくタイムレンジウィンドウ内に、現在存在しているマッチイベント数を表しています。その
ため、マッチするイベントの発見率が 加/減少するにつれて、時間の 過とともにこの値は 減します。Splunk Web
でサーチを実行している場合、サーチタイムラインには、選 した時間範 内に返されたサーチにマッチするイベン
トも表示されます。
1 分間のタイムレンジウィンドウを指定した、リアルタイムサーチの例を示します。この画面キャプチャの取得時
点では、サーチは実行後合計 3,105 件のイベントをスキャンしています。マッチしたイベント数 558 件は、サー
チ基準にマッチする過去 1 分間に識別されたイベント数を表しています。この値は次の 1 分間で 530 560 の範 で
動しています。これが急激に 加/減少した場合は、何か調査する必要がある注目すべき事態が発生した可能性があ
ります。
画面のように、タイムラインの右側には最新のイベントが表示されます。時間の 過に伴い、これが左側に移動し
ていき、タイムレンジウィンドウから完全に消えることになります。
リアルタイムサーチは、誰かがサーチを停止するかまたはサーチジョブを削除するまで 続的に動作します。何ら
かの理由でタイムアウトになることはありません。イベントが停止している場合は、パフォーマンス上の問題が発
生している可能性があります (下の「予想されるパフォーマンスと既知の制限事項」を参照)。
リアルタイムサーチは、ルックアップやトランザクションなどの高度な機能を含め、Splunk のすべてのサーチ機
能を活用することができます。また、streamstats や rtorder などの、特にリアルタイムサーチと連携動作するこ
38
とを前提に設計されたサーチコマンドも用意されています。
Splunk Web でのリアルタイムサ ー チとレポ ー ト
Splunk Web でのリアルタイムサ ー チ
リアルタイムサーチの実行とリアルタイムレポートの作成は、標準のサーチを実行する場合と同じ方法で行えま
す。ただし、ライブで 続的にデータストリームをサーチするため、イベントストリームの入力に伴ってタイムラ
インが更新され、またレポートはプレビューモードでしか表示できません。また、標準のサーチよりもリアルタイ
ムサーチに適したサーチコマンドが存在しています。たとえば、streamstats および rtorder は、リアルタイムサー
チでの使用を前提に設計されています。
Splunk Web でリアルタイムサーチを開始するには、[時間範 ] メニューから事前設定されているリアルタイムのタ
イムレンジウィンドウを選 します (例：[30 秒] または [1 分] など)。また、リアルタイムサーチに適用する、スライ
ドするタイムレンジウィンドウを指定することもできます。
このサーチを実行すると、到着したページビューイベントを参照することができます。
eventtype="pageview"
入力パイプラインから入力される raw イベントは、時間順に並んではいません。rtorder コマンドを使用すれば、
リアルタイムサーチからのイベントをバッファに格納し、それを時間の昇順に出力することができます。
以下の例では、過去 5 分間のページビューイベントをバッファに保管し、5 分以上 過したイベントを時間の昇順
に送信します。新たに受信したイベントが 5 分以上前の時刻を持つ場合、その時刻以降のイベントをすでに送信し
ているならば、当該イベントを破棄します。
eventtype="pageview" | rtorder discard=t buffer_span=5m
リアルタイムサーチは、イベントのストリームに依存しています。そのため、イベントを生成しない | metadata
や、単にファイルを読み取るだけの | inputcsv などのコマンドをリアルタイムサーチに利用することはできませ
ん。また、サーチ結果を | outputcsv に送信しても、リアルタイムサーチを完了させない限り、CSV ファイルに
書き込まれることはありません。
Splunk Web でのリアルタイムレポ ー ト
大部分の Web ページにアクセスする IP アドレスをプレビューするには、レポートを実行します。この場合、top
コマンドは、clientip (クライアント IP)、count (カウント)、および percent (パーセント) の 3 つの列を持つテーブ
ルを返します。データストリームが到着すると、テーブルが新たな値で更新されます。
eventtype="pageview" | top clientip
各ページビューイベントに して、現在までに確認されたイベント数を表す count フィールドを追加します (ただ
し、現在のイベントはカウントに入れない)。
eventtype="pageview" | streamstats count current=false
リアルタイムレポートにドリルダウンすることもできます。ただし、リアルタイムにドリルダウンを行っても新た
なリアルタイムサーチが行われる訳ではありません。代わりに、すでに取得され、インデックスが作成されたイベ
ントの履歴サーチが実行されます。詳細は、『User Manual』の「Understand table and chart drilldown actions」
を参照してください。
CLI でのリアルタイムサ ー チとレポ ー ト
CLI でリアルタイムサーチを実行するには、「search」の代わりに「rtsearch」を使用します。
./splunk rtsearch 'eventtype=pageview'
サーチ結果内の単語を強調するには、highlight コマンドを使用します。以下の例では、ページビューイベントの
「GET」を強調表示しています。
./splunk rtsearch 'eventtype=pageview | highlight GET'
デフォルトでは、サーチ結果の行の折り返しが有効になっています。行の折り返しを無効にするには、-wrap オプ
ションを使用します。
./splunk rtsearch 'eventtype=pageview' -wrap 0
39
CLI でのリアルタイムレポートもプレビューモードで表示され、データの到着に伴い更新されていきます。
./splunk rtsearch 'error | top clientip'
結果のプレビューを抑制するには、-preview オプションを使用します。
./splunk rtsearch 'error | top clientip' -preview false
プレビューをオフにしても、Splunk Web の [ジョブ] ページからサーチを管理することができます (保存、一時停
止、完了、または削除)。サーチを完了させると、レポートテーブルが表示されます。詳細は、このマニュアルの
「ジョブ管理を使ったサーチジョブの管理」を参照してください。
ウィンドウを使ったリアルタイムサーチを実行するには、earliest_time および latest_time パラメータを使用し
ます。
rtsearch 'index=_internal' -earliest_time 'rt-30s' -latest_time 'rt+30s'
注意：リアルタイムサーチは API レベルでのみ設定できます。サーチ文字列内に時間範 修飾子を指定しても、そ
のようなサーチは機能しません。REST API 内で、earliest_time および latest_time パラメータには同名の引数
を設定する必要があります。
CLI ヘルプリファレンスで、すべての CLI コマンドの情報を参照することができます。詳細は、このマニュアルの
「CLI でのヘルプの使用」を参照してください。
リアルタイムサ ー チとレポ ー トの、予想されるパ
フォ ー マンスと 既 知の制限事項
Splunk のパフォーマンスは、インデクサーに膨大な負荷がかかっておらず、多数のリアルタイムサーチを同時に
実行しない限り、十分に許容できるものと想定されています。ただし、多数のリアルタイムサーチを同時に実行す
ると、大量のデータが存在する環境ではパフォーマンスやネットワークに大きな影響を与えます。
インデックス作成のスル ー プット
リアルタイムサーチをプランニングする場合、以下の両方のパフォーマンスに与える影響を考慮する必要がありま
す。
ライブイベントを転送する必要があるサーチピア。
ライブイベントの集約されたストリームを処理する必要があるサーチヘッド。
サーチピアで行われる処理が多くなれば、サーチヘッドで必要な処理は減少します。また、逆も同 です。サーチ
ピアは総合的なシステム機能に影響してきます。そのため、ライブイベントのフィルタリングであまり大きな負荷
をかけないようにしてください。しかし、サーチピアで何もフィルタリングを行わないと、サーチヘッドにすべて
のライブイベントを送信するために必要な処理能力と帯域幅のコストが高くなる可能性があります (特に複数のリ
アルタイムサーチを同時実行する場合)。
サーチヘッドがインデクサーに追随できない場合、インデックスプロセッサ上のキューはイベントを破棄しま
す。ただし、イベントにはシーケンス番号があり、これを使って破棄されたイベント数とその時期を確認すること
ができます。
リアルタイムサーチと履歴サーチの同時実行
ハードウェアの能力が許す範 内で、複数のリアルタイムサーチと履歴サーチを同時実行することができます。同
じユーザーまたは異なるユーザーによる、個別のサーチに関する制限はありません。
リアルタイムサーチの同時実行
複数のリアルタイムサーチを同時実行すると、インデックス作成能力に 影響を与えてしまいます。リアルタイム
サーチ機能は、スパース (希少語) サーチのリアルタイムアラート向けに最適化されており、それと引き替えに待
ち時間と信頼性を改善するインデックス能力が犠牲になっています。
リアルタイムサ ー チウィンドウ
ウィンドウを使ったリアルタイムサーチは、ウィンドウを使わないサーチよりもコストが高くなっています。ウィ
ンドウの内容を管理、プレビューするために必要な操作のため、ウィンドウを利用したリアルタイムサーチの処理
が、頻繁なインデックスの作成に追いつかないこともあります。Windows を利用するサーチで、期待している数
のイベントが表示されない場合は、ウィンドウを利用しないサーチをお試しください。イベント数のみに注目する
40
場合は、サーチで「timechart count」を使用してみてください。
詳細は、「サーチへのリアルタイム時間範 ウィンドウの指定」を参照してください。
リアルタイムサ ー チの利用の制限方法
リアルタイムサーチの過度の使用はパフォーマンスに 影響を与えるため、必要に じてその利用を制限しなければ
ならないこともあります。Splunk にはこのためのさまざまな方法が用意されています。以下の作業を行えます。
特定のインデックスの indexes.conf を編集して、インデクサーレベルでリアルタイムサーチを無効にする。
特定のロールおよびユーザーに してリアルタイムサーチを無効にする。
limits.conf を編集して、同時に実行できるリアルタイムサーチ数を減らす。
limits.conf を編集して、リアルタイムサーチのインデクサーサポートを制限する。
indexes.conf でリアルタイムサ ー チを無 効 にする
リアルタイムサーチにより、インデクサーに非常に負担がかかることがあります。インデクサー上でリアルタイム
サーチを無効にする場合は、インデクサーの indexes.conf で [default] 設定を編集します。
[default]
enableRealtimeSearch = <bool>
注意：複数のインデクサーに接続するサーチヘッドは、リアルタイムサーチが有効になっているインデクサーから
引き続きリアルタイムサーチ結果を取得することができます。
ユ ー ザ ー またはロ ー ルに してリアルタイムサ ー チを無 効 にする
リアルタイムサーチは、Splunk Web の [管理] > [アクセス制御] から、特定のユーザーやロールに割り当てられる
限です。デフォルトで、rtsearch 限は、Admin (管理者) および Power (パワー) ロールに割り当てられています。
User (ユーザー) ロールには割り当てられていません。rtsearch 限のないロールは、サーチヘッドが接続している
インデクサーに関係なく、そのサーチヘッドでリアルタイムサーチを実行することはできません。
リアルタイムサ ー チの制限の設定
の [search] スタンザを使って、システム上で同時に実行できる最大リアルタイムサーチ数を 更する
ことができます。
limits.conf
[search]
max_rt_search_multiplier = <decimal number>
realtime_buffer = <int>
max_rt_search_multiplier
履歴サーチの最大数に数字が乗算されて、最大同時リアルタイムサーチ数が決まります。デフォルトは 3 で
す。
注意：リアルタイムサーチの最大数は、以下のように算出されます。 max_rt_searches =
max_rt_search_multiplier x max_hist_searches
realtime_buffer
UI からのリアルタイムサーチ用に保持するアクセス可能イベントの最大数。1 以上でなければなりません。
デフォルトは 10000 です。
リアルタイムバッファがこの制限値に達すると、それは循環バッファとして動作します。
リアルタイムサ ー チのインデクサ ー 制限の設定
の [realtime] スタンザを使用して、リアルタイムサーチのインデクサーサポートのデフォルト設定
を 更することができます。個別のサーチに REST API 引数を使って、これらのオプションに優先させることがで
きます。
limits.conf
[realtime]
queue_size = <int>
blocking = [0|1]
max_blocking_secs = <int>
indexfilter = [0|1]
41
queue_size = <int>
各リアルタイムサーチのキューサイズ。0 より大きな値でなければなりません。
デフォルトは 10000 です。
blocking =[0|1]
キューが 杯になった場合、インデクサーをブロックするかどうかを示します。
デフォルトは偽 (0) です。
max_blocking_secs = <int>
キューが 杯の場合に、ブロックする最大時間。blocking = false の場合、このオプションは何も意味を持ち
ません。
0 を設定すると「無制限」になります。
デフォルトは 60 です。
indexfilter = [0|1]
効率のために、インデクサーがイベントを事前フィルタリングするかどうかを示します。
デフォルトは真 (1) です。
統計の算出
統計の算出について
この章では、イベントのサマリー統計の算出方法について 明していきます。
サーチ言語には、さまざまな統計コマンドが用意されています。このマニュアルの「サーチ結果のレポー
ト」で、すでにいくつかの例を取り上げています。この章では、「stats コマンドおよび関数の使用」から始
めて、さらに詳細に内容を 明していきます。
また、「stats と eval 式および関数の使用」の 明に従って、統計情報を算出することもできます。
また、stats と chart を使って作業を行う場合、「サーチ結果へのスパークラインの追加」を行うことも可能
です。
stats コマンドおよび 関数 の使用
ここでは、chart、timechart、stats、eventstats、および streamstats コマンドおよび統計関数の使用方法につ
いて 明していきます。統計関数には、以下のようなものがあります。
count、distinct count
mean、median、mode
min、max、range、percentiles
standard deviation、variance
sum
first occurrence、last occurrence
統計関数の詳細および使用例については、『Search Reference Manual』の「Functions for stats, chart, and
timechart」を参照してください。一部の統計関数は、timechart コマンドしか利用できません。
stats と eval 式および 関数 の使用
このトピックは作成途中です！
ここでは、stat 内での eval 式と関数の使用方法について 明していきます。
eval コマンドの詳細と構文については、『Search Reference Manual』の eval コマンドに関する 明を参照し
てください。
eval 関数の詳細は、『Search Reference Manual』の「Functions for eval and where」を参照してくださ
い。
また、このマニュアルの次の章にある「フィールドの評価と操作」には、他の eval コマンドの使用方法が
明されています。
例 1：一致したイベントとの一意の 数
42
エラーが発生した IP アドレス数を数えたい場合を考えてみましょう。これは、イベントのサーチと似ています。
特定のコードでフィルタリングして、stats コマンドで IP アドレス数を数えます。
... | search error=404 | stats dc(ip)
これを実現するための eval 式は以下のようになります。
... | stats dc(eval(if(error==404),ip,NULL))) AS dc_ip
サ ー チ結果へのスパ ー クラインの追加
および chart を使ったサーチを行う場合、結果テーブルにスパークラインを追加することで、その有用性を
高め、総合的な情報密度を向上することができます。スパークラインはテーブルのセル内に表示されるインライン
グラフで、各行のプライマリキーに関連する時間ベースの傾向を表示することを目的にしています。
stats
たとえば、過去 15 分のイベントに して実行する以下のサーチを考えてみましょう。
index=_internal | chart count by sourcetype
このサーチは、過去 15 分に _internal にインデックス作成された、ソースタイプに するイベント数を表す、2 つ
の列を持つ結果テーブルを返します。最初の列は、過去 1 時間の _internal インデックスイベントセット内で見つ
かった各 sourcetype を記載しています。これが、テーブルのプライマリキーです。2 番目の列 count には、記載
されている各ソースタイプのイベント数が表示されます。
サーチ自体に sparkline 関数を追加して、このサーチ結果にスパークラインを追加できます。
index=_internal | chart sparkline count by sourcetype
このテーブル内の結果は前の結果とほとんど同じです。ただし各行には、記載されている各ソースタイプのイベン
ト数の、過去 15 分間の傾向を表すスパークライングラフが表示されます。
これで、以前には分からなかったデータのパターンを手 に確認することができます。15 分の期間の 3/4 当たり
で、サーチ活動が大半の index=_internal ソースタイプに して 動を与えていることが明確に分かります。ま
た、splunkd はこの期間全体に渡って、ほぼ通常通りにハートビートを実行しているように見えます。
注意：テーブル内の各スパークラインには、当該スパークラインで表されているその他のイベントに関連する情報
が表示されます。ただし、他のスパークラインに関連する情報ではありません。あるスパークラインのピーク値が
他のスパークラインのピーク値と同じである必要はありません。
stats および chart コマンドでのスパ ー クラインの使用
スパークライン機能は常に、chart および stats サーチと一緒に使用します。スパークラインは、これらの 2 つの
サーチコマンド用の関数です。それ自体はコマンドではありません。スパークラインの機能は、どちらのサーチコ
マンドでも同じです。
43
注意：スパークライン自体をダッシュボードグラフの視 エフェクトとして使用することはできません。ただし、
ダッシュボードパネルにスパークラインを表示するテーブル視 エフェクトを入れることは可能です。詳細は、
『データのビジュアル化マニュアル』の「ビジュアル化リファレンス」を参照してください。
および stats コマンドの詳細、sparkline 関数の構文などについては、『Search Reference Manual』の
「chart」および「stats」を参照してください。
chart
例 ： Stats、 ス パ ー ク ラ イ ン 、 お よ び 地 震 デ ー タ
ここでは、スパークラインを使って地震データに関する追加情報を得るための、stats サーチの使用例を 明してい
きます。
これらの例は、USGS Earthquakes Web サイトからダウンロードされたデータ (2011 年 9 月 13 20 日の 7 日間
の期間) を使用しています。データは過去 7 日間に発生した地震について、ソースネットワーク (Src)、ID
(Eqid)、version、date、location、magnitude、深さ (km)、および報告ステーション数 (NST) を含むカンマ区切
り形式の ASCII テキストファイルです。
テキストファイル M 2.5+ earthquakes, past 7 days をダウンロードして CSV ファイルとして保存し、それを
Splunk にアップロードしてください。Splunk はフィールドを自動的に抽出します。ダウンロードデータはダ
ウンロード時から過去 7 日間のデータになるため、結果は下記の例とは異なることに注意してください。
ここでは、USGS Earthquakes データを使って過去 1 週間に地震発生頻度の高かった地域を表示します。また、各
地域における地震の平均マグニチュードを表す列も追加します。以下のサーチを使用することができます。
source=eqs7day-M2.5.csv | stats sparkline count, avg(Magnitude) by Region | sort count
このサーチは、以下のテーブルを返し、過去 1 週間の地震発生頻度が高い地域の地震発生数の推移を表すスパーク
ラインを表示します (この例では、Region がテーブルのプライマリキーになります)。
地震発生数上位 10 の地域間の地震の分布の違いが明確に分かります。Southern Alaska や Virgin Islands などの地
域は、比較的 続的に地震が発生していますが、Fox Islands や Vanuatu ではある時点に地震活動が集中していま
す。
スパークライン上にカーソルを移動すると、特定の地域の最低/最大カウントが分かります。この例では、
Southern Alaska で過去 1 週間に発生した地震で、各日に発生した地震数は一番少ない日で 1 回、一番多い日で 6
回であることが分かります。
スパークラインに地震発生回数だけでなく、各地域の地震の相 平均マグニチュードも表示させたい場合はどうし
たら良いでしょうか？別の言い方をすれば、スパークラインの折れ線グラフが、各「時間バケツ」 (セグメント)
の平均マグニチュードを表すようにするにはどうしたら良いでしょうか？
以下のサーチを試してください。
source=eqs7day-M2.5.csv | stats sparkline(avg(Magnitude),6h) as magnitude_trend, count, avg(Magnitude)
by Region | sort count
このサーチは、各地域において、スパークラインの各セグメント内で発生した地震の、平均マグニチュードを表す
スパークラインを生成します。
ただし、それだけではありません。スパークラインをより小さな時間単位に分割します>前のテーブル例では、ス
パークラインが日単位に分割されていました。スパークライン内の各データポイントは、24 時間の期間における
イベントカウントを表しています。これが、それらのスパークラインが短い理由です。
サーチ言語に 6h を追加すると、この設定がデフォルト値に優先され、スパークラインが 6 時間単位で表示されま
44
す。こうすることにより、指定期間内の各イベントの分布が、より把握しやすくなります。
また、このサーチではスパークラインの列名をより分かりやすい、「magnitude_trend」 (マグニチュードの傾向)
に 更します。
ここでは、Honshu, Japan で発生した地震のマグニチュードがほぼ同じなのに して、Puerto Rico で発生した地震
はマグニチュードの強弱にかなりのばらつきがあることが分かります。また、Southern California では比較的弱い
地震が 7 日間の期間の最初と最後に発生していることが一目で理解できます。また、前回のサーチで考えたように
Virgin Islands で発生する地震が一定の頻度で発生している訳ではないことが、今回のサーチでは分かります。ま
た、Honshu の地震は前のテーブルと比べてより定期的に発生していることが分かります。
フィ ー ルドの評 価 と操作
フィ ー ルドの評 価 と操作について
この章では、新規フィールドの評価、既存のフィールドの操作、新規フィールドによるイベント情報の強化、およ
び複数値フィールドの解析などを行うためのサーチコマンドについて 明していきます。
新規フィールド評価の主役となるのが、eval コマンドとその関数です。
eval コマンドおよび 関数 の使用
ここでは、eval コマンドとその関数を使った、任意の式による新規フィールドの評価について 明していきます。
ルックアップを使ったルックアップテ ー ブルから
のフィ ー ルドの追加
イベント内のフィールドを、ルックアップテーブルなどの外部ソースのフィールドと照合し、マッチする情報を
使って他の情報をイベントに追加することができます。
ルックアップテーブルは、静的 CSV ファイルまたは Python スクリプトの出力になります。また、サーチ結果を
CSV ファイルに出力し、それをルックアップテーブルとして使用することもできます。フィールドルックアップ
の詳細は、『Knowledge Manager Manual』の「Configure field lookups」を参照してください。
フィールドルックアップの設定後は、サーチ App から lookup コマンドを使って起動できます。
例：名前が dnslookup のフィールドルックアップは、DNS ルックアップおよび逆引き DNS ルックアップを実行
し、ホスト名または IP アドレスを引数として受け取る Python スクリプトを参照します。lookup コマンドを使っ
て、イベント内のホスト名値とテーブル内のホスト名値を照合し、イベントに する IP アドレス値を追加すること
ができます。
... | lookup dnslookup host OUTPUT ip
Splunk スクリプト external_lookup.py の詳細な使用例については、Splunk ブログの「Reverse DNS Lookups for
Host Entries」を参照してください。
サ ー チコマンドによるフィ ー ルドの抽出
45
多彩なサーチコマンドを使って、フィールドをさまざまな方法で抽出することができます。
rex は Perl 正規表現名前付きグループを使って、フィールド抽出を行います。
extract (「キー/値」の場合は kv) は、デフォルトのパターンを使って明示的にフィールド/値を抽出します。
multikv は、複数行、表形式イベントのフィールド/値を抽出します。
spath は、XML および JSON 形式のイベントデータのフィールド/値を抽出します。
xmlkv および xpath は、XML 形式イベントデータのフィールド/値を抽出します。
kvform は、あらかじめ定義されたテンプレートに基づいてフィールド/値を抽出します。
rex、extract、multikv、xmlkv、および kvform コマンドの使用例も参照してください。
正規表現を使ったフィ ー ルドの抽出
rex サーチコマンドは、サーチ文字列に指定した Perl 正規表現名前付きグループを使ってフィールド抽出を実行し
ます。これは、raw イベントのセグメントを正規表現と照合し、これらの値をフィールドに保存します。
この例では、文字列「From:」および「To:」の後に存在する用語を照合し、それらの値をそれぞれ「from」および
「to」フィールドに保存します。
... | rex field=_raw "From: (?<from>.*) To: (?<to>.*)"
raw イベントに文字列「From: Susan To: Bob」がある場合、Splunk は「from=Susan」および「to=Bob」のよう
に、フィールドの名前/値のペアを抽出します。
正規表現の構文と使用法については、「Regular-Expressions.info」を参照してください。Splunk には、正規表現
の作成とテストに役立つサードパーティ製ツールの一覧も用意されています。
サ ー チ結果のフィ ー ルド値抽出の 強 制
設定ファイルに定義されているフィールド抽出の強制
extract (「キー/値」の場合は kv) サーチコマンドは、結果セットのフィールド/値の抽出を強制します。extract に
引数を指定しないで使用すると、props.conf に追加されている field extraction スタンザを使ってフィールド抽出が
行われます。この設定ファイルにフィールドを追加して、extract で任意のフィールドの抽出をテストすることが
できます。
表形式のイベントからのフィールド抽出
複数行、表形式イベントのフィールド/値の抽出を強制するには、multikv を使用します。この場合、各テーブル行
に して新しいイベントが作成され、テーブルのタイトルからフィールド名が取得されます。
XML 形 式 の イ ベ ン ト か ら の フ ィ ー ル ド 抽 出
xmlkv コマンドを使って、Web ページからのトランザクションなどの、イベントデータ内の XML 形式タグの
フィールド/値の抽出を強制できます。
XML お よ び JSON ド キ ュ メ ン ト か ら の フ ィ ー ル ド の 抽 出
spath コマンドは、構造化データフォーマットの XML および JSON から情報を抽出し、それをフィールドに保存
する手段を提供しています。
フォ ー ムテンプレ ー トに基づいたイベントからのフィ ー ルドの抽出
kvform コマンドは、$SPLUNK_HOME/etc/system/local/ または $SPLUNK_HOME/etc/apps/ 内の独自のカスタムアプリ
ケーションディレクトリに、事前定義、保管されているフォームテンプレートに基づいて、イベントからフィール
ド/値のペアを抽出します。たとえば、form=sales_order の場合、Splunk は sales_order.form を探して、すべて
の処理 みイベントをそのフォームと照合し、値の抽出を試みます。
複 数 値フィ ー ルドの操作と評 価
Splunk はサーチ時に複数値フィールドを解析します。これにより、値をサーチパイプライン内で処理することが
できます。複数値フィールドを利用できるサーチコマンドには、makemv、mvcombine、mvexpand、および
nomv があります。eval および where コマンドは、複数値フィールドを利用できる mvcount(), mvfilter(),
mvindex(), and mvjoin() などの関数をサポートしています。これらの関数の詳細は、『Search Reference
Manual』の「Functions for eval」およびこのページの例を参照してください。
46
fields.conf に複数値フィールドを設定し、単一の抽出されたフィールド値内にある複数のフィールド値の認識方
法を Splunk に指示できます。fields.conf は $SPLUNK_HOME/etc/system/local/、または $SPLUNK_HOME/etc/apps/
内の独自のカスタムアプリケーションディレクトリ内で編集します。詳細は、『Knowledge Manager Manual』の
「Configure multivalue fields」を参照してください。
複 数 値フィ ー ルドの操作
nomv を 使 っ た 複 数 値 フ ィ ー ル ド の 単 一 値 へ の 換
nomv コマンドを使って、指定した複数値フィールドの値を単一の値に 換することができます。nomv コマンド
は、fields.conf にある複数値フィールドの設定に優先します。
この sendmail イベントの例では、senders フィールドの値を単一値にまとめます。
eventtype="sendmail" | nomv senders
makemv を 使 っ た 複 数 値 フ ィ ー ル ド の 分 割
makemv コマンドを使って、複数値フィールドを複数の単一値フィールドに分割することができます。この
sendmail サーチ結果の例では、senders フィールドの値を複数のフィールド値に分割します。
eventtype="sendmail" | makemv delim="," senders
フィールド値を分割したら、パイプ文字を使ってそれを他のコマンドの入力にすることができます。たとえば、上
位何人かの送信者を表示することができます。
eventtype="sendmail" | makemv delim="," senders | top senders
mvexpand を 使 っ た 、 複 数 値 フ ィ ー ル ド に 基 づ く 複 数 イ ベ ン ト の 作 成
mvexpand コマンドを使って、複数値フィールド内の各値を個別のイベントに展開することができます。この例で
は、複数値フィールド「foo」の各値に して新しいイベントが作成されます。
... | mvexpand foo
mvcombine を 使 っ た 類 似 イ ベ ン ト か ら の 複 数 値 フ ィ ー ル ド の 作 成
「foo」の値を、区切り文字「:」で結合します。
... | mvcombine delim=":" foo
複 数 値フィ ー ルドの評 価
複数値フィールドの一般的な例として、メールアドレスフィールドが げられます。一般的にこのフィールドは単
一の sendmail イベント内に 2 3 回登場します (送信者用、一連の受信者用、そして CC アドレスが指定されている
場合はそのリスト用)。
フィールド内の値数の算出
単一値または複数値フィールド内の値数を算出するには、mvcount() 関数を使用します。
この例で mvcount() は、To、From、および Cc フィールド内のメールアドレス数を返し、それを指定した _count
フィールドに保存します。
eventtype="sendmail" | eval To_count=mvcount(to) | eval From_count=mvcount(from) | eval
Cc_count=mvcount(cc)
注意：sender フィールドに 1 つのメールアドレスのみが存在している場合、mvcount(from) は 1 を返します。ま
た、CC アドレスが指定されていない場合、イベントの CC フィールドは存在せず、mvcount(cc) はヌルを返しま
す。
複数値フィールドからの値のフィルタリング
任意の論理演算式を指定して複数値フィールドをフィルタリングするには、mvfilter() 関数を使用します。
この例で、mvfilter() は最後が .net または .org で終了する、すべての email フィールドの値を保持します。
eventtype="sendmail" | eval email=mvfilter(match(email, "\.net$") OR match(email, "\.org$"))
47
重要：この関数は、1 回に 1 つのフィールドに してのみ利用できます。
注意：この例は、match() 関数も使用して、引用符内に定義されているパターンを email の値と比較しています。
詳細は、『Search Reference Manual』の eval と where の関数の 明を参照してください。
複数値フィールドから値のサブセットを返す
複数値フィールド内の特定の値または値のサブセットを参照するには、mvindex() 関数を使用します。インデック
ス番号は 0 から始まるため、フィールド内の 3 番目の値を参照する場合は、関数に 2 を指定します。
この例で、mvindex() は Sender が送信した各メールに して、To フィールド内の最初のメールアドレスを返しま
す。
eventtype="sendmail" from=Sender@* | eval to_first=mvindex(to,0)
送信者 (Sender) のメールの送信先上位 3 件のメールアドレスを取得するには、以下のように指定します。
eventtype="sendmail" from=Sender@* | eval top_three=mvindex(to,0,2)
注意：この場合、top_three はそれ自身が複数値フィールドになります。
イベントの相 関
イベントの相 関 について
イベントの相関は、データ内の一見無関係に見えるイベント間の関係を探すことです。この章では、イベントの相
関に利用できる 3 種類の方法について 明していきます。
時間を使ったイベント間の関係の識別
サブサーチを使ったイベントの相関
トランザクションを使った関連イベントの識別とグループ化
その他の相関手法としては、フィールドルックアップとサーチ言語および associate、contigency、または join コ
マンドの使用などが げられます。
時間を使ったイベント間の 関 係の識別
時間は、問題を判断するために必要不可欠な情報で、この情報は既知であることもしばしばです。Splunk では、
イベント内のベースラインパターンまたは傾向を判別して、それを現在のアクティビティと比較することができま
す。
一連の時間ベースのサーチを実行し、異常なアクティビティを調査、特定し、その後タイムラインを使ってその特
定の期間にドリルインすることができます。同時刻に発生したイベントを調査することで、結果間の相互関係を見
つけ出し、主原因を特定する手がかりにできるかもしれません。
詳細は、このマニュアルの「タイムラインを使ったイベントパターンの調査」を参照してください。
この例は、Splunk チュートリアルの「タイムラインの使用」で取り上げられています。
サブサ ー チについて
サブサーチは、サーチパイプラインを引数に持つサーチです。サブサーチは角括弧で まれ、最初に評価されま
す。サブサーチの結果をプライマリ、または外部サーチの引数として使用できます。サブサーチは主に 2 種類の目
的で使用されます。
他のサーチの出力を使って、あるサーチをパラメータ化する (たとえば、特定の URL を訪問した IP アドレ
スから各レコードを 索する)。
別個のサーチを実行するけれども、append コマンドを使って出力を最初のサーチにつなげる。
サブサーチは、サーチで行うアクションや目的が明確で、データの 換を伴わない場合にのみ使用できます。たと
えば、「sourcetype=top | multikv」でサブサーチを使用することはできません。multikv コマンドは、引数にサ
ブサーチを予期していません。append や join などの、一部のコマンドはサブサーチを引数として使用することが
できます。
サブサ ー チの例
48
以下の例では、サブサーチを使ってあるサーチをパラメータ化します。過去の時間にもっともアクティブなホス
トからのすべてのイベントを 索したいと考えていますが、 時間同じホストである訳ではないため、特定のホスト
に してサーチを実行することはできません。まず、もっともアクティブなホストを識別する必要があります。
sourcetype=syslog earliest=-1h | top limit=1 host | fields + host
このサーチは 1 つのホスト値のみを返します。この例で、結果となるホスト名は「crashy」でした。次に、
「crashy」からのすべてのイベントをサーチすることができます。
sourcetype=syslog host=crashy
この情報が必要な時に 回 2 つのサーチを実行する代わりに、サブサーチを使ってホスト名を取得し、それを外部
サーチに渡すことができます。
sourcetype=syslog [search sourcetype=syslog earliest=-1h | top limit=1 host | fields + host]
サブサ ー チのパフォ ー マンス
サブサーチが巨大な結果テーブルを返すと、それはサーチのパフォーマンスに影響を与えます。サーチと連携動作
する format コマンドを利用して、サーチに渡す結果数を 更することができます。サブサーチの最後に、| format
maxresults = <integer> コマンドを追加してください。詳細は、『Search Command Reference』の format コマ
ンドの 明を参照してください。
また、limits.conf 内の設定でも、サブサーチの実行時間や返す最大結果数などを制御することができます。
[subsearch]
maxout = <整数>
サブサーチから返される最大結果数。
この値は 10500 未 でなければなりません。
デフォルトは 100 です。
maxtime = <整数>
サブサーチの最大実行時間 (秒)。この時間を過ぎるとサブサーチは完了させられます。
デフォルトは 60 です。
ttl = <整数>
サブサーチの結果をキャッシュに保持する時間。
デフォルトは 300 です。
サーチの実行後、[アクション] メニューの [サーチジョブの 査] を選 することができます。remoteSearch コンポー
ネントまでスクロールすると、サブサーチの結果となる実際のクエリーを確認することができます。詳細は、
『サーチマニュアル』の「サーチジョブ調査」を参照してください。
サブサ ー チコマンドの結果出力設定
Limits.conf.spec は、サブサーチがデフォルトで最大 100 件の結果を返すことを指定しています。ただし、各コマ
ンドではそのコマンド内のサブサーチのデフォルト最大結果数を 更できるため、実際の出力結果数は場合によっ
て異なります。また、デフォルトの最大出力数は、サーチ式内に展開される目的のサブサーチにのみ適用されま
す。しかし、join や append などのコマンドはこれに該当しません。たとえば append コマンドは、ユーザーがコ
マンドの引数として maxout を指定しない限り、このデフォルト値に優先して、maxresultrows の値を使用しま
す。
回答
何か質問がありますか？「Splunk Answers」から、Splunk コミュニティに寄せられた、サブサーチの使用方法に
関する質問と回答をご覧ください。
サブサ ー チを使ったイベントの相 関
サブサーチはあるサーチの結果を取得し、それを別のサーチに使用することで、順次処理のデータ分析を実現して
います。サブサーチを使って、異なるインデックスからのデータや分散環境の Splunk サーバーからのデータも含
めて、イベントセット全体からデータの相関を探したり、イベントを評価することができます。
たとえば、異なるアプリケーションログに由来する、複数のインデックスがある場合を考えてみましょう。これら
のログからのイベントデータは、最低 1 つの共通フィールドを共有している場合もあります。このフィールドの値
49
を使って、他のインデックス内に存在しない値に基づいて、あるインデックス内のイベントをサーチすることがで
きます。
sourcetype=some_sourcetype NOT [search sourcetype=another_sourcetype | fields field_val]
注意：これは、SQL の「NOT IN」機能と同等です。
SELECT * from some_table
WHERE field_value
NOT IN (SELECT field_value FROM another_table)
サブサ ー チ結果のフォ ー マットの 更
サブサーチを使用する場合、サブサーチ結果には 示的に format コマンドが適用されます。format コマンドは、サ
ブサーチ結果を単一の線形サーチ文字列に 更します。これは、返されたフィールド内の返された値を、プライマ
リサーチに渡す場合に使用されます。
サブサーチが以下のようなテーブルを返した場合：
| field1 | field2 |
------------------event/row1 | val1_1 | val1_2 |
event/row2 | val2_1 | val2_2 |
format コマンドは以下の文字列を返します。
(field1=val1_1 AND field2=val1_2) OR (field1=val2_1 AND field2=val2_2)
詳細は、『Search Command Reference』の format コマンドの 明を参照してください。
サ ー チおよびクエリ ー フィ ー ルド
これにはいくつかの例外があります。まず、すべての内部フィールド (先頭がアンダースコア「_*」で始まる
フィールド) は無視され、このように再フォーマットされることはありません。また、「search」および「query」
フィールドは、再フォーマットされたサーチ文字列内にその値が直接表示されます。
「search」の使用
一般的に「search」は、静的なデータを追加する必要がある場合、またはサブサーチ内のデータに eval を実行
し、それをプライマリサーチに渡すような場合に役立ちます。「search」を使用する場合、フィールドの最初の値
が実際のサーチ単語として使用されます。たとえば、上記のテーブルで field2 が「search」の場合、format コマン
ドは以下の文字列を返します。
(field1=val1_1 AND val1_2) OR (field1=val2_1 AND val2_2)
また、「search」を使って、プライマリサーチに渡される実際のサーチ文字列を 更することもできます。
「query」の使用
「query」は、これらの実際のフィールドではなく、サブサーチから返されたフィールドの値を 索する場合に役立
ちます。query フィールドは、format と類似の動作を行います。format のようにフィールド/値のペアを渡す代わ
りに、これは値を渡します。
(val1_1 AND val1_2) OR (val2_1 AND val2_2)
例
特定の Name と関連する clID を探す、以下のサーチを考えてみましょう。次にこの値が、複数のソースのサーチに
用いられます。
index="myindex" [ index="myindex" host="myhost" <Name> | top limit=1 clID | fields + clID ]
このサブサーチは、次のような文字列を返します： ( (clID="0050834ja") )
値 0050834ja のみを返したい場合は、以下のサーチを実行します。
index=myindex [ index=myindex host=myhost MyName | top limit=1 clID | fields + clID | rename clID as
search ]
50
フィールドが名前付きサーチ (またはクエリー) の場合、フィールド名は破棄されて、サブサーチ (技術的には、サ
ブサーチの最後にある 示の | format コマンド) はフィールド名を破棄して ( ( 0050834ja ) ) を返します。たとえ
ば、( ( value1 ) OR ( value2 ) OR ( value3 ) ) のように複数の結果が返されます。
これは、フィールド名が「search」または「query」の場合のみの特殊な事例です。フィールドを別の名前に 更す
ると、サブサーチは新しいフィールド名を使用します。
トランザクションについて
トランザクションは、一定期間にまたがる任意の関連イベントのグループです。トランザクションタイプは、設定
されたトランザクションで、Splunk にフィールドとして保存されています。任意の数のデータソースが、複数の
ログエントリにまたがってトランザクションを生成できます。
トランザクションサ ー チ
トランザクションサーチは、ログに記 された複数のイベントにまたがる任意の物理イベントに注目する場合に役
立ちます。transaction コマンドを使って、トランザクションを定義したり、transactiontypes.conf に設定されて
いるトランザクションオプションに優先する設定を使用したりすることができます。
一般的にトランザクションサーチは、複数のイベントを単一の物理イベントを表す、単一のメタイベントにグルー
プ化する場合に用いられます。たとえば、メモリー不足の問題により、複数のデータベースイベントがログに記
された場合に、それらをまとめてトランザクションにグループ化することができます。
詳細は、このマニュアルの「イベントの識別とトランザクションへのグループ化」を参照してください。
トランザクションの代わりに stats を使用する場合
トランザクションは、トランザクションデータの総統計を算出するためのもっとも効率的な手段と言う訳ではあり
ません。単一フィールド内のデータにより定義されているトランザクションの総統計を算出する場合は、stats コ
マンドを使用します。
たとえば、session_id フィールドが定義する、トランザクションの期間の統計を算出する場合は、以下のコマン
ドを使用します。
* | stats min(_time) AS earliest max(_time) AS latest by session_id | eval duration=latest-earliest |
stats min(duration) max(duration) avg(duration) median(duration) perc95(duration)
同 に、アクセスログ内の clientip 当たりのヒット数を算出する場合は、以下のコマンドを使用します。
sourcetype=access_combined | stats count by clientip | sort -count
また、アクセスログ内の clientip 当たりの一意のセッション (cookie でパラメータ化) 数を算出する場合は、以下
のコマンドを使用します。
sourcetype=access_combined | stats dc(cookie) as sessions by clientip | sort -sessions
stats コマンドの使用方法の詳細は、リファレンスマニュアルの stats コマンドに関する 明を参照してください。
トランザクションおよびマクロサ ー チ
トランザクションおよびマクロサーチは強力な組み合わせで、トランザクションサーチ内で代替を行うことができ
ます。代替を行うには、トランザクションサーチを実行して、それを $field$ で保存します。
マクロサーチとトランザクションサーチの使用例については、このマニュアルの「サーチマクロの作成と使用」を
参照してください。マクロサーチの詳細は、『Knowledge Manager Manual』の「Design macro searches」を参
照してください。
イベントの識別とトランザクションへのグル ー プ
化
Splunk では、関連するイベントをサーチ、識別して、それを「トランザクション (またはセッション)」と呼ばれ
る単一のイベントにグループ化することができます。トランザクションの例を以下に示します。
同じソース、同じホストからの異なるイベント。
51
同じホストの異なるソースからの異なるイベント。
異なるホスト、異なるソースからの類似イベント。
トランザクションのサーチは、Splunk Web または CLI で transaction サーチコマンドを使って行いま
す。transaction コマンドは、グループ化されたイベントを生成します。これをレポートに使用することができま
す。transaction を使用するには、トランザクションタイプ (transactiontypes.conf で設定) を呼び出すか、または
transaction にサーチオプションを設定して、サーチ内にトランザクション制約を定義します。
transaction のサ ー チオプション
サーチ時に返されるトランザクションは、各イベントの raw テキスト、共有イベントタイプ、およびフィールド
値から成り立っています。トランザクションには、duration および transactiontype フィールドに保存される追
加データも存在しています。
には、トランザクションの期間が含まれています (トランザクション内の最初と最後のイベントの
タイムスタンプの差)。
transactiontype はトランザクション名です (transactiontypes.conf にトランザクションのスタンザ名で定
義)。
duration
は任意のサーチに追加できます。最良のサーチパフォーマンスを確保するために、適切なサーチを作
成して、それをパイプ文字で transaction コマンドに渡してください。詳細は、『Search Reference Manual』の
「transaction」を参照してください。
transaction
コマンドに続けて、以下のオプションを指定できます。注意：一部の transaction オプションは、他
のオプションと一緒に指定することはできません。
transaction
[field-list]
のように、フィールドのカンマ区切りリストです。
設定した場合、同じトランザクション内にあるイベントと判断するには、各イベントに同じフィールドがな
ければなりません。
共通のフィールド名で異なる値を持つフィールドはグループ化されません。
たとえば、...|transaction host を追加した場合、host=mylaptop を持つサーチ結果が host=myserver
を持つサーチ結果と同じトランザクションになることはありません。
host の値を持たないサーチ結果は、host=mylaptop を持つ結果と同じトランザクションになる可能性
があります。
...|transaction host,cookie
match=closest
トランザクション定義で使用するマッチタイプを指定します。
現在のところ、値は closest のみをサポートしています。
maxspan=[<integer> s|m|h|d]
トランザクション内のイベント間の最大一時停止期間を設定します。
秒、分、時間、または日単位で指定できます。
例：5s、6m、12h、または 30d。
デフォルトは、maxspan=-1 で、時間範 は「全時間」となっています。
maxpause=[<integer> s|m|h|d]
トランザクション間の最大一時停止期間を指定します。
トランザクション内のイベント間の一時停止期間は maxpause 未 でなければなりません。
負の値を指定した場合、maxspause 制約は無効になります。
デフォルトは maxpause=-1 です。
startswith=<string>
サーチまたは eval フィルタリング式。あるイベントがこの条件を たすと、新しいトランザクションの開始
としてマークされます。
例：
startswith="login"
startswith=(username=foobar)
startswith=eval(speed_field < max_speed_field)
startswith=eval(speed_field < max_speed_field/12)
デフォルトは "" です。
endswith=<transam-filter-string>
サーチまたは eval フィルタリング式。あるイベントがこの条件を たすと、新しいトランザクションの終了
としてマークされます。
52
例：
endswith="logout"
endswith=(username=foobar)
endswith=eval(speed_field < max_speed_field)
endswith=eval(speed_field < max_speed_field/12)
デフォルトは "" です。
startswith
および endswith の場合、<transam-filter-string> は次の構文で定義されます： "<search-
expression>" | (<quoted-search-expression>) | eval(<eval-expression>
は、引用符を含まない有効なサーチ式です。
は、引用符を含まない有効なサーチ式です。
<eval-expression> は、論理演算式を評価する有効な eval 式です。
<search-expression>
<quoted-search-expression>
例：
サーチ式： (name="foo bar")
サーチ式： "user=mildred"
サーチ式： ("search literal")
eval 論理演算式： eval(distance/time < max_speed)
トランザクションサ ー チの例
単一のユーザー (またはクライアント IP アドレス) が一定期間に参照したすべての Web ページをグループ化する
サーチを実行します。
このサーチはアクセスログからイベントを作成し、同じ clientip 値を共有し、相互の発生間隔が 5 分以内のイベ
ントからトランザクションを作成します (3 時間の期間内で)。
sourcetype=access_combined | transaction clientip maxpause=5m maxspan=3h
将来 のイベントの予測
Splunk による予測分析について
このページは現在作業中で、まもなく更新される予定です。
予測分析はさまざまな方法で利用できます。例：
仮想環境のハードウェア要件を判断し、エネルギー消費を予測することで、キャパシティプランニングに役
立ちます。
主原因分析を 張して、イベント内の異常なパターンを 出し、セキュリティ攻 を防止します。
主要コンポーネントのモニタリングを強化して、システム障害の 出や機能停止の防止を行います。
Splunk では、レポートやダッシュボードを使って発生するアクティビティをモニターし、そのイベントにドリル
ダウンして、何が起きているのかを調査する主原因分析を行えます。モニターしているイベントに何かパターンや
相関が存在している場合、それを使って将来のアクティビティを予測することができます。このような知識を活用
して、閾値に基づいて積極的にアラートを送信したり、「what-if」分析を行って各種シナリオを比較したりするこ
とができます。
予測コマンド
Splunk のサーチ言語には、predict と x11 の 2 種類の予測コマンドが用意されています。
predict コマンドでは、異なる予測アルゴリズムを利用して、単一値または複数値フィールドの将来の値を予
想します。
x11 アルゴリズムに由来して名付けられた x11 コマンドでは、時間ベースのデータ内の季節的なパターンを
判別し、それをデータから取り除くことで実際の傾向を確認できます。
付加的および 加的シ ー ズナリティ
その他のサ ー チ方法
53
サ ー チマクロの作成と編集
サーチマクロは、保存 みサーチやアドホックサーチを含め、複数の場所で再利用できるひとかたまりのサーチで
す。サーチマクロは、eval ステートメントやサーチ単語など、サーチの任意の部分に利用でき、また完全なコマ
ンドである必要はありません。マクロフィールドが任意の引数を取るかどうかを指定することも可能です。
ここでは、Splunk Web でのサーチマクロの作成、使用方法について 明していきます。サーチマクロの使用方法と
使用理由にについては、『Knowledge Manager manual』の「Design macro searches」を参照してください。
Splunk Web でのサ ー チマクロの作成
[管理] > [詳細サーチ] > [サーチマクロ] で、[新規] をクリックして新しいサーチマクロを作成します。
サーチマクロとその引数の定義
後ほど他のサーチの一部として再利用する、サーチ文字列またはサーチパイプライン内の任意の部分をサーチマク
ロにすることができます。
[宛先 App] は、サーチマクロを制限する App の名前です。デフォルトでは、サーチマクロはサーチ App に
限定されています。
[名前] は、mymacro のようなサーチマクロ名です。サーチマクロが引数を取る場合、名前に引数の数を追加
してその旨を知らせる必要があります。たとえば、mymacro に 2 つの引数が必要な場合は、mymacro(2) のよ
うに指定する必要があります。同じ名前を持つ複数のサーチマクロを作成できますが、引数の数は異なって
いなければなりません。 foo, foo(1), foo(2), etc.
[定義] は、サーチマクロが他のサーチ内で参照されている場合に、マクロを展開する文字列です。サーチマ
クロに引数が含まれている場合、それが記入され、$arg1$ のようにドル記号でラップされます。
[Eval Generated Definition?] (eval 生成定義？) が選 されている場合、定義 (Definition) はこのマクロの展開
を表す文字列を返す eval 式が予期されます。
[引数] は、引数名のカンマ区切り文字列です。引数名には英数字 a z、A Z、0 9、アンダースコア「_」、お
よびダッシュ「-」しか使用できません。このリストには、要素を繰り返し指定することはできません。
マクロ定義の先頭にパイプ文字 (|) がある場合、それを UI からのサーチの最初の単語として使用することはできま
せん。例："| metadata type=sources"。UI はマクロ展開を行わず、通常の 索単語と初期パイプを正しく識別できま
せん。UI は、マクロ名がサーチ単語であるかのようにサーチを作成します。この場合、展開後に誤ったメタデー
タコマンドが形成され、無効になってしまいます。
マクロ引数に引用符が含まれる場合、サーチ内でマクロを呼ぶ際には引用符をエスケープ処理する必要がありま
す。たとえば、マクロ引数として引用符付きの文字列を渡す場合、`my-macro("He said \"hello!\"")` のように
指定する必要があります。.
引数値の 証：
サーチマクロを起動するために使用する引数値が妥当かどうかを 証することができます。サーチマクロの起動方
法については、次のセクション「保存 みサーチおよびアドホックサーチへのマクロの適用」で 明しています。
[ 証式] は、論理演算または文字列を評価する「eval」式の文字列です。
証式が論理演算式の場合、真 (True) が返された場合に 証が成功になります。偽 (False) またはヌルを返した
場合、 証は失敗し 証エラーメッセージが返されます。
証式が論理演算式でない場合は、文字列またはヌルを返すことが前提になっています。ヌルが返された場合、 証
は成功したとみなされます。そうでない場合、返された文字列はエラー文字列として表示されます。
保存 みサ ー チおよびアドホックサ ー チへのマクロの適用
保存 みサーチまたはアドホックサーチにサーチマクロを入れる場合、左引用符 (アクサングラーブ) 文字を使用し
ます。たいていの英語版キーボードの場合、この文字はチルダ (~) 文字と同じキーにあります。また、同じ構文を
使って、他のサーチマクロ内のサーチマクロを参照することも可能です。
注意：ダブルクォート (") と同じキーにある垂直引用符文字は使用しないでください。
例 - サ ー チマクロとトランザクションの組み合わせ
トランザクションおよびマクロサーチを組み合わせれば、トランザクションサーチ/レポートを手 に作成すること
ができます。この例は、サーチマクロを使った、定義されたトランザクションに基づくレポートの作成方法を表し
ています。
54
ここで、「makesessions」と言う名前のサーチマクロが、それぞれが相互に 30 分以内に発生した同じ clientip 値
を共有するイベントからのトランザクションセッションを定義しています。
transaction clientip maxpause=30m
このサーチはページビューイベントを取り、サーチマクロ「makesessions」を使ってそれをセッションに分類し
ます。
eventtype=pageview | `makesessions`
このサーチは、各日のセッション当たりのページビュー数のレポートを返します。
eventtype=pageview | `makesessions` | timechart span=1d sum(eventcount) as pageviews count as sessions
同じレポートを作成したいけれどもしばしば異なる期間を使用する場合は、それを期間を引数に持つサーチマクロ
として保存します。このサーチマクロを「pageviews_per_second(1)」と呼ぶことにします。
eventtype=pageview | `makesessions` | timechart $spanarg$ sum(eventcount) as pageviews count as sessions
これで、サーチ App からこのサーチを実行する際に、または保存 みサーチに追加する際に、期間を指定できるよ
うになります。
`pageviews_per_second(span=1h)`
カスタムサ ー チコマンドの作成
この章について
Splunk のサーチ言語には、さまざまコマンドが用意されています。それらのコマンドを使って、多彩なデータを
引き出して、それらを異なる手段で表示することができます。イベントの相関の 索、結果の統計の算出、フィー
ルドの評価と結果の並べ替え、データの再フォーマットおよびデータの強化、グラフの作成など、さまざまな作業
を行うためのコマンドが用意されています。さらに、サーチ言語を強化するために、各自のニーズに合わせてこれ
らのコマンドをカスタマイズしたり、独自の処理や計算を実行するための独自のサーチコマンドを開発したりする
ことができます。
この章は、以下の事項を 明しています。
サーチコマンドとその引数の命名方法のガイドライン。
サーチコマンド作成およびそれの Splunk サーチコマンドへの統合方法の概要。
サーチコマンドの 限とアクセス制御の設定方法。
カスタムサーチコマンドの例。
サ ー チコマンドスタイルガイド
ここでは、カスタムサーチコマンドおよびその引数の命名のガイドライン、そして引数の処理方法について 明し
ていきます。このスタイルガイドは searchproc_style.txt にも記載されています。
カスタムサ ー チコマンドの命名規則
サーチプロセッサのコマンド名：
英数字を使用し、最初は文字でなければなりません。
ダッシュやアンダースコアなどの、英数字以外の文字を使用することはできません。
引数オプション名：
英数字を使用し、最初は文字でなければなりません (アンダースコアは可)。
論理演算式は肯定的に指定する必要があります。たとえば、hidefield=<bool ではなく showfield=<bool> を
使用します。
大文字小文字区別：
コマンド名は大文字と小文字が区別されます。
フィールド名は、大文字と小文字を区別する必要があります。
キーワードでは、大文字と小文字は区別されません (例：「by」のようなストップワード)。
55
引 数 の 処 理およびチェック方法
一連の引数とそのオプションを取るサーチコマンド (またはプロセッサ) を作成できます。
一連のオプション引数セット (空のセットも可能) を取る単純プロセッサ：
processArguments() では、getOption() 呼び出しで各オプションの値を取得します
例：outputraw (オプションなし)、analyzefields (1 つのオプション引数を取る)
オプションとフィールドのリストまたは他の引数を取るプロセッサ (大部分のコマンドはこのカテゴリに分類)：
フィールドのリストはオプションとして指定するのではなく、引数リストの一部として直接指定する必要が
あります。複数のリストが必要な場合は、キーワードを使ってリストを区切ります。
processArguments() で、まず getOption() を使ってオプションパラメータを取り込みます。次に
getNextArgs() を使って名前 更引数のリストを取得します。getNextArgs() では、必要に じてストップワード
を使用することができます。この場合、特定の単語が見つかると、引数の取得を停止します。
例："mycommand myopt=optval field1 field2 field3 by otherval1 overval2" (「by」がストップワード)。
完全に引用符で まれた引数は、キーワードまたはオプションとはみなされません。
外部引数をすべてチェック：
すぺてのプロセッサは、引数処理の最後に「ERRORIFUNUSEDARG」マクロを呼び出して、使用されな
かった外部引数にエラーのフラグが設定されていないことを確認する必要があります。
オプション名のスペル誤りも多いため、意図しない結果を招かないようするためにも、このことが重要にな
ります。
エラ ー の 処 理
エラーをパーシングするすべての引数は、解析時に SearchProcessorException() をスローする必要があります。
一般的に、実行時のエラー (例：指定フィールドがイベント内に存在していない) は、実行時に SearchResultsInfo
に INFO/WARN/ERROR メッセージを追加する必要があります。また、実行を停止しないようにする必要があり
ます。
カスタムの Python サーチコマンドスクリプトの場合、commands.conf から以下のように stderr 出力を設定する
ことができます。
stderr_dest = log|message|none
デフォルトの stderr_dest = log は、エラー出力が search.log に転送される古い動作です。stderr_dest =
message を使用する場合、stderr 出力の各行がサーチバナーのメッセージとして処理されます。メッセージレベル
は、メッセージの開始がどうなっているかによって決まります。
情報メッセージは「INFO 」から始まる必要があります。
警告メッセージは「WARN 」から始まります。
デバッグメッセージは「DEBUG 」から始まります。
エラーメッセージは「ERROR 」から始まります。
これらのパターンで始まらないメッセージは、エラーメッセージとして処理されます。
サブパイプラインを取るコマンド
これらのコマンドは、サブパイプラインが自動実行されないように evalArgs() に優先させる設定を行うか、または
handleSearchResultsArgs() に優先させる設定を行って真 (True) を返すようにする必要があります。
複数のパイプラインを処理するコマンドは、コマンドへの入力をイベントのパイプラインとして、指定されている
サブパイプラインをその他の入力として使用する必要があります。例："join [search A] [search B]" ではなく
"search A | join [search B]" とします。
このようなコマンドの例として、join、append、set (set は前のガイドラインに違反していますが) などが げられ
ます。
サ ー チコマンドの作成
カスタムサーチコマンドは、データを読み取り、それを処理して出力する Python スクリプトです。ここでは、
Python スクリプトによる入力と引数の処理規則について 明していきます。
サーチコマンドは以下の条件を たしていなければなりません。
56
サーチコマンドは以下の条件を たしていなければなりません。
$SPLUNK_HOME/etc/apps/<app_name>/bin/
に保管する
名前付き <command>.py
サーチコマンド名には、英数字 (a z、A Z、および 0 9) のみを使用できます。新しいコマンドに既存のコマンドと
同じ名前を使用することはできません。
サ ー チコマンドの種類
カスタムサーチコマンドには、生成およびストリーミングの 2 種類のサブタイプがあります。
生成コマンドは、サーチパイプラインの先頭に使用できるコマンドです。入力 (イベントやサーチ結果など)
を予期していませんし、必要でもありません。代わりに、インデックスからのイベントの取得または生成を
担当します。
ストリーミングコマンドは、各イベントに 換を適用し、その結果をすべてを一度にではなく、一定単位ごと
に出力します (各イベントへのフィールドの追加など)。非ストリーミングコマンドは、それがデータを操作/
減少して出力する前に、すべてのデータが入力として利用できることを前提にしています。
順次出力形式でイベントを生成したり、データを返すコマンドを作成することもできます。
これらは、commands.conf 内の 更可能な設定です。詳細は、「Splunk へのカスタムコマンドの追加」を参照して
ください。
入力の 処 理
スクリプトへの入力は、純粋な CSV または Intersplunk でなければなりません。Intersplunk では、ヘッダーセク
ションの次に空行があり、それに続けて純粋な CSV 本体が記載されています。
スクリプト入力を解釈するもっとも簡単な方法は、splunk.Intersplunk.readResults を使用することです。これ
は、3 つのオプションパラメータを取り、dict のリストを返します (入力イベントのリストを表す)。オプションパ
ラメータは、「input_buf」、「settings」、および「has_header」です。
「inputbuf」は入力の読み取り場所で、これが None (デフォルト) の場合、sys.stdin が仮定されます。
「settings」は dict で、ここに入力ヘッダー内に見つかった任意の情報を保管します (デフォルトは None
で、この場合設定は記 されません)。
「has_header」は、入力ヘッダーを予期するかどうかを表しており、デフォルトは 真 (True) です。
スクリプトがヘッダーを予期するかどうかを指定するには、enableheader キーを使用します。enableheader キー
のデフォルトは真 (True) です。これは、入力にヘッダーセクションが含まれており、Intersplunk フォーマットを
使用していることを表しています。
スクリプトが入力のヘッダーセクションを予期しない場合 (enableheader が偽 (False)) は、直接 Python csv モ
ジュールを使って入力を読み取ります。例：
import csv
r = csv.reader(sys.stdin)
for l in r:
...
この方法の利点は、任意の時点で for ループを中止でき、反復によりその時点までに入力された行のみがメモリー
に読み込まれることです。場合によっては、これがパフォーマンスの向上にもつながります。
出力の送信
Intersplunk を使ってスクリプトの出力を作成することもできます。splunk.Intersplunk.generateErrorResults は
文字列を取り、sys.stdout に正しいエラー出力を書き込みます。splunk.Intersplunk.outputResults は dict オブ
ジェクトのリストを取り、sys.stdout に適切な CSV 出力を書き込みます。
データを出力するには、以下の文字列を追加します。
splunk.Intersplunk.outputResults(results)
スクリプトの出力は、純粋な CSV であるとみなされます。エラーが発生した場合は、1 つの「ERROR」列と 1
つの行 (見出し行の他に)、およびメッセージのコンテンツを含む CSV が返されます。
エラ ー処 理
スクリプトに supports_getinfo = true が存在している場合を除き、スクリプトに渡される引数 (sys.argv 内) は、
57
サーチ言語内でコマンドの起動に使用された引数と同じになります。supports_getinfo キーは、スクリプトへの
最初の引数が __GETINFO__ or __EXECUTE__ であることを示しています。これにより、解析時にコマンド引数でス
クリプトを呼び出して、サーチ実行前に構文エラーを確認することができます。この時点でのエラーは、サーチの
実際の実行を回避します。__GETINFO__ で呼び出した場合は、引数に じて動的にスクリプトのプロパティ (スト
リーミングかどうかなど) を指定することができます。
スクリプトで supports_getinfo に「true」が設定されている場合、最初に以下のような呼び出しを実行する必要
があります。
(isgetinfo, sys.argv) = splunk.Intersplunk.isGetInfo(sys.argv)
このコールにより sys.argv から最初の引数が除去され、GETINFO モードまたは EXECUTE モードかどうかが確
認されます。GETINFO モードの場合、スクリプトは splunk.Intersplunk.outputInfo() を使ってスクリプトのプ
ロパティを返すか、または引数が無効な場合は splunk.Intersplunk.parseError() を使用する必要があります。
outputInfo()
およびその引数の定義は以下のようになります。
def outputInfo(streaming, generating, retevs, reqsop, preop, timeorder=False)
また、commands.conf にこれらの属性を設定することもできます。
Splunk へのカスタムコマンドの追加
サーチコマンドを作成したら、commands.conf を編集してそのコマンドのエントリを作成する必要がありま
す。commands.conf にエントリを追加しない限り、Splunk がカスタムコマンドを認識することはありません。内
の各コマンドの設定オプションについては、『管理マニュアル』の commands.conf.spec を参照してください。こ
こでは、ほんの一部のパラメータのみを取り上げています。
新しいスタンザの作成
内の各スタンザは、サーチコマンドの設定を表しています。カスタムスクリプトを単に有効にする
スタンザの例を以下に示します。
commands.conf
[<STANZA_NAME>]
filename = <文字列>
は、コマンド起動時にサーチ単語として指定するキーワードです。サーチコマンド名には、英数字
(a z、A Z、および 0 9) のみを使用できます。新しいコマンド (ここでは新しいスタンザ) に、既存のコマンドと同
じ名前は使用できません。
STANZA_NAME
属性には、カスタムスクリプト名を指定します。Splunk はこのスクリプトが適切な
ディレクトリにあることを前提にしています。見つからない場合
は、$SPLUNK_HOME/etc/apps/search/bin (Splunk 出荷時に大部分のスクリプトはここに保存される) からスクリプ
トを探します。たいていの場合は、スクリプトを app 名前空間内に配置することをお勧めします。
filename
$SPLUNK_HOME/etc/apps/<app_name>/bin/
コマンドの記述
filename 属性は、単にサーチスクリプトの場所を示します。その他の属性を使って、Splunk に追加するコマンド
のタイプを記述することができます。
streaming = [true|false]
コマンドがストリーミング かどうかを示します。
デフォルトは偽 (false) です。
generating = [true|false|stream]
コマンドが新たなイベントを生成するかどうかを示します。
stream の場合、そのコマンドは新しいイベントを生成し (generating = true)、ストリーム (streaming = true)
となります。
デフォルトは偽 (false) です。
Splunk の再起動
にカスタムコマンドを追加したら、Splunk を再起動する必要があります。カスタムコマンドスク
リプトまたは commands.conf 内の既存のコマンドのパラメータを編集した場合は、再起動の必要はありません。
commands.conf
58
カスタムコマンドへのアクセス制御
スクリプトを作成して、commands.conf に追加したら、それの使用を開始することができます。
デフォルトでは、すべてのロールが commands.conf への読み取りアクセス を持っています。書き込み は管理者の
みが保有しています。つまり、個別のコマンドに するアクセス を明示的に 更しない限り、すべてのロールが
commands.conf に記載されているコマンドを実行できてしまいます。コマンドの使用を特定のロールまたはユー
ザーに制限する場合、[管理] でそのアクセス を 更するか、または default.meta.conf を編集します。
Splunk Web で 編 集 で き る 項 目
Splunk 管理を使って、App 内で実行させたくないサーチコマンドを無効にすることができます。
1. [管理] >> [詳細サーチ] >> [サーチコマンド] に移動します。
サーチコマンドのテーブルが表示されます。これには、次の情報が記載されています：コマンド名、コマンドを定
義しているスクリプトのファイル名、スクリプトの所有者、所属している App、共有制限、有効になっているかど
うか。
注意：このテーブルには、Python で作成されたサーチコマンドのみが記載されています。
2. サーチコマンドの [ステータス] 列から、[無効] をクリックします。
App 内でコマンドが無効になったことを知らせるメッセージが表示されます。
[管理] ページから、コマンドに するロールのアクセス を 更することもできます。
1. サーチコマンドの [共有] 列から、[ 限] をクリックします。
サーチコマンドの [ 限] ビューが表示されます。このページから、以下の事項を指定できます。
コマンドを現在の App に表示するか、またはすべての App に表示するか。
このコマンドに読み取り、書き込みアクセス を持つロール。
2. 更内容は忘れずに保存してください。
設定ファイルで編集できる項目
コマンドに するアクセス は、$SPLUNK_HOME/etc/apps/<app_name>/metadata/default.meta ファイルを使って 更す
ることもできます。詳細は、『管理マニュアル』の default.meta.conf に関する記事を参照してください。
以下の例は、commands.conf および input コマンド (管理者以外は実行不可) に する、デフォルトアクセス を表し
ています。
[commands]
access = read : [ * ], write : [ admin ]
export = system
[commands/input]
access = read : [ admin ], write : [ admin ]
サーチスクリプトファイル自体へのアクセス制限も存在しています。これらのコントロールは、[searchscripts]
スタンザに定義されています。デフォルトで、すべてのロールと App がファイルを参照できますが、編集できる
のは管理者のみとなっています。
[searchscripts]
access = read : [ * ], write : [ admin ]
export = system
ファイルをシステム内のすべての App で利用できるようにするには、export = system 属性を使用します。上記の
例では、commands.conf および [searchscripts] へのアクセスはグローバル (global) です。[searchscripts] に
global export が指定されていない場合、スクリプト設定 (commands.conf) はすべての App で参照できます。ただ
し、スクリプトファイル自体は参照できません。
注意：UI を持たない App 内のカスタムコマンドも、システムにエクスポートする必要があります。そうしない
と、ローカルコンテキスト内でコマンドを実行する手段がありません。
カスタムサ ー チコマンドの例
59
外部化されたサ ー チエラ ー 文字列
外部化されたサ ー チエラ ー
サーチコマンドのエラー文字列を含め、Splunk で外部化された文字列は、literals.conf 設定ファイルに定義さ
れています。Splunk ユーザーと管理者はこのファイルを編集する必要はありません。ただし、Splunk 開発者が既
存の文字列を 更したり、カスタム設定を定義したりすることは可能です。
この設定ファイルは、$SPLUNK_HOME/etc/system/default/literals.conf に存在しています。このファイルは編集
しないでください。このトピックの残りの部分をお読みください。
サ ー チエラ ー 文字列
ファイル内のサーチエラー文字列用の部分は、以下のテキストで示されています。
# String externalization starts here
この後に、関連するエラー文字列がある、各サーチコマンド用のスタンザが記載されています。たとえば、eval
コマンドのスタンザは以下のようになります。
[EVAL]
MISSING_ARGS
FAILED_PARSE
INVALID_DEST
BOOLEAN_RESULT
BAD_DEST_BRACKETS
INVALID_OP__S
TYPE_FAIL_CONCAT
TYPE_FAIL_DIFF__S
TYPE_FAIL_PLUS
TYPE_FAIL_NUM__S
TYPE_FAIL_BOOL__S
MATCH_FAIL__C
CONSUME_FAIL__S
INVALID_NUMBER__S
INVALID_UNARY_OP
UNEXPECTED_CHAR__C
MISSING_FACTOR
MISSING_TERM
MISSING_COMP_TERM
MISSING_AND
MISSING_OR
INVALID_FUNC_ARGS__S
BAD_FUNC__S
= Missing arguments. usage: eval dest_key = expression
= Failed to parse arguments. eval usage: eval dest_key = expression
= Invalid destination key
= The result of an expression cannot be boolean. Try if([bool expr], [expr], [expr])
= Invalid destination field. {} brackets must be closed
= Invalid operator at '%s'
= Typechecking failed. '.' operator only takes strings and numbers
= Typechecking failed. '%s' operator received different types
= Typechecking failed. '+' only takes two strings or two numbers
= Typechecking failed. '%s' only takes numbers
= Typechecking failed. '%s' only takes boolean arguments
= Malformed expression - %c expected
= Malformed expression - %s expected
= Invalid number: %s
= Malformed expression - Invalid unary op
= Malformed expression - Unexpected character hit in factor: %c
= Malformed expression - Missing factor
= Malformed expression - Missing term
= Malformed expression - Missing comparison term
= Malformed expression - Missing AND term
= Malformed expression - Missing OR term
= Invalid arguments to '%s' function
= Unsupported Function: %s
エラ ー 文字列の上書きまたは定義
literals.conf を編集する前に、設定の仕 とファイルの例を参照してください。
$SPLUNK_HOME/etc/system/README/literals.conf.spec
$SPLUNK_HOME/etc/system/README/literals.conf.example
既存のエラー文字列を上書き、またはカスタムエラー文字列を定義するには、以下のディレクトリに literals.conf
を作成します。
$SPLUNK_HOME/etc/system/local/
既存の文字列を上書きするには、デフォルトの literals.conf からローカルの literals.conf にスタンザ名と属性/値の
ペアをコピーして、ローカル版の literals.conf ファイルで値を編集します。
新しいカスタム設定はすべて、literals.conf のローカルコピーに定義します。
重要：literals.conf を不適切に編集すると、Splunk のパフォーマンスに深刻な影響を与える可能性があります。
literals.conf の設定を 更する際のガイドラインを以下に示します。
外部化文字列は、属性名と値のペアで定義されています。属性値のみを 更する必要があります。属性名は 更
しないでください。
文字列に "%s" が含まれている場合、%s のインスタンス追加/削除したり、順序を 更したりしないでくださ
い。
60
文字列に HTML タグおよびエンティティが含まれている場合は、すべてが適切にエスケープ処理されている
ことを確認してください。
サ ー チの例と手引き
この章の 内 容
このページは現在作業中で、まもなく更新される予定です。
この章では、サーチの例を段階的に 明しています。
複数のデータシリーズのレポート
異なる日の時間別合計の比較
動的フィールドのサイズの算出
Windows ディスク使用量の監視とアラート
複 数 のデ ー タシリ ー ズのレポ ー ト
Splunk のレポートコマンドには、グラフ (または時間グラフ) に複数のデータシリーズを定義する直接的な方法が
ありません。この例では、stats および xyseries コマンドを使って、複数データシリーズのグラフを作成する方法
を 明していきます。
はじめに
コマンドと timechart コマンドは両方とも、グラフ作成用に表形式のデータを返します。X 軸はそれぞれ任
意のフィールドまたは _time になります。これらのコマンドと split-by フィールドを使用すると、各列が split-by
フィールドの一意の値を示す表が出力されます。
chart
一方 stats コマンドは、各行が group-by フィールドの、単一で一意の値の組み合わせを示す表を生成します。次
に xyseries コマンドを使って、グラフ化用のデータシリーズを再定義することができます。
たいていの場合は、「... | chart n by x,y」の結果を「... | stats n by x,y | xyseries x y n」を使ってシミュレーション
できます。(timechart と同等の結果は x = _time.)
シナリオ
この例では、アプリケーションサーバーのクラスタからのデータに注目します。各サーバーから収集されたイベン
トには、アクティブなセッション数や前回の更新後に処理されたリクエスト数などの情報が含まれてお
り、applications_servers インデックスに配置されています。セッションや負荷の分布を確認できるように、各
サーバーインスタンスとインスタンス当たりのセッション数を同じ時間グラフに表示します。
理想的なのは、以下のような時間グラフレポートを実行、生成することです。
index=application_servers | timechart sum(handledRequests) avg(sessions) by source
しかし、時間グラフは複数のデータシリーズをサポートしていないため、代わりに以下のようなサーチを実行する
必要があります。
index=application_servers
| stats sum(handledRequests) as hRs, avg(sessions) as ssns by _time,source
| eval s1="handledReqs sessions"
| makemv s1
| mvexpand s1
| eval yval=case(s1=="handledReqs",hRs,s1=="sessions",ssns)
| eval series=source+":"+s1
| xyseries _time,series,yval
明
... | stats sum(handledRequests) as hRs, avg(sessions) as ssns by _time,source
これは、stats コマンドを使って各ソース値の統計を算出しています。handledRequests 値の合計は hRs と名付
け、sessions の平均は ssns と名付けます。
... | eval s1="handledReqs sessions" | makemv s1 | mvexpand s1
61
また、eval コマンドを使って、stats コマンドからの各結果に単一値フィールド「s1」を追加します。次に、
makemv コマンドで sl を複数値フィールドに 換します。このフィールドで、最初の値は「handleReqs」、2 番目
の値は「sessions」になります。次に mvexpand で、s1 の各値に して個別のシリーズを作成します。
... | eval yval=case(s1=="handledReqs",hRs,s1=="sessions",ssns)
これは、eval コマンドを使って新たなフィールド yval を定義し、マッチしたケースに基づいて値を割り当てま
す。s1 の値が「handledReqs」の場合、yval には「hRs」が割り当てられます。また、s1 の値が「sessions」の
場合、yval には「ssns」が割り当てられます。
... | eval series=source+":"+s1
これは eval コマンドを使って新たな series フィールドを定義します。このフィールドは、host および s1 フィー
ルドの値を連結します。
... | xyseries _time,series,yval
最後に xyseries コマンドを使って、X 軸が _time、Y 軸が yval で、シリーズで定義されたデータを利用したグラフ
を作成します。
異なる日の時間別合計の比較
ここでは、複数の日数に渡って収集された値を比較するための、chart の使用例を取り上げます。
はじめに
コマンドは、時間の推移に伴う傾向を表示するグラフを生成します。ただし、このコマンドでできるこ
とには 密な境界の制限があるため、より柔軟性に優れた chart コマンドを使用する方が良い場合もあります。
timechart
シナリオ
ほぼ同一の 2 つのサーチがあります。どちらも 24 時間の期間における P フィールドの時間ごとの合計値を表示し
ます。ただし、片方のサーチは過去 10 日間の期間をカバーしており、もう一方は 過去 9 日間の期間をカバーして
いると言う違いがあります。
サーチ 1：
earliest=-10d latest=-9d | timechart span="1h" sum(P)
サーチ 2：
earliest=-9d latest=-8d | timechart span="1h" sum(P)
ここでは、これらの 2 つのサーチ結果を組み合わせた棒グラフを作成し、10 日前の午後 3 時の P の合計と 9 日前
の午後 3 時の P の合計を並べて表示します。
解決策
コマンドでは、この目的を実現することはできません。しかし、chart コマンドを使用すれば簡単にこ
の目的を達成できます。両方の日をカバーするサーチを設定し、サーチイベント内で見つかった一意の date_hour
および date_day の各組み合わせに して、［sum of P］ (P の合計) 列を作成します。
timechart
サーチは以下のようになります。
earliest=-10d latest=-8d | chart sum(P) by date_hour date_day
これは、24 スロットを持つ単一のグラフを作成します。各スロットが、その日の各時間を表しています。各ス
ロットにはレポートの時間範 がカバーしている、2 日間の時間後との合計を比較するための 2 つの列が含まれて
います。
その他の情報
レポートサーチの概要については、「レポートコマンドについて」を参照してください。
および timechart 関数の詳細については、『Search Reference Manual』の「Functions for stats, chart, and
timechart」を参照してください。
chart>
62
Windows ディスク使用量の監視とアラ ー ト
このページは現在作業中で、まもなく更新される予定です。
この例では、ディスクの使用可能量が一定の割合を下回った場合にメールを送信する、基本条件アラートの設定方
法について取り上げています。
動的フィ ー ルドのサイズの算出
この例ではフィールドとディスク上のサイズに注目し、もっともスペースを消費しているディスクを判断します。
シナリオ
このサーチはフィールド名と消費されているディスクスペース量に関する事前の知識がない状態で、もっともス
ペースを消費しているディスクを判断します。
index=_internal earliest=-15m latest=now
| fieldsummary
| rex field=values max_match=0 "value\":\"(?<values>[^\"]*)\","
| mvexpand values
| eval bytes=len(values)
| rex field=field "^(?!date|punct|host|hostip|index|linecount|source|sourcetype|timeendpos|timestartpos|splunk_server)(?<Fiel
| stats count sum(bytes) as SumOfBytesInField values(values) as Values max(bytes) as MaxFieldLengthInBytes by FieldName
| rename count as NumberOfValuesPerField
| eventstats sum(NumberOfValuesPerField) as TotalEvents sum(SumOfBytesInField) as TotalBytes
| eval PercentageOfTotalEvents=round(NumberOfValuesPerField/TotalEvents*100,2)
| eval PercentageOfTotalBytes=round(SumOfBytesInField/TotalBytes*100,2)
| eval ConsumedMB=SumOfBytesInField/1024/1024
| eval TotalMB=TotalBytes/1024/1024
| table FieldName NumberOfValuesPerField SumOfBytesInField ConsumedMB PercentageOfTotalBytes PercentageOfTotalEvents
| addcoltotals labelfield=FieldName label=Totals
| sort - PercentageOfTotalEvents
明
最初のサーチは、別のサーチと時間範 に置き換えることができます。
63

本田技研工業 - マクニカネットワークス

IT運用とビッグデータの 意外な関係とは

マシンデータに眠っているのはビジネスチャンス

はいしゃうんちく其の四 "タバコいつやめるの？？"

Splunk Enterprise

納入書取扱いのお願い - 余市町ホームページ

介護記録の書き方

Splunk Enterprise の概要

Prospector

Splunk 5.0.2 Splunk チュートリアル