サーチマニュアル - Splunk Docs

S plu nk ® E nt er pr is e 6 . 4 . 0
サーチマニュアル
作成⽇時：2016/03/22 7:49 pm
Copyright (c) 2016 Splunk Inc. All Rights Reserved
T abl e o f C o nt e nt s
サーチの概要
サーチについて
Splunk Web 内の移動⽅法
サーチ処理⾔語
サーチの種類
コマンドの種類
サーチ処理⾔語の構⽂
Splunk Web、CLI、または REST API による検索
5
5
6
8
8
9
11
12
Sp l u n k サーチの使⽤
サーチ App の利⽤
実⾏中のサーチへのアクション
サーチモード
サーチアシスタントを使⽤してサーチをビルドする
サーチ履歴
13
13
16
17
18
19
サーチの最適化
最適化のクイックヒント
より良いサーチの作成
19
19
20
イベントの取得
イベントの取得について
サーチコマンド⼊⾨
フィールドを使ったイベントの取得
イベントサンプリング
インデックスおよび分散サーチピアからのイベントの取得
類似イベントの分類とグループ化
タイムラインを使ったイベントの調査
イベント詳細へのドリルダウンサーチの実⾏
[パターン] タブによるイベントパターンの識別
22
22
22
25
27
28
30
32
34
36
時間範囲の指定
時間を使ったサーチについて
サーチに適⽤する時間範囲の選択
サーチへの時間修飾⼦の指定
サーチへのリアルタイム時間範囲ウィンドウの指定
時間を使った近接イベントの検索
39
39
39
42
45
45
サブサーチ
サブサーチについて
サブサーチを使ったイベントの相関
サブサーチ結果のフォーマットの変更
46
46
47
48
統計的テーブルおよびグラフ視覚エフェクトの作成
変換コマンドとサーチについて
時間ベースのグラフの作成
時間ベースではないグラフの作成
フィールド値件数の上位/下位の視覚化
サマリー統計情報を表⽰するレポートの作成
サーチでの関連、統計的相関、および差異の調査
複数のデータシリーズを持つグラフの作成
複数⽇の時間ごとの合計の⽐較
テーブルの⾏またはセルの情報でセカンダリサーチを実⾏
48
49
49
50
50
51
51
52
53
53
テーブル/グラフを作成するためにピボットで⾮変換サーチを開く
56
リアルタイムのサーチとレポート
リアルタイムサーチとレポートについて
Splunk Web でのリアルタイムサーチとレポート
CLI でのリアルタイムサーチとレポート
リアルタイムサーチとレポートの、予想されるパフォーマンスと既
知の制限事項
リアルタイムサーチの利⽤の制限⽅法
58
58
60
60
61
フィールドの評価と操作
フィールドの評価と操作について
eval コマンドおよび関数の使⽤
ルックアップを使ったルックアップテーブルからのフィールドの追
加
サーチコマンドによるフィールドの抽出
複数値フィールドの操作と評価
63
63
63
64
統計の算出
統計の算出について
stats コマンドおよび関数の使⽤
stats と eval 式および関数の使⽤
サーチ結果へのスパークラインの追加
66
66
67
68
69
⾼度な統計
⾼度な統計について
⾼度な統計のためのコマンド
異常検出について
外れ値の検索と削除
異常の検出
パターンの検出
時系列の予測について
マシン学習
71
71
71
72
73
75
76
76
78
イベントのグループ化と相関
イベントのグループ化と相関について
時間を使ったイベント間の関係の識別
トランザクションについて
イベントの識別とトランザクションへのグループ化
78
78
79
79
80
ジョブの管理
ジョブとジョブ管理について
ジョブの寿命の延⻑
Splunk Web を使ったジョブの保存と共有
[ジョブ] ページでのジョブの管理
サーチジョブ調査の使⽤
OS からのジョブの管理
82
82
83
83
86
87
92
サーチ結果のエクスポート
サーチ結果のエクスポート
93
93
カスタムサーチコマンドの作成
カスタムサーチコマンドの作成について
サーチコマンドスタイルガイド
サーチコマンドの作成
Splunk Enterprise へのカスタムコマンドの追加
61
64
65
99
99
99
100
101
サーチの例と⼿引き
このセクションの内容
サーチへのコメントの追加
Windows ディスク使⽤量の監視とアラート
動的フィールドのサイズの算出
102
102
102
103
104
サーチの概要
サーチについて
このマニュアルでは、 [ サーチレポート] App Splunk Enterprise サーチ処理⾔語 (SPL) の使⽤⽅法について
説明していきます。
[サーチレポート] App の省略名であるサーチ App は、Splunk Enterprise でユーザーがデータを探索するための
主な⼿段です。サーチ App は、 Web ベースのインターフェイス (Splunk Web)、コマンドラインインターフェ
イス (CLI) および Splunk SPL から成り⽴っています。
ここから開始
Splunk Enterprise および サーチ App を利⽤したことがない場合は、まず『サーチチュートリアル』 をご覧く
ださい。『サーチチュートリアル』 では、サーチおよびレポート App の紹介、およびデータの追加、データの
サーチ、簡単なレポートやダッシュボードの作成などの事項をご案内しています。
『サーチチュートリアル』では、 Splunk Search を理解するための具体的な基礎を確認できます。
環境内での利⽤について
『サーチチュートリアル』 を完了したら、開始できるデータの種類、 Splunk のデータのインデックス⽅法、お
よび Splunk でのナレッジオブジェクトについて学習する必要があります。
注⽬するリソースを以下に⽰します。
Splunk インスタンスにデータを追加してください。『データの取り込み』 マニュアルを参照してくださ
い。
Splunk Enterprise でのインデックスの働きを理解してください。『インデクサーおよびインデクサーのク
ラスタの管理』マニュアルを参照してください。
フィールドとホスト、ソースタイプ、イベントタイプなどのナレッジオブジェクトを理解してください。
『ナレッジ管理』マニュアルを参照してください。
サ ー チ A pp の 効 果 的 な 学 習
なお当然ですが、このマニュアルの対象であるサーチ App を効果的に利⽤する⽅法を学習する必要があります。
このマニュアルには、すべてを説明する概念的な情報の詳細が含まれています。
サーチ App の基本的技能
Splunk Web 内の移動⽅法
サーチ App の利⽤
サーチの種類
コマンドの種類
5
サーチの詳細情報
イベントの取得
時間範囲の指定
サーチの最適化
テーブルおよびチャートの作成
フィールドの評価と操作
統計情報の算出および⾼度な統計
イベントのグループ化と相関
サーチジョブの管理
Splunk Enterprise のサーチ処理⾔語を構成するサーチコマンドや引数の⼀覧については、『サーチリファレン
ス』マニュアルを参照してください。
分散サーチ では、サーチ管理とプレゼンテーション層をインデックス作成とサーチ取得層から分離させること
で、デプロイを拡張することができます。分散サーチの詳細は、『分散サーチ』マニュアルを参照してください。
関連項⽬
Splunk Web 内の移動⽅法
Splunk サーチの使⽤
S pl u nk Web 内の移動⽅法
このトピックでは、Splunk Web の各種ビューへの移動⽅法について解説します。Splunk の Web ブラウザーイ
ンターフェイスです。
Splunk ホ ー ム に つ い て
Splunk ホームは、Splunk インスタンスからアクセスできるデータと App 向けの対話型ポータルです。Splunk
に初めてログインする場合、Splunk ホームが表⽰されます。このページには、すべての App が表⽰されます。
ホームの主な構成要素として、Splunk Enterprise ナビゲーションバー、[App] メニュー、Splunk Enterprise
の探索パネル、およびデフォルトのカスタムダッシュボード (ここには表⽰されていません) などがあります。
アカウントによっては、 Splunk Home の代わりに [サーチとレポート ] App の [サーチ] または [ピボット]
ビューなどの、他のビューを表⽰するように設定されていることもあります。
App パネル
[App] パネルには、Splunk インスタンス上にインストールされている、表⽰する権限のある App が表⽰されま
す。リストから App を選択すると、それを開くことができます。
Splunk Enterprise を標準インストールした場合、当初 1 つの App [サーチとレポート ] がワークスペースに表
⽰されています。[サーチとレポート] App は、Splunk サーチと呼ばれることもあります。複数の App が表⽰
されている場合、ワークスペース内の App をドラッグアンドドロップして配置を変更することができます。
次のアクションを実⾏することができます。
Splunk インスタンスにインストールされている App を表⽰、管理するにはギアアイコンをクリックしま
す。
インストールする他の App を参照するには、プラスアイコンをクリックします。
Splunk Ent erprise の探索
[Splunk Enterprise の探索] パネルには、Splunk Enterprise の使⽤を開始するために役⽴つオプションが⽤意
されています。各種アイコンをクリックして、[データの追加 ] ビューを開く、新しい App を参照する、Splunk
Enterprise ドキュメントを開く、Splunk Answers を開く、などの作業を⾏うことができます。
[ホーム] ダッシュボード
以下の Splunk Enterprise の探索パネルが、 [ホーム] ダッシュボードです。初めて Splunk Home を開いた場
合、デフォルトのダッシュボードはありません。
[ホームダッシュボードの選択 ] と表⽰されたラベルをクリックして、デフォルトのダッシュボードを選びます。
6
Splunk を利⽤したことがない場合は、いくつかのサーチを作成し、保存するまでデフォルトのダッシュボードの
選択を控えてください。独⾃のダッシュボードを作成し、デフォルトのダッシュボードとして利⽤する必要がある
でしょう。
ダッシュボードについての詳細は、『ダッシュボードと視覚エフェクト』 マニュアルを参照してください。
Splunk バ ー に つ い て
Splunk インスタンス内でビューを移動するには、Splunk バーを使⽤します。これは、Splunk Enterprise 内の
各ページに表⽰されます。これを使って App 間の切り替え、Splunk 設定の管理と編集、システムレベルメッ
セージの参照、およびサーチジョブの進捗状況の監視を⾏うことができます。
Splunk ホームにある Splunk バーの例を以下の画像に⽰します。
[ サーチとレポート] App の [サーチ] ビューなど他のビューにある Splunk バーでも、Splunk ロゴの隣りに
[ App] メニューが配置されています。
Splunk ホームに戻る
Splunk Web 内の任意のビューから、ナビゲーション バーの Splunk ロゴをクリックして、Splunk ホームに戻
ることができます。
[設定] メニュー
[設定] メニューには、ナレッジオブジェクト、分散環境設定、システムおよびライセンス、データ、および認証設
定に関連する設定ページが⼀覧化されています。これらのオプションのいずれかが表⽰されない場合は、それを表
⽰または編集する権限がありません。
[アカウント] メニュー
[アカウント ] メニューを使⽤して、アカウント設定の編集やこの Splunk インストールからのログアウトができ
ます。[アカウント ] メニュー は、新たにインストールされたデフォルトユーザー名である「Administrator」に
なっています。この表⽰名を変更するには、[アカウントの編集 ] を選択して、[フルネーム ] を変更します。その
他にも、タイムゾーン設定、このアカウントのデフォルト App 、アカウントのパスワードの編集ができます。
7
[メッセージ] メニュー
[メッセージ ] メニューには、すべてのシステムレベルのエラーメッセージが表⽰されます。新しい未読メッセー
ジがある場合、[メッセージ ] メニューの隣りに番号が表⽰されます。[X] をクリックすると、メッセージが削除
されます。
[アクティビティ] メニュー
[アクティビティ] メニューには、ジョブ、⽣成されたアラート、およびシステムアクティビティのビューへの
ショートカットが搭載されています。
[ジョブ ] をクリックすると、サーチジョブ管理ウィンドウが表⽰されます。ここでは、現在実⾏中のサーチ
を表⽰、管理することができます。
[⽣成されたアラート ] をクリックすると、⽣成されたスケジュール済みアラートが表⽰されます。
[システムアクティビティ ] をクリックすると、ユーザーアクティビティとシステムステータスに関する
ダッシュボードが表⽰されます。
ヘルプ
ビデオチュートリアル、Splunk Answers、Splunk サポートポータル、およびオンラインマニュアルへのリンク
を表⽰するには、[ヘルプ ] をクリックします。
サーチ
Splunk Enterprise インスタンス内のオブジェクトをサーチするには、[検索 ] を使⽤します。[検索 ] は⼤⽂字と
⼩⽂字を区別せずに、保存されたオブジェクトの ID、ラベル、説明で⼀致検索を実⾏します。たとえば、
「error」と⼊⼒すると、「error」を含む保存済みのオブジェクトが返されます。
このような保存済みオブジェクトには、レポート 、ダッシュボード 、アラート 、データモデル が含まれます。
既存のカテゴリ毎に分類されたリストに結果が表⽰されます。
[サーチでエラーを開く ] をクリックして、[サーチレポート ] App でエラー のサーチを実⾏することもできま
す。
関連項⽬
Splunk サーチの使⽤
サーチ処理⾔語
サーチ処理⾔語 (SPL) は、あらゆるサーチコマンド、関数、引数、句を網羅しています。サーチコマンドは、イ
ンデックスから取得したイベントに対する処理を Splunk Enterprise に指⽰します。たとえば、コマンドを使っ
て不要な情報のフィルタリング、追加情報の抽出、新しいフィールドの評価、統計情報の算出、結果の並べ替え、
グラフの作成などを⾏います。
⼀部のサーチコマンドには、それに関連した関数や引数が⽤意されています。これらの関数や引数を使って、結果
の処理⽅法や処理対象フィールドを指定します。たとえば、関数を使ってグラフ内のデータのフォーマット、算出
する統計情報の指定、評価対象フィールドの指定などを⾏うことができます。また、句を使ってサーチ結果をグ
ループ化できるコマンドも⽤意されています。
SPL を理解するために、このマニュアルの次のトピックを参照してください。
サーチの種類
コマンドの種類
Splunk サーチの使⽤
SPL 構⽂の詳細は、『サーチリファレンスマニュアル』の「SPL 構⽂の理解」を参照してください。
サーチの種類
サーチを実⾏するにしたがって、そのパターンを理解したり、サーチ可フィールドとして役⽴つその他の情報が分
かってくることでしょう。新たなデータのインデックスを作成するにつれて、これらの新規フィールドを認識する
8
ように Splunk を設定したり、サーチに応じて新たなフィールドを作成することができます。どのような場合で
も、イベントデータのフィールド、イベント、およびトランザクションに関するこのナレッジを使⽤、追加、編集
できます。このナレッジの収集は、効率的なサーチの作成や詳細なレポートの構築に役⽴ちます。
サーチ⾔語とその構⽂の詳細を学習する前に、まず⽬的が何なのかを確認しておきましょう。⼀般的には、
Splunk にデータを取り込んだら、以下のような作業を⾏います。
インデックスを作成したデータを調査して詳細を把握する、または問題の主原因を特定する。
サーチ結果を表形式またはその他の視覚的な形式のレポートで表⽰する。
このために、raw イベントサーチと変換サーチの 2 種類のサーチが存在しています。
r aw イ ベ ン ト サ ー チ
raw イベントサーチ は、インデックスから単にイベントを取得するサーチで、⼀般的には問題の分析を⾏う場合
に使⽤されます。このようなサーチの例として、エラーコードのチェック、イベントの相関付け、セキュリティ上
の問題の調査、障害の分析などが挙げられます。⼀般的にこのようなサーチにはサーチコマンドは含まれず
(search ⾃体を除く)、サーチ結果は raw イベントの⼀覧になります。
raw イベントサーチの詳細は、「イベントの取得について」を参照してください。
変換サーチ
変換サーチ は、⼀連の結果に対してある種の統計的な計算を実⾏するサーチです。これらは、まずインデックス
からイベントを取得して、そのイベントを 1 つまたは複数のサーチコマンドに渡すタイプのサーチです。これら
のサーチは常にフィールドと最低 1 つの統計コマンドのセットを必要としています。この例としては、毎⽇のエ
ラーイベント数の取得、特定ユーザーのログイン回数のカウント、フィールド値の 95 番⽬のパーセンタイルの算
出などが挙げられます。
サーチ構造の詳細は、「サーチ処理⾔語の構⽂」を参照してください。
サブサーチを使⽤した結果のフィルタリングの詳細については、「サブサーチについて」を参照してくださ
い。
このトピックの変換サーチとコマンドの詳細は、「変換コマンドとサーチについて」を参照してください。
情報密度
raw イベントを取得するにせよレポートを作成するにせよ、サーチ対象の情報がスパースなのかまたはデンスなの
かを考慮する必要があります。
スパースサーチ は、⼤量のデータセット内で滅多に発⽣しない単⼀のイベントを検索するサーチです。これ
は「⼲し草の⼭から 1 本の針を⾒つける」サーチと⽐喩されることもあります。たとえば、特定の IP アド
レスやエラーコードを探すサーチなどが挙げられます。
デンスサーチ は、多数のイベントをスキャン、レポートするサーチです。たとえば、発⽣したエラー数のカ
ウントや特定のホストからすべてのイベントの検索するなどが挙げられます。
コマンドの種類
Splunk (SPL ) に関する情報を確認する場合、サーチコマンドの種類を表すために、ストリーム配信、⽣成、およ
び変換などの⽤語が使われているのにお気づきかもしれません。このトピックでは、これらの⽤語の意味と、各カ
テゴリに該当するコマンドを説明しています。
すべてのサーチコマンドをおおまかに分類する 4 つのカテゴリが存在しています (分散可能ストリーミング、集中
ストリーミング、変換、⽣成)。
それぞれのタイプでのコマンドの完全リストは、『サーチリファレンス』の「コマンドタイプ」を参照してくださ
い。
ストリーミングおよび⾮ストリーミングコマンド
ストリーミングコマンド は、サーチが返した各イベントを処理します。基本的には１つのイベントはイン、そし
て 1 つ (または無し) のイベントはアウトです。
たとえば、 eval コマンドは、 first_name フィールドでの値の連結、空⽩、および
まれるように、新しいフィールド full_name を作成します。
last_name
フィールドでの値が含
... | eval full_name = first_name." ".last_name
eval
コマンドは、他のイベントを考慮することなく、それぞれのイベントを評価します。
⾮ストリーミングコマンド は、コマンドが⼀連のイベント全体を操作できるように、すべてのインデクサーから
のイベントを必要とします。
9
たとえば、 sort コマンドがイベントをソートし始められるように、⼀連のイベント全体が sort コマンドによって
受信される必要があります。⾮ストリーミングコマンドの他の例には、 dedup, stats, and top が含まれます。
⾮ストリーミングコマンドは、⼀連のイベント全体をサーチヘッドに強制します。これには多くのデータの移動と
並列性の損失が必要です。
⾮ストリーミングのコストの軽減⽅法については、このマニュアルのより良いサーチの作成を参照してください。
種類による違い
分散可能ストリー
ミング
集中ストリー
ミング
⾮ストリーミング基づいた
イベント
変
換
インデクサーを実⾏できる
Y
N
N
N
最終的なの⼊⼒の前に出⼒できる
Y
Y
N
N
⼊⼒がイベントの場合、出⼒はイベ
ントである
Y
Y
Y
N
分散可能ストリーミング
ストリーミングコマンドは、サーチが返した各イベントを処理します。分散可能ストリーミングコマンドはインデ
クサー上で実⾏され、処理時間を向上します。サーチの他のコマンドは、分割可能ストリーミングコマンドがイン
デクサー上で実⾏されているかどうかを判断します。
ストリーミングコマンドの前にすべてのコマンドがインデクサー実⾏されている場合、分割可能ストリーミ
ングコマンドはインデクサーで実⾏されます。
ストリーミングコマンドの前にいずれかのコマンドがサーチヘッドで実⾏されている必要があり、サーチの
残りのコマンドはサーチヘッドで実⾏される必要があります 。サーチがサーチヘッドへの移動を実⾏してい
る場合、それをインデクサーに戻すことはできません。
分散可能ストリーミングコマンドは、インデックスデータのサブセットに並列的に適⽤できます。たとえば、 rex
コマンドはストリーミング配信されています。それは、サーチ時にフィールドを抽出してそれをイベントに追加し
ます。
⼀部の共通の分散可能ストリーミングコマンドは、eval、fields、 makemv、 rename、 regex、 replace、
strcat、 where です。
分散可能ストリーミングコマンドの完全リストは、『サーチリファレンス』の「ストリーミングコマンド」を参照
してください。
集中ストリーミング
集中ストリーミングコマンドは、サーチが返した各イベントに変換を適⽤します分散可能ストリーミングコマンド
とは違い、集中ストリーミングコマンドとは、サーチヘッドのみ処理します。これらのコマンドを説明するため
に、「ステートフルストリーミング」という⽤語が使われることもあります。
集中ストリーミングコマンドには、head、streamstats、⼀部のモードの dedup、および⼀部のモードの
cluster が含まれます。
⽣成
⽣成コマンド は、変換を⾏わずに情報を取得するコマンドです。⽣成コマンドは、イベント⽣成 (分散可能または
集中管理) またはレポート⽣成コマンドです。コマンドの種類により、結果はリストまたはテーブルに返されま
す。
⼀般的に⽣成コマンドは、サーチの先頭で実⾏され、その前にはパイプ⽂字が付けられます。つまり、⽣成コマン
ドにパイプするサーチはありません。この例外が search コマンドです。サーチの先頭に暗黙的に存在しており、
実⾏する必要はありません。
たとえば、⽣成コマンドには、dbinspect、datamodel、 inputcsv、 metadata、 pivot、 search、 tstats が含
まれます。
⽣成コマンドの完全リストは、『サーチリファレンス』の「⽣成コマンド」を参照してください。
変換
変換コマンド は、結果をデータテーブルに変換します。各イベントのセル値を、Splunk が統計⽬的で使⽤できる
数値に変換します。変換コマンドはストリーミングではありません。また、サーチ結果のデータを縦棒、横棒、折
れ線、⾯、および円グラフなどの視覚エフェクトが必要とするデータ構造に変換するために⽤いられます。
変換コマンドには、chart、timechart、stats、top、rare、contingency、highlight、typer、および列合計 (⾏
合計ではない) を算出するために⽤いられる場合の addtotals が含まれます。
10
統計的テーブルおよびグラフ視覚エフェクトの作成での変換コマンドやその役割の詳細は、このマニュアルの「変
換コマンドとサーチについて」を参照してください。
変換コマンドの完全リストは、『サーチリファレンス』の「変換コマンド」を参照してください。
その他のコマンド
これらのカテゴリに該当しないコマンドもあります。sort、eventstats、dedup の⼀部のモード、およびの
cluster の⼀部のモードのコマンドは、⾮変換、分散不可能、および⾮ストリーミングです。
サーチ処理⾔語の構⽂
Splunk サーチは、パイプ (|) ⽂字で区切られた⼀連のコマンドから成り⽴っています。各パイプ⽂字の直後の、
空⽩⽂字で区切られた最初の⽂字列がコマンドになります。各コマンドの残りの⽂字列は、そのコマンドに応じた
⽅法で処理されます。
このトピックでは、Splunk サーチの構造およびフィールドとフィールド値に対して各コマンドと構⽂ルールが共
有する⼀部の構⽂ルールについて説明していきます。
サーチの詳細
サーチコマンドがデータをどのように処理するかを理解するために、インデックスデータをテーブルとして考えて
みましょう。各サーチコマンドは、表の形を再定義します。
たとえば、以下のサーチコマンドについて⾒てみましょう。
sourcetype=syslog ERROR | top user | fields - percent
ディスクはインデックスが作成された、⼀定サイズのすべてのデータを表しています。テーブルの列はフィールド
を、⾏はイベントを表しています。最初の中間結果テーブルでは、⾏数が減少しています。これは、サーチ単語
「sourcetype=syslog ERROR」に⼀致した、インデックスから取得されたイベントのサブセットを表していま
す。2 番⽬の中間結果テーブルでは、列が減少しています。これは、イベントを上位 10 ⼈のユーザーに限定し、
ユーザー、カウント、および割合を表⽰する「top user」コマンドの結果を表しています。次に、「fields percent」で割合を表⽰する列が削除され、⽬的の情報のみを含む最終結果テーブルが表⽰されます。
サーチパイプラインについて
サーチパイプラインは、Splunk サーチの構造を表しています。これは、パイプ⽂字「|」を使って複数のコマンド
を連続的に結合します。パイプ⽂字は、あるコマンド (パイプの左側) の出⼒または結果を、次のコマンド (パイプ
の右側) の⼊⼒として使⽤することを表しています。これにより、⽬的の結果が得られるまでパイプラインの各ス
テップでデータを調節または追加することができます。
Splunk サーチは、パイプラインの先頭にあるサーチ単語から開始されます。これらのサーチ単語は、インデック
スから取得するイベントを⽰す、キーワード、フレーズ、論理演算式、キー/値のペアなどです。「イベントの取
得について」を参照してください。
次に取得されたイベントは、パイプ⽂字を使って次のサーチコマンドに⼊⼒されます。サーチコマンドは、イン
デックスから取得したイベントに対する処理を Splunk に指⽰します。たとえば、コマンドを使って不要な情報の
フィルタリング、追加情報の抽出、新しいフィールドの評価、統計情報の算出、結果の並べ替え、グラフの作成な
どを⾏います。⼀部のコマンドには、それに関連した関数や引数が⽤意されています。これらの関数と引数によ
り、結果の処理⽅法や処理対象フィールドなどを指定できます。たとえば、グラフの作成⽅法、算出する統計情
報、評価対象フィールドなどを指定できます。また、句を使ってサーチ結果をグループ化できるコマンドも⽤意さ
れています。
サーチコマンドでできる操作の詳細は、「サーチ処理⾔語について」を参照してください。
サーチコマンドのリストは、『サーチリファレンス』の「コマンドクイックリファレンス」を、構⽂と使⽤
⽅法についてはそれぞれのサーチコマンドの参照トピックをご覧ください。
引⽤符とエスケープ⽂字
⼀般的に、空⽩⽂字、カンマ、パイプ、引⽤符、⾓括弧を含むフレーズやフィールド値は、引⽤符で囲む必
要があります。 引⽤符の数は偶数でなければなりません。⽂字列の最初に引⽤符を指定したら、その⽂字列の終
了を表す引⽤符も指定する必要があります。例：
のようなサーチは、⽂字列「error」を含むイベント数を検索します。
のようなサーチは、error、1 つのパイプ、stats、および count がその順
番で含まれている raw イベントを返します。
error | stats count
... | search "error | stats count"
また、論理演算⼦やフィールド/値のペアなどが、サーチ時に元の意味で解釈されないように、そのようなキー
ワードやフレーズを引⽤符で囲むことも可能です。例：
11
キーワード AND を論理演算⼦として解釈せずにサーチする場合：error "AND"
フィールド/値のペアをフレーズとしてサーチする場合： error "startswith=foo"
円記号またはバックスラッシュ (\) は、引⽤符、パイプ、および円記号⾃⾝をエスケープ処理する場合に使
⽤します。 円記号によるエスケープシーケンスは、引⽤符内でも展開されます。例：
サーチ内に「\|」と指定すると、このパイプ⽂字は 2 つのコマンドの区切り⽂字ではなく、処理対象のパイ
プ⽂字としてコマンドに渡されます。
「\"」と指定すると引⽤符がそのまま⽂字としてコマンドに渡されます。たとえば、⽂字通りの引⽤符を検
索したり、rex を使ってフィールド内に引⽤符を挿⼊する場合に使⽤します。
「\\」と指定すると、⽂字通りの円記号がコマンドに渡されます。
Splunk が円記号 (バックスラッシュ) シーケンスを認識しない場合、それは変更されません。
たとえば、サーチ⽂字列内に「\s」とある場合、これは既知のエスケープシーケンスではないため「\s」と
してコマンドに渡されます。
しかし、「\\s」と指定した場合、「\\」は既知のエスケープシーケンスで「\」に変換されるため、「\s」
としてコマンドに渡されます。
アスタリスク (* ) を円記号 (バックスラッシュ) でエスケープ処理して、サーチすることはできませ
ん。 Splunk はアスタリスクを主区切り⽂字として取り扱います。そのため、インデックスに含まれることはあり
ません。アスタリスク⽂字をサーチしたい場合は、データの後処理を⾏う正規表現サーチを実⾏する必要がありま
す。
index=_internal | regex ".*\*.*"
主区切り⽂字の詳細は、『データの取り込み』マニュアルの「イベント処理の概要」を参照してください。
例
例 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」になります。数値を取得するコマンドは、計算のために内部で⾃動的に⽂字を数値に変換しま
す。
NULL フィールド
NULL フィールドは、特定の結果やイベントに存在しないフィールドです。サーチ内のその他のイベントま
たは結果に、このようなフィールド値が存在していることがあります。たとえば、fillnull コマンドは、
サーチ内の他のイベントや結果に存在しているフィールドが⾒つからないイベントや結果に、フィールドと
デフォルト値を追加するために⽤いられます。
空のフィールド
空のフィールドは、単⼀の空⽂字列を値に持つフィールドです。
空の値
空⽂字列または ""の値です。これは、⻑さが 0 の⽂字列として扱うこともできます。
複数値フィールド
複数の値を持つフィールドです。NULL フィールド以外のフィールドは、⽂字列のリストを保有していま
す。⼀般的には、1 つの値を持つリストになります。リストに複数のエントリが存在している場合、それは
複数値フィールドになります。『サーチ』マニュアルの「複数値フィールドの操作と評価」を参照してくだ
さい。
S pl u nk Web、CL I 、または R E S T A P I による検索
12
⼀般的には、Splunk Web のサーチ App からサーチを実⾏します。しかし、コマンドラインインターフェイス
(CLI) や REST API からサーチを実⾏することもできます。どの⽅法を使⽤するのが最適なのかは、サーチ⽬的に
よって異なります。
Splunk W eb に よ る 検 索
Splunk Web でサーチを実⾏する場合は、サーチ App を使⽤することになり、サーチモード (⾼速、詳細、ス
マート) によりサーチ処理を制御します。Splunk は選択したモードに応じて、デフォルト以外のフィールドを⾃
動的に発⾒、抽出して、それをイベントリストまたはテーブルとして返し、次にイベントタイムラインの⽣成に必
要な計算を実⾏します。イベントタイムラインの計算では、ユーザーがタイムライン上のバーをクリックした時に
データを提供できるように、バケツが作成されてイベントとフィールドの統計情報がディスパッチディレクトリに
保持されます。そのため、コストが⾮常に⾼くなります。
詳細は、このマニュアルの「サーチに合わせたサーチモードの設定」を参照してください。
C L I、 ま た は R EST A P I に よ る 検 索
コマンドラインインターフェイス (CLI) または REST API のサーチジョブエンドポイントを使⽤してサーチを作
成、実⾏する場合、 Splunk W eb を介さず直接 splunkd でサーチの処理が⾏われます。これらのサーチでは、
イベントタイムラインの算出、⽣成が⾏われないため、Splunk Web と⽐べて⼤幅にサーチ処理が⾼速化されま
す。その代わり、CLI のサーチ結果は、サーチの種類に応じて raw イベントリストまたはテーブルとして表⽰さ
れます。
詳細は、『サーチリファレンス』マニュアルの「CLI サーチについて」を参照してください。
また、『REST API チュートリアル』マニュアルの「REST API を使⽤したサーチの作成」を参照してくだ
さい。
Spl unk サーチの使⽤
サーチ A pp の利⽤
[サーチ レポート] App は、データのサーチとレポートの作成に使⽤する [サーチ] App と呼ばれます。
ここでは、 [サーチ] App を構成する表⽰と要素について説明しています。
サ ー チ A pp の 利 ⽤
1. Splunk ホームで、[App ] パネルの [サーチとレポート ] をクリックします。[サーチとレポート] App のサー
チサマリービューが開きます。
サーチサマリービュー
サーチの実⾏前、サーチサマリービューには App バー、 サーチバー、タイム レンジ ピッカー、[サーチ⽅法] パ
ネル、[検索内容 ] パネル、[サーチ履歴 ] パネルが表⽰されています。
サーチサマリービューの固有の要素は、 [サーチ⽅法 ] と [検索内容 ] パネル、および [サーチ履歴 ] です。これら
の要素は以下を参照してください。他の要素は「新規サーチビュー」のセクションを参照してください。
エレメント
サーチ⽅法
説明
サーチチュートリアルとサーチマニュアルのリンクから、サーチ⽅法を参照することがで
きます。
この Splunk インスタンスにインストールされており、参照する権限があるデータのサマ
13
検索内容
リー情報が表⽰されます。[データサマリー ] をクリックすると、データサマリーダイア
ログボックスが開き、データのホスト、ソース、ソースタイプを確認することができま
す。
サーチ履歴
サーチの履歴の閲覧や操作ができます。サーチ履歴では、キーワードや時間によって検索
やフィルタリングが可能な過去のサーチの拡張テーブルが表⽰されます。最初のサーチの
実⾏後、サーチ履歴が表⽰されます。詳細は、このマニュアルの「サーチ履歴」を参照し
てください。
データサマリー
[データサマリー] ダイアログボックスには、[ホスト]、[ソース]、[ソースタイプ] の 3 つのタブがあります。これ
らのタブはデータのサーチ可能なフィールドを⽰しています。
ホスト
イベントのホスト は、イベントの発⽣元となるマシン名、IP アドレス、またはネットワークホストの完全修飾ド
メイン名になります。分散環境では、ホストフィールドを使⽤して特定のマシンからデータをサーチすることがで
きます。
ソース
イベントのソース は、イベントの発⽣元の、ファイルまたはディレクトリパス、ネットワークポート、またはス
クリプトになります。
ソースタイプ
イベントのソースタイプ は、そのデータの種類を表しています。⼀般的には、そのデータのフォーマットに基づ
いています。このような分類により、複数のソースやホストにまたがって同じ種類のデータをサーチすることがで
きます。
14
この例のソースタイプを以下に⽰します。
access_co m bined_wco o kie： Apache Web サーバーログ
secure： セキュリティサーバーログ
vendo r_sales： グローバルセールスベンダー
Splunk Enterprise でのデータのソースタイプ分類については、『データの取り込み』マニュアルの「ソースタイ
プが重要な理由」を参照してください。
[新 規 サ ー チ ] ビ ュ ー
[新規サーチ ] ビューは、サーチの実⾏後、または [サーチ ] タブをクリックして新規サーチを開始した後に開きま
す。このビューでも App バー、 サーチバー、タイム レンジ ピッカーを使⽤できます。また、このビューには、
サーチアクションボタン、サーチモードセレクタ、イベント数、ジョブステータスバー、およびイベント、パター
ン、統計情報、視覚エフェクトの結果タブなど、さまざまなエレメントが含まれています。
サーチバーで index=_internal を⼊⼒し、[Ent er ] を押して Splunk instance の内部ログファイルからイベントを
表⽰させることができます。
『サーチチュートリアル』の「Splunk へのデータの取り込み」の⼿順に従って、サーチバーに buttercupgames を
⼊⼒し、[Ent er ]を押して、イベント内の「buttercupgames」キーワードを検索することができます。
このビューでは、 App バー、サーチバー、タイム レンジ ピッカーも利⽤できます。[新規サーチ ] ビューには、
サーチアクションボタン、サーチモードセレクタ、イベント数、ジョブステータスバー、およびイベント、パター
ン、統計情報、視覚エフェクトの結果タブなど、さまざまなエレメントが含まれています。
App bar
App バーを使って、[サーチとレポート] App のサーチ、ピボット、レポート、アラート、ダッシュボードなどの
15
各種ビューに移動することができます。これらの他の機能専⽤の完全マニュアルがあります。
『アラート』マニュアル
『ダッシュボードと視覚エフェクト』マニュアル
『ピボット』マニュアル
『レポート』マニュアル
サーチバー
Splunk Web 内でサーチを実⾏するには、サーチバーを使⽤します。サーチ⽂字列を⼊⼒して、[Enter] キーを押
すか、タイム レンジ ピッカーの右にある望遠鏡型アイコンをクリックしてください。
タイム レンジ ピッカー
タイムは指定した最も需要な単⼀サーチパラメーターです。
特定の期間のイベントを取得するには、タイム レンジ ピッカーを使⽤します。リアルタイムサーチの場合、イベ
ントを取得するウィンドウを指定することができます。履歴サーチの場合、相対時間範囲 (15 分前、昨⽇など) ま
たは特定の⽇付/時間範囲を指定して、サーチを限定することができます。タイム レンジ ピッカーには、あらか
じめ設定された時間範囲から選択できますが、独⾃の時間範囲を⼊⼒することも可能です。
詳細は、「時間を使ったサーチについて」を参照してください。
サーチアクション
サーチジョブの活⽤、保存、共有、エクスポート、サーチ結果の印刷を含む、幅広いサーチアクションを実⾏でき
ます。
詳細は、以下の項⽬を参照してください。
「実⾏中のサーチへのアクション」
「ジョブとジョブ管理について」
「サーチ結果のエクスポート」
サーチモード
サーチモードセレクタを使って、ご⾃分のニーズに合わせたサーチを利⽤することができます。[スマート] (デ
フォルト)、[⾼速]、および [詳細] モードがあります。
詳細は、「サーチモード」を参照してください。
実⾏中のサーチへのアクション
Splunk では、処理中のサーチを管理し、レポートやダッシュボードを作成するための⼀連のコントロール機能が
⽤意されています。
サーチジョブ進捗状況の制御
サーチの開始後は、[サーチ] ビューから移動しなくても、サーチジョブ に関する情報を参照、管理することがで
きます。サーチの実⾏後は、⼀時停⽌中、または完了後、[ジョブ ] をクリックして、適切なオプションを選択し
ます。
以下の作業を⾏うことができます。
ジョブ設定の編集： [ジョブ設定] ダイアログボックスを開くと、ジョブの読み取り権限の変更、ジョブ寿
命の延⻑、および URL の取得を⾏うことができます。URL を使⽤して、他の⼈とジョブを共有したり、
ブックマークを Web ブラウザーのジョブに追加することができます。
ジョブをバックグラウンドに送る： サーチジョブの完了が遅く、バックグラウンドでジョブを実⾏したい
場合は、このオプションを選択します。これにより、新規サーチジョブの実⾏を含む他の Splunk 作業を実
⾏することができます。
ジョブの調査： 別のウィンドウに、[サーチジョブ調査 ] を使ったサーチジョブの情報と測定基準を表⽰し
ます。サーチの実⾏中またはサーチ完了後にこの操作を⾏うことができます。詳細は、このマニュアルの
「サーチジョブ調査によるサーチジョブプロパティの表⽰」を参照してください。
ジョブの削除： 現在実⾏中、⼀時停⽌中、または完了したジョブを削除する場合に選択します。ジョブを削
除しても、サーチをレポートとして保存することもできます。
詳細は、このマニュアルの「ジョブとジョブ管理について」を参照してください。
サーチモードの変更
サーチモードを使って、サーチを制御することができます。返されるイベントデータを減らすことでサーチを⾼速
16
化するように設定したり (⾼速モード)、できる限り多くの情報を返すように設定したり (詳細モード) できま
す。スマートモード (デフォルト設定) では、実⾏するサーチの種類に応じてサーチモードを⾃動的に切り替えま
す。
詳細は、次のトピック「サーチモードの設定」を参照してください。
結果の保存
[名前を付けて保存 ] メニューには、サーチ結果をレポート 、ダッシュボードパネル 、アラート 、およびイベン
トタイプ として保存するためのオプションが搭載されています。
レポート ：サーチを後で再利⽤する場合は、レポート として保存します。レポートを再実⾏するには、レ
ポート⼀覧ページで⽬的のレポート名をクリックします。詳細は、『レポート』マニュアルの「レポートの
作成と編集」を参照してください。
ダッシュボードパネル ：このオプションは、サーチに基づくダッシュボードパネル を⽣成し、新規または
既存のダッシュボード に追加する場合に使⽤します。ダッシュボードの詳細は、「ダッシュボードとフォー
ム」および「ダッシュボードエディタについて」を参照してください。両⽅のトピックとも、『ダッシュ
ボードと視覚エフェクト』 マニュアルに記載されています。
アラート ：サーチに基づくアラート を定義します。アラートは保存済みサーチをバックグラウンドで実⾏し
ます (スケジュール またはリアルタイム で)。サーチでアラートに設定した条件と⼀致する結果が返される
と、アラートが⽣成されます。詳細は、『アラート』 マニュアルを参照してください。
イベントタイプ ：共通の特徴を持つイベントを分類することができます。パイプ記号 またはサブサーチ が
含まれていないサーチは、このオプションを使ってイベントタイプとして保存できます。詳細は、『ナレッ
ジ管理』 マニュアルの「イベントタイプについて」および「Splunk Web でのイベントタイプの定義と管
理」を参照してください。
その他のサーチアクション
ジョブの進捗状況コントロールとサーチモードセレクタの中間には、3 種類のボタンがあります。これを使って
サーチ結果を共有 、エクスポート 、印刷 することができます。
ジョブを共有するには、[共有 ] をクリックします。このオプションを選択すると、ジョブの寿命が 7 ⽇間に
延⻑され、読み取り権限が「全員」に設定されます。
結果をエクスポートするには、[エクスポート ] をクリックします。raw イベント、CSV､XML 、JSON 形
式での出⼒を選択できます。また、エクスポートする結果数も指定できます。
設定されているプリンタに結果を送るには、[印刷 ] をクリックします。
また、[名前を付けて保存 ] メニューの隣にある [閉じる ] ボタンを使って、サーチをキャンセルして Splunk
ホームに戻ることができます。
サーチモード
サーチモードセレクタを使って、ご⾃分のニーズに合わせたサーチを利⽤することができます。
サーチモードセレクタは、サーチバーの右上⾓にあります。[ スマート] (デフォルト)、[ ⾼速]、および [ 詳細] モー
ドを利⽤できます。
17
設定内容に応じて、サーチで利⽤できるすべてのデータを表⽰したり (サーチ時間が⻑くなります)、さまざまな⽅
法でサーチを⾼速化/能率化したりすることができます。
⾼速 および詳細 モードは、サーチモードの両極をなしています。デフォルトのスマート モードは、実⾏するサー
チの種類に応じてこれらのモードを切り替えます。保存済みサーチを初めて実⾏する場合は、スマート モードで
実⾏されます。
⾼速モードの選択
⾼速 モードはサーチのパフォーマンスを優先し、不要なフィールドやイベントデータを返しません。つまり、必
須かつ要求されるものだけが返されることになります。
フィールド検出を無効にします。 フィールド検出 は、Splunk がデフォルトフィールド 以外の host、
source、および sourcetype などのフィールドの抽出に使⽤するプロセスです。これは、Splunk がデフォルト
フィールドとサーチの要件を満たすために必要なフィールド (特定のフィールドをサーチする場合、それら
のフィールドが抽出される) の情報のみを返すことを表しています。
レポートサーチの実⾏時に、サーチ結果はレポート結果テーブルまたは視覚化した状態でのみ表⽰さ
れます (変換コマンド を含むサーチ)。⾼速モードでは、変換コマンドを含まないサーチについては、イベン
トリストとイベントタイムラインのみが表⽰されます。
フィールド検出を有効または無効にした時の Splunk Enterprise の処理については、『ナレッジ管理』マニュア
ルの「Splunk Enterprise がフィールドを抽出する時期」を参照してください。
詳細モードの選択
詳細 モードは、サーチの完了に時間がかかる場合やサーチにレポートコマンドが含まれている場合でも、可能な
限りすべてのフィールドとイベントデータを返します。
可能なすべてのフィールドを検出します。 これには、デフォルトのフィールド、⾃動サーチ-時間フィール
ド抽出、およびすべてのユーザー定義のインデックス-時間およびサーチ-時間フィールド抽出が含まれてい
ます。検出フィールドは [イベント] 結果タブの左側のフィールドサイドバーに表⽰されます。
結果のイベントリストビューを返して、サーチタイムラインを⽣成します。 サーチにレポートコマンド
が含まれている場合は、レポートテーブルと視覚エフェクトも⽣成します。
変換サーチを利⽤したいけれども、レポートに必要なフィールドが分からない場合、または正しいイベントを要約
しているかどうかを検証したい場合には、詳細モードを使⽤します。
注意 ：レポートを詳細モードで実⾏する場合、レポート⾼速化の恩恵は受けられません。レポート⾼速化を有効
にして、その結果処理速度が向上した場合に、そのサーチを詳細モードに切り替えると処理速度が低下して、⾼速
化機能を利⽤しない場合と同じになってしまうことに注意してください。
レポート⾼速化機能は、10 万件を超えるイベントに対して変換コマンド を利⽤したサーチを実⾏するような、完
了までに時間がかかるサーチを前提に設計されています。詳細は、『レポート』マニュアルの「レポートの⾼速
化」を参照してください。
スマートモードの選択
作成されたすべてのレポートは、デフォルトのサーチモードであるスマートモードで実⾏されます。スマー
ト モードは、実⾏するサーチまたはレポートに対して最良の結果を返します。単にイベントをサーチする場合、必
要なすべてのイベントの情報が取得されます。変換サーチを実⾏する場合、Splunk Enterprise は完全性よりも速
度を重視して、レポート結果テーブルや視覚エフェクトを直接提供します。
変換コマンドを含まないスマートモードサーチを実⾏する場合、サーチは詳細モードのように動作します。
可能なすべてのフィールドを検出します。
フルイベントリストおよびイベントタイムラインを⽣成します。 変換コマンドが必要なため、イベント
テーブルや視覚エフェクトは表⽰されません。
変換コマンドを含むスマートモードサーチを実⾏する場合、サーチは⾼速モードのように動作します。
フィールド検出を無効にします。
イベントリストとイベントタイムラインの⽣成に時間を費やさず、 レポート結果テーブルや視覚エフェ
クトに直接移動します。
変換コマンドや変換サーチの詳細は、『サーチ』マニュアルの「レポートコマンドについて」を参照してくださ
い。
サーチアシスタントを使⽤してサーチをビルドする
18
Splunk のサーチ処理⾔語は多彩で、多数のサーチコマンド、引数、および関数が⽤意されています。Splunk
Web にサーチの書き込みをする際、サーチアシスタントを使⽤して容易にサーチ⽂字列を構成することができま
す。
サーチアシスタントを使⽤してサーチ作成時にデータを表⽰
サーチバーに⽂字を⼊⼒すると、サーチアシスタントがそれに合わせた先⾏⼊⼒テキストまたは⽂脈上適切なテキ
ストを表⽰します。このような⽂脈上のテキストは、データの内容に基づいて表⽰されます。⼊⼒を続けると、
[⼀致する単語 ] に表⽰される項⽬がそれに応じて変化します。
サーチアシスタントには、サーチ⽤語に⼀致する項⽬数も表⽰されます。この値は、Splunk から返されるサーチ
結果数の⽬安になります。データ内に当該の⽤語またはフレーズが存在していない場合、サーチアシスタントには
表⽰されません。
サーチアシスタントの設定の変更
サーチアシスタントはサーチバーから呼び出される Python エンドポイントで、サーチバーの下側にスライドされ
るパネル上の HTML を返します。サーチアシスタントは searchbnf.conf ファイルからその説明と構⽂情報を取得
します。このファイルには、すべての Splunk サーチコマンドとその構⽂が定義されています。提案するフィール
ドの表⽰に fields.conf ファイルを使⽤したり、ユーザーに既存の保存済みサーチと似ていることを知らせるため
に savedsearches.conf ファイルを使⽤したりもしています。
サーチ履歴
サーチ履歴 パネルではサーチ履歴の閲覧や操作ができます。
サーチ履歴 パネルを探すには、[サーチ ] をクリックし、Splunk サーチのランディングページであるサーチサマ
リーダッシュボードを開きます。
サーチ履歴を閲覧するには、[サーチ履歴 ] の [サーチ履歴の拡張 ] をクリックします。サーチ履歴は下記の欄が
あるテーブルで表⽰されます。
サーチ ：プレーンテキストとして表⽰され、コンテンツのコピーが可能なサーチ⽂字列を含みます。デフォ
ルトのサーチ履歴テーブルでは、⼀列に収まるようサーチ⽂字列が切り捨てられます。⻑いサーチストリン
グ⽂字列については、サーチ⽂字列の左にある拡張アイコンをクリックして、サーチ⽂字列をすべて表⽰す
ることができます。
アクション ：アクション [サーチに追加 ] が含まれます。[サーチに追加 ] をクリックし、サーチバーのコン
テンツを選択した過去のサーチコンテンツに差し替えます。[サーチに追加 ] をコマンドクリックし、新しい
タブでサーチを開きます。
前回の実⾏結果 ：サーチを最後に実⾏した⽇時が表⽰されます。
次の⽅法で、サーチ履歴を操作できます。
キーワードを使⽤するフィルタリング ：フィルター バーを使⽤し、過去のサーチしたテキストに対して
キーワードサーチを実⾏できます。
時間によるフィルタリング ：サーチが書き込まれ、最後に実⾏された時間によって作成された時間フィル
タのリストから選択します。時間フィルタなし でサーチ履歴を表⽰するか、事前に定義した時間フィルタ
(今⽇ 、 過去 7 ⽇間 、 過去 30 ⽇間 ) のリストから選択することができます。
テーブルコンテンツのソート ：サーチ または前回の実⾏結果 の列⾒出しをクリックし、テーブルの結果を
ソートします。
関連項⽬
Splunk Web 内の移動⽅法
サーチの最適化
最適化のクイックヒント
⾼速なサーチの鍵については以下を参照してください。
1. ディスクから取得するデータ量を最低限に抑えてください。
2. サーチではできる限りデータをフィルタリングしてください。そうすることにより、必要最低限のデータのみを
処理できます。
ディスクから取得するデータ量の制限
ディスクから所得するデータを制限する最も効果的な⽅法の 1 つは、時間範囲を最低限必要なデータのみに制限
することです。
たとえば、 過去 1 週間 (-1w) ではなく過去 1 時間 (-1hr)、 または earliest= 過去1⽇ (-1d)
特定の時間範囲については、マニュアルの「時間範囲について」を参照してください。
ディスクから所得するデータを制限するもう 1 つの⽅法は、データを異なるインデックスで分割することです。
⼀度に複数のタイプのデータにまたがるサーチを⾏うことがほとんどない場合は、各データタイプを異なるイン
デックスで分割します。それから、サーチを特定のインデックスに限定します。たとえば、あるインデックスには
19
Web アクセスデータを、別のインデックスにはファイアウォールデータを保管します。これは、⼤量の無関係な
データの中に埋もれがちな、スパースデータに対しておすすめの⽅法です。
『インデクサーとクラスタの管理』 マニュアルの「複数のインデックスの設定⽅法」と、このマニュアルの「異
なるインデクサーのサーチ」を参照してください。返されるイベントデータを減らすことによってサーチの速度を
増加させるために⾼速モードを使います。
できるだけ特定してサーチします。たとえば、*error* ではなく fatal_error
計算の前にできる限り早く結果をフィルタリングします。フィールドと値のペアを
最初のパイプの前に使います。たとえば、ERROR | search status=404... の代わりに ERROR status=404 ... ま
たは where などのフィルタリングコマンドを使います。
サーチの不必要なフィールドをできる限り早くフィルタリングします。
⼀連の結果 (⾮ストリーミングコマンド) 全体を実⾏するコマンドを
できる限りあとに延ばします。 dedup、sort、stats はこれらのコマンドの⼀部です。
ダッシュボード内でのサーチの後処理機能を使⽤します。
サマリーインデックス化、レポート⾼速化、データモデル⾼速化の機能を使⽤します。
より良いサーチの作成
このトピックでは、サーチが遅くなる原因、および効率的なサーチを作成するために役⽴つ簡単なルールを説明し
ていきます。サーチ速度には多くの要因が影響します。サーチ対象のデータ量、サーチの内容、同時にサーチを実
⾏するユーザー数に対応できるデプロイ環境かどうかなど、さまざまな要因が考えられます。サーチ速度を最適化
するために⼤切なのは、Splunk Enterprise が必要な処理以外を⾏わないようにすることです。
サーチのタイプを知る
サーチ最適化の推奨事項は、実⾏するサーチの種類およびサーチ対象データの特徴によって異なります。⼀般的に
は、イベントの取得やレポートの⽣成など、何をするかに基づきます。データセット内で⽬的のイベントが頻繁に
発⽣しているような場合、それを「デンスサーチ」と呼んでいます。データセット内で⽬的のイベントが滅多に存
在しない場合、それを「スパースサーチ」と呼んでいます。
詳細は、「サーチタイプについて」を参照してください。
raw イベントサーチ
raw イベントサーチは、取得したイベントを処理することなく、Splunk インデックスからそのままイベントを返
します。基本的にインデックスからイベントを取得する際には、⽬的のイベントのみを取得するように適切な指定
を⾏うことが⼤切です。そのためには、イベント固有のキーワードおよびフィールド/値のペアを使⽤します。⼤
量のデータにスパースサーチを実⾏する場合、同じデータセットにデンスサーチを⾏う場合と⽐べて時間がかかる
ことに注意してください。
レポート⽣成サーチ
レポート⽣成サーチは、インデックスから取得したイベントに対して、さらなる処理を⾏います。結果セットに対
して 1 つまたは複数の統計関数を利⽤した、フィルタリング、変換、およびその他の操作を⾏うことができま
す。この処理はメモリー内で⾏われるため、ディスクから取得するイベント数を限定するほど、サーチが⾼速に⾏
われます。
サーチチューニングのヒント
たいていの場合、サーチが遅い原因は、インデックスからイベントを取得するためのクエリの複雑性が原因です。
たとえば、サーチに極端に⼤きな OR リスト、複雑なサブサーチ (OR リストを分割する)、およびある種のフレー
ズサーチが含まれている場合、その処理には時間がかかります。このセクションは、サーチを効率的に実⾏するた
めにチューニングを⾏うための、いくつかのヒントを記載しています。
できる限り詳細な指定を⾏ってください。
最初からできる限りサーチを絞り込んで、ディスクから取得するデータ量を最低限に抑えるようにしてください。
サーチを特定の時間ウィンドウに限定します。 たとえば、数分前に発⽣したエラーの原因を調査する場合
は、過去 1 週間 (-1w) ではなく過去 15 分 (-15min) または過去 1 時間 (-1hr) のデータをサーチします。
「サーチの時間範囲について」を参照してください。
必要なイベントにのみ存在している⽂字列を追加してください。
可能な限り、特定のホスト、インデックス、ソース、ソースタイプ、または Splunk サーバーにサー
チを制限してください。 サーチ内でのフィールドの使⽤の詳細は、次のセクションを参照してください。
取得するデータ量を制限します。 次の head コマンドを使えば、簡単にこれを実現できます：
sourcetype=access_* | head 1000
可能な限り NOT 式の使⽤は避けてください。
20
(NOT host=d NOT host=e)
または
(host!=d OR host!=e)
を使⽤する代わりに、
(host=a OR host=b OR host=c)
を使⽤しま
す。
NOT or != expression を使⽤する必要がある場合は、これらの表現の使⽤の重要な違いを理解するようにしてく
ださい。詳細は、このマニュアルの「Difference between NOT と != の違い」を参照してください。
サーチの特定のインデックスへの限定
⼀度に複数のタイプのデータにまたがるサーチを⾏うことがほとんどない場合は、各データタイプを異なるイン
デックスで分割します。それから、サーチを特定のインデックスに限定します。たとえば、あるインデックスには
Web アクセスデータを、別のインデックスにはファイアウォールデータを保管します。これは、⼤量の無関係な
データの中に埋もれがちな、スパースデータに対しておすすめの⽅法です。複数のインデックスの設定⽅法、およ
び異なるインデックスのサーチ⽅法を参照してください。
フィールドルックアップの効果的な使⽤
サーチ時に抽出されるフィールドではなく、すでに抽出されているフィールド (インデックスが作成されたフィー
ルド) を使⽤すると、フィールドによるサーチを⾼速化できます。インデックス作成されたフィールドとデフォル
トのフィールドについては、『ナレッジ管理』マニュアルの「フィールドについて」を参照してください。
インデックスが作成されたデフォルトのフィールドの使⽤
データを効率的にサーチまたはフィルタリングするために、できる限りインデックスが作成されたデフォルトの
フィールドを使⽤してください。インデックス時に、Splunk は各イベントに共通の⼀連のデフォルトフィールド
を抽出します。これらのフィールドには host、source、および sourcetype が含まれます。サーチではできる限りこ
れらのフィールドを使ってデータをフィルタリングしてください。そうすることにより、必要最低限のデータのみ
を処理できます。
たとえば、Web アクセスエラーに関するレポートを作成する場合、レポートコマンドを実⾏する前に特定のエ
ラーのみをサーチします。
sourcetype=access_* (status=4* OR status=5*) | stats count by status
<field>::<value> によるインデックスが作成されたフィールドの指定
CSV ファイルや JSON データソースなどの構造化データからインデックスが作成されたフィールドの、効率的な
サーチを実⾏できます。その場合、次のように等号をダブルコロンに置き換えます： <field>::<value>。
この構⽂はデフォルトのカスタム インデックス フィールドのサーチにも使⽤されますが、構造化データからイン
デックスが作成されたフィールドのサーチで最も機能します。[サーチ時間 ]フィールドでのサーチには使⽤できま
せん。
サーチのパフォーマンスを向上させるために、フィールド検出を無効にする
サーチで追加のフィールドが不要な場合は、サーチモード の設定でフィールド検出を無効にして、タイムライン
ビューでのパフォーマンスを向上させるか、または fields コマンドを使って結果に必要なフィールドのみを指定
してください。
ただし、フィールド検出を無効にすると、サーチを実現するために必要なフィールド (サーチ対象の特定のフィー
ルドなど)、および _time、host、 source、 sourcetype などのデフォルトフィールド 以外のフィールドの⾃動抽
出 は⾏われません。対象となる可能性がある各フィールドをイベントから抽出する⼿間がなくなるため、サーチの
実⾏は⾼速化されます。
デフォルトで [サーチモード ] は、[ スマート] に設定されています。レポートコマンドを使⽤するサーチ、データ
に存在しているフィールドが分からないサーチ、サーチを絞り込むために追加フィールドが必要な場合などは、こ
れを [ 詳細] に設定してください。
本マニュアルの「サーチに合わせたサーチモードの設定」を参照してください。
『サーチリファレンス』の「フィールドコマンド」に関するトピックを参照してください。
データの要約
⼤量のデータセットに対してサーチを⾏う場合、⾮常に時間がかかることがあります。⼤量のデータに対して定期
的にレポートを⽣成する場合は、サマリーインデックス化を使って、レポートでもっとも頻繁に使⽤する値
を事前に算出してください 。保存済みサーチをスケジュールして定期的に指標を収集し、raw データの代わりに
21
要約したデータをレポートします。
レポート効率を向上するためのサマリーインデックス化の使⽤⽅法に関する記事を参照してください。
サーチジョブ調査の使⽤
サーチジョブ調査 は、サーチパフォーマンスのトラブルシューティングと最も時間のかかるサーチフェーズの特
定に使⽤できるツールです。このツールはサーチの動作を解析し、イベントタイプ、タグ、ルックアップ、サーチ
コマンドおよびサーチ内のその他のコンポーネントなど、ナレッジオブジェクトの実⾏コストの把握に役⽴ちま
す。
詳細は、このマニュアルの「サーチジョブ調査の使⽤⽅法」を参照してください。
イベントの取得
イベントの取得について
Splunk でサーチを実⾏する場合、サーチコマンドを使ってサーチ単語に⼀致するイベントデータを検索します。
これらのサーチ単語は、インデックスから取得するイベントを⽰す、キーワード、フレーズ、論理演算式、フィー
ルド名/値のペアなどです。サーチコマンドの効果的な使⽤法の詳細については、『サーチ』マニュアルの「サー
チコマンド⼊⾨」を参照してください。
イベントデータが異なるインデックスや複数の分散サーチピア間にパーティション分割されている場合もありま
す。複数のインデックスやサーバーにまたがるサーチについては、「インデックスおよび分散サーチピアからのイ
ベントの取得」を参照してください。
イベントはインデックスから、時間の逆順に取得されます。Splunk のサーチ結果はデフォルトで 、最新のデータ
からもっとも古いデータへと並んでいます。時刻でフィルタリングを⾏うと、タイムラインを使ってイベントの集
合にズームインする場合でも、サーチ⾃体に時間範囲を適⽤する場合でも、イベントの取得が⾼速化されます。詳
細は、「タイムラインを使ったイベントの調査」および「サーチにおける時間範囲について」を参照してくださ
い。
イベント、イベントデータ、およびフィールド
⼀般的に「イベントデータ」とは、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 は⾃動的にいくつかのフィールド (イベントのホストやデータソースの種類など) を抽出します。
サーチコマンド⼊⾨
サーチパイプラインを明⽰的に起動していなくても、その先頭には
host=webserver*
search
コマンドが暗⽰されています。
host=webserver*
search host=webserver*
search host=webserver*
キーワード、フレーズ、フィールド、論理演算式、⽐較式を使って、Splunk インデックスから取得するイベント
を厳密に指定することができます。デフォルトでは、キーワードとフレーズを使ってサーチを実⾏する場合、デー
タ内の _raw イベントフィールドに対して照合が⾏われて、⼀致するイベントが取得されます。_time や tag などの
フィールドをサーチ修飾⼦として追加していくと、_raw フィールドから抽出された情報に対して、それらの照合が
⾏われます。
キーワード、フレーズ、ワイルドカード
キーワードや引⽤符で囲まれたフレーズ (またはサーチ修飾⼦以外の任意の語句) を含む⽂字列をサーチする場
合、Splunk は _raw フィールドと照合して、⼀致するイベントや結果を探します。キーワードとフレーズの例を以
下に⽰します。
web
error
web error
"web error"
22
引⽤符で囲まれたフレーズ "web error" は、その前のサーチとは異なることに注意してください。web error を
サーチした場合、「web」と「error」の両⽅を含むイベントが返されます。"web error" でサーチした場合は、
フレーズ「web error」を含むイベントのみが返されます。
アスタリスクのワイルドカード (*) を使⽤して、⽂字列内の任意の数の⽂字と⼀致させます。* でサーチを実⾏す
ると、それは「すべてにマッチ」を意味しており、上限値に⾄るまですべてのイベントが返されます。⽂字列の⼀
部として * でサーチを実⾏すると、その⽂字列に基づいて照合が⾏われます。例：
は、myhost1、myhost.ny.mydomain.com、myeventtype などに⼀致します。
は、myhost、yourhost などに⼀致します。
*host* は、host1、myhost3、yourhost27.yourdomain.com などに⼀致します。
my*
*host
⽬的のイベントに特有のサーチ単語を指定すれば、より良好な結果を得ることができます。たとえば、
「denied」(拒否) でサーチを実⾏するよりも、「access denied」(アクセス拒否) の⽅が良い結果を得られます。
イベントの 90% に「error」と⾔う単語が存在しているけれども、「sshd」は 5% にしか存在していない場合 (そ
して⽬的のイベントに両⽅の単語が必要な場合)、サーチに「sshd」を⼊れるとより効率的に検索を⾏うことがで
きます。
論理演算式
Splunk は、 AND、 OR、および NOT、 の論理演算⼦をサポートしています。論理演算⼦は⼤⽂字でなければなり
ません 。単語の間には、常に AND 演算⼦が存在することが前提です。 つまり、 web error と web AND error は同
じす。
Splunk は論理演算式を次の順序で評価します。
1. 括弧内の式。
2. OR 句。
3. AND または
NOT
句。
括弧がないと、
A=1 AND B=2 OR C=3
は次のように処理されます。
A=1 AND ( B=2 OR C=3 )
括弧を使って論理演算式をグループ化することができます。
web client error NOT (403 OR 404)
(A=1 AND B=2 ) OR C=3
web client error NOT (403 OR 404)
注意： ⼀般的に包含条件の⽅が除外条件よりも良好な結果を得られます。"access denied" (アクセス拒否) の⽅が
NOT "access granted" (「アクセス許可」の否定) よりも素早く結果を得られます。
フィールド式
データの追加時に、Splunk は情報のペアを抽出して、それをフィールドとして保存します。⼀部のフィールドは
すべてのイベントに共通ですが、そうではないフィールドも存在しています。サーチ単語にフィールドを追加する
と、特定のイベントをより正確に探し出せます。
特定の HTTP ステータスエラーに関する Web アクセスログをサーチする場合、「web error 404」でサーチする
代わりに、以下のようにフィールドを使ってサーチを⾏うことができます。
status=404
詳細は、「フィールドを使ったイベントの取得」を参照してください。
⽐較演算⼦を使ったフィールド値の照合
⽐較演算⼦を使って、特定の値または⼀連のフィールド値を照合できます。
演算⼦
例
結果
=
field=foo
!=
field!=foo 「foo」と完全⼀致しない複数値フィールドの値。
「foo」と完全⼀致する複数値フィールドの値。
<
field<x
値が x 未満の数値フィールド値。
>
field>x
値が x を超える数値フィールド値。
<=
field<=x
値が x 以下の数値フィールド値。
>=
field>=x
値が x 以上の数値フィールド値。
23
たとえば、delay フィールドの値が 10 を超えるイベントを検索するには、以下のように指定します。
delay > 10
NO T と ! = の 違 い
サーチから結果を除外する場合は、 NOT operator または != field expression を使⽤することができます。ただ
し、これらの2つの⽅法で返した結果には⼤きな違いがあります。
以下のフィールドが存在する場合を考えてみましょう。
fieldA
fieldB
fieldC
これらのフィールドにはそれぞれ3つの値が存在し、たとえば、 fieldA には value1, value2, value3 が存在しま
す。
fieldB!=value3
でサーチを実⾏した場合、サーチは次の value3 ではない fieldB でのイベントの値のみを返しま
す。
fieldB=value1、 fieldB=value2
fieldB が存在しない場合は、何も返しません。
NOT fieldB=value3
でサーチを実⾏した場合、サーチは次の fieldB=value3 以外のすべての値を返します 。
fieldA=value1、 fieldA=value2、 fieldA=value3
fieldB=value1、 fieldB=value2
fieldC=value1、 fieldC=value2、 fieldC=3
fieldB が存在しない場合は、 次の
NOT fieldB=value3
を返します。
fieldA=value1、 fieldA=value2、 fieldA=value3
fieldC=value1、 fieldC=value2、 fieldC=3
C A SE( ) と T ER M ( ) を 使 っ た フ レ ー ズ の 照 合
Splunk インデックス内の特定の⽤語またはフレーズをサーチする場合、CASE() または TERM() ディレクティブ
を使って⽤語全体との完全⼀致を検索します。
CASE は、⼤⽂字⼩⽂字が⼀致する⽤語やフィールド値のサーチを実⾏します。
TERM は、⼀般的に副区切り⽂字として認識される⽂字 (ピリオドやアンダースコアなど) が含まれている場
合でも、括弧内のすべての⽂字を単⼀の単語とみなして照合を⾏います。
副区切り⽂字を含む単語をサーチする場合、Splunk はデフォルトでその単語をフレーズとして扱います。サブ⽂
字列 (副区切り⽂字間の⽂字列) を論理積で連結した⽂字列に対してサーチが実⾏され、その後結果が後処理で
フィルタリングされます。たとえば、IP アドレス 127.0.0.1 をサーチする場合、Splunk では次のようにサーチさ
れます：127 AND 0 AND 1
⽂字列全体がさほど⼀般的ではない場合でも、これらのサブ⽂字列の論理積が頻繁に登場する場合、このような
サーチは効率的ではありません。
そこで TERM(127.0.0.1) と指定してサーチを実⾏すると、この IP アドレスが単⼀の単語として取り扱われて、
raw データとの照合が⾏われます。
TERM は、⽂字列に副区切り⽂字が含まれており、それがスペースやカンマなどの主区切り⽂字で区切られてい
るような場合に特に役⽴ちます。実際に TERM は、主区切り⽂字で区切られている⽂字列には機能しません。以
下に例を⽰します。
Splunk がイベントを サーチ可セグメントに分割する⽅法の詳細は、『データの取り込み』マニュアルの「セグメ
ント分割について」を参照してください。
例
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
24
TERM(user admin) を実⾏しても、結果は返されません。スペースは主区切り⽂字のため、Splunk はフレーズ
「user admin」を単⼀の単語としてインデックス作成することはありません。
SP L お よ び 正 規 表 現
Splunk Enterprise の正規表現は、Perl 互換の正規表現 (PCRE) です。
および regex コマンドを使って正規表現を使⽤することができます。match および
使って正規表現を使⽤することもできます。
rex
replace
などの評価関数を
Splunk Enterprise の正規表現の使⽤について、次のことを知っておく必要があります。
パイプ⽂字
パイプ⽂字 ( | ) は、 OR 条件を指定する正規表現で使⽤されます。たとえば、 A または B は A | B で表現されま
す。
パイプ⽂字は、SPLのコマンドの分割に使⽤されるため、引⽤符で使⽤するパイプ⽂字の正規表現を囲む必要があ
ります。例：
...|regex "expression | with pipe"
これは、テキスト「表現」または「パイプを使う」でのサーチとして、SPL により解釈されます。
バックスラッシュ⽂字
バックスラッシュ⽂字 (\) は、特殊⽂字をエスケープ処理させる正規表現で使われます。例：ピリオド⽂字は、区
切り⽂字の線を除いた全ての⽂字に⼀致させる正規表現で使われます。ピリオド⽂字に⼀致させる場合は、正規表
現で \. を指定し、ピリオド⽂字をエスケープ処理する必要があります。
Splunk Enterprise は、アスタリスクのワイルドカード ( * ) を使⽤します。バックスラッシュは、サーチ⽂字列
でのアスタリスクのエスケープ処理に使⽤することができません。
c:\\tempのようなファイルパスなどのダブルバックスラッシュを持つダブルバックスラッシュを含む正規表現を含
むサーチは、最初のバックスラッシュを⽂字をエスケープ処理する正規表現として解釈します。ファイルパスは、
c:\temp として解釈され、バックスラッシュの 1 つは削除されます。
ファイルパスのルート部分の 4 つ の連続したバックスラッシュを指定し、ファイルパスでの両⽅のバックスラッ
シュ⽂字をエスケープ処理する必要があります。例： c:\\\\temp。c:\\temp\example などのより⻑いファイルパスで
は、サーチ⽂字列の正規表現で c:\\\\temp\\example を指定します。
正規表現の詳細
詳細は、『ナレッジ管理』マニュアルの「Splunk Enterprise の正規表現について」を参照してください。
フィールドを使ったイベントの取得
フィールドは、イベントデータ 内のサーチ可能な名前と値のペアです。すべてのフィールドには名前があり、そ
れらの名前でサーチできます。フィールド式によるサーチは、キーワードと引⽤符で囲んだフレーズのみを使った
サーチよりも正確 (そして効率的) です。
以下のサーチを例に考えてみましょう。
host=webserver
このサーチ host=webserver では、値が webserver の host フィールドを持つイベントをサーチすることを⽰していま
す。このサーチを実⾏すると、 host フィールドの値が異なるイベントは取得されません。また、値が webserver の
他のフィールドを持つイベントも取得されません。つまり、このサーチはサーチバーに単に webserver を指定した
場合よりも、より絞り込まれたサーチ結果が返されることを意味しています。
詳細は、『ナレッジ管理』マニュアルの「フィールドについて」を参照してください。
インデックス時およびサーチ時フィールド
Splunk Enterprise によるイベントデータの処理時には、フィールドが抽出されて、定義されます。フィールドの
抽出はまずインデックス時に⾏われ、サーチ時に再び⾏われます。
詳細は、『インデクサーとクラスタの管理』マニュアルの「インデックス時とサーチ時」を参照してください。
インデックス時のフィールド抽出
インデックス時 に、Splunk Enterprise はフィールドの⼩さなセットを抽出します。このフィールドセットに
は、デフォルトのフィールド 、カスタムでインデックスされたフィールド、構造化データからインデックスされ
たフィールドが含まれます。
デフォルトのフィールドはすべてのイベントに存在します。3 つの重要なデフォルトのフィールドは、ホスト、
ソース、ソースタイプです。これらのフィールドにはイベントが発⽣した場所が記述されます。他のデフォルト
フィールドとしては、イベントのタイムスタンプに追加のサーチ詳細を与える datetime フィールドも含まれま
す。Splunk Enterprise はデフォルトのフィールドを⾃動的に内部フィールドとして分類します。
25
カスタムのインデックスされたフィールドは、インデックス時に抽出を⾏うために⼿動で設定されたフィールドで
す。『データの取り込み』マニュアルの「インデックス時のカスタムフィールドの作成」を参照してください。
構造化データのインデックス作成時には、⾒つかるフィールドのインデックス時に存在するフィールドの抽出を作
成します。下記は構造化データの例です。
カンマで区切られた値のファイル (CSV)
タブで区切られた値のファイル (TSV)
パイプで区切られた値のファイル (PSV)
JavaScript Object Notation (JSON) データソース
デフォルトのフィールド値およびカスタムでインデックスされたフィールド値のサーチでは、標準の
<field>=<value> 構⽂を使⽤できます。この構⽂はデフォルトのフィールド、カスタムでインデックスされたフィー
ルド、サーチ時フィールドに⼀致します。
ただし、インデックス時に構造化データから抽出されたフィールドだけをサーチする場合は、次のように等号をダ
ブルコロンと置き換えるとサーチの効率性が上がります。
<field>::<value>
この構⽂は、構造化データからインデックスされたフィールドのサーチで最も機能します。ただし、この構⽂はデ
フォルトのフィールドやカスタムでインデックスされたフィールドにも使⽤できます。[サーチ時間 ]フィールドで
のサーチには使⽤できません。
構造化データのファイルからフィールドを抽出する作業の詳細は、『データの取り込み』マニュアルの「ヘッダー
のあるファイルからのデータの抽出」を参照してください。
サーチ時のフィールド抽出
サーチ時 には、サーチモード の設定および実⾏中のサーチのタイプに対してフィールド検出が有効になっている
かどうかに応じて、Splunk Enterprise は追加のフィールドを抽出します。
サーチの例
例 1：ユーザー「strawsky」によるすべての「corp」サーバーへのアクセスイベントをサーチします。その中で
最新の 20 件のイベントのレポートを作成します。
host=corp* eventtype=access user=strawsky
この例 host では、デフォルトのフィールドですが、 eventtype と user は Splunk Enterprise が⾃動抽出した可能
性のある、または⾃分で定義した追加のフィールドになります。
⼀般的にイベントタイプは、イベントを分類することでサーチを容易にするための、ユーザーが定義するフィール
ドです。サーチをイベントタイプとして保存した後、 eventtype フィールドを使ってそれらのイベントを早く抽出
することができます。詳細は、『ナレッジ管理』マニュアルの「イベントタイプについて」を参照してください。
例 2：ソース「/var/www/log/php_error.log」からのイベントをサーチします。
source="/var/www/log/php_error.log"
イベントのソースは、イベントの起源となるファイル、ストリーム、または他の⼊⼒の名前です。
例 3：ソースタイプが Apache Web アクセスの、すべてのイベントをサーチします。
sourcetype="access_*"
イベントのソースタイプは、データの起源からのデータ⼊⼒の形式です。このサーチでは、ワイルドカードを使っ
て、「access_」で始まる Apache Web アクセスログを探します。これには、access_common や
access_combined などが含まれます (access_combined_wcookie などが返されることもあります)。
例 4 ：さまざまな CSV ファイルからインデックスされた情報をサーチして、プレイノを拠点とする従業員のリス
トを⼊⼿します。
employee_office::Plano
従業員の記録がまとめられている、インデックスされたいくつかの CSV ファイルがあります。それぞれの CSV
ファイルは同じフィールドを共有しています。テキサス州プレイノのオフィスと関連するこれらのファイルから従
業員をサーチしてみましょう。
この例では <field>::<value> の構⽂を使⽤して、インデックス時に抽出される CSV ファイルからフィールドを特
定し⾒つけます。この構⽂は、インデックスされた構造化データから抽出されるフィールドで最も機能するもの
の、これ以外のインデックス時のフィールドにも対応します。サーチ時に抽出されるフィールドは特定できませ
ん。
例 5： corp1 で 4 ⾏を超えるイベントのサーチを実⾏し、単語「400」を含むイベントを除外します。
host=corp1 linecount>4 NOT 400
フィールド/値のペアを照合する際に、⽐較式を使⽤できます。「=」および「!=」を使った⽐較式は、すべての
フィールド/値のペアに利⽤できます。< > <= >= を使った⽐較式は、数値を持つフィールドに対してのみ使⽤で
きます。この例は、4⾏を超えるイベント、 linecount>4 のサーチを表しています。
26
例 6： 論理演算⼦の「NOT」と⽐較演算⼦の「!=」は同じではありません。以下のサーチでは、
れていない (または NULL) の場合にイベントが返されます。
field
が定義さ
NOT field="value"
以下のサーチは、
field
が 存在し、値が「value」でない場合、イベントを返します。
field!="value"
値がワイルドカード「*」の場合、 NOT field=* ではフィールドが NULL または未定義のイベントが返されます。
⼀⽅、 field!=* では、イベントが返されることはありません。
フィールドの詳細
このトピックでは、いくつかのフィールドを使ったサーチのみを取り上げています。
次のトピック「インデックスおよび分散サーチピアからのイベントの取得」では、デフォルトのフィールド
index と splunk_server を使ったサーチ例を⾒ていきます。
その他のサーチ例については、『ナレッジ管理』マニュアルの「デフォルトフィールドの使⽤」を参照して
ください。
Splunk Enterprise サーチ⾔語を使ってデータを要約し、レポートに変換する作業を⾏う場合、フィールドの理解
がより重要になってきます。詳細は、「レポートコマンドについて」 を参照してください。
イベントサンプリング
デフォルトでは、 Splunk サーチはすべてのイベントを所得します。ただし状況によっては、⼀連のイベント全体
を所得する代わりに、⼀連のイベントのサンプルを所得する必要があるでしょう。イベントサンプリングを使⽤す
る必要があるかもしれないいくつかの理由があります。
正しいイベントが返されていることを確認するために、クイックサーチを実⾏する場合。
すべてのイベントを実⾏せずに、⼤量のデータセットの⽂字を特定する場合。
ほとんどのサーチでは、イベントのサンプリングは機能を衰えさせることなく、サーチパフォーマンスを⼤きく向
上させることができます。
イベントサンプリング⽐
サンプリング⽐は、⼀連のサンプル結果に含まれる全てのイベントの可能性です。⽐率の式は
です。
1/sample_ratio_value
たとえば、サンプル⽐の値が 100 の場合、各イベントは、 100 分の 1 の可能性で⼀連の結果に含まれます。それ
ぞれのイベントの選択は、他のすべてのイベントの選択とは無関係です。最初の100のイベントから多くのイベン
トが含まれる、または全く含まれない可能性があります。
サンプルが使われておらず、サーチが 1,000,000 のイベントに⼀致した場合、サンプル⽐、100の値の使⽤で、
およそ 10,000 のイベントを返す結果になります。
サンプルリングサーチを何度も実⾏する場合、返される結果の正確な数は、n=1000000 および p=0.01 との⼆項
分布によってモデル化されます。この分布は平均= 10000 および標準偏差（標準偏差）= 99.5 で、正規分布のよ
うに表⽰されます。
Splunk Web では、指定した⽐率の値が 1 より⼤きい正の整数でなければなりません。ui-prefs.conf ファイルで
サンプリング⽐を設定する場合、サンプル⽐はすべての正の整数を指定できます。⽐率を 1 に設定することは、
Splunk Webで「イベントサンプリング無し 」を設定することと同等です。
イベントサンプリングの処理⽅法
デフォルトでは、イベントサンプリングはアクティブではありません。サーチを実⾏する場合、基準に⼀致するす
べてのイベントが返されます。⽐率を指定した場合、サンプリングはアクティブなサーチウインドウで有効な状態
となります。また、サンプリングは、サーチをレポートまたはダッシュボードパネルとして保存した場合にも有効
な状態となります。
⽐率の値を指定する場合、その値は
まで有効な状態となります。
ui-prefs.conf
のデフォルト値に優先します。指定する値は、それを変更する
新規サーチウインドウを開いた場合、イベントサンプリングはもはやアクティブではありません。ただし、使⽤し
た最後のカスタム⽐は、サンプリング ドロップダウン表⽰されます。
イベントサンプリングを避けるコマンドおよび関数
⼀般的に、
ません。
transaction、 stats、
または
streamstats
コマンドを使⽤するサーチは良いサンプルには適切ではあり
⼀連のイベントのサンプルを使⽤して統計を算出する場合、統計値は不正確です。true の統計値を特定するに
は、イベントサンプリングで返された値をスケーリングする必要があります。また、スケーリングは true の近似
値のみを提供します。
たとえば、有効なイベントサンプリングでこのサーチを使⽤して、レポートを作成します。
27
... | stats sum(x)
イベントサンプリングを使⽤しているために、返された値はすべてのイベントの完全な合計ではありません。それ
は⼀連のイベントのサンプルのみの合計です。サンプリング⽐が 100 である場合、true の合計はおよそサーチが
返した値のおよそ 100 倍の値です。
この状況に該当する統計的算出は、
count、 sum、 sumsq
です。
イベントサンプリングが使⽤される場合に解釈が困難な他の統計には、以下のものが含まれます。
distinct_count
earliest
latest
max
min
サンプリング⽐の指定
サンプリング⽐を指定することで、サーチでのイベントサンプリングを実⾏します。
1. Splunk Web の サーチバーの下にある「イベントサンプリング無し 」をクリックします。
2. デフォルトのいずれかの⽐率を使⽤するか、またはカスタム⽐率を指定することができます。
a. デフォルトのいずれかの⽐率を使⽤するには、サンプリング ドロップダウンの⽐率をクリックします。
B. カスタム⽐率を指定するには、カスタム をクリックし、⽐率の値を⼊⼒します。[適⽤ ] をクリックしま
す。⽐率の値は、 1 より⼤きい正の整数である必要があります。
イベントサンプリングインジケーター
イベントサンプリングがアクティブであることを表⽰する [サーチとレポート] App ウインドウには、いくつかの
インジケーターがあります。サーチの実⾏後、 サンプリング ドロップダウンがイベントカウントラインに表⽰さ
れます。サンプリング ドロップダウンのラベルは、サーチに適⽤される⽐率を表しています。また、サンプリン
グ⽐率が使⽤されている場合、ジョブ ドロップダウンはサーチに適⽤される⽐率を表しています。
レポートとダッシュボードパネルを使ったイベントサンプリング
イベントサンプリングを使ったサーチを、レポートやダッシュボードパネルとして保存できます。[名前を付けて
保存 ] ドロップダウンを使ってサーチを保存します。
サーチがレポートとして保存される場合、レポートが実⾏される際にサンプリング⽐率が使⽤されます。
サーチがダッシュボードとして保存される場合、パネルはインラインサーチを使⽤します。サーチがレポートが更
新される場合、インラインサーチを使って保存されたサンプリング⽐率が使⽤されます。
レポートを開きレポートをダッシュボードパネルに追加する場合、パネルがどのように作成されているかを特定す
ることができます。パネルが、レポートの基になっているインラインサーチを使っていることを特定できます。ま
たは、パネルがレポート⾃体を使っていることを特定できます。
レポートを使ったパネル
シンプル XMLでパネルのソースが表⽰されている場合、レポートがイベントサンプリングを使っているか
どうかの表⽰はありません。
インラインサーチを使ったパネル
シンプル XMLでパネルのソースが表⽰されている場合、根本的なサーチがイベントサンプリングを使⽤し
ていれば、 <sampleRatio> エントリーが表⽰されます。例：
<event>
<title>sample events</title>
<search>
<query>buttercupgames</query>
<earliest>@d</earliest>
<latest>now</latest>
<sampleRatio>500</sampleRatio>
</search>
</event>
⾼速化されたレポート
イベントサンプリングサーチに基づいたレポートは⾼速化することができません。詳細は、『レポート』 マ
ニュアルの「レポートの⾼速化」を参照してください。
インデックスおよび分散サーチピアからのイベントの取得
新しいインデックスの作成、サーチピアの追加、データの保管場所の管理はいつでも⾏うことができます。また、
異なるインデックスや分散サーチピアにデータを分散させている場合、⼀度にサーチできるのは特定のインデック
スやサーバーには限定されません。複数のインデックスやサーバーを対象として同時にサーチを実⾏することがで
きます (それぞれ index および splunk_server フィールドを使⽤します)。
28
1 つまたは複数のサーチ対象インデックスの指定
Splunk 管理者は、ユーザーがサーチするデフォルトのインデックスを設定することができます。ユーザーのロー
ルや権限に基づいて、1 つまたは複数のインデックスにアクセスさせることができます。たとえば、メインイン
デックスのサーチのみを⾏えるようにすることも、公開されているすべてのインデックスのサーチを⾏えるように
することも可能です。ユーザーはサーチを⾏う際に、これらのインデックスのサブセットを指定します (個別のイ
ンデックスまたは複数のインデックスに対して)。ユーザーとロールの設定⽅法の詳細は、『Splunk Enterprise
のセキュリティ』の「ユーザーとロールについて」を参照してください。
インデックスの管理と複数インデックスの設定については、『インデクサーとクラスタの管理』マニュアルの「イ
ンデックスの管理について」を参照してください。
Splunk W eb を介したインデックスアクセスの制御
1. [ 管理 ] > [ アクセス制御 ] > [ ロール] に移動します。
2. ユーザーが割り当てられているロールを選択します。
次の画⾯の下部にはインデックスコントロールが表⽰されています。
3. 特定のロールが利⽤できるインデックスやデフォルトのサーチインデックスを設定します。
構⽂
フィールド名と値を指定する場合と同じ⽅法で、複数のサーチ対象インデックスを指定できます。この場合、
フィールド名は 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] フィールドの値として保存されます。分散サーチの詳細は、『分散サーチ』マニュ
アルの「分散サーチについて」を参照してください。
サーチピアを指定しない場合は、アクセス権があるすべてのサーチピアが利⽤されます。アクセスできるデフォル
トのピアは、⾃分のプロファイルに関連付けられているロールと権限によって決まります。この設定は、Splunk
管理者が⾏います。詳細は、『Splunk のセキュリティ』の「ユーザーとロールについて」を参照してください。
特定のピアにサーチを制限する機能は、あるサーチピアの遅延時間が⼤きく、デフォルトではそれを対象にサーチ
したくないような場合などに役⽴ちます。1 つまたは複数のサーチピアを指定すると、それらのサーバーのみが
サーチに含まれます。
その他のフィールド名と値を指定する場合と同じ⽅法で、複数のサーチピアを指定できます。この場合、フィール
ド名は「splunk_server」、フィールド値は特定の分散ピア名になります。
splunk_server=<peer_name>
29
注意 ：サーチ元の 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)
⽬的のイベントが⾒つかりませんか？
Splunk に⼊⼒を追加すると、その⼊⼒はその時点で利⽤している App に追加されます。⼀部の App は、⼊⼒
データを独⾃のインデックスに書き込みます (たとえば、Splunk App for Unix and Linux は、「os」インデック
スを使⽤します)。
Splunk に取り込んだはずのデータが⾒つからない場合は、適切なインデックスを使⽤しているかどうかを確認し
てください。使⽤しているロールに対して、デフォルトインデックスのリストに App 固有のインデックスを追加
しなければならないこともあります。ロールの詳細は、『Splunk のセキュリティ』のロールに関するトピックを
参照してください。
類似イベントの分類とグループ化
イベントはイベントタイプとは異なります。イベントは、データの単⼀のインスタンスです。たとえば、1 つのロ
グエントリがイベントになります。イベントタイプは、イベントにラベルを付けてグループ化するために⽤いられ
る分類⽅法です。
イベントに対応するイベントタイプ名は、 eventtype と呼ばれる複数値フィールドのイベントに設定されます。こ
れらのイベントグループ (例：SSH ログイン) は、任意のフィールド値と同じ⽅法でサーチできます。
ここでは、イベントの分類⽅法 (サーチをイベントタイプとして保存) およびタグ付きフィールドのサーチ⽅法に
ついて説明していきます。イベントの詳細、Splunk のイベントの認識⽅法、インデックス作成時のイベントの処
理⽅法などについては、『データの取り込み』マニュアルの「イベント処理の概要」を参照してください。
重要 ：サーチパイプラインをイベントタイプとして保存することはできません。つまり、サーチをイベントタイ
プとして保存する場合、それにサーチコマンドを⼊れることはできません。
サーチの新規イベントタイプとしての保存
基本的に、イベントデータをサーチする場合、不要なイベントをすべて除去することになります。サーチ結果は類
似の特徴を持つイベントの集合になり、それらに総称名を指定することができます。
たとえば、異なるホストマシン上の失敗したログインを頻繁にサーチする場合、それらのイベントに対応するイベ
ントタイプを保存して、 failed_login と⾔う名前を付けられます。
"failed login" OR "FAILED LOGIN" OR "Authentication failure" OR "Failed to authenticate user"
このサーチをイベントタイプとして保存するには：
1. [作成 ] をクリックして、[ イベントタイプ]を選択します。
2. [イベントタイプとして保存 ] で、サーチに名前 を指定します。このサーチ例では、「failed_login」と名付け
ます。
30
必要に応じて、[サーチ ] フィールドを変更することができます。このフィールドには、先ほど実⾏したサーチが
⾃動的に⼊⼒されています。
また、必要に応じて [タグ ] フィールドに、イベントタイプに適⽤するタグのリストを追加することもできます。
詳細は、後述のイベントタイプへのタグ設定に関する説明を参照してください。
3. [保存] をクリックするとイベントタイプ名が保存されます。
これで、任意のフィールドをサーチするのと同じ⽅法で、イベントタイプにマッチするすべてのイベントを⼿軽に
サーチできるようになります。
たとえば、特定のホストマシン上の失敗したログインを調査することができます。
host=target eventtype=failed_login
また、疑わしいユーザーのアクティビティを調査することもできます。
user=suspicious eventtype=failed_login
ty pelear ner を 使 っ た 新 規 イ ベ ン ト タ イ プ の 検 出
任意のサーチを typelearner コマンドに渡すと、Splunk が提案するイベントタイプを確認できます。デフォルト
で、 typelearner はサーチ結果となるイベントの句読点を⽐較し、類似の句読点や単語を持つイベントをグループ
化します。
イベントをグループ化するために、異なるフィールドを指定することができます。 typelearner は任意のフィール
ドと同じように機能します。結果は、このフィールドとフレーズを共通に保有する、 (サーチ結果からの) ⼀連の
イベントになります。
詳細と例については、『サーチコマンドリファレンス』の「typelearner」を参照してください。
タグを使った類似イベントのグループ化と検索
データ内で、関連するフィールド値でイベントをグループ化している場合があります。これらのフィールドのグ
ループを効率的にサーチするために、フィールド値にタグを割り当てることができます。抽出された任意のフィー
ルドに、1 つまたは複数のタグを割り当てられます (イベントタイプ、ホスト、ソース、またはソースタイプを含
む)。
イベントタイプには、それに関連する 1 つまたは複数のタグを割り当てられます。サーチをイベントタイプとし
て保存する際に、またはイベントタイプ管理 ([ 管理] > [ イベントタイプ] )から、これらのタグを追加できます。
このウィンドウのイベントタイプリストから、編集するイベントタイプを選択します。
イベントタイプにタグを追加したら、任意のタグのサーチと同じ⽅法でサーチを実施することができます。ファイ
アウォールイベントのサーチをイベントタイプ firewall_allowed として保存し、ログインイベントのサーチをイベ
ントタイプ login_successful として保存した場合を考えてみましょう。これらのイベントタイプにタグ「allow」
を設定しておけば、サーチを使って両⽅のイベントタイプのイベントを取得できます。
tag::eventtype="allow"
フィールド/値のペアにタグを設定することができます。また、フィールド名のエイリアスを設定することもでき
ます。タグの使⽤⽅法の詳細は、『ナレッジ管理』マニュアルの「Splunk Web でのフィールド値のタグとエイ
リアス設定」を参照してください。
タグ設定した値のサーチ
タグのサーチには 2 種類の⽅法があります。任意のフィールドの値に関連するタグをサーチする場合は、以下の
構⽂を使⽤できます。
31
tag=<tagname>
特定のフィールドの値に関連するタグをサーチする場合は、以下の構⽂を使⽤できます。
tag::<field>=<tagname>
ワイルドカードを使⽤したタグのサーチ
イベントタイプやタグを含め、キーワードやフィールド値をサーチする場合、ワイルドカード⽂字のアスタリスク
(*) を使⽤することができます。
たとえば、各種 IP アドレスに対して複数のイベントタイプタグがある場合 (IP-srcや
指定してそれらのすべてをサーチすることができます。
IP-dst
など)、以下のように
tag::eventtype=IP-*
タグに「local」を含むすべてのホストを探す場合は、以下のようにタグをサーチします。
tag::host=*local*
タグのないイベントタイプを持つイベントをサーチする場合は、論理演算式を使⽤します。
NOT tag::eventtype=*
タイムラインを使ったイベントの調査
タイムラインは、各時点で発⽣したイベント数を視覚的に表したものです。これは、時間の経過に伴うイベントの
分布を表しています。バー上にカーソルを移動すると、そのイベント数が表⽰されます。バーをクリックすると、
その時間範囲にドリルダウンできます。この⽅法でドリルダウンしても新たなサーチは実⾏されません。単に前の
サーチから結果をフィルタリングするだけです。タイムラインを使ってイベントのパターンまたはクラスタを強調
表⽰したり、イベントアクティビティのピーク (アクティビティのスパイク) を調査したりすることができます。
タイムラインフォーマットの変更
タイムラインは、[イベント] タブのイベントリストにあります。これは、サーチが実⾏された時間範囲のイベント
数を表しています。ここでタイムラインは、「先週の営業⽇ 」の Web アクセスイベント数の推移を表していま
す。
フォーマットオプションは、[タイムラインのフォーマット] メニューにあります。
タイムラインを⾮表⽰にする、または簡易 (コンパクト) ビューまたは完全ビューで表⽰することができます。ま
た、タイムラインのスケールを線形 (線形スケール) と対数 (対数スケール) とで切り替えることができます。
[フル ] を選択した場合、タイムラインはの表⽰が⼤きくなり、Y 軸にカウントを、X 軸に時間を表⽰します。
イベントを調査するためのズームイン/アウト
ズームおよび選択オプションは、タイムラインの上にあります。当初は、[ズームアウト ] オプションのみが利⽤
できます。
32
タイムラインの凡例は、タイムラインの右上にあります。これは、タイムラインのスケールを⽰しています。たと
えば、列あたり 1 分 の場合、各列がその分の間のイベント数を表しています。ズームイン/ズームアウトを⾏う
と、時間のスケールが変わります。たとえば、[ズームアウト ] をクリックすると、各列が 1 分ではなく 1 時間で
あることを⽰すように、凡例が変化します。
タイムライン上にマウスカーソルを移動してバーを選択すると、[選択項⽬にズーム ] または [選択解除 ] オプ
ションが利⽤できるようになります。
タイムラインの⼀番⾼いバーをクリックするか、またはバーの集合上にマウスをドラッグします。イベントリスト
が更新され、選択した時間範囲内に発⽣したイベントのみが表⽰されます。タイム レンジ ピッカーは、選択した
時間範囲も更新します。この選択をキャンセルするには、[選択解除 ] をクリックします。
[選択項⽬にズーム ] を選択した場合、選択した期間内の前のサーチの結果をフィルタリングすることになりま
す。タイムラインとイベントリストが更新され、新しいサーチの結果が表⽰されます。
選択した時間範囲内にズームインしたら、それを選択解除 することはできません。ただし、再びズームアウト す
ることは可能です。
33
イベント詳細へのドリルダウンサーチの実⾏
[イベント ] タブにイベントを返すサーチを実⾏したら、それらのイベントの⼀部をクリックすると、選択したイ
ベント詳細を使ったドリルダウンサーチを実⾏できます。
[イベント ] タブでは、以下のようなイベントの部分をクリックして、ドリルダウンサーチを実⾏することができ
ます。
セグメント (セグメントの接続⽂字列も可能)
フィールド値
タグ
タイムスタンプ
フィールド値、タグ、およびセグメントのドリルダウンサーチ
ドリルダウンサーチは、フィールド、タグ、およびイベントセグメントに対して以下のアクションを実⾏できま
す。
ドリ
ルダ
ウン
サー
チの
アク
ショ
ン
説明
結果
選択したイベント詳細のフォーカス範囲をオリジナルの
サーチ サーチに追加して実⾏します。Splunk プラットフォー
に追加 ムは、サーチ⽂字列、およびそれに続くすべてのもの
ら変換コマンド を破棄します。
選択されたフィールド、タグ、またはセグ
メントを持つイベントのみを含むように
フィルタリングされた、オリジナルのサー
チから返されたものと類似のデータ セッ
ト。
選択したイベント詳細の除外条件をオリジナルのサーチ
サーチ に追加して実⾏します。Splunk プラットフォームは、
から除
サーチ⽂字列、およびそれに続くすべてのものら変換コ
外
マンドを破棄します。
選択されたフィールド、タグ、またはセグ
メントを持たないイベントのみを含むよう
にフィルタリングされた、オリジナルの
サーチと類似のデータ セット。
強調表⽰されたフィールド値、タグ、またはセグメント
サーチ を検索しないことを除いて、オリジナルのサーチと同⼀
から削 の新しいサーチを実⾏します。Splunk プラットフォー
除
ムは、サーチ⽂字列、およびそれに続くすべてのものら
変換コマンドを破棄します。
オリジナルのサーチにより返されたデータ
セットのように限定されない新しいデータ
セット。もはや、強調表⽰されたフィール
ド値、タグ、またはセグメントのないイベ
ントは含まれていません。
新規
選択したフィールド、タグ、またはセグメントに集中し
サーチ た、新しいサーチを実⾏します。
フィールド、タグ、または選択されたセグ
メントを含む任意のイベントを持つデータ
セット。
。
これらのドリルダウンサーチはすべて、オリジナルのサーチと同じ時間範囲を使⽤します。
たとえば、以下のサーチを開始します。時間範囲は [過去 7 ⽇間 ]。
sourcetype=access_combined status=4*
この最初のサーチの結果から、イベントを開いて
clientip
フィールドの値
69.72.161.186
を選択します。
[サーチに追加 ] をクリックすると、過去 7 ⽇間の期間に対して以下のサーチが実⾏されます。
sourcetype=access_combined status=4* clientip="69.72.161.186"
[ サーチから除外] をクリックすると、過去 7 ⽇間の期間に対して以下のサーチが実⾏されます。
sourcetype=access_combined status=4* clientip!="69.72.161.186"
セカンダリサーチの実⾏後、[サーチから除外] をクリックすると、過去 7 ⽇間の期間に対して以下のサーチが実
⾏されます。
sourcetype=access_combined status=4*
[新規サーチ ] をクリックすると、過去 7 ⽇間の期間に対して以下のサーチが実⾏されます。
clientip="69.72.161.186"
フィールド値、タグ、またはセグメントに基づくドリルダウンサーチの実⾏
Splunk Enterprise は、インデックス時とサーチ時にフィールドを抽出 します。詳細は、『ナレッジ管理』マ
ニュアルの「フィールドについて」を参照してください。
セグメント は、イベントのサーチ可能な部分です。セグメントの設定や作成の仕組みについては、『データの取
り込み』マニュアルの「イベントセグメント分割について」を参照してください。
34
タグ は、フィールド/値のペアと関連付けられます。タグを、複数のフィールド/値のペアと関連付けることがで
きます。フィールド/値のペアを、複数のタグに関連付けることができます。詳細は、『ナレッジ管理』マニュア
ルの「タグとエイリアスについて」を参照してください。
1. [サーチとレポート] App で、[イベント ] タブにイベントリストを返すサーチまたはレポートを実⾏します。
サーチに変換コマンド が含まれている場合は、[サーチモード ] に [詳細 ] を設定します。
2. ドリルダウンサーチで実⾏するアイテムに必要であれば、イベント表⽰をリセットします。
ドリルダウンサーチをフィールド値で実⾏する場合、イベント表⽰は以下のようにに設置されています。
Raw 、 実際のフィールド値を選択するイベントを開きます。
List または Table 、選択したフィールドから値を選ぶ、または他のフィールド値を選択するイベントを開
くことができます。
イベントセグメントでドリルダウンを実⾏する場合は、イベント表⽰を List または Raw に設定します。
3. ドリルダウンリサーチで使⽤するフィールド値、タグ、またはセグメントを持つイベントを特定します。
選択したフィールドおよびそれらのタグのみが開いていないイベントに表⽰されます。開かれたイベントを
開いて、他のフィールドおよびタグを⾒つけます。
サーチ結果に⻩⾊の強調表⽰で表⽰されているサーチ⽂字列に明⽰的に含まれているフィールド値、タグ、
またはセグメント。以下の画⾯例では、オリジナルのサーチには sourcetype=access_* が含まれています。
4. フィールド値、タグ、セグメントをクリックします。
それらをクリックする前に、イベントセグメントおよび連結されたセグメントセットを選択します。選択し
たセグメントが⻩⾊で強調表⽰されます。
クリックすると、⼀連のドリルダウンサーチオプションが表⽰されます。[サーチに追加 ]、[サーチから除
外 ]、および [新規サーチ ] オプションが表⽰されます。これらのオプションの詳細は、このトピックの上部
にある表を参照してください。
フィールド値を選択し、値が⾒つかったフィールドのトップ 10 に該当する場合、[サーチに追加 ] および
[サーチから除外 ] オプションには返すことができるイベント数が表⽰されます。
5. ドリルダウンサーチのオプションをクリックします。
現在のタブでセカンダリサーチを実⾏し、現在のサーチと置換します。または、新しいタブでセカンダリ
サーチを実⾏し、現在のサーチ結果をそのまま保持します。現在のタブでサーチを実⾏するには、オプショ
ンのテキストをクリックします。新しいタブでサーチを開くには、オプションの [新しいタブで開く ] アイ
コン
をクリックします。
[サーチに追加 ] または [新規サーチ ] を実⾏すると、ドリルダウンサーチが返したイベント内で⼀致する
値、タグ、またはセグメントが⻩⾊で強調表⽰されます。ドリルダウンサーチに返されるイベントには⼀致
するフィールド値、タグ、またはセグメントが含まれないため、「サーチから除外 」を実⾏する場合には強
調表⽰されません。
6. (任意) ドリルダウンサーチの実⾏後、そのサーチが返したイベント内の、マークされたセグメントをクリックし
ます。
フィールド値、タグ、またはセグメントに対して 2 つのドリルダウンサーチオプション [サーチから削除 ]
および [新規サーチ ] が表⽰されます。これらのオプションの詳細は、このトピックの上部にある表を参照
してください。
35
7. (オプション) サーチを実⾏するためのオプションをクリックします。
現在のタブまたは新しいタブでサーチを実⾏できます (ステップ 5 を参照)。
注意 ： 現在のサーチ結果を置き換えたい場合は、ブラウザの [戻る] ボタンをクリックします。
イベントタイムスタンプに対するドリルダウンサーチ
イベントタイムスタンプのドリルダウンサーチはイベントの相関の検索や、主原因分析に役⽴ちます。
イベントのタイムスタンプ をクリックすると、そのイベントと時系列的に近い他のイベントを返すセカンダリ
サーチを実⾏できます。
イベントを開く場合、
す。
_time
フィールドをクリックして、こうしたドリルダウンサーチを実⾏することもできま
このサーチのコントロールは、_t im e アクセラレータ (タイムアクセラレータ) と呼ばれています。_time アクセ
ラレータの使⽤については、このマニュアルの「時間を使った近接イベントの検索」を参照してください。
[ パターン] タブによるイベントパターンの識別
サーチ結果のイベントは、イベントパターン にグループ化できます。あるイベントパターンに所属するイベント
は共通の特性を共有しており、特定のサーチ⽂字列を使って取得することができます。イベントパターン分析は、
サーチ結果となるデータセット内で共通な種類のイベントを素早く確認できるため、多彩なイベントを返すサーチ
に役⽴ちます。
[パターン] タブにより、イベントパターンの識別を簡単に⾏うことができます。[パターン] タブをクリックする
と、サーチで返された⼀連のイベントの中でもっとも⼀般的なパターンのリストが表⽰されます。各パターンは、
類似の構造を共有する⼀連のイベントを表しています。
パターンをクリックして、以下の作業を⾏うことができます。
パターンに合致する、結果内のイベント数概算を表⽰する。
このパターンのイベントを返したサーチを参照する。
パターンサーチをイベントタイプとして保存する (可能な場合)。イベントタイプとして保存できないイベン
トパターンもあります。
パターンに基づいてアラートを作成する。たとえば、特定のパターンの頻度が増加/減少した場合に⽣成され
るアラートを作成することができます。
イベントパターンの例
sourcetype=cisco_esa
のサーチを、当⽇までの⼀週間に対して⾏いました。その結果 55,518 件のイベントが返され
ました。
36
これらのイベントの⼤半は、脅威レベル (threat level) のお知らせと、データベース監視 (database watcher) の
更新の 2 つのパターンのいずれかに該当しています。
データセット内のすべてのパターンを表⽰するには、[パターン] タブを開いて、スライダーを [拡⼤ ]側にドラッ
グして、⼤きなイベントパターンを返すようにします。7 つのパターンが返されます。
脅威レベルのイベントパターンは、もっとも⼀般的なものです。記載されているパターンの⼀部は、このデータ
セット内では⽐較的まれで、[イベント] タブのリストでそれを発⾒するのは困難なこともあります。[パターン]
タブでは、そのようなイベントパターンの発⾒と、必要に応じてそれをイベントタイプとしての⼿軽に保存できま
す。
[パ タ ー ン ] タ ブ の 仕 組 み
[パターン] タブをクリックすると、Splunk Enterprise はその時点で受け取ったサーチ結果のサブセットに対し
37
て、セカンダリサーチを実⾏します。このサーチジョブは、それらの結果を解析し、結果内のもっとも⼀般的なイ
ベントパターンを確認します。次に、もっとも⼀般的なものから、まったく⼀般的ではないものまで、パターンを
降順に表⽰します。極端に⼩さなイベントのグループからなる外れパターンは、統計的に信頼できないため除外さ
れることがあります。
オリジナルのデータセットに多彩なイベントパターンが含まれている場合、セカンダリサーチの完了まで時間がか
かることがあります。たとえば、⼤半のパターンが⾮常に⼩さなイベントの集まりを表している、500 件を超え
るパターンを含むデータセットを返すサーチがあります。これらのパターンを識別するアルゴリズムは、⼩さなパ
ターンの詳細な処理をできる限り回避するように設計されていますが、それでもできる限り正確に識別しようとし
ます。
[パターン] タブでは、サーチモード を詳細 に設定した場合、変換サーチ のみ利⽤できます。[パターン] タブは、
任意のサーチモードでリアルタイムサーチ のパターンを⾒つけることができません。
イベントパターンのキーワード
[パターン] タブは、1 つまたは複数のキーワードの存在または不存在により、パターンを定義します。あるパター
ンのキーワードがオリジナルのサーチから追加または除外されたと判断した場合、そのパターンに適合するイベン
トが返されます。パターン内のキーワードは、パターンリストに緑⾊のテキストで表⽰されます。イベントリスト
内に、除外されたキーワードは表⽰されません。
先ほどのイベントパターンの例で、驚異レベルのイベントパターンにはキーワードとして「threat」があります。
この場合、パターンに該当するイベントを返すサーチは以下のようになります。
sourcetype=cisco_esa threat
このイベントパターンがキーワード「verified」の除外でも判別される場合、パターンに該当するイベントを返す
サーチは以下のようになります。
sourcetype=cisco_esa threat ( NOT verified )
パターンに関連しているすべてのキーワードを表⽰するには、パターンをクリックします。
[パ タ ー ン ] タ ブ の 使 ⽤
1. サーチビューで、5,000 件を超える結果を返すサーチを実⾏します。
5,000 件を超える結果を返すサーチでは、信頼できるパターンを⽣成できます。
2. [パターン] タブをクリックします。
サーチの完了まで待つ必要はありませんが、サーチが完了した結果を利⽤するとより正確なパターンリスト
が⽣成されます。
3. (オプション) パターンが多すぎるまたは少なすぎる場合、または⽬的のパターンが表⽰されない場合は、スライ
ダーを移動します。
スライダーを [拡⼤ ] ⽅向にドラッグすると、いくつかのパターンを⼀緒にまとめるセカンダリサーチジョブ
が実⾏されます。その結果、イベント数が多いイベントパターンが表⽰されます。また、イベントパターン
グループ内のイベントも多彩になります。
[縮⼩ ] ⽅向にスライダーをドラッグすると、結果の粒度が増加するセカンダリサーチジョブが実⾏されま
す。検出されるイベントパターンも、より少数のイベントを表すものになります。
4. (オプション) パターンをクリックして、そのパターンの情報を参照します。
[予想されるイベント ] は、オリジナルのサーチが返す、イベントパターンに適合するデータセット内の予
想イベント数です。この例では、オリジナルのサーチには 265,000 件のイベントがあります。このパターン
は、それらのイベントの中の 7,350 件 (2.7%) と予想されています。
[含めるキーワード ] には、パターンを返すベースサーチに追加する必要のあるキーワードを指定します。
[パターン] タブにベースサーチから除外するキーワードが指定されている場合、それは [除外するキーワー
ド ] セクションに表⽰されます。
38
イベントパターンに適合するイベントを返すサーチは、[サーチ ] で確認できます。
5. (任意) パターン情報エリアで、[イベントの表⽰ ] をクリックすると [サーチ ] に表⽰されているサーチが実⾏さ
れます。
実⾏時にこのサーチは、オリジナルのサーチと同じ時間範囲を使⽤します。
6. (任意) パターン情報領域で、[イベントタイプとして保存 ] をクリックして、サーチをイベントタイプ として
保存します。
[イベントタイプとして保存 ] は、パイプ⽂字や追加のサーチコマンドを含まないサーチに基づくイベント
パターンに対してのみ利⽤できます。このマニュアルの「イベントタイプについて」を参照してください。
7. (任意) パターン情報エリアで、[アラートの作成 ] をクリックして、パターンをベースにしたアラート を作成し
ます。
たとえば、イベントパターンの頻度が閾値を超えた、または下回った場合に⽣成される、スケジュール済み
アラートを作成します。イベントパターンに適合するイベントが、約 100 イベント/時間の割合で安定的に
登場する傾向があると分かっている場合に、時間ごとに実⾏して 150 件以上のイベントが返された場合に⽣
成されるアラートをスケジュールできます。『アラート』 マニュアルを参照してください。
[パ タ ー ン ] タ ブ の 数 値
セカンダリサーチが完了すると、表⽰結果を取得するために分析したイベント数を表すメッセージが、[パターン]
タブに表⽰されます。
[パターン] タブは、オリジナルのサーチが返した合計イベント数のサブセットを分析します。このサブセットの最
⼤イベント数は、50,000 件です。この最⼤値により、[パターン] タブでのセカンダリサーチの処理時間を減らす
ことができます。オリジナルのサーチが 50,000 件未満のイベントを返す場合、セカンダリサーチではオリジナル
のサーチが作成したタイムラインバーあたり最⾼ 1,000 件のイベントが分析されます。たとえば、オリジナルの
サーチが 14 のタイムラインバーを作成した場合、セカンダリサーチはパターンリストを取得するために 14,000
件のイベントを分析します。
セカンダリサーチが分析する最⼤イベント数を制御するには、 limits.conf の max_events 設定を編集します。この
設定のデフォルトは、 50000 です。この値は変更しないでください。50,000 未満の値を設定すると、イベントの
精度が低下します。50,000 より⼤きな値を設定すると、セカンダリサーチ完了までの処理時間が増加します。
パターン情報エリアに表⽰される予想イベント数は、[パターン] タブのセカンダリサーチの分析イベント数には適
⽤されません。オリジナルのサーチが返すイベント数合計に適⽤されます。イベントパターンの予想が 7,350 件
のイベントで、オリジナルのサーチが 265,000 件のイベントを返した場合、そのパターンはサーチが返すイベン
トの 2.7% を構成していることになります。
[パ タ ー ン ] タ ブ の 使 ⽤ の 制 限
デフォルトでは、user ロールも含めたすべてのロールに、[パターン] タブを使⽤する権限があります。[パター
ン] タブの使⽤を制限するには、 pattern_detect 権限 を削除します。この権限を持たないロールには、サーチ実⾏
後に [パターン] タブのオプションが表⽰されません。
権限の詳細は、『Splunk のセキュリティ』マニュアルの「権限を持つロールの定義について」を参照してくださ
い。
時間範囲の指定
時間を使ったサーチについて
時間は、問題を判断するために必要不可⽋な情報です。何が起きたのかが明確に分からなくても、発⽣した時期は
分かることがしばしばあります。同時刻に発⽣したイベントを調査することで、結果間の相互関係を⾒つけ出し、
主原因を特定する⼿がかりにできるかもしれません。
⻑期間を対象にサーチを実⾏することは、システムリソースの無駄にとどまらず、膨⼤な結果が⽣成され、処理し
きれなくなってしまいます。
このセクションでは、時間を使ったサーチの絞り込み⽅について説明していきます。
タイムレンジメニューからの時間範囲の選択
サーチへの時間修飾⼦の指定
リアルタイムサーチでの時間ウィンドウの指定
時間を使った近接イベントの検索
サーチに適⽤する時間範囲の選択
タイム レンジ ピッカー を使って、サーチの時間境界を設定することができます。あらかじめ設定されている時
間範囲、独⾃の相対時間範囲、および独⾃のリアルタイム時間範囲にサーチを限定することができます。また、
[⽇付範囲] または [⽇付と時間の範囲] を指定することもできます。これらのオプションは次のセクションに記述
されています。
注意 ：別のタイムゾーンで作業を⾏っている場合、時間ベースのサーチでは、データのインデックスを作成した
インスタンスの、イベントのタイムスタンプが⽤いられます。
事前設定された時間範囲のリストから選択
39
タイム レンジ ピッカーにはあらかじめ設定ファイル times.conf に定義されている、さまざまな時間範囲オプショ
ンが⽤意されています。リストに記載されているリアルタイムウィンドウ、相対時間範囲、および全時間に対する
サーチなどを選択することができます。
カスタム相対時間範囲の定義
カスタムの相対時間範囲オプションを使って、サーチに対して現在からの相対的な時間範囲を指定します。「秒
前」、「分前」などの時間範囲を表す単位をリストから選択できます。
選択内容に合わせて [ もっとも早い] および [ もっとも遅い] のラベルが更新されます。
時間範囲を設定すると、フィールド下のプレビューボックスが更新されます。
相対時間範囲の詳細は、次のトピック「サーチへの時間修飾⼦の指定」を参照してください。
カスタムリアルタイム範囲の定義
40
カスタムリアルタイムオプションにより、リアルタイムの時間範囲ウィンドウの開始時間を指定することができま
す。
リアルタイム範囲の詳細は、「サーチのリアルタイムタイムレンジウィンドウの指定」を参照してください。
カスタム⽇付範囲の定義
カスタム⽇付範囲オプションは、サーチに暦⽇を指定するために⽤いられます。[次の間 ] にイベントを返す範囲
の開始⽇と終了⽇を指定、[次の前 ] にその⽇より前のイベントを返す⽇付を指定、または [次から ] にその⽇から
のイベントを返す⽇付を指定することができます。
これらのフィールドに対して、ボックスに⽇付を⼊⼒するか、またはカレンダーから⽇付を選択することができま
す。
カスタム⽇付および時間範囲の定義
カスタム⽇付と時間の範囲オプションを使って、サーチの開始/終了⽇時を指定することができます。
41
ボックスに⽇付を⼊⼒するか、またはカレンダーから⽇付を選択することができます。
詳細時間範囲オプションの使⽤
詳細オプションを使って、サーチのもっとも早い時間ともっとも遅い時間を指定することができます。時間は
UNIX (エポック) 時で、または相対時間表記で指定できます。エポック時を指定した場合、それがローカル時間に
変換されます。このタイムスタンプは、テキストフィールド下に表⽰され、⼊⼒内容を確認することができます。
選択できる時間範囲のカスタマイズ
Splunk には、ビルトインの時間範囲が⽤意されています。Splunk 管理者は⼀連の時間範囲をカスタマイズし
て、それをサーチ時にドロップダウンメニューから選択させることができます。時間範囲の設定⽅法については、
『管理』マニュアルの「times.conf リファレンス」を参照してください。
デフォルト時間範囲の変更
タイム レンジ ピッカーを使って、デフォルトの [全時間] 以外の範囲をサーチしたい場合は、この値を別の時間範
囲に変更します。ユーザーの ui-prefs を設定して特定のユーザーを指定したり、App 全体を設定したりすること
ができます。そのためには、ui-prefs.conf を編集または作成して、新しいデフォルト時間範囲を定義します。
サーチ App 内で、デフォルトの時間範囲を [全時間 ] から [今⽇ ] に変更する例を以下に⽰します。
[search]
dispatch.earliest_time = @d
dispatch.latest_time = now
他のビューに対してこのデフォルトを変更する場合、スタンザ名をそのビューのダッシュボード ID と⼀致させる
必要があります。これらのパラメータ値は、相対時間修飾⼦を使って定義します。時間修飾⼦の詳細は、このマ
ニュアルの「サーチへの時間修飾⼦の指定」を参照してください。
サーチ App に限定して追加したい場合は、このスタンザを $SPLUNK_HOME/etc/apps/search/local/ui-prefs.conf ファ
イル内に作成します。グローバルなデフォルトを指定する場合は、これらのパラメータを
$SPLUNK_HOME/etc/system/local/ui-prefs.conf ファイルに追加します。詳細は、『管理』マニュアルの「uiprefs.conf」を参照してください。
管理者は、すべての App 間で、デフォルトの時間範囲をグローバルに設定することができます。詳細は、『管
理』マニュアルの「デフォルト値の変更」を参照してください。
サーチへの時間修飾⼦の指定
サーチを実⾏または保存する場合、以下の属性を使って絶対/相対時間範囲を指定することができます。
earliest=<time_modifier>
latest=<time_modifier>
42
絶対時間範囲は、たとえば、2015 年11 ⽉ 13 ⽇ 午前 12 時 から 2015 年 11 ⽉ 1 ⽇ 午前 12 時 のような特定の
⽇付/時間を使⽤します。
相対時間範囲は、いつサーチが実⾏されるかによります。たとえば、相対時間範囲 -60m は「60 分前」を意味し
ます。現在時刻が午後 3 時の場合、サーチは過去 60 分、または午後 2 時〜午後 3 時のイベントを返します。
現在時刻は頻繁に「現在」と表⽰されます。
相対時間範囲の指定
正確な時間範囲を指定する time_modifier の構⽂は、 %m/%d/%Y:%H:%M:%S です。たとえば、2015 年 10 ⽉ 19 ⽇午前
12 時〜2015 年 10 ⽉ 27 ⽇午前 12 時の時間範囲は、以下のように指定します。
earliest=10/19/2015:0:0:0 latest=10/27/2015:0:0:0
「earliest」属性のみを指定した場合、デフォルトで「latest」は現在の時刻 (now) になります。⼀般的に、
「earliest」を指定せずに「latest」を指定することはありません。
サーチバーまたは保存済みサーチで指定した時間範囲は、タイム レンジ ピッカーで選択した時間範囲に優先しま
す。
注意 ：サーチに直接指定した時間範囲は、サブサーチには適⽤されませんタイム レンジ ピッカーで選択した時間
範囲は適⽤されます。
相対時間範囲の指定
相対時間の場合、時間の量を⽰す⽂字列を使って相対時間を指定することができます。構⽂は整数と時間単位で
す。
1. ⽂字列は、時間量のオフセットを⽰すプラス (+) またはマイナス (-) 記号で開始します。
2. 数字と時間単位を使って字完了を指定します。単⼀の時間⼊⼒を指定する場合、数字は省略できます。つまり、
「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
3. スナップ (snap to) 時間単位を使⽤して、時間量を切り捨てた最寄りの時間またはもっとも遅い時間を指定する
ことができます。このためには、時間量とスナップ (snap to) 時間単位を、「@」⽂字で区切ります。
「スナップ (snap to)」時間単位の構⽂は、[+|-]<time_integer><time_unit>@<time_unit>です。また、相対時間を指定
する際には、現在の時刻を表す now を使⽤できます。
相対時間修飾⼦は、「スナップ」時間単位としてのみ 定義できます。たとえば、特定の曜⽇にスナップするに
は、⽇曜⽇の場合は @w0、⽉曜⽇の場合は @w1 などのように指定します。
スナップ時間単位を指定しない場合、Splunk は⾃動的に秒に スナップします。
特殊時間単位
これらの省略形は、時間単位の特殊な事例とスナップ時間オフセットのために予約されています。
時間単位
説明
UTC エポック時の開始からイベントをサーチする場合は、 earliest=1 を使⽤します。(サーチ⽂
字列内の earliest=0 は、サーチ内でその時間が使⽤されていないことを⽰しています。)
および
す。違いは：
earliest=1
earliest=1
latest=now
または
latest=<a large number>
43
の場合、サーチは全時間 実⾏されま
を指定した場合、将来のイベントは返されません (デフォルト)。
を指定すると、将来のイベント、つまり現在の時刻 now よりも後のタ
イムスタンプを持つイベントが返されます。
latest=now
latest=<a big number>
latest=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, 13:37:05 PM now
-60m
60 分前
Wednesday, 05 February 2009, 12:37:05 PM -60m@s
-1h@h
1 時間前、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
-24h@s
+24h@s
相対時間オフセットのチェーン例
より詳細な相対時間定義を⾏うために、スナップ時間からのオフセットを指定または時間修飾⼦と⼀緒に「チェー
ン」することができます。
時間修飾⼦
@d-2h
説明
今⽇の開始 (午前 0 時) にスナップし、そこから 2 時間差し引きま
す。
1 ヶ⽉前の⽉の初⽇の午前 0 時にスナップして、7 ⽇間を加算
mon@mon+7d
結果となる時間
昨晩の午後 10 時
先⽉の 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 時間分のデータに該当するイベントしか返されません。⼀⽅、この
サーチを⾦曜⽇に実⾏すれば、⽉曜⽇から⾦曜⽇の現在の時刻までのイベントが返されます。ただし、タイムライ
ンには週の営業⽇全体が表⽰されます。
44
例 3：先週の営業⽇からの Web アクセスエラー。
eventtype=webaccess error earliest=-7d@w1 latest=@w6
このサーチは、先週⽉曜⽇午前 0 時から、先週⾦曜⽇午後 11 時 59 分までの、マッチするイベントを返します。
サーチへのリアルタイム時間範囲ウィンドウの指定
履歴サーチの時間境界は、サーチ実⾏時の時間に設定されます。リアルタイムサーチでは、時間境界は常時更新さ
れ、デフォルトで結果はサーチ開始時から累積されます。また、過去 30 秒などのように、時間範囲がスライドし
ていくウィンドウとなる時間範囲を指定することもできます。スライドウィンドウを指定した場合、Splunk はそ
の時間量を使ってデータを蓄積します。たとえば、スライドウィンドウが 5 分間の場合、最初の 5 分間が経過す
るまではデータを参照することができません。この動作に優先させて、通常のリアルタイムサーチを実⾏する前
に、初期ウィンドウに履歴データをバックフィルすることができます (後述の「リアルタイムバックフィル」を参
照)。
リアルタイム修飾⼦の構⽂
サーチをリアルタイムに実⾏するには、時間範囲リストに事前定義されているリアルタイムのタイムレンジウィン
ドウを選択するか、または [カスタム時間... ] で [リアルタイム ] を選択して、独⾃のリアルタイムウィンドウを
指定します。
リアルタイムサーチの時間範囲の構⽂は履歴サーチと同じですが、相対時間指定⼦の前に「rt」を付ける必要があ
ります (rt <time_modifier>： rt[+|-]<time_integer><time_unit>@<time_unit>) 。時間修飾⼦の構⽂は、「サーチへの
時間修飾⼦の指定」を参照してください。
これらの値は、サーチ⾔語内から (サーチ⽂字列でインラインに) 使⽤するようには設計されていませ
ん。 times.conf 内で (タイム レンジ ピッカーにオプションを追加するため)、保存済みサーチダイアログ内でもっ
とも早い/もっとも遅い時間範囲を指定する場合、または直接 REST API を使って Splunk のバックエンドサーチ
エンジンにアクセスする場合にも、これらの値を使⽤することができます。
リアルタイムサーチでタイムレンジウィンドウを使⽤する場合、直前に発⽣した⼀部のイベントが表⽰され
ない場合があります。 これは、イベントのタイムスタンプとイベント到着時刻の間の遅延時間が原因で、想定通
りの動作です。タイムレンジウィンドウはイベントの到着時刻ではなく、イベント内のタイムスタンプに対応して
いるため、時間ウィンドウ後に到着したイベントが表⽰されることはありません。
「全時間」リアルタイムサーチ
設定された時間ウィンドウ (30 秒、1 分、2 時間) 内で⾏われるリアルタイムサーチと「全時間」が設定されたリ
アルタイムサーチの間には、わずかな違いがあることに注意してください。
ウィンドウを使⽤するリアルタイムサーチでは、 サーチ内のイベントはウィンドウから外れると消えてし
まいます。また、サーチジョブ作成時刻よりも新しいイベントは、発⽣時にウィンドウに表⽰されます。
「全時間」リアルタイムサーチの場合、 ウィンドウはイベント全体にまたがっています。そのため、ウィ
ンドウに登場したイベントが消えることはありません。サーチジョブ作成時刻よりも新しいイベントは、発
⽣時に表⽰されます。
また、履歴サーチ では、サーチで指定した時間範囲内のイベントが消えることはありません。また、最新の
イベントは常にジョブ作成時刻よりも前になります (将来の⽇付のタイムスタンプを持つイベントを含めた
サーチを除く)。
リアルタイムバックフィル
リアルタイムウィンドウを使⽤するサーチの場合，初期ウィンドウに履歴データをバックフィルするように設定で
きます。これは 2 フェーズの単⼀サーチとして実⾏されます。まず、イベントをバックフィルするための履歴
データに対するサーチが⾏われ、次に標準のリアルタイムサーチが⾏われます。リアルタイムバックフィルによ
り、リアルタイムダッシュボードには開始時点から、時間の経過にともなう正確な視覚エフェクトや統計的指標が
表⽰されます。
リアルタイムバックフィルを有効にするには、
limits.conf
の [realtime] スタンザを使⽤します。
[realtime]
default_backfill = <bool>
* Specifies if windowed real-time searches should backfill events
* Defaults to true
時間を使った近接イベントの検索
Splunk Web でのサーチの時間範囲の設定およびタイムライン の作成には、タイムスタンプ が使⽤されます。
エラーや問題に関するトラブルシューティングを⾏う場合、同時刻に発⽣したイベントを調査することで、結果間
の相互関係を⾒つけ出し、主原因を特定する⼿がかりにできるかもしれません。ここでは、イベントのタイムスタ
ンプやタイムラインを使った、周辺のイベントのサーチ⽅法について説明していきます。
タイムアクセラレータの使⽤
45
フィールドは、イベントのタイムスタンプを表しています。イベントを取得するためにサーチを実⾏する
と、各イベントのタイムスタンプが [時間 ] 列下に表⽰されます。
_time
イベントのタイムスタンプをクリックして、タイムアクセラレータがあるダイアログボックスを開くことがで
きます。あるイベントと時系列的に近いイベントを取得するサーチを実⾏する場合に、タイムアクセラレー
タを使⽤します。
選択したイベントのタイムスタンプの時刻の前、後、またはその時点で発⽣したイベントをサーチすることができ
ます。たとえば、+/- 30 秒、+/- 1 時間、+/- 5 秒などを指定できます。
タイムラインの使⽤
タイムラインは、指定した時間範囲に対するサーチで返されたイベント数のヒストグラムです。時間範囲は⼩さな
期間 (秒、分、時間、または⽇など) に分割され、各期間のイベント数が列 (バー) として表⽰されます。
タイムライン上の各バーの位置は、サーチに⼀致するイベントが発⽣した時期に対応しています。バーがない期間
は、その期間中にイベントが発⽣していないことを表しています。バーの⾼さが⾼いほど、その期間中により多く
のイベントが発⽣したことになります。
タイムライン内でイベント数が突出している、またはイベントがない期間がある場合、その期間が調査を必要とし
ている期間である可能性があります。
タイムラインには、テーブルやグラフと似たようなドリルダウン 機能が⽤意されています。タイムライン内の
バー (列) をクリックすると、サーチ結果が更新され、そのバーが表しているイベントのみが表⽰されます。バー
をダブルクリックすると、それが表している時間範囲に対してサーチが再実⾏されます。その時間範囲の前後にあ
るイベントをサーチすることもできます。
サブサーチ
サブサーチについて
サブサーチの使⽤
サブサーチはもうひとつのコマンドの引数として最も頻繁に使⽤されるセカンダリサーチです。サブサーチは⾓括
弧で囲まれ、最初に評価されます。最初の最初のコマンドは、 ⽣成コマンド である必要があります。⽣成コマン
ドのリストは、『サーチリファレンス』の「コマンドタイプ」を参照してください。
サブサーチの結果をプライマリ、または外部サーチの引数として使⽤できます。サブサーチは主に 2 種類の⽬的
で使⽤されます。
別のサーチ結果を使⽤して、 1 つのサーチをパラメータ化します。たとえば、特定の URL を訪問した IP ア
ドレスのすべての記録を特定します。
サーチを個別に実⾏し、append コマンドを使って最初のサーチに結果を追加します。
サブサーチは、サーチで⾏うアクションが明確で、データの変換を伴わない場合にのみ使⽤できます。たとえ
ば、multikv コマンドは、引数にサブサーチを想定していないため、「sourcetype=top | multikv」でサブサーチを使
⽤することはできません。append や join などの⼀部のコマンドはサブサーチを引数として使⽤することができま
す。
サブサーチの例
以下の例では、サブサーチを使ってあるサーチをパラメータ化します。過去の時間に最もアクティブなホスト の
イベントをすべてを検索することに注⽬しています。毎時間同じホストである訳ではないため、特定のホストに対
してサーチを実⾏することはできません。まず、もっともアクティブなホストを識別する必要があります。
sourcetype=syslog earliest=-1h | top limit=1 host | fields + host
このサーチは 1 つのホスト値のみを返します。この例で、結果となるホスト名は「crashy」でした。次に、
「crashy」からのすべてのイベントの 2 番⽬のサーチを実⾏することができます。
sourcetype=syslog host=crashy
この情報が必要な時に毎回 2 つのサーチを実⾏する代わりに、サブサーチを使ってホスト名を取得し、それを外
部サーチに渡すことができます。
sourcetype=syslog [search sourcetype=syslog earliest=-1h | top limit=1 host | fields + host]
46
サブサーチのパフォーマンス
サーチが⼤量の数の結果を返すと、サブサーチのパフォーマンスが低下させる可能性があります。
この迫のサーチを検討します。
sourcetype=access_* status=200 action=purchase [search sourcetype=access_* status=200 action=purchase | top limit=1
clientip | table clientip] | stats count, dc(productId), values(productId) by clientip
このサブサーチのパフォーマンスは、⼀意の IP アドレスが stats=200 action=purchaseとマッチする数に左右されま
す。何千もの IP アドレスがある場合、topコマンドはトップ 1 が返される前にこれらのアドレスをすべて追跡しな
ければならず、パフォーマンスに影響を及ぼします。
またデフォルトで、サブサーチは最⼤で 10,000 件の結果を返し、ランタイムは最⼤ 60 秒です。この例の場合、
⼤規模な運⽤環境ではサブサーチが完了する前にタイムアウトとなってしまう可能性が⼤いにあります。
次のいくつかの選択肢によって、結果をコントロールすることができます。
クエリを書き換えてサブサーチが処理しなければならないイベント数を制限してください。
サーチと連携動作する format コマンドを利⽤して、サーチに渡す結果数を変更することができます。サブ
サーチの最後に、 次のコマンドを追加してください。
...| format maxresults = <integer>
詳細は、『サーチリファレンス』の format コマンドを参照してください。
また、
limits.conf
内の設定でも、サブサーチの実⾏時間や返す最⼤結果数などを制御することができます。
[subsearch]
maxout = <整数>
サブサーチから返される最⼤結果数。
この値は 10,500 以下にはなりません。
デフォルトは 10000 です。
maxtime = <整数>
サブサーチの最⼤実⾏時間 (秒)。この時間を過ぎるとサブサーチは完了させられます。
デフォルトは 60 です。
ttl = <整数>
サブサーチの結果をキャッシュに保持する時間 (秒)。
120 秒未満には設定しないでください。
デフォルトは 300 です。
サーチの実⾏後、[ ジョブ] メニューをクリックして [ ジョブの調査] を選択し、サーチジョブ調査を開くことがで
きます。remoteSearch コンポーネントまでスクロールすると、サブサーチの結果となる実際のクエリを確認するこ
とができます。詳細は、このマニュアルの「サーチジョブ調査によるサーチジョブプロパティの表⽰」を参照して
ください。
サブサーチコマンドの出⼒設定
は、サブサーチがデフォルトで最⼤ 100 件の結果を返すことを指定しています。サブサーチ内で
の各コマンドの実⾏時に、それらのコマンドがデフォルトの maxout を変更する可能性があるため、実際の出⼒結
果数には変動があるでしょう。また、デフォルトの最⼤出⼒数 (maxout only) は、サーチ式内に展開される⽬的のサ
ブサーチにのみ適⽤されます。しかし、join、append、appendcols などのコマンドはこれに該当しません。
Limits.conf.spec
たとえば append コマンドは、ユーザーがコマンドの引数として maxout を指定しない限り、このデフォルト
値に優先して、 maxresultrows の値を使⽤します。
join コマンドの出⼒制限値は、limits.conf の subsearch_maxout で設定します。デフォルトは 50,000 件のイ
ベントです。
A ns w er s
何か質問がありますか？「Splunk Answers」から、Splunk コミュニティに寄せられた、サブサーチの使⽤⽅法
に関する質問と回答をご覧ください。
サブサーチを使ったイベントの相関
サブサーチはサーチから結果を取得し、別のサーチでその結果を使⽤します。これにより、順次なデータの分析が
可能になります。サブサーチを使って、異なるインデックスからのデータや、分散環境の Splunk サーバーからの
データも含めて、イベントセット全体からデータの相関を探したり、イベントを評価することができます。
たとえば、異なるアプリケーションログには 2 つ以上のインデックスがあります。これらのログからのイベント
データは、少なくとも 1 つの共通フィールドを共有しています。このフィールドの値を使って、他のインデック
ス内に存在しない値に基づき、あるインデックス内のイベントをサーチすることができます。
sourcetype=some_sourcetype NOT [search sourcetype=another_sourcetype | fields field_val]
47
注意： これは、SQL の「NOT IN」機能と同等です。
SELECT * from some_table
WHERE field_value
NOT IN ( 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)
詳細は、『サーチコマンドリファレンス』の 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" [search index="myindex" host="myhost" <Name> | top limit=1 clID | fields + clID ]
サブサーチは、フィールドと値を以下の形式で返します。(
値
0050834ja
(clID="0050834ja") )
のみを返したい場合は、サブサーチ内の clID フィールド名を「search」に変更します。
index=myindex [search index=myindex host=myhost MyName | top limit=1 clID | fields + clID | rename clID as search ]
フィールドが名前付きサーチ (またはクエリ) の場合、フィールド名 (この場合 clID) は破棄されて、サブサーチ
(技術的には、サブサーチの最後にあるのが前提の | format コマンド) は値 ( ( 0050834ja ) ) のみを返します。複
数の値がある場合 (前のサーチで、top コマンドはサーチ結果を 1 に制限します)、サブサーチは各値を OR で処
理して返します。たとえば、3 つの値の結果は ( ( value1 ) OR ( value2 ) OR ( value3 ) ) になります。
これは、フィールド名が「search」または「query」の場合のみの特殊な事例です。フィールドを別の名前に変更
すると、サブサーチは新しいフィールド名を使⽤します。
統計的テーブルおよびグラフ視覚エフェクトの作
成
48
変換コマンドとサーチについて
このトピックでは、変換サーチ を使ったレポートの作成について説明していきます。変換サーチは変換コマン
ド を使って、イベントデータを変換します。サーチが返したデータは、変換コマンドを使って、グラフやその他の
視覚エフェクトが必要とする統計データテーブルへの変換です。
変換コマンド⼊⾨
ここでは、変換コマンドの主な分類と、サーチへの使⽤例を説明していきます。
主な変換コマンド：
chart：描画する任意のデータの
シリーズ を表⽰できるグラフ。グラフの X 軸に使⽤するフィールドを指定
できます。
timechart：「傾向の推移」レポートを作成するために⽤いられます。常に _time が X 軸になります。
top： フィールドで⼀番多い値を表すグラフを表⽰します。
rare： フィールドで⼀番少ない値を表すグラフを表⽰します。
stats、 eventstats、 および streamstats： サマリー統計情報を表⽰するレポートを⽣成します。
associate、 correlate、 および diff ：データのフィールド間の関連、相関、差異を表すレポートを作成しま
す。
注意 ：以下の例で⽰すように、変換コマンドは常にサーチコマンドの後にパイプ記号 (|) を使って指定します。
chart、 timechart、 stats、 eventstats、
および
streamstats
コマンドは、統計関数と連動します。統計関数には、
以下のようなものがあります。
count、distinct count
mean、median、mode
min、max、range、percentiles
standard deviation、variance
sum
first occurrence、last occurrence
統計関数に関する詳細は、『サーチリファレンス』の「統計・グラフ関数」を参照してください。⼀部の統計関数
は、 timechart コマンドしか利⽤できません。
注意 ：変換コマンドを使ったサーチはすべて、特定構造のデータを⽣成します。Splunk で利⽤できるグラフに応
じて、これらのデータ構造を特定の⽅法で設定する必要があります。たとえば、横棒グラフ、縦棒グラフ、折れ線
グラフ、⾯グラフを⽣成できるサーチでも、円グラフは作成できないことがあります。詳細は、『データの視覚
化』マニュアルの「視覚エフェクトのデータ構造要件」を参照してください。
リアルタイムレポート
リアルタイムサーチによって、サマリーインデックス化を使わずに、⼤量のデータからリアルタイムに指標を算出
することができます。ただし、ライブで継続的にデータストリームをレポートしているため、イベントストリーム
の⼊⼒にともなってタイムラインが更新され、テーブルやグラフはプレビューモードでしか表⽰できません。ま
た、リアルタイムでの使⽤に適したサーチコマンドが存在しています (例：streamstats および rtorder)。
関連項⽬
コマンドの種類
サーチの種類
時間ベースのグラフの作成
このトピックでは、変換コマンドの timechart コマンドを使った、時間ベースのレポートの作成について説明し
ています。
ti m ec har t コ マ ン ド
timechart コマンドは、サマリー統計のテーブルを⽣成します。このテーブルをグラフ視覚エフェクトとして
フォーマットし、X 軸を常に時間フィールドとしてデータを描画することができます。timechart を使って時間の
経過に伴う統計的な傾向を表⽰することができます。必要に応じてデータを他のフィールドで異なるシリーズとし
て分割して、グラフに表⽰することができます。タイムチャート視覚エフェクトは、⼀般的に折れ線、⾯、または
縦棒グラフになります。
コマンドを使⽤するサーチの場合、X 軸は時間を表します。Y 軸には任意のフィールド値、値カウン
ト、またはフィールド値の統計計算を表⽰できます。
timechart
詳細は、『ダッシュボードと視覚エフェクト』マニュアルの「視覚化のデータ構造要件」を参照してください。
例
例 1：このレポートは内部 Splunk ログデータを使って、Splunk プロセスによるインデックス作成の平均スルー
プット (インデックスの kbps) の推移を、プロセッサ別に視覚化します。情報は、次のようにプロセッサーで区切
られているか、分割されています。
index=_internal "group=thruput" | timechart avg(instantaneous_eps) by processor
49
関連項⽬
複数のデータシリーズを持つグラフの作成
時間ベースではないグラフの作成
このトピックでは、変換コマンド の chart を使った、時間ベースではない視覚エフェクトの作成について説明し
ています。
c har t コ マ ン ド
chart コマンドは、結果をデータ構造で返します。このデータ構造を利⽤して、縦棒、折れ線、⾯、および円グラ
フとしてデータシリーズを視覚エフェクトで表⽰することができます。
デフォルトフィールド をX 軸として使⽤する timechart コマンドと違い、 chart コマンドを使って作成され
るグラフは、任意のフィールドを X 軸として使⽤します。over キーワードを使って、X 軸に使⽤するフィールド
を指定します。
_time
例
例 1：Web アクセスデータを使⽤して、各平⽇の⼀意のビジター数平均を表します。
sourcetype=access_* | chart avg(clientip) over date_wday
たとえば、他のフィールドでデータを分割することができます。この場合、split by フィールドの各⼀意の値が、
グラフに別個のシリーズとして表⽰されます。サーチに split by 句を指定する場合、over 句は split by 句の前に
配置してください。
以下のレポートは、指定期間内に各 clientip が処理したキロバイト数を host で分割したグラフを⽣成します。⽣
成されたグラフでは、Y 軸に kb が、X 軸に clientip が使⽤されます。遅延値はホストにより区分されます。この
サーチの実⾏後、レポートをスタック横棒グラフとしてフォーマットします。
sourcetype=access_* | chart sum(kb) over clientip by host
例 2：サーバーでヒットした HTTP および HTTPS リクエストを区分した積み上げ横棒グラフを作成します。
この場合、まず着信ポート番号または着信 URL リクエストを含むサーチ時フィールド抽出 の
ます (これらの情報がログに記録されていると仮定)。サーチは以下のようになります。
ssl_type
を作成し
sourcetype=access_* | chart count over ssl_type
このサーチの実⾏後、結果をスタック横棒グラフとしてフォーマットします。
フィールド値件数の上位/ 下位の視覚化
このトピックでは、変換コマンド top および rare を使って、もっとも⼀般的な値ともっとも⼀般的ではない値
を表⽰するグラフを作成する⽅法を説明していきます。
to p お よ び r ar e コ マ ン ド
top コマンドは、返されたイベント内の指定フィールドの、もっとも頻繁に登場する値を返します。rare コマン
ドは、返されたイベント内の指定フィールドの、もっとも登場頻度が少ない値を返します。両⽅のコマンドは同じ
構⽂を使⽤します。limit を指定しない場合、デフォルトで top または rare で表⽰される値数は 10 件です。
例
例 1：ファイアウォール情報を調査するレポートを⽣成して、システムが使⽤した上位 100 件の宛先ポートを表
⽰します。
sourcetype=firewall | top limit=100 dst_port
例 2： 拒否数がもっとも⼩さいソースポートを表⽰するレポートを⽣成します。
sourcetype=firewall action=Deny | rare src_port
複 雑 な to p コ マ ン ド の 例
2 つのフィールドを持つ監視対象システムのアラートログから、インデックスを作成する場合を考えてみましょ
う。
msg
は
のようなメッセージです。
は、log01 のようなメッセージを⽣成するホストです。
CPU at 100%
mc_host
およびそれを送信した mc_host の値の上位値を表⽰するレポートを⽣成して、以下のようなテーブルを取得す
るにはどうしたら良いでしょうか？
msg
50
m c_ho st 別メッセージ
CPU at 100%
log01
log02
log03
LogFile Alert
host02
host56
host11
このためには、mc_host 当たりの message のトップ値を探し (limit=1 を使って 1 件のみを返す)、次にメッセージ
sort の降順に count を実⾏します。
sourcetype=alert_log | top 1 msg by mc_host | sort count
サマリー統計情報を表⽰するレポートの作成
このトピックでは、フィールドに関連するサマリー統計を表⽰するレポート作成をするための、stats および
eventstats 変換コマンド の使⽤について説明しています。
s tats お よ び ev ents tats コ マ ン ド
各イベントに関係するコマンドの集計結果のみが、各イベントに対してインラインに追加されることを除き、
eventstats コマンドは stats とまったく同じ働きをします。
split -by 句
コマンドを有効活⽤するためには、split by 句を指定する必要があります。たとえば、以下のレポートコマ
ンドでは⼗分な情報が得られません。
stats
sourcetype=access_combined | stats avg(kbps)
これはソースタイプが access_combined のすべてのイベントの平均
るグラフには、1 つの列しか表⽰されません。
kbps
を算出しますが、単⼀の値です。結果とな
このような場合 split by フィールドを利⽤することで、当該フィールドの統計情報を記載したレポートを⽣成す
ることができます。以下のレポートは、 access_combined ログを調査して、ホスト別の平均スループット (kbps) を
取得する縦棒グラフを⽣成します。
sourcetype=access_combined | stats avg(kbps) by host
例
例 1：Splunk プロセスの CPU 使⽤状況を降順にソートしたレポートを作成します。
index=_internal "group=pipeline" | stats sum(cpu_seconds) by processor | sort sum(cpu_seconds) desc
例 2：ソースタイプが access_combined のすべてのイベントに対して、ホスト別に分類して平均 kbps を表⽰する
レポートを作成します。
eventstats
結果のフィールド名を指定するには、 as 引数を追加します。これを利⽤すれば、前述の最初の例で
操作の結果を含む新規フィールド名を「avgkbps」にすることができます。
eventstats avg(kbps)
sourcetype=access_combined | eventstats avg(kbps) as avgkbps by host
この⼀連のコマンドを実⾏すると、 kbps フィールドを含む各 sourcetype=access_combined イベントに、新しい
avgkbps フィールドが追加されます。avgkbps の値は、当該イベントの平均 kbps になります。
サーチでの関連、統計的相関、および差異の調査
このトピックでは、サーチ結果の各フィールド値間の関連、類似性、差異を検索する変換コマンド を使⽤しま
す。
as s o c i ate コ マ ン ド
associate コマンドは、フィールド値のペアを使って相互に関連するイベントを判別します。たとえば、あるイベ
ントに「http://www.google.com/」の referer_domain があり、別のイベントに同じ URL 値の referer_domain が
ある場合、それらは関連していると判断されます。
associate
コマンドにより得られた結果は、supcnt 、supfreq 、および improv 引数でチューニングできます。こ
51
れらの引数の詳細は、『サーチリファレンス』マニュアルの Associate コマンドに関連するトピックを参照して
ください。
例 ： Web アクセスソースタイプをサーチして、最低 3 つのフィールド/フィールド値のペアの関連を持つイベン
トを判別します。
sourcetype=access* | associate supcnt=3
c o r r elate コ マ ン ド
correlate コマンドは、フィールド間の統計的相関を算出します。このコマンドは
セットに対して 2 つのフィールドが存在する割合 (パーセント) を算出します。
例：
eventtype=goodaccess
cocur
操作を使って、同じ結果
の全イベントをサーチして、それらの全フィールド間の共起相関を算出します。
eventtype=goodaccess | correlate type=cocur
di f f コ マ ン ド
diff コマンドは、2 つのサーチ結果間の差異を⽐較する場合に使⽤します。デフォルトでこのコマンド
は、attribute 引数で特定のフィールド属性を指定しない限り、選択したサーチ結果の raw テキストが⽐較されま
す。
例 ：サーチで返された 44 番⽬と 45 番⽬のイベントの IP アドレスを⽐較します。
eventtype=goodaccess | diff pos1=44 pos2=45 attribute=ip
複数のデータシリーズを持つグラフの作成
Splunk Enterprise の変換コマンド には、グラフ (または時間グラフ) に複数のデータシリーズ を定義する直接的
な⽅法がありません。ただし、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 値の合計は
平均数は ssns に名前が変更されます)。
hRs
に、
sessions
の
... | 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」
52
の場合、yval には「ssns」が割り当てられます。
... | eval series=source+":"+s1
これは eval コマンドを使って新たな series フィールドを定義します。このフィールドは、host および s1
フィールドの値を連結します。
... | xyseries _time,series,yval
最後に xyseries コマンドを使って、X 軸が _time、Y 軸が yval で、シリーズで定義されたデータを利⽤したグラ
フを作成します。
複数⽇の時間ごとの合計の⽐較
は、時間の推移に伴う傾向を表⽰するグラフを⽣成します。このコマンドでできることには厳密
な制限があります。状況によっては、柔軟性に優れた chart command コマンドを使⽤する必要があります。
timechart command
ここでは、複数の⽇数にわたって収集された値を⽐較するための、
使って同じことはできません。
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 の合計を並べて表⽰します。
P
の合計と 9 ⽇前の午後 3
解決策
chart コマンドを使って、両⽅の⽇をカバーするサーチを設定します。次に、サーチ結果内に⾒つかった各⼀意の
date_hour および date_wday の組み合わせに対して、「sum of P」列を作成します。
サーチは以下のようになります。
earliest=-10d latest=-8d | chart sum(P) by date_hour date_wday
これは、24 スロットを持つ単⼀のグラフを作成します。各スロットが、その⽇の各時間を表しています。各ス
ロットにはレポートの時間範囲がカバーしている、2 ⽇間の時間ごとの合計を⽐較するための 2 つの列が含まれて
います。
レポートサーチの詳細および作成⽅法については、『サーチ』マニュアルの「レポートコマンドの使⽤」を参照し
てください。
chart>
および
timechart
関数に関する詳細は、『サーチリファレンス』の「統計・グラフ関数」を参照してくださ
い。
テーブルの⾏またはセルの情報でセカンダリサーチを実⾏
[統計 ] タブ内のテーブルを返す変換サーチの実⾏後、そのテーブルの⾏またはセルをクリックして別の種類のセ
カンダリサーチを実⾏することができます。
Splunk プラットフォームには、テーブルの⾏やセルに対するさまざまなセカンダリサーチアクションが⽤意され
ています。これらのアクションは、⾏またはセルが表しているフィールド/値のペアを利⽤しています。
セカ
ンダ
リ
サー
チの
アク
ショ
ン
イベ
ント
の表
⽰
説明
時間範囲
結果
フィールド/値のペアを含む、
オリジナルのデータセットから
のイベントのみを表⽰するサー
チを実⾏します。パイプ⽂字以
降のサーチコマンドはすべて破
特定の期間を表すセルまたは⾏
をクリックしない限り、オリジ
ナルのサーチと同じです。ク
リックした場合、セカンダリ
サーチでは時間範囲としてその
オリジナルのサーチが返すのと類似
のイベントリストですが、フィール
ド/値のペアを持つイベントのみが含
まれます。
53
棄されます。
期間が使⽤されます。
その
他の
イベ
ント
フィールド/値のペアを含まな
い、オリジナルのデータセット
からのイベントのみを表⽰する
サーチを実⾏します。変換サー
チコマンドとそれに続くコマン
ドを破棄します。
オリジナルのサーチと同じで
す。
オリジナルのサーチと類似のイベン
トリストですが、フィールド/値のペ
アを持たないイベントのみが含まれ
ます。
結果
から
除外
パイプ⽂字以降のサーチコマン
ドを含めて、オリジナルのサー
チを再実⾏します。フィール
ド/値のペアを持つイベントを
除外します。
オリジナルのサーチと同じで
す。
オリジナルのサーチが返すのと類似
のテーブルですが、フィールド/値の
ペアを持つイベントは除外されま
す。
新規
サー
チ
フィールド/値のペアに集中し
た、新しいサーチを実⾏しま
す。他の値やサーチコマンドは
含まれません。
オリジナルのサーチと同じで
す。
フィールド/値のペアを持つ、時間範
囲内のすべてのイベントのリスト。
この
時間
範囲
を狭
める
パイプ⽂字以降のサーチコマン
ドを含めて、オリジナルのサー
チを再実⾏します。
選択した⾏またはセルが表して
いる時間範囲。
オリジナルのサーチが返すのと類似
のテーブルですが、クリックした⾏
の時間範囲に該当するイベントのみ
が含まれます。新しいテーブルは、
新たな時間範囲内の期間を表す⾏で
分類されています。
テーブルの⾏またはセルでセカンダリサーチを実⾏
1. [サーチレポート] App で、[統計 ] タブのテーブルを返す変換サーチまたはレポートを実⾏します。
2. [フォーマット ] をクリックし、[ドリルダウン ] に適切な値を選択します。
⾏でセカンダリサーチを実⾏する場合は、[⾏ ] を選択します。
セルにセカンダリサーチを実⾏する場合は、[セル ] を選択します。
3. セカンダリサーチを実⾏するテーブルの⾏またはセルをクリックします。
セカンダリサーチ⽤のオプションリストが表⽰されます。リストには、セカンダリサーチオプションの対象
となるフィールド/値のペアも表⽰されます。オプションリストには、セカンダリサーチが特定の時間範囲を
使⽤するかどうかも表⽰されます。
表⽰されるオプションは、さまざまな要素によって異なります。「⾏のセカンダリサーチオプション」と
「セルのセカンダリサーチオプション」を参照してください。
4. セカンダリサーチのオプションをクリックします。
現在のタブでセカンダリサーチを実⾏し、現在のサーチと置換します。または、新しいタブでセカンダリ
サーチを実⾏し、現在のサーチ結果をそのまま保持します。現在のタブでサーチを実⾏するには、オプショ
ンのテキストをクリックします。新しいタブでサーチを実⾏するには、オプションの [新しいタブで開く ]
アイコン
をクリックします。
⾏のセカンダリサーチサーチオプション
⾏のセカンダリサーチサーチオプションには 2 つのセットがあります。
最初の列が
されます。
_time
の値を表す⾏ （期間）をクリックすると 、2 つのセカンダリサーチサーチオプションが表⽰
イベントの表⽰
この時間範囲を狭める
54
最初の列がフィールド/値のペアを表す⾏をクリックすると 、セカンダリサーチオプションが表⽰されます。
セカンダリサーチでは、⾏に⽰されるフィールド/値のそれぞれのペアが使⽤されます。
イベントの表⽰
その他のイベント
セルのセカンダリサーチオプション
セルをクリックした時に表⽰されるセカンダリサーチオプションは、さまざまな要素によって変化します。
セルは期間を意味します。 _time の値を表⽰している⾏のセル (期間) をクリックすると、2 つのセカンダリサー
チサーチオプションが表⽰されます。
イベントの表⽰
この時間範囲を狭める
セルが⾏分割フィールド値を表します。 列がフィールドを表しているテーブル内のセルに表⽰され、最初の列
ではないセルをクリックしている場合です。列タイトルとセル値が表しているフィールド/値のペアに対して、4
つのセカンダリサーチオプションが表⽰されます。
イベントの表⽰
その他のイベント
結果から除外
新規サーチ
また、選択したセルが表すフィールド/値のペアおよび⾏でその前にある他のフィールド/値のペアの組み合わせに
対する、2 つのセカンダリサーチオプションも表⽰されます。
イベントの表⽰
その他のイベント
55
セルが列分割値を表しています。 通常、最初の列が時間範囲または⾏分割フィールドで、他の列が別のフィール
ドの値を⽰しているテーブル内に⾒られます。通常、列分割セルにはカウントや類似する数値が含まれています。
結果から除外 (列が表すフィールド/値のペアに対して)
イベントの表⽰ (列が表すフィールド/値のペアと⾏が表すフィールド/値のペアまたは時間範囲に対して)
セルがイベント数または割合 (パーセント) を表しており、列分割値ではありません。 このセルの前のセル内
のフィールド/値のペアに対する 2 つのセカンダリサーチオプションとその⾏が表⽰されます。
イベントの表⽰
その他のイベント
グラフと視覚エフェクトのセカンダリサーチ
グラフや視覚エフェクトのエレメントをクリックしてセカンダリサーチを実⾏することもできます。詳細は、
『ダッシュボードと視覚エフェクト』マニュアルの「ドリルダウン動作」を参照してください。
テーブル/ グラフを作成するためにピボットで⾮変換サーチを開く
変換コマンド を含まないサーチは、[イベント ] タブで参照できるイベントリストを返します。また、[パターン ]
タブを使って、それらのイベントの中で有⼒なパターンを確認することができます。ただし、⾮変換サーチは、統
計テーブルの形式で結果を返すことができません。統計テーブルがないと、グラフや他の視覚エフェクトを作成で
きません。つまり、⾮変換サーチを実⾏すると、[統計 ] または [視覚エフェクト ] タブには結果が表⽰されませ
ん。
⾮変換サーチを実⾏して、それに基づくテーブルやグラフを作成したい場合、[統計 ] または [視覚エフェクト ] タ
ブに移動してサーチをピボットで開きます。
56
ピボットエディタ では、オリジナルのサーチ⽂字列に追加しなくても、テーブルやグラフを作成することができ
ます。ピボットエディタで作業 (フィールドの選択、テーブルや視覚エフェクトエレメントの定義、フィルタの設
定など) を⾏うにつれて、オリジナルのサーチが更新され、再実⾏されます。編集内容により、作成するテーブル
や視覚エフェクトがどのように変化するのかを確認することができます。
ピボットエディタでは、作成したテーブル、グラフ、または他の視覚エフェクトを、レポートやダッシュボードパ
ネルとして保存できます。Splunk Enterprise は、対応するデータモデル を作成します。このデータモデルが、
保存済みレポートやダッシュボードパネルの基盤になります。これは、レポートやダッシュボードパネルに関与す
るサーチやフィールドを定義しています。データモデルがないと、保存したレポートの再実⾏やパネルの表⽰を⾏
うことはできません。
ピボットでサーチを開く
1. [サーチ] ビューで、⾮変換サーチを実⾏します。例：
sourcetype=access_* status=200 action=purchase
2. [統計 ] または [視覚エフェクト ] タブに移動して、[ピボット ] をクリックします。
3. ピボットエディタでテーブルやグラフの作成に使⽤する、⼀連のフィールドを選択します。
各オプションには、それが表しているフィールド数が括弧に囲まれて表⽰されます。
[すべてのフィールド ] には、サーチで⾒つかったすべてのフィールドが表⽰されます。
[選択されたフィールド ] は、[フィールド ] タブのサーチで選択されたフィールド のみに制限されま
す。フィールドの変更や選択を⾏わずにピボットでサーチを開くと、[選択されたフィールド ] オプ
ションには、デフォルトで選択されたフィールド (host、 source、および sourcetype) が表⽰されます。
別のフィールドセットでテーブルやグラフを作成するには、[フィールド ] タブに移動して [選択され
たフィールド] のリストでフィールドを選択します。その後、[統計 ] または [視覚エフェクト ] タブに
移動して、ピボットでサーチを開きます。
[カバー範囲が最低 n% のフィールド ] では、フィールドセットのカバー範囲閾値を設定することが
できます。たとえば、イベントの⼤半に適⽤するフィールドで作業を⾏う場合は、70% のように⾼め
の閾値を設定します。ピボットに取り込まれるフィールドセットは、サーチが返すイベントの 70% 以
上に存在するフィールドになります。
4. [OK ] をクリックして、ピボットエディタ に移動します。
5. ピボットテーブルまたはグラフを作成します。
ピボットエレメントタイプ (フィルタ、⾏分割、列分割、および列値) の [属性 ] リストには、ステップ 3 で
選択したフィールドセットが表⽰されます。
注意 ：テーブルまたはグラフを保存せずに、ピボットエディタから他の場所に移動すると、作業内容は失わ
れてしまいます。
作業内容の保存については、次のトピック「完成したピボットテーブルまたはグラフの保存」を参照してく
ださい。
ピボットエディタでは、[サーチで開く ] をクリックして、ピボットサーチを開いて編集することができます。こ
の操作を⾏うとピボットエディタ外の場所に移動して、作成したピボットテーブルまたはグラフを保存できなくな
ります (次のトピックを参照)。
ピボットエディタを使ったテーブルの設計については、「ピボットエディタを使ったピボットテーブルの設計」を
参照してください。
ピボットエディタを使ったグラフや他の視覚エフェクトの設計については、「ピボットエディタを使ったピボット
グラフと視覚エフェクトの設計」を参照してください。
完成したピボットテーブルまたはグラフの保存
ピボットエディタでテーブルやグラフを、レポートやダッシュボードパネルとして保存できます。ただし、保存し
たレポートやパネルをサポートするためには、データモデルも作成する必要があります。このデータモデルは、保
存したレポートやパネルにアクセスできなければなりません。
1. ピボットエディタで [名前を付けて保存 ] をクリックして、[ レポート] または[ ダッシュボードパネル ] を選択
します。
選択内容に応じて、[レポートとして保存] または [ダッシュボードパネルとして保存] ダイアログボックスが
表⽰されます。
2. [名前を付けて保存 ] ダイアログボックスには、保存するレポートまたはダッシュボードパネルに関する情報が
表⽰されます。
これらのフィールドに関する詳細は、レポートまたはダッシュボードパネルの保存に関するドキュメントを
参照してください。
3. [名前を付けて保存 ] ダイアログボックスで、レポートやダッシュボードパネルをサポートするデータモデル
の、[モデル名 ] および [モデル ID ] を⼊⼒します。
管理者レベルの権限があるロールをお持ちの場合、この⼿続きで Splunk Enterprise が作成したモデルを管
理することができます。
57
4. [保存 ] をクリックして、レポートまたはダッシュボードパネルを保存して、データモデルを作成します。
ボタンをクリックして、新しいレポートまたはダッシュボードパネルを表⽰します。または、モデル名をク
リックして、新しいデータモデルに移動します。
データモデル名をクリックすると、データ モデル ビルダーに移動します。ここでは、モデルに関連する
フィールドを変更したり、モデルにデータ モデル オブジェクトを追加したりできます。
この⽅法で作成したオブジェクトの権限について
新しく作成したデータモデルはプライベートで、その作成者のみが参照、使⽤することができます。admin また
は power ロール (または同等の権限を持つロール) を持つユーザーのみが、データモデルを共有できます。データ
モデルが共有されていない場合、そのデータモデルを使って作成されたレポートやダッシュボードパネルも共有で
きません。また、共有されない限りデータモデルを⾼速化できません。
⾃分専⽤のレポートまたはダッシュボードパネルを作成した場合は、何もする必要はありません。他のユーザーに
レポートやダッシュボードにアクセスさせたい場合は、関連するデータモデルを共有するか (適切な権限がある場
合)、または管理者レベルの権限を持つユーザーに共有を依頼してください。
データモデルの権限の詳細は、『ナレッジ管理』マニュアルの「データモデルの管理」を参照してください。
リアルタイムのサーチとレポート
リアルタイムサーチとレポートについて
リアルタイムサーチ とレポートでは、イベントのインデックス が作成される前にイベントをサーチし、イベント
の⼊⼒に伴ってレポートをプレビューすることができます。
バックグラウンドで継続的に実⾏されるリアルタイムサーチに基づくアラート を作成できます。このようなリア
ルタイムアラート により、スケジュール済みレポート に基づくアラートよりもタイムリーに通知することがで
きます。詳細は、『アラート』 マニュアルを参照してください。
また、ダッシュボードエディタ、パネルエディタ、シンプル XML を使って、カスタムダッシュボード にリアル
タイムサーチ結果およびレポートを表⽰することもできます。ビジュアルダッシュボードエディタの詳細は、
『データの視覚化』マニュアルの「UI による簡単なダッシュボードの作成」を参照してください。
ビジュアルダッシュボードエディタよりも⾼度な機能を提供するリアルタイムダッシュボードの使⽤⽅法について
は、『開発者』マニュアルの「リアルタイムダッシュボードの構築」を参照してください。
注意 ： Splunk Enterprise をデフォルト設定で利⽤する場合、管理者ロールを持つユーザーのみがリアルタイム
サーチを実⾏、保存することができます。ロールの管理とユーザーへの割り当てについては、『Splunk
Enterprise のセキュリティ』の「ロールの追加と編集」を参照してください。
リアルタイムサーチの仕組み
リアルタイムサーチでは、インデックス処理のために Splunk Enterprise にイベントが⼊⼒されると、それに対
してサーチが⾏われます。リアルタイムサーチを開始すると、Splunk Enterprise はサーチの⼀致候補であること
を⽰す、インデックス時フィールドを含む到着イベントをスキャンします。
リアルタイムサーチを実⾏すると、ソフトウェアがサーチ基準に対してスキャンされたイベントを定期的に評価
し、サーチで定義したスライド可能なタイム レンジ ウィンドウ で実際のマッチを探します。⼀致したイベント
を特定する速度により、⼀致するイベント数は時間の経過とともに増減します。Splunk Web でサーチを実⾏し
ている場合、サーチタイムラインには、選択した時間範囲内に返されたサーチにマッチするイベントも表⽰されま
す。
1 分間のタイムレンジウィンドウを指定したリアルタイムサーチの例を⽰します。この画⾯キャプチャの取得時点
では、サーチは実⾏後合計 904 件のイベントをスキャンしています。⼀致したイベント数 447 件は、サーチ基準
に⼀致する過去 1 分間に識別されたイベント数を表しています。この値は次の 1 分間で 430〜450 の範囲で変動
しています。これが急激に増加/減少した場合は、何か調査する必要のある注⽬すべき事態が発⽣した可能性があ
ります。
58
画⾯のように、タイムラインの右側には最新のイベントが表⽰されます。時間の経過に伴い、これが左側に移動し
ていき、タイムレンジウィンドウから完全に消えることになります。
リアルタイムサーチは、誰かがサーチを停⽌するかまたはサーチジョブを削除するまで継続的に動作します。何ら
かの理由でタイムアウトになることはありません。イベントが停⽌している場合は、パフォーマンス上の問題が発
⽣している可能性があります (「予想されるパフォーマンスと既知の制限事項」を参照)。
リアルタイムサーチでは、ルックアップやトランザクションなどの⾼度な機能を含め、すべてのサーチ機能を活⽤
することができます。また、 streamstats や rtorder など、特にリアルタイムサーチと連係動作することを前提に
設計されたサーチコマンドも⽤意されています。
インデックス リアルタイム サーチ
同時リアルタイムサーチ数は、インデックス作成パフォーマンスに⼤きな影響を与えます。インデクサーへの影響
を軽減するために、インデックス リアルタイム サーチを有効にすることができます。これは、履歴サーチのよう
なサーチを実⾏することですが、継続的にディスク上に新たに登場したイベントで更新されていきます。
リアルタイムサーチのデフォルト動作として、インデックス リアルタイム サーチを有効にするには、limits.conf
のスタンザ realtime を編集して、 indexed_realtime_use_by_default = true を設定します。
インデックス リアルタイム サーチは、最新の情報精度が不要な場合に⽤いられます。インデックス リアルタイム
サーチが返す結果には、常にリアルタイムサーチよりも遅延があります。indexed_realtime_disk_sync_delay = <int>
設定で、遅延の秒数を制御することができます。デフォルトで、この遅延は 60 秒です。
インデックス リアルタイム サーチ動作の設定に利⽤できるその他の項⽬は、後述します。
[realtime]
indexed_realtime_default_span = <int>
* An indexed realtime search is made up of many component historical searches that by default
* will span this many seconds. If a component search is not completed in this many seconds the
* next historical search will span the extra seconds. To reduce the overhead of running an
* indexed realtime search you can change this span to delay longer before starting the next
* component historical search.
* Precendence: Indexers
* Defaults to 1
indexed_realtime_maximum_span = <int>
* While running an indexed realtime search, if the component searches regularly take longer
* than indexed_realtime_default_span seconds, then indexed realtime search can fall more than
* indexed_realtime_disk_sync_delay seconds behind realtime. Use this setting to set a limit
* afterwhich we will drop data to return back to catch back up to the specified delay from
* realtime, and only search the default span of seconds.
* Precedence: API overrides SearchHead overrides Indexers
* Defaults to 0 (unlimited)
indexed_realtime_cluster_update_interval = <int>
* While running an indexed realtime search, if we are on a cluster we need to update the list
* of allowed primary buckets. This controls the interval that we do this. And it must be less
* than the indexed_realtime_disk_sync_delay. If your buckets transition from Brand New to warm
59
* in less than this time indexed realtime will lose data in a clustered environment.
* Precendence: Indexers
* Default: 30
S pl u nk Web でのリアルタイムサーチとレポート
Splunk W eb で の リ ア ル タ イ ム サ ー チ
リアルタイムサーチ は、履歴サーチ とまったく同じ⽅法で実⾏できます。ただし、ライブで継続的にデータスト
リームをサーチするため、イベントストリームの⼊⼒に伴ってタイムラインが更新され、またレポートはプレ
ビューモードでしか表⽰できません。また、履歴サーチよりもリアルタイムサーチに適したサーチコマンドが存在
しています。たとえば、streamstats および rtorder は、リアルタイムサーチでの使⽤を前提に設計されていま
す。
Splunk Web でリアルタイムサーチを開始するには、[時間範囲] メニューから事前設定されているリアルタイム
の [タイム レンジ ウィンドウ ] を選択します (例：[30 秒 ] または [1 分 ] など)。また、リアルタイムサーチに適
⽤する、スライドするタイムレンジウィンドウを指定することもできます。
Apache Web アクセスデータがある場合、以下のサーチを実⾏して取り込まれてくる Web トラフィックイベン
トを参照することができます。
sourcetype=access_*
⼊⼒パイプラインから⼊⼒される raw イベントは、時間順に並んではいません。rtorder コマンドを使⽤すれば、
リアルタイムサーチからのイベントをバッファに格納し、それを時間の昇順に出⼒することができます。
以下の例では、過去 5 分間の Web トラフィックイベントをバッファに保管し、5 分以上経過したイベントを時間
の昇順に送信します。新たに受信したイベントが 5 分以上前の時刻を持つ場合、その時刻以降のイベントをすで
に送信しているならば、当該イベントを破棄します。
sourcetype=access_* | rtorder discard=t buffer_span=5m
リアルタイムサーチは、イベントのストリームに依存しています。そのため、イベントを⽣成しない | metadata
や、単にファイルを読み取るだけの | inputcsv などのコマンドをリアルタイムサーチに利⽤することはできませ
ん。また、サーチ結果を | outputcsv に送信しても、リアルタイムサーチを完了させない限り、CSV ファイルに書
き込まれることはありません。
Splunk W eb で の リ ア ル タ イ ム レ ポ ー ト
⼤部分の Web ページにアクセスする IP アドレスをプレビューするには、レポートを実⾏します。この場合 top
コマンドは、clientip (クライアント IP)、count (カウント)、および percent (パーセント) の 3 つの列を持つテー
ブルを返します。データストリームが到着すると、テーブルが新たな値で更新されます。
sourcetype=access_* | top clientip
各 Web トラフィックイベントに対して、現在までに確認されたイベント数を表す
(ただし、現在のイベントはカウントに⼊れません)。
count
フィールドを追加します
sourcetype=access_* | streamstats count current=false
リアルタイムレポートにドリルダウンすることもできます。ただし、リアルタイムにドリルダウンを⾏っても新た
なリアルタイムサーチが⾏われるわけではありません。代わりに、すでに取得されインデックスが作成されたイベ
ントの履歴サーチが実⾏されます。詳細は、『ダッシュボードと視覚エフェクト』マニュアルの「ドリルダウン動
作」を参照してください。
CL I でのリアルタイムサーチとレポート
CLI でリアルタイムサーチを実⾏するには、「search」の代わりに「rtsearch」を使⽤します。
./splunk rtsearch 'eventtype=pageview'
サーチ結果内の単語を強調するには、highlight コマンドを使⽤します。以下の例では、ページビューイベントの
「GET」を強調表⽰しています。
./splunk rtsearch 'eventtype=pageview | highlight GET'
デフォルトでは、サーチ結果の⾏の折り返しが有効になっています。⾏の折り返しを無効にするには、-wrap オプ
ションを使⽤します。
./splunk rtsearch 'eventtype=pageview' -wrap 0
CLI でのリアルタイムレポートもプレビューモードで表⽰され、データの到着に伴い更新されていきます。
./splunk rtsearch 'error | top clientip'
結果のプレビューを抑制するには、-preview オプションを使⽤します。
./splunk rtsearch 'error | top clientip' -preview false
60
プレビューをオフにしても、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 のパフォーマンスは、インデクサーに膨⼤な負荷がかかっておらず、多数のリアルタイムサーチを同時に
実⾏しない限り、⼗分に許容できるものと想定されています。ただし、多数のリアルタイムサーチを同時に実⾏す
ると、⼤量のデータが存在する環境ではパフォーマンスやネットワークに⼤きな影響を与えます。
リアルタイムサーチをプランニングする場合、以下の両⽅のパフォーマンスに与える影響を考慮する必要がありま
す。
ライブイベントを転送する必要があるサーチピア 。
ライブイベントの集約されたストリームを処理する必要があるサーチヘッド 。
サーチピアで⾏われる処理が多くなれば、サーチヘッドで必要な処理は減少します。また、逆も同様です。サーチ
ピアは総合的なシステム機能に影響してきます。そのため、ライブイベントのフィルタリングであまり⼤きな負荷
をかけないようにしてください。しかし、サーチピアで何もフィルタリングを⾏わないと、サーチヘッドにすべて
のライブイベントを送信するために必要な処理能⼒と帯域幅のコストが⾼くなる可能性があります (特に複数のリ
アルタイムサーチを同時実⾏する場合)。
サーチヘッドがインデクサーに追随できない場合、インデックスプロセッサ上のキューはイベントを破棄し
ます。 ただし、イベントにはシーケンス番号があり、これを使って破棄されたイベント数とその時期を確認する
ことができます。
リアルタイムサーチと履歴サーチの同時実⾏
ハードウェアの能⼒が許す範囲内で、複数のリアルタイムサーチと履歴サーチを同時実⾏することができま
す。 同じユーザーまたは異なるユーザーによる、個別のサーチに関する制限はありません。
リアルタイムサーチの同時実⾏
複数のリアルタイムサーチを同時実⾏すると、インデックス作成能⼒に悪影響を与えてしまいます。 リアル
タイムサーチ機能は、スパースサーチのリアルタイムアラート向けに最適化されており、それと引き換えに待ち時
間と信頼性を改善するインデックス能⼒が犠牲になります。
インデックス リアルタイム サーチ
同時リアルタイムサーチ数は、Splunk のインデックス作成パフォーマンスに⼤きな影響を与えます。インデク
サーへの影響を軽減するために、インデックス リアルタイム サーチを有効にすることができます。基本的にこれ
は、履歴サーチのようなサーチを実⾏することですが、継続的にディスク上に新たに登場したイベントで更新され
ていきます。
インデックス リアルタイム サーチを有効にする⽅法の詳細は、「リアルタイムサーチとレポートについて」を参
照してください。
リアルタイムサーチウィンドウ
ウィンドウを使ったリアルタイムサーチは、ウィンドウを使わないサーチよりもコストが⾼くなっていま
す。 ウィンドウの内容を管理、プレビューするために必要な操作のため、ウィンドウを利⽤したリアルタイム
サーチの処理が、頻繁なインデックスの作成に追いつかないこともあります。ウィンドウを利⽤するサーチで、期
待している数のイベントが表⽰されない場合は、ウィンドウを利⽤しないサーチをお試しください。イベント数の
みに注⽬する場合は、サーチで「timechart count」を使⽤してみてください。
詳細は、「サーチへのリアルタイム時間範囲ウィンドウの指定」を参照してください。
リアルタイムサーチの利⽤の制限⽅法
リアルタイムサーチの過度の使⽤はパフォーマンスに悪影響を与えるため、必要に応じてその利⽤を制限しなけれ
ばならないこともあります。Splunk にはこのためのさまざまな⽅法が⽤意されています。以下の作業を⾏うこと
61
ができます。
特定のインデックスの indexes.conf を編集して、インデクサーレベルでリアルタイムサーチを無効にする。
特定のロールおよびユーザーに対してリアルタイムサーチを無効にする。
limits.conf を編集して、同時に実⾏できるリアルタイムサーチ数を減らす。
limits.conf を編集して、リアルタイムサーチのインデクサーサポートを制限する。
i ndex es .c o nf で リ ア ル タ イ ム サ ー チ を 無 効 に す る
リアルタイムサーチにより、インデクサーに⾮常に負担がかかることがあります。インデクサー上でリアルタイム
サーチを無効にする場合は、インデクサーの indexes.conf で [default] 設定を編集します。
[default]
enableRealtimeSearch = <bool>
注意 ：複数のインデクサーに接続するサーチヘッドは、リアルタイムサーチが有効になっているインデクサーか
ら引き続きリアルタイムサーチ結果を取得することができます。
ユーザーまたはロールに対してリアルタイムサーチを無効にする
リアルタイムサーチは、Splunk Web の [ 管理] > [ アクセス制御] から、特定のユーザーやロールに割り当てら
れる権限 です。デフォルトで、rt search 権限は、Admin (管理者) および Power (パワー) ロールに割り当てられ
ています。User (ユーザー) ロールには割り当てられていません。rtsearch 権限のないロールは、サーチヘッドが
接続しているインデクサーに関係なく、そのサーチヘッドでリアルタイムサーチを実⾏することはできません。
リアルタイムサーチの制限の設定
の [search] スタンザを使って、システム上で同時に実⾏できる最⼤リアルタイムサーチ数を変更する
ことができます。
limits.conf
[search]
max_rt_search_multiplier = <decimal number>
realtime_buffer = <int>
max_rt_search_multiplier
履歴サーチの最⼤数に乗算する数値、最⼤同時リアルタイムサーチ数を決定します。デフォルトは 1 です。
注意 ：リアルタイムサーチの最⼤数は、以下のように算出されます：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]
queue_size = <int>
各リアルタイムサーチのキューサイズ。0 以上でなければなりません。
デフォルトは 10000 です。
blocking =[0|1]
キューが満杯になった場合、インデクサーをブロックするかどうかを⽰します。
デフォルトは偽 (0) です。
max_blocking_secs = <int>
キューが満杯の場合に、ブロックする最⼤時間。blocking
ません。
0 を設定すると「無制限」になります。
デフォルトは 60 です。
62
= false
の場合、このオプションは何も意味を持ち
indexfilter = [0|1]
効率のために、インデクサーがイベントを事前フィルタリングするかどうかを⽰します。
デフォルトは真 (1) です。
フィールドの評価と操作
フィールドの評価と操作について
このセクションでは、新規フィールドの評価、既存のフィールドの操作、新規フィールドによるイベント情報の強
化、および複数値フィールドの解析などを⾏うためのサーチコマンドについて説明していきます。
新規フィールド評価の主役となるのが、eval コマンドとその関数です。イベント内のフィールドに基づいて
統計情報を算出する stats コマンドとは違い、eval は既存のフィールドと任意の式を使って新しいフィール
ドを作成するために⽤いられます。eval コマンドには多くの関数が⽤意されています。詳細は、「eval コ
マンドと関数の使⽤」を参照してください。
サーチ時にその他の情報を使って、⼿軽にデータの価値を⾼めることができます。詳細は、「ルックアップ
を使った外部ルックアップテーブルからのフィールドの追加」を参照してください。
Splunk サーチ⾔語を使⽤して、さまざまなサーチコマンドを使って異なる⽅法でフィールドを抽出するこ
とができます。
イベントには、複数の値を持つフィールドが含まれている場合があります。Splunk のサーチ⾔語には、複
数値フィールドに対応できるさまざまなサーチコマンドと関数が⽤意されています。詳細は、「複数値
フィールドの操作と評価」を参照してください。
ev a l コマンドおよび関数の使⽤
eval コマンドでは、⾃動抽出フィールドを使った任意の式の評価結果となる値を取る新しいフィールドを作成す
ることができます。eval コマンドは、多彩な機能を持ちとても有⽤です。eval 式は⽐較的単純ですが、しばしば
⾮常に複雑になる場合もあります。
このトピックでは、eval コマンドと評価関数の使⽤⽅法について説明していきます。
ev al 式 の タ イ プ
eval 式は宛先フィールドの値を表す、リテラル、フィールド、演算⼦、および関数の組み合わせです。式には数
値演算、⽂字列連結、⽐較式、論理式、または eval 関数の呼び出しを含めることができます。eval 式では、操作
タイプに対して有効なフィールド値が必要になります。
たとえば、追加の例外処理では、値が数値でないと算出操作で有効な結果を得ることはできません。また、eval
では 2 つのオペランドが両⽅とも⽂字列の場合、それを連結することができます。「.」が存在する値を連結する
場合は、実際の種類に関係なく両⽅の値が⽂字列として処理されます。
例 1： eval を使って、2 つの円 A と B の⾯積の合計となるフィールドを定義します。
... | eval sum_of_areas = pi() * pow(radius_a, 2) + pi() * pow(radius_b, 2)
円の⾯積は πr 2 で、r は半径を表しています。円 A と B に対して、半径はそれぞれ radius_a と radius_b とし
ます。この eval 式は pi と pow 関数を使ってそれぞれの円の⾯積を算出し、次にそれらを加算して結果を
sum_of_areas フィールドに保存します。
例 2： eval 式および city と state フィールドを使って場所を定義します。たとえば、city=Philadelphia で
state=PA の場合、場所は location="Philadelphia, PA" となります。
... | eval location=city.", ".state
この eval 式は、単純な⽂字列連結を⾏っています。
例 3： eval 関数を使って、メールアドレスのドメインに基づいて、メールの送信元を分類します。.com、.net、
および .org アドレスは国内 (local)、それ以外は海外 (abroad) と⾒なされます。(もちろんですが、
.com/.net/.org 以外のドメインは abroad からである必要はありません。)
sourcetype="cisco_esa" mailfrom=*| eval accountname=split(mailfrom,"@") | eval from_domain=mvindex(accountname,-1) |
eval location=if(match(from_domain, "[^\n\r\s]+\.(com|net|org)"), "local", "abroad") | stats count by location
この例は、⽣成されたメールデータ (sourcetype=cisco_esa) を使⽤しています。この例の sourcetype=cisco_esa をご
⾃分のデータの sourcetype 値に、そして mailfrom フィールドをご⾃分のメールアドレスフィールド名 (例 ：To,
From, or Cc) に変更すれば、任意のメールデータに対して利⽤できます。
関数は、mailfrom フィールド内のメールアドレスの分割に⽤いられます。mvindex 関数は
を、mailfrom フィールドの @ 記号の後の部分として定義しています。
split()
from_domain
次に if() および match() 関数が使⽤されます。 from_domain の値が.com, .net., or .org で終了する場合、 location
フィールドには local が割り当てられます。from_domain が⼀致しない場合は、location に abroad が割り当てられま
す。
63
の結果は
成されます。
eval
stats
コマンドに渡されて、各
location
値の結果数がカウントされ、以下のような結果テーブルが⽣
注意 ：これは match() を使⽤する⼀例にすぎません。イベントを分類して、それらのイベントを早くサーチしたい
場合は、イベントタイプを使⽤することをお勧めします。詳細は、『ナレッジ管理』マニュアルの「イベントタ
イプについて 」を参照してください。
計算済みフィールドの定義
特定の eval 式を定期的に使⽤しているような場合は、フィールドを計算済みフィールドとして props.conf 内に定
義することを検討してください。そうすれば、サーチを作成する場合に、eval 式を全体を省略し、抽出された他
のフィールドを参照するように、このフィールドを参照することができます。サーチを実⾏すると、サーチ時に
フィールドが抽出され、eval 式内のフィールドを含むイベントに追加されます。
設定⽅法の詳細は、『ナレッジ管理』マニュアルの「計算済みフィールドの定義」を参照してください。
ルックアップを使ったルックアップテーブルからのフィールドの追
加
イベント内のフィールドを、ルックアップテーブルなどの外部ソースのフィールドと照合し、マッチする情報を
使って他の情報をイベントに追加することができます。
ルックアップテーブルは、静的 CSV ファイル、KV ストアコレクション、または Python スクリプトの出⼒にな
ります。また、サーチ結果を CSV ファイルまたは KV ストアコレクションに出⼒し、それをルックアップテーブ
ルとして使⽤することもできます。フィールドルックアップの詳細は、『ナレッジ管理』マニュアルの「CSV お
よび外部ルックアップの設定」および「KV ストアルックアップの設定」を参照してください。
フィールドルックアップの設定後は、サーチ 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」を参照してください。
サーチコマンドによるフィールドの抽出
多彩なサーチコマンドを使って、フィールドをさまざまな⽅法で抽出することができます。
rex は Perl 正規表現名前付きグループを使って、フィールド抽出を⾏います。
extract (「キー/値」の場合は kv) は、デフォルトのパターンを使って明⽰的にフィールド/値を抽出しま
す。
multikv は、複数⾏、表形式イベントのフィールド/値を抽出します。
spath は、XML や JSON などの構造化されたイベントデータのフィールド/値を抽出します。
xmlkv および xpath は、XML 形式イベントデータのフィールド/値を抽出します。
kvform は、あらかじめ定義されたテンプレートに基づいてフィールド/値を抽出します。
次のセクションでは、正規表現とコマンドを使ったフィールドの抽出⽅法が記述されています。詳細は、『ナレッ
ジ管理』 マニュアルの「フィールドの抽出について」を参照してください。
正規表現を使ったフィールドの抽出
rex サーチコマンドは、サーチ⽂字列に指定した Perl 正規表現名前付きグループを使ってフィールド抽出を実⾏
します。これは、raw イベントのセグメントを正規表現と照合し、これらの値をフィールドに保存します。
この例では、⽂字列「From:」および「To:」の後に存在する値が、それぞれ「from」および「to」フィールドに
保存されます。
... | rex field=_raw "From: (?<from>.*) To: (?<to>.*)"
raw イベントに「From: Susan To: Bob」とある場合、サーチではは「from=Susan」と「to=Bob」のように、
64
フィールドの名前/値のペアが抽出されます。
正規表現の構⽂と使⽤⽅法の概要については、Regular-Expressions.info を参照してください。正規表現式を作
成、テストするために役⽴つサードパーティ製ツールのリストも⽤意されています。
.c o nf フ ァ イ ル か ら の フ ィ ー ル ド の 抽 出
抽出コマンドを使⽤し、結果セットでのフィールド/値の抽出を強制します。引数を指定せずに extract コマンド
を使⽤する場合、フィールドは props.conf ファイルに追加されるフィールド抽出スタンザを使⽤して抽出されま
す。extract を使⽤すると、conf ファイル経由で⼿動で追加するフィールドの抽出をテストできます。
表形式のイベントからのフィールド抽出
複数⾏、表形式イベントのフィールド/値の抽出を強制するには、multikv を使⽤します。この場合、各テーブル
⾏に対して新しいイベントが作成され、テーブルのタイトルからフィールド名が取得されます。
XML 形式のイベントからのフィールド抽出
xmlkv コマンドを使って、Web ページからのトランザクションなどのイベントデータ内の XML 形式タグの
フィールド/値の抽出を強制できます。
X M L お よ び J SO N ド キ ュ メ ン ト か ら の フ ィ ー ル ド の 抽 出
spath コマンドは、XML および JSON といった構造化データフォーマットの情報を抽出し、値をフィールドに保
存する⼿段を提供しています。
フォームテンプレートに基づいたイベントからのフィールドの抽出
kvform コマンドは、$SPLUNK_HOME/etc/system/local/ または $SPLUNK_HOME/etc/apps/ 内の独⾃のカスタムアプリケー
ションディレクトリに事前定義、保管されているフォームテンプレートに基づいて、イベントからフィールド/値
のペアを抽出します。たとえば form=sales_order の場合、サーチは sales_order.form を探し、すべての処理済みイ
ベントをそのフォームと照合し、値の抽出を試みます。
複数値フィールドの操作と評価
複数値フィールドについて
Splunk はサーチ時に複数値フィールドを解析します。これにより値をサーチパイプライン内で処理することがで
きます。複数値フィールドを利⽤できるサーチコマンドには、makemv、mvcombine、mvexpand、および
nomv があります。eval および where コマンドは、複数値フィールドを利⽤できる mvcount(), mvfilter(),
mvindex(), and mvjoin() などの関数をサポートしています。『サーチリファレンス』 の評価関数と本トピックの例
を参照してください。
ファイルに複数値フィールドを設定し、単⼀の抽出されたフィールド値内にある複数のフィールド値
の認識⽅法を Splunk Enterprise に指⽰できます。$SPLUNK_HOME/etc/system/local/ の fields.conf 、または
$SPLUNK_HOME/etc/apps/ の独⾃のカスタムアプリケーションディレクトリを編集します。詳しい⽅法は、『ナレッジ
管理』マニュアルの「複数値フィールドの設定」を参照してください。
fields.conf
サーチがテーブルなどの結果を⽣成する場合、その結果は results.csv.gz ファイルに書き込まれま
す。results.csv.gz ファイルのコンテンツには、「__mv_」で始まるフィールドが含まれます。これらのフィール
ドは内部使⽤専⽤であり、複数値フィールドをエンコードするために使⽤されます。
複数値フィールドの操作
nom v を使った複数値フィールドの単⼀値への変換
コマンドを使って、指定した複数値フィールドの値を単⼀の値に変換できます。nomv コマンドは、fields.conf
ファイルの複数値フィールドの設定に優先します。
nomv
この sendmail イベントの例では、senders フィールドの値を単⼀値にまとめます。
eventtype="sendmail" | nomv senders
m akem v を使った複数値フィールドの分割
コマンドを使って、複数値フィールドを複数の単⼀値フィールドに分割できます。この sendmail サーチ結
果の例では、senders フィールドの値を複数のフィールド値に分割します。
makemv
eventtype="sendmail" | makemv delim="," senders
フィールド値を分割したら、他のコマンドに利⽤することができます。たとえば、上位何⼈かの送信者を表⽰する
ことができます。
eventtype="sendmail" | makemv delim="," senders | top senders
m vexpand を使った、複数値フィールドに基づく複数イベントの作成
65
コマンドを使って、複数値フィールドの値をそれぞれの個別のイベントに展開できます。この例では、複
数値フィールド「foo」の各値に対して新しいイベントが作成されます。
mvexpand
... | mvexpand foo
m vcom bine を使った類似イベントからの複数値フィールドの作成
「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 フィールドに単⼀のメールアドレスのみが存在している場合、mvcount(from) は 1 を返し
ます。Cc アドレスが含まれていない場合、イベントに Cc フィールドが存在しない可能性があります。その場
合、mvcount(cc) は NULL を返します。
複数値フィールドからの値のフィルタリング
任意の論理演算式を指定して複数値フィールドをフィルタリングするには、mvfilter() 関数を使⽤しま
す。mvfilter 関数は、⼀度に 1 つのフィールドに対してのみ使⽤できます。
この例で、mvfilter() は最後が
.net
または
.org
で終了する
email
フィールドのすべての値を保持します。
eventtype="sendmail" | eval email=mvfilter(match(email, "\.net$") OR match(email, "\.org$"))
注意 ：この例は、match() 関数も使⽤して、引⽤符内に定義されているパターンを
『サーチリファレンス』 マニュアルの評価機能を参照してください。
email
の値と⽐較しています。
複数値フィールドから値のサブセットを返す
複数値フィールド内の特定の値または値のサブセットを参照するには、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 はそれ⾃⾝が複数値フィールドになります。
統計の算出
統計の算出について
このセクションでは、イベントのサマリー統計の算出⽅法について説明していきます。Splunk のサーチ処理⾔語
(SPL) で統計情報を算出する場合、まず思い浮かぶのが stats コマンドです。stats コマンドは、サマリー統計情
報を表形式で表⽰するレポートを⽣成します。また、chart および timechart コマンドを使って、サマリー統計情報
のグラフ視覚エフェクトを作成することができます。 geostats コマンドを使って、地理的位置情報フィールドを
含むイベントのサマリー統計を、地図視覚エフェクトで表⽰することも可能です。
stats、chart、および timechart
コマンド (およびその関連コマンドの eventstats、geostats、および streamstats)
は、統計関数と連係動作するように設計されています。これらのコマンドおよび関数を使ったサーチの例について
は、「stats コマンドおよび関数の使⽤」を参照してください。
後のトピックでは、以下の事項を取り上げています。
「stats と eval 式および関数の使⽤」による、統計情報の算出
66
「レポートテーブルへのスパークラインの追加」
「⾼度な統計」のセクションには、異常検出、外れ値の検索と削除、パターンの検出、および時系列の予測のト
ピックが含まれています。
st a t s コマンドおよび関数の使⽤
このトピックでは、統計関数を変換コマンド
る⽅法について説明しています。
chart、timechart、stats、 eventstats、および streamstats
で使⽤す
stat コマンドと構⽂の詳細については、『サーチリファレンス』の「stats」コマンドに関する説明を参照し
てください。
stats 関数のリストについては、『サーチリファレンス』の「統計・グラフ関数」を参照してください。
s tats コ マ ン ド お よ び 関 数 に つ い て
stats、 streamstats、
および eventstats コマンドを利⽤して、サーチの結果またはインデックスから取得されたイ
ベントに対してサマリー統計を算出することができます。stats コマンドはサーチ結果全体を処理しま
す。streamstats コマンドは、イベント登場時に、各イベントの統計を順次算出します。eventstats コマンドは、す
べてのサーチ結果の統計を算出し、関連する各イベントに対して集計をインラインに追加します。これらのコマン
ドの違いについては、次のセクションを参照してください。
は、結果をデータ構造で返します。このデータ構造を利⽤して、縦棒、折れ線、⾯、および円グラフ
などの、視覚エフェクトで表⽰することができます。グラフの X 軸に使⽤するフィールドを指定できま
す。timechart command は、結果を時間シリーズのグラフとして返します。このグラフでは、常に時間フィールドと
なる X 軸に対してデータが描画されます。Splunk のビジュアル化機能とオプションについては、『データのビ
ジュアル化』マニュアルの「ビジュアル化リファレンス」を参照してください。
chart command
stats、chart、および timechart
コマンド (およびその関連コマンドの eventstats、および streamstats) は、統計関数
と連係動作するように設計されています。統計関数のリストにより、フィールドの登場頻度をカウントして、
フィールド値の合計、平均、範囲などを計算することができます。
統計関数の⼀覧および使⽤法については、『サーチリファレンス』の「統計・グラフ関数」を参照してください。
Stats 、 ev ents tats 、 お よ び s tr eam s tats
eventstats
および
streamstats
コマンドは、stats コマンドのバリエーションです。
コマンドは、サーチ結果全体を処理して、指定されたフィールドのみを返します。たとえば、以下のサーチ
は 2 つの列 (10 ⾏) を持つテーブルを返します。
stats
sourcetype=access_* | head 10 | stats sum(bytes) as ASumOfBytes by clientip
ASumOfBytes
のサーチは
および clientip フィールドは、stats コマンドの後に存在する唯⼀のフィールドです。たとえば、以下
bytes 列に空のセルを返します (結果フィールドではないため)。
sourcetype=access_* | head 10 | stats sum(bytes) as ASumOfBytes by clientip | table bytes, ASumOfBytes, clientip
結果内に ASumOfBytes および clientip 以外のフィールドを表⽰するには、それらを stats コマンドに含める必要が
あります。また、raw イベント内のオリジナルのフィールドに計算を実⾏したい場合は、stats コマンドの前に実
施する必要があります。
コマンドは stats コマンドと同じ統計を算出しますが、さらに結果を集計してオリジナルの raw データ
に追加します。以下のサーチを実⾏する場合、結果テーブルの代わりにイベントリストが返されます (eventstats
コマンドは raw データを変更しないため)。
eventstats
sourcetype=access_* | head 10 | eventstats sum(bytes) as ASumOfBytes by clientip
コマンドを使って、⽬的のフィールドを表⽰するテーブルとして、結果をフォーマットすることができま
す。bytes (または、raw イベント内の任意のオリジナルフィールド) の値を結果内に表⽰することもできます。
table
sourcetype=access_* | head 10 | eventstats sum(bytes) as ASumOfBytes by clientip | table bytes, ASumOfBytes,
clientip
コマンドも算出した統計をオリジナルの raw イベントに集約しますが、この処理はイベントの発⾒時
に⾏われます。これのデモンストレーションを⾏うには、前のサーチに _time を含めて streamstats を使⽤しま
す。
streamstats
sourcetype=access_* | head 10 | sort _time | streamstats sum(bytes) as ASumOfBytes by clientip | table _time,
clientip, bytes, ASumOfBytes
このサーチは、各 clientip の合計の代わりに (stats と eventstats が返す)、このサーチは発⾒された時間に基づい
て、各イベントの合計を算出します。streamstats コマンドは、既知の時間範囲のイベントをレポートするのに役
⽴ちます。
67
例
例 1
この例は、その⽇の各時間にオンラインとなった新規ユーザー数を表すグラフを作成します。
... | sort _time | streamstats dc(userid) as dcusers | delta dcusers as deltadcusers | timechart sum(deltadcusers)
(または
す。
dc
distinct_count)
関数は、userid の⼀意の値をカウントし、結果フィールド
dcusers
の名前を変更しま
関数の名前を変更しない (例：dc(userid) as dcusers) 場合、結果となる計算は⾃動的に関数呼び出し (例：
dc(userid)) に保存されます。
コマンドは、現在の dcusers の値と、前の dcusers の値の差を探すために使⽤します。次にこの差の合計
の推移がグラフに表⽰されます。
delta
例 2
この例は、フィールドの中央値を算出し、次にフィールドの値が中央値未満のイベント数をグラフ化します。
... | eventstats median(bytes) as medbytes | eval snap=if(bytes>=medbytes, bytes, "smaller") | timechart count by
snap
eventstats は、前のサーチからのすべてのバイト値の中央値を算出するために⽤いられます。
例 3
この例は、計算済みフィールドの標準偏差と分散を算出します。
sourcetype=log4j ERROR earliest=-7d@d latest=@d | eval warns=errorGroup+"-"+errorNum | stats count as
Date_Warns_Count by date_mday,warns | stats stdev(Date_Warns_Count), var(Date_Warns_Count) by warns
このサーチは過去 7 ⽇間のエラーを返し、抽出されたフィールド errorGroup および errorNum から新しい
フィールド warns を作成します。stats コマンドは 2 回使⽤されています。まず、各⽇の警告 (warns) 数を算出
します。次に、その警告 (warns) 数の標準偏差と分散を計算しています。
例 4
計算済みフィールドを、サーチのフィルタパラメータとして使⽤できます。
sourcetype=access_* | eval URILen = len(useragent) | eventstats avg(URILen) as AvgURILen, stdev(URILen) as
StdDevURILen| where URILen > AvgURILen+(2*StdDevURILen) | chart count by URILen span=10 cont=true
この例で eventstats は、 useragent からの URI ⻑の平均と標準偏差を算出するために使⽤しています。次に、こ
れらの数字を取得したイベントのフィルタとして使⽤します。
st a t s と ev a l 式および関数の使⽤
ここでは、stat 内での eval 式と関数の使⽤⽅法について説明していきます。
eval コマンドと構⽂の詳細については、『サーチリファレンス』の eval コマンドに関する説明を参照して
ください。
eval 関数の⼀覧については、『サーチリファレンス』の「評価関数」をご覧ください。
また、このマニュアルの他のセクションにある「フィールドの評価と操作」では、eval コマンドの使⽤⽅法
が解説されています。
例 1： ⼀ 致 し た イ ベ ン ト と の ⼀ 意 の 数
この例では、エラーが発⽣した IP アドレスがカウントされています。これは、特定のエラーコードでフィルタリ
ングを⾏い、stats コマンドで IP アドレスをカウントするために使⽤されるイベントのサーチと類似します。
status=404 | stats dc(ip)
これを実⾏するための eval 式は以下のようになります。
status=404 | stats dc(eval(if(status=404))) AS dc_ip
例 2：フィールドの分類とカウント
メールが .com、
断します。
.net、 .org
ドメインから来ているのか、または他のトップレベルドメインから来ているのかを判
sourcetype="cisco_esa" mailfrom=* | eval accountname=split(mailfrom,"@") | eval from_domain=mvindex(accountname,-1)
| stats count(eval(match(from_domain, "[^\n\r\s]+\.com"))) AS ".com", count(eval(match(from_domain,
"[^\n\r\s]+\.net"))) AS ".net", count(eval(match(from_domain, "[^\n\r\s]+\.org"))) AS ".org", count(eval(NOT
match(from_domain, "[^\n\r\s]+\.(com|net|org)"))) AS "other"
68
このサーチの前半部では、eval コマンドを使って mailfrom フィールドのメールアドレスを分割します。次
に、from_domain を、mailfrom フィールドの @ 記号の後の部分として定義します。
次に結果を stats コマンドに渡します。eval 式の結果数のカウントには、count() 関数を使⽤しています。ここ
で、eval は match() 関数を使って、from_domain とドメインのサフィックスを識別する正規表現を⽐較していま
す。from_domain の値が正規表現と⼀致する場合、各サフィックス (.com、.net、および .org) の count が更新されま
す。その他のドメインサフィックス数は、other としてカウントされます。
これによって、以下の結果テーブルが作成されます。
注意 ： この例は、⽣成されたメールデータ (sourcetype=cisco_esa) を使⽤しています。この例の
sourcetype=cisco_esa をご⾃分のデータの sourcetype 値に、そして mailfrom フィールドをご⾃分のメールアドレス
フィールド名 (例 ：To, From, or Cc) に変更すれば、任意のメールデータに対して利⽤できます。
サーチ結果へのスパークラインの追加
および 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 はこの期間全体に渡って⼼電図のグラフのように⾒えます。
注意 ： テーブル内の各スパークラインには、当該スパークラインで表されているその他のイベントに関連する情
報が表⽰されます。ただし、他のスパークラインに関連する情報ではありません。あるスパークラインのピーク値
69
が他のスパークラインのピーク値と同じである必要はありません。
s tats お よ び c har t コ マ ン ド で の ス パ ー ク ラ イ ン の 使 ⽤
スパークライン機能は常に、chart および stats サーチとともに使⽤します。スパークラインは、これらの 2 つの
サーチコマンド⽤の関数です。それ⾃体はコマンドではありません。スパークラインの機能は、どちらのサーチコ
マンドでも同じです。
注意 ：スパークライン⾃体をダッシュボードグラフの視覚エフェクトとして使⽤することはできません。ただ
し、ダッシュボードパネルにスパークラインを表⽰するテーブル視覚エフェクトを⼊れることは可能です。詳細
は、『データの視覚化』マニュアルの「視覚化リファレンス」を参照してください。
および stats コマンドの詳細、sparkline 関数の構⽂などについては、『サーチリファレンス』マニュアルの
「chart」および「stats」を参照してください。
chart
例：St at s、スパークライン、および地震データ
ここでは、スパークラインを使って地震データに関する追加情報を得るための、stats サーチの使⽤例を説明して
いきます。
この例では、USGS Earthquakes Web サイトからダウンロードした地震データを使⽤しています。USGS
Eart hquake F eeds から最新の CSV ファイルをダウンロードして、それを Splunk への⼊⼒として追加す
ることができます。ただし、フィールド名とフォーマットが、ここの例とは少し異なる場合があります。
ここでは、USGS Earthquakes データを使って過去 1 週間に地震発⽣頻度の⾼かった地域を表⽰します。また、
各地域における地震の平均マグニチュードを表す列も追加します。以下のサーチを使⽤することができます。
source=usgs | 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=usgs | stats sparkline(avg(Magnitude),6h) as magnitude_trend, count, avg(Magnitude) by Region | sort count
このサーチは各地域において、スパークラインの各セグメント内で発⽣した地震の平均マグニチュードを表すス
パークラインを⽣成します。
ただしそれだけではありません。スパークラインをより⼩さな時間単位に分割します。前のテーブル例では、ス
パークラインが⽇単位に分割されていました。スパークライン内の各データポイントは、24 時間の期間における
イベントカウントを表しています。これが、それらのスパークラインが短い理由です。
サーチ⾔語に 6h を追加すると、この設定がデフォルト値に優先され、スパークラインが 6 時間単位で表⽰されま
す。こうすることにより、指定期間内の各イベントの分布がより把握しやすくなります。
また、このサーチではスパークラインの列名をより分かりやすい、「magnitude_trend」(マグニチュードの傾向)
に変更します。
70
ここでは、Andreanof Islands で発⽣した地震のマグニチュードがほぼ同じなのに対して、Puerto Rico で発⽣
した地震はマグニチュードの強弱にかなりのばらつきがあることが分かります。また、Central California では⽐
較的弱い地震が 7 ⽇間の期間の最初と最後に発⽣していることが⼀⽬で理解できます。また、前回のサーチで考
えたように Virgin Islands で発⽣する地震が⼀定の頻度で発⽣している訳ではないことが、今回のサーチでは分
かります。また、Southern Alaska の地震は前のテーブルと⽐べてより定期的に発⽣していることが分かりま
す。
⾼度な統計
⾼度な統計について
前のセクションでは、stats、
しました。
eval
を使った基本統計の算出⽅法、およびスパークライングラフの作成⽅法を表⽰
このセクションでは、データ内の異常の検索⽅法について取り上げています。これには異常を特定する外れ値の検
索、またはデータの急騰が含まれる可能性があります。計算、またはグラフによるデータの描画⽅法を不必要に歪
曲させる外れ値を削除する必要があるでしょう。イベントの類似度合いを基に分類して、データのパターンを検出
することができます。モニターしているイベントに何かパターンや相関が存在している場合、それを使って将来の
アクティビティを予測することができます。このような知識を活⽤し、閾値に基づくプロアクティブなアラートを
送信したり、「what-if」分析を⾏って各種シナリオを⽐較できます。⾼度な統計を使って、これらすべて、およ
びそれ以上のことが可能です。
⾼度な統計のためのコマンド
異常検出について
外れ値の検索と削除
異常の検出
パターンの検出
時系列の予測
マシン学習ツールキットとショーケース
関連項⽬
stats コマンドおよび関数の使⽤
stats と eval 式および関数の使⽤
レポートテーブルへのスパークラインの追加
⾼度な統計のためのコマンド
ここでは、⾼度な統計の実⾏に利⽤できる多数のコマンド群について学習していきます。次のテーブルには、こう
したコマンドがカテゴリ別に整理されています。
異常を検出するコマンド
データの異常を検索するには、これらのコマンドを使⽤します。⼀般的ではないまたは範囲外のイベントとフィー
ルドのサーチ、または同様のイベントのクラスタ化をすることができます。
コマンド
説明
analyzefields
他の離散型フィールドを予測できるかどうか、数値フィールドを分析します。
anomalies
イベントの「unexpectedness」(意外さ) スコアを算出します。
anomalousvalue
不正な、または異常なサーチ結果を探します。
anomalydetection
各イベントで確率を計算し、極端に確率が低い異常なイベントを特定します。
71
cluster
類似イベントをグループ化します。
kmeans
平均値を使って各クラスタを定義し、イベントを、 k クラスタへパーティション
分割します。各イベントは最寄りの平均値を使ってクラスタに所属しています。
outlier
範囲外の数値を削除します。
rare
フィールドの⼀番少ない値を表⽰します。
予測と傾向に関するコマンド
これらのコマンドは将来の値を予測し、視覚エフェクトの作成に利⽤できるトレンド線を計算します。
コマンド
説明
predict
時系列の将来の値を予測します。
trendline
フィールドの移動平均を算出します。
x11
繰り返されるパターンを削除することで、時系列の傾向を探します。
レポートのためのコマンド、グラフ、地図
これらのコマンドは、変換サーチ の作成に使⽤されます。これらのコマンドは、グラフやその他の視覚エフェク
トに必要な統計データテーブルを返します。
コマンド
説明
addtotals
各結果のすべての数値フィールドの合計を算出します。
contingency
2 つのフィールドの値の分割表、共起相関関係マトリックスを作成します。
correlate
異なるフィールドの相関関係を算出します。
eval
数式、⽂字列式、論理式を算出します。値を新しいフィールドに保管します。
eventstats
すべてのサーチ結果に、サマリー統計情報を追加します。
geostats
地理情報データを表⽰してマップ上のデータを要約するための統計を⽣成しま
す。
outlier
範囲外の数値を削除します。
rare
フィールドの⼀番少ない値を表⽰します。
stats
平均、計数、合計など、結果セットの集計統計を計算します。
streamstats
各サーチ結果に対する直前のイベントについての統計情報を追加します。
timechart
時系列グラフと対応する統計情報テーブルを作成します。『サーチリファレン
ス』の「統計およびグラフ関数」を参照してください。
trendline
フィールドの移動平均を算出します。
異常検出について
このセクションでは、異常検出について説明しています。異常検出、外れ値の検索と削除、パターンの検出、時系
列の予測についてのトピックの完全リストは、このマニュアルの「⾼度な統計について」を参照してください。
異常検出の概要
異常はシステムの想定される動作からの偏差です。異常は以下の可能性があります。
単⼀のイベント
⼀連のイベント
⼀連のトランザクション
複雑なパターン
異常検出の⼀般的な使⽤事例には、以下の事項が含まれています。
72
業界
使⽤事例
IT
IP 範囲からの分散型サービス拒否 (DDoS) 攻撃の識別
マーケ
ティン
グ
稀ではあるが⾼価値顧客の購⼊パターン
製品
既知の⽅法よりもより良い結果、またはより⾼い効率性をもたらす製品を使った、稀な、またはこれ
まで知られていなかった⽅法。
⼈間より早いトランザクション。トランザクションが、他の⼈よりも⼀⼈のユーザーにより迅速に⾏
security われている場合の検出。ボットまたはセキュリティ対策を調査する試みを⽰している可能性がありま
す。
効果的な異常検出
効果的な異常検出を実⾏するために、すべてのデータを⼀箇所に保管してください。マシンやビジネスデータが同
じ場所にない場合は、総合的な分析を実⾏することができません。
IT およびビジネスパフォーマンス測定基準のトラッキングを開始します。また、現在のシステムの状態を表⽰す
るベースラインデータ画像を作成します。
関連項⽬
⾼度な統計、外れ値の検索と削除、異常検索について。
外れ値の検索と削除
このセクションでは、外れ値について説明しています。異常検出、外れ値の検索と削除、パターンの検出、時系列
の予測についてのトピックの完全リストは、このマニュアルの「⾼度な統計について」を参照してください。
外れ値とは
外れ値は、データポイントの⼀般的な分散とは程遠いデータポイントです。
状況によっては、単に外れ値を識別する必要があるでしょう。他の状況では、統計的結果を歪曲させる、またはグ
ラフのデータ表⽰に問題を発⽣させる外れ値を削除する必要があるでしょう。
統計的外れ値
統計的外れ値は、⼀部の中⼼性の測定とは程遠いデータポイントです。典型的な中⼼性の測定は、平均値、中央値
およびモードです。平均値とは平均の値です。中央値とは、すべての値のソートされたリストの中間の値です。
モードとは、最も頻度の⾼い値です。
中⼼性の測定 Splunk 中⼼性コマンド
平均値
stats avg(field)
中央値
stats median(field)
モード
stats mod(field)
異なるタイプの統計的外れ値が存在します。外れ値は平均値、中央値から程遠い、またはモードとの少数の相対で
ある可能性があります。外れ値は、データポイントの⼀般的な範囲とは程遠いデータポイントです。
外れ値の識別
外れ値を識別するいくつかの⽅法があります。これらの⽅法は頻繁に、⼀部の中⼼性の測定の算出、その後の外れ
値の識別が含まれます。
場合によって、異常に気づいたときに外れ値が特定されます。たとえば、データをグラフ化する際に軸が歪曲して
73
いることに気づいた場合。外れ値が原因である可能性があります。
統計的外れ値の数を指標として使⽤します。通常より多くの統計的外れ値が表⽰された場合、その現象⾃体が異常
です。
次のコマンドを使⽤して、現在の測定を算出することができます。
中⼼性の測定
Splunk 中⼼性コマンド
標準偏差
stats stdev(field)
四分位とパーセンタイル
stats perc75(field) perc25(field)
上位3つの最も頻繁な値
top 3 field
多くの場合、探している情報を算出ために追加のコマンドが必要です。次のセクションには、これらのいくつかの
例が含まれています。
外れ値を識別するための許容範囲の上限と加減の境界の算出
以下の例は quote.csv ファイルから最初の 500 のイベントを取ります。streamstats コマンド、および 100 のイベ
ントの移動ウィンドウは、平均と標準偏差を算出するために使⽤しています。平均と標準偏差は、上限と加減の境
界を算出する eval コマンドと⼀緒に使⽤します。感度は、stdev を 2 乗して算出に追加されます。eval コマンド
は、それらの境界を使⽤して外れ値を識別します。外れ値はその後降順にソートされます。
| inputlookup quote.csv | head 500 | eval _time=(round(strptime(time, "%Y-%m-%d %H:%M:%SZ"))) | streamstats
window=100 avg("price") as avg stdev("price") as stdev | eval lowerBound=(avg-stdev*2) | eval
upperBound=(avg+stdev*2) | eval isOutlier=if('price' < lowerBound OR 'price' > upperBound, 1, 0) | fields "_time",
"symbol", "sourcetype", "time", "price", "lowerBound", "upperBound", "isOutlier" | sort - isOutlier
四分位範囲 (IQR) を 使⽤した外れ値の識別
以下の例は quote.csv ファイルから最初の 500 のイベントを取ります。eventstats コマンドは、数値フィールドの
25 位パーセンタイルと 75 位パーセンタイルの中央値を算出するために使⽤されます。IQR は、eval コマンドを
使⽤してパーセンタイルを減算することで算出されます。中央値と IRQ は、上限と加減の境界を算出する eval コ
マンドと⼀緒に使⽤されます。感度は、IQR を 20 乗して算出に追加されます。eval コマンドは、それらの境界を
つかって外れ値を識別します。外れ値はその後降順にソートされます。
| inputlookup quote.csv | head 500 | eval _time=(round(strptime(time, "%Y-%m-%d %H:%M:%SZ"))) | eventstats
median("price") as median p25("price") as p25 p75("price") as p75 | eval IQR=(p75-p25) | eval lowerBound=(medianIQR*20) | eval upperBound=(median+IQR*20) | eval isOutlier=if('price' < lowerBound OR 'price' > upperBound, 1, 0) |
fields "_time", "symbol", "sourcetype", "time", "price", "lowerBound", "upperBound", "isOutlier" | sort - isOutlier
グラフ内の外れ値の削除
outlier コマンドを使⽤して、サーチ結果から範囲外の数値を削除することができます。
外れ値からイベントを削除または変換するオプションがあります。remove オプションはイベントを削除しま
す。transform オプションは、外れ値をその閾値に切り捨てます。閾値は、param オプションを使って指定されま
す。
値が四分位範囲 (IQR を乗じた) param 閾値の範囲を超えている場合、外れ値であると考えられます。param のデ
フォルト値は 2.5 です。
web server イベントのグラフの作成、範囲外の値の変換
例1：web server イベントの時間グラフで、範囲外の平均 CPU 値を変換します。
host=''web_server'' 404 | timechart avg(cpu_seconds) by host | outlier action=transform
グラフのY 軸の表⽰を使った⼲渉する外れ値の削除
グラフを作成する場合、少数の値は、グラフが読み取り不能な他の値から程遠いこともあります。グラフの値が表
⽰されるように外れ値を削除することができます。
index=_internal source=*access* | timechart span=1h max(bytes) | fillnull | outlier
トランザクションにまたがる 3 シグマを使⽤した外れ値の削除
この例は、標準偏差を算出するために eventstats を使⽤しています。3 シグマ制限はその後算出されます。where
コマンドは、サーチ結果をフィルタリングします。3 シグマ制限以下の持続時間を持つイベントのみが返されま
す。
... | eval durationMins = (duration/60) | eventstats avg(durationMins) as Avrg, stdev(durationMins) as StDev | eval
threeSigmaLimit = (Avrg + (StDev * 3)) | where durationMins < threeSigmaLimit
外れ値のアラート管理
74
アラートを設定する際に、設定した外れ値の閾値を確認することが重要です。
* 閾値が低すぎる場合、あまりにも多くのアラート値が⾮クリティカルの外れ値として返されます。
* 閾値が⾼すぎる場合、⼗分なアラートが返されず、外れ値を識別できない可能性があります。
⼀般的に、データ内のほんの少しのイベントが外れ値です。1 ⽇に 1,000,000 のイベントがあり、5% のイベント
が外れ値の場合、抑制条件を指定しない限り、アラートの設定は 50,000 のアラートアクションを⽣成します。抑
制条件は、与えられた時間範囲で同じフィールド値を持つ追加のアラートを抑制します。
たとえば、サーチが毎分平均 100 のイベントを返す場合を考えます。イベントのステータスが 404 の場合のみに
アラートを実⾏場合は以下を⾏います。各イベントに対し、60 秒のウィンドウで 404 ステータスを持つすべての
イベントに対してアラートアクションを実⾏する代わりに、60 秒おきに⼀度のアラートアクションを実⾏するよ
うにアラートを設定することができます。
アラート抑制機能の設定
アラート設定の⼀部として抑制機能を設定します。
1. 何パーセントのイベントが外れ値であるかを特定します
2. [設定 ] で、 [サーチ、レポート、アラート ] を選択します。
3. [スケジュールとアラート] で、 [このサーチをスケジュール ] チェックボックスをクリックします。画⾯
にスケジュール/アラートオプションの表⽰が拡張されます。
4. アラート条件およびモードを指定します。
5. [抑制機能 ] チェックボックスをマークし、 抑制機能の有効期限を指定します。
6. アラートアクションを指定します。
7. [保存 ] をクリックします。
関連項⽬
⾼度な統計について
SPL コマンド：outlier、stats、 top
異常の検出
データの急騰の検索
データの急騰を識別する場合は以下を⾏います。急騰は、⼀部の数値の急激な上昇または減少を⽰すピーク (また
は⾕) があるところに表⽰することができます。以下が全ての種類の急騰です。トラフィック急騰、売上急騰、返
される数、データベース負荷の急騰関⼼のあるどの急騰のタイプにおいても、それを監視し、おそらくそれらの急
騰に対処するための作業を⾏う必要があるでしょう。
移動トレンドラインを使⽤して、急騰の表⽰を容易に⾏うことができます。サーチを実⾏します。この後、そのた
めのトレンドラインを作成するフィールドを使⽤した trendline コマンドが続きます。
たとえば、Web アクセスデータでは、bytes フィールドの平均値をグラフ化できます。
sourcetype=access* | timechart avg(bytes) as avg_bytes
の最後5つの値の単純移動平均 (sma) に使われる別の折れ線または横棒シリーズをグラフに追加するには、
以下のコマンドを使⽤します。
bytes
... | trendline sma5(avg_bytes) as moving_avg_bytes
急騰を明確に識別する場合、急騰に使われるさらなるシリーズを追加する必要があるでしょう。以下のサーチは、
バイトの平均数が移動平均の 2 倍を超えた場合に⽰す、「急騰」と呼ばれるフィールドを追加します。
... | eval spike=if(avg_bytes > 2 * moving_avg_bytes, 10000, 0)
ここで 10000 は任意であり、急騰を顕著に表すデータに関連する値を選択する必要があります。スケールをログ
に記⼊するには、Y 軸の書式設定を変更しても効果があります。
以上の事項をまとめると、サーチは以下のようになります。
sourcetype=access* | timechart avg(bytes) as avg_bytes | trendline sma5(avg_bytes) as moving_avg_bytes | eval
spike=if(avg_bytes > 2 * moving_avg_bytes, 10000, 0)
このサーチは、最後5つの値の単純移動平均 (sma5) を使⽤します。急騰の識別に使う最⾼の単純移動平均を指定
するために、異なる単純移動平均値を使⽤して探索します。
trendline のコマンドは、指数移動平均（ema）と加重移動平均（wma）もサポートしています。
あるいは、結果をフィルタリングするためにグラフをバイパスし、
ことができます。
75
eval
コマンドを
where
コマンドに置き換える
... | where avg_bytes > 2 * moving_avg_bytes
あるいは、テーブルビューを参照またはアラートを設定することで、いつ
ができます。
avg_bytes
が急騰したかを表⽰すること
関連項⽬
⾼度な統計、 eval、 trendlineについて
パターンの検出
このセクションでは、データ内のパターンの検出について説明しています。異常検出、外れ値の検索と削除、時系
列の予測についてのトピックの完全リストは、このマニュアルの「⾼度な統計について」を参照してください。
イベント内のパターンの検出
クラスタコマンドは、イベント内のパターンを検出する強⼒なコマンドです。コマンドは、相互の類似度に基づい
てイベントをグループ化します。cluster コマンドは、他のフィールドを指定しない限り、 _raw フィールドのコン
テンツに基づくイベントをグループ化します。
cluster
コマンドを使⽤する場合、2 つの新しいフィールドが各イベントに追加されます。
は、クラスタの⼀部となるイベント数です。これはクラスタサイズです。
は、どのクラスタにイベントが所属するかを指定します。たとえば、サーチが 10 件のクラス
タを返す場合、クラスタには 1〜10 のラベルが付けられます。
cluster_count
cluster_label
イベントの⼩規模、または⼤規模なグループ （またはクラスタ） から到着する異常⼩規模なグループには、ユー
ザーからの 1 つまたは 2 つのログインイベントが含まれている可能性があります。イベントの⼤規模なグループ
は、何千もの類似イベントの DDoS 攻撃になる可能性があります。
クラスタコマンドパラメーターの賢明な使⽤
パラメーターを使⽤して、すべてのイベントを返します。デフォルトである labelonly=false
を使⽤する場合、各クラスタから 1 つのイベントのみ返されます。
showcount=true パラメーターを使⽤することで、 cluster_count フィールドがすべてのイベントに追加されま
す。デフォルトである showcount=false 場合、イベントにはイベントカウントが追加されません。
閾値 t パラメーターは、クラスタの感度を調整します。より⼩規模な閾値は、より少ない数のクラスタで
す。
labelonly=true
クラスタコマンドを使⽤する他のコマンド
「Cluster_label」列の dedup コマンドを使って、各クラスタ内でグループ化された最新のイベントを表⽰
します。
イベントをグループ化し、より把握しやすい結果を作成するには、クラスタ列を使った sort コマンドを使
⽤します。クラスタ数に基いて「Cluster_count」列を並べ替えます。
⼩規模なイベントグループに対しては、昇順で cluster_count を並べ替えます。
⼤規模なイベントグループに対しては、降順で cluster_count を並べ替えます。
昇順で cluster_label 列を並び替えます。クラスタラベルは数値です。降順での並び替えは、数値的順
序でラベルごとにイベントを編成します。
各 ク ラ ス タ の 3つ の 最 新 イ ベ ン ト を 返 す
ファイルの CustomerID は、以下のサーチで使われます。showcount=true の設定は、すべてのイ
ベントが cluster_count を所得することを有効にします。クラスタ閾値は 0.7 に設定されます。labelonly=true の設
定は、到着したイベントを返します。dedup コマンドは、各クラスタ内の3つの最新イベントを表⽰するために使⽤
します。結果はイベントをグループ化するために降順で並び替えられます。
sales_entries.log
source="/opt/log/ecommsv1/sales_entries.log" CustomerID | cluster showcount=true t=0.7 labelonly=true | table _time,
cluster_count, cluster_label, _raw | dedup 3 cluster_label | sort -cluster_count, cluster_label, - _time
labelonly=true
を設定しなかった場合、各クラスタから1つのイベントのみ返されます。
関連項⽬
⾼度な統計、 dedup、 cluster、 sort について
時系列の予測について
さまざまな⽅法で、時系列データを予測することができます。例：
仮想環境のハードウェア要件を判断し、エネルギー消費を予測するための、キャパシティプランニング
業績予測およびその他のビジネス指標
システム障害を検出し、機能停⽌の防⽌する、主要コンポーネントのモニタリングの強化
レポートやダッシュボードを使⽤して、発⽣するアクティビティをモニターリングし、そのイベントにドリルダウ
ンして、何が起きているのかを調査する主原因分析を⾏うことができます。モニターしているイベントに何かパ
76
ターンや相関が存在している場合、それを使って将来のアクティビティを予測することができます。このような知
識を活⽤し、閾値に基づくプロアクティブなアラートを送信したり、「what-if」分析を⾏って各種シナリオを⽐
較できます。
時系列の予測に使⽤するコマンド
Splunk のサーチ⾔語には、predict と x11 の 2 種類の予測コマンドが⽤意されています。
predict コマンドでは、異なる予測アルゴリズムを利⽤して、単⼀値および複数値フィールドの将来の値を
予想します。
X11 アルゴリズムにちなんで名付けられた x11 コマンドは、フィールド内の時期的変動を排除してデータシ
リーズの実際の傾向を明らかにします。
予測アルゴリズム
コマンドではアルゴリズムとして LL、LLP、LLT、LLB および LLP5 を選択できます。これらのアルゴリ
ズムは、Kalman フィルターのバリエーションです。
predict
アル
ゴリ
ズム
のオ
プ
ショ
ン
アルゴ
リズム
名
LL
ローカ
ルレベ
ル
これは⼀変量モデルで、傾向もシーズンもありません。最低 2 つのデータポイントが必要で
す。
LLP
シーズ
ンに合
わせた
ローカ
ルレベ
ル
シーズンを持つ⼀変量モデル。時系列の周期性は⾃動的に算出されます。周期の 2 倍以上の
データポイントが必要です。
LLT
ローカ
ルレベ
ル傾向
これは⼀変量モデルで、傾向を考慮しますがシーズンは考慮しません。最低 3 つのデータポイ
ントが必要です。
LLB
⼆変量
ローカ
ルレベ
ル
これは⼆変量モデルで、傾向もシーズンもありません。最低 2 つのデータポイントが必要で
す。LLB は、1 つのデータセットを使って、別の予測を⾏います。たとえば、それがデータ
セット Y を使ってデータセット X の予測を⾏う場合を考えてみましょう。holdback=10 の場
合、 LLB アルゴリズムは Y の最後の 10 件のデータポイントを使って、X の最後の 10 件の
データポイントの予測を⾏います。
LLP5
説明
LLT と LLP モデルを組み合わせて予測を⾏います。
詳細は、『サーチリファレンス』 の predict コマンドを参照してください。
x11 コマンドを使ったシーズナリティの予測
時系列データのシーズンコンポーネントは、加法的または乗法的であります。Splunk Enterprise では、x11 で計
算を⾏うための 2 種類のシーズナリティとして反映されています。加法的な場合は add() を、乗法的な場合は
mult() を使⽤します。
データの調整にどちらのシーズナリティを使⽤するかは、どうやって判断すれば良いのでしょうか？加法的シーズ
ナリティコンポーネントと乗法的シーズナリティコンポーネントの違いの例を⾒ていきましょう。たとえば、年間
の花の売り上げは、バレンタインデーや⺟の⽇など、特定の⽇やその前後にピークに達します。
バレンタインデーの場合、バラの花の売り上げは毎年 X ドル増加すると考えられます。このドル量は時系列の標
準レベルとは独⽴しており、毎年のバレンタインデーの予測には X ドルを追加することができるため、この時系
列は加法的季節調整の候補となります。加法的季節調整では、当該シーズンにおいて標準とは異なる値の絶対量を
表す数量を、加算または減算することで、時系列の各値が調整されます。
あるいは、⼀⽅乗法的シーズンコンポーネントでは、そのシーズンの影響⾃体がパーセンテージで表現されます。
季節的変動の絶対量は、時間の経過に伴う時系列の増加とともに増加していきます。たとえば、バレンタインデー
に販売されるバラの数が 40% または係数 1.4 増加すると考えられます。普段バラの売り上げが少ない場合、バレ
ンタインデー時の売り上げ増加の絶対値 (ドル)も⽐較的少なくなります。ただし、パーセンテージは⼀定です。バ
ラの売り上げが多い場合、絶対値 (ドル) の増加は⽐例的に⼤きくなります。乗法的季節調整では、⼀般的にその
シーズンに観察される標準からの、または係数で割ったパーセンテージで各時系列の各値を除算することで、この
パターンを排除することができます。
これらの 2 種類のシーズンコンポーネントをグラフに描画した場合、その特徴が際⽴ちます。
加法的シーズン時系列は、シリーズの総合的なレベルに関係なく安定した季節変動を表しています。
乗法的シーズン時系列は、シリーズの総合的なレベルに応じた、サイズの異なる季節変動を表しています。
詳細は、『サーチリファレンス』 の x11 コマンドを参照してください。
関連項⽬
77
⾼度な統計、 predict、 x11について
マシン学習
このセクションでは、マシン学習ツールキットとショーケースを説明しています。異常検出、外れ値の検索と削
除、パターンの検出、時系列の予測についてのトピックの完全リストは、このマニュアルの「⾼度な統計につい
て」を参照してください。
マシン学習ツールキットとショーケース
マシン学習ツールキットとショーケースアプリケーションは、さまざまな種類マシン学習の概念を探索するための
ダッシュボードや例を提供します。各ダッシュボードには、埋め込まれたデータセットを使ったエンドツーエンド
の例が含まれています。しかし、独⾃のデータにショーケースを適⽤することができます。
ショーケースパネルおよび基盤となるコードをを調査して、それがどのように作動するかを表⽰させた後、ご⾃分
のニーズに合わせたカスタムダッシュボードを作成することができます。
イベントのグループ化と相関
イベントのグループ化と相関について
イベントの相関は、「あるイベントの発⽣からどれくらい時間が経過したのか？」や「処理にどれくらいの時間を
要したのか？」などの疑問に答えるために、複数のソースからのデータ内に存在する、⼀⾒無関係に⾒えるイベン
ト間の関係を探すことです。
Splunk Enterprise は、時間と地域、場所、トランザクション、サブサーチ、フィールドルックアップ、および結
合を使ったイベントの相関をサポートしています。
時間の近接性やイベントの地域に基づいて、関係を識別します。この相関は、特定の期間や場所で発⽣した
すべてのイベントまたはその⼀部を参照する必要がある、セキュリティまたは運⽤の調査に使⽤します。
たとえば、複数の IT システムやデータソースから来る、⼀連の関連するイベントを、単⼀のトランザク
ションとして追跡します。トランザクションの完了に要した時間、および単⼀のトランザクション内のイベ
ント数を識別します。
あるサーチの結果を引き継ぐサブサーチを使⽤して、それを別のサーチで使⽤します。サブサーチが特定の
閾値を満たす場合にのみサーチ結果を表⽰する、条件サーチを作成します。
ルックアップを使って、データと外部ソースを相関させます。
SQL のような内部結合と外部結合を使って、1 つまたは複数の共通フィールドに基づき、まったく異なる 2
つのデータセットをリンクします。
この章では、イベントの相関またはグループ化に利⽤できる 3 種類の⽅法について説明していきます。
時間を使ったイベント間の関係の識別
サブサーチを使ったイベントの相関
トランザクションを使った関連イベントの識別とグループ化
フィールドルックアップやサーチ⾔語のその他の機能を使⽤することもできます。サーチ基準やグループ化の⽅法
に応じて、append、associate、contingency、join、または stats などのサーチコマンドを使⽤できることもあ
ります。場合によっては、使⽤できる単⼀コマンドがないこともあります。
何から始めてよいのか分からない場合は、以下のフローチャートを参考に、イベントの定義にルックアップを使⽤
する、トランザクションを定義する、または他のサーチコマンドを使⽤するなどを判断してください。
78
たいていの場合は、stats コマンドや transaction が役⽴ちます。また、join や append を使⽤するのではなく、こ
れらのコマンドを使⽤することをおすすめいたします。stats および transaction の使⽤時期の詳細については、こ
の章の後半にある「トランザクションについて」を参照してください。stats コマンドの詳細は、このマニュアル
の「統計の算出」を参照してください。
注意 ：この図の情報は、Nick Mealy によるものです。
時間を使ったイベント間の関係の識別
時間は、問題を判断するために必要不可⽋な情報で、この情報は既知であることもしばしばです。Splunk では、
イベント内のベースラインパターンまたは傾向を判別して、それを現在のアクティビティと⽐較することができま
す。
⼀連の時間ベースのサーチを実⾏し、異常なアクティビティを調査、特定し、その後タイムラインを使ってその特
定の期間にドリルインすることができます。同時刻に発⽣したイベントを調査することで、結果間の相互関係を⾒
つけ出し、主原因を特定する⼿がかりにできるかもしれません。
詳細は、このマニュアルの「タイムラインを使ったイベントの調査」を参照してください。
トランザクションについて
トランザクション は、⼀定期間において概念的に関連したイベントのグループです。たとえば、1 ⼈の顧客によ
るホテルの客室オンライン予約に関する⼀連のイベントや、ファイアウォール侵⼊事件に関連する⼀連のイベント
などがトランザクションにあたります。トランザクションタイプ は、設定されたトランザクションで、フィール
ドとして保存されています。また、transaction コマンドと⼀緒に使⽤されます。任意の数のデータソースが、複
数のログエントリにまたがってトランザクションを⽣成できます。
トランザクションサーチ
トランザクションサーチは、ログに記録された複数のイベントにまたがる任意の物理イベントに注⽬する場合に役
⽴ちます。transaction コマンドを使って、トランザクションを定義したり、 transactiontypes.conf に設定されて
いるトランザクションオプションに優先する設定を使⽤したりすることができます。
⼀般的にトランザクションサーチ は、複数のイベントを単⼀の物理イベントを表す、単⼀のメタイベントにグ
ループ化する場合に⽤いられます。たとえば、メモリー不⾜の問題 により複数のデータベースイベントがログに
記録された場合に、それらをまとめてトランザクションにグループ化することができます。
詳細は、このマニュアルの「イベントの識別とトランザクションへのグループ化」を参照してください。
ト ラ ン ザ ク シ ョ ン の 代 わ り に s tats を 使 ⽤ す る 場 合
stats コマンドと transaction コマンドは、フィールド値に基づいて個別のイベントを集計できる点で似ていま
す。
79
コマンドは 1 つまたは複数のフィールドでグループ化されたイベントの統計を算出して、イベントを破棄す
る (eventstats または streamstats を使⽤する場合を除きます) ⼿段となっています。⼀⽅、最初と最後のイベン
ト間の期間およびイベント数を除いて、transaction コマンドはグループ化されたイベントの統計を算出しませ
ん。また、オリジナルのイベントからの raw イベントとその他のフィールド値を保持し、より複雑な基準 (期間ま
たは遅延でグループ化し、⽤語を要求してグループの開始/終了を定義するなど) を使ってイベントをグループ化
することができます。
stats
transaction
は、2 つの特殊な事例で特に役⽴ちます。
1. (1 つまたは複数のフィールドからの) ⼀意の ID 単独では、2 つのトランザクションを区別するのに⼗分ではな
い場合。これは、ID が再利⽤される場合の事例です (例：cookie またはクライアント IP で識別される Web セッ
ション)。この場合、期間や中断を設定し、データをトランザクションにセグメント分割することができます。他
の例として、DHCP ログなどで ID が再利⽤される場合に、特定のメッセージがトランザクションの開始または終
了を⽰すことがあります。
2. イベントを構成するフィールドを分析するのではなく、raw イベントのテキストを参照したい場合。
⼀般的に他の事例では、特に分散環境で効率的に動作する stats コマンドを使⽤する⽅がお勧めとなります。しば
しばイベントには⼀意の ID が存在しており、stats を使⽤することができます。
たとえば、⼀意の ID trade_id で識別される、取引期間の統計を算出する場合、次のサーチは同じ結果を⽣成しま
す：
... | transaction trade_id | chart count by duration span=log2
および
... | stats range(_time) as duration by trade_id | chart count by duration span=log2
しかし、
策は次の
trade_id
の値が再利⽤されるけれども、各取引は「END」などのテキストで終了する場合、唯⼀の解決
サーチを使⽤することです：
transaction
... | transaction trade_id endswith=END | chart count by duration span=log2
⼀⽅、
す：
trade_id
の値が再利⽤されるけれども、10 分の期間内ではない場合は、次の
transaction
サーチを使⽤しま
... | transaction trade_id maxpause=10m | chart count by duration span=log2
詳細は、前述の「イベントのグループ化と相関」を参照してください。
トランザクションおよびマクロサーチ
トランザクションおよびマクロサーチは強⼒な組み合わせで、トランザクションサーチ内で代替を⾏うことができ
ます。代替を⾏うには、トランザクションサーチを実⾏して、それを $field$ で保存します。
マクロサーチとトランザクションの使⽤例については、『ナレッジ管理』マニュアルの「サーチマクロの作成と編
集」を参照してください。
イベントの識別とトランザクションへのグループ化
Splunk Enterprise では、関連するイベントをサーチして、それを「トランザクション (またはセッション)」と呼
ばれる単⼀のイベントにグループ化することができます。
トランザクションには、以下の項⽬を含めることができます。
同じソース、同じホストからの異なるイベント
同じホストの異なるソースからの異なるイベント
異なるホスト、異なるソースからの類似イベント
トランザクションのサーチは、Splunk Web または CLI で transaction サーチコマンドを使って⾏いま
す。transaction コマンドは、レポートに使⽤することができる、グループ化されたイベントを⽣成しま
す。transaction を使⽤するには、トランザクションタイプ (transactiontypes.conf で設定) を呼び出すか、また
は transaction コマンドにサーチオプションを設定して、サーチ内にトランザクション制約を定義します。
tr ans ac ti o n の サ ー チ オ プ シ ョ ン
サーチ時に返されるトランザクションは、各イベントの raw テキスト、共有イベントタイプ、およびフィールド
値から成り⽴っています。トランザクションには、duration および transactiontype フィールドに保存される追加
データも存在しています。
には、トランザクションの期間が含まれています (トランザクション内の最初と最後のイベントのタ
イムスタンプの差)。
transactiontype はトランザクション名です (transactiontypes.conf にトランザクションのスタンザ名で定義)。
duration
は任意のサーチに追加できます。最良のサーチパフォーマンスを確保するために、適切なサーチを作
成して、それをパイプ⽂字で transaction コマンドに渡してください。詳細は、『サーチリファレンス』マニュ
アルの「transaction」を参照してください。
transaction
80
コマンドに続けて、以下のオプションを指定できます。注意 ：⼀部の
オプションと⼀緒に指定することはできません。
transaction
transaction
オプションは、他の
name=<transaction-name>
のスタンザ名を指定します。これを使って、再利⽤のために設定したトランザクショ
ンタイプ を呼び出します。他の引数が指定されている場合、それらはトランザクションルールに指定されて
いる同じ引数の値に優先されます。たとえば、web_purchase の場合、呼び出すトランザクションルールに
maxevents=10 が設定されているけれども、別の maxevents 値で実⾏したい場合は、サーチ⽂字列に⽬的の値を
指定した maxevents を追加してください。
transactiontypes.conf
sourcetype=access_* | transaction name=web_purchase maxevents=5
[field-list]
次のような、 ...| transaction host,cookie フィールドのカンマ区切りリストです：
設定した場合、同じトランザクション内にあるイベントと判断するには、各イベントに同じフィールドがな
ければなりません。
共通のフィールド名で異なる値を持つフィールドはグループ化されません。
たとえば、 ...| transaction host を追加した場合、 host=mylaptop を持つサーチ結果が host=myserver を
持つサーチ結果と同じトランザクションになることはありません。
host の値を持たないサーチ結果は、 host=mylaptop を持つ結果と同じトランザクションになる可能性が
あります。
match=closest
トランザクション定義で使⽤するマッチタイプを指定します。
現在のところ、値は closest のみをサポートしています。
maxspan=[<integer>s | m | h | d]
1 つのトランザクションの最⼤期間を設定します。
秒、分、時間、または⽇単位で指定できます。
例：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 フィルタリング式。あるイベントがこの条件を満たすと、新しいトランザクションの終
了としてマークされます。
例：
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> は次の構⽂で定義されます：
(<quoted-search-expression>) | eval(<eval-expression>
は、引⽤符を含まない有効なサーチ式です。
は、引⽤符を含む有効なサーチ式です。
は、論理演算式を評価する有効な eval 式です。
<search-expression>
<quoted-search-expression>
<eval-expression>
例：
サーチ式： (name="foo bar")
サーチ式： "user=mildred"
サーチ式： ("search literal")
eval 論理演算式： eval(distance/time
< max_speed)
81
"<search-expression>" |
トランザクションサーチの例
単⼀のユーザー (またはクライアント IP アドレス) が⼀定期間に参照したすべての W eb ページをグループ
化するサーチを実⾏します。
このサーチはアクセスログからイベントを作成し、同じ clientip 値を共有し、相互の発⽣間隔が 5 分以内のイベ
ントからトランザクションを作成します (3 時間の期間内で)。
sourcetype=access_combined | transaction clientip maxpause=5m maxspan=3h
その他の例については、『サーチリファレンス』マニュアルの トランザクションコマンドの記事を参照してくだ
さい。
ジョブの管理
ジョブとジョブ管理について
サーチの実⾏、ピボットの作成、レポートを開く、またはダッシュボードパネルのロード時には、Splunk
Enterprise システム内でジョブ が作成されます。このジョブには、サーチ、ピボット、レポート、またはパネル
から返されたイベントデータが含まれています。[ジョブ] ページでは、最近使⽤したジョブや以前に保存したジョ
ブを確認することができます。また、Admin または同等の権限を持つロールを保有している場合、[ジョブ] ペー
ジでシステム内のすべてのユーザーのジョブを管理することができます。
[ジョブ] ページにアクセスするには、[アクティビティ] ドロップダウンの [ジョブ ] をクリックします。
[ジョブ] ページの使⽤⽅法の詳細は、『ナレッジ管理』マニュアルの「[ジョブ] ページによるジョブの管理」を
参照してください。
OS のコマンドラインからジョブを管理することもできます。詳細は、このマニュアルの「OS からのサーチジョ
ブの管理」を参照してください。
注意 ：サーチジョブが保存済みサーチや保存済みレポートとは違う物だということに注意してください。レポー
トには、サーチ⽂字列、時間範囲、およびグラフやテーブル視覚エフェクトの書式設定などの、レポートの実⾏に
使⽤されるデータが含まれています。ジョブは、以前に実⾏したサーチやレポートなどの成果物 (結果) です。特
定のサーチ/レポート実⾏の結果が含まれています。ジョブは、スケジュール済みサーチまたはサーチ/レポートの
⼿動実⾏により⽣成されます。
サーチをレポートとして保存する⽅法の詳細は、『レポート』マニュアルの「レポートの作成と編集」を参照して
ください。
ユーザーが実⾏できるジョブの制限
あるユーザーが実⾏できるジョブおよび保管できるジョブ成果物の量を制限するには、そのようにロールを制限し
てそれを⽬的のユーザーに割り当てます。システム内の各ユーザーに⼀意のロールを割り当てることで、きめ細か
く管理することができます。
『管理』マニュアルの authorize.conf ファイルのコピーを作成します。ファイルのコピー
は、$SPLUNK_HOME/etc/system/local ディレクトリに保管します。authorize.conf ファイルで、以下の適切な値を指定
します。
srchDiskQuota:
このロールに所属するユーザーのサーチジョブが利⽤できる最⼤ディスクスペース (MB)。
srchJobsQuota：このロールが利⽤できる同時実⾏サーチの最⼤数。
詳細は、『Splunk Enterprise のセキュリティ』マニュアルの「Splunk Web を使ったロールの追加と編集」を
参照してください。
⻑期実⾏しているジョブの⾃動停⽌
予期せずに⻑期間実⾏されているサーチジョブに対処するために、Splunk Enterprise には⾃動停⽌機能が⽤意さ
れています。デフォルトでこの機能は、ユーザーがうっかりと「全時間」サーチを実⾏してしまった場合に対処す
るために、サマリーダッシュボードのクリックに対してのみ有効になっています。
特定のサーチビューの⾃動停⽌を有効にすると、サーチ中にビューに⾃動停⽌のカウントダウンフィールドが表⽰
されます。サーチの時間制限に達すると、ユーザーにサーチが停⽌されたことを知らせる情報ウィンドウが表⽰さ
れます。このウィンドウから、実⾏を再開したり、サーチを終了したりすることができます。デフォルトでは、
30 秒で⾃動停⽌されます。
82
ジョブの寿命の延⻑
新しいサーチジョブを実⾏する場合、ジョブは、ジョブの寿命と呼ばれる期間に対してシステムに保持されます。
寿命が存続する間、ジョブへのアクセス、およびジョブが返したデータを表⽰することができます。
10 分と7 ⽇間の 2 つの寿命設定があります。デフォルトの寿命は 10 分です。寿命はジョブの実⾏時から開始し
ます。
寿命の⾃動延⻑
アクティブなジョブにアクセスしている場合は常に、寿命がリセットされます。ジョブの寿命が 10 分でも 7 ⽇間
でも、このリセットは⾏われます。
寿命が 10 分に設定されており、午前 11 時にサーチジョブを実⾏した場合、ジョブの寿命は午前 11 時 10
分に終了するように設定されます。再び午前 11 時 7 分にジョブを実⾏した場合、ジョブの寿命は午前 11
時 17 分に終了するようにリセットされます。
ジョブの寿命を 7 ⽇間に設定した後、4 ⽇後にそれにアクセスすると、その寿命はリセットされてその時点
から 7 ⽇間が新たな寿命になります。
寿命はジョブへのアクセス時から延⻑されます。
ジョブの寿命の変更
[ジョブ ]、[ジョブ設定の編集 ] を選択し、ジョブの寿命を指定することで、寿命の設定を変更します。
失効したジョブ
ジョブの時間制限が経過すると、ジョブは失効します。Splunk Enterprise は失効したジョブをシステムから削除
します。
注意 ： ジョブのリストを参照している間にジョブが失効する可能性があります。失効したジョブの寿命を延⻑す
ることはできません。
S pl u nk Web を使ったジョブの保存と共有
サーチの開始後は、[サーチ] ページから移動しなくても、サーチジョブ に関する情報を参照、管理することがで
きます。サーチの実⾏中、⼀時停⽌中、または完了後、[ジョブ ] をクリックして、適切なオプションを選択しま
す。
以下の作業を⾏うことができます。
ジョブ設定の編集： [ジョブ設定] ダイアログボックスを選択すると、ジョブの読み取り権限の変更、ジョ
ブ寿命の延⻑、および URL の取得を⾏うことができます。URL を使⽤して、他の⼈とジョブを共有した
り、ブックマークを Web ブラウザーのジョブに作成することができます。
ジョブをバックグラウンドに送る： サーチジョブの完了までに時間がかかるため、 Splunk Enterprise で
他の作業 (新規サーチジョブの実⾏を含む) を⾏う場合に選択します。ジョブはバックグラウンドで実⾏し続
けます。
ジョブの調査： 別のウィンドウに、[サーチジョブ調査 ] を使ったサーチジョブの情報と測定基準を表⽰し
ます。
ジョブの削除： 現在実⾏中、⼀時停⽌中、または完了したジョブを削除する場合に使⽤します。ジョブを削
除しても、サーチをレポートとして保存することもできます。
サーチジョブ設定の編集
サーチジョブの実⾏、⼀時停⽌、または完了後、[ジョブ設定] ダイアログを開くことができます。単純に [ジョ
ブ ] をクリックして、[ジョブ設定の編集 ] を選択してください。
83
サーチジョブの権限の変更
サーチジョブの読み取り権限は、[ジョブ] ページで他のユーザーがジョブを参照してアクセスできるかどうかを決
定します。デフォルトではすべてのジョブの読み取り権限が [ プライベート] に設定されています。ジョブを実⾏
したユーザーのみが、その結果を [ジョブ] ページで参照できます。
[ジョブ設定] ダイアログには、[読み取り権限 ] スイッチがあり、これを使ってジョブの読み取り権限を [ 全員] に
切り替えることができます。この権限の適⽤範囲はジョブが実⾏された App コンテキストを対象にしているた
め、[ 全員] を設定しても実際にはそのジョブが所属している App に対して読み取り権限を持っているユーザー全
員が、[ジョブ] ページでそのジョブを参照できることになります。
ジョブの所有者であるならば、ジョブの読み取り権限を [ プライベート] に戻すことも可能です。
[ジョブ] ページの詳細は、このマニュアルの「[ジョブ] ページによるジョブの管理」を参照してください。
ジョブの保存
⼀時的にジョブを保存するには、ジョブの寿命を変更することができます。このマニュアルの「ジョブの寿命の延
⻑」を参照してください。
あるいは、サーチをレポートとして保存、または次にしたがってサーチ結果をエクスポートすることができます。
このマニュアルの「サーチアクションの実⾏」を参照してください。
このマニュアルの「サーチ結果のエクスポート」を参照してください。
ジョブの調査
サーチまたはピボットで実⾏したジョブに関連するさまざまな測定基準やプロパティを、[サーチジョブ調査 ] で
確認することができます。[ジョブ ] をクリックして、[ ジョブの調査] を選択すると、別のウィンドウに [サーチ
ジョブ調査] が表⽰されます。
過去のサーチ/ピボット結果が存在している限り (期限が切れていない限り)、そのジョブのサーチジョブ調査にア
クセスすることができます。
サーチジョブ調査およびそれが提供する情報の詳細は、このマニュアルの「サーチジョブ調査によるサーチジョブ
プロパティの表⽰」を参照してください。
84
他のユーザーとのジョブの共有
ジョブのリンクを送信することで、他の Splunk Enterprise ユーザーと素早くジョブを共有することができま
す。他のユーザーにジョブが返した結果を⾒せるような場合に、この⽅法が便利です。これはレポートの共有とは
違うことに注意してください。ジョブを共有すると、特定のサーチ実⾏の結果を共有することになります。
このリンクを取得するには、2 種類の⽅法があります。前述の [ジョブ設定] ダイアログを使⽤する、またはサー
チ/ピボット結果の上に表⽰される共有アイコンを使⽤することができます。共有アイコンを使⽤する場合、その
ジョブの読み取り権限が [ 全員] に⾃動的に設定され、また寿命が 7 ⽇間に延⻑されます。
どちらの⽅法でも、[ ジョブにリンク] が表⽰されます。これをメールに貼り付けて、他の Splunk Enterprise
ユーザーに送信することができます。ただし、[ジョブ設定] ダイアログを使ってリンクを⼊⼿する場合は、ジョブ
の読み取り権限 が [ 全員] に設定されていることを確認し、また寿命 を [ 7 ⽇間] に設定してください。ジョブの
権限が [プライベート] になっている場合、他のユーザーがリンクを使ってアクセスすることはできません。リン
クを送信するユーザーは、そのジョブが所属している App を使⽤する権限も持っている必要があります。
今後⾃分が再利⽤するためにリンクを保存しておくこともできます。[ジョブにリンク ] の右にあるブックマーク
アイコンをクリックして、それをブラウザのブックマーク (お気に⼊り) バーにドラッグしてください。
ジョブデータのファイルへのエクスポート
サーチ/ピボットジョブのイベントデータを CSV、XML、JSON、または raw データファイルにエクスポートし
て、それをアーカイブしたり、サードパーティのアプリケーションで使⽤したりすることができます。
1. サーチを実⾏します。
2. サーチまたはピボット結果の上部に表⽰される [エクスポート ] アイコンを選択します。
85
3. データの [形式 ] を選択し、作成するファイルの [ファイル名 ] を指定します。
4. このファイルにエクスポートする結果の件数が[制限なし ] または [制限あり ] かを設定します。
エクスポートするイベント数の制限値を設定したり、サーチ/ピボットから返されたすべての結果をエクス
ポートしたりすることができます。⼀部のサーチでは膨⼤な件数のイベントが返される場合があります。状
況に応じて必要な事前措置を講じてください。
5. [エクスポート ] をクリックしてファイルをエクスポートします。
ファイルは、ブラウザまたはオペレーティングシステムのデフォルトのダウンロードディレクトリにエクス
ポートされます。たとえば、他のディレクトリを指定していない限り、⼤半の Mac OSX のユーザーはデ
フォルトの [ダウンロード ] ディレクトリでエクスポートファイルを確認できます。
Splunk Enterprise には、サーチ結果をエクスポートするためのさまざまなオプションが⽤意されています。ス
ピードを最適化するオプションのほか、容量が⾮常に⼤きいイベントセットに適したオプションを活⽤できます。
これらのエクスポート⽅法のサマリーについては、このマニュアルの「サーチ結果のエクスポート」を参照してく
ださい。
[ ジョブ] ページでのジョブの管理
[ジョブ] ページを使って、⾃分が保有している任意のサーチをレビュー、管理することができます。Admin また
は同等の権限を持つロールを保有している場合、すべてのユーザーが実⾏したサーチジョブを管理することができ
ます。Splunk Web で利⽤できるこれらのジョブは、[ジョブ] ページからアクセスすることができます。そのた
めには、Splunk Web で [アクティビティ ] > [ジョブ ] を選択します。
[ ジョブ] をクリックすると、[ジョブ] ページが表⽰されます。[ジョブ] ページには、サーチジョブの⼀覧が表⽰
されます。[ジョブ] ページに記載されるサーチジョブには、以下のものが含まれます。
最近⼿動実⾏したサーチ/ピボットの結果となるジョブ。
ダッシュボード読み込み時に実⾏されたサーチの成果物となるジョブ。
スケジュール済みサーチ (定期的に実⾏されるサーチ) 実⾏の成果物となるジョブ。
保存されたジョブ。
サーチジョブは、[ジョブ] ページで保存することができます。
サーチをバックグラウンドに移動した場合 も、サーチが完了する前にジョブが⾃動保存されます。
注意 ： [ジョブ] ページの表⽰時にあるジョブがキャンセルされた場合、ページにそのジョブは引き続き表⽰され
ますが、結果を参照することはできません。[ジョブ] ページを閉じてから再表⽰すると、キャンセルされたジョブ
は表⽰されなくなります。
サーチジョブの寿命
サーチジョブは Splunk Enterprise が⾃動削除するまでの間、[ジョブ] ページに表⽰されます。サーチジョブの
デフォルトの寿命は、それがサーチの⼿動実⾏の結果か、またはスケジュール済みサーチの結果なのかによって異
なります。
⼿動実⾏またはダッシュボードの読み込みによるサーチジョブ
サーチを⼿動実⾏して完了した場合、結果となるサーチジョブのデフォルトの寿命は 10 分です。ダッシュボード
パネルの読み込み時に実⾏されるサーチの成果物の寿命も 10 分です。
サーチジョブを保存することで、寿命を 7 ⽇間に延ばすことができます。サーチジョブは 2 種類の⽅法で保存で
きます。[ジョブ] ページを開いてサーチジョブを⼿動保存するか、またはサーチの実⾏中にバックグラウンドに
サーチを移動してください。
86
注意 ： 保存したジョブの保持期間を延⻑/短縮したい場合は、 limits.conf で [search] スタンザの
の値を適切な値に変更してください。「TTL」は「有効期間」を表す略語です。
default_save_ttl
サーチジョブの結果を表⽰した場合 ([ジョブ] ページでジョブをクリックして結果を別のウィンドウに表⽰した場
合)、ジョブの有効期限 (寿命) がリセットされ、表⽰した時点からさらに 7 ⽇間保持されます。
スケジュール済みサーチの結果となるサーチジョブ
スケジュール済みサーチは定期的に実⾏されます。デフォルトでは、スケジュール済みサーチの実⾏間隔の 2 倍
の期間サーチジョブが保存されます。つまり、サーチが 6 時間ごとに実⾏される場合は、サーチジョブは 12 時間
保持されます。
注意 ： 特定のスケジュール済みサーチの結果となるジョブのデフォルトの寿命は変更することができます。そう
するには、 savedsearches.conf に移動して⽬的のスケジュール済みサーチを探し、dispatch.ttl の値を変更してくだ
さい (倍数で指定、スケジュール間隔にこの値を乗じた時間だけ保持されます)。
[ジ ョ ブ ] ペ ー ジ の コ ン ト ロ ー ル
[ジョブ] ページのコントロールを使って以下の作業を⾏うことができます。
最近実⾏または保存したジョブの⼀覧の表⽰、およびそれを使ったジョブ統計 (実⾏時間、⼀致イベント
数、サイズなど) の⽐較。Admin ロールまたはそれと同等の権限を保有している場合、最近⽣成されたすべ
てのジョブを表⽰することができます。
処理中のバックグラウンドジョブ (リアルタイムサーチおよび⻑期間実⾏されている履歴サーチを含む) また
はスケジュール済みサーチによるジョブの進捗状況の表⽰。
サーチ/ピボットジョブの保存、⼀時停⽌、再開、完了、削除 (個別にまたは⼀括)。⽬的のジョブの左側にあ
るチェックボックスを選択して、ページ下部にある⽬的の操作に対応するボタンをクリックしてください。
サーチ名またはサーチ⽂字列をクリックして、特定のジョブに対応する結果を表⽰する。結果は別のブラウ
ザウインドウに表⽰されます。
ジョブがまだレポートとして保存されていないサーチに関連付けられている場合、結果はサーチ
ビューに表⽰されます。
ジョブがレポートに関連付けられている場合は、レポートに結果が表⽰されます。
[失効 ] 列には、各ジョブがシステムから削除されるまでの時間を表しています。失効の時点以降にサーチ
ジョブを表⽰または他のユーザーと共有したい場合は、ジョブを保存してください。ただし、ジョブを保存
しても 7 ⽇後には失効することに注意してください (期間内にジョブを表⽰した場合は、その時点から 7 ⽇
間に有効期間が延⻑されます)。詳細は、上記の「サーチジョブの寿命」を参照してください。
[サーチ] では、[ジョブ] ページに移動しないでも、⾃分が最後に実⾏したサーチまたはレポートジョブを保存す
ることができます (ジョブが失効していない場合)。
[サーチ] ビューでサーチを実⾏した後に、サーチジョブを保存したい場合は、[ジョブ ] をクリックして、
[ ジョブ設定の編集] を選択し、[ジョブ設定 ] ダイアログを表⽰します。ここでは、ジョブの読み取り権
限 の設定 (他のユーザーと共有する場合は [ 全員] を設定) を⾏うことができます。調査のためにジョブを保
持したい場合は、[寿命 ] に [ 7 ⽇間] を設定します。他のユーザーとジョブを共有する ([権限 ] に [ 全員] を
設定した場合) ためにリンクを取得する場合は、[ ジョブにリンク] を使⽤します。
注意 ：ジョブの寿命 を [ 7 ⽇間] に設定すると、その期間が経過するまでにジョブへのアクセスがなかった場合、
そのジョブは削除されます。アクセスがあった場合は、寿命がリセットされその時点から 7 ⽇間に設定されま
す。
⼿動実⾏したサーチジョブは、サーチの実⾏中に [バックグラウンドで処理 ] アイコンをクリックして保存
することもできます。この操作によりジョブの寿命が⾃動的に 7 ⽇間に延⻑され、また権限も [ 全員] に設
定されます。Splunk Enterprise は、他のユーザーと共有するために利⽤できるリンクも提供しています。
詳細は、このマニュアルの「ジョブとジョブ管理について」を参照してください。
サーチジョブ調査の使⽤
サーチジョブ調査 は、サーチの処理状況や Splunk が時間をもっとも費やしている所を確認するためのツールで
87
す。
ここでは、サーチジョブ調査を使ったサーチジョブパフォーマンスのトラブルシューティング、およびイベントタ
イプ、タグ、ルックアップなどのナレッジオブジェクトの働きについて説明していきます。詳細は、このマニュア
ルの「[ジョブ] ページでのサーチジョブの管理」を参照してください。
サーチジョブのプロパティの表⽰
過去のサーチ結果が存在している限り (期限切れでない限り)、サーチジョブ調査でサーチジョブ を調査すること
ができます。サーチが動作している必要はありません。
サーチを調査するには：
1. サーチを実⾏します。
2. [ジョブ] メニューで、[ジョブの調査] を選択します。
新しいブラウザウィンドウにサーチジョブ調査が表⽰されます。
過去のサーチ結果のプロパティを表⽰するには：
サーチ ID (SID) がある場合、URL を使って過去のサーチ結果を調査できます。サーチの SID は、ジョブ管理で確
認できます (右上の [ジョブ ] リンクをクリック)。または、Splunk のディスパッチディレクトリ
$SPLUNK_HOME/var/run/splunk/dispatch にも記載されています。ジョブ管理の使⽤⽅法の詳細は、このマニュアルの
「[ジョブ] ページでのサーチジョブの管理」を参照してください。
サーチジョブ調査ウィンドウで URI パスに注⽬すると、⽂字列の最後に以下のような⽂字列が付いているのが分
かります。
.../inspector?sid=1299600721.22&namespace=search
および namespace は SID 番号およびそれが属する App 名を表しています。ここでは、SID は 1299600721.22
になります。
sid
過去のサーチ結果の SID を URI パスの sid= の後に⼊⼒して、Return キーを押してください。サーチを表⽰する
ために⼗分な権限を持っている限り、それを調査することができます。
さて、何を調査しますか？
サーチジョブ調査で分かること
サーチの実⾏中、サーチジョブ調査には 2 種類のパネルが表⽰されます。[実⾏コスト ] には、サーチのコンポー
ネントに関する情報、およびサーチの総合的なパフォーマンスにおいて各コンポーネントが与える影響が表⽰され
ます。[サーチジョブのプロパティ ] には、ジョブのその他の特徴が表⽰されます。サーチ完了時にサーチジョブ
調査は、⾒つかった結果数およびサーチ完了までにかかった時間を通知します。サーチ完了後、サーチジョブ調査
の画⾯上部にはエラーメッセージも表⽰されます。⼤部分の情報は簡単に理解できますが、このセクションではパ
ネルをもう少し詳細に説明していきます。
実⾏コスト
[実⾏コスト ] パネルでは、サーチ-時間イベント処理アクションに関連する特定のコンポーネントのパフォーマン
ス上の影響に注⽬することで、サーチ効率のトラブルシューティングを⾏うことができます。以下の項⽬を⽰す、
コンポーネントのテーブルが表⽰されます。
コンポーネントの期間 (秒)
サーチ実⾏中の各コンポーネントの起動回数
各コンポーネントの⼊⼒および出⼒イベント数
サーチジョブ調査は、コンポーネントをアルファベット順に表⽰します。実⾏したサーチによってコンポーネント
数は異なります。以下の表は、個別のサーチコマンドおよび分散サーチコンポーネントの意義について説明してい
ます。
注意 ： これらは、単にキーワードサーチを実⾏した場合に表⽰されるコンポーネントです。
サーチコマンドの実⾏コスト
⼀般的に、サーチジョブの⼀部となる各コマンドには、command.<command_name> パラメータが存在しています。これ
らのパラメータの値は、各 <command_name> の処理に費やされる時間を表しています。たとえば、table コマンドを
使⽤すると、command.table が表⽰されます。
サーチコマンドコンポーネン
ト名
説明
Splunk は、サーチに⼀致するインデックスフィールドを含むイベントを識別
すると、イベント⾃体を調査してその他の基準に⼀致するかどうかを判断し
ます。これらは同時に処理されます。順次処理されるのではありません。
- raw データ内の読み取り場所を判断するために、
TSIDX ファイルの調査にかかった時間を⽰します。
command.search.rawdata - raw データファイルから実際のイベントを読み
command.search.index
88
取るまでにかかった時間を⽰します。
command.search.typer - イベントタイプの識別にかかった時間を⽰しま
す。
command.search.kv - イベントへのフィールド抽出の適⽤にかかった時間を
⽰します。
command.search.fieldalias - props.conf に基づいて、フィールド名の変更
にかかった時間を⽰します。
command.search.lookups - 既存のフィールドに基づいて、新しいフィール
ドを作成するためにかかった時間を⽰します (フィールドルックアップ
を実⾏)。
command.search.filter - ⼀致しないイベントのフィルタリングにかかった
時間を⽰します (たとえば、フィールドとフレーズ)。
command.search.typer - イベントへのイベントタイプの割り当てにかかっ
た時間を⽰します。
command.search.tags - イベントへのタグの割り当てにかかった時間を⽰し
ます。
command.search
使⽤するコマンドのタイプと、呼び出し、⼊⼒数/出⼒数に表⽰される項⽬数には関係があります。イベントを⽣
成するサーチの場合、⼊⼒数は 0 で、出⼒数はある程度のイベント数 X になると予測できます。サーチがサーチ
の⽣成とフィルタリングの両⽅を⾏う場合、フィルタリングには⼊⼒ (⽣成サーチの出⼒ X と等しい) および出⼒
= X となります。合計数は、⼊⼒ = X、出⼒ = 2 * X になり、呼び出し回数は倍になります。
ディスパッチされたサーチの実⾏コスト
分散サーチコンポーネント名
説明
dispatch.check_disk_usage
このジョブのディスク使⽤状況の確認に費やされた時間。
dispatch.createdSearchResultInfrastructure
各ピアのコレクタの作成および設定、各ピアへの HTTP POST の実
⾏にかかった時間。
dispatch.emit_prereport_files
変換サーチ を実⾏すると、レポートの統計結果はサーチが完了する
まで計算されません。サーチピア (dispatch.fetch) からイベントを取
得した後に、結果がローカルファイルに書き込まれま
す。dispatch.emit_prereport_files は、ローカルファイルへの変換サー
チの結果の書き込みにかかる時間を提供します。
dispatch.evaluate
サーチのパーシング、およびサーチを実⾏するために必要なデータ構
造の設定に費やされた時間。また、このコンポーネントにはサブサー
チの評価と実⾏に費やされた時間も含まれます。これは、使⽤される
各サーチコマンドによりさらに詳細に分けられます。⼀般的に
dispatch.evaluate.<command_name> は、<command_name> 引数のパーシング
と評価に費やされた時間を表しています。たとえ
ば、dispatch.evaluate.search は、search コマンド引数の評価とパーシ
ングに費やされた時間を表します。
dispatch.fetch
サーチピアからのイベントの待機または取得に費やされた時間。
dispatch.preview
プレビュー結果の⽣成に費やされた時間。
dispatch.process_remote_timeline
サーチピアが⽣成したタイムラインのデコードに費やされた時間。
dispatch.reduce
中間レポート出⼒を減らすために費やされた時間。
dispatch.stream.local
サーチのストリーミング部でサーチヘッドが費やした時間。
dispatch.stream.remote
分散サーチ環境でリモートサーチの実⾏に費やされた時間で、すべて
のピアの集計になります。また、各リモートサーチピア上でリモート
サーチの実⾏に費やされた時間
は、dispatch.stream.remote.<search_peer_name> で表されま
す。output_count は、この場合イベント数ではなく送信されたバイト
数を表します。
dispatch.timeline
タイムラインとフィールドサイドバー情報の⽣成に費やされた時間。
dispatch.writeStatus
ジョブのディスパッチディレクトリにある
定期更新に費やされた時間。
startup.handoff
個別のサーチプロセスのフォークから、フォークされたサーチプロセ
スの有益な作業の開始までにかかった時間。つまり、サーチ装置の作
成にかかるおおよその時間です。これは関連するすべてのピアの累積
です。これに⻑い時間がかかる場合、.conf ファイルまたはディス
パッチディレクトリに I/O に関する問題が発⽣している可能性があ
ります。
サーチジョブのプロパティ
[サーチジョブのプロパティ ] フィールドはアルファベット順に表⽰されます。
パラメータ名
説明
89
status.csv
と
info.csv
の
cursorTime
以降にイベントがスキャンされていない、もっとも早い時間。進捗状況を⽰
すために利⽤できます。doneProgress の説明を参照してください。
delegate
保存済みサーチに対して、ユーザーが開始したジョブを指定します。デフォ
ルトはスケジューラーになります。
diskUsage
使⽤されている合計ディスクスペース量 (バイト)。
dispatchState
サーチの状態。QUEUED、PARSING、RUNNING、PAUSED、
FINALIZING、FAILED、または DONE になります。
サーチのおおよその進捗状況を⽰す、0〜1.0 の数字。
doneProgress
doneProgress = (latestTime â​​ cursorTime) / (latestTime â​​ earliestTime)
dropCount
リアルタイムサーチのみ。 rt_queue_size のために破棄された、⾒込みイベン
ト数 (デフォルトは 100000)。
earliestTime
サーチジョブの開始が設定されたもっとも早い時間。進捗状況を⽰すために
利⽤できます。doneProgress の説明を参照してください。
eai:acl
App およびユーザーレベルの権限を記述します。たとえば、App がグローバ
ルに共有されているかどうか、サーチを実⾏または表⽰できるユーザーなど
を記述します。
eventAvailableCount
エクスポートに利⽤できるイベント数。
eventCount
サーチが返したイベント数。
eventFieldCount
サーチ結果で⾒つかったフィールド数。
eventIsStreaming
このサーチのイベントをストリーム配信するかどうかを⽰します。
eventIsTruncated
サーチのイベントが保管されていないため、サーチのイベントエンドポイン
トから利⽤できないかどうかを⽰します。
eventSearch
任意の変換コマンド前のサーチ全体のサブセット。タイムラインおよびイベ
ントエンドポイントは、サーチのこの部分の結果を表しています。
eventSorting
このサーチのイベントをソートするかどうかのほか、その順番を⽰していま
す。asc = 昇順、desc = 降順、none = ソートしない
isBatchMode
サーチがバッチモードで実⾏されているかどうかを⽰します。これは、変換
コマンドを含むサーチにのみ適⽤されます。
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
レポートコマンドが使⽤された場合のレポート対象サーチ。
90
request
サーチが
resultCount
サーチが返す結果数合計。別の⾔い⽅をすれば、スキャンしたイベント数
(scanCount で表される) の中で、実際にサーチ単語に⼀致したサブセット。
resultIsStreaming
サーチの最終結果をストリーミングを使って利⽤できるかどうかを⽰します
(たとえば、変換操作なし)。
resultPreviewCount
最新のプレビュー結果の結果⾏数。
runDuration
サーチ完了までにかかった時間 (秒)。
scanCount
スキャンされたまたはディスクから読み込まれたイベント数。
search
サーチ⽂字列。
splunkd
に送信する GET 引数。
サーチがイベントタイプとして保存された場合、1 になり、それ以外は 0 に
なります。
searchCanBeEventType
ベースサーチのみ (サブサーチまたはパイプではなく) イベントタイプとして
保存することができます。
searchProviders
通信したすべてのサーチピアのリスト。
sid
サーチ ID 番号。
statusBuckets
最⼤タイムラインバケツ数。
ttl
有効期間、またはサーチジョブの完了後、それが失効するまでの時間。
サーチに関するその他の情報へのリンクを⽰します。これらのリンクは利⽤
できない場合もあります。
Additional info
タイムライン
フィールドサマリー
search.log
注意 ：サーチパフォーマンスのトラブルシューティングを⾏う場合、scanCount と resultCount のコストの違いを正
しく理解しておくことが重要です。デンスサーチでは、 scanCount と resultCount が類似しています (scanCount =
resultCount)。スペースサーチについては、scanCount が結果のカウントよりもはるかに多くなります (scanCount >>
resultCount)。サーチパフォーマンスを測定する際には、resultCount/時間の⽐ではさほど正確には表せません。
scanCount/時間の⽐を使⽤してください。⼀般的に、scanCount/秒のイベントレートが 10,000〜20,000 イベント/
秒の場合に、パフォーマンスは良好とみなされます。
デバッグメッセージ
サーチジョブ調査を設定して、サーチにエラーがある場合に DEBUG メッセージを表⽰させます。たとえば、結
果にフィールドが不⾜している場合に警告で通知できます。
サーチの完了後、サーチジョブ調査によって DEBUG メッセージがサーチジョブ調査ウィンドウの上部に表⽰さ
れます。
デフォルトでは、DEBUG メッセージが⾮表⽰になっています。表⽰を設定するには、limits.conf を開
き、[search_info] スタンザの infocsv_log_level パラメーターを INFO に設定します。
[search_info]
infocsv_log_level = INFO
サーチジョブ調査の出⼒例
全時間実⾏した dedup サーチの実⾏コスト例を以下の⽰します。
* | dedup punct
[実⾏コスト ] パネルのサーチコマンドコンポーネントは、以下のように表⽰されます。
91
command.search コンポーネントおよびその下にある項⽬は、サーチの
影響を表しています (パイプ⽂字の前のすべて)。
search
コマンド部のパフォーマンス上の
は、search コマンドに渡す前の dedup コマンドの結果処理のパフォーマンス上の影響を表していま
す。command.prededup の⼊⼒カウントは、command.search の出⼒カウントに⼀致し、command.prededup の⼊⼒カウント
は、command.prededup の出⼒カウントに⼀致します。この場合、command.prededup の出⼒カウントは、サーチ完了時
に返されたイベント数と⼀致しなければなりません ([サーチジョブプロパティ ] の resultCount の値)。
command.prededup
A ns w er s
何か質問がありますか？「Splunk Answers」では、Splunk コミュニティに寄せられた、サーチジョブ調査の使
⽤⽅法に関する質問と回答をご覧いただけます。
OS からのジョブの管理
ここでは、OS からのサーチジョブの管理⽅法について説明していきます。以下の 2 種類のプラットフォームを対
象にしています。
*nix
Windows
Splunk Web を使ったサーチジョブの管理⽅法については、このマニュアルの「[ジョブ] ページでのジョブの管
理」を参照してください。
* ni x で の ジ ョ ブ の 管 理
Splunk Enterprise がジョブを実⾏している間、それが OS に splunkd search プロセスとして表⽰されます。この
ジョブプロセスは、OS のコマンドラインで管理することができます。
ジョブのプロセスとその引数を表⽰するには、以下のコマンドを⼊⼒します。
> top
> c
実⾏中のすべてのプロセスとその引数が表⽰されます。
と⼊⼒すると、このリスト内の Splunk Enterprise サーチプロセスのみが表⽰されます。
以下のような情報が表⽰されます。
ps -ef | grep "search"
[pie@fflanda ~]$ ps -ef | grep 'search'
530369338 71126 59262
0 11:19AM ??
0:01.65 [splunkd pid=59261] search --id=rt_1344449989.64 --
maxbuckets=300 --ttl=600 --maxout=10000 --maxtime=0 --lookups=1 --reduce_freq=10 --rf=* --user=admin --pro -roles=admin:power:user
AhjH8o/Render TERM_PROGRAM_VERSION=303.2
530369338 71127 71126
0 11:19AM ??
0:00.00 [splunkd pid=59261] search --id=rt_1344449989.64 --
maxbuckets=300 --ttl=600 --maxout=10000 --maxtime=0 --lookups=1 --reduce_freq=10 --rf=* --user=admin --pro --roles=
各サーチジョブに対して 2 つのプロセスが存在しています。2 番⽬のプロセスは、 splunkd が必要に応じて他の作
業を⼿伝わせる「ヘルパー」プロセスです。メインジョブは、システムリソースを使⽤しています。メインプロセ
スを kill すると、ヘルパープロセスも終了されます。
プロセス情報には以下の内容が含まれます。
サーチ⽂字列 (search=)
92
サーチ⽂字列 (search=)
ジョブ ID (id=)
ディスク上に保持されるジョブの成果物 (出⼒) の ttl または有効期間 (ttl=)
ジョブを実⾏しているユーザー (user=)
ユーザーが所属しているロール (roles=)
ジョブの実⾏中、データは $SPLUNK_HOME/var/run/splunk/dispatch/<job_id>/ に書き込まれます。スケジュール済み
ジョブ (スケジュールされた保存済みサーチ) には、ディレクトリ名の⼀部として保存済みサーチ名が含まれま
す。
プロセスの ttl の値により、ここへのデータの保持期間が決まります。OS でジョブを kill する場合、その成果物
も削除するには、実施する前にジョブ ID を確認してください。
W i ndo w s で の ジ ョ ブ の 管 理
Windows の場合も、各サーチジョブに対して別個のプロセスが⽣成されます。Windows には、*nix の top コマ
ンドに対応するコマンドはありませんが、実⾏中のサーチジョブのコマンドライン引数を表⽰するさまざまな⽅法
があります。
Process Explorer (http://technet.microsoft.com/ja-jp/scriptcenter/dd742419.aspx) ユーティリティ
を使って、サーチを実⾏しているプロセスのコマンドラインを検索する。
Powershell (http://technet.microsoft.com/ja-jp/scriptcenter/dd742419.aspx) の TASKLIST と Get-WMIObj
コマンドを使って、サーチジョブの ProcessID と CommandLine 引数を取得する。
Splunk Enterprise がサーチを実⾏する場合、そのサーチのデータは
ディレクトリに書き込まれ
ます。保存済みサーチも命名規則 「admin__admin__search_」とエポック時に加えて無作為に⽣成されたハッシュを
使⽤した、似たようなディレクトリに書き込まれます。
%SPLUNK_HOME\var\run\splunk\dispatch\<epoch_time_at_start_of_search>.<number_separator>
ファイルシステムを使ったジョブの管理
Splunk Enterprise では、ジョブの成果物ディレクトリでの項⽬の作成/削除によりジョブを管理することができ
ます。
ジョブをキャンセルするには、ジョブの成果物ディレクトリに移動して、そこに「cancel」という名前の
ファイルを作成します。
ジョブの成果物を保持するには (ttl 設定を無視する)、「save」ファイルを作成します。
ジョブを⼀時停⽌するには、「pause」ファイルを作成します。⼀時停⽌を解除するには、「pause」ファ
イルを削除します。
サーチ結果のエクスポート
サーチ結果のエクスポート
このトピックでは、Splunk Enterprise でのデータのエクスポート⽅法に関する技術的な概要が解説されていま
す。サーチ結果は Splunk Enterprise から直接エクスポートできます。エクスポートしたデータはサードパー
ティのシステムに転送することもできます。
エクスポート⽅法
Splunk Enterprise ではいくつかのエクスポート⽅法を使⽤できます。
Splunk Web
コマンドラインインターフェイス (CLI)
Splunk Enterprise ソフトウェア開発キット (SDK)
Representational State Transfer (REST)
dump サーチコマンド
データ転送
Splunk Apps
Splunk App for CEF のデプロイと使⽤
Splunk DB Connect のデプロイと使⽤
Hadoop Connect
Splunk ODBC Driver のインストールと Microsoft Excel での使⽤
Splunk ODBC Driver のインストールと MicroStrategy での介した使⽤
Splunk ODBC Driver のインストールと Tableau での使⽤
Splunk Enter pr i s e エ ク ス ポ ー ト オ プ シ ョ ン の 概 要
Splunk Enterprise ではさまざまな⽅法でデータをエクスポートできます。選択するエクスポート⽅法は、関わる
データ量と対話機能のレベルによって異なります。たとえば、Splunk Web を経由する単⼀のオンデマンドサー
チのエクスポートは、容量の少ないエクスポートに最適です。また、容量の多いスケジュール済みエクスポートを
設定する場合は、SDK や REST のオプションが最も機能します。
容量の多いエクスポートの場合、サーチデータの最も安定した取得⽅法はコマンドラインインターフェース (CLI)
です。CLI では、さまざまな Splunk Enterprise SDK を使⽤してサーチを外部アプリケーションに合わせて調整
できます。REST API は CLI からも動作しますが、内部だけで使⽤することが推奨されます。
専⾨的な観点では、ソフトウェア開発キットや REST API エンドポイントとの過去の連動経歴を必要とする SDK
93
や REST API よりも、Splunk Web や CLI の⼿法のほうがはるかに使⽤しやすいでしょう。
⽅法
ボリューム
対話機能
備考
Splunk Web
低
オンデマンド、対話型
オンデマンドエクスポートの⼊
⼿は簡単
CLI
中
オンデマンド、低対話型
オンデマンドエクスポートの⼊
⼿は簡単
REST
⾼
⾃動、コンピュータ対コン
ピュータに最適
SDK 下で動作
SDK
⾼
⾃動、コンピュータ対コン
ピュータに最適
⾃動化に最適
エクスポート形式の選択
Splunk Enterprise では次の形式でデータを直接エクスポートできます。
Raw イベント
CSV
JSON
XML
Splunk W eb を 使 ⽤ す る デ ー タ の エ ク ス ポ ー ト
1. データでサーチを実⾏します。
2. タイムラインのすぐ下にある [エクスポート] ボタンをクリックします。
注意 ：ボタンが表⽰されない場合、データのエクスポートを禁ずるシステム管理者により⾮表⽰になっていま
す。詳細は、『Splunkのセキュリティ』マニュアルの「権限を持つロールの定義について」を参照してくださ
い。export_results_is_visible 権限を検索します。
3. サーチ結果をエクスポートする形式 (CSV 、Raw イベント 、XML または JSON ) を選択します。
4. 希望する [結果数 ] を選択します ([制限あり ] または [制限なし ])。
5. [エクスポート ] をクリックして確定します。
⼤量のデータをエクスポートする際のセッションタイムアウトの延⻑
[エクスポート] ボタンを使⽤して⼤量のデータをエクスポートしようとすると、セッションがタイムアウトになる
場合があります。次の⼿順に従ってセッションタイムアウトの制限を延⻑します。
1. [設定 ] をクリックして、[システム設定 ] を選択します。
2. Splunk W eb でセッションタイムアウトのフィールドの数字を増やします。
タイムアウトの延⻑設定により、ブラウザと splunkweb の接続時間が延⻑されます。
サーチ結果のアーカイブ
サーチ結果をアーカイブする必要がある場合は、ジョブデータをサードパーティのグラフ作成アプリケーションに
エクスポートすることが可能です。『サーチ』マニュアルの「ジョブデータのファイルへのエクスポート」を参照
してください。
ステークホルダーに結果を送信するレポートのスケジューリング
定期的にレポートを実⾏するためのスケジューリングを⾏い、その結果をプロジェクトのステークホルダーにメー
ルで送信できます。このメールではインラインテーブルのほか、CSV や PDF の添付でレポートの結果を通知でき
ます。また、Splunk Enterprise でのレポート結果のリンクを送ることも可能です。
94
詳細は、『レポート』マニュアルの「レポートのスケジュール」を参照してください。
CLI を使⽤するデータのエクスポート
記述が簡単なコマンドラインインターフェイス (CLI) は、⾃動化に対応するほか、Splunk Web よりも速く効率
的に⼤量のデータを処理します。
CLI を経由して Splunk Enterprise にアクセスするには、Splunk Enterprise サーバーへのシェルアクセス、ま
たはリモートの Splunk サーバーの正しいポートにアクセスする権限のいずれかが必要です。
CLI を使ったエクスポートでは次のコマンド構造を使⽤します。
splunk search [eventdata] -preview 0 -maxout 0 -output [rawdata|json|csv|xml] > [myfilename.log] ...
デフォルトでは、100 件のイベントしかエクスポートできません。この数を増やすには、引数 -maxout を使⽤しま
す。たとえば、-maxout 300000 を含めると、300,000 件のイベントをエクスポートできます。-maxout を 0 に設定
すると、イベントを無制限にエクスポートできます。
Splunk Enterprise CLI の詳細は、『管理』マニュアルの「CLI について」を参照してください。
CLI アウトプットコマンドの例
この CLI の例は、サーチ⽂字列によって指定される時間範囲内で発⽣した _internal インデックスからイベントを
取得し、200,000 件のイベントをraw データ形式で test123.dmp ファイルに出⼒します。
splunk search "index=_internal earliest=09/14/2014:23:59:00 latest=09/16/2014:01:00:00 " -output rawdata -maxout
200000 > c:/test123.dmp
Splunk Enter pr i s e R EST A P I を 使 ⽤ す る エ ク ス ポ ー ト
Splunk Enterprise SDK を迂回し、REpresentational State Transfer (REST) モデルを直接使⽤してターミナル
またはブラウザからリクエストを⾏うことで、Splunk Enterprise にアクセスできます。Splunk REST API で
は、 Splunk インスタンスからのデータの GET (⼊⼿) と POST (投稿) が可能です。
REST API を使⽤してデータをエクスポートするには、エンドポイントからデータを GET (⼊⼿) する必要があり
ます。ただし、その前にサーチジョブを実⾏する必要があります。
1. /services/search/jobs/ でPOST (投稿) 操作を使⽤してサーチジョブを実⾏します。
サーチを POST (投稿) ペイロードとして設定します。必要な場合はサーチに⽇付範囲を含めます。
curl -k -u admin:changeme \
https://localhost:8089/services/search/jobs/ -d search="search sourcetype=access_* earliest=-7d"
2. サーチに対しサーチジョブ ID (SID) を⼊⼿します。
サーチが、<sid> タグにサーチジョブ ID を含む XML 応答を返します
<?xml version='1.0' encoding='UTF-8'?>
<response>
<sid>1423855196.339</sid>
</response>
サーチジョブ ID は [サーチジョブ調査 ] のジョブでも取得できます。[ アクティビティ] > [ ジョブ] へと
進み、[ジョブ管理] を開きます。実⾏したばかりのサーチを⾒つけて [調査 ] をクリックします。サーチ
ジョブ調査によって別のウィンドウが表⽰されます。
3. GET (⼊⼿) 操作を作成し、ファイルにサーチの結果をエクスポートします。
この操作では下記が実⾏されます。
オブジェクトエンドポイントの特定。各エンドポイントから、Splunk の別の領域にアクセスできるように
なります。現時点でユーザーが利⽤できるオブジェクトエンドポイントの⼀覧を確認するには、アプリ内で
https://localhost:8089/servicesNS/<user>/<app>/ へと進みます。
例：https://localhost:8089/servicesNS/admin/search/saved/searches/
サーチジョブユーザーと App を特定します。次の例は
ています。
<user>
を使⽤して、出⼒形式を特定します。可能な値は
結果が JSON ファイルにエクスポートされています。
output_mode
を
admin
として、<app> を
JSON、CSV、または XML
curl -u admin:changeme \
-k https://localhost:8089/servicesNS/admin/search/jobs/1423855196.339/results/ \
95
search
として定義し
です。次の例ではサーチ
--get -d output_mode=json count=5
Splunk Enterprise のオブジェクトエンドポイントに関する詳細は、『REST API リファレンス』マニュアルの
「サーチエンドポイントに関する解説」を参照してください。
REST API を使⽤したサーチの連動に関する詳細は、『Rest API チュートリアル』の「REST API を使⽤した
サーチの作成」を参照してください。
エンドポイントの詳細については、『REST API リファレンス』マニュアルの「サー
チエンドポイントに関する解説」を参照してください。
/services/search/jobs/export
Splunk SD K を 使 ⽤ す る エ ク ス ポ ー ト
Splunk では、ソフトウェア開発者が⼀般的なプログラミング⾔語を使⽤して Splunk App を構築するためのソフ
トウェア開発キット (SDK) が提供されています。この Splunk SDK を活⽤することで、Splunk Enterprise を
サードパーティのレポートツールやポータルと統合できるようになります。これにより、アプリケーションでサー
チ結果を扱ったり、アーカイブを⽬的に⼤量のデータを抽出したりできます。Splunk SDK を使⽤するには、
SDK ナレッジや開発に精通している必要があります。
Splunk が提供する SDK は、Python、Java、JavaScript、Ruby、C# に対応しています。こうした SDK のエク
スポートサーチはすぐに実⾏されます。サーチではジョブが⽣成されず、すぐに結果のストリーミングが開始され
ます。
Splunk SDK は Splunk Enterprise REST API をベースに構築されます。また、REST API エンドポイントを対
象とするより単純なインターフェイスが提供されます。より少ないコードで、以下のことを実⾏できるアプリケー
ションを書くことができます。
認証サーチの作成と実⾏
データの追加
データのインデックス作成
サーチジョブの管理
Splunk の設定
Splunk SDK に関する詳細は、[Splunk 開発者ポータル] の「Splunk SDK の概要」を参照してください。
Pyt hon SDK
Python 向け Splunk SDK では、Splunk Enterprise で操作できる Python のアプリケーションを書くことがで
きます。Python SDK を使⽤したエクスポートサーチは、履歴モードやリアルタイムモードで実⾏可能です。実
⾏はすぐに開始され、結果がストリーミングされます。これらは Python アプリケーションに統合できます。
Python SDK を使⽤してエクスポートサーチを実⾏します。
1. サーチを実⾏する対象のパラメータを設定します。次の例では、直近 1 時間の
としてパラメータが設定されています。
splunklib
のエクスポートサーチ
import splunklib.client as client
import splunklib.results as results
2. 通常モードのサーチを実⾏します。
service = client.connect(â​¦)
rr = results.ResultsReader(service.jobs.export("search index=_internal | earliest= -1h))
3. 結果を⼊⼿し、ResultsReader を使⽤して結果を表⽰します。
if isinstance(result, results.Message):
# Diagnostic messages may be returned in the results
print '%s: %s' % (result.type, result.message)
elif isinstance(result, dict):
# Normal events are returned as dicts
print result
assert rr.is_preview == False
Java SDK
Java SDK では、Java を使⽤しながらサーチの実⾏とエクスポートができます。
Java SDK を使⽤してエクスポートサーチを実⾏するには、
例を実⾏します。
/splunk-sdk-java
ディレクトリでCLI を使⽤して次の
java -jar dist/examples/export.jar main --username="admin" --password="changeme"
[エクスポート] アプリケーションは、現在の作業中ディレクトリに保存されている export.out に「main」イン
デックスをエクスポートします。このアプリケーションをもう⼀度実⾏する場合は、その前に export.out を削除し
ます。削除しないと場合、エラーが発⽣します。
96
ます。削除しないと場合、エラーが発⽣します。
下記は、Java SDK を使⽤する別の CLI の例です。サーチクエリを含める⽅法や出⼒形式を JSON に変更する⽅
法が記載されています。
java -jar dist/examples/export.jar main --search="search sourcetype=access_*" json
JavaScript エクスポート
JavaScript エクスポートのエンドポイントでは、 JavaScript フレームワーク内で Splunk Enterprise からデー
タをエクスポートできます。
現在、Splunk Enterprise は Javascript SDK の Javascript エクスポートのエンドポイントに対応していませ
ん。ただし、ノード javascript (.js) アプリケーションのリクエストを使⽤してデータをエクスポートすることは
できます。
Javascript エクスポートのエンドポイントを使⽤してエクスポートサーチを実⾏します。
1. リクエストモジュールを読み込みます。リクエストは最も簡単に http/https 呼び出しができるよう設計されて
います。
var request = require('request');
2. [get ] (⼊⼿) を呼び出して GET リクエストを発⾏します。以下のパラメータを⼊⼒します。
値を false に設定すると、strictSSL によって、デフォルトでは無効な証明書とされるサーバー証明
書を有効にしないように、Splunk Enterprise からリクエストが返されます。
uri エクスポートエンドポイントのパスと共に、Splunk Enterprise ホストの uri を提供します。JSON 応
答はクエリ⽂字列に指定されます。
qs サーチパラメータを付与するために qs を設定します。これにより、サーチ⽂字列に URI のエンコードを
⾏う必要がなくなります。
strictSSL
request.get(
{
strictSSL: false,
uri: 'https://localhost:8089/servicesNS/admin/search/search/jobs/
export?output_mode=json',
qs: {
search: 'search index=_internal'
}
}
)
3. auth を呼び出して HTTP Basic の認証を使⽤し、Splunk Enterprise のユーザー名とパスワードを⼊⼒しま
す。
.auth('admin', 'changeme', false)
4. パイプを使って結果を
stdout
に渡します。
.pipe(process.stdout);
C# SDK
C# SDK を使⽤したエクスポートサーチが⾮同期的かつすぐに実⾏されます。サーチのジョブは作成されず、結
果のストリーミングがすぐに開始されます。C# SDK は、⼤量の履歴データやリアルタイムデータのエクスポー
トに役⽴ちます。
Python SDK を使⽤してエクスポートサーチを実⾏します。
1. StreamReader を使⽤してサーチのプレビューを作成します。
SearchPreviewStream searchPreviewStream;
2. サーチ結果のプレビューをエクスポートします。
using (searchPreviewStream = service.ExportSearchPreviewsAsync("search index=_internal | head 100").Result)
{
int previewNumber = 0;
97
3. それぞれのサーチ結果のプレビューを使って⼀覧を作成します。
foreach (var searchPreview in searchPreviewStream.ToEnumerable())
{
Console.WriteLine("Preview {0:D8}: {1}", ++previewNumber, searchPreview.IsFinal ? "final" : "partial");
int recordNumber = 0;
foreach (var result in searchPreview.Results)
{
Console.WriteLine(string.Format("{0:D8}: {1}", ++recordNumber, result));
}
}
}
Ruby SDK
Ruby SDK は、開発者による Splunk Enterprise を使⽤したアプリケーションの構築に役⽴ちます。Ruby 向け
Splunk SDK では、Splunk エンジンを使⽤できる Ruby のアプリケーションを書くことができます。次の⼿順で
は、サービスクラスが構成され、Splunk サーバーに接続していることが想定されています。
Ruby SDK を使⽤してエクスポートサーチを実⾏するには、下記を⾏います。
1. create_export ⼿法を使⽤してサーチ時のパラメータを特定します。
⼿法はサーチクエリを開始し、サーチ⽂字列の変換コマンドから実⾏される前に、ジョブが発
⾒したイベントを返します。これはジョブでのイベントの呼び出しに相当します。
create_export
このサーチの例では、直近の 1 時間 (現在の 1 時間前) に発⽣したイベントが返されています。
stream = service.create_export("search index=_internal | head 1",
:earliest_time => "-1h",
:latest_time => "now")
2. エクスポートするイベントを特定します。
次の例は、raw データ (_raw) として出⼒される⼀連のストリーミングイベントのエクスポートサーチです。
パフォーマンスを加速させるために、イベントはサーチ⽂字列の変換サーチコマンド (存在する場合) を経由
して処理が⾏われる前に返されます。つまり、エクスポートサーチが返されるまでプレビューがスキップさ
れることになります。
results = Splunk::ResultsReader.new(stream)
results.each do |result|
puts "#{result["_raw"]}"
end
3. .rb ファイル (example.rb) へのコードを保存します。
4. ターミナルの
example.rb
を実⾏します。
dum p サ ー チ コ マ ン ド の 使 ⽤
サーチコマンドでは、⼤量のイベントコレクションをローカルディスクに「ダンプ」できます。ここでは、
CLI、Splunk SDK、Splunk Web を使⽤できます。
dump
dump
コマンドの基本構⽂は次の通りです。
dump basefilename=<string> [rollsize=<number>] [maxlocal=<number>] [compress=<number>] [format=<string>]
[fields=<comma-delimited-string>]
<format>
は作成する ダンプファイルのデータ形式です。形式は、
raw、 csv、 tsv、xml、 json
maxlocal
は、このダンプの最⼤許容ディスク使⽤量 (MB) です。デフォルトは 1GB です。
から選択できます。
必須の dump コマンドおよびオプションの引数に関する詳細とサーチ例については、『サーチリファレンス』の
dump コマンドに関するトピックを参照してください。
サードパーティ製システムへのデータの転送
Splunk Enterprise ではサードパーティ製システムへのデータの転送が可能です。データは下記のように送信でき
ます。
TCP ソケットを経由
98
標準 syslog でのパッケージ化
outputs.conf、 transforms.conf、および props.conf
を編集し、ヘビーフォワーダーを設定します。このエクスポー
ト⽅法は、他の Splunk Enterprise インスタンスへのデータのルーティングに類似します。データはホスト、
ソース、またはソースタイプでフィルタリングできます。『データの転送』マニュアルの「サードパーティー製シ
ステムへのデータ転送」を参照してください。
カスタムサーチコマンドの作成
カスタムサーチコマンドの作成について
Splunk のサーチ処理⾔語 (SPL) には様々なコマンドが含まれています。これらのコマンドを使⽤することで、
データから必要な情報を⼊⼿し、結果を表⽰できます。コマンドを使⽤して、イベントの相関付け、結果に関する
統計値の算出、フィールドの評価と結果の並べ替え、データの再フォーマットと強化、グラフの作成などを⾏うこ
とができます。
さらに、Splunk Enterprise サーチ処理⾔語を拡張して、ニーズに合わせてこれらのコマンドをカスタマイズした
り、独⾃の処理や計算を実⾏するための独⾃のサーチコマンドを開発したりすることができます。
Python 向け Splunk SDK では、わずかな変更だけでカスタムサーチコマンドを作成できるいくつかのテンプ
レートを使⽤します。Splunk 開発者向けポータルの「カスタムサーチコマンドの作成⽅法」を参照してくださ
い。
サーチコマンドスタイルガイド
ここでは、カスタムサーチコマンドおよびその引数の命名のガイドライン、そして引数の処理⽅法について説明し
ていきます。このスタイルガイドは searchproc_style.txt にも記載されています。
カスタムサーチコマンドの命名規則
サーチプロセッサのコマンド名：
英数字を使⽤し、最初は⽂字でなければなりません。
ダッシュやアンダースコアなどの、英数字以外の⽂字を使⽤することはできません。
引数オプション名：
英数字を使⽤し、最初は⽂字でなければなりません (アンダースコアは可)。
論理演算式は肯定的に指定する必要があります。たとえば、hidefield=<bool> ではなく、
使⽤します。
showfield=<bool>
を
⼤⽂字⼩⽂字区別：
コマンド名は⼤⽂字と⼩⽂字が区別されます。
フィールド名は、⼤⽂字と⼩⽂字を区別する必要があります。
キーワードでは、⼤⽂字と⼩⽂字は区別されません (例：「by」のようなストップワード)。
引数の処理およびチェック⽅法
⼀連の引数とそのオプションを取るサーチコマンド (またはプロセッサ) を作成できます。
⼀連のオプション引数セット (空のセットも可能) を取る単純プロセッサ：
processArguments() では、getOption() 呼び出しで各オプションの値を取得します
例：outputraw (オプションなし)、analyzefields (1 つのオプション引数を取ります)
オプションとフィールドのリストまたは他の引数を取るプロセッサ (⼤部分のコマンドはこのカテゴリに分類され
ます)：
フィールドのリストはオプションとして指定するのではなく、引数リストの⼀部として直接指定する必要が
あります。複数のリストが必要な場合は、キーワードを使ってリストを区切ります。
processArguments() で、まず getOption() を使ってオプションパラメータを取り込みます。次に
getNextArgs() を使って名前変更引数のリストを取得します。getNextArgs() では、必要に応じてストップ
ワードを使⽤することができます。この場合、特定の単語が⾒つかると、引数の取得を停⽌します。
例："mycommand myopt=optval field1 field2 field3 by otherval1 overval2" (「by」がストップ
ワードです)。
完全に引⽤符で囲まれた引数は、キーワードまたはオプションとはみなされません。
外部引数をすべてチェック：
すべてのプロセッサは、引数処理の最後に「ERRORIFUNUSEDARG」マクロを呼び出して、使⽤されな
かった外部引数にエラーのフラグが設定されていないことを確認する必要があります。
オプション名のスペルの誤りも多いため、意図しない結果を招かないようするためにも、このことが重要に
なります。
エラーの処理
エラーをパーシングするすべての引数は、解析時に SearchProcessorException() をスローする必要がありま
す。
99
⼀般的に、実⾏時のエラー (例：指定フィールドがイベント内に存在していない) は、実⾏時に
SearchResultsInfo に INFO/WARN/ERROR メッセージを追加する必要があります。また、実⾏を停⽌しないよ
うにする必要があります。
カスタムの Pyt ho n サーチコマンドスクリプトの場合、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 は前のガイドラインに違反していますが) などが挙げら
れます。
サーチコマンドの作成
重要
このページの情報は、Intersplunk APIを使⽤して作成されたカスタムサーチコマンドを所持するユーザーのみに
提供しています。
ただし、新たなカスタムサーチコマンドの作成は、Splunk Python SDK サーチコマンド API を使⽤して⾏うこ
とができます。Splunk 開発者向けポータルの「カスタムサーチコマンドの作成⽅法」を参照してください。
カスタムサーチコマンドは、データを読み取り、それを処理して出⼒する Python スクリプトです。ここでは、
Python スクリプトによる⼊⼒と引数の処理規則について説明していきます。
サーチコマンドは以下の条件を満たしていなければなりません。
適切な $SPLUNK_HOME/etc/apps/<app_name>/bin/ ディレクトリに存在していること。Splunk に同梱されているス
クリプトの⼤半は、サーチ App に関連付けられており、 $SPLUNK_HOME/etc/apps/search/bin に保管されていま
す(たとえば、このディレクトリ内のスクリプトを参照することができます)。
<command_name>.py の名前が付けられていること。つまり、スクリプトのファイル名は Splunk サーチ内で呼
び出されるコマンド名でなければなりません。サーチコマンド名には、英数字 (a〜z、A〜Z、および 0〜9)
のみを使⽤できます。新しいコマンドに既存のコマンドと同じ名前を使⽤することはできません。
コマンドの種類
サーチコマンドは、⽣成コマンド、ストリーミングコマンド、またはイベントを⽣成するコマンドになります。
⽣成コマンドは、インデックスからイベントを取得 (または⽣成) するコマンドです。これらのコマンドは、
サーチパイプラインの先頭で⽤いられます。⼊⼒ (イベントやサーチ結果) を予測する、または必要とするこ
とはありません。代わりに先頭のパイプラインで呼び出されます。⽣成コマンドの例としては、search (パ
イプラインの先頭で使⽤される場合)、inputcsv、inputlookup、および metadata などが挙げられます。
ストリーミングコマンドは、各イベントに変換を適⽤し、そのすべてを⼀度にではなく、⼀定単位ごとに出
⼒します。ストリーミングコマンドの例としては、eval (各イベントに 1 つまたは複数のフィールドを追加
するために使⽤)、where、および streamstats などが挙げられます。⾮ストリーミングコマンドは、それ
がデータを操作/減少して出⼒する前に、すべてのデータが⼊⼒として利⽤できることを前提にしています。
⾮ストリーミングコマンドの例としては、stats、top、timechart などがあります。
イベントを⽣成するコマンドは、データをストリーミングで返すコマンドです。これらのコマンドの例とし
ては、search、eval、where などが挙げられます。
デフォルトの初期サーチ操作では、イベントが⽣成され、取得されたイベントは Splunk Web のイベントビュー
アに表⽰されます。⼀部の⽣成コマンド (inputcsv、inputlookup、metadata など) はイベントを⽣成しないた
め、イベントビューアには何も表⽰されません。⼀部の演算⼦ (eval、sort、dedup、cluster、where など) はイ
ベントを保持し、他のコマンド (stats、top、timechart など) は保持しません。
commands.conf 内の streaming および generating パラメータで、カスタムサーチコマンドのタイプを記述するこ
とができます。retainevents パラメータを使って、イベントを保持するか、または変換するかを指定することもで
きます。詳細は、「Splunk へのカスタムコマンドの追加」を参照してください。すべての設定可能な項⽬につい
ては、『管理』マニュアルの commands.conf に関する項⽬を参照してください。
100
⼊⼒の処理
スクリプトへの⼊⼒は、純粋な 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 オブジェ
クトのリストを取得し、適切な CSV 出⼒を sys.stdout に書き込みます。
データを出⼒するには、以下の⽂字列を追加します。
splunk.Intersplunk.outputResults(results)
スクリプトの出⼒は、純粋な CSV であるとみなされます。エラーが発⽣した場合は、1 つの「ERROR」列と 1
つの⾏ (⾒出し⾏の他に)、およびメッセージのコンテンツを含む CSV が返されます。
エラー処理
スクリプトに supports_getinfo = true が存在している場合を除き、スクリプトに渡される引数 (sys.argv 内) は、
サーチ⾔語内でコマンドの起動に使⽤された引数と同じになります。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 にこれらの属性を設定することもできます。
S pl u nk E nt er pr ise へのカスタムコマンドの追加
重要
このページの情報は、Intersplunk APIを使⽤して作成されたカスタムサーチコマンドを所持するユーザーのみに
提供しています。
ただし、新たなカスタムサーチコマンドの作成は、Splunk Python SDK サーチコマンド API を使⽤して⾏うこ
とができます。Splunk 開発者向けポータルの「カスタムサーチコマンドの作成⽅法」を参照してください。
サーチコマンドを作成したら、commands.conf を編集してそのコマンドのエントリを作成してくださ
101
い。commands.conf にエントリを追加しない限り、Splunk Enterprise がカスタムコマンドを認識することはありま
せん。各コマンドの設定オプションについては、『管理』マニュアルの commands.conf.spec を参照してください。
ここでは、ほんの⼀部のパラメータのみを取り上げています。
カスタムコマンドが App 固有の場合は、App のローカルディレクトリ $SPLUNK_HOME/etc/apps/<app_name>/local 内
の設定ファイルを編集、または作成します。システム全体でコマンドを利⽤できるようにするには、システムの
ローカルディレクトリ $SPLUNK_HOME/etc/system/local の commands.conf を編集、または作成します。
新しいスタンザの作成
内の各スタンザは、サーチコマンドの設定を表しています。カスタムスクリプトを単に有効にするス
タンザの例を以下に⽰します。
commands.conf
[<STANZA_NAME>]
filename = <string>
は、コマンド起動時にサーチ単語として指定するキーワードです。サーチコマンド名には、英数字 (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 Enterprise に追加
するコマンドのタイプを記述することができます。たとえば、⽣成コマンドか、ストリーミングコマンドか、また
はイベントを⽣成するコマンドかを指定するには、 generating と streaming を使⽤します。
generating = [true|false|stream]
コマンドが新たなイベントを⽣成するかどうかを⽰します。
stream の場合、そのコマンドは新しいイベントを⽣成し (generating = true)、ストリーム対応 (streaming
= true) となります。
デフォルトは偽 (false) です。
streaming = [true|false]
コマンドがストリーミング対応かどうかを⽰します。
デフォルトは偽 (false) です。
カスタムサーチコマンドがイベントを保持するか、または変換するかを指定するには、
使⽤します。
retainevents
パラメータを
retainsevents = [true|false]
コマンドがイベントを保持するか (sort/dedup/cluster コマンドが⾏うような処理) 、またはそれを変換す
るか (stats コマンドが⾏うような処理) を指定します。
デフォルトは偽 (false) です。
Splunk の 再 起 動
にカスタムコマンドを追加した後は、Splunk Enterprise を再起動する必要があります。カスタムコ
マンドスクリプトまたは commands.conf ファイル内の既存のコマンドのパラメータを変更した場合、再起動は必要
ありません。
commands.conf
サーチの例と⼿引き
このセクションの内容
このセクションでは、Answers やフィールドから収集された、各種サーチの例を簡単に紹介していきます。
複数のデータシリーズのレポート
異なる⽇の時間別合計の⽐較
動的フィールドのサイズの算出
Windows ディスク使⽤量の監視とアラート
サーチへのコメントの追加
サーチ⽂字列への最も柔軟なコメントの追加⽅法は、マクロを作成することです。サーチ⽂字列および単⼀コマン
ド⽂字列でマクロを複数回使⽤できます。サーチ内のコメントは、サーチパフォーマンスに影響を与えません。
これらのステップを実施するには、Splunk Web を利⽤するか、または
102
macros.conf
ファイルを編集します。
Splunk W eb で の コ メ ン ト マ ク ロ の 作 成
1.
2.
3.
4.
5.
6.
7.
8.
9.
Splunk Web で[ 設定] > [ 詳細サーチ] > [ サーチマクロ] へと進みます。
App コンテキスト が [ サーチレポート] (サーチ) に設定されていることを確認します。
[新規 ] をクリックして新しいサーチマクロを作成します。
宛先 App の [サーチ ] を選択します。
名前 の [co m m ent (1)] を⼊⼒します。
定義 の [""] (⼆重引⽤符) を⼊⼒します。
チェックボックス eval 式に基づく定義を使⽤しますか？ をマークします。
引数 の [テキスト ] を⼊⼒します。
[保存 ] をクリックします。
m ac r o s .c o nf フ ァ イ ル で の コ メ ン ト マ ク ロ の 作 成
macros.conf
ファイルで、次のマクロを追加します。
[comment(1)]
args = text
definition = ""
iseval = 1
コメントマクロの使⽤
コメントマクロを使⽤して、サーチ⽂字列の任意の場所にコメントを追加することができます。コメントの基本構
⽂は `comment("comment text")` です。
例
サーチへのコメントの追加
このサーチは、最近の地震をその発⽣深度に基づいて分類します。
source=usgs
| eval Description=case(depth<=70, "Shallow", depth>70 AND depth<=300,
"Mid",
depth>300, "Deep")
| stats count min(mag) max(mag) BY Description
インラインコメントを追加すると、サーチがより分かりやすくなります。
source=usgs `comment("source is the us geological service (usgs)")`
| eval Description=case(depth<=70, "Shallow", depth>70 AND depth<=300, "Mid",
depth>300, "Deep")
`comment("Creates field Description. Case function specifies earthquake
depths, returns Description values - Shallow, Mid, Deep.")`
| stats count min(mag) max(mag) `comment("Counts earthquakes, displays min
and max magnitudes")` BY Description
サーチのトラブルシューティングを⾏うコメントの使⽤
次のサーチは、各インデクサーのバイトを返すことを試みています。ただしサーチは、stats コマンド <split-by
clause> に誤ったフィールドが存在しています。
index=_internal source=*license* type=usage | stats sum(b) BY index
サーチの部分をコメントアウトし、問題の特定に役⽴たせることができます。他のオプションは、詳細モードで
サーチを実⾏することです。このサーチでは、サーチの stats 部はコメントアウトされます。
index=_internal source=*license* type=usage `comment("| stats sum(b) BY index")`
結果はフィールドの正確な名前を表⽰します。Index の代わりにフィールド名として idx を指定する必要があり
ます。
index=_internal source=*license* type=usage | stats sum(b) BY idx
(この例を提供した Splunk ユーザー Runals さんに感謝の意を表明します。)
Window s ディスク使⽤量の監視とアラート
このページは現在作業中で、まもなく更新される予定です。
この例では、ディスクの使⽤可能量が⼀定の割合を下回った場合にメールを送信する、基本条件アラート の設定
⽅法について取り上げています。
103
動的フィールドのサイズの算出
このサーチは、フィールド名やイベント数を事前に知らずに、イベント内のどのフィールドがもっともディスクス
ペースを消費しているのかを判断します。
シナリオ
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)(?
<FieldName>.*)"
| 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
説明
1. この例は、過去 15 分間の
index=_internal
内のすべてのイベントを取得するサーチから始まります。
index=_internal earliest=-15m latest=now
注意 ：これは、どのサーチ⽂字列や時間範囲とも置き換えることができます。
2. 次に、fieldsummary コマンドで、前に取得したイベント内のすべてのフィールドのサマリーを作成します。
... | fieldsummary
これは、以下のようになります。
3. 正規表現で各フィールドの値を複数値フィールドに値として抽出し、次に展開します。各値の⻑さがバイト数で
104
算出されます。
| rex field=values max_match=0 "value\":\"(?<values>[^\"]*)\","
| mvexpand values
| eval bytes=len(values)
4. ⼀部の例外を除き、フィールドの値が別の正規表現で抽出されます。
| rex field=field
"^(?!date|punct|host|hostip|index|linecount|source|sourcetype|timeendpos|timestartpos|splunk_server)(?
<FieldName>.*)"
5.
| stats count sum(bytes) as SumOfBytesInField values(values) as Values max(bytes) as MaxFieldLengthInBytes by
FieldName
| rename count as NumberOfValuesPerField
6.
| eventstats sum(NumberOfValuesPerField) as TotalEvents sum(SumOfBytesInField) as TotalBytes
7.
| eval PercentageOfTotalEvents=round(NumberOfValuesPerField/TotalEvents*100,2)
| eval PercentageOfTotalBytes=round(SumOfBytesInField/TotalBytes*100,2)
| eval ConsumedMB=SumOfBytesInField/1024/1024
| eval TotalMB=TotalBytes/1024/1024
8.
| table FieldName NumberOfValuesPerField SumOfBytesInField ConsumedMB PercentageOfTotalBytes PercentageOfTotalEvents
| addcoltotals labelfield=FieldName label=Totals
| sort - PercentageOfTotalEvents
105