Splunk Enterprise 6.2.1
ナレッジ管理マニュアル
作成：2015 年 1 ⽉ 30 ⽇ 午前 11 時 20 分
Copyright (c) 2015 Splunk Inc. All Rights Reserved
Table of Contents
ナレッジ管理にようこそ
Splunk Enterprise のナレッジとは？
Splunk Enterprise ナレッジを管理する訳
ナレッジ管理の前提条件
4
4
5
5
ナレッジオブジェクトの編成と管理
[設定] を使った Splunk Enterprise ナレッジの管理
ナレッジオブジェクトの監視と編成
ナレッジオブジェクトの命名規則の策定
Common Information Model アドオンの理解と使⽤
ナレッジオブジェクトの権限の管理
ナレッジオブジェクトの無効化または削除
6
6
7
8
8
9
11
データの解釈：フィールドとフィールドの抽出
フィールドについて
Splunk Enterprise がフィールドを抽出する時期
フィールド抽出ユーティリティを使ったフィールド抽出の作成
Splunk Web での [フィールドの抽出] ページの使⽤
Splunk Web での [フィールド変換] ページの使⽤
設定ファイルを使ったサーチ時フィールド抽出の作成と管理
複数値フィールドの設定
計算済みフィールドの定義
デフォルトフィールドの使⽤
Splunk Enterprise の正規表現について
13
13
16
17
28
31
34
44
45
47
50
データ分類：イベントタイプとトランザクション
イベントタイプについて
類似イベントの分類とグループ化
Splunk Web でのイベントタイプの定義と管理
eventtypes.conf を使ったイベントタイプの設定
イベントタイプテンプレートの設定
トランザクションについて
トランザクションのサーチ
トランザクションタイプの設定
53
53
54
56
59
60
60
61
63
データの強化：ルックアップとワークフローアクション
ルックアップとワークフローアクションについて
フィールドルックアップを使ったイベントへの情報の追加
CSV と外部ルックアップの設定
KV ストア・ルックアップの設定
Splunk Web を使ったワークフローアクションの作成と管理
actions.conf を使ったワークフローアクションの設定
65
65
66
71
78
79
85
データの正規化：タグとエイリアス
タグとエイリアスについて
Splunk Web でのフィールド値のタグとエイリアス設定
タグの定義と管理
フィールドのエイリアスの作成
ホストフィールドのタグ設定
イベントタイプのタグ設定
85
85
86
87
89
90
91
データモデルの作成
データモデルについて
91
91
データモデルの管理
データモデルとオブジェクトの設計
オブジェクト属性の定義
⾃動抽出された属性の追加
eval 式属性の追加
ルックアップ属性の追加
正規表現属性の追加
Geo IP 属性の追加
96
101
107
110
112
113
116
118
サーチとピボットジョブの保存と共有
ジョブとジョブ管理について
Splunk Web を使ったジョブの保存と共有
[ジョブ] ページでのジョブの管理
サーチジョブ調査によるサーチジョブプロパティの表⽰
OS からのジョブの管理
119
119
120
123
124
128
データサマリーを使ったサーチの⾼速化
サマリーベースのサーチとピボットの⾼速化の概要
レポート⾼速化の管理
データモデルの⾼速化
サマリーインデックスを使ったレポート効率の向上
サマリーインデックスのギャップの管理
サマリーインデックスの設定
バッチモードサーチの設定
129
129
132
141
148
152
154
157
ナレッジ管理にようこそ
Splunk Enterprise のナレッジとは？
Splunk Enterprise は、お客様の IT データの詳細や⼤規模なパターンを判別するために役⽴つ、強⼒なサーチ/分
析エンジンです。Splunk Enterprise を使⽤する場合、単にログファイル内の個別のエントリを参照するのではあ
りません。それらのデータが保有している情報を総合的に活⽤して、IT 環境を総合的かつ詳細に把握することが
できます。
Splunk Enterprise はお客様の IT データ (イベント、フィールド、タイムスタンプなど) からさまざまな知識 (ナ
レッジ) を抽出して、より理解、把握しやすく、有益な情報を導き出せます。このような情報の⼀部は、Splunk
Enterprise が IT データのインデックスを作成する時 (インデックス時) に抽出されます。しかし、この情報の⼤
半は「サーチ時」に Splunk Enterprise とユーザーの両⽅により作成されます。あらかじめ抽出する情報を決め
るまたは分析しておく、データベースまたはスキーマベースの分析ツールと違い、Splunk Enterprise では raw
データから必要に応じて動的にナレッジを抽出することができます。
Splunk Enterprise を使⽤するにつれて、イベントタイプ、タグ、ルックアップ、フィールド抽出、ワークフロー
アクション、保存済みサーチなどの、さまざまな Splunk Enterprise ナレッジオブジェクトが作成されていきま
す。
Splunk Enterprise のナレッジは、IT データのさまざまな側⾯を発⾒/分析するための各種ツールと考えることが
できます。たとえば、イベントタイプにより類似のイベントを⼿軽に分類、グループ化して、それを使って厳密に
定義されたイベントのサブグループに対して分析的サーチを実施できます。
『ナレッジ管理』マニュアルでは、Splunk Web および設定ファイルを使った⼀連のナレッジオブジェクトの管
理⽅法、およびナレッジを使った現実世界の問題の解決⽅法について説明していきます。
Splunk Enterprise ナレッジは、5 つのカテゴリに分類できます。
データの解釈：フィールドおよびフィールドの抽出 - フィールドとフィールドの抽出は、Splunk
Enterprise でもっとも使⽤されるナレッジです。IT データから Splunk Enterprise が⾃動的に抽出する
フィールドは、raw データに意味をもたらし、⼀⽬⾒ただけでは把握できないデータをどのように扱えば良
いかを明らかにします。⾃分で⼿動抽出したフィールドを活⽤すれば、情報の価値と意味をさらに拡張、強
化できます。
データ分類：イベントタイプとトランザクション - イベントタイプとトランザクションを使って、関連す
る複数の類似イベントをグループ化できます。イベントタイプはサーチで検出された⼀連のイベントをグ
ループ化します。⼀⽅トランザクションは、⼀定期間内に発⽣した概念的に関連しているイベントの集合体
です。
データの強化：ルックアップとワークフローアクション - ルックアップとワークフローアクションは、
データの有⽤性をさまざまな⽅法で拡張する、ナレッジオブジェクトのカテゴリです。フィールドルック
アップにより、静的なテーブル (CSV ファイル) や Python ベースのコマンドなどの、外部データソースか
らフィールドを追加することができます。ワークフローアクションにより、データ内のフィールドと他のア
プリケーションや Web リソース間の対話操作を⾏えます (例：IP アドレスを含むフィールドの WHOIS
ルックアップ)。
データの正規化：タグとエイリアス - タグとエイリアスは、⼀連のフィールド情報を管理、標準化するた
めに使⽤されます。タグとエイリアスを使って⼀連の関連するフィールド値をグループ化したり、抽出した
フィールドにその特性を表すタグを指定したりすることができます。たとえば、特定の場所 (例：建物や市
など) にある⼀連のホストからのイベントをグループ化するには、単純に各ホストに同じタグを設定しま
す。また、異なるフィールド名を使⽤する 2 つの異なるソースに同じデータを参照させるには、エイリアス
を使ってデータを標準化します (例：clientip にエイリアス ipaddress を設定)。
データモデル - データモデルは、1 つまたは複数のデータセットを表しています。ユーザーはピボットツー
ルを活⽤して、Splunk Enterprise のサーチ⾔語を使⽤することなく、有益なテーブル、複雑な視覚エフェ
クト、および確個たるレポートを、素早く作成することができます。データモデルは、インデックスデータ
のフォーマットとセマンティクスを完全に理解しているナレッジ管理者により設計されています。⼀般的な
データモデルは、ルックアップ、トランザクション、サーチ時フィールド抽出、および計算済みフィールド
を含めて、このマニュアルに記述されている他のナレッジオブジェクトタイプを活⽤しています。
『ナレッジ管理』マニュアルには、以下の章も含まれています。
サーチおよびピボットジョブ - サーチおよびピボットジョブは、基本的には個別に実⾏したサーチやピ
ボットの成果物です。これは保存するか、または他者と共有しない限り、10 分間で削除されます。ナレッ
ジ管理者は、[ジョブ] ページで最近実⾏されて保存されたジョブを確認、管理することができます。
サマリーベースのレポートとデータモデル - サーチやピボットの完了に時間がかかる場合は、Splunk
Enterprise が提供するサマリーベースの⾼速化⼿法を利⽤して、処理を⾼速化することができます。この章
は、レポート⾼速化 (サーチの場合)、データモデル⾼速化 (ピボットの場合)、およびサマリーインデックス
(特殊なサーチの場合) について説明しています。
この時点で、「なぜ Splunk Enterprise ナレッジを管理する必要があるの？」という疑問が湧く⽅もいるでしょ
う。その答えについては、この章の次のトピック「Splunk Enterprise ナレッジを管理する訳」を参照してくださ
い。
ナレッジ管理者は、最低でもデータ取り込み設定、イベントの処理、およびインデックス作成の概念に関する基本
的な知識を理解しておく必要があります。詳細は、この章の 3 番⽬のトピック「ナレッジ管理の前提条件」を参
照してください。
PDF を作成
このマニュアルの PDF 版が欲しい場合は、このページの⽬次の左下にある⾚い [Download the Knowledge
Manager Manual as PDF ] リンクをクリックしてください。PDF 版のマニュアルがその場で作成されます。
作成された PDF は後で利⽤するために保存、印刷することができます。
4
Splunk Enterprise ナレッジを管理する訳
Splunk Enterprise デプロイ環境内で、かなり⼤量のナレッジオブジェクトを保有する必要がある場合、そのナ
レッジの管理が重要になります。このことは、特に多数の Splunk Enterprise ユーザーが存在している組織、そ
して多数のチームが Splunk Enterprise で作業を⾏っている場合に当てはまります。ユーザー数が増加すると、
Splunk Enterprise ナレッジも増加していきます。
このような状況を放置すると、ユーザーが⼤量のオブジェクトを誤った⽅法で調査したり、名前の競合が発⽣した
り、不適切に App/権限が割り当てられたオブジェクトの使⽤に悪戦苦闘したりする可能性があります。さらに
は、システム内のどこかにすでに存在しているのに、レポートやフィールド抽出などの、類似のオブジェクトの作
成に貴重な時間を費やしてしまう可能性があります。
Splunk Enterprise 管理者は、このようなナレッジを集中管理します。ナレッジを管理することには以下のような
利点があります。
チーム、部⾨、およびデプロイ環境全体の、ナレッジオブジェクト作成と使⽤を管理、監督する。 ⼤
規模な Splunk Enterprise デプロイ環境で多数のチームが作業を⾏っている場合、時間の経過に伴い各チー
ムがすでの他のチームが作成したオブジェクトと同じようなオブジェクトを再び独⾃に開発するような、
「再作成の輪」ができていることに気が付くことでしょう。ナレッジ管理者は、オブジェクトの作成をモニ
ターして、役に⽴つ「汎⽤⽬的」オブジェクトをデプロイ環境の⼀部または全体で共有することにより、こ
のような無駄を最低限に抑えることができます。
詳細は、このマニュアルの「ナレッジオブジェクトの監視と編成」を参照してください。
イベントデータの標準化。 単純に⾔うと、時間の経過とともにナレッジオブジェクトは増加していきま
す。Splunk Enterprise はデータインデックスをベースにしておりデータベースではありませんが、標準化
の基本原則はそのまま適⽤されます。どんなに堅牢でよく使われている Splunk Enterprise 環境でも、同じ
フィールドに多数のタグが付けられると、分かりにくいオブジェクトになってしまい、ユーザーに混乱と⾮
効率をもたらす可能性があります。このマニュアルでは、ナレッジオブジェクトライブラリに、⼀定の命名
規則を導⼊し、Splunk Enterprise の Common Information Model を採⽤することによる標準化のコツを
説明しています。
詳細は、「ナレッジオブジェクトの命名規則の策定」を参照してください。
設定ファイルを使ってナレッジオブジェクトを管理する。 ナレッジ管理の達⼈は、Splunk Enterprise
ナレッジを管理するために、設定ファイルを活⽤しています。ナレッジオブジェクトの設定に、設定ファイ
ルを利⽤する⽅が効率的なさまざまな事例が存在しています。このマニュアルでは、このような⽅法でのナ
レッジの利⽤について取り上げています。
設定ファイルを使った Splunk Enterprise ナレッジの管理⽅法については、このマニュアルの「インデック
ス・ファイルを使ったサーチ時フィールド抽出の作成と管理」を参照してください。
ピボットユーザー向けのデータモデルの作成。 Splunk Enterprise は、⻑くて複雑になりがちなサーチ⽂
字列を作成することなく、テーブル、グラフ、およびダッシュボードを素早く作成したいユーザー向けに、
ピボットツールを提供しています。ピボットツールは、データモデルを活⽤しています。データモデルがな
いと、ピボットで何もレポートを作成することはできません。データモデルは Splunk Enterprise ナレッジ
管理者が設計します。ナレッジ管理者は、インデックスされたデータの形式や仕組みを理解し、Splunk
Enterprise のサーチ⾔語に習熟している⼈です。
データモデルのアーキテクチャと使⽤に関する概要については、このマニュアルの「データモデルについ
て」を参照してください。
サマリーベースのサーチおよびピボット⾼速化ツールの設定や利⽤の管理。 データが⼤量だと、サーチ
実⾏、レポート実⾏、ピボットの使⽤など、Splunk Enterprise のパフォーマンスが低下する可能性があり
ます。ナレッジ管理者は、レポート⾼速化 、データモデル⾼速化、およびサマリーインデックス を活⽤し
処理を⾼速化することで、デプロイ環境内の各チームに対して、結果を素早く効果的に⼊⼿できるように⼿
助けすることができるようになります。このマニュアルでは、これらの機能が確実かつ効果的に利⽤される
ように、これらの⾼速化戦略を集中管理するための⽅法を説明しています。
詳細は、このマニュアルの「サマリーベースのサーチとピボット⾼速化の概要」を参照してください。
ナレッジ管理の前提条件
ナレッジ管理作業の⼤半は、「サーチ時」のイベント操作に関連しています。⼀般的なナレッジ管理者は、データ
⼊⼒の設定、イベント処理アクティビティの調整、デフォルトのフィールド抽出の問題の修正、インデックスの作
成と管理、転送と受信の設定などの、イベントのインデックス作成前に⾏われる作業には注意を払いません。
ただし、ナレッジ管理者はこのような「Splunk Enterprise 管理者」の概念を理解しておくことをお勧めします。
このような知識をしっかりと理解しておくことで、適切な⽅法でナレッジ管理を⾏えるだけでなく、何らかの問題
が発⽣したような場合にも的確に対処することができます。
ここでは、ナレッジ管理者の⽅に必要な「管理者」としての知識を得るために役⽴つ、いくつかのトピックを紹介
します。
Splunk App の利⽤： デプロイ環境で複数の Splunk Enterprise App を使⽤している場合、それらの編成
⽅法や App の管理⽅法を理解しておく必要があります。『管理マニュアル』の「App とは」、「App の
アーキテクチャとオブジェクトの所有権」、および「App の管理」を参照してください。
設定ファイルの管理： 設定ファイルはどこにあるのでしょう？どのように編成されているの？各設定ファ
イルの優先順位は？このような疑問については、『管理マニュアル』の「設定ファイルについて」と「設定
ファイルの優先度」を参照してください。
Splunk のインデックス作成： インデックスとは何でどのように機能するのでしょうか？「インデックス
時」と「サーチ時」の違い、そしてなぜこのように区別されているのでしょうか？『インデクサーとクラス
5
タの管理』の「インデックスとインデクサーについて」およびそれ以降の章を参照してください。特にイン
デックス時とサーチ時の違いについてはしっかりと理解してください。
Splunk へのイベントデータの取り込み： Splunk Enterprise のデータ取り込みに関する基本的な概念を
理解しておく必要があります。『Getting Data In』マニュアルの「What Splunk can index」および他のト
ピックを参照してください。
転送と受信の設定の理解： フォワーダーとレシーバーを利⽤している場合、それらがどのように導⼊され
ているのかを理解しておくと、ナレッジの管理⽅針の策定に役⽴ちます。概要については、『データの転
送』マニュアルの「転送と受信について」を参照してください。
イベント処理の理解： Splunk Enterprise がデータのインデックスを作成する前の「解析」⽅法を理解し
ておくことをお勧めします。このような知識は、イベントデータに関する問題や「インデックス時」のイベ
ント処理に関する問題をトラブルシューティングするために役⽴ちます。『Getting Data In』マニュアルの
「Overview of event processing」およびその他の関連記事を参照してください。
デフォルトのフィールド抽出： フィールド抽出の⼤部分はサーチ時に⾏われますが、特定のデフォルト
フィールドはインデックス時に抽出されます。ナレッジ管理者は、主にサーチ時のフィールド抽出に注⽬し
ますが、デフォルトのフィールド抽出の管理⽅法も理解しておくと便利です。また、Splunk Enterprise が
各イベントに対して適⽤する、host、source、および sourcetype フィールドの問題に関するトラブルシュー
ティングにも役⽴ちます。『データの取り込み』マニュアルの「デフォルトフィールドについて」を参照し
てください。
ユーザーとロールの管理： ⼀般的なナレッジ管理者は、ユーザーとロールの設定に直接関与することはあ
りません。ただし、デプロイ環境内でどのように設定されているのかを理解しておくと、各ユーザーグルー
プ間でのナレッジの共有と利⽤の促進に役⽴ちます。詳細は、『管理マニュアル』の「ユーザーとロールに
ついて」および他の関連する記事を参照してください。
ナレッジオブジェクトの編成と管理
[設定] を使った Splunk Enterprise ナレッジの管理
社内で Splunk Enterprise が使われるに従って、イベントデータ の基本セットにナレッジ が追加されていきま
す。たとえばあなたや同僚達は以下のような作業を⾏うことでしょう。
サーチ の保存とスケジュール。
フィールドへのタグ の追加。
⼀連のイベントをグループ化した、イベント・タイプ やトランザクション の定義。
ルックアップ とワークフロー・アクション の作成。
ナレッジ・オブジェクト の作成プロセスはゆっくりと始まりますが、ユーザーが Splunk Enterprise を⻑く使っ
ていくにつれて複雑になってしまう可能性があります。ユーザーがすでに存在しているサーチを作成したり、不要
なタグを追加したり、冗⻑なイベント・タイプを開発したりするような状況は、簡単に発⽣してしまいます。ユー
ザー数が少ない場合は、これがさほど問題にならないこともあります。しかし、時間の経過に伴いこのような問題
が蓄積していくと、余計な誤解や混乱を招いたり、繰り返し作業を⾏わなければならない可能性もあります
この章では、[設定] の [ナレッジ] ページを使った、Splunk Enterprise 内のナレッジ・オブジェクトの管理⽅法
について説明していきます。[設定] を利⽤すれば、どのようなナレッジオブジェクトが現在作成されているか、誰
が作成しているのか、そして (ある程度ですが) どのように使⽤されているのかを把握、考察することができま
す。
[設定] では以下の作業を⾏えます。
必要に応じて最初から、またはオブジェクトを複製して、新たなナレッジ・オブジェクトを作成する。
他のユーザーが作成したナレッジ・オブジェクトをレビューして、無駄を減らしたり、正しい命名規則が使
⽤されているかを確認したりする。
不要な、または不出来なナレッジ・オブジェクトを、それが下流での依存関係を作り出す前に削除する。
ナレッジ・オブジェクトが特定の作業グループ、ロール、App だけでなく、共有して他のグループ、ロー
ル、他の App のユーザーなどにも利⽤させる価値があるかどうかを確認する。
注意： この章では、ナレッジ管理者が Admin ロールまたは同等の権限を持つロールを保有していることを前提に
しています。
この章には、以下の項⽬について説明しているトピックが含まれています。
ナレッジオブジェクトコレクションの整合性と規律の維持。
理解/使⽤しやすくするための、ナレッジオブジェクトの命名規則の策定。
イベントデータを正規化する Common Information Model アドオンの使⽤。
ナレッジオブジェクトの権限の管理。特定の App のユーザー、特定のロールを持つユーザー、またはすべ
ての App のユーザー (「グローバル」権限) が、ナレッジ・オブジェクトを利⽤できるようにします。
ナレッジオブジェクトの無効化または削除。ナレッジ・オブジェクト削除の制限事項、および下流の依存関
係を持つナレッジ・オブジェクトを削除することのリスクを理解します。
[設定] の代わりに設定ファイルを使ったナレッジの管理
前のリリースの Splunk Enterprise では、ユーザーは設定ファイルを直接編集して、ナレッジオブジェクトを追
加、更新、または削除していました。現在は、それらの設定ファイルを更新するためのグラフィカルなインター
フェイスを提供する、[設定] の [ナレッジ] ページをご利⽤いただけます。
Splunk Enterprise 管理者は、設定ファイルの変更⽅法を学習することをお勧めします。設定ファイルを理解する
ことには、以下のような利点があります。
6
設定ファイル・レベルでの機能を理解しておけば、Splunk Web で何を⾏っているのかをより詳細に理解で
きます。特に [フィールドの抽出] および [フィールド変換] ページで作業を⾏う場合にこれが当てはまりま
す。
特定のナレッジ・オブジェクト・タイプを管理するには、設定ファイルを変更する必要があります。
古くなった、冗⻑な、または不適切なナレッジ・オブジェクトの⼀括削除は、設定ファイルを使ってのみ⾏
えます。
直接設定ファイルを編集する⽅が効率的なことがあります。たとえば、⻑期間に渡って設定ファイルを利⽤
し、それを熟知している Splunk Enterprise 管理者の⽅は、設定ファイルを使った Splunk Enterprise ナ
レッジの管理作業をすでに理解していることでしょう。また、設定ファイルでできるきめ細かな調整を⾏い
たいユーザーも存在しています。
ナレッジ管理マニュアルには、設定ファイルを使った各種ナレッジオブジェクトタイプの取り扱い⽅法が記載され
ています。詳細は、タイプに応じた各トピックを参照してください。
Splunk Enterprise の設定ファイルに関する全般情報については、管理マニュアルの以下のトピックを参照してく
ださい。
設定ファイルについて
設定ファイルの優先度
管理マニュアルには、Splunk Enterprise 内のすべての設定ファイルの
ファイルの参考資料も⽤意されています。
.spec
と
.example
ファイルを含む、設定
ナレッジオブジェクトの監視と編成
ナレッジ管理者は、Splunk Enterprise 環境内のナレッジオブジェクトコレクションを定期的にチェックする必要
があります。以下の事項に注意する必要があります。
命名規則違反
重複/無駄
他のユーザーと共有した⽅が良いかどうか
古くなったまたは貧弱な設計のため無効化/削除するかどうか
定期的にナレッジオブジェクトをチェックすることで、異常を検出したり、それに起因する問題を事前に防⽌する
ことができます。
注意： このトピックでは、ナレッジ管理者が Admin ロールまたは同等の権限を持つロールを保有していることを
前提にしています。
例：タグの維持
⼀般的に Splunk Enterprise 環境では、フィールド/値の集合体にサーチを実⾏するために⽤いられるタグ が数多
く作成されます。ただし、時間の経過とともに似たような名前のタグを使っても、それぞれがまったく別個の結果
を⽣み出すようになることも珍しくはありません。このような状況は⾮常に混乱を招き、また不満の原因にもなっ
てしまいます。
ここでは、タグを正常な状態に維持するための管理⼿順について説明していきます。この⽅法は、他のタイプのナ
レッジオブジェクトにも応⽤できます。
1. 1. [設定] > [タグ] > [タグ名別表⽰] に移動します。
2. 同じ App に所属している (またはすべてのユーザーが利⽤できるようになっている)、類似のまたは重複してい
る名前を持つタグを探します。たとえば、同じ App 内に authentication と authentications のような類似のタグが
あるけれども、⽚⽅のタグには別のタグとはまったく異なるフィールド/値のペアセットが設定されている場合が
あります。
また、crash と Crash のように、⼤⽂字/⼩⽂字が違うだけで同名のタグが使われていることもあるでしょう。タグ
では⼤⽂字と⼩⽂字が区別されるため、Splunk Enterprise はこれらのタグを個別のナレッジオブジェクトと認識
します。
[App コンテキスト] に「すべて」を設定している場合は、別な App に所属するタグが同名であってもそれは正
常であることに注意してください。⼀般的にはこのような状況は許容できるものです。たとえば、Windows App
の authentication タグには、UNIX App の authentication タグとまったく異なるフィールド/値のペアが設定され
ていることも珍しくはありません。
3. 適切な権限がある場合は、⾒つかった重複するタグや古くなったタグを、無効にするかまたは削除してくださ
い。ただし、オブジェクトに依存関係があって、それによって影響を受けるオブジェクトがある可能性があ
ることに注意してください。 タグがレポート、ダッシュボードサーチ、他のイベントタイプ、またはトランザク
ション内で使⽤されている場合、タグを削除するとそれらのオブジェクトが機能しなくなってしまいます。また、
ある App コンテキストに所属しているオブジェクトを他の App コンテキストに移動する場合にも、問題が発⽣
する可能性があります。
詳細は、このマニュアルの「ナレッジオブジェクトの無効化または削除」を参照してください。
4. 新しい独⾃の名前を持った代わりのタグを作成する場合は、置換するタグと同じフィールド/値のペアが設定さ
れていることを確認してください。
オブジェクト命名上の問題を防⽌する命名規則の使⽤
Splunk Enterprise 導⼊の初期段階にナレッジオブジェクトの命名規則を制定すれば、オブジェクトの命名に関す
る問題を防⽌することができます。詳細は、「ナレッジオブジェクトの命名規則の策定」を参照してください。
7
ナレッジオブジェクトの命名規則の策定
ナレッジオブジェクトの命名規則を策定しておくことをお勧めします。社内の全ユーザーが策定した命名規則を遵
守すれば、それらの違いや⽬的を⼀⽬で把握でき、より使いやすくなることでしょう。
Splunk Enterprise のあらゆる種類のナレッジオブジェクトに対して命名規則を策定できます。命名規則はオブ
ジェクトの編成管理に役⽴つだけでなく、似たような⽤途を持つレポート、イベントタイプ、およびタグのグルー
プを区別するためにも役⽴ちます。また、オブジェクトを使⽤するチームや場所、利⽤している技術、使⽤⽬的な
どの、オブジェクトに関するさまざまな事項を判断するためにも役⽴ちます。
Splunk Enterprise 環境に早めに命名規則を導⼊すれば、将来的な混乱を回避することができます。
Com m on Inform a tion Mod el アドオンの使⽤
Common Information Model (CIM) アドオンは、イベントデータをパーシング、分類、および正規化するための
標準的な⼿段を提供しています。これには、データモデルとしてアドオンに実装された、カスタムフィールドとタ
グの各種カテゴリが含まれています。
CIM アドオンを使って、フィールドとタグを確実に標準化、正規化することができます。CIM のデータモデル実
装は、フィールドの名前または別名が正しく設定され、データの各種カテゴリに関するレポートを素早く作成でき
るようにするために役⽴ちます。
ここの Splunk Apps から Common Information Model アドオンをダウンロードできます。CIM アドオンの詳
細な概要については、Common Information Model アドオン製品のマニュアルを参照してください。
例 - レポートの命名規則の設定
あなたは会社のシステムエンジニアグループで働いています。また、Splunk Enterprise 環境のナレッジ管理者と
して、レポートの命名規則を策定しようとしています。
いろいろと考慮した結果、以下のような命名規則を作成することに決定しました。
グループ ：サーチを保存したユーザーが所属するグループ。
サーチタイプ ：サーチのタイプ (アラート、レポート、サマリーインデックス設定) を⽰します。
プラットフォーム ：サーチのプラットフォームを⽰します。
カテゴリ ：プラットフォームの関連するエリアを表します。
時間間隔 ：サーチの実⾏間隔 (スケジュールサーチの場合は、サーチの実⾏時刻)。
説明 ：サーチの説明と⽬的、可能な限り 1〜2 つの単語に限定。サーチ名の⼀意性を保証します。
グルー
プ
SEG
NEG
OPS
NOC
サーチタイ
プ：
アラート
レポート
サマリー
プラットフォー
ム
Windows
iSeries
ネットワーク
カテゴリ
時間間隔
説明
Disk
<arbitrary> <arbitrary>
Exchange
SQL
Event log
CPU
Jobs
Subsystems
Services
Security
この命名規則を使ったレポートの例：
SEG_Alert_Windows_Eventlog_15m_Failures
SEG_Report_iSeries_Jobs_12hr_Failed_Batch
NOC_Summary_Network_Security_24hr_Top_src_ip
Common Information Model アドオンの理解と使⽤
Common Information Model アドオンは、ほとんどのログファイルが 2 つのコンポーネントに分類できるという
アイディアをベースにしています。
フィールド
イベント・カテゴリ・タグ
ナレッジ管理者は、これらの 2 つのコンポーネントに基づいてログ・ファイルを Splunk で利⽤しやすいように
設定できます。また、準拠していないログを正規化して、同様のスキーマを適⽤することができます。Common
Information Model は、Splunk が⼤部分の IT データを処理する際に使⽤する標準フィールドおよびイベント・
カテゴリ・タグを記述しています。
従来 Common Information Model は、⼀連のテーブルとして表されていました。ユーザーはこのテーブルを使っ
てデータを正規化することで、異なるソースまたはベンダーからの同じようなイベントに、同じフィールド名とイ
ベント・タグを使⽤することができました。
のちに当社は、Common Information Model を更新しました。現在では CIM テーブルをデータモデルとして実
装したアドオンとして設定されています。これらのデータモデルは 2 種類の⽅法で使⽤できます。
まず、フィールドとタグが正しく正規化されたかどうかをテストするために利⽤できます。
データが正規化されたことを確認したら、モデルを使ってピボット機能でレポートやダッシュボードを⽣成
することができます。
8
ここの Splunk Apps から Common Information Model アドオンをダウンロードできます。CIM アドオンの詳
細な概要については、Common Information Model アドオン製品のマニュアルを参照してください。
ナレッジオブジェクトの権限の管理
注意： このトピックでは、ナレッジ管理者が Admin ロールまたは同等の権限を持つロールを保有していることを
前提にしています。
ナレッジ管理者は、ナレッジオブジェクト権限を設定して、Splunk Enterprise 環境内のさまざまなナレッジオブ
ジェクトへのアクセスを制限/拡張することができます。
場合によっては、特定のナレッジオブジェクトを特定のロール、特定の App 内でのみ使⽤させるようにします。
また逆に、特定の⼈のみが利⽤していたナレッジオブジェクトを、すべてのユーザーがすべての App で利⽤でき
るようにすることもあります。ナレッジ管理のあらゆる側⾯に当てはまりますが、これらのアクセス制限/拡張が
暗黙的に意味することを⼊念に検討する必要があります。
Splunk Enterprise ユーザーがレポート、イベントタイプ、トランザクション、または他のナレッジオブジェクト
を作成した場合、当初はそのユーザーのみがそれを利⽤できます。そのオブジェクトを他のユーザーも利⽤できる
ようにするには、次のような⽅法があります (適切な権限がある場合)。以下の作業を⾏えます。
ナレッジオブジェクトをグローバルにすべての App のユーザーが利⽤できるようにする (オブジェクトを
「昇格」する)。
ナレッジオブジェクトをすべての App のすべてのユーザーに利⽤できるようにする。
ユーザーまたはロール単位に、オブジェクトをグローバルまたは App 固有のものに制限 (または拡張) す
る。
ロールに対して App レベルで読み取り/書き込み権限を設定し、ユーザーに⾃⼰が所有していないオブジェ
クトを共有または削除する。
デフォルトでは、 power または admin ロールがあるユーザーのみが、ナレッジオブジェクトを共有、昇格
することができます。 これにより、あなた (および同僚のナレッジ管理者) は、新しいナレッジオブジェクトの共
有を承認できる権限を持つことになります。
他のロールに権限の設定を許可する⽅法については、「power および admin 以外のロールへの権限の設定とオブ
ジェクトの共有の許可」を参照してください。
権限がナレッジオブジェクトの使⽤に与える影響
これらの選択肢がナレッジオブジェクトの使⽤に与える影響を理解するために、架空の Network Security (ネッ
トワークセキュリティ) App のユーザーである Bob を考えてみましょう。彼は、admin レベルの「Firewall
Manager」ロールを保有しており、ファイアウォール関係のイベントを探す新しいイベントタイプ firewallbreach
を作成しました。ここで、発⽣する権限関連の問題と、その対処⽅法と結果を以下に⽰します。
問題
対処
結果
Bob が firewallbreach を作
成した時点では、彼のみが
それを利⽤できます。その
他のユーザーは参照するこ
とも使⽤することもできま
せん。そこで Bob は、
Network Security App を
使⽤する他の同僚とこれを
共有することにしました。
Bob は firewallbreach イベント
タイプの権限を更新して、その
ロールに関係なく Network
Security App のすべてのユー
ザーが利⽤できるようにしまし
た。また、新たなイベントタイ
プを設定し、Network Security
のすべてのユーザーがその定義
内容を編集できるようにしまし
た。
Network Security App コンテキストで Splunk
を使⽤する任意のユーザーが、firewallbreach イ
ベントタイプを表⽰、利⽤、編集することができ
ます。同じ Splunk Enterprise 環境内の他の
App のユーザーは、そのイベントタイプの存在
を知りません。
その後ナレッジ管理者の
Mary が、Firewall
Manager ロールのユー
ザーのみが firewallbreach
イベントタイプを編集また
は更新できるようにする必
要があることに気が付きま
した。
そこで Mary は、イベントタイ
プの編集を Firewall Manager
ロールのユーザーのみに制限す
るようにしました。
Network Security App のユーザーは
firewallbreach イベントタイプをトランザクショ
ン、サーチ、ダッシュボードなどで利⽤すること
はできますが、ナレッジオブジェクトを編集でき
るのは、Firewall Manager ロールを持つユー
ザーと管理者レベルの権限を持つユーザー (ナ
レッジ管理者など) だけになります。他の App
コンテキスト内で Splunk を使⽤しているユー
ザーは、まだこのイベントタイプの存在を知りま
せん。
その後しばらくして、
Network Security App 内
で、便利な firewallbreach
イベントタイプを使い慣れ
てきた⼀部のユーザーが、
これを Windows App コ
ンテキスト内でも利⽤した
いと考えるようになりまし
た。
そこでナレッジ管理者にその旨
を依頼した所、firewallbreach イ
ベントタイプが昇格されてグ
ローバルに利⽤できるようにな
りました。
この Splunk Enterprise 環境の全員が、App コ
ンテキストに関係なく firewallbreach イベントタ
イプを使⽤できるようになりました。ただし、イ
ベントタイプ定義の更新は、管理者レベルのユー
ザーと Firewall Manager ロールを持つユーザー
に制限されています。
権限 - はじめに
ナレッジオブジェクトの権限を変更するには、以下の⼿順に従ってください。
1. Splunk Web で、権限を更新するナレッジオブジェクトタイプのページに移動します (例：[サーチとレポート]
や [イベントタイプ] など)。
9
2. 作成したナレッジオブジェクトを探して (必要に応じてページ上部のフィールドのフィルタリング機能を使⽤)、
それの [権限] リンクをクリックします。
3. 当該ナレッジオブジェクトの [権限] ページで、オブジェクトの権限の変更⽅法に応じて、以下のサブセクショ
ンで説明している作業を⾏います。
すべての App のユーザーに対してオブジェクトを利⽤できるようにする
オブジェクトを Splunk Enterprise 環境内のすべての App のユーザーにグローバルに利⽤させるには：
1. ナレッジオブジェクトの [権限] ページに移動します (上記の説明を参照)。
2. [オブジェクトの表⽰先] から、[すべての App] を選択します。
3. [権限] セクションの [全員] で、[読み取り] または [書き込み] 権限を選択します。
[読み取り] を選択した場合、ユーザーはオブジェクトを表⽰、使⽤することができますが、その定義を更新
することはできません。たとえば、ユーザーが特定のレポートに対して読み取り権限のみを保有している場
合、トップレベルのナビゲーションにレポートが表⽰され、それを実⾏することができます。たただし、
サーチ⽂字列の更新、時間範囲の変更、および変更内容の保存などの作業を⾏うことはできません。
[書き込み] 権限の場合、ユーザーはオブジェクトの表⽰、使⽤、および必要に応じてその定義情報を変更す
ることができます。
[読み取り] または [書き込み] のどちらも選択されていない場合、ユーザーはナレッジオブジェクトを参照す
ることも使⽤することもできません。
4. 権限の変更を保存します。
App のすべてのユーザーに対してオブジェクトを利⽤できるようにする
すべてのナレッジオブジェクトは、App に関連付けられています。新しいナレッジオブジェクトの作成時、その
時点の App コンテキストに関連付けられます。つまり、オブジェクトの作成時に [サーチとレポート] App を使
⽤した場合、そのオブジェクトは [設定] に [App] 列値が [サーチとレポート] として表⽰されます。このことは、
共有権限を App レベルに制限すると、[サーチとレポート] App のユーザーのみが利⽤できることを意味していま
す。
新しいオブジェクトを作成する場合、それをプライベートにする、現在使⽤している App のユーザーと共有す
る、またはグローバルにすべてのユーザーと共有することができます。App のユーザーがその App コンテキスト
にいる場合にのみ使⽤を制限する場合は、[この App のみ] 利⽤できるように App を指定します。
既存のオブジェクトに対する書き込み権限がある場合は、以下の⼿順に従って App のユーザーにのみ利⽤できる
ように権限を変更することができます。
1. ナレッジオブジェクトの [権限] ページに移動します (上記の「権限 - はじめに」を参照)。
2. [オブジェクトの表⽰先] から、[この App のみ] を選択します。
3. [権限] セクションの [全員] で、[読み取り] または [書き込み] 権限を選択します。
[読み取り] を選択した場合、ユーザーはオブジェクトを表⽰、使⽤することができますが、その定義を更新
することはできません。たとえば、ユーザーが特定のレポートに対して読み取り権限のみを保有している場
合、トップレベルのナビゲーションにレポートが表⽰され、それを実⾏することができます。たただし、
サーチ⽂字列の更新、時間範囲の変更、および変更内容の保存などの作業を⾏うことはできません。
[書き込み] 権限の場合、ユーザーはオブジェクトの表⽰、使⽤、および必要に応じてその定義情報を変更す
ることができます。
[読み取り] または [書き込み] のどちらも選択されていない場合、ユーザーはナレッジオブジェクトを参照す
ることも使⽤することもできません。
4. 権限の変更を保存します。
ナレッジオブジェクトの移動または複製
ある App のユーザーを、別の App に所属する特定のナレッジオブジェクトにアクセスできるようにしたいけれ
ども、そのオブジェクトをグローバルにすべての App とは共有させたくないような場合もあるでしょう。そのた
めには 2 種類の⽅法があります。オブジェクトを複製するか、またはオブジェクトを移動します。
複製 - ナレッジオブジェクトのコピーを作成します。コピーはオリジナルのオブジェクトとすべて同じ設定
を持っており、そのまま保持することも、修正することもできます。それを複製元オブジェクトと同じ App
内に保持することも、新しい App 内に配置することもできます。複製したオブジェクトをオリジナルと同
10
じ App に追加する場合、それには別の名前を指定シィオリジナルの名前と同じ名前を持つ同じタイプのナ
レッジオブジェクトが存在しない App にオブジェクトを追加する場合は、オリジナルの名前をそのまま保
持することができます。ご⾃分のロールがオブジェクトに対する書き込み権限を持たない場合でも、任意の
オブジェクトを複製することができます。
移動 - 既存のナレッジオブジェクトを他の App に移動します。現在の App からオブジェクトを削除して、
それを⽬的の App に配置します。その後、その権限をプライベート、グローバルに利⽤可能、またはその
App のユーザーのみが利⽤できるように設定することができます。App を移動できる能⼒は、App を削除
できるかどうかを決定するのと同じ権限に依存しています。あるナレッジオブジェクトを作成し、それが所
属している App に対する書き込み権限を持つ場合にのみ、そのナレッジオブジェクトを移動することがで
きます。
注意： ナレッジオブジェクトを移動して App コンテキストを切り替えると、それに関連する下流のオブジェクト
に影響する可能性があります。詳細は、このマニュアルの「ナレッジオブジェクトの無効化または削除」を参照し
てください。
[設定] ページの各種ナレッジオブジェクトタイプに対して、[複製] および [移動] コントロールが表⽰されます。
オブジェクトを複製または移動するには、リストからオブジェクトを探して、[複製] または [移動] をクリックし
ます。
App とロールによるナレッジオブジェクトアクセスの制限
この⽅法を使って、各種ナレッジオブジェクトの変更を特定のロールに限定することができます。特定のロールが
ナレッジオブジェクトを使⽤できるけれどもそれを更新できないように設定することができます。また、あるロー
ルを持つユーザーにオブジェクトを表⽰しないように設定することもできます。後者の場合、そのようなユーザー
には Splunk Web にオブジェクトは表⽰されず、それに対してサーチを実⾏しても結果は表⽰されません。
ロール別にナレッジオブジェクトの表⽰、更新を制限するには、オブジェクトの [権限] ページに移動してくださ
い。ロールのメンバーを以下のように設定したい場合：
オブジェクトを使⽤し、その定義を更新できるようにする場合 、そのロールに読み取りおよび書き込み
アクセスを割り当てます。
オブジェクトを使⽤できるけれども、更新できないようにする場合 は、そのロールに読み取りアクセス
のみを割り当てます ([全員] ロールの [書き込み] の選択が解除されていることを確認してください)。
ナレッジオブジェクトを表⽰せず、使⽤できないようにする場合 は、そのロールの [読み取り] と [書き
込み] の選択を解除します (また、[全員] ロールでもこれらの権限の選択を解除してください)。
Splunk Enterprise のロールベースの権限の詳細は、『セキュリティマニュアル』の「ロールベースのユーザーア
クセスについて」を参照してください。
Power と Admin 以外のロールの権限の設定とオブジェクトの共有を有効にする
Splunk Enterprise をそのままの状態で使⽤している場合、ナレッジオブジェクトに権限を設定できるロールは
Power と Admin のみです。他のロールにナレッジオブジェクトに対する権限の設定を⾏わせる場合は、 [App]
に移動して、特定の App の [権限] をクリックして、[権限] ページに移動します。このページでは、その App に
含まれるナレッジオブジェクトに読み取り/書き込みアクセスができるロールを設定することができます。ロール
に、サーチ、アラート、およびダッシュボードの共有を含めて、完全なナレッジオブジェクト権限の設定能⼒を与
えるには、Splunk Web での作成時にロールに 書き込みアクセス権を割り当てます。
ナレッジオブジェクトを共有するための権限の設定は、App レベルで制御されています。サーチのスケジュール
やデフォルトの⼊⼒設定の変更などのロール権限 とは接続されていません。
App 内でのナレッジオブジェクトに対する権限の設定をロールに許可する⽅法の詳細は、『Developing
Dashboards, Forms, and Views for Splunk Web』マニュアルの「Step 5: Set Permissions」を参照してくださ
い。
共有されていないオブジェクトを持つユーザーとロールの削除について
ユーザーが所属しているチームから離脱して、そのユーザーまたはロールを Splunk Enterprise システムから削
除する必要がある場合は、ユーザーまたはロールに所属している、ステータスが「プライベート」のナレッジオブ
ジェクトが失われないように注意する必要があります。これらのナレッジオブジェクトを保持したい場合は、ユー
ザーまたはロールを削除する前に、App またはグローバルレベルでそれを共有してください。
ナレッジオブジェクトの無効化または削除
Splunk Web でナレッジ・オブジェクトを削除できるかどうかは、⼀連の要素によって決まります。
Splunk Enterprise に最初から⽤意されている (または App で提供されている) デフォルトのナレッジ・オ
ブジェクトを削除することはできません。
ナレッジ・オブジェクト定義がデフォルトのディレクトリに存在している場合、Splunk Web を使ってそれ
を削除することはできません。無効にすることしかできません ([設定] でオブジェクトの [無効] をクリッ
ク)。App の local ディレクトリに存在するオブジェクトのみを削除できます。
⾃分が作成し、(⾃分または管理者レベルのユーザーにより) 共有されていないナレッジ・オブジェクトは常
に削除できます。
⾃分が作成したナレッジ・オブジェクトを他のユーザーと共有すると、それが所属する App への書き込み
権限がない限りそれを削除することはできなくなります (後述)。
他のナレッジ・オブジェクトを削除するには、ご⾃分のロールに以下の項⽬に対する書き込み権限が必要で
す。
ナレッジ・オブジェクトが所属している App。
ナレッジ・オブジェクト⾃⾝。
11
これは、グローバルに共有されているナレッジ・オブジェクトにも、ある App 内でのみ共有されているナ
レッジ・オブジェクトにも適⽤されます。すべてのナレッジ・オブジェクトは、その共有⽅法に関わらず特
定の App に所属しています。
⼀般的に App レベルの書き込み権限は、管理者レベルのユーザーにのみ与えられます。
注意： ロールに App に対する書き込み権限がないけれども、その App に所属するナレッジ・オブジェクトに対
する書き込み権限がある場合、それらのナレッジ・オブジェクトを無効にすることができます。ナレッジ・オブ
ジェクトの [無効] をクリックすると、ナレッジ・オブジェクトを削除した場合と同じ状態になりますが、無効に
されたナレッジ・オブジェクトがシステムから削除されることはありません。無効にされたナレッジ・オブジェク
トに対して書き込み権限を持つロールは、任意の時点で再有効化することができます。
データ・モデルにも同様のルールがあります。ロールにデータ・モデルの作成と他のユーザーとの共有を許可する
には、App に対する書き込みアクセス権を与える必要があります。この場合、データモデルを作成、共有できる
ユーザーは、基本的にナレッジ・オブジェクトを削除することもできます。詳細は、このマニュアルの「データモ
デルの管理」を参照してください (サブトピック「ロールへのデータモデル作成の許可」を参照)。
ロールに App への書き込み権限を与える
ロールに管理者レベルの権限がある場合、Splunk Web で App に対する書き込み権限をロールに割り当てること
ができます。
1. ページの上部にある [App] ドロップダウンメニューをクリックし、[App の管理] を選択して [App] ページに移
動します。
2. [App] ページで、書き込み権限を与える App を探して、[権限] をクリックします。
3. App の [権限] ページで、その App のナレッジオブジェクトの削除を許可するロールに対して [書き込み] を選
択します。
4. 変更内容を保存するには、[保存] をクリックします。
App の local.meta ファイルを更新して、App のロールベースの権限を管理することもできます。詳細は、
『Splunk Enterprise のセキュリティ』マニュアルの「管理コンソールと App へのアクセスの設定」を参照して
ください。
App に所属するナレッジ・オブジェクトを削除するための、ロールへの App に対する書
き込み権限の割り当て
ロールに App に対する書き込み権限が割り当てられたら、そのロールを持つユーザーは当該 App に所属するナ
レッジ・オブジェクトを削除することができます (ただし、削除するナレッジ・オブジェクトに対する書き込み権
限も必要です)。ナレッジ・オブジェクトがある App で共有されている場合でも、すべての App でグローバルに
共有されている場合でも、この作業は可能です。ナレッジ・オブジェクトがグローバルに共有されている場合で
も、それは特定の App に所属しています。
この⼿順は以下の事項を前提にしています。
⾃分のロールに管理者レベルの権限がある。
オブジェクト・レベルの権限を設定しようとしているロールに、そのオブジェクトが所属している App へ
の書き込み権限がある。
1. [設定] で、ナレッジ・オブジェクトの⼀覧ページに移動します。
2. App 名を選択する、または [App コンテキスト] の [すべて] を選択して、ロールが書き込み権限を持つ App
に所属しているオブジェクトを参照していることを確認します。
3. ⼀覧ページでロールに削除させるナレッジ・オブジェクトを探し、その [権限] リンクをクリックします。
4. ナレッジ・オブジェクトの権限ページで、ロールに対する [書き込み] を選択します。
この⼿順および前の⼿順に従った場合、このロールでナレッジ・オブジェクトを削除できるようになります。
下流と依存関係があるナレッジオブジェクトの削除
悪影響を与える可能性があるため、下流のオブジェクトと依存関係のあるナレッジオブジェクトの削除には注意を
払う必要があります。
たとえば、ある⼀般的なタグと重複しているタグが存在している場合を考えてみましょう。表⾯上はその重複する
タグを削除しても問題はないように思えます。しかし、とても良く利⽤されるイベントタイプがベースにしている
サーチに、その重複しているタグが使われていることもあります。そのようなイベントタイプが、ダッシュボード
パネルのベースサーチ、およびさまざまな他のダッシュボードパネルを実⾏するサーチが使⽤するサマリーイン
デックス へのデータ追加サーチの、2 つの重要なレポートで使⽤されている場合はどうなるでしょうか。このよ
うなタグを削除すると、イベントタイプが無効になるため、それに関連して下流で使われている他の保存済みサー
チなどにも影響してしまいます。
このような問題を回避するためにも、分かりにくい名前または不適切な定義のナレッジオブジェクトがデプ
ロイ環境に⼤きな影響を与える前に、早期段階で発⾒して取り除くことが重要になります。 特定のナレッジ
オブジェクトの下流の依存関係を判別する唯⼀の⼿段は、それがどこで使⽤されているのかを地道に探し出すこと
です。ナレッジオブジェクトの下流の依存関係を⼿軽に探し出す⽅法はありません。
ナレッジオブジェクトを本当に削除する必要がある場合に、その下流の依存関係を徹底的に調査して、対処できた
かどうか⾃信がない場合は、まずそれを無効にして影響があるかどうかを確認してください。数⽇たっても問題が
ないようなら、削除しても構いません。
12
設定ファイルでナレッジオブジェクトを削除
Splunk Web では、⼀度に 1 つのナレッジオブジェクトしか無効化/削除できません。⼤量のオブジェクトを無効
にする場合は、設定ファイルのナレッジオブジェクトに関するスタンザを直接削除するのが効率的です。システム
内には、設定ファイルが何種類か存在する場合もあることに注意してください。たいていの場合
は、$SPLUNK_HOME/etc/system/local/ の設定ファイルを編集してサイト全体に対するローカル変更を⾏うだけで⼗分
です。また、特定の App に対してのみ変更を⾏う場合は、$SPLUNK_HOME/etc/apps/<App_name>/local/ の設定ファイル
を編集します。
『管理マニュアル』の以下のトピックを読んで内容を理解しない限り、設定ファイルを編集しないでください。
設定ファイルについて
設定ファイルの優先度
データの解釈：フィールドとフィールドの抽出
フィールドについて
このページは現在も作業中です。順次更新されていく予定です。
フィールド はイベント・データ 内に、user_name=fred や ip_address=192.168.1.1 のような、サーチ可能な名前/値の
ペアで登場します。これは Splunk Enterprise 内のサーチ、レポート、データ・モデルのパーツとなっていま
す。イベント・データに対してサーチを実⾏すると、そのデータ内のフィールドが探されます。
注意： フィールド名はしばしばキーとして表現されます。KV はキー/値の省略語です。
以下のサーチを例に考えてみましょう。
status=404
このサーチは値が 404 のフィールド status を持つイベントを探します。このサーチを実⾏した場合、他の status
値を持つイベントは検索対象にはなりません。また、値が 404 の他のフィールドを持つイベントも検索対象にはな
りません。その結果、サーチ⽂字列に 404 を使⽤した場合よりも、このサーチではより絞り込まれた結果セットが
返されます。
イベント内でフィールドは、しばしば user_name=Fred のような key=value のペアで登場します。しかし、多くのイ
ベントでフィールドの値は固定的な区切られた位置に登場し、キーを識別できない場合があります。たとえ
ば、user_name の値が常にタイムスタンプと user_id 値の後に登場するイベントを考えてみましょう。
Nov 15 09:32:22 00224 johnz
Nov 15 09:39:12 01671 dmehta
Nov 15 09:45:23 00043 sting
Nov 15 10:02:54 00676 lscott
Splunk Enterprise は、カスタム・フィールド抽出を使って、これらのフィールドを識別することができます。
フィールドの抽出について
Splunk Enterprise がイベントを処理すると、そこからフィールドが抽出されます。このプロセスは、フィール
ドの抽出 と呼ばれています。
Splunk Enterprise はいくつかのフィールドを⾃動抽出する
Splunk Enterprise は、いくつかのフィールドをイベントから⾃動的に抽出します。到着したイベントのインデッ
クスを作成する際に、host、source、および sourcetype の値、タイムスタンプ、および他のデフォルト・フィール
ド が抽出されます。
また、イベント・データ内に登場するフィールドも、key=value のペアとして抽出されます。このキーと値の認識
と抽出のプロセスは、フィールド検出 と呼ばれています。サーチのパフォーマンスを向上するためにめに、
フィールド検出は無効にすることができます。
イベント内にフィールドがキーなしで登場した場合、Splunk Enterprise は正規表現と呼ばれるパターン・マッチ
ング・ルールを使って、それらのフィールドを完全なキーと値のペアとして抽出します。適切に設定した正規表現
を使⽤することで、前のサンプル・イベントから user_id=johnz を抽出することができます。Splunk Enterprise
には、正規表現を使ってイベント・データ内のフィールドを識別、抽出する、さまざまなフィールド抽出設定が⽤
意されています。
フィールド検出および⾃動フィールド抽出の例については、このマニュアルの「Splunk Enterprise がフィールド
を抽出する時期」を参照してください。
Splunk Enterprise の正規表現によるフィールドの抽出⽅法については、このマニュアルの「Splunk Enterprise
正規表現について」を参照してください。
データ内のすべてのフィールドを抽出するには、カスタム・フィールド抽出を作成する
13
Splunk Enterprise のサーチ機能を活⽤するには、追加のフィールド抽出を作成します。カスタム・フィールド抽
出により、Splunk Enterprise では⾃動的に検出されない、⾃分のニーズに合わせた情報を取得、追跡することが
できます。指定するフィールド抽出設定には、Splunk Enterprise に抽出するフィールドを検出する⽅法を知らせ
る、正規表現を定義する必要があります。
カスタム・フィールド抽出も含め、すべてのフィールド抽出は、特定の source、sourcetype、または host の値と関
連付けられます。たとえば、ip フィールド抽出を作成する場合、ip の抽出設定を sourcetype=access_combined に関
連付けます。
カスタム・フィールド抽出はサーチ時に⾏う必要があります。ただし、⾮常に希な環境下では、いくつかのカスタ
ム・フィールド抽出をインデックス時に⾏うようにすることもできます。詳細は、このマニュアルの「Splunk
Enterprise がフィールドを抽出する時期」を参照してください。
カスタム・フィールド抽出を作成する前にデータを理解する
フィールド抽出の作成を開始する前に、⽬的のデータの source、sourcetype、または host に関連するイベント・
データのフォーマットとパターンを正しく理解していることを確認してください。そのためには、たとえば [パ
ターン ] タブでデータに頻発するイベント・パターンを調査します。詳細は、『サーチ・マニュアル』の「[パ
ターン] タブを使ったイベント・パターンの識別」を参照してください。
同じソース・タイプの Apache Web アクセス・ログにある 2 つのイベントを以下に⽰します。
131.253.24.135 - - [03/Jun/2014:20:49:53 -0700] "GET /wp-content/themes/aurora/style.css HTTP/1.1" 200 7464
"http://www.splunk.com/download" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.0; Trident/5.0;
Trident/5.0)â€​
10.1.10.14 - - [03/Jun/2014:20:49:33 -0700] "GET / HTTP/1.1" 200 75017 "-" "Mozilla/5.0 (compatible; Nmap Scripting
Engine; http://nmap.org/book/nse.html)"
これらのイベントには異なる⽂字列/⽂字が含まれていますが、その形式は⼀貫しています。どちら
も、clientIP、status、bytes、method などのフィールドの値を⼀定の順序で表しています。
ここで「⼀定の」とは、常に method の値の後に URI の値が、URI の値の後に status の値が、status の値の後に
bytes が来ていることを意味しています。イベントのフォーマットが⼀貫した⼀定の形式で構成されている場合、
そこからさまざまなフィールドの値を正確に取得するフィールド抽出を作成することができます。
これとは対照的な、Cisco ASA ファイアウォールのログ・イベントを⾒てみましょう。
1
2
3
4
Jul 15 20:10:27 10.11.36.31 %ASA-6-113003: AAA group policy for user AmorAubrey is being set to
Acme_techoutbound
Jul 15 20:12:42 10.11.36.11 %ASA-7-710006: IGMP request discarded from 10.11.36.36 to outside:87.194.216.51
Jul 15 20:13:52 10.11.36.28 %ASA-6-302014: Teardown TCP connection 517934 for Outside:128.241.220.82/1561 to
Inside:10.123.124.28/8443 duration 0:05:02 bytes 297 Tunnel has been torn down (AMOSORTILEGIO)
Apr 19 11:24:32 PROD-MFS-002 %ASA-4-106103: access-list fmVPN-1300 denied udp for user 'sdewilde7'
outside/12.130.60.4(137) -> inside1/10.157.200.154(137) hit-cnt 1 first hit [0x286364c7, 0x0] "
これらのイベントのフィールド値は常にスペースで区切られていますが、先ほどの 2 つのイベントのように⼀定
した形式を持っていません。これらのイベントは順番に、以下の事項を表しています。
1.
2.
3.
4.
グループ・ポリシーの変更
IGMP リクエスト
TCP 接続
特定の IP からのリクエストのファイアウォールによるアクセス拒否
これらのイベントは⾮常に異なっているため、1 つのフィールド抽出を作成してこれらの各イベント・パターンに
適⽤し、関連するフィールド値を抽出することはとても困難です。
特定のホスト、ソースタイプ、またはソースに複数のイベント・パターンが含まれるこのような状況下では、すべ
てのパターンに対応できる単⼀のフィールド抽出を設計するのではなく、それぞれ個別のパターンに対応する
フィールド抽出を定義する⽅が便利なことがあります。イベントを調査して、各パターンで⼀般的に発⽣する「⼀
定の」テキストを判別してください。
フィールド抽出での必要なテキストの使⽤
最後の 4 つのイベントで、%ASA-#- の後に来る数字⽂字列には特定の意味があります。これについては、Cisco の
ドキュメントを参照してください。データ内にこのような独⾃のイベント ID がある場合は、それをフィールド抽
出の必須テキストとして指定してください。必須テキストの⽂字列は、フィールド抽出の正規表現で照合できるイ
ベントを制限します。
必須テキストの指定は省略できますが、このオプションにはさまざまな利点があります。必須テキストによりス
キャンするイベント数が減るため、フィールド抽出の効率が向上し、誤判定によるフィールド抽出数を減少するこ
とができます。
フィールド抽出ユーティリティにより、サンプル・イベント内のテキストを選択して、それを必須テキストとして
指定することができます。
14
Splunk Enterprise でのカスタムのフィールド抽出⽅法
ナレッジ管理者は、Splunk Enterprise 環境でユーザーが作成する⼀連のカスタム・フィールド抽出を管理し、ま
た必要に応じて専⽤のカスタム・フィールド抽出のグループを定義します。そのためには、以下のような⽅法を利
⽤できます。
フィールド抽出ユーティリティで、フィールド抽出⽤の正規表現を⽣成する。
[設定] 内のページを利⽤して、フィールド抽出を追加する。正規表現を指定する必要があります。
.conf ファイル・レベルでフィールド抽出の設定を⼿動で追加する。この⽅法では、フィールド抽出を柔軟に
⾏えます。
Splunk Enterprise ユーザーが利⽤できるフィールド抽出の⼿段は、以下のセクションに記述されています。これ
らの⼿段を利⽤して、サーチ時フィールド抽出を作成することができます。インデックス時フィールド抽出を作成
するには、設定ファイルを直接編集します。
フィールド抽出ユーティリティで抽出を作成する
フィールド抽出ユーティリティは、フィールド抽出の設計プロセスをステップごとに案内します。この機能は正規
表現を⽣成し、それを検証できるため、正規表現の構⽂と利⽤に不慣れの⽅に適しています。また、フィールド抽
出機能を使って正規表現を⼿動で作成、編集することはいつでも可能です。
フィールド抽出機能を使って、以下の作業を⾏えます。
サンプル・イベントを選択し、イベントから抽出するフィールドを強調表⽰して、フィールド抽出を設定す
る。
複数のフィールドを取得する個別の抽出を作成する。
誤判定の⼀致を検出、削除して、抽出精度を向上する。
サーチ・フィルタを使って抽出結果を調査し、特定の値が抽出されていることを検証する。
必須テキストの特定の⽂字列を持つイベントからのみフィールドを抽出するように指定する。
抽出で検出したフィールド値の統計テーブルをレビューする。
フィールド抽出の正規表現を⾃分で⼿動設定する。
フィールド抽出機能では、データ内の特定のソースタイプ (ホストやソースタイプではない) に関連するサーチ
時 フィールド抽出のみを作成することができます。
フィールド抽出機能の使⽤に関する詳細は、このマニュアルの「フィールド抽出機能によるフィールド抽出の作
成」を参照してください。
フィールド抽出機能とフィールド変換によるフィールド抽出の定義
Splunk Web で [設定] の [フィールドの抽出] および [フィールド変換] ページを使って、複雑なフィールド抽出を
管理することができます。
この⽅法のフィールド抽出作成では、フィールド抽出機能を使って⽣成できるフィールド抽出よりも、さらに多彩
なフィールド抽出を作成することができます。この場合、以下の知識が必要になります。
正規表現の作成⽅法を理解している。
props.conf および transforms.conf で、フィールド抽出がどのように設定されているのかについて、基本的な
事項を理解している。
からフィールドを抽出し、フィールド変換が不要なカスタムのフィールド抽出を作成する場合は、フィールド
抽出機能のユーティリティを使⽤してください。フィールド抽出機能は正規表現を⽣成でき、そのフィールド抽出
の精度を検証することができます。
_raw
基本的なフィールド抽出を作成するには、[フィールドの抽出] ページを使⽤します。または、このページと
[フィールド変換] ページを併⽤して、以下のような処理を⾏うフィールド抽出設定を⾏えます。
複数のソース、ソースタイプ、またはホスト間で同じ正規表現を再利⽤する。
複数の正規表現を同じソース、ソースタイプ、またはホストに適⽤する。
正規表現を使って、他のフィールドの値からフィールドを抽出する。
[フィールド抽出] および [フィールド変換] ページでは、サーチ時フィールド抽出のみを定義できます。
このマニュアルの以下のトピックを参照してください。
Splunk Web での [フィールドの抽出] ページの使⽤
Splunk Web での [フィールド変換] ページの使⽤
.conf ファイルへのフィールド抽出の直接の設定
フィールド抽出をきめ細かく設定するには、props.conf と transforms.conf に設定を直接追加します。この⽅法で
は、Splunk Web のフィールド抽出ユーティリティや [設定] ページを利⽤する⽅法よりも、さらに詳細な機能を
持つフィールド抽出を作成することができます。たとえば設定ファイルでは、以下の事項を設定できます。
区切り⽂字ベースのフィールド抽出。
複数値フィールドの抽出。
数字またはアンダースコアで始まる名前を持つフィールドの抽出。⼀般的にこの処理は、キー・クリーニン
グを無効にしない限りできません。
抽出されたフィールドのフォーマット。
詳細は、このマニュアルの「設定ファイルを使ったサーチ時抽出の作成と管理」を参照してください。
15
インデックス時 のフィールド抽出は、props.conf および transforms.conf を設定することによってのみ作成できま
す。デフォルトのインデックス作成フィールド・セットを追加すると、サーチ・パフォーマンスに影響し、イン
デックスの作成に関する問題が発⽣する可能性があります。インデックス時のフィールド抽出を作成する必要があ
る場合は、『データの取り込み』マニュアルの「インデックス時のカスタム・フィールドの作成」を参照してくだ
さい。
カスタムの計算済みフィールドおよび複数値フィールドの作成
ファイルを使って、計算済みフィールドと複数値フィールドの 2 種類のカスタム・フィールドを設定するこ
とができます。
.conf
複数値フィールド は、単⼀のイベント内に異なる値を持って複数回登場する可能性があります。カスタムの複数
値フィールドを設定するには、fields.conf と props.conf を変更します。このマニュアルの「複数値フィールドの
設定」を参照してください。
計算済みフィールド は eval 式を使って、イベント内に存在する他のフィールドの値から計算された値を提供して
います。設定は、props.conf を使って⾏います。このマニュアルの「計算済みフィールドの設定」を参照してくだ
さい。
サーチ⽂字列でのフィールド抽出の作成
Splunk Enterprise には、さまざまな⽅法でサーチ時のフィールドの抽出を⾏うための、サーチ・コマンドが⽤意
されています。これには、以下のようなコマンドがあります。
rex
extract
multikv
spath
xmlkv
xpath
kvform
『サーチ・マニュアル』の「サーチ・コマンドを使ったフィールドの抽出」を参照してください。また、『サー
チ・リファレンス』でこれらのコマンドを探すことも可能です。
サーチ・コマンドによるフィールド抽出は、それらのコマンドを使ったサーチが返す結果にのみ適⽤されます。そ
れらのサーチ・コマンドを使って、サーチ完了後も引き続き再利⽤可能な抽出を作成することはできません。そう
したい場合は、フィールド抽出ユーティリティを使⽤、[設定] ページで抽出を作成、または .conf ファイルに直接
設定を⾏ってください。
Splunk Enterprise がフィールドを抽出する時期
Splunk Enterprise は、まずインデックス時 にフィールドを抽出して、サーチ時 に再び抽出を⾏います。サーチ
の実⾏後、フィールド・サイドバー に、そのサーチで抽出されたフィールドが表⽰されます。
インデックス時のフィールド抽出
インデックス時 には、各イベントに対して host、source、sourcetype などの、デフォルトのフィールド ・セット
が抽出されます。デフォルトのフィールドは、すべてのイベントに共通なイベントです。このマニュアルの「デ
フォルト・フィールドの使⽤」を参照してください。
Splunk Enterprise では、インデックス時にカスタムのインデックス作成フィールド を抽出することもできま
す。これらのフィールドは、インデックス時に抽出を⾏うために明⽰的に設定されたフィールドです。
警告： カスタム・フィールドを、Splunk がインデックス時 に抽出してインデックスを作成する、⼀連のデフォ
ルト・フィールドには追加しないでください。このフィールド・リストに追加すると、インデックスが作成された
各フィールドがサーチ可能インデックスのサイズを増やすため、インデックス作成のパフォーマンスとサーチ時間
が遅くなる可能性があります。インデックス作成フィールドは柔軟性にも⽋けています。⼀連のインデックス作成
フィールドを変更すると、データセット全体のインデックスを再作成する必要があるからです。詳細は、『インデ
クサーとクラスタの管理』マニュアルの「インデックス時とサーチ時」を参照してください。
サーチ時のフィールド抽出
サーチ時 には、サーチ・モード の設定および実⾏中のサーチのタイプに対してフィールド検出 が有効になって
いるかどうかに応じて、追加のフィールドが抽出されます。
フィールド検出が有効になっている場合は、以下の処理が⾏われます。
明らかに key=value のペアと分かるイベント・データ内の最初の 50 件のフィールドを識別、抽出します。こ
の 50 件のフィールド制限はデフォルト値で、limits.conf の [kv] スタンザを編集して変更することができま
す。
⾃動抽出で⾒つけられる場合もある、サーチに明⽰的に指定されている任意のフィールドを抽出します。た
だし、これは最初に識別された 50 件のフィールドには含まれません。
フィールド抽出、[設定] の [フィールドの抽出] ページ、設定ファイルの編集、または rex などのサーチ・コ
マンドを利⽤して定義されているカスタム・フィールドを抽出します。
フィールド検出が無効になっている場合は、以下の項⽬が抽出されます。
サーチに明⽰的に指定されている任意のフィールド。
16
前述のデフォルトおよびインデックス作成フィールド。
transforms.conf で CAN_OPTIMIZE パラメータに真 (True) が設定されている、任意のカスタム・フィールド抽
出。
デフォルト・フィールドおよびサーチ⽂字列に明⽰的に指定されているフィールド以外のフィールドは、次の場合
にのみ検出されます。
スマートサーチモードで⾮変換 サーチを実⾏する
詳細サーチモードでサーチを実⾏する
詳細は、『サーチ・マニュアル』の「サーチに合わせたサーチ・モードの設定」を参照してください。
インデックス時/サーチ時の違いについては、『インデクサーとクラスタの管理』マニュアルの「インデックス時
とサーチ時」を参照してください。
⾃動フィールド抽出の例
この例は、Splunk Enterprise がユーザーの助けを借りることなく⾃動的にフィールドを抽出する仕組みを表して
います。逆にカスタム・フィールド抽出では、ユーザーが定義したイベント抽出ルールに従って抽出が⾏われま
す。
インデックス時に各イベントから抽出される、デフォルトの
しょう。以下のサーチの場合
sourcetype
フィールドに対するサーチを考えてみま
sourcetype=veeblefetzer
これを過去 24 時間に対してサーチを実⾏すると、その時間範囲の sourcetype が veeblefetzer のイベントが返さ
れます。このイベントセットから、Splunk は⾃⾝で識別した最初の 50 件のフィールドを抽出します。また、設
定ファイルに基づいてカスタムフィールドの抽出が⾏われます。サーチの完了後に、これらのフィールドはすべて
フィールド・サイドバーに表⽰されます。
ここで、サーチ対象の 25,000 件のイベントに userlogin=fail のような名前/値のペアが初めて登場し、userlogin
が事前設定しているカスタム・フィールドではない場合、Splunk Enterprise が識別した最初の 50 件のフィール
ドにはおそらく⼊りません。
ただし、サーチを以下のように変更すると
sourcetype=veeblefetzer userlogin=*
Splunk Enterprise は、userlogin フィールドと sourcetype の値が veeblefetzer の両⽅を含む、すべてのイベントを
発⾒して返します。これは、このサーチで抽出された他のサーチとともに、フィールド・サイドバーから利⽤でき
ます。
フィールド抽出ユーティリティを使ったフィールド抽出の作成
Splunk Enterprise インスタンスで動的にカスタム・フィールドを作成するには、フィールド抽出ユーティリティ
を使⽤します。フィールド抽出ユーティリティは、サンプル・イベントを選択し、イベントから抽出するフィール
ドを強調表⽰して、フィールド抽出を設定する。また、フィールド抽出の精度をテスト、調整するためのさまざま
なツールも⽤意されています。
フィールド抽出ユーティリティは、フィールド抽出⽤の正規表現を⽣成し、それをテストできるため、正規表現の
構⽂と利⽤に不慣れの⽅に適しています。正規表現はフィールド抽出の基盤となっています。Splunk Enterprise
は正規表現を使って、イベント内のフィールドを探し、それを抽出します。
これらの正規表現は、⼿動で作成、編集することができます。ただし、この作業はフィールド抽出ユーティリティ
の範囲外です。正規表現への変更を保存する場合、作成したフィールド抽出を保存するための、フィールド抽出
ユーティリティの最後の [保存] ステップをスキップします。
フィールド抽出ユーティリティの概要
新しいフィールドの作成を⽀援するために、フィールド抽出ユーティリティは⼀連のステップを案内いたします。
以下の表に、必要なステップの概要を⽰します。各ステップはこの表の後で詳細に説明していきます。
ステップ
のタイト
ル
説明
ソースタイ
新しいフィールドに関連付けるソースタイプを選択します。
プを選択
サンプルを
抽出する 1 つまたは複数のフィールドを持つイベントを選択します。
選択
フィールド抽出ユーティリティが類似のイベントからフィールドと識別して抽出する、イベント内
の 1 つまたは複数の値を選択します。必要に応じて以下の作業を⾏えます。
フィールド
を選択
イベントの例を提供して、抽出精度を向上する。
必須テキストを指定して、そのテキストを含むイベントのみからフィールドを抽出する。
フィールド抽出の結果を確認する。
基盤となる正規表現を⼿動更新する。これは、フィールド抽出ユーティリティのワークフ
ローの範囲外の作業です。
17
フィールド
の検証
保存
フィールド抽出の結果を確認します。
誤って抽出されたフィールドを反例として、フィールド抽出の精度を向上します。
新しいフィールド抽出の名前と権限を設定して、それを保存します。
フィールド抽出ユーティリティへのアクセス
フィールド抽出ユーティリティには、さまざまな⽅法でアクセスできます。アクセス⽅法により、開始するフィー
ルド抽出ワークフローのステップが異なります。
すべてのユーザーが、イベントを返すサーチの実⾏後、フィールド抽出ユーティリティにアクセスすることができ
ます。サーチ後には、3 ヶ所からフィールド抽出ユーティリティにアクセスすることができます。
フィールド・サイドバーの下部
[すべてのフィールド] ダイアログ・ボックス
サーチ結果内の任意のイベント
以下の場所からフィールド抽出ユーティリティにアクセスすることもできます。
Splunk Enterprise のホーム・ページから
[設定] の [フィールドの抽出] ページから
固定ソースタイプでのデータの追加時
フィールド・サイドバーの下部からのアクセス
この⽅法を使ってフィールド抽出ユーティリティにアクセスする場合、実⾏したサーチが返した結果となる⼀連の
イベントのみが対象となります。Splunk Enterprise インスタンス内のすべてのソースタイプを対象にする場合
は、[設定] の [フィールドの抽出] ページに移動してください。
1. イベントを返すサーチを実⾏します。
2. フィールド・サイドバー の下部に移動して、[新規フィールドの抽出] をクリックします。
の値を識別しないサーチ⽂字列の場合、フィールド抽出ユーティリティは [ソースタイプを選択]
ステップから開始されます。
sourcetype
などのように sourcetype の値を識別するサーチ⽂字列の場合、フィールド抽出
ユーティリティは [サンプルを選択] ステップから開始されます。
sourcetype=access_combined
[すべてのフィールド] ダイアログ・ボックスからのフィールド抽出ユーティリティへのアクセス
この⽅法を使ってフィールド抽出ユーティリティにアクセスする場合、実⾏したサーチが返した結果となる⼀連の
イベントのみが対象となります。Splunk Enterprise インスタンス内のすべてのソースタイプを対象にする場合
は、[設定] の [フィールドの抽出] ページに移動してください。
1. イベントを返すサーチを実⾏します。
2. フィールド・サイドバーの上部から、[すべてのフィールド] をクリックします。
3. [すべてのフィールド] ダイアログ・ボックスで、[新規フィールドの抽出] をクリックします。
の値を識別しないサーチ⽂字列の場合、フィールド抽出ユーティリティは [ソースタイプを選択]
ステップから開始されます。
sourcetype
などのように sourcetype の値を識別するサーチ⽂字列の場合、フィールド抽出
ユーティリティは [サンプルを選択] ステップから開始されます。
sourcetype=access_combined
18
特定のイベントからのフィールド抽出ユーティリティへのアクセス
サーチ結果内のイベントを選択して、以下のようなフィールド抽出を作成する場合に、この⽅法を使⽤します。
そのイベント内で⾒つかった 1 つまたは複数のフィールドを抽出する。
そのイベントのソースタイプに関連付ける。
この⽅法を使ってフィールド抽出ユーティリティにアクセスする場合、実⾏したサーチが返した結果となる⼀連の
イベントのみが対象となります。Splunk Enterprise インスタンス内のすべてのソースタイプを対象にする場合
は、[設定] の [フィールドの抽出] ページに移動してください。
1. イベントを返すサーチを実⾏します。
2. フィールドを抽出するイベントを探し、そのタイムスタンプの左側にある⽮印記号をクリックして、それを開き
ます。
3. [イベント・アクション] をクリックして、[フィールドの抽出] を選択します。
フィールド抽出ユーティリティの [フィールドを選択] ステップが開始されます。ソースタイプとサンプル・
イベントはすでに定義されています。
[設定] の [フィールドの抽出] ページからのフィールド抽出ユーティリティへのアクセス
この⽅法は、すべてのユーザーが利⽤できます。
1. [設定] > [フィールド] > [フィールドの抽出] を選択します。
2. [フィールド抽出機能を開く] ボタンをクリックします。
フィールド抽出ユーティリティの [ソースタイプを選択] ステップが開始されます。
ホーム・ページからのフィールド抽出ユーティリティへのアクセス
この⽅法は Admin などの、ロールに
edit_monitor
権限があるユーザーのみが利⽤できます。
ホーム・ページで、[データの追加] アイコンの下にある [フィールドの抽出] をクリックします。
フィールド抽出ユーティリティの [ソースタイプを選択] ステップが開始されます。
19
データ追加後のフィールド抽出ユーティリティへのアクセス
この⽅法は Admin などの、ロールに
edit_monitor
権限があるユーザーのみが利⽤できます。
Splunk Enterprise にデータを追加した後、それに固定のソースタイプがある限り、フィールド抽出ユーティリ
ティを使ってデータからフィールドを抽出することができます。
例：vendors.csv ファイルを Splunk Enterprise インスタンスに追加して、それにカスタムのソースタイプ vendors
を割り当てた場合を考えてみましょう。この⼊⼒を保存した後、フィールド抽出ユーティリティを使って、vendors
ソースタイプに関連するイベントからフィールドを抽出することができます。
別の例：/var/log ディレクトリのモニター⼊⼒を作成し、ソースタイプとして [⾃動] を選択しました。この場
合、その⼊⼒からのデータのソースタイプ値は、イベントごとに⾃動的に判断されます。この⼊⼒の保存時には、
この新しいデータ⼊⼒からフィールドを抽出する旨のメッセージは表⽰されません。そのディレクトリからイン
デックスを作成するイベントには、さまざまなソースタイプ値が存在する可能性があるためです。
1. [データの追加] ページに移動します。
『データの取り込み』マニュアルの「データの追加⽅法は？」を参照してください。
2. 固定ソースタイプを持つデータ⼊⼒を定義します。
既存のソースタイプ、または⾃分で定義した独⾃のソースタイプを利⽤できます。『データの取り込み』マ
ニュアルの「イベント・データのソースタイプの表⽰と設定」を参照してください。
3. 新しいデータ⼊⼒を保存します。
4. [ファイルが正常にアップロードされました] ダイアログ・ボックスで、[フィールドの抽出] をクリックしま
す。
フィールド抽出ユーティリティの [サンプルを選択] ステップが開始されます。
ソースタイプを選択
フィールド抽出ユーティリティの [ソースタイプを選択] ステップで、フィールド抽出⽤のソースタイプ を選択し
ます。フィールド抽出ユーティリティが定義するすべてのフィールド抽出は、ソースタイプに関連付けられます。
注意： サーチ実⾏後にフィールド抽出ユーティリティにアクセスした場合、そこで選択できるソースタイプは、
サーチが返した結果内で発⾒されたものに限定されます。Splunk Enterprise インスタンス内のすべてのソースタ
イプを対象にする場合は、[設定] の [フィールドの抽出] ページに移動してください。
1. フィールド抽出⽤のソースタイプを選択します。
2. [次へ] をクリックして、[サンプルを選択] ステップに移動します。
以下の画⾯は、[設定] の [フィールドの抽出] ページからフィールド抽出ユーティリティにアクセスした場合に表
⽰される、ソースタイプ⼀覧の例です。
20
[ソースタイプを選択] ステップの省略条件
フィールド抽出ユーティリティにアクセスする前にソースタイプを定義した場合、[ソースタイプを選択] ステップ
は省略されます。これは、以下の場合に⾏われます。
ソースタイプを識別するサーチの実⾏後に、フィールド抽出ユーティリティにアクセスする (フィールド・
サイドバーまたは [すべてのフィールド] ダイアログ・ボックスから [フィールドの抽出] リンクを使⽤)。
サーチ結果のイベントからフィールド抽出ユーティリティにアクセスする。
サンプルを選択
フィールド抽出ユーティリティの [サンプルを選択] ステップでは、抽出するフィールドの値を含んでいるサンプ
ル・イベントを選択します。
注意： サーチ結果のイベントからフィールド抽出ユーティリティにアクセスした場合、このステップと前の [ソー
スタイプを選択] ステップは省略されます。フィールド抽出ユーティリティは指定したイベントをサンプル・イベ
ントとして使⽤し、イベントのソースタイプをフィールド抽出のソースタイプとして使⽤します。
1. イベントのリストを参照して、⽬的のイベントを探してください。
2. (オプション) ⽬的のイベントが⾒つからない場合は、キーワードでイベント・リストをフィルタリングしてくだ
さい。
フィルタにキーワードを⼊⼒して [適⽤] をクリックすると、それらのキーワードでイベント・リストがフィ
ルタリングされます。フィルタ・フィールドからキーワードを削除して、[適⽤] をクリックすると、フィル
タが解除されます。
3. (オプション) 特に希なイベントを取得するには、[サンプル] の値を [最初の 10,000 件] や [過去 24 時間]
などの、より⼤きなイベント・セットを対象にする値に変更します。
デフォルトでは、最初の 1000 件のイベントがイベント・リストに表⽰されます。このデータ量では、⼀部
の希なイベントを取得するのに⼗分ではない可能性もあります。
4. (オプション) [すべてのイベント] を [レア・イベント] または [多彩なイベント] に切り替えて、それらのカ
テゴリに該当するイベントを表⽰します。
5. イベントをクリックして選択します。
6. [次へ] をクリックして、[フィールドを選択] ステップに移動します。
この例で、このフィルタは access_combined ソースタイプの、⽂字列 POST を含むイベントを探します。選択された
イベントは、フィールド・リストの上部に⻘い背景に⽩いテキストで表⽰されます。
21
フィールドの選択
フィールド抽出ユーティリティの [フィールドを選択] ステップでは、サンプル・イベント内のフィールドとして
抽出する値を選択します。
フィールド抽出の精度を向上するために、必要に応じて以下の作業を⾏えます。
正規表現の範囲を拡張するために、サンプル・イベントを指定する。
必須テキストの⽂字列を指定して、そのテキストを含むイベントのみからフィールドを抽出する。
正規表現が返す結果をプレビューする。
正規表現を⼿動で編集する。
1 つまたは複数のフィールド値を指定する
フィールドを指定する前に、このソースタイプでそれらが抽出されていないことを確認します。「既存のフィール
ドのレビュー」を参照してください。
フィールドとして抽出する、最低 1 つのフィールド値を指定する必要があります。
複数のフィールド値を指定した場合、各値は個別の⾊でマークされます。
フィールド値を選択してフィールド抽出に追加するたびに、フィールド抽出ユーティリティが正規表現を⽣成しま
す。この正規表現は、選択したイベントと似ているイベントに⼀致して、指定したフィールドの値が抽出されま
す。
フィールド抽出ユーティリティが正規表現を⽣成する際には、選択されたソースタイプに所属するフィールドを対
象に処理が⾏われ、イベント・リストに結果が表⽰されます。正規表現に⼀致するイベントには⼀番左の列に緑⾊
のチェック・マークが、⼀致しないイベントには⾚⾊の「x」が表⽰されます。⼀致するフィールド値は、サンプ
ル・イベントと同じ⾊で表⽰されます。
1. サンプル・イベントで、フィールドとして抽出する値を選択します。
選択された値の下に、フィールドがあるダイアログ・ボックスが表⽰されます。
2. [フィールド名] フィールドに名前を⼊⼒します。
フィールド名は⽂字から始まる必要があります。また、⽂字、数字、およびアンダースコアのみを使⽤でき
ます。
3. [抽出の追加] をクリックして、抽出を保存します。
4. (オプション) 抽出するすべての値を指定するまで、ステップ 1〜3 を繰り返します。
イベント内で抽出するフィールドをさらに選択していくと、それらのすべてのフィールドを確実に抽出でき
る正規表現をフィールド抽出ユーティリティが⽣成できない可能性が出てきます。複数値フィールド抽出の
信頼性は、サンプル・イベントの追加および必須テキストの指定により向上することができます。正規表現
を⼿動で編集して、改善することもできます。
22
5. (オプション) [削除] または [名前変更] をクリックして選択することで、サンプル・イベントのフィールド抽出
の名前を削除、変更することもできます。6. [次へ] をクリックして、[フィールドの検証] ステップに移動しま
す。
正規表現の範囲を拡張するためのサンプル・イベントの追加
[フィールドを選択] ステップでこの作業は省略することができます。
サンプル・イベント内で⼀連のフィールドを選択しても、イベント・リスト内でそれらのフィールドを持つイベン
トが⼀致とみなされないことがあります。これは、フィールド抽出ユーティリティが⽣成した正規表現がサンプ
ル・イベントと類似のパターンを持つイベントと⼀致するけれども、パターンがわずかに異なっており、そのイベ
ントが⼀致とみなされないことがあるからです。
抽出できなかったイベントをさらなるサンプル・イベントとして追加して、正規表現の適⽤範囲を拡張してくださ
い。抽出されなかったフィールドを選択すると、フィールド抽出ユーティリティは両⽅のイベント・パターンを認
識する新たなフィールド抽出の⽣成を試みます。
1. フィールド・リストで、正規表現に⼀致しなかったけれども、当初のサンプル・イベントで抽出しようとしてい
たすべてのフィールドの値を持つイベントをクリックします。
オリジナルのサンプル・イベントと似たフォーマット/パターンを持つサンプル・イベントを追加すること
で、フィールド抽出の精度を向上できる可能性があります。
選択したサンプル・イベントは、オリジナルのサンプル・イベントの下に表⽰されます。
2. 追加したサンプル・イベント内で、最初のサンプル・イベントから抽出しようとしていたフィールドの値を選択
します。
3. 正しいフィールド名 を選択します。
最初のサンプル・イベントで指定したフィールドの値のみが表⽰されます。
4. [抽出の追加] をクリックします。
両⽅のイベント・パターンのフィールド値を認識できるように、正規表現の対象の拡張が試みられます。新
しい正規表現でイベント・サンプルとの照合が⾏われ、結果がイベント・テーブルに表⽰されます。
5. (オプション) 複数のフィールドを抽出する場合は、各フィールドに対してステップ 2〜4 を繰り返します。
最初のサンプル・イベントで選択したすべてのフィールドを選択する必要はありません。たとえば、オリジ
ナルのサンプル・イベント内で指定した 2 つのフィールドの内の 1 つのみを追加のイベントで選択した場合
でも、フィールド抽出の精度が向上する場合があります。
6. (オプション) サンプル・イベントを追加します。
7. (オプション) イベントの隣りにある [X] をクリックして、サンプル・イベントを削除します。
フィールド抽出ユーティリティでは、オリジナルのサンプル・イベントおよび追加のサンプルイベントに⼀致する
正規表現を⽣成できないこともあります。この問題に対処するには、以下のような⽅法があります。
複数のフィールドを抽出しようとしている場合は、その⼀部を削除する。 この作業により、選択したイ
ベントすべてに対処するフィールド抽出を⽣成できる可能性があります。まず削除する必要があるのは、⻑
いテキスト⽂字列が含まれているフィールドです。削除したフィールドに対しては、別個のフィールド抽出
を設定することができます。
必須テキストを使って抽出を分類し、⽬的のフィールド値を含む各イベント・パターンに対する
フィールド抽出を定義する。 必須テキストについては、次のトピックを参照してください。
必須テキストの指定による、特定のイベント・パターンと⼀致する抽出の作成
[フィールドを選択] ステップでこの作業は省略することができます。
23
あるソースタイプに、抽出対象の 1 つまたは複数の同じフィールドが存在している、異なる種類のイベントが存
在することがあります。この場合、単独で複数のイベント・パターンに対応できるフィールド抽出の設計は困難に
なる可能性があります。対処⽅法の 1 つとして、各イベント・パターンに対して個別のフィールド抽出を定義す
ることが挙げられます。
必須テキストを使って、抽出を特定のイベント・パターンに絞り込むことができます。必須テキストは、サーチ・
フィルタのような働きをします。これは、Splunk Enterprise が照合対象とするイベント内に、存在している必要
があるテキスト⽂字列です。
たとえば
に、それぞれ⽂字列 action=addtocart、action=changequantity、action=purchase、および
が違っているイベント・パターンが存在していることがあります。異なる必須テキストを指定するこ
とで、同じフィールドを抽出するけれども、それぞれの⽂字列に対応した 4 種類の抽出を作成することができま
す。
access_combined
action=remove
必須テキストを指定することで、特定のイベントからのみ値を抽出するようにすることもできます。
必須テキストの定義には、2 つの制限事項があります。
単⼀のフィールド抽出に対して、必須テキストは 1 つしか定義できません。
フィールド値として選択したテキスト⽂字列を必須テキスト⽂字列に指定することはできません (逆も同様
です)。
1. サンプル・イベント内で、必須テキストを選択します。
2. [必須] を選択します。
3. フィールド抽出に必須テキストを追加するには、[必須テキストの追加] をクリックします。
4. (オプション) サンプル・イベントから必須テキストを削除するには、それをクリックして [必須テキストの削
除] を選択します。
この例は、必須テキストとして action=purchase が定義されており、http_method フィールド (緑) および status
フィールド (⻩) を抽出するフィールド抽出を表しています。フィールド・リストで、最初の 2 つのイベントは必
須テキストがないため、抽出とは⼀致しません。3 番⽬のイベントは、必須テキストを持ち、正規表現と⼀致して
います。抽出されたフィールドが強調表⽰されています。
フィールド抽出の結果のプレビュー
24
[フィールドを選択] および [フィールドの検証] ステップで、この作業は省略することができます。
イベント・リストには、フィールド抽出の精度を調査するために利⽤できる機能があります。デフォルトでリスト
には、そのソースタイプのサンプル内にあるすべてのイベントが表⽰されます。
⼀番左側の列を使って、正規表現に⼀致するイベントと⼀致しないイベントを判別することができます。
正規表現がサンプル・イベント内のほんの少しのイベントにしか⼀致しない場合は、ビューを [⼀致] に切り
替えて⼀致するイベントを確認することができます。[不⼀致] を選択して、正規表現に⼀致しないイベント
のみを表⽰することもできます。
フィールド・タブをクリックすると、そのフィールドの統計情報が表⽰されます。各フィールド・タブに
は、イベント・サンプル内のフィールドに対して⾒つかった、各値の数を表す棒グラフが、多いものから順
に表⽰されます。
グラフ内の値をクリックすると、フィールド・リストがその値でフィルタリングされます。たとえ
ば、status グラフで値 503 をクリックすると、フィルタに [status=503] が設定された、メインの [プレビュー]
フィールド・リストが表⽰されます。これには、値 status を持つイベントのみが表⽰されます。
注意 ：誤って抽出されたフィールド値が⾒つかった場合、それを反例として適⽤することができます。次のス
テップである [フィールドの検証] を参照してください。
正規表現の⼿動編集
[フィールドを選択] および [フィールドの検証] ステップで、この作業は省略することができます。
正規表現は⼿動で編集することができます。ただし、この作業はフィールド抽出ユーティリティのワークフローの
範囲外です。変更内容を保存する場合、フィールド抽出ユーティリティの最後のステップである [保存] で、
フィールド抽出の名前と権限を指定して、それを保存します。保存前に抽出を検証したり、微調整したりすること
はできません。
1. [正規表現を表⽰] をクリックします。
2. [正規表現を編集] をクリックします。
フィールド抽出ユーティリティのワークフローを終了したくない場合は、ページの左上にある [戻る] ボタン
をクリックして、ワークフローに戻ります。正規表現の編集を開始すると、このボタンは表⽰されなくなり
ます。
3. 正規表現を編集します。
4. [プレビュー] をクリックして、編集した抽出をサンプル・イベントと照合します。
正規表現が正しくイベントを照合して、適切なフィールドが抽出されるまで、ステップ 3 と 4 を繰り返しま
す。
5. 新しいフィールド抽出を保存するには、[保存] をクリックします。
[保存] ステップに移動した後、[戻る] をクリックすると、正規表現の編集を続⾏できます。抽出の名前を指
定したり、権限を設定したりすると、[戻る] ボタンが消えます。
25
このマニュアルの「Splunk Enterprise 正規表現について」を参照してください。
既存のフィールドのレビュー
[フィールドの検証] ステップでこの作業は省略することができます。
ソースタイプに対して選択した抽出するフィールドが、すでに抽出されている場合があります。このような状況か
どうかを判断して、そのような場合にフィールドを抽出する⽬的のイベント・パターンから抽出されたかどうかを
確認することができます。
1. 画⾯右上の [既存のフィールド] をクリックします。
フィールド抽出ユーティリティの [フィールドを選択]、[フィールドの検証]、および [保存] ステップに [既
存のフィールド] ボタンが表⽰されます。
[フィールド] サイドバーが表⽰されます。ソースタイプに対してフィールドが抽出されている場合、それは
テーブルに表⽰されます。抽出したフィールドが表⽰されない場合は、⾓にある [X] をクリックして、サイ
ドバーを閉じます。
フィールド名が、異なるパターン名 の値で複数回表⽰されることもあります。
2. 抽出するフィールドがテーブルに表⽰されている場合は、[開く] をクリックするとそのフィールド抽出に関す
る詳細を表⽰することができます。
この場合、新しいタブにページが表⽰されます。このページでは、フィールド抽出の正規表現、それに⼀致
するイベント、および抽出されたフィールド値を確認することができます。
3. 正規表現 、それに⼀致するイベント、および抽出されたフィールド値を確認します。
イベントがフィールドを抽出するイベント・パターンのタイプと⼀致して、⽬的のフィールド値が正しく抽
出されている場合は、新しいフィールド抽出を作成する必要はありません。
フィールド抽出が⽬的のイベント・パターン以外のパターンに⼀致している場合は、⼀意のパターン名 を持
つ新たな抽出を作成することができます。
26
フィールドの検証
フィールド抽出ユーティリティの [フィールドの検証] ステップでは、フィールド抽出を検証することができま
す。フィールド抽出ユーティリティは、以下の検証⼿段を提供しています。
イベント・リストをレビューして、フィールド抽出に⼀致した、または⼀致しなかったイベントを確
認する。 「フィールド抽出の結果のプレビュー」を参照してください。
誤った抽出を反例としてフィールド抽出ユーティリティに報告する。 フィールド抽出ユーティリティは
それに応じて正規表現の改善を試みます。
正規表現を⼿動で編集する。「正規表現の⼿動編集」を参照してください。
フィールド抽出の検証が完了したら、[保存] をクリックして抽出を保存します。
反例の提出
[フィールドの検証] ステップでこの作業は省略することができます。
誤って抽出されたフィールドを持つイベントが⾒つかった場合は、それらのイベントを反例として提出します。
1. 誤って抽出されたフィールド値を持つイベントを探します。
強調表⽰されたテキストが、それが著しているフィールドに対して正しい値でないものです。
2. 誤ったフィールド値の隣りにある [X] をクリックします。
テーブルに先ほどの反例となるイベントが表⽰されます。誤っている値は⾚い取り消し線でマークされま
す。また、正規表現とプレビュー結果も更新されます。
3. 反例を提出しても問題が解決されない場合は、反例イベントの左にある [X] をクリックして、それを削除しま
す。
保存
フィールド抽出ユーティリティの [保存] ステップでは、新しいフィールド抽出の名前と権限を設定して、それを
保存します。
1. (オプション) フィールド抽出ユーティリティが指定したデフォルト名を、必要に応じて別の名前に変更します。
フィールド抽出ユーティリティは、フィールド抽出でするフィールド名で構成された名前をデフォルトで使
⽤します。この名前をそのまま使⽤することも可能です。
2. (オプション) フィールド抽出の権限 を App またはすべての App に変更し、ロールベースの読み取り/書き込
み権限を更新します。
フィールド抽出には [所有者] が設定されています。この場合、抽出の作成者が実⾏したサーチでのみ
フィールドが抽出されます。
フィールド抽出が所属している App のユーザーのみにこの抽出を利⽤させる場合は、[権限] に [App] を設
定します。
すべての App のすべてのユーザーが、サーチ実⾏時にこのフィールド抽出を利⽤できるようにするに
は、[権限] に [すべての App] を設定します。
App の権限を [App] または [すべての App] に変更した場合、ロール単位で読み取り/書き込み権限を設
定することができます。詳細は、このマニュアルの「ナレッジ・オブジェクト権限の管理」を参照してくだ
さい。
27
3. [完了] をクリックして、抽出を保存します。
フィールド抽出ユーティリティで作成したフィールド抽出を管理することができます。これは、[設定] の [フィー
ルドの抽出] ページに記載されています。詳細は、このマニュアルの「Splunk Web の [フィールドの抽出抽出]
ページの使⽤」を参照してください。
Splunk Web での [フィールドの抽出] ページの使⽤
Splunk Web の [フィールドの抽出] ページを使って、props.conf に追加したサーチ時のフィールド抽出 を管理す
ることができます。props.conf にサーチ時フィールド抽出を追加するには、3 種類の⽅法があります。以下の作業
を⾏えます。
フィールド抽出ユーティリティを使⽤して抽出を作成する。この⽅法は⽐較的簡単で、正規表現の仕組みを
理解する必要はありません。
props.conf を直接編集する。
[] ページで新しいフィールド抽出を追加する (以下を参照)。
[フィールドの抽出] ページでは、以下の作業を⾏えます。
⾃分が作成した、またはSplunk 環境内のすべての App に対して⾃分が参照できる権限を持つ、サーチ時抽
出をレビューする。
新しいサーチ時フィールド抽出を作成する。
フィールド抽出の権限を更新する。フィールド抽出ユーティリティおよび [フィールドの抽出] ページを使っ
て作成されたフィールド抽出は、作成者が他のユーザーと共有しない限りその作成者のみが利⽤できます。
フィールドの抽出を削除する (App レベルの権限が許可しており、製品に同梱されているデフォルトの抽出
ではない場合)。デフォルトのナレッジオブジェクトを削除することはできません。ナレッジオブジェクト削
除の詳細は、このマニュアルの「ナレッジオブジェクトの無効化または削除」を参照してください。
特定のサーチ時フィールド抽出に対して「書き込み」権限 がある場合、[フィールドの抽出] ページで以下の作業を
⾏えます。
インライントランザクションの場合、正規表現を更新する。
トランザクションを使⽤している場合に、transforms.conf または Splunk Web の [フィールドの抽出] ペー
ジで定義された名前付き抽出を追加、削除する。
注意： Splunk Web では、インデックス時フィールド抽出を管理することはできません。インデックス時フィー
ルド抽出を変更することはお勧めできません。どうしても変更する必要がある場合は、props.conf および
transforms.conf 設定ファイルを⼿動で編集してください。インデックス時フィールド抽出の設定の詳細は、『デー
タの取り込み』マニュアルの「インデックス時フィールド抽出の設定」を参照してください。
[フィールドの抽出] ページに移動するには [設定] > [フィールド] > [フィールドの抽出] を選択します。
Splunk Web でのサーチ時フィールド抽出のレビュー
Splunk Web の [フィールドの抽出] ページへのフィールド抽出の表⽰⽅法を理解するために、props.conf および
transforms.conf ファイル内にフィールド抽出がどのように設定されているのかを理解することが役⽴ちます。
フィールドの抽出全体を props.conf に設定することができます。この場合、それらの設定は [フィールドの抽出]
ページに「インライン」フィールド抽出として表⽰されます。⼀部のフィールド抽出には、「フィールド変換 」
と呼ばれる transforms.conf のコンポーネントが含まれています。Splunk Web でこのようなフィールドの抽出の
コンポーネントを作成/編集するには、[フィールド変換] ページを使⽤します。
[フィールド変換] ページの詳細は、「フィールド変換の管理」を参照してください。
props.conf および transforms.conf ファイルに直接フィールド抽出を設定する⽅法については、このマニュアル
の「設定ファイルを使ったサーチ時フィールド抽出の作成と管理」を参照してください。
［名前］ 列
[フィールドの抽出] ページの ［名前］ 列には、props.conf に指定されているフィールド抽出の総合的な名前 (ま
たは「クラス」) が表⽰されます。props.conf でのフィールド抽出の形式を以下に⽰します。
<spec> : [EXTRACT-<class> | REPORT-<class>]
<spec>
には、以下の値を使⽤できます。
<sourcetype>、イベントのソースタイプ。
host::<host>、<host>
はイベントのホストを表します。
はイベントのソースを表します。
source::<source>、<source>
フィールド抽出は、props.conf に全体が定義された抽出です (transforms.conf 内の変換を参照しな
い)。これらは、IFX および特定のサーチコマンドで⾏われたフィールド抽出により、⾃動的に作成されま
す。props.conf ファイルを直接更新して、追加することもできます。この種類の抽出は、常にフィールド抽出正規
表現と関連付けられます。[フィールドの抽出] ページで、この正規表現は ［抽出/変換］ 列に表⽰されます。
EXTRACT-<class>
フィールド抽出は、transforms.conf 内のフィールド変換スタンザを参照します。これは、その
フィールド抽出正規表現が存在している場所です。[フィールドの抽出] ページで、参照されているフィールド変換
スタンザは ［抽出/変換］ 列に表⽰されます。
REPORT-<class>
変換に関する作業は、Splunk Web の [フィールド変換] ページで⾏います。詳細は、このマニュアルの「Splunk
28
Web の [フィールド変換] ページの使⽤」を参照してください。
［タイプ］ 列
フィールド抽出には、インラインと transforms.conf の 2 種類のタイプが存在しています。
インライン抽出には、常に EXTRACT-<class> 設定があります。これらは全体が props.conf に定義され、外部の
フィールド変換は参照しません。
変換を使⽤する抽出には、常に REPORT-<class> 名前設定があります。そのため、transforms.conf 内のフィー
ルド変換が参照されます。Splunk Web の [フィールド変換] ページを使って、直接 transforms.conf 内に
フィールド変換を定義することができます。
［抽出/変換］ 列
［抽出/変換］ 列には、フィールド抽出タイプ に応じて異なる事項が表⽰されます。
インライン抽出タイプの場合、Splunk Enterprise がフィールドの抽出に使⽤する正規表現式が表⽰されま
す。正規表現内の名前付きグループ (複数の場合もある) は、どのようなフィールドを抽出するのかを⽰して
います。
正規表現の構⽂と使⽤⽅法の概要については、Regular-Expressions.info を参照してください。正規表現を
テストするには、rex サーチコマンドのを使⽤します。正規表現式を作成、テストするために役⽴つサード
パーティ製ツールのリストも⽤意されています。
transform を使⽤する変換タイプの場合、props.conf 経由でフィールド抽出にリンクされてい
る、transforms.conf のフィールド変換スタンザ名が表⽰されます。同じソース、ソースタイプ、またはホス
トに複数のフィールド抽出正規表現を適⽤したい場合は、フィールドの抽出に複数のフィールド変換を参照
させることができます。これは、抽出するフィールドが、複数の異なるイベントパターンに登場するような
場合に必要になります。
たとえば、［式］ 列に「transform を使⽤」抽出の 2 つの値「 access-extractions」および「ip-extractions」が
表⽰されることがあります。 これらは、たとえば props.conf に以下のように指定されています。
[access_combined]
REPORT-access = access-extractions, ip-extractions
この例で、access-extractions および ip-extractions は、transforms.conf 内のフィールド変換スタンザ名で
す。Splunk Web を使ったフィールド変換に関する作業については、[フィールド変換] ページに移動してく
ださい。
新しいフィールド抽出の追加
新しいフィールド抽出を追加するには、[フィールドの抽出] ページの上部にある [新規] ボタンをクリックしま
す。[新規追加] ページが表⽰されます。
props.conf
内でのフィールド抽出の設定⽅法を知っている⽅にとって、この作業は単純に感じられることでしょ
う。
以下のすべてのフィールドが必要です。
1. フィールド抽出の [宛先 App] コンテキストを定義します。デフォルトでは、現在あなたがいる App コンテキ
ストになります。
2. フィールド抽出の名前 を指定します。複数の単語を指定する場合、間はスペースの代わりにアンダースコアを
使⽤してください。props.conf で、これは EXTRACT または REPORT フィールド抽出タイプの <class> 値になり
ます。注意： <class>の値は、フィールド名構⽂の制限 (下の「重要 」を参照) に従う必要はありません。a-z、AZ、および 0-9 以外の⽂字を使⽤でき、またスペースも利⽤できます。また、<class> の値はキークリーニングに
も従いません。
3. 抽出を適⽤するソースタイプ、ソース、またはホストを定義します。sourcetype、source、または host を選択
して、値を⼊⼒してください。これは、props.conf 内の <spec> の値にマップされます。
4. 抽出タイプを定義します。
[transform を使⽤] を選択した場合は、関与する変換を [抽出/変換] フィールドにカンマで区切って⼊⼒し
ます。変換は、[フィールド変換] ページで作成、更新できます。
[インライン] を選択した場合、[抽出/変換] フィールドにフィールドの抽出に使⽤する正規表現式を⼊⼒し
ます。正規表現の構⽂と使⽤⽅法の概要については、Regular-Expressions.info を参照してください。正規
表現をテストするには、rex サーチコマンドのを使⽤します。正規表現式を作成、テストするために役⽴つ
サードパーティ製ツールのリストも⽤意されています。
重要： 正規表現で複数のグループを取得する場合は、英数字またはアンダースコアのみを使⽤したフィールド名
を指定する必要があります。
フィールド名に使⽤できる⽂字は、a-z、A-Z、0-9、 、_ です。
フィールド名の先頭に、0-9 または _ を使⽤することはできません。先頭のアンダースコアは、Splunk
Enterprise の内部変数⽤に予約されています。
国際⽂字は使⽤できません。
Splunk Enterprise は、すべての抽出されたフィールド (デフォルトおよびカスタム設定による抽出フィールド)
29
に以下の「キークリーニング」ルールを適⽤します。
a-z、A-Z、および 0-9 以外 のすべての⽂字は、アンダースコア (_) に置換されます。
先頭のアンダースコアと 0-9 は、すべて削除されます。
特定のフィールド抽出でこの動作を無効にするには、props.conf および transforms.conf の両⽅を⼿動で変更する必
要があります。詳細は、このマニュアルの「設定ファイルを使ったサーチ時フィールド抽出の作成と管理」を参照
してください。
注意： インラインフィールド抽出 (フィールド変換コンポーネントが不要なフィールド抽出) のキークリーニング
は、props.conf スタンド内の抽出スタンザを編集しない限りオフにすることはできません。
例 - 新しいエラーコードフィールドの追加
ここでは、新しい err_code フィールドの抽出の定義⽅法について説明していきます。フィールドは、device_id= に
続けて括弧に囲まれた単語、およびコロンで終了するテキスト⽂字列で識別できます。このフィールドを testlog
ソースタイプに関連するイベントから抽出する必要があります。
props.conf
で、この抽出は以下のようになります。
[testlog]
EXTRACT-errors = device_id=\[w+\](?<err_code>[^:]+)
[新しいフィールド抽出の追加] ページを使った設定を以下に⽰します。
注意： この例の別バージョンがこのマニュアルの「サーチ時フィールド抽出の作成と管理」に記載されていま
す。その例では、props.conf ファイルを使ったフィールド抽出の設定⽅法を取り上げています。
既存のフィールド抽出の更新
既存のフィールド抽出を編集するには、［名前］ 列の名前をクリックします。
フィールド抽出の詳細ページが表⽰されます。[抽出/変換] フィールドでできる作業は、その抽出のタイプによっ
て異なります。
インライン抽出の場合、フィールド抽出に使⽤する正規表現式を編集できます。
1 つまたは複数の変換を使⽤するフィールド抽出の場合は、関与している変換を更新できます (複数指定す
る場合はカンマで区切って⼊⼒)。変換は、[フィールド変換] ページで作成、更新できます。
30
上記のフィールド抽出は、3 つの変換 wel-message、wel-eq-kv、および wel-col-kv を使⽤しています。これらの変換
の設定を確認するには、[設定] > [フィールド] > [フィールド変換] に移動するか、または直接 transforms.conf
を参照します。
注意： [transform を使⽤] フィールドには、最低 1 つの
要があります。
transforms.conf
フィールド抽出スタンザ名を指定する必
フィールドの抽出権限の更新
インラインのフィールド抽出を作成する場合 (IFX やサーチコマンドで)、当初はその作成者のみが使⽤できま
す。他のユーザーにも利⽤させる場合は、その権限 を更新する必要があります。そのためには、[フィールドの抽
出] ページ内の⽬的のフィールド抽出の [権限] リンクを選択します。ナレッジオブジェクト の標準の権限管理⽤
ページが表⽰されます。
このページでは、フィールド抽出のロールベース の権限の設定、および特定の App のユーザーに使⽤させるか、
またはすべての App のユーザーにグローバルに使⽤させるかを指定することができます。Splunk Web を使った
権限の管理の詳細は、このマニュアルの「ナレッジオブジェクトの権限の管理」を参照してください。
フィールド抽出の削除
Splunk Web の [フィールドの抽出] ページでは、必要な権限があればフィールド抽出を削除することができま
す。デフォルトのフィールド抽出 (製品に⽤意されている抽出で App の default ディレクトリに保管) を削除する
ことはできません。
削除するフィールド抽出の [削除] をクリックします。
注意： 下流の依存関係があるオブジェクトの削除時には注意する必要があります。たとえば、フィールド抽出が
あるサーチで使⽤されており、そのサーチが他の 5 種類の保存済みサーチ (その中の 2 つはダッシュボードパネ
ルに利⽤されている) が使⽤しているイベントタイプの基盤となっている場合、フィールド抽出を削除するとそれ
らのすべてのナレッジオブジェクトに悪影響を与えてしまいます。ナレッジオブジェクト削除の詳細は、このマ
ニュアルの「ナレッジオブジェクトの無効化または削除」を参照してください。
Splunk Web での [フィールド変換] ページの使⽤
[フィールド変換] ページでは、transforms.conf に存在しているサーチ時フィールド抽出のフィールド変換 コン
ポーネントを管理することができます。フィールド変換は、transforms.conf を直接変換して、または [フィールド
変換] ページに追加することで作成できます。
注意： 各フィールド変換には、最低 1 つのフィールド抽出コンポーネントが必要です。ただし、インラインの
フィールド抽出には、フィールド変換コンポーネントは必要ありません。
[フィールド変換] ページでは、以下の作業を⾏えます。
⾃分が作成した、またはSplunk 環境内のすべての App に対して⾃分が参照できる権限を持つ、フィールド
変換をレビューする。
新しいフィールド変換を作成する。フィールド変換を使⽤する必要がある状況については、下の「[フィール
ド変換] ページを使⽤する場合」を参照してください。
フィールド変換の権限を更新する。[フィールド変換] ページで作成されたフィールド変換は、他のユーザー
と共有しない限り、当初は作成者のみが利⽤できます。フィールド変換の権限は、⾃分がそのフィールド変
換を保有しているか、またはロールが適切な権限を持っている場合にのみ更新できます。
フィールド変換を削除する (App レベルの権限が許可しており、製品に同梱されているデフォルトのフィー
ルド変換ではない場合)。デフォルトのナレッジオブジェクトを削除することはできません。ナレッジオブ
ジェクト削除の詳細は、このマニュアルの「ナレッジオブジェクトの無効化または削除」を参照してくださ
い。
特定のフィールド変換に対して「書き込み」権限がある場合、[フィールド変換] ページで以下の作業を⾏えます。
正規表現の更新および正規表現の適⽤先キーの変更。
フィールド変換フォーマットを定義または更新する。
[フィールド変換] ページに移動するには [設定] > [フィールド] > [フィールド変換] を選択します。
フィールド抽出のフィールド変換を設定する理由
⼤半のサーチ時フィールド抽出は props.conf (または Splunk Web の [フィールドの抽出] ページ) で全体を定義す
ることができますが、⼀部の⾼度なサーチ時フィールド抽出を使⽤する場合は、「フィールド変換 」と呼ばれる
transforms.conf コンポーネントが必要になります。このコンポーネントは、[フィールド変換] ページで定義、管理
することができます。
以下のような場合に、フィールド変換コンポーネントを持つサーチ時フィールド抽出を設定します。
複数のソース、ソースタイプ、またはホストにまたがって同じフィールド抽出正規表現を再利⽤する
(複数のフィールド抽出が参照する 1 つのフィールド変換を設定する)。異なるソース、ソースタイプ、およ
びホストに対するフィールドの抽出に同じ正規表現を使⽤している場合は、それを変換として設定すること
ができます。そうすることで、正規表現を更新する必要がある場合は、複数のフィールド抽出が使⽤してい
るような場合でも、1 回の変更で作業が完了します。
同じソース、ソースタイプ、またはホストに対して複数のフィールド抽出正規表現を適⽤する (同じ
フィールド抽出に複数のフィールド変換を適⽤する)。これは、特定のソース/ソースタイプ/ホストから抽出
するフィールドが、複数の異なるイベントパターンで登場するような場合に必要になります。
他のフィールドの値 (ソースキー) からフィールドを抽出する正規表現を使⽤する 。たとえば、url
フィールドの値から⽂字列を取得して、それを新しいフィールドの値にします。
31
サーチ時フィールド変換を transforms.conf に直接設定することで、ほかにもさまざまな処理を⾏えます (区切り⽂
字ベースのフィールド抽出や複数値フィールドの抽出の設定など)。詳細は、このマニュアルの「設定ファイルを
使ったサーチ時フィールド抽出の作成と管理」を参照してください。
注意： すべてのインデックス時フィールド抽出は、1 つまたは複数のフィールド変換と組み合わされています。
Splunk Web では、インデックス時のフィールド抽出を管理できません。ただし、props.conf および
transforms.conf 設定ファイルを使⽤することは可能です。通常の環境下では、インデックス時のフィールド抽出を
変更することはお勧めできません。どうしても編集する必要がある場合は、先に『Getting Data In』マニュアル
の「Create custom fields at index-time」を参照してください。
Splunk Web でのサーチ時フィールド変換のレビューと更新
Splunk Web の [フィールド変換] ページへのフィールド変換の表⽰⽅法を理解するために、props.conf および
transforms.conf ファイル内にフィールド抽出がどのように設定されているのかを学習することが役⽴ちます。
transforms.conf
内の⼀般的なフィールド変換は、以下のようになっています。
[banner]
REGEX = /js/(?<license_type>[^/]*)/(?<version>[^/]*)/login/(?<login>[^/]*)
SOURCE_KEY = uri
この変換は正規表現を uri フィールドの値と照合し、3 つのフィールドを 名前付きグループ
license_type、version、および login として抽出します。
props.conf
では、この変換がソースの
.../banner_access_log*
と照合されます。
[source::.../banner_access_log*]
REPORT-banner = banner
この場合、正規表現は
uri
ソースのイベント内にある
.../banner_access_log
フィールドとのみ照合されます。
ただし、必要に応じて他のソース、ソースタイプ、およびホストと照合することができます。このような処理は、
インラインのフィールド抽出 (props.conf に全体が設定されているフィールド抽出) では実現できません。
注意： デフォルトでは、変換は _raw の SOURCE_KEY の値と照合されます。この場合、そのイベント内のフィールド
のみではなく、イベント全体に対して正規表現が適⽤されます。
［名前］ 列
[フィールド変換] ページの ［名前］ 列には、ご⾃分の権限で参照できるサーチ時フィールド変換の名前が表⽰さ
れます。これらの名前は、transforms.conf 内の実際のフィールド変換スタンザ名です。上記の変換例の場合
は、banner として表⽰されます。
変換名をクリックすると、その変換に関する詳細情報が表⽰されます。
変換の詳細のレビューと編集
フィールド変換の詳細ページでは、正規表現、キー、およびイベントフォーマットを表⽰、更新することができま
す。このサブトピックの最初に説明した banner 変換の詳細ページを以下に⽰します。
適切な権限があれば、正規表現、キー、およびイベントフォーマットを編集することができます。変換を複数の
ソース、ソースタイプ、またはホストに適⽤している場合、それを編集すると、props.conf および [フィールドの
32
抽出] ページに定義されている、複数のフィールド抽出に影響する可能性があることに注意してください。
新しいフィールド変換の作成
新しいフィールド変換を作成するには：
1. [フィールド変換] ページに移動して、[新規] ボタンをクリックします。
2. 現在の App ⽤のフィールド変換ではない場合、その宛先 App を指定します。
3. フィールド変換の名前 を指定します。これは、transforms.conf 内の変換スタンザ名になります。この変換を保
存すると、[フィールド変換] ページの ［名前］ 列にこれが表⽰されます。(これは必須フィールドです。)
4. 変換の正規表現 を⼊⼒します。(これは必須フィールドです。)
5. 必要に応じて、変換のキー を定義します。これは、transforms.conf 内の SOURCE_KEY オプションに対応していま
す。デフォルトでは _raw が設定されています。この場合、正規表現がイベント全体に適⽤されます。正規表現を
特定のフィールドの値に適⽤する場合は、_raw を⽬的のフィールド名に変更してください。フィールド変換実⾏時
に存在しているフィールドのみを使⽤できます。
6. 必要に応じて、イベントのフォーマット を指定します。これは、transforms.conf 内の FORMAT オプションに対応
しています。正規表現が捕捉したグループを指定する場合は、$n を使⽤します。たとえば、作成した正規表現が
2 つのグループを捕捉する場合、[フォーマット] には次のように設定します：$1::$2、ここで、最初のグループは
フィールド名、2 番⽬のグループはフィールド値になります。または、[フォーマット] を「username::$1
userid::$2」のように指定します。この場合、正規表現は username および userid フィールドの値を抽出します。
[フォーマット] フィールドのデフォルトは、「<変換スタンザ名>::$1」になります。
正規表現の構⽂と使⽤法
正規表現の構⽂と使⽤⽅法の概要については、Regular-Expressions.info を参照してください。正規表現をテス
トするには、rex サーチコマンドのを使⽤します。正規表現式を作成、テストするために役⽴つサードパーティ製
ツールのリストも⽤意されています。
重要： 正規表現で複数のグループを取得する場合は、英数字とアンダースコアを使⽤したフィールド名を指定す
る必要があります。
フィールド名に使⽤できる⽂字は、a-z、A-Z、0-9、 、_ です。
フィールド名の先頭に、0-9 または _ を使⽤することはできません。先頭のアンダースコアは、Splunk
Enterprise の内部変数⽤に予約されています。
国際⽂字は使⽤できません。
Splunk Enterprise は、サーチ時に抽出されたすべてのフィールド (デフォルトおよびカスタム設定による抽出
フィールド) に、以下の「キークリーニング」ルールを適⽤します。
1. a-z、A-Z、および 0-9 以外 のすべての⽂字は、アンダースコア (_) に置換されます。
2. キークリーニングが有効になっている場合 (デフォルトで有効)、抽出されたフィールドから先頭のアンダースコ
アまたは数字 (0-9) がすべて削除されます。
内のスタンザに
無効にすることができます。
transforms.conf
CLEAN_KEYS=false
を設定することで、特定のフィールド変換のキークリーニングを
注意： インラインフィールド抽出 (フィールド変換コンポーネントが不要なフィールド抽出) のキークリーニング
をオフにすることはできません。
例 - イベントからのフィールド名と対応する値の抽出
イベントのフォーマット 属性と適切に設計された正規表現式を使って、⼀致する各イベントからフィールド名と
対応する値の両⽅を抽出するフィールド変換を設定できます。
ここでは、Splunk Enterprise に同梱されている変換を使った例を説明していきます。
フィールド変換には、イベントデータの⾓括弧内にあるフィールド名/値のペアを検索する正規表現
式があります。これは、イベント内のすべての⼀致するフィールド/値のペアを抽出するまで、この正規表現を適
⽤していきます。
bracket-space
33
このトピックの最初の⽅で説明したように、フィールド変換は常にフィールド抽出と関連付けられます。Splunk
Web の [フィールドの抽出] ページで、osx-asl:REPORT-asl 抽出に bracket-space フィールド変換が関連付けられて
いることを確認できます。
フィールド変換権限の更新
デフォルトでフィールド変換の作成当初は、作成者のみがそれを利⽤できます。他のユーザーにもフィールド変換
を利⽤させる場合は、その権限 を更新する必要があります。そのためには、[フィールド変換] ページ内の⽬的の
フィールド変換の [権限] リンクを選択します。ナレッジオブジェクト の標準の権限管理⽤ページが表⽰されま
す。
このページでは、フィールド変換のロールベース の権限の設定、および特定の App のユーザーに使⽤させるか、
またはすべての App のユーザーにグローバルに使⽤させるかを指定することができます。Splunk Web を使った
権限の管理の詳細は、このマニュアルの「ナレッジオブジェクトの権限の管理」を参照してください。
フィールド変換の削除
Splunk Web の [フィールド変換] ページでは、必要な権限があればフィールド変換を削除することができます。
削除するフィールド抽出の [削除] をクリックします。
注意： 下流の依存関係があるナレッジオブジェクトの削除時には注意する必要があります。たとえば、フィール
ド変換で抽出されたフィールドが、あるサーチで使⽤されており、そのサーチが他の 5 種類のレポート (その中の
2 つはダッシュボードパネルに利⽤されている) が使⽤しているイベントタイプの基盤となっている場合、フィー
ルド変換を削除するとそれらのすべてのナレッジオブジェクトに悪影響を与えてしまいます。ナレッジオブジェク
ト削除の詳細は、このマニュアルの「ナレッジオブジェクトの無効化または削除」を参照してください。
設定ファイルを使ったサーチ時フィールド抽出の作成と管理
Splunk Web を使ってサーチ時フィールド抽出 を設定、管理することができますが、それが props.conf および
transforms.conf のレベルでどのように扱われているのかを理解することが重要です。これらの設定ファイルは、
Splunk 管理の [フィールドの抽出] ページおよび [フィールド変換] ページでの作業時に読み書きされるファイル
です。
多くのナレッジ管理者、特に Splunk Enterprise の利⽤経験が⻑い⽅は、設定ファイルを使ってカスタムフィー
ルドの追加、編集、レビューなどの管理作業を⾏う⽅が簡単と感じる場合が多いでしょう。設定ファイルでは、
フィールド抽出⽤の [設定] ページよりも、より幅広いフィールド抽出オプションを利⽤することができます。
ここでは、以下の作業について説明していきます。
props.conf
props.conf
の編集による、基本的な「インライン」サーチ時フィールド抽出の設定。
と transforms.conf の編集による、より複雑なサーチ時フィールド抽出の作成。
正規表現とフィールド名の構⽂
Splunk は正規表現正規表現を使って、イベントデータからフィールドを抽出します。対話式フィールド抽出
(IFX) を使⽤して、指定内容に応じたフィールド抽出⽤正規表現を⽣成できますが、⼀度に 1 つのフィールドを抽
出する正規表現しか作成できません。
設定ファイルを使って⼿動でフィールドの抽出を設定する場合は、正規表現を⾃分で指定する必要がありますが、
必要に応じてイベントから複数のフィールドを抽出する正規表現を作成することができます。
正規表現の構⽂と使⽤⽅法の概要については、Regular-Expressions.info を参照してください。正規表現をテス
トするには、rex サーチコマンドのを使⽤します。正規表現式を作成、テストするために役⽴つサードパーティ製
ツールのリストも⽤意されています。
34
重要： 正規表現で複数のグループを取得する場合は、英数字とアンダースコアを使⽤したフィールド名を指定す
る必要があります。「適切なフィールド名構⽂の使⽤」を参照してください。
適切なフィールド名構⽂の使⽤
Splunk Enterprise では、フィールド名に英数字とアンダースコアのみを使⽤できます。
フィールド名に使⽤できる⽂字は、a-z、A-Z、0-9、 、_ です。
フィールド名の先頭に、0-9 または _ を使⽤することはできません。先頭のアンダースコアは、Splunk
Enterprise の内部変数⽤に予約されています。
国際⽂字は使⽤できません。
Splunk Enterprise は、サーチ時に抽出されたすべてのフィールド (デフォルトおよびカスタム設定による抽出
フィールド) に、以下の「キークリーニング」ルールを適⽤します。
1. a-z、A-Z、および 0-9 以外 のすべての⽂字は、アンダースコア (_) に置換されます。
2. キークリーニングが有効になっている場合 (デフォルトで有効)、抽出されたフィールドから先頭のアンダースコ
アまたは数字 (0-9) がすべて削除されます。
特定のサーチ時フィールド抽出のキークリーニングを無効にすることができます。そうするには、その抽出を⾼度
な REPORT 抽出タイプとして設定し、参照フィールド変換スタンザに CLEAN_KEYS=false を設定します。REPORT
抽出設定の詳細は、後述の説明を参照してください。
注意： 基本的な EXTRACT (props.conf のみ) フィールド抽出設定では、キークリーニングをオフにすることはで
きません。
props.conf の編集による基本的なサーチ時フィールド抽出の作成
設定ファイルを編集して、基本的なサーチ時フィールド抽出 (transforms.conf 内のフィールド変換 を参
照しない、props.conf 内に全体が定義されるフィールド抽出)を作成できます。props.conf は
$SPLUNK_HOME/etc/system/local/、または $SPLUNK_HOME/etc/apps/ 内の独⾃のカスタム App ディレクトリにあります。
(カスタムデータを他のサーチサーバーに⼿軽に転送したいような場合は、後者のディレクトリを使⽤することを
お勧めします。)
props.conf
注意： $SPLUNK_HOME/etc/system/default/ 内のファイルは編集しないでください 。
設定ファイルの⼀般情報については、『管理マニュアル』の「設定ファイルについて」を参照してください。
props.conf を使った基本的なサーチ時フィールド抽出の定義⼿順
基本的なサーチ時フィールド抽出は、props.conf 内の EXTRACT 抽出設定を使⽤します。各 EXTRACT 抽出スタ
ンザには、サーチ時に Splunk Enterprise が 1 つまたは複数のフィールドの抽出に使⽤する正規表現、および
フィールドの抽出⽅法を⽰すその他の属性が含まれています。
基本的なサーチ時フィールド抽出を作成するには、以下の⼿順に従ってください。
1. props.conf 内のすべての抽出設定は、特定のソース、ソースタイプ、またはホストに制限されています。まず、
フィールドを抽出するイベントを提供するソースタイプ、ソース、またはホストを判別します。
注意： ホスト、ソース、およびソースタイプの詳細は、『データの取り込み』マニュアルの「デフォルトフィー
ルドについて (host、source、source type など)」を参照してください。
2. イベント内のフィールドを識別する正規表現を作成します。抽出した値のフィールド名を指定するには、名前付
きグループを使⽤します。前のセクションで説明しているフィールド名構⽂を使⽤してください。
3. EXTRACT フィールド抽出タイプ (次のセクションで説明) のフォーマットに従って、props.conf 内にホスト/
ソース/ソースタイプと正規表現を指定したフィールド抽出スタンザを作成します。$SPLUNK_HOME/etc/system/local/
内、またはカスタム App ディレクトリ $SPLUNK_HOME/etc/apps/ 内にある props.conf ファイルを編集してください。
注意： $SPLUNK_HOME/etc/system/default/ 内のファイルは編集しないでください 。
4. フィールド値が単語の⼀部である場合は、fields.conf にもエントリを追加する必要があります。下の例「サブ
トークンからのフィールドの作成」を参照してください。
5. 変更内容を有効にするために、Splunk Enterprise を再起動します。
props.conf への EXTRACT フィールド抽出スタンザの追加
props.conf
に EXTRACTフィールド抽出スタンザを追加するには、以下のフォーマットに従ってください。
[<spec>]
EXTRACT-<class> = [<regular_expression>|<regular_expression> in <source_field>]
<spec>
には、以下の値を使⽤できます。
<source type>、イベントのソースタイプ。
host::<host>、<host>
はイベントのホストを表します。
はイベントのソースを表します。
source::<source>、<source>
35
rule::<rulename>、ここで <rulename>
はソースタイプ分類ルールの⼀意の名前です。
は遅延ソースタイプ分類ルールの⼀意の名前です。
delayedrule::<rulename>、ここで <rulename>
注意： ruleと
れます。
delayedrule
は、ソースに基づいて新しいソースタイプを⽣成する前の、最終⼿段としてのみ考慮さ
は、抽出するフィールド (キー) の名前空間を識別する⼀意のリテラル⽂字列です。
注意： <class>の値は、フィールド名構⽂の制限 (前述) に従う必要はありません。a-z、A-Z、および 09 以外の⽂字を使⽤でき、またスペースも利⽤できます。<class>値はキークリーニングの影響を受け
ません。
名前付きグループを使⽤するには <regular_expression> が必要です。各グループが、異なる抽出フィールドを
表します。<regular_expression> がイベントに⼀致すると、名前付きグループとその値がイベントに追加
されます。
正規表現を特定のフィールドの値と照合する場合は、<regular_expression> in <source_field> を使⽤します。
それ以外の場合は、_raw に対して照合されます (すべての raw イベントデータ)。
注意： <src_field>はフィールド名なので、フィールド名構⽂に従う必要があります。英数字 (a-z、AZ、および 0-9) のみを使⽤できます。
正規表現を in <string> で終了する必要がある場合 (ここで <string> はフィールド名ではない )、<string> が
フィールド名と照合されないように、[i]n <string> で正規表現を終了するように変更してください。
<class>
EXTRACT フィールド抽出タイプの優先ルール：
各フィールド抽出に対して、Splunk Enterprise は優先度がもっとも⾼い設定スタンザの設定を使⽤しま
す。
複数のカテゴリの⼀致する [<spec>] スタンザがある場合、[host::<host>] 設定が [<sourcetype>] 設定に優先し
ます。
[source::<source>] 設定は、[host::<host>] と [<sourcetype>] の両⽅の設定に優先します。
同様に、<spec> に対して ../local/ に特定のフィールド抽出が指定されている場合、それが ../default/ のク
ラスに優先します。
他にも
[<spec>]
スタンザの優先順位が存在しています。詳細は、props.conf.spec を参照してください。
注意： Splunk Enterprise がインデックス時に抽出するデフォルトのフィールドセットの設定⼿順とは違い、
サーチ時フィールド抽出中は何もインデックスに書き込まれないため、transforms.conf には DEST_KEY は必要ありま
せん。サーチ時に抽出されるフィールドは、インデックス中にキーとしては保持されません。
サーチ時フィールド抽出の実⾏時、Splunk Enterprise は優先ルールに従って処理を⾏います。まずインラインの
フィールド抽出 (EXTRACT-<class>) が実施され、次にツールバー変換を参照するフィールド抽出 (REPORT-<class>) が
⾏われます。
サーチ時データの KV_MODE の設定
属性を使って、データのフィールド/値の抽出モードを指定できます。KV_MODE は
スタンザに追加できます。フォーマットを以下に⽰します。
KV_MODE
EXTRACT
または
REPORT
KV_MODE = [none|auto|multi|json|xml]
none：スタンザ名が⽰すソース、ソースタイプ、またはホストのフィールド抽出を無効にします。この設定
を使って、作成した他の正規表現が、特定のソース、ソースタイプ、またはホストのフィールド/値の⾃動抽
出により優先されないようにすることができます。また、この設定を使って共通の必須ではないフィールド
の抽出を無効にすることにより、サーチのパフォーマンスを向上することができます。このトピックの最後
には、異なる環境下でフィールド抽出を無効にする例が記載されています。
auto：フィールド/値のペアを抽出して、それらを等号で区切ります。フィールド抽出スタンザにこの属性を
指定していない場合は、これがデフォルト値になります。
auto_escaped：フィールド/値のペアを抽出して、それらを等号で区切ります。また、この設定では引⽤符で
囲まれた値内の「\"」と「\\」が、エスケープされた⽂字列として処理されます。例：field="value with
\"nested\" quotes"。
multi：表形式のイベントからフィールド値を抽出する、multikv コマンドを起動します。
xml：フィールド抽出スタンザを使って XML データからフィールドを抽出する場合は、この設定を使⽤しま
す。
json：フィールド抽出スタンザを使って JSON データからフィールドを抽出する場合は、この設定を使⽤し
ます。
xml および json モードを、指定したフォーマット (XML または JSON) 以外のデータに使⽤すると、フィー
ルドは抽出されません。
インライン (props.conf のみ) サーチ時フィールド抽出の例
ここには、props.conf のみを使った、いくつかのサーチ時フィールド抽出の例を記載しています。
新しいエラーコードフィールドの追加
この例では、props.conf にフィールド抽出を設定することで、新しいフィールド「error code」を作成する⽅法を
表しています。フィールドは、device_id= に続けて括弧に囲まれた単語、およびコロンで終了するテキスト⽂字列
で識別できます。このフィールドを testlog ソースタイプに関連するイベントから抽出する必要があります。
props.conf
に以下の項⽬を追加します。
36
[testlog]
EXTRACT-errors = device_id=\[w+\](?<err_code>[^:]+)
1 つの正規表現を使った複数のフィールドの抽出
これは、5 つの個別のフィールドを抽出する例です。次にこれらのフィールドとイベントタイプを使って、ポート
フラッピングイベントを検索、レポートします。
フィールドを抽出するイベントデータの例を以下に⽰します。
#%LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet9/16, changed state to down
抽出するための
props.conf
のスタンザは以下のようになります。
[syslog]
EXTRACT-port_flapping = Interface\s(?<interface>(?<media>[^\d]+)(?<slot>\d+)\/(?<port>\d+))\,\schanged
\sstate\sto\s(?<port_status>up|down)
5 つの個別のフィールドは、名前付きグループ interface、media、slot、port、および port_status として抽出さ
れることに注意してください。
以下の 2 つのステップはフィールド抽出には必要ありません。これらのステップは、抽出したフィールドを使っ
た、ポートフラッピングイベントの検索と、それのレポート⽅法を表しています。
eventtypes.conf に、タグを使って⼀連のイベントタイプを定義します。
[cisco_ios_port_down]
search = "changed state to down"
[cisco_ios_port_up]
search = "changed state to up"
最後に savedsearches.conf に、上記の事項を合わせてポートフラッピングを検索して結果を報告する、レポート
を作成します。
[port flapping]
search = eventtype=cisco_ios_port_down OR eventtype=cisco_ios_port_up starthoursago=3 | stats count by
interface,host,port_status | sort -count
サブトークンからのフィールドの作成
⼤きなトークンの⼀部となるサブトークンのフィールド値を抽出する場合、問題が発⽣する可能性があります。
トークンは、インデックス作成前のイベント処理が⾏われた、イベントデータのチャンクです。イベント処理時に
イベントはセグメントに分割され、トークンが作成されます。作成された各セグメントがトークンになります。
トークンは、1 つの完全な単語または数字より細かくはなりません。たとえば、イベント内に foo123 と⾔う単語
がある場合を考えてみましょう。イベントの処理が⾏われてインデックスが作成されると、これがトークンとな
り、あるフィールドの値となります。しかし、抽出でフィールドの値として foo を取得する場合、これはサブトー
クンを抽出することになります。ここで問題となるのは、インデックスに存在しているのが foo123 で foo ではな
いことです。そのため、正常にサーチ結果が抽出されるように⾒えても、そのサブトークンに対してサーチを実⾏
すると、ほとんど結果は得られません。
トークンは⽂字列内の個別の単語よりも細かくはなりません。そこで、サブトークン (単語の⼀部) のフィールド
抽出を実⾏しても、それがインデックスには存在しない (それが所属しているより⼤きな単語のみがインデックス
にある) ため、問題が発⽣する可能性があります。
フィールド値が細かなトークンの⼀部である場合は、上記の説明に従って
次に、以下のエントリを fields.conf に追加します。
props.conf
を設定する必要があります。
[<fieldname>]
INDEXED = False
INDEXED_VALUE = False
<fieldname> には、フィールド名を指定します。
たとえば、名前が「url」のフィールドを設定した場合は、[url] のように指定します。
INDEXED と INDEXED_VALUE に false を設定します。
こう指定することで、サーチしているのがインデックス内のトークンではないことを Splunk
Enterprise に知らせます。
注意： リリース 4.3 以降では、インデックスが作成されていない (トークン化されていない) デフォルトのフィー
ルド (host、source、sourcetype、timestamp など) の値からフィールドの値を抽出する場合、fields.conf にこのエン
トリを追加する必要がなくなりました。
37
イベントデータのトークン化の詳細は、『Getting Data In』マニュアルの「About segmentation」を参照してく
ださい。
フィールド変換を使った⾼度なサーチ時フィールド抽出の作成
⼤半のサーチ時フィールド抽出は props.conf に定義できますが、⼀部の⾼度なサーチ時フィールド抽出で
は、フィールド変換 と呼ばれる追加コンポーネントを参照します。ここでは、transforms.conf へのフィールド変
換の設定⽅法を説明していきます。
フィールド変換には、フィールド抽出正規表現と、抽出フィールドの変換⽅法を⽰すその他の属性が含まれていま
す。フィールド変換は、常に props.conf 内のフィールド抽出スタンザと⼀緒に作成されます。単独で作成すること
はできません。
以下のような場合に、サーチ時フィールド抽出にフィールド変換コンポーネントが必要になります。
複数のソース、ソースタイプ、またはホストにまたがって同じフィールド抽出正規表現を再利⽤する
(複数のフィールド抽出⽤に 1 つのフィールド変換を設定する)。異なるソース、ソースタイプ、およびホス
トに対するフィールドの抽出に同じ正規表現を使⽤している場合は、それを変換として設定することができ
ます。そうすることで、正規表現を更新する必要がある場合は、複数のフィールド抽出が使⽤しているよう
な場合でも、1 回の変更で作業が完了します。
同じソース、ソースタイプ、またはホストに対して複数のフィールド抽出正規表現を適⽤する (同じ
フィールド抽出に複数のフィールド変換を適⽤する)。これは、特定のソース/ソースタイプ/ホストから抽出
するフィールドが、複数の異なるイベントパターンで登場するような場合に必要になります。
区切り⽂字ベースのフィールド抽出を設定する。 区切り⽂字ベースの抽出は、カンマ、コロン、ハイフ
ン、改⾏、タブ、スペースなどの区切り⽂字で区切られたフィールド/値のペア (または単なるフィールド
値) がイベントデータに存在している場合に役⽴ちます。
複数値フィールドから設定を抽出する。 この場合、イベントデータ内で⾒つかったフィールドに、追加の
フィールド値が追加されます。
数字またはアンダースコアで始まる名前を持つフィールドを抽出する。 通常のキークリーニングでは、
フィールド名の先頭にある数字とアンダースコアが削除されますが、必要に応じてこの機能をオフにするよ
うにフィールド変換を設定することができます。
フィールド変換には、以下のような設定を⾏うこともできます。
属性を使って、他のフィールド (_raw 以外) の値からフィールドを抽出する。
複数のフィールドを抽出するまたはフィールド名とフィールド値の両⽅を抽出する場合に、FORMAT 属性を
使って抽出されたフィールドのフォーマットを管理する。
SOURCE_KEY
これらの両⽅の設定を、正規表現に直接設定することができます。⽅法の詳細は、後述する「フィールド変換の定
義」を参照してください。
注意： ⼀連の正規表現抽出を単⼀のフィールド値に連結する場合は、FORMAT 属性を使⽤します。ただし、イン
デックス時抽出として設定した場合にのみ使⽤することができます。たとえば、イベントデータ内に
192(x)0(y)2(z)1 のような⽂字列が存在する場合、それをインデックス時に ip address フィールド値とし
て、192.0.2.1 のフォーマットで抽出することができます。詳細は、『データの取り込み』マニュアルの「イン
デックス時フィールド抽出の設定」を参照してください。ただし、インデックス作成されたフィールドセットに⼤
幅な変更を加えることはお勧めできません。変更する必要がある場合でも慎重に作業を⾏ってください。
フィールド変換を参照するカスタムサーチ時フィールド抽出の定義⼿順
⾼度なサーチ時フィールド抽出は、props.conf 内の REPORT 抽出設定を使⽤します。各 REPORT 抽出スタンザ
が、transforms.conf に個別に定義されているフィールド変換を参照します。フィールド変換には、サーチ時に
Splunk Enterprise がフィールドの抽出に使⽤する正規表現、およびそれらのフィールド抽出の変換⽅法を⽰す他
の属性が含まれます。
⾼度なサーチ時フィールド抽出を作成するには、以下の⼿順に従ってください。
1. props.conf 内のすべての抽出設定は、特定のソース、ソースタイプ、またはホストに制限されています。まず、
フィールドを抽出するイベントを提供するソースタイプ、ソース、またはホストを判別します。(まだ props.conf
は更新しないでください。)
注意： ホスト、ソース、およびソースタイプの詳細は、『データの取り込み』マニュアルの「デフォルトフィー
ルドについて (host、source、source type など)」を参照してください。
2. イベント内のフィールドを識別する正規表現を作成します。抽出した値のフィールド名を指定するには、名前付
きグループを使⽤します。前のセクションで説明しているフィールド名構⽂を使⽤してください。
注意： イベントにフィールド/値のペアまたは単にフィールド値のリストがある場合、正規表現を使わない区切り
⽂字ベースのフィールド抽出を作成できます。詳細は後述する DELIMS 属性の説明を参照してください。
3. transforms.conf 内に、この正規表現 (または区切り⽂字設定) を利⽤するフィールド変換を作成します。この変
換には、ソースキーやイベント値のフォーマットを定義することもできます。
内、またはカスタム App ディレクトリ
ファイルを編集してください。
$SPLUNK_HOME/etc/system/local/
transforms.conf
$SPLUNK_HOME/etc/apps/
内にある
注意： $SPLUNK_HOME/etc/system/default/ 内のファイルは編集しないでください 。
4. REPORT フィールド抽出タイプ (2 つ後のセクションで説明) のフォーマットに従って、props.conf 内にステッ
プ 1 で識別したホスト、ソース、またはソースタイプを使⽤するフィールド抽出スタンザを作成します。必要に
応じて、同じフィールド変換を参照する、その他のホスト、ソース、およびソースタイプのフィールド抽出スタン
38
ザを作成することができます。
内、またはカスタム App ディレクトリ
ファイルを編集してください。
$SPLUNK_HOME/etc/system/local/
$SPLUNK_HOME/etc/apps/
内にある
props.conf
注意： $SPLUNK_HOME/etc/system/default/ 内のファイルは編集しないでください 。
5. 変更内容を有効にするために、Splunk Enterprise を再起動します。
まず、フィールド変換を定義します
transforms.conf
にサーチ時フィールド変換を定義する場合は、以下のフォーマットに従ってください。
[<unique_transform_stanza_name>]
REGEX = <regular expression>
FORMAT = <string>
SOURCE_KEY = <string>
DELIMS = <quoted string list>
FIELDS = <quoted string list>
MV_ADD = [true|false]
CLEAN_KEYS = [true|false]
KEEP_EMPTY_VALS = [true|false]
CAN_OPTIMIZE = [true|false]
すべてのサーチ時変換に、<unique_transform_stanza_name> が必要です。注
意： <unique_transform_stanza_name>の値は、フィールド名構⽂の制限 (前述) に従う必要はありません。a-z、
A-Z、および 0-9 以外の⽂字を使⽤でき、またスペースも利⽤できます。これらはキークリーニングの影響
を受けません。
REGEX は、データからフィールドを抽出するための正規表現です。区切り⽂字ベースのトランザクションを設
定する場合を除き、すべてのサーチ時フィールド変換に必要です。区切り⽂字ベースの場合は、DELIMS 属性
を使⽤します (後述する DELIMS 属性の説明を参照)。
デフォルトは空⽂字列です。
REGEX および FORMAT 属性。
REGEX の名前取得グループは、直接フィールドに抽出されます。単純なフィールド抽出の場合
は、FORMAT を指定する必要はありません。
REGEX でフィールド名と対応する値の両⽅を抽出する場合、以下の特殊グループを使って FORMAT のマッ
ピング指定をスキップすることができます。
<_KEY_><string>、<_VAL_><string>。
たとえば、以下の事項は同じ意味を持っています。
FORMAT
を使⽤：
REGEX = ([a-z]+)=([a-z]+)
FORMAT = $1::$2
FORMAT
を不使⽤：
REGEX = (?<_KEY_1>[a-z]+)=(?<_VAL_1>[a-z]+)
どちらの場合でも、イベントのソーステキストに正規表現が繰り返し適⽤されて、⼀致するすべてのフィー
ルド/値のペアが抽出されます。
は省略することができます。これは、抽出するフィールド/値のペアのフォーマットを指定するために
使⽤します。単純な名前付きグループを持つ REGEX の場合、FORMAT を指定する必要はありません。
サーチ時抽出の場合、FORMAT のパターンは以下のようになります。
FORMAT
FORMAT = <field-name>::<field-value>(<field-name>::<field-value>)*
ここで：
field-name = [<string>|$<extracting-group-number>]
field-value = [<string>|$<extracting-group-number>]
サーチ時
1.
2.
FORMAT
の使⽤例：
FORMAT = firstfield::$1 secondfield::$2 thirdfield::other-value
FORMAT = $1::$2
に変数フィールド名を設定した場合 (上記の例 2 のように、フィールド名を表す $1 など)、ソースイ
ベントテキストに対して正規表現が繰り返し適⽤され、⼀致するフィールド/値のペアがすべて抽出されま
す。
注意： サーチ時に FORMAT を使って連結フィールドを作成することはできません。この機能は、イン
デックス時のフィールド変換でのみ利⽤できます。
FORMAT のデフォルトは空⽂字列です。
FORMAT
39
は省略することができます。これは、他のフィールド値から 1 つまたは複数の値を抽出するため
に使⽤します。このフィールド抽出の実⾏時に利⽤できる、任意のフィールドを使⽤できます。
SOURCE_KEY を設定する場合、変換の REGEX を適⽤するフィールドを指定します。
デフォルトでは、SOURCE_KEY には _raw が設定されます。この場合、すべてのイベントの raw (未処理
の) テキストに適⽤されます。
SOURCE_KEY
は省略することができます。フィールド値またはフィールド/値のペアが、カンマ、コロン、スペー
ス、タブ、改⾏などで区切られている場合に、区切り⽂字ベースのフィールド抽出を使⽤するには、REGEX の
代わりにこれを使⽤します。
区切り⽂字は " " で囲む必要があります。必要に応じて円記号 (バックスラッシュ) を使って、⼆重引
⽤符をエスケープ処理することができます (\")。
重要：値にエスケープ処理が⾏われていない⼆重引⽤符が含まれている場合 (例："foo"bar") は、
DELIMS ではなく REGEX を使⽤することをお勧めします。
区切り⽂字列内の各⽂字が、区切り⽂字として使⽤され、イベントが分割されます。
イベントに完全に区切り⽂字で区切られたフィールド/値のペアが含まれている場合は、DELIMS に対し
て 2 つのセットの引⽤符で囲んだ区切り⽂字を指定します。最初のセットの引⽤符で囲んだ区切り⽂
字は、フィールド/値のペアを区切ります。2 番⽬のセットは、フィールド名とそれに対応する値を区
切ります。
イベントに、区切り⽂字で区切られた値のみが含まれている場合 (フィールド名がない) は、引⽤符で
囲んだ区切り⽂字の単⼀セットを指定して、各値を区切ります。次に FIELDS 属性を使って、フィール
ド名を抽出された値に適⽤します (後述する FIELDS を参照)。代わりに、Splunk Enterprise は偶数の
トークンをフィールド名として、奇数のトークンをフィールド値として読み取ります。
Splunk Enterprise は、フィールド名のリストを指定しない限り、連続する区切り⽂字を処理します。
デフォルトは空⽂字列です。
フィールド/値のペアが「|」記号で区切られ、フィールド名と対応する値は「=」記号で区切られてい
るイベントに適⽤する、DELIMS の使⽤例を以下に⽰します。
DELIMS
[pipe_eq]
DELIMS = "|", "="
は、区切り⽂字のフィールド抽出を実⾏する際に、DELIMS と⼀緒に使⽤していますが、フィールド値
のみを抽出しています。値が抽出された順序によるリスト形式で、抽出したフィールド値に対応するフィー
ルド名を指定するには、FIELDS を使⽤します。
注意： フィールド名にスペースまたはカンマが含まれている場合は、それを引⽤符で囲む必要があり
ます (エスケープ処理するには \ を使⽤します)。
デフォルトは空⽂字列です。
イベント内に 3 つのフィールド値が登場する、区切り⽂字ベースの抽出例を以下に⽰します。これら
のフィールドは、カンマとスペースで区切られています。
FIELDS
[commalist]
DELIMS = ", "
FIELDS = field1, field2, field3
は省略することができます。同じフィールドが異なる値で複数回登場するイベントで、それらの
フィールド値を保持したい場合などに使⽤します。
MV_ADD = true の場合、イベント内に異なる値で複数回登場するフィールドが、複数値フィールド
(フィールド名は 1 つ、「=」記号に続けてフィールドの複数の値が登場) に変換されます。
MV_ADD=false の場合、フィールドに対してイベント内で最初に⾒つかった値が保持され、同じイベント
内でそのフィールドに対して⾒つかった残りの値は破棄されます。
デフォルトは false です。
MV_ADD
は省略することができます。これは、システムがキーから先頭のアンダースコアまたは 0-9 の数
字を除去するかどうかを⽰します (詳細は前述の「適切なフィールド名構⽂の使⽤」を参照)。「キークリー
ニング」とは、フィールド名内の英数字 (a-z、A-Z、および 0-9) 以外の⽂字をアンダースコアに置換し、ま
た先頭のアンダースコアと 0-9 ⽂字をフィールド名から削除する処理です。
フィールド名をそのまま保持する (先頭のアンダースコアや 0-9 ⽂字を削除しない) 場合は、変換に
CLEAN_KEYS = false を追加してください。
デフォルトでは、変換の CLEAN_KEYS には常に true が設定されます。
CLEAN_KEYS
は省略することができます。値が空⽂字列の場合に、フィールド/値のペアを保持するかどう
かを⽰します。
このオプションは、Splunk Enterprise の autokv 抽出 (⾃動フィールド抽出) 処理で⽣成された
フィールド/値のペアには適⽤されません。Autokv は、空⽂字列のフィールド/値のペアを無視しま
す。
デフォルトは false です。
KEEP_EMPTY_VALS
は省略することができます。Splunk Enterprise が抽出を最適化できるかどうか (抽出を無効化
できるかどうか) を⽰します。
フィールドの検出 を無効にするサーチ・モード 設定でサーチを実⾏するような場合などに、これを使
⽤します。これにより、Splunk Enterprise は常に特定のフィールドを検出します。
抽出で識別されたすべてのフィールドが、サーチの評価に不要だと判断できた場合にのみ、抽出が無
効化されます。
注意： この属性に false が設定されることはほとんどありません。
デフォルトは true です。
CAN_OPTIMIZE
次に、props.conf 内の REPORT フィールド抽出スタンザと関連するフィールド変換を設定します
フィールド変換に関連付けるサーチ時フィールド抽出を props.conf に設定する場合は、REPORT フィールド抽出クラ
スを使⽤します。以下のフォーマットに従ってください。
40
単⼀のフィールド抽出に複数のフィールド変換スタンザを関連付ける場合は、最初の
<unique_transform_stanza_name> の後にカンマで区切って指定します。(詳細は、このトピックの後半にある例を参照
してください。)
[<spec>]
REPORT-<class> = <unique_transform_stanza_name1>, <unique_transform_stanza_name2>,...
<spec>
には、以下の値を使⽤できます。
<sourcetype>、イベントのソースタイプ。
host::<host>、<host>
はイベントのホストを表します。
はイベントのソースを表します。
<class> は、抽出するフィールド (キー) の名前空間を識別する⼀意のリテラル⽂字列です。注意： <class>の
値は、フィールド名構⽂の制限 (前述) に従う必要はありません。a-z、A-Z、および 0-9 以外の⽂字を使⽤
でき、またスペースも利⽤できます。<class>値はキークリーニングの影響を受けません。
<unique_transform_stanza_name> は、transforms.conf からのフィールド変換スタンザ名です。
source::<source>、<source>
REPORT フィールド抽出クラスの優先ルール：
各クラスに対して、Splunk Enterprise は優先度がもっとも⾼い設定ブロックの設定を使⽤します。
source および sourcetype に対して特定のクラスが指定されている場合、source のクラスが優先されま
す。
同様に、<spec> に対して ../local/ に特定のクラスが指定されている場合、それが ../default/ のクラス
に優先します。
特定の順序で実⾏する必要がある⼀連の変換があり、それらが同じホスト、ソース、またはソースタイプに所属し
ている場合、それらを同じ props.conf のスタンザ内にカンマ区切り形式のリストとして指定することができま
す。Splunk Enterprise は指定された順序に処理を⾏います。たとえば、以下のように指定すると、まず [yellow]
フィールド変換が適⽤され、次に [blue] が、次に [red] が適⽤されます。
[source::color_logs]
REPORT-colorchange = yellow, blue, red
実⾏順序を変更する必要がある場合は、リスト内の項⽬の指定順序を変更します。
フィールド変換を使ったカスタムサーチ時フィールド抽出の例
これらの例は、transforms.conf 内に 1 つまたは複数のフィールド変換スタンザを設定し、次に props.conf 内の
フィールド抽出スタンザでそれらを参照する必要がある、カスタムフィールド抽出の使⽤事例を表しています。
複数のフィールド変換を利⽤するフィールド抽出の設定
このサーチ時フィールド変換設定例では、以下の⽅法について⾒ていきます。
イベントのさまざまなフィールド名/値のペアを取得する変換を作成する。
複数のフィールド変換を参照するフィールド抽出を作成する
複数のフィールド名/値のペアが含まれているログがある場合を考えてみましょう。イベントによってフィールド
は異なりますが、ペアは常に 2 種類のいずれかの形式で登場します。
ログにはしばしば以下のようなフォーマットが登場します。
[fieldName1=fieldValue1] [fieldName2=fieldValue2]
ただし、より複雑な複数の名前/値のペアのリストとして、以下のような形式で記録されている場合もあります。
[headerName=fieldName1] [headerValue=fieldValue1], [headerName=fieldName2] [headerValue=fieldValue2]
リスト項⽬はカンマで区切られており、各 fieldName は対応する fieldValue と照合されることに注意してくださ
い。この 2 番⽬の場合でも、サーチ結果が以下のようになるように、フィールド名と値を取得したいと考えてい
ます。
fieldName1=fieldValue1
fieldName2=fieldValue2
(以降も同様)
より明確になるように、ここでは上記の両⽅のフォーマットを持つ HTTP リクエストイベントの例を使⽤しま
す。
[method=GET] [IP=10.1.1.1] [headerName=Host] [headerValue=www.example.com], [headerName=User-Agent]
[headerValue=Mozilla], [headerName=Connection] [headerValue=close] [byteCount=255]
イベントから以下のフィールド/値のペアを取得する、単⼀のフィールド抽出を作成したいと考えています。
method=GET
41
IP=10.1.1.1
Host=www.example.com
User-Agent=Mozilla
Connection=close
byteCount=255
解決策
両⽅のフォーマットのフィールド/値のペアを効率的かつ⾼信頼に取得するために、各フォーマットに対して最適
化された 2 つの異なる正規表現を作成します。⽚⽅の正規表現は、最初のフォーマットのイベントを識別して、
⼀致するすべてのフィールド/値のペアを取得します。もう⼀⽅の正規表現は、別のフォーマットのイベントを識
別して、それらのイベントのフィールド/値のペアを取得します。
次に、transforms.conf 内に各正規表現に対応した、2 つの独⾃の変換を作成します。その後、props.conf 内の対応
するフィールド抽出スタンザで、両⽅を統合します。
transforms.conf
に追加する最初の変換は、⼀般的な
[fieldName1=fieldValue1] [fieldName2=fieldValue2]
を収集しま
す。
[myplaintransform]
REGEX=\[(?!(?:headerName|headerValue))([^\s\=]+)\=([^\]]+)\]
FORMAT=$1::$2
2 番⽬の変換 (同様に
transforms.conf
に追加) は、やや複雑な [headerName=fieldName1]
を収集します。
[headerValue=fieldValue1],
[headerName=fieldName2] [headerValue=fieldValue2]
[mytransform]
REGEX= \[headerName\=(\w+)\],\s\[headerValue=([^\]]+)\]
FORMAT= $1::$2
どちらの変換も <fieldName>::<fieldValue> FORMAT を使って、イベント内の各フィールド名と対応する値を照合しま
す。この FORMAT の設定により、すべての⼀致するフィールド/値のペアが抽出されるまで、正規表現によるイ
ベントの照合が継続されます。
最後に、props.conf 内に作成する以下のフィールド抽出スタンザで、両⽅のフィールド変換を参照します。
[mysourcetype]
KV_MODE=none
REPORT-a = mytransform, myplaintransform
複数のフィールド変換を使⽤するだけではなく、フィールド抽出スタンザには KV_MODE=none も設定されていること
に注意してください。これにより、識別されたソースタイプに対するフィールド/値の抽出が無効化されます (⼿
動で定義された抽出は継続)。この設定により、⾃動フィールド抽出がこれらの新しい正規表現に優先されること
を防⽌でき、またサーチパフォーマンスの向上にも役⽴ちます。(キー/値の抽出の、無効化の詳細については後述
します。)
区切り⽂字ベースのフィールド抽出の設定
フィールド変換で DELIMS 属性を使⽤して、フィールド値またはフィールド/値のペアがカンマ、コロン、タブ、ス
ペースなどの区切り⽂字で区切られているイベントの、フィールド抽出を設定することができます。
たとえば、異なるフィールド/値のペアが個別の⾏に配置され、各ペアがコロンとタブで区切られている、複数⾏
イベントを考えてみましょう。イベントの例を以下に⽰します。
ComponentId:
Application Server
ProcessId:
5316
ThreadId:
00000000
ThreadName:
P=901265:O=0:CT
SourceId:
com.ibm.ws.runtime.WsServerImpl
ClassName:
MethodName:
Manufacturer:
IBM
Product:
WebSphere
Version:
Platform 7.0.0.7 [BASE 7.0.0.7 cf070942.55]
ServerName:
sfeserv36Node01Cell\sfeserv36Node01\server1
TimeStamp:
2010-04-27 09:15:57.671000000
UnitOfWork:
Severity:
3
Category:
AUDIT
PrimaryMessage:
WSVR0001I: Server server1 open for e-business
ExtendedMessage:
42
内に、これらのすべてのフィールドを処理する、⻑くて冗⻑なサーチ時フィールド抽出スタンザを設定
することができます。
props.conf
[activityLog]
LINE_BREAKER = [-]{8,}([\r\n]+)
SHOULD_LINEMERGE = false
EXTRACT-ComponentId = ComponentId:\t(?.*)
EXTRACT-ProcessId = ProcessId:\t(?.*)
EXTRACT-ThreadId = ThreadId:\t(?.*)
EXTRACT-ThreadName = ThreadName:\t(?.*)
EXTRACT-SourceId = SourceId:\t(?.*)
EXTRACT-ClassName = ClassName:\t(?.*)
EXTRACT-MethodName = MethodName:\t(?.*)
EXTRACT-Manufacturer = Manufacturer:\t(?.*)
EXTRACT-Product = Product:\t(?.*)
EXTRACT-Version = Version:\t(?.*)
EXTRACT-ServerName = ServerName:\t(?.*)
EXTRACT-TimeStamp = TimeStamp:\t(?.*)
EXTRACT-UnitOfWork = UnitOfWork:\t(?.*)
EXTRACT-Severity = Severity:\t(?.*)
EXTRACT-Category = Category:\t(?.*)
EXTRACT-PrimaryMessage = PrimaryMessage:\t(?.*)
EXTRACT-ExtendedMessage = ExtendedMessage:\t(?.*)
ただ、このような設定は実⽤的ではありません。これらの
しょうか？もちろん、存在しています！
transforms.conf
EXTRACT
⾏を使わない、もっとうまいやり⽅はないで
に以下のスタンザを設定してください。
[activity_report]
DELIMS = "\n", ":\t"
これは、イベント内のフィールド/値のペアが個別の⾏に存在しており ("\n")、次に各⾏のフィールド名とフィー
ルド値がコロンとタブで区切られていること (":\t") を記述しています。
この設定を完成するには、props.conf のスタンザにある上記の冗⻑な設定を、以下のように書き直します。
[activitylog]
LINE_BREAKER = [-]{8,}([\r\n]+)
SHOULD_LINEMERGE = false
REPORT-activity = activity_report
これら 2 つの簡単な設定で、前と同じセットのフィールドを抽出できます。ただし、こちらの⽅がエラーが発⽣
する可能性も少なく、より柔軟性に優れています。
複数値フィールドを持つイベントの処理
あるイベント内に同じフィールドが複数回登場し、毎回別の値を保有しているような場合に、MV_ADD 属性を使っ
て、フィールドを抽出することができます。通常 Splunk Enterprise では、イベント内の最初のフィールド値の
みが抽出され。残りの値は破棄されます。ただし、transforms.conf で MV_ADD に true を設定すると、フィール
ドが複数値フィールドのように処理されて、イベント内の各⼀意のフィールド/値のペアが抽出されます。
以下のような⼀連のイベントがある場合を考えてみましょう。
event1.epochtime=1282182111 type=type1 value=value1 type=type3 value=value3
event2.epochtime=1282182111 type=type2 value=value4 type=type3 value=value5 type=type4 value=value6
各イベント内に type および value フィールドが複数回登場しているのがお分かりでしょうか？ここで
は、type=type3 のサーチを実⾏して、これらの両⽅のイベントを返します。また、5 を返したイベントの
count(type) レポートを実⾏します。
そのためには、これらのイベントの type の複数値抽出を作成します。そのための、transforms.conf と
ファイルの設定⽅法を説明していきます。
まず、transforms.conf を設定します。
[mv-type]
REGEX = type=(?<type>\s+)
MV_ADD = true
次に、props.conf で、ソースタイプまたはソースに対して、以下のように設定します。
43
props.conf
次に、props.conf で、ソースタイプまたはソースに対して、以下のように設定します。
REPORT-type = mv-type
特定のソース、ソースタイプ、またはホストに対する、サーチ時⾃動フィールド抽出の無
効化
を編集して、特定のソース、ソースタイプ、またはホストに対する、サーチ時⾃動フィールド抽出を無
効にすることができます。props.conf の適切な [<spec>] に、KV_MODE = none を追加してください。
props.conf
注意： Splunk Web で設定ファイルに⼿動設定されたカスタムフィールド抽出は、対象のソース、ソースタイ
プ、またはホストに KV_MODE = none が設定されている場合でも、引き続き処理が⾏われます。
[<spec>]
KV_MODE = none
<spec>
には、以下の値を使⽤できます。
- イベントのソースタイプ。
はイベントのホストを表します。
source::<source>、<source> はイベントのソースを表します。
<sourcetype>
host::<host>、<host>
複数値フィールドの設定
複数値フィールドは、イベント内に複数回登場するフィールドで、それぞれが異なる値を保有しています。複数値
フィールドの⼀般的な例として、メールアドレスフィールドが挙げられます。⼀般的にこのフィールドは単⼀の
sendmail イベント内に 2〜3 回登場します (送信者⽤、⼀連の受信者⽤、そして CC アドレスが指定されている
場合はそのリスト⽤)。これらのすべてのフィールドに同⼀のラベルが設定されている場合 (例：AddressList)
は、個別のラベルが設定されている場合 (例：「From」、「To」、および「Cc」) と違い、その意味が失われて
しまいます。
Splunk Enterprise はサーチ時に複数値フィールドを解析します。これにより、値をサーチパイプライン内で処理
することができます。複数値フィールドを利⽤できるサーチコマンドには、makemv、mvcombine、
mvexpand、および nomv があります。これらのコマンドおよび他のコマンドの詳細は、『ユーザーマニュア
ル』と『サーチリファレンスマニュアル』の、複数値フィールドに関するトピックを参照してください。
fields.conf に複数値フィールドを設定するには、TOKENIZER キーを使⽤します。TOKENIZERは、正規表現を使って
Splunk Enterprise に、イベント内の反復フィールドの複数フィールド値の認識、抽出⽅法を指⽰しま
す。$SPLUNK_HOME/etc/system/local/、または $SPLUNK_HOME/etc/apps/ 内の独⾃のカスタム App ディレクトリ内にある
fields.conf を編集してください。
設定ファイルの⼀般情報については、『管理マニュアル』の「設定ファイルについて」を参照してください。
正規表現の構⽂と使⽤⽅法の概要については、Regular-Expressions.info を参照してください。正規表現をテス
トするには、サーチ内で rex サーチコマンドを使ってそれらを指定します。正規表現式を作成、テストするために
役⽴つサードパーティ製ツールのリストも⽤意されています。
fields.conf を使った複数値フィールドの設定
複数値フィールドを定義するには、fields.conf にスタンザを追加します。次に、TOKENIZER キーに対応する正規表
現を指定した⾏を追加します。この正規表現は、フィールドの複数値の抽出⽅法を表しています。
注意： 複数値フィールド⽤に他の属性を設定する場合は、同じスタンザ内の TOKENIZER ⾏の下に設定してくださ
い。詳細は、『管理マニュアル』の fields.conf に関するトピックを参照してください。
[<field name 1>]
TOKENIZER = <regular expression>
[<field name 2>]
TOKENIZER = <regular expression>
には、⽬的のフィールドがどのように複数の値を取るのかを指定する必要があります。
のデフォルトは空です。TOKENIZER が空の場合、フィールドは 1 つの値のみを取ることができま
<regular expression>
TOKENIZER
す。
そうでない場合は、各⼀致項⽬から最初のグループが取得され、⼀連のフィールド値が形成されます。
TOKENIZER キーは、where、timeline、および stats コマンドが使⽤します。また、⾮同期サーチ API のサマ
リーと XML 出⼒も提供しています。
注意： インデックスフィールド (インデックス時に抽出されたフィールド) のトークン化はサポートされていませ
ん。フィールドに対して INDEXED=true を設定した場合、そのフィールドに TOKENIZER を使⽤することはできませ
ん。インデックスフィールドを複数の値に分割するには、props.conf および transforms.conf に定義されているサー
チ時フィールド抽出を使⽤します。
例
すべてのアドレスが
AddressList
下にグループ化されている、適切なフォーマットが⾏われていないメール・ログ
44
を考えてみましょう。
From:
[email protected]
To:
[email protected], [email protected], [email protected]
CC:
[email protected], [email protected], [email protected]
Subject:
Multivalue fields are out there!
X-Mailer:
Febooti Automation Workshop (Unregistered)
Content-Type:
text/plain; charset=UTF-8
Date:
Wed, 3 Nov 2014 17:13:54 +0200
X-Priority:
3 (normal)
この $SPLUNK_HOME/etc/system/README/fields.conf.example からの例は、メールのフィールド
に分割します。
To、From、CC
を複数の値
[To]
TOKENIZER = (\w[\w\.\-]*@[\w\.\-]*\w)
[From]
TOKENIZER = (\w[\w\.\-]*@[\w\.\-]*\w)
[Cc]
TOKENIZER = (\w[\w\.\-]*@[\w\.\-]*\w)
計算済みフィールドの定義
Splunk Enterprise でのサーチ作成経験が⻑い⽅ならば、eval コマンドの使⽤⽅法をかなり理解していることで
しょう。このコマンドを利⽤すれば、⾃動的に抽出されたフィールド を含む式を作成し、式の評価結果となる値
を取る新たなフィールドを⽣成することができます。(eval コマンドの詳細とさまざまな使⽤例については、
『サーチリファレンスマニュアル』のコマンドに関する記事を参照してください。)
コマンドは、多彩な機能を持ちとても有⽤です。⼀部の eval 式は⽐較的単純ですが、しばしば⾮常に複雑に
なる場合もあります。かなり⻑くて複雑な eval 式を定期的に使⽤する必要があるような場合、毎回のサーチにそ
れをいちいち⼊⼒するのは⾮常に⼤変な作業です。
eval
このような場合に役に⽴つのが、計算済みフィールド です。計算済みフィールドにより、eval 式を持つフィール
ドを props.conf に定義することができます。次に、サーチを作成する場合には、eval 式を全体を省略し、抽出さ
れた他のフィールドを参照するように、このフィールドを参照します。サーチを実⾏すると、サーチ時にフィール
ドが抽出され、eval 式内のフィールドを含むイベントに追加されます。
たとえば、『サーチリファレンス』からの eval コマンドのサーチ例を考えてみましょう。この例は、地震データ
を調査して、新しい Description フィールドを作成して、深度によって地震を分類しています。
source=eqs7day-M1.csv | eval Description=case(Depth<=70, "Shallow", Depth>70 AND Depth<=300, "Mid", Depth>300 AND
Depth<=700, "Deep") | table Datetime, Region, Depth, Description
計算済みフィールドを使⽤して、props.conf 内に
うなサーチを実⾏することができます。
Description
フィールド⽤の eval 式を定義することで、以下のよ
source=eqs7day-M1.csv | table Datetime, Region, Depth, Description
これで、Description フィールドを、他の抽出されたフィールドと同様にサーチできるようになりました。Splunk
Enterprise は props.conf 内の計算済みフィールドキーを探して、Depth フィールドを持つ各イベントを評価しま
す。以下のようなサーチを実⾏することもできます。
source=eqs7day-M1.csv Description=Deep
注意： 次のセクションでは、props.conf 内に
説明しています。
Description
計算済みフィールドがどのように設定されているのかを
props.conf の編集による計算済みフィールドの作成
計算済みフィールドを作成するには、新しいまたは既存の props.conf スタンザに、計算済みフィールドキーを追加
します。props.conf は $SPLUNK_HOME/etc/system/local/、または $SPLUNK_HOME/etc/apps/ 内の独⾃のカスタム App ディ
レクトリにあります。(カスタムデータを他のサーチサーバーに⼿軽に転送したいような場合は、後者のディレク
トリを使⽤することをお勧めします。)
注意： $SPLUNK_HOME/etc/system/default/ 内のファイルは編集しないでください 。
設定ファイルの⼀般情報については、『管理マニュアル』の「設定ファイルについて」を参照してください。
props.conf
内に指定する、計算済みフィールドキーのフォーマットを以下に⽰します。
[<stanza>]
45
EVAL-<field_name> = <eval statement>
<stanza>
には、以下の値を使⽤できます。
<source type>、イベントのソースタイプ。
host::<host>、<host>
はイベントのホストを表します。
はイベントのソースを表します。
source::<source>、<source>
計算済みフィールドキーは、「EVAL-」 (ハイフンを含む) で開始する必要があります。「EVAL」の⼤⽂字
と⼩⽂字は区別されません (たとえば、「eVaL」も可能です)。
<field_name> ただし、is は⼤⽂字と⼩⽂字が区別されます。このルールは、Splunk Enterprise 内の他の
フィールド名でも⼀貫しています。
<eval_statement> は、eval コマンドと同様に⾃由かつ柔軟に指定することができます。複数値、論理値、また
は NULL も含めて任意の値タイプを評価することができます。
そこで、Description 計算済みフィールド (このトピックの先頭にある例を参照) を設定するには、props.conf 内に
以下のスタンザを作成します。
<Stanza>
Eval-Description = case(Depth<=70, "Shallow", Depth>70 AND Depth<=300, "Mid", Depth>300 AND Depth<=700, "Deep")
計算済みフィールドキーを適切に定義したら、eval ステートメントに登場する抽出されたフィールドを持つイベ
ントに対して、サーチ時にフィールドが計算されます。計算済みフィールドの評価は、サーチ時フィールド抽
出 およびフィールドのエイリアス設定 の後で、ルックアップフィールド の⽣成前に⾏われます。
注意： 計算済みフィールドをサーチする場合、パフォーマンスの点でこの操作はフィルタリング と同等の効果を
発揮します。フィールド値がインデックスには⾒つからないため、実際のサーチにインデックスが使⽤されること
はありません。
既存のフィールドの上書きの防⽌
計算済みフィールドが通常の⼿段で抽出されたフィールドと同じ名前を持つ場合、eval ステートメントの評価が
NULL の場合でも、計算済みフィールドで抽出されたフィールドが上書きされてしまいます。eval 式と⼀緒に
eval ⽤の coalesce 関数を使⽤することで、この上書き (優先) 動作を解除することができます。coalesceは任意の
数の引数を取得して、ヌルではない最初の値を返します。
eval ステートメントが値を返した場合に、計算済みフィールドで既存のフィールドを上書きしたくない場合は、
以下のように設定します。
EVAL-field = coalesce(field, <eval expression>)
eval ステートメントが値を返した場合に、計算済みフィールドで既存のフィールドを上書きしたくない場合は、
以下のように設定します。
EVAL-field = coalesce(<eval expression>, field)
および他の
てください。
coalesce
eval
関数の詳細は、『サーチリファレンスマニュアル』の「eval と where の関数」を参照し
すべての計算済みフィールドが相互に独⽴して判断されることを⽰す例
Splunk Enterprise が計算済みフィールドを評価する場合、それぞれの式が他の式と無関係なものとして評価され
ます。つまり、ある計算済みフィールドの評価を別の計算済みフィールドの式内に使⽤することはできません。
以下の例では、各任意のイベントに対して、x の値が計算済みフィールド y の値と同じになります。これらの 2 つ
の計算は相互に独⽴して実⾏され、x*2 の計算時には両⽅の式がオリジナルの x の値を使⽤します。
[<foo>]
EVAL-x = x * 2
EVAL-y = x * 2
特定のイベントが
ます。
x=4
の場合は、これらの計算済みフィールドは
x
の値を
8
に置換して、イベントに
y=8
を追加し
抽出されたフィールド response_time を含む、他の多少現実的な例を⾒てみましょう。最初に抽出された時の
response_time の値はミリ秒で表されています。ここでは、個別の⽅法で response_time を利⽤する、2 つの計算済
みフィールドを定義しました。
[<access_common>]
EVAL-response_time =
response_time/1000
EVAL-bitrate = bytes*1000/response_time
この例では、access_common ソースタイプを持つすべてのデータに対して、2 つの処理が⾏われています。
46
最初の EVAL は、すべての sourcetype=access_common イベント内の response_time の値を、ミリ秒ではなく秒
で表⽰するように変更しています。新しい「in seconds」の値は、古い「in milliseconds」の値に上書きさ
れます。
2 番⽬の EVAl は、すべての sourcetype=access_common イベントに対して、bitrate と呼ばれる新たなフィール
ドを算出します。これは、秒当たりの bytes で表されます。(bytes は別の抽出されたフィールドです。)
どちらの計算でも、response_time は当初ミリ秒で表されており、両⽅の EVAL が相互に独⽴して算出されます。
ルックアップフィールドと計算済みフィールド
計算済みフィールドをルックアップフィールドのベースにすることはできません。試しても正常に利⽤することは
できません。前述のように、計算済みフィールドの評価は、サーチ時フィールド抽出 およびフィールドのエイ
リアス設定 の後で、ルックアップフィールド の⽣成前に⾏われます。
デフォルトフィールドの使⽤
フィールド は、イベントデータ内のサーチ可能な名前と値のペアです。サーチ を実⾏する場合、サーチ単語をイ
ベントデータ のセグメントと照合することになります。フィールドを使⽤すれば、より正確にサーチを実⾏でき
ます。フィールドはインデックス時またはサーチ時にイベントデータから抽出 されます。Splunk Enterprise がイ
ンデックス時に⾃動抽出するフィールドは、デフォルトフィールド と呼ばれます。
デフォルトのフィールドは、さまざまな⽬的に利⽤されます。たとえば、デフォルトフィールド index はイベント
が存在しているインデックスを⽰します。デフォルトフィールド linecount はイベントに含まれる⾏数
を、timestamp はイベントの発⽣時刻を⽰します。Splunk Enterprise はデータのインデックス作成時に、⼀部の
フィールドの値、特に sourcetype の値を利⽤して、正しくイベントを作成します。データのインデックスが作成さ
れたら、サーチにデフォルトフィールドを使⽤できます。
サーチコマンドでのデフォルトフィールドの使⽤の詳細は、『サーチマニュアル』の「サーチ⾔語について」を参
照してください。デフォルトフィールドの設定⽅法の詳細は、『Getting Data In』の「About default fields」を
参照してください。
フィー
ルドの
タイプ
内部
フィー
ルド
フィールドの
リスト
_raw, _time,
_indextime, _cd
説明
これらのフィールドには、Splunk Enterprise 内のイベントに関する全般的な情報が
含まれています。
host, index,
デフォ
ルト
フィー
ルド
linecount,
punct, source,
sourcetype,
splunk_server,
これらのフィールドには、イベントのソース、存在しているインデックス、そのタイ
プ、⾏数、発⽣時刻などの情報が含まれています。これらのフィールドはデフォルト
でインデックスが作成され、[フィールド] メニューに追加されます。
timestamp
date_hour,
デフォ
ルトの
⽇時
フィー
ルド
date_mday,
date_minute,
date_month,
date_second,
date_wday,
date_year,
date_zone
これらのフィールドは、イベントのタイムスタンプに対するサーチをさらに細かく制
御するために⽤いられます。
注意： 各システムで⽣成されたタイムスタンプ情報を持つイベントのみが、date_*
フィールドを持っています。イベントに date_* フィールドがある場合、それはイベ
ント⾃体からの直接の時間/⽇付値を表しています。インデックス時/⼊⼒時にタイム
ゾーン変換や時間/⽇付値の変更をを⾏った場合 (例：タイムスタンプがインデックス
時または⼊⼒時になるように設定した)、これらのフィールドはそれを表さないよう
になります。
フィールドは複数の値を持つことができます。そのようなフィールドと値の処理⽅法の詳細は、この章の「複数値
フィールドの操作と評価」を参照してください。
Splunk Web または抽出サーチコマンドを使⽤して、追加のフィールド (デフォルト以外のフィールド) を抽出で
きます。詳細は、このマニュアルの「フィールドについて」を参照してください。
フィールド名を変更したり、類似のフィールドをグループ化することができます。このような操作は、フィールド
およびフィールド値のタグやエイリアスを使って簡単に⾏えます。詳細は、このマニュアルの「フィールド値のタ
グ/エイリアス設定」を参照してください。
ここでは、データのインデックスを作成する際に Splunk Enterprise が⾃動的に追加する内部フィールドやその
他のフィールドについて取り上げていきます。
内部フィールド
アンダースコアで始まるフィールドは内部フィールドです。
注意： ⾃分が何を⾏っているのかを確実に理解している場合を除き、内部フィールドを上書きすることはお勧め
できません。
_raw
_raw
フィールドには、イベントのオリジナルの raw データが含まれています。サーチおよびデータ抽出の実⾏時
47
に、Splunk の
search
コマンドは、_raw 内のデータを使⽤します。
常に _raw の値を直接サーチすることはできません。regex や
きます。
sort
などのコマンドでフィルタリングすることがで
例： IP アドレスの値が「10」で始まる sendmail イベントを返します。
eventtype=sendmail | regex _raw=*10.\d\d\d\.\d\d\d\.\d\d\d\*
_time
フィールドには、UNIX 時で表されるイベントのタイムスタンプが含まれています。Splunk Enterprise は
このフィールドを使って、Splunk Web のイベントタイムラインを作成します。
_time
注意： _time フィールドは、内部的に UTC 形式で保管されます。Splunk Enterprise がサーチ結果を表⽰する際
(サーチ時 の最後の⽅のステップ) に、⼈が理解できる UNIX 時間形式に変換されます。
例： タイプが「mail」のソースに対して、ユーザー「[email protected]」宛のメールアドレスをサー
チして、サーチ結果をタイムスタンプでソートします。
sourcetype=mail [email protected] | sort _time
_indextime
フィールドには、UNIX 時間で表された、イベントのインデックスが作成された時刻が保管されていま
す。このフィールドを使って、特定の期間内にインデックスが作成されたイベントに絞り込む (フィルタリングす
る) ことができます。
_indextime
_cd
基本的に _cd フィールドは、インデックス内のイベントの「アドレス」を表しています。短い数字と⻑い数字の 2
種類の数字で構成されています。短い数字は、イベントが存在している特定のインデックスバケツを⽰していま
す。⻑い数字は、インデックスバケツのオフセットを表しています。これにより、バケツ内の正確なイベントの位
置が提供されます。_cd は内部参照のためにのみ⽤いられるため、サーチにこれを使⽤することはお勧めいたしま
せん。
その他のデフォルトフィールド
ホスト
フィールドには、イベントを⽣成したネットワークデバイスのホスト名または IP アドレスが含まれていま
す。。host フィールドを使ってサーチを絞り込むことができます。host に照合する値を指定してください。ワイ
ルドカードを使って、単⼀の式内に複数のホストを指定することができます (例：host=corp*)。
host
を使ってデータ⽣成コマンドの結果をフィルタリングしたり、データ処理コマンドの引数として使⽤したりす
ることができます。
host
例 1： ユーザー「strawsky」によるすべての「corp」サーバーへのアクセスイベントをサーチします。その中で
最新の 20 件のイベントのレポートを作成します。
host=corp* eventtype=access user=strawsky | head 20
例 2： 「192」から始まるホストからの、⽤語「404」を含むイベントをサーチします。
404 | regex host=*192.\d\d\d\.\d\d\d\.\d\d\d\*
インデックス
フィールドには、イベントのインデックスが作成されたインデックス名が含まれています。次のように、
サーチで使⽤するインデックスを指定できます：index="name_of_index"。デフォルトでは、すべてのイベントが
main インデックスにインデックスされます (index="main")。
_index
例： myweb インデックスの拡張⼦「.php」を持つイベントをサーチします。
index="myweb" *.php
linecount
フィールドには、イベントに含まれている⾏数が保管されています。これは、インデックスが作成され
る前にイベントに含まれていた⾏数です。linecount は、特定の⾏数を持つイベントのサーチに、またはデータ処
理コマンドの引数として⽤いられます。 照合する範囲を指定するには、不等号を使⽤します (例：linecount>10
linecount<20)。
linecount
例： corp1 に対して「40」および 40 ⾏を持つイベントをサーチして、「400」を含むイベントを除外します。
40 linecount=40 host=corp1 NOT 400
48
punct
フィールドには、イベントから抽出された句読点パターンが保管されています。句読点パターンは、イベン
トのタイプによって⼀意です。サーチで punct を使ってイベントをフィルタリングしたり、データ処理コマンドの
引数として使⽤したりできます。
punct
フィールドにワイルドカードを使って、共通の特性を持つ複数の句読点パターンをサーチすることができま
す。punct フィールドの句読点パターンを定義する際には、引⽤符を使⽤する必要があります。
punct
例 1： : で開始、終了するすべての句読点パターンをサーチします。
punct=":*:"
例 2： php_error.log に対して、句読点パターン「[--_::]__:___:____/-..-///.___」を持つ php エラーイベントを
サーチします。
source="/var/www/log/php_error.log" punct="[--_::]__:___:____''/-..-''///.___"
ソース
フィールドには、イベントのソースとなるファイル、ストリーム、または他の⼊⼒名が保管されます。サー
チ時に source を使ってイベントをフィルタリングしたり、データ処理コマンドの引数として使⽤したりできま
す。ワイルドカードを使って、単⼀の式内に複数のソースを指定することができます (例：source=*php.log*)。
source
を使ってデータ⽣成コマンドの結果をフィルタリングしたり、データ処理コマンドの引数として使⽤したり
することができます。
source
例： ソース「/var/www/log/php_error.log」からのイベントをサーチします。
source="/var/www/log/php_error.log"
ソースタイプ
フィールドは、access_combined や cisco_syslog などのイベントのソースからの、データ⼊⼒フォーマッ
トを⽰します。サーチ時に sourcetype を使ってイベントをフィルタリングしたり、データ処理コマンドの引数とし
て使⽤したりできます。ワイルドカードを使って、単⼀の式内に複数のソースを指定することができます
(例：sourcetype=access*)。
sourcetype
例： ソースタイプが「access log」のイベントをサーチします。
sourcetype=access_log
splunk_server
splunk_server
フィールドには、イベントを含む Splunk サーバー名が含まれています。分散 Splunk 環境で役⽴ち
ます。
例： サーチを名前が「remote」 サーバー上の main インデックスに制限します。
splunk_server=remote index=main 404
タイムスタンプ
フィールドには、イベントのタイムスタンプ値が含まれています。Splunk Enterprise によるタイムス
タンプの抽出⽅法は設定することができます。timestamp を search コマンドの引数として使⽤して、サーチをフィ
ルタリングできます。
timestamp
たとえば、サーチに timestamp=none を指定して、認識できるタイムスタンプ値がないイベントのみを含めるように
サーチ結果をフィルタリングできます。
例： データ内の認識できるタイムスタンプがないイベント数を返します。
timestamp=none | stats count(_raw) as count
デフォルトの⽇時フィールド
サーチで datetime を使ってイベントをフィルタリングしたり、データ処理コマンドの引数として使⽤したりでき
ます。
Splunk Enterprise サーバーとは別のタイムゾーンで作業を⾏っている場合、時間ベースのサーチでは、
イベントのインデックスが作成されたサーバーからのイベントのタイムスタンプが⽤いられます。 ⽇時値
は、そのタイムゾーンに関係なく、インデックス作成時にイベントから解析されるリテラル値です。そのため、
「05:22:21」のような⽂字列が解析されると、「date_hour::5 date_minute::22 date_second::21」のようなイ
ンデックスフィールドが作成されます。
date_hour
49
date_hourフィールドには、イベントが発⽣した時間の値が含まれます
(範囲：0〜23)。 この値は、イベントのタ
イムスタンプから抽出されます (_time 内の値)。
例： 現在の⽇の午後 10 時から午前 0 時までに発⽣した、⽤語「apache」を含むイベントをサーチします。
apache (date_hour >= 22 AND date_hour <= 24)
date_mday
date_mday フィールドには、イベントが発⽣したその⽉の⽇付値が含まれます
(範囲：1〜31)。 この値は、イベ
ントのタイムスタンプから抽出されます (_time 内の値)。
例： 今⽉の 1 ⽇〜15 ⽇の間に発⽣した、⽤語「apache」を含むイベントをサーチします。
apache (date_mday >= 1 AND date_mday <= 15)
date_minute
フィールドには、イベントが発⽣した分の値が含まれます (範囲：0〜59)。 この値は、イベントのタ
イムスタンプから抽出されます (_time 内の値)。
date_minute
例： 現在の時間の 15 分〜20 分の間に発⽣した、⽤語「apache」を含むイベントをサーチします。
apache (date_minute >= 15 AND date_minute <= 20)
date_month
フィールドには、イベントが発⽣した⽉の値が含まれます。この値は、イベントのタイムスタンプから
抽出されます (_time 内の値)。
date_month
例： 1 ⽉に発⽣した⽤語「apache」を含むイベントをサーチします。
apache date_month=1
date_second
フィールドには、イベントのタイムスタンプの秒の値が含まれます (範囲：0〜59)。この値は、イベン
トのタイムスタンプから抽出されます (_time 内の値)。
date_second
例： 現在の分の 1〜15 秒の間に発⽣した、⽤語「apache」を含むイベントをサーチします。
apache (date_second >= 1 AND date_second <= 15)
date_wday
date_wdayフィールドには、イベントが発⽣した曜⽇が含まれています
(Sunday、Monday など)。Splunk
Enterprise はイベントのタイムスタンプ (_time 内の値) から⽇付を抽出して、その⽇付の曜⽇を判断します。こ
の曜⽇値は、date_wday フィールドに保管されます。
例： ⽇曜⽇に発⽣した⽤語「apache」を含むイベントをサーチします。
apache date_wday="sunday"
date_year
フィールドには、イベントが発⽣した年の値が含まれます。この値は、イベントのタイムスタンプから
抽出されます (_time 内の値)。
date_year
例： 2008 年に発⽣した⽤語「apache」を含むイベントをサーチします。
apache date_year=2008
date_zone
フィールドには、UNIX 時間 (時間) で表される、イベントのローカルタイムゾーンの時間値が含まれて
います。この値は、イベントのタイムスタンプから抽出されます (_time 内の値)。イベントのタイムゾーンのオフ
セットを使⽤するには、date_zone を使ってオフセットを分で指定します (範囲：-720〜720)。
date_zone
例： 現在のタイムゾーン (ローカル) で発⽣した⽤語「apache」を含むイベントをサーチします。
apache date_zone=local
Splunk Enterprise の正規表現について
ここでは、Splunk Enterprise で有効な正規表現を作成するために役⽴つ、基本的な情報を取り上げています。正
50
規表現の構⽂と使⽤⽅法については、www.regular-expressions.info などのオンライン・リソースまたは適切な
マニュアルを参照してください。
正規表現は、テキスト内の⽂字のパターンを照合します。Splunk Enterprise は、デフォルト・フィールドの抽
出、バイナリ・ファイル・タイプの認識、およびソースタイプの⾃動割り当てに正規表現を使⽤しています。カス
タムのフィールド抽出、イベントのフィルタリング、データのルーティング、および相関サーチにも正規表現を使
⽤します。正規表現を使⽤するサーチ・コマンドには、rex および regex、および match や replace などの eval 関
数が含まれています。
Splunk Enterprise の正規表現は、Perl 互換の正規表現 (PCRE) です。特に PCRE C ライブラリを使⽤していま
す。
正規表現の⽤語と構⽂
⽤語
説明
リテラル
正規表現を使って照合するテキスト⽂字列。
正規表現
リテラルに対して照合するために⽤いられるパターンを定義するメタ⽂字。
グループ
正規表現では、正規表現⽂字を囲むために⽤いられる括弧のタイプで表される、グ
ループ化を利⽤できます。グループでは、⽂字クラス、反復⼀致、名前付き捕捉グ
ループ、モジュール正規表現などを定義できます。グループに演算⼦を適⽤した
り、選択条件を使⽤することができます。
⽂字クラス
⾓括弧に囲まれた⽂字。⽂字列の照合に⽤いられます。⽂字クラスを定義するに
は、たとえば任意の⼤⽂字と⼀致させる場合は [A-Z] などのように、範囲を指定し
ます。否定⼀致を定義するには、⽂字クラスの先頭にキャレット (^) を指定しま
す。たとえば、[^A-Z] のように指定すると、任意の⼩⽂字と⼀致します。
⽂字タイプ
ワイルドカードと同様に、⽂字タイプは特定のリテラル⼀致を表しています。たと
えば、ピリオド . は、任意の⽂字に、\w はアンダースコアを含む任意の単語または
英数字に⼀致します。
アンカー
復帰
オルタネーション
正規表現内の代替⼀致パターンを提供することを表しています。代替パターンを区
別するためには、垂直バーまたはパイプ⽂字 ( | ) を使⽤します。このパターンに
は、完全な正規表現を指定することができます。たとえば、grey|gray は「grey」ま
たは「gray」と⼀致します。
量指定⼦または反復
( *, +, ?) は、グループをリテラル・パターンと照合する⽅法を定義するために使
⽤します。たとえば、* は 0 件以上、+ は 1 件以上、? は 0 または 1 件に⼀致しま
す。
後⽅参照
後ほど再利⽤できるリテラル・グループ。Splunk Enterprise の場合は、ドル記号
($) を持つ値の数値 (0 以外) への逆参照を表しています。
ルックアラウンド
⽂字列内の位置を判断するための、グループの定義⽅法の 1 つです。この定義は、
グループ内の正規表現と照合されますが、結果を保持するためその後の照合を⾏い
ません。たとえば、y が後に続く x を、y との照合を⾏わずに照合するには、ルッ
クアラウンドを使⽤します。
\r
や改⾏
\n
などの、テキストフォーマット位置に⼀致する⽂字タイプです。
⽂字タイプ
⽂字タイプは、リテラル⼀致の簡略的表現です。
⽤語
説明
例
説明
\w
単語⽂字 (⽂字、数字、または
アンダースコア⽂字) に⼀致し
ます。
\w\w\w
任意の 3 単語の⽂字に⼀致しま
す。
\W
⾮単語⽂字に⼀致します。
\W\W\W
任意の 3 つの⾮単語⽂字に⼀致し
ます。
\d
数字に⼀致します。
\D
⾮数字⽂字に⼀致します。
\D\D\D
任意の 3 桁の⾮数字⽂字に⼀致し
ます。
\s
空⽩⽂字に⼀致します。
\d\s\d
⼀連の数字、空⽩⽂字、次に別の数
字のシーケンスに⼀致します。
\S
⾮空⽩⽂字に⼀致します。
\d\S\d
⼀連の数字、⾮空⽩⽂字、次に別の
数字のシーケンスに⼀致します。
.
任意の⽂字に⼀致使⽤は慎重
に⾏ってください。
\d\d.\d\d.\d\d
12/31/14 や 01.01.15 のような⽇
付⽂字に⼀致しますが、
99A99B99 とも⼀致します。
\d\d\d-\d\d\d\d\d\d
グループ、量指定⼦、交代⼦
51
社会保障番号、または類似の 3-2-4
⽂字の⽂字列に⼀致します。
正規表現では、正規表現⽂字を囲むために⽤いられる括弧のタイプで表される、グループ化を利⽤できます。グ
ループに量指定⼦ (*, +, ? ) を適⽤したり、交代⼦を使⽤したりすることができます。
⽤
語
説明
例
説明
*
0 回以上⼀致します。
\w*
0 以上の単語⽂字と⼀致します。
+
1 回以上⼀致します。
\d+
1 桁以上の数字に⼀致します。
\d\d\d-?\d\d-
ダッシュを含む、または含まない
社会保障番号と⼀致します。
?
(
)
[
]
{
}
<
>
[[
]]
0 回または 1 回⼀致します。
?\d\d\d\d
括弧は、⼀致または捕捉グループ、アトミックグルー
プ、およびルックアラウンドを定義します。
(H..).(o..)
⾓括弧は⽂字クラスを定義します。
[a-z0-9#]
中括弧は反復を定義します。
\d{3,5}
⼭括弧は、名前付き捕捉グループを定義します。名前付
きフィールド抽出を設定するには、構⽂ (?P<var> ...) を
使⽤します。
⼆重⾓括弧は、Splunk Enterprise 固有のモジュール正
規表現を定義します。
⽂字列 Hello World が与えられた
場合、これは Hel および o W に⼀
致します。
a〜z、0〜9、または #
の任意の⽂
字に⼀致します。
3〜5 桁の数字に⼀致します。
(?
P<ssn>\d\d\d\d\d-
社会保障番号を抽出して、それを
ssn フィールドに割り当てます。
\d\d\d\d)
[[octet]]
0〜255 の検証された整数。
グループ、量指定⼦、演算⼦の簡単な例
この例では、「to」または「too」との⼀致を照合する 2 種類の⽅法を表しています。
最初の正規表現は、?を使って最初に登場した後もう 1 ⽂字まで登場する「o」を探します。
2 番⽬の正規表現は交代⼦を使って、パターンを指定しています。
to(o)?
(to|too)
正規表現によるグループの捕捉
名前付き捕捉グループは、正規表現がイベントと⼀致した時にフィールド値を抽出する、正規表現のグループ化で
す。捕捉グループには、フィールド名が含まれます。これは次のように、⼭括弧で表されます：
matching text (?<field_name>capture pattern) more matching text。
たとえば、以下のイベント・テキストがある場合を考えてみましょう。
131.253.24.135 fail admin_user
このイベントから同じ⼀連のフィールドを抽出するために、捕捉グループ内で異なる構⽂を使⽤している 2 種類
の正規表現を以下に⽰します。
式 A： (?<ip>\d+\.\d+\.\d+\.\d+\.) (?<result>\w+)
式 Ｂ： (?<ip>\S+) (?<result>\S+) (?<user>\S+)
(?<user>.*)
式 Ａ で、最初の捕捉グループ (ip) で使われているパターン照合⽂字はそれ⾃体を表しています。\dは数字を表し
ており、+ は「1 つ以上」であることを表しています。そこで、\d+ は「1 つ以上の数字」を意味していることに
なります。\.は、ピリオドを表しています。
の捕捉グループは、1桁以上の数字、次にピリオド、次に 1 桁以上の数字、次にピリオド、次に 1 桁以上の数
字、次にピリオド、次に 1 桁以上の数字、次にピリオドが来る⽂字列に⼀致します。これは、IP アドレスの構造
を記述しています。
ip
式 A の result フィールドに対する 2 番⽬の捕捉グループのパターンは \w+ で、これは「1 つ以上の英数字」を表
しています。式 A の user フィールドに対する 3 番⽬の捕捉グループのパターンは .* で、これは「残りの任意の
ものに⼀致」を表しています。
式 B は、否定⼀致と呼ばれる⼀般的な⼿法を利⽤しています。否定⼀致で正規表現は、⼀致するテキストを定義
しません。代わりに対象にしないテキストを定義します。この式 B で、サンプル・イベントから抽出する値は、
「スペース」⽂字 (\S) ではありません。+ を使って、「スペースではない」、「1 つ以上の」⽂字を指定していま
す。
式 B の意味：
52
1. ip フィールド値に対する、スペースではない最初の⽂字列を抽出する。
2. 続くスペースは無視する。
3. 次に
result
フィールド値に対する、スペースではない 2 番⽬の⽂字列を抽出する。
4. 2 番⽬のスペースは無視する。
5. user フィールド値に対する、スペースではない 3 番⽬の⽂字列を抽出する。
モジュール正規表現
モジュール正規表現は、⻑い正規表現定義内で使⽤するために定義された、⼩型の正規表現です。Splunk
Enterprise は、transforms.conf 内にモジュール正規表現を定義しています。
たとえば、ある整数を定義した後に、その正規表現定義を使って浮動⼩数を定義することができます。
[int]
# matches an integer or a hex number
REGEX = 0x[a-fA-F0-9]+|\d+
[float]
# matches a float (or an int)
REGEX = \d*\.\d+|[[int]]
[float]
の正規表現で、整数または 16 進数照合⽤のモジュール正規表現は、⼆重⾓括弧
[[int]]
で開始されます。
フィールドの抽出にモジュール正規表現を使⽤することもできます。
[octet]
# this would match only numbers from 0-255 (one octet in an ip)
REGEX = (?:2(?:5[0-5]|[0-4][0-9])|[0-1][0-9][0-9]|[0-9][0-9]?)
[ipv4]
# matches a valid IPv4 optionally followed by :port_num the
# octets in the ip would also be validated 0-255 range
# Extracts: ip, port
REGEX = (?<ip>[[octet]](?:\.[[octet]]){3})(?::[[int:port]])?
データ分類：イベントタイプとトランザクション
イベントタイプについて
イベントタイプは、データを把握するために役⽴つ分類システムです。イベントタイプにより⼤量のデータを調査
して、類似パターンを探し、アラートやレポートを作成することができます。
イベントとイベントタイプ
イベントはログファイル内の単⼀のアクティビティレコードです。⼀般的にイベントにはタイムスタンプが含まれ
ており、監視/記録されているシステムに何が発⽣したかに関する情報を提供します。
イベントタイプはイベントを分類することで、サーチを容易にするための、ユーザーが定義するフィールドです。
イベントタイプを使って、共通の特徴を持つイベントを分類することができます。サーチ結果が返されると、それ
が既知のイベントタイプに対してチェックされます。サーチ時にイベントが eventtypes.conf に定義されている
イベントタイプに⼀致すると、そのイベントタイプがイベントに適⽤されます。データのインデックス作成後に、
イベントタイプをタグ付けまたは保存してください。
イベントタイプの分類
独⾃のイベントタイプを作成するには、さまざまな⽅法が存在しています。Splunk Web を使⽤したり、設定
ファイルを編集したり、さらには任意のサーチをイベントタイプとして保存したりすることができます。サーチを
イベントタイプとして保存する場合、punct フィールドを使ってサーチを調整することができます。punct フィール
ドは、イベントの構造に基づいてサーチを絞り込むために役⽴ちます。
punct フィールドを使った類似イベントのサーチ
イベントのフォーマットはしばしばイベントタイプ特有のため、Splunk Enterprise はイベントの句読点⽂字を
punct. フィールドとしてインデックスを作成します。punct フィールドは、イベントの最初の⾏の最初の 30 ⽂字
の句読点を保管しています。このフィールドは、類似イベントを素早く探すために役⽴ちます。
punct
を使⽤する場合、以下の事項に注意してください。
引⽤符と円記号 (バックスラッシュ) はエスケープ処理されます。
スペースは、アンダースコア (_) で置換されます。
53
タブは「t」で置換されます。
英数字に続くダッシュは無視されます。
注⽬される句読点⽂字を以下に⽰します。
",;-#$%&+./:=?@\\'|*\n\r\"(){}<>[]^!"
punct フィールドは、_audit インデックス内のイベントには利⽤できません。これらのイベントは⽣成時に
PKI で署名されています。
punct フィールドの概要と、他のイベント分類⽅法については、このマニュアルの「類似イベントの分類とグルー
プ化」を参照してください。
Pu nc t の例
このイベントは：
####<Jun 3, 2005 5:38:22 PM MDT> <Notice> <WebLogicServer> <bea03> <asiAdminServer> <WrapperStartStopAppMain> <>WLS
Kernel<> <> <BEA-000360> <Server started in RUNNING mode>
以下の punct フィールドを⽣成します。
####<_,__::__>_<>_<>_<>_<>_<>_
このイベントは：
172.26.34.223 - - [01/Jul/2005:12:05:27 -0700] "GET /trade/app?action=logout HTTP/1.1" 200 2953
以下の punct フィールドを⽣成します。
..._-_-_[:::_-]_\"_?=_/.\"__
イベントタイプの検出
任意のサーチをパイプ⽂字を使って typelearner コマンドに渡し、Splunk Web から直接イベントタイプを作成
できます。eventdiscoverer.conf ファイルはほぼ廃⽌状態ですが、引き続き Splunk Web で新たなイベントタイ
プを学習する際に無視する単語を指定するこは可能です。
新たなイベントタイプの作成
新しいイベントタイプを作成するもっとも⼿軽な⽅法は、Splunk Web を使⽤することです。良質なイベントタ
イプを⽣成するサーチを実⾏したら、[名前を付けて保存] をクリックして、[イベントタイプ] を選択します。[イ
ベントタイプとして保存] ダイアログボックスが表⽰されます。ここでは、イベントタイプ名を指定し、必要に
応じてタグを設定することができます。サーチをイベントタイプとして保存する⽅法の詳細は、このマニュアルの
「類似イベントの分類とグループ化」を参照してください。
を変更して、新たなイベントタイプを作成することもできます。この⽅法によるイベントタイプの
⼿動設定については、このマニュアルの「eventtypes.conf でのイベントタイプの設定」を参照してください。
eventtypes.conf
イベントタイプタグ
データをカテゴリに分類するには、イベントタイプにタグを設定します。イベントに複数のタグを設定することも
できます。イベントタイプのタグ設定の詳細は、このマニュアルの「イベントタイプのタグ設定」を参照してくだ
さい。
イベントタイプの設定ファイル
イベントタイプは eventtypes.conf に保存されます。
イベントタイプ検出⽤の⽤語は eventdiscoverer.conf に設定されます。
類似イベントの分類とグループ化
イベント はイベントタイプ とは異なります。イベントは、データの単⼀のインスタンスです。たとえば、1 つの
ログエントリがイベントになります。イベントタイプは、イベントにラベルを付けてグループ化するために⽤いら
れる分類⽅法です。
イベントに対応するイベントタイプ名は、イベントの eventtype と呼ばれる複数値フィールドに設定されます。こ
れらのイベントグループ (例：SSH ログイン) は、任意のフィールド値と同じ⽅法でサーチできます。
ここでは、イベントタイプの保存とサーチでの使⽤⽅法について説明していきます。イベントの詳細、Splunk の
イベントの認識⽅法、インデックス作成時のイベントの処理⽅法などについては、『Getting Data In Manual』
の「Overview of event processing」を参照してください。
サーチの新規イベントタイプとしての保存
基本的に、イベントデータをサーチする場合、不要なイベントをすべて除去することになります。サーチ結果は類
似の特徴を持つイベントの集合になり、それらに総称名を指定することができます。
たとえば、異なるホストマシン上の失敗したログインを頻繁にサーチする場合、サーチで⾒つかったイベントに対
応するイベントタイプを作成して、failed_login と⾔う名前を付けられます。
54
応するイベントタイプを作成して、failed_login と⾔う名前を付けられます。
"failed login" OR "FAILED LOGIN" OR "Authentication failure" OR "Failed to authenticate user"
このサーチをイベントタイプとして保存するには：
1. サーチを実⾏します。サーチの実⾏中に、[作成] をクリックして、[イベントタイプ] を選択します。サーチが
完了するまで待たずにこの作業を⾏えます。
2. [イベントタイプとして保存] で、サーチに名前 を指定します。このサーチ例では、「failed_login」と名付け
ます。
必要に応じて、[サーチ⽂字列] フィールドを変更することができます。このフィールドには、先ほど実⾏した
サーチが⾃動的に⼊⼒されています。
また、必要に応じて [タグ] フィールドに、イベントタイプに適⽤するタグのリストを追加することもできます。
詳細は、後述のイベントタイプへのタグ設定に関する説明を参照してください。
3. [保存] をクリックするとイベントタイプ名が保存されます。
これで、任意のフィールドをサーチするのと同じ⽅法で、イベントタイプにマッチするすべてのイベントを⼿軽に
サーチできるようになります。
たとえば、特定のホストマシン上の失敗したログインを調査することができます。
host=target eventtype=failed_login
また、疑わしいユーザーのアクティビティを調査することもできます。
user=suspicious eventtype=failed_login
重要なイベントタイプ定義の制限事項
パイプ演算⼦ またはサブサーチ を含むサーチに基づいたイベントタイプを作成することはできません。
また、レポートを参照するサーチに基づいてイベントタイプを作成することはできません。たとえば、前の例の
サーチを実⾏してそれを failed_login_search という名前のレポートとして保存しても、そのサーチ
savedsearch=failed_login_search が定義するイベントタイプを作成することはできません。このような場合は、レ
ポートと同じサーチ⽂字列をイベントタイプに指定する必要があります。
punct による類似イベントの識別
イベントの句読点⽂字はイベントタイプに対して⼀意であることが多いため、Splunk Enterprise はイベントの句
読点⽂字を punct フィールドにインデックスしています。このフィールドの値は暗号のように⾒えますが、類似イ
ベントの特性を把握するための効果的な⼿段を提供しています。
サーチ結果に punct フィールドを適⽤するには、Splunk チュートリアルの「フィールドを使ったサーチ」で説明
されているフィールドポップアップを使⽤します。SSH ログインイベントの punct 値を選択します。これによ
り、サーチバーのサーチに punct が⼊れられます。句読点⽂字にワイルドカードを使⽤して、さまざまなバリエー
ションを照合することができます (例："punct=::[]*/*")。
typelearner を使った新規イベントタイプの検出
任意のサーチを typelearner コマンドに渡すと、Splunk Enterprise が提案するイベントタイプを確認できます。
デフォルトで、typelearner はサーチ結果となるイベントの句読点を⽐較し、類似の句読点や単語を持つイベント
をグループ化します。
イベントをグループ化するために、異なるフィールドを指定することができます。typelearner は任意のフィール
55
ドと同じように機能します。結果は、このフィールドとフレーズを共通に保有する、⼀連のイベント (サーチ結果
からの) になります。
詳細と例については、『サーチリファレンスマニュアル』の「typelearner」を参照してください。
タグを使った類似イベントのグループ化と検索
イベントタイプには、それに関連する 1 つまたは複数のタグを割り当てられます。サーチをイベントタイプとし
て保存する際に、またはイベントタイプ管理 ([設定] > [イベントタイプ] )から、これらのタグを追加できます。
このウィンドウのイベントタイプリストから、編集するイベントタイプを選択します。
イベントタイプにタグを追加したら、任意のタグのサーチと同じ⽅法でサーチを実施することができます。ファイ
アウォールイベントのサーチをイベントタイプ firewall_allowed として保存し、ログインイベントのサーチをイベ
ントタイプ login_successful として保存した場合を考えてみましょう。これらのイベントタイプにタグ「allow」
を設定しておけば、サーチを使って両⽅のイベントタイプのイベントを取得できます。
tag::eventtype="allow"
タグの使⽤⽅法の詳細は、このマニュアルの「フィールド値のタグ/エイリアス設定」を参照してください。
Splunk Web でのイベントタイプの定義と管理
有益なイベントを結果として得るために、イベントタイプに基づいてサーチを実⾏します。単⼀のイベントは、複
数のイベントタイプに⼀致することができます。
Splunk Web で作成したイベントタイプは、$SPLUNK_HOME/etc/users/<your-username>/<app>/local/ の
eventtypes.conf に⾃動的に追加されます。ここで、<app> はイベントタイプ作成時にあなたがいた App を表しま
す。イベントタイプの権限を変更してすべてのユーザーが利⽤できるようにした場合 (App 内で、またはすべての
App でグローバルに)、そのイベントタイプは $SPLUNK_HOME/etc/apps/<App>/local/ に移動されます。
重要なイベントタイプ定義の制限事項
パイプ演算⼦ またはサブサーチ を含むサーチに基づいたイベントタイプを作成することはできません。
また、レポートを参照するサーチに基づいてイベントタイプを作成することはできません。たとえ
ば、failed_login_search という名前のレポートがある場合に、savedsearch=failed_login_search で定義されるイベン
トタイプを作成することはできません。このような場合は、レポートと同じサーチ⽂字列をイベントタイプに指定
する必要があります。
サーチのイベントタイプとしての保存
サーチをイベントタイプとして保存するには：
サーチを⼊⼒して実⾏します。
[名前を付けて保存] をクリックして、[イベントタイプ] を選択します。
[イベントタイプとして保存] ダイアログボックスに、サーチ⽂字列が表⽰されます。
イベントタイプ名を指定します。
必要に応じて、イベントタイプに 1 つまたは複数のカンマで区切ったタグ を設定します。
[保存 ] をクリックします。
これでイベントタイプをサーチに利⽤できるようになりました。イベントタイプに foo という名前を指定した場
合、サーチでは以下のようにイベントタイプを使⽤します。
eventtype=foo
イベントタイプの⾃動検索/作成
IT データ内に有益なイベントタイプがあるかどうか分からないことがありませんか？Splunk Enterprise には、
役に⽴つイベントタイプを賢く動的に検出、作成するユーティリティが⽤意されています。
イベントタイプの検索： findtypes サーチコマンドは、指定されたイベントセットを分析して、有⽤なイベ
ントタイプに変換できる共通パターンを判別します。
イベントタイプの作成： イベントタイプの作成ユーティリティ により、サーチから返されたイベントに
基づいて動的にイベントタイプを作成することができます。このユーティリティでは、イベントタイプに特
定の⾊を割り当てることもできます。たとえば、「sendmail error」イベントタイプに⾚を割り当てた場
合、次回のサーチ実⾏時にこのイベントタイプに該当するイベントが⾚⾊で表⽰され、⼀⽬で把握できるよ
うになります。
イベントタイプの検索
イベントタイプを検索するには、サーチの最後に以下の項⽬を追加します。
...| findtypes
findtypes
コマンドを使⽤するサーチは、サーチ結果内のもっとも共通なイベントグループの明細を返します。こ
れは：
56
頻度の観点から並べられています。これにより、⼤きなイベントグループのサブセットとなるイベントを⼿
軽に把握することができます。
類似のイベントを探すために役⽴つイベントタイプの基盤として利⽤できるサーチが記載されています。
デフォルトで、findtypes は、サンプルから⾒つかったイベント数の観点から上位 10 件のイベントタイプ候補を
返します。max 引数を追加して、返される値を増やすことができます。 findtypes max=30
また、findtypes で⾒つかったイベントグループが、すでに他のイベントタイプに関連付けられているかどうかも
表⽰されます。
注意： findtypes コマンドは、これらの結果を返すために最⾼で 5000 件のイベントを分析します。サーチの効率
性を向上するために、head コマンドを使ってこの値を減らすことができます。
...| head 1000 | findtypes
イベントタイプ候補のサーチを保存する前のテスト
役に⽴つイベントグループ候補を識別する際に、それに関連するサーチをテストして、⽬的の結果が返されるかど
うかをテストすることができます。注⽬しているイベントグループの [テスト] をクリックして、関連するサーチ
を別のウィンドウで実⾏することができます。サーチの実⾏後、返された結果を⾒て、⽬的の情報が表⽰されるか
どうかを確認することができます。
テストしたサーチのイベントタイプとしての保存
⽬的の結果を返すサーチが⾒つかったら、対応するイベントグループの [保存] をクリックして、それをイベント
タイプとして保存します。[イベントタイプの保存] ダイアログが表⽰されます。イベントタイプ名を⼊⼒して、必
要に応じてタグを設定します (複数設定する場合はカンマで区切る)。必要に応じてサーチを編集することもできま
す。
イベントタイプの作成
イベントタイプのベースにする、⽬的の結果を返すサーチが⾒つかったら、イベントのタイムスタンプの横にある
ドロップダウンメニューの下⽮印をクリックして、[イベントタイプの作成] をクリックします。
イベントタイプの作成ユーティリティ (イベントタイプビルダー) が表⽰されます。このユーティリティを使っ
て⽬的のセットを返すサーチを作成し、それに基づいたイベントタイプを作成します。
イベントタイプの作成ユーティリティは、サーチ結果から選択した場合と同様な、サンプルイベントセットを検索
します。[イベントタイプの特徴] サイドバーには、イベントタイプをさらに絞り込むためのフィールド/値のペ
アが表⽰されます。
このユーティリティのページ上部の [⽣成されたイベントタイプ] には、サーチ⽂字列が表⽰されます。これ
は、作成しているイベントタイプのベースとなるサーチです。[イベントタイプの特徴] サイドバーでフィールド/
値のペアを選択すると、[⽣成されたイベントタイプ] がそれらを含むように更新されます。サンプルイベントの
リストも、変更されたサーチに応じて更新されます。
サーチを直接編集する場合は、[編集] をクリックします。[イベントタイプの編集] ダイアログが表⽰されます。
ここでは、サーチ⽂字列を編集することができます。
イベントタイプ候補のサーチを保存する前のテスト
有⽤なイベントタイプになるサーチを作成したら、それをテストしてください。[テスト] をクリックすると、
サーチが別のウィンドウで実⾏されます。
57
テストしたサーチのイベントタイプとしての保存
サーチをテストして、⽬的のイベントセットが得られることを確認したら、[保存] をクリックして、それをイベ
ントタイプとして保存します。[イベントタイプの保存] ダイアログが表⽰されます。
イベントタイプ名を⼊⼒してください。次に、必要に応じて [スタイル] リストでイベントタイプに割り当てる⾊
を選択します。保存した後は、そのイベントタイプに該当するイベントは、割り当てた⾊で表⽰されます。たとえ
ば、イベントタイプ sendmail_bounce を作成して、それの [スタイル] に⾚を設定して保存します。そうすると、
サーチを実⾏してこのイベントタイプに該当するイベントは⾚で表⽰されるため、⼿軽に特定することができま
す。
[優先度] リストを使って、[スタイル] が設定されている複数のイベントタイプに該当するイベントの処理⽅法を
指定することができます。たとえば、優先度が「⾼」のイベントタイプのスタイルに⾚を設定し、優先度が「平
均」のイベントタイプのスタイルに緑を設定した場合を考えてみましょう。返されたイベントが両⽅のイベントタ
イプに該当する場合、「⾼」優先度のイベントタイプが「平均」のイベントタイプに優先されて、そのイベントは
サーチ結果内に⾚で表⽰されます。
Splunk Web でのイベントタイプの追加と管理
Splunk Web の [イベントタイプ] ページでは、作成したイベントタイプや編集権限のあるイベントタイプの詳細
を表⽰、管理することができます。[イベントタイプ] ページでは、新しいイベントタイプを追加することもできま
す。[イベントタイプ] ページに表⽰されるイベントタイプは、グローバルにシステム全体で利⽤できる場合も、
App 固有の場合もあります。
Splunk Web でのイベントタイプの追加
Splunk Web でイベントタイプを追加するには、[イベントタイプ] ページで [新規] をクリックします。[新しいイ
ベントタイプの追加] ページが表⽰されます。
このページでは、イベントタイプを定義する [宛先 App] 、[名前] 、および [サーチ⽂字列] を⼊⼒します (上記の
「サーチのイベントタイプとしての保存」を参照)。
注意： 作成したイベントタイプはすべて、当初は特定の App で利⽤できます。イベントタイプをすべてのユー
ザーにグローバルに利⽤させるには、[イベントタイプ] ページで⽬的のイベントタイプを探して [権限] リンクを
クリックし、[この App のみ] を [すべての App] に変更しますイベントタイプ (および他のナレッジオブジェ
クトタイプ) の権限の設定⽅法については、このマニュアルの「ナレッジオブジェクトの権限の管理」を参照して
ください。
必要に応じて、イベントタイプにタグ を設定することもできます。イベントタイプおよび他の Splunk Enterprise
ナレッジへのタグの設定については、このマニュアルの「タグとエイリアスについて」を参照してください。
必要に応じてイベントタイプの優先度 を設定することもできます。1 が最⾼優先度、10 が最低優先度になりま
す。[優先度] の設定は、イベントが複数のイベントタイプに該当する場合に重要になります。サーチ結果にイベ
ントを表⽰する場合、イベントに関連するイベントタイプが特定の順序で表⽰されます。[優先度] の設定によ
り、この表⽰順序においてあるイベントタイプを他のイベントタイプに優先させることができます。
58
多数のオーバーラップするイベントタイプがある場合、または⼤きなイベントタイプのサブセットとなるイベント
タイプがある場合、厳密に絞り込まれているイベントタイプに⾼い優先度を割り当てる⽅が分かりやすいことがあ
ります。たとえば、幅広い system_error イベントタイプの⼀部となるイベントセットを、⼿軽に把握できるように
することができます。そのような巨⼤なイベントセットに対して、より絞り込んだイベントタイプ
critical_disc_error や bad_external_resource_error を作成することができます。
このような状況で、たとえば system_error に優先度 10 を、他の 2 つのエラーコードには優先度 に 1〜5 の範囲
の値を割り当てます。これにより、サーチ結果でイベントが system_error と critical_disc_error の両⽅に該当する
場合、critical_disc_error イベントタイプが常に system_error イベントタイプよりも先に表⽰されます。
Splunk Web での イベントタイプの管理
イベントタイプの詳細を更新するには、Splunk Web の [イベントタイプ] ページ ([設定] > [イベントタイプ] )
で、⽬的のイベントタイプの名前をクリックします。イベントタイプの詳細ページが表⽰されます。ここで
は、[サーチ⽂字列] 、[タグ] 、および [優先度] を編集できます (適切な権限がある場合)。また [イベントタイプ]
ページでは、イベントタイプの権限を変更したり、イベントタイプを削除したりすることもできます (編集権限が
ある場合)。
eventtypes.conf を使ったイベントタイプの設定
eventtypes.conf を編集して、新しいイベントタイプを追加したり、既存のイベントタイプを更新したりすること
ができます。いくつかのイベントタイプは、デフォルトで $SPLUNK_HOME/etc/system/default/eventtypes.conf に存在
しています。Splunk 管理で作成したイベントタイプは、⾃動的に $SPLUNK_HOME/etc/system/local/eventtypes.conf に
追加されます。
重要なイベントタイプ定義の制限事項
パイプ演算⼦ またはサブサーチ を含むサーチに基づいたイベントタイプを作成することはできません。
また、保存済みサーチを参照するサーチに基づいてイベントタイプを作成することはできません。たとえ
ば、failed_login_search という名前の保存済みサーチがある場合に、サーチ savedsearch=failed_login_search が定義
するイベントタイプを作成することはできません。このような場合は、保存済みサーチと同じサーチ⽂字列にイベ
ントタイプを指定する必要があります。
設定
でイベントタイプを変更します。$SPLUNK_HOME/etc/system/README/eventtypes.conf.example を例として
使⽤することも、独⾃の eventtypes.conf を作成することも可能です。
eventtypes.conf
$SPLUNK_HOME/etc/system/local/、または $SPLUNK_HOME/etc/apps/
内の独⾃のカスタム App ディレクトリ内にある
を編集してください。設定ファイルの⼀般情報については、『管理マニュアル』の「設定ファイル
について」を参照してください。
eventtypes.conf
[$EVENTTYPE]
イベントタイプのヘッダー。
$EVENTTYPE はイベントタイプ名です。
任意の数のイベントタイプを指定できます。それぞれのイベントタイプをスタンザとして定義して、
以下の属性/値のペアを指定できます。
注意： イベントタイプ名にパーセント記号で囲んだフィールド名が含まれている場合 (例：%$FIELD%)、サーチ時に
$FIELD の値がイベントタイプ名に代⼊されます。たとえば、ヘッダーが [cisco-%code%] のイベントタイプ
で、code=432 の場合は [cisco-432] のように表⽰されます。
disabled = <1 or 0>
イベントタイプをオン/オフにします。
無効にする場合は 1 を設定します。
search = <string>
このイベントタイプのサーチ⽤語。
例：error OR warn。
tags = <string>
イベントタイプのタグとなる、スペースで区切られた単語。
description = <string>
イベントタイプの説明 (省略可)。
priority = <integer>
Splunk Enterprise はこの値を使って、イベントに該当するイベントタイプの表⽰順序を決定します。1 が
最⾼、10 が最低を表します。
注意： eventtype のフィールド値は、他のフィールド/値の組み合わせへのタグ設定と同じようにタグ付けすること
59
ができます。詳細は、tags.conf ファイルを参照してください。
例
2 種類のイベントタイプ
web
および
fatal
があります。
[web]
search = html OR http OR https OR css OR htm OR html OR shtml OR xls OR cgi
[fatal]
search = FATAL
イベントタイプの無効化
イベントタイプを無効にするには、eventtypes.conf の該当するイベントタイプスタンザに
す。
disabled = 1
を追加しま
[$EVENTTYPE]
disabled = 1
$EVENTTYPE
web
は無効にするイベントタイプ名を表しています。
イベントタイプを無効にする場合は、以下のエントリを該当するスタンザに追加します。
[web]
disabled = 1
イベントタイプテンプレートの設定
イベントタイプテンプレートは、サーチ時にイベントタイプを作成します。eventtypes.conf にイベントタイプテ
ンプレートを定義します。$SPLUNK_HOME/etc/system/local/、または $SPLUNK_HOME/etc/apps/ 内の独⾃のカスタム App
ディレクトリ内にある eventtypes.conf を編集してください。
設定ファイルの⼀般情報については、『管理マニュアル』の「設定ファイルについて」を参照してください。
イベントタイプテンプレートの設定
イベントタイプテンプレートは、フィールド名をパーセント記号で囲んだものを使って、サーチ時にイベントタイ
プを作成します。この時、%$FIELD% の値がイベントタイプ名に代⼊されます。
[$NAME-%$FIELD%]
$SEARCH_QUERY
テンプレートのサーチが %$FIELD%=bar のイベントを返した場合、そのイベントに対して
ベントタイプが⽣成されます。
$NAME-bar
と⾔う名前のイ
例
[cisco-%code%]
search = cisco
「cisco」のサーチで
成されます。
code=432
を持つイベントが返された場合、「cisco-432」と⾔う名前のイベントタイプが作
トランザクションについて
トランザクション は、⼀定期間にまたがる概念的に関連するイベントのグループです。トランザクションタイ
プ はtransactiontypes.conf に設定されているトランザクションで、Splunk にフィールド として保存されていま
す。
トランザクションには、以下の項⽬を含めることができます。
同じソース、同じホストからの異なるイベント。
同じホストの異なるソースからの異なるイベント。
異なるホスト、異なるソースからの類似イベント。
たとえば、オンラインストアで商品を購⼊した顧客が、複数のソースからのイベントをまとめたトランザクション
を⽣成する場合があります。
⼀連の Web アクセスイベント が、以下のセッション ID を共有します。
アプリケーションサーバーログ内の該当するイベント 、これには関連するアカウント、製品、およびトラ
60
ンザクション ID も含まれます。そのアプリケーションサーバーイベント内のトランザクション ID は、以
下の所にも登場します。
メッセージキューイベント 、これはメッセージ ID を含んでいます。このメッセージ ID は、その後次によ
り共有されます。
購⼊処理アプリケーションが記録した購⼊完了イベント 、これには顧客が購⼊した商品の配送状況ステータ
スも含まれています。
ここで取り上げた項⽬すべてをまとめたものが、1 つのユーザートランザクションを表しています。これをトラン
ザクションタイプとして定義して、それに「商品購⼊」トランザクションなどの名前を付けることができます。そ
の他の種類のトランザクションとしては、Web アクセス、アプリケーションサーバーダウンロード、メール、セ
キュリティ違反、およびシステム障害などが含まれます。
トランザクションサーチ
トランザクションサーチにより、ログに記録されている複数のイベントにまたがってトランザクションイベントを
識別することができます。トランザクション (イベントのグループ) を返すサーチを定義するには、transaction コ
マンドとそのオプションを使⽤します。使⽤⽅法を説明したさまざまな例については、『サーチリファレンス』に
記載されているこのコマンドの説明を参照してください。
最初のイベントと最後のイベントが、⼀定の値 (maxspan で設定) を超えない期間により区切られている、⼀
連のイベントを探します。
含まれているイベント間の期間が⼀定の値 (maxpause オプションで設定) を超えない、⼀連のイベントを探し
ます。
合計イベント数が特定の数 (maxevents オプションで設定) を超えない、関連するイベントのグループを探し
ます。
最後のイベントが特定のテキスト⽂字列 (endswith オプションで設定) を含むイベントグループを探すトラン
ザクションを設計します。
このコマンドで利⽤できるオプションについては、transaction コマンドの記事を参照してください。
また、transaction コマンドを使って、transactiontypes.conf に設定されているトランザクションオプションに優先
する設定を⾏うこともできます。
を使ったサーチの詳細は、『サーチマニュアル』の「イベントの識別とトランザクションへのグルー
プ化」を参照してください。
transaction
トランザクションタイプの設定
繰り返し再利⽤するのにふさわしいトランザクションサーチを作成したら、それを
ザクションタイプとして追加して、継続的に利⽤することができます。
transactiontypes.conf
にトラン
トランザクションタイプの設定⽅法の詳細は、「トランザクションの設定」を参照してください。
トランザクションの代わりに stats を使⽤する場合
トランザクションは、トランザクションデータの総統計を算出するためのもっとも効率的な⼿段と⾔う訳ではあり
ません。単⼀フィールド内のデータにより定義されているトランザクションの総統計を算出する場合は、stats コ
マンドを使⽤します。
たとえば、session_id フィールドが定義する、トランザクションの期間の統計を算出する場合は、以下のコマンド
を使⽤します。
* | stats min(_time) AS earliest max(_time) AS latest by session_id | eval duration=latest-earliest | stats
min(duration) max(duration) avg(duration) median(duration) perc95(duration)
同様に、アクセスログ内の
clientip
当たりのヒット数を算出する場合は、以下のコマンドを使⽤します。
sourcetype=access_combined | stats count by clientip | sort -count
また、アクセスログ内の clientip 当たりの⼀意のセッション (cookie でパラメータ化) 数を算出する場合は、以下
のコマンドを使⽤します。
sourcetype=access_combined | stats dc(cookie) as sessions by clientip | sort -sessions
stats コマンドの使⽤⽅法の詳細は、リファレンスマニュアルの stats コマンドに関する説明を参照してくださ
い。
トランザクションのサーチ
トランザクションのサーチは、Splunk Web または CLI で transaction サーチコマンドを使って⾏いま
す。transaction コマンドは、グループ化されたイベントを⽣成します。これをレポートに使⽤することができま
す。transaction を使⽤するには、トランザクションタイプ (transactiontypes.conf で設定) を呼び出すか、または
transaction コマンドにサーチオプションを設定して、サーチ内にトランザクション制約を定義します。
サーチオプション
サーチ時に返されるトランザクションは、各イベントの raw テキスト、共有イベントタイプ、およびフィールド
値から成り⽴っています。トランザクションには、次のフィールドに保存される追加データも存在していま
61
す：durationおよび
transactiontype。
には、トランザクションの期間が含まれています (トランザクション内の最初と最後のイベントのタ
イムスタンプの差)。
transactiontype はトランザクション名です (transactiontypes.conf にトランザクションのスタンザ名で定義)。
duration
は任意のサーチに追加できます。最良のサーチパフォーマンスを確保するために、適切なサーチを作
成して、それをパイプ⽂字で transaction コマンドに渡してください。詳細は、『Search Reference Manual』
の「transaction」を参照してください。
transaction
コマンドに続けて、以下のオプションを指定できます。注意： ⼀部の
オプションと⼀緒に指定することはできません。
transaction
transaction
オプションは、他の
[field-list]
次のような、フィールドのカンマ区切りリストです： ...|transaction host,cookie
設定した場合、同じトランザクション内にあるイベントと判断するには、各イベントに同じフィールドがな
ければなりません。
共通のフィールド名で異なる値を持つフィールドはグループ化されません。
たとえば、...|transaction host を追加した場合、host=mylaptop を持つサーチ結果が host=myserver を持
つサーチ結果と同じトランザクションになることはありません。
host の値を持たないサーチ結果は、host=mylaptop を持つ結果と同じトランザクションになる可能性が
あります。
match=closest
トランザクション定義で使⽤するマッチタイプを指定します。
現在のところ、値は closest のみをサポートしています。
maxspan=[<integer> s|m|h|d]
トランザクション内のイベントにまたがる最⼤期間を設定します。
秒、分、時間、または⽇単位で指定できます。
例：5s、6m、12h、または 30d。
デフォルトは、maxspan=-1 で、時間範囲は「全時間」となっています。
maxpause=[<integer> s|m|h|d]
トランザクション間の最⼤⼀時停⽌期間を指定します。
トランザクション内のイベント間の⼀時停⽌期間は maxpause 未満でなければなりません。
負の値を指定した場合、maxspause 制約は無効になります。
デフォルトは maxpause=-1 です。
startswith=<string>
サーチまたは eval フィルタリング式。あるイベントがこの条件を満たすと、新しいトランザクションの開
始としてマークされます。
例：
startswith="login"
startswith=(username=foobar)
startswith=eval(speed_field < max_speed_field)
startswith=eval(speed_field < max_speed_field/12)
デフォルトは
""
です。
endswith=<transam-filter-string>
サーチまたは eval フィルタリング式。あるイベントがこの条件を満たすと、新しいトランザクションの終
了としてマークされます。
例：
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)
62
"<search-expression>" |
トランザクションおよびマクロサーチ
トランザクションおよびマクロサーチは強⼒な組み合わせで、トランザクションサーチ内で代替を⾏うことができ
ます。代替を⾏うには、トランザクションサーチを実⾏して、それを $field$ で保存します。
マクロサーチとトランザクションの使⽤例については、『サーチマニュアル』の「サーチマクロの作成と使⽤」を
参照してください。
トランザクションサーチの例
単⼀のユーザー (またはクライアント IP アドレス) が⼀定期間に参照したすべての Web ページをグルー
プ化するサーチを実⾏します。
このサーチはアクセスログからイベントを作成し、同じ clientip 値を共有し、相互の発⽣間隔が 5 分以内のイベ
ントからトランザクションを作成します (3 時間の期間内で)。
sourcetype=access_combined | transaction clientip maxpause=5m maxspan=3h
トランザクションタイプの設定
任意のイベントシリーズをトランザクションタイプに変換することができます。使⽤事例については、このマニュ
アルの「トランザクションについて」を参照してください。
トランザクションタイプは、transactiontypes.conf を使って作成することができます。設定の詳細は、以下を参
照してください。
設定ファイルの⼀般情報については、『管理マニュアル』の「設定ファイルについて」を参照してください。
transactiontypes.conf へのトランザクションタイプの設定
1. $SPLUNK_HOME/etc/system/local/ 内、またはカスタム App ディレクトリ
transactiontypes.conf ファイルを作成してください。
$SPLUNK_HOME/etc/apps/
内に
2. スタンザを作成して、各トランザクションの属性を定義します。以下の属性を使⽤してください。
[<transactiontype>]
maxspan =
[<integer> s|m|h|d|-1]
maxpause = [<integer> s|m|h|d|-1]
fields = <comma-separated list of fields>
startswith = <transam-filter-string>
endswith=<transam-filter-string>
[<TRANSACTIONTYPE>]
任意の数のトランザクションタイプを作成できます。それぞれのトランザクションタイプ名はスタンザ名で
表します。以下の属性/値のペアを指定できます。
スタンザ名 [<TRANSACTIONTYPE>] を使って、Splunk Web 内のトランザクションをサーチします。
以下の属性にエントリを指定しない場合は、デフォルト値が使⽤されます。
maxspan = [<integer> s|m|h|d|-1]
トランザクションの最⼤期間を設定します。
秒、分、時間、⽇で指定できます。-1 を設定すると無制限になります。
例：5s、6m、12h、または 30d。
デフォルトは -1 です。
maxpause = [<integer> s|m|h|d|-1]
トランザクション内のイベント間の最⼤⼀時停⽌期間を設定します。
秒、分、時間、⽇で指定できます。-1 を設定すると無制限になります。
例：5s、6m、12h、または 30d。
デフォルトは -1 です。
maxevents = <integer>
1 つのトランザクション内の最⼤イベント数。値が負の整数の場合、制約は無効になります。
デフォルトは 1000 です。
fields = <comma-separated list of fields>
設定した場合、同じトランザクション内にあるイベントと判断するには、各イベントに同じフィールドがな
ければなりません。
例： fields = host,cookie
デフォルトは " " です。
connected= [true|false]
fields
が空でない場合にのみ関係しています。トランザクションのフィールドと整合性のあるまたは整合性
63
のないイベントを、新しいトランザクションで開く (connected=true) か、またはトランザクションに追加
するかを指定します。
トランザクションが必要とするフィールドを持つけれども、トランザクション内でこれらのフィールドがど
れもインスタンス化されていない (前のイベント追加により) 場合、イベントは⾮不整合および⾮整合にでき
ます。
デフォルト： connected = true
startswith = <transam-filter-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> の構⽂は以下のようになります。
"<search-expression>" | (<quoted-search-expression> | eval(<eval-expression>)
ここで：
は、引⽤符を含まない有効なサーチ式です。
は、引⽤符を含む有効なサーチ式です。
<eval-expression> は、論理演算式を評価する有効な eval 式です。たとえば、startswith=eval(foo<bar*2)
は、foo が 2 x bar 未満のイベントに⼀致します。
<search-expression>
<quoted-search-expression>
例：
"<search-expression>"： startswith="foo bar"
<quoted-search-expression>： startswith=(name="foo bar")
<quoted-search-expression>： startswith=("search literal")
eval(<eval-expression>)： eval(distance/time < max_speed)
3. Splunk Web で transaction コマンドを使って、定義したトランザクション (定義したトランザクションタイプ
名を使⽤) を呼び出します。サーチ時の指定に優先させることができます。
トランザクションの詳細は、このマニュアルの「トランザクションのサーチ」を参照してください。
その他のトランザクション設定属性
transactions.conf
には、複数値フィールドやメモリー制限上の問題などに対処する⽬的で⽤意されている属性があ
ります。
メモリー制限に関する問題⽤のトランザクションオプション
maxopentxn=<int>
LRU (least-recently-used memory cache) ポリシーを使って、トランザクションの削除を開始するまで
に、開いているプール内に保持する未終了トランザクションの最⼤数を指定します。
この属性のデフォルト値は、limits.conf の transactions スタンザから読み込まれます。
maxopenevents=<int>
LRU (least-recently-used memory cache) ポリシーを使って、トランザクションの削除を開始する前に、
開かれているトランザクションの⼀部となるイベントの最⼤数を指定します。
この属性のデフォルト値は、limits.conf の transactions スタンザから読み込まれます。
keepevicted=[true|false]
削除したトランザクションを出⼒するかどうかを指定します。evicted フィールドの値を確認すれば、削除さ
れたトランザクションと削除されていないトランザクションを判別することができます。削除されたトラン
ザクションの場合、フィールドには 1 が設定されます。
デフォルトは keepevicted=false です。
64
複数値フィールド表⽰⽤トランザクションオプション
mvlist=[true|false]|<field-list>
属性には、トランザクションの複数値フィールドを、元のイベントのリストの到着順に並べるか、ま
たは⼀連の⼀意のフィールド値を辞書式に並べるかを指定します。フィールドのカンマまたはスペース区切
りリストを指定した場合、それらのフィールドのみをリストとして表⽰します。
デフォルト：mvlist=false。
mvlist
delim=<string>
トランザクションのイベントフィールドにある元のイベント値を区切るために使⽤する⽂字列。
デフォルト： delim=" "
nullstr=<string>
⽋損フィールド値を、トランザクション内の複数値フィールドの⼀部として表⽰する際に使⽤する⽂字列
値。
このオプションは、リストとして表⽰されるフィールドにのみ適⽤されます。
デフォルト： nullstr=NULL
データの強化：ルックアップとワークフローアクショ
ン
ルックアップとワークフローアクションについて
ルックアップとワークフローアクションにより、外部リソースを活⽤してイベントデータの有益性を強化すること
ができます。
テーブルのルックアップ
テーブルのルックアップ はイベント内の情報を使って、静的テーブル (CSV ファイル) や Python およびバイナ
リ・ベースのスクリプト、App キー・バリュー・ストア (KV ストア)コレクションなどの外部データソースから
の、他のフィールドの追加⽅法を判断します。これらのルックアップ・タイプでは、必要に応じて時間情報に基づ
いてフィールドを追加することができます。
この例として、イベント内の http_status 値を使⽤する CSV ルックアップが挙げられます。この値を CSV ファイ
ル内の定義と照合して、イベントにその定義を新たな status_description フィールドの値として追加します。イベ
ントが http_status = 503 の場合、ルックアップによりイベントに status_description = Service Unavailable, Server
Error が追加されます。
ルックアップには他にもさまざまな利⽤法があります。たとえば、以下のような作業を⾏えます。
静的ルックアップテーブルに、レポートの結果を設定する。
ルックアップテーブルの代わりに、外部 Python スクリプトに基づくフィールドルックアップを定義する。
たとえば、与えられたホスト名に対して IP アドレスを、与えられた IP アドレスに対してホスト名を返す
Python スクリプトを使ったルックアップを作成することができます。
イベント内のフィールドとKV ストアのルックアップ内のフィールドと照合して、イベントのフィールドを
返すルックアップを定義します。サーチ結果を KV ストアのコレクションに書き込むサーチを設計すること
もできます。
時間を表すフィールド値を持つルックアップテーブルを利⽤して、時間ベースのルックアップを作成する。
たとえば、DHCP ログから、IP アドレスとイベントのタイムスタンプに基づいて、ネットワークのユー
ザーを識別する場合などに役⽴ちます。
詳細は、このマニュアルの「CSV および外部ルックアップの設定」および「KV ストア・ルックアップの設定」
を参照してください。
ワークフローアクション
ワークフローアクション を使って、データ内の特定のフィールドと他のアプリケーションや Web リソース間の
やり取りを設定することができます。とても単純なワークフローアクションとして、たとえば IP_address フィール
ドにワークフローアクションを関連付け、起動時に IP_address の値に基づいて、外部の WHOIS サーチを別のブ
ラウザウィンドウに表⽰することができます。
また、以下のようなワークフローアクションを設定することもできます。
特定のフィールドのみに適⽤する (イベント内のすべてのフィールドではない)。
特定のイベントタイプまたはイベントタイプのグループに属するイベントにのみ適⽤する。
イベントドロップダウンメニュー、フィールドドロップダウンメニュー、またはその両⽅からアクセスされ
たかを判断する。
HTTP GET リクエストを実⾏して、情報を外部検索エンジンや IP ルックアップサービスに渡す。
フィールド値を外部リソースに送信できる、HTTP POST リクエストを実⾏する。たとえば、ステータス値
を外部の問題追跡アプリケーションに送信するワークフローアクションを作成することができます。
選択したイベントからフィールド値を取得して、それらの値を設定した⼆次サーチを別のブラウザウィンド
ウで実⾏する。
Splunk Web でのワークフローアクションの設定については、この章の「Splunk Web を使ったワークフローア
クションの作成と管理」を参照してください。
65
フィールドルックアップを使ったイベントへの情報の追加
Splunk Enterprise のルックアップ機能では、イベントデータ内のフィールドとマッチする外部 CSV ファイル内
のフィールドを参照することができます。このマッチを使⽤して、他のサーチ可フィールドをイベントデータに追
加することで、データの価値をさらに⾼められます。⼀時フィールドや Python スクリプトの出⼒などを含め、任
意のフィールドをベースにしたフィールドルックアップを実⾏することができます。
ここでは、Splunk Web の [設定] > [ルックアップ] にある、ルックアップページの使⽤⽅法について説明して
いきます。
既存のルックアップテーブルの表⽰または新しいファイルのアップロードを⾏います。
既存のルックアップ定義を編集、または新たにファイルベースのルックアップまたは外部ルックアップを定
義します。
既存の⾃動ルックアップの編集または新しい⾃動実⾏ルックアップの設定を⾏います。
ルックアップの詳細は、このマニュアルの「CSV および外部ルックアップの設定」および「KV ストア・ルック
アップの設定」を参照してください。
既存のルックアップテーブルの表⽰または新しいファイルのアップロード
[設定] > [ルックアップ] > [ルックアップテーブルファイル] で既存のルックアップテーブルを表⽰するか、ま
たは [新規追加] をクリックして、ファイルベースのルックアップに使⽤する CSV ファイルをアップロードしま
す。
注意： OSX OS9 より前のバージョンおよび初期の Classic Macintosh 形式の⾏終端 (単なるキャリッジリター
ン「\r」のみ) を持つ CSV ファイルはサポートされていません。
新しいファイルをアップロードするには：
1. [宛先 App] を選択します。
これにより、ルックアップテーブルファイルが App のディレクトリに保存されま
す。$SPLUNK_HOME/etc/users/<username>/<app_name>/lookups/。
2. ルックアップテーブルファイルの名前 を指定します。
この名前を使ってルックアップ定義内でファイルを参照します。
3. アップロードする CSV ファイルを参照 して、選択します。
4. [保存 ] をクリックします。
既存のルックアップ定義の編集または新たなファイルベースのルックアップまたは外部
ルックアップの定義
[設定] > [ルックアップ] > [ルックアップ定義] ページを使って、ルックアップテーブルを定義したり、既存の
ルックアップ定義を編集することができます。ルックアップのタイプ (ファイルベースまたは外部)、および時間
ベースかどうかを指定できます。ルックアップテーブルを定義したら、サーチ内でルックアップを実⾏ (lookup
コマンドを使⽤)、またはルックアップを⾃動的に実施するように設定することができます。
注意： この作業は transforms.conf にルックアップを定義する場合と同じ意味を持っています。
時間ベースのルックアップの設定
フィールドの照合が時間情報 (ルックアップテーブル内のタイムスタンプを表すフィールド) に基づいている場合
は、フィールドベース/外部ルックアップを時間ベース (または⼀時) にすることもできます。
時間ベースのルックアップ を設定するには、[時間ベースのルックアップの設定] を選択して、次に時間フィー
ルド名を指定します。また、この時間情報の strptime フォーマットと時間照合⽤のオフセットを指定することも
できます。
詳細オプションの設定
[詳細オプション] では、以下の事項を指定できます。
各⼊⼒ルックアップ値の最低⼀致数。
各⼊⼒ルックアップ値の最⼤⼀致数。
⼊⼒からの最低⼀致項⽬数未満の場合に出⼒するデフォルト値。
既存の⾃動ルックアップの編集または新たなルックアップの設定
イベントにフィールドルックアップを適⽤する際に、lookup コマンドを実⾏する代わりに、ルックアップを⾃動
実⾏するように設定することができます。[設定] > [ルックアップ] > [⾃動ルックアップ] ページから、⾃動
ルックアップを編集、設定することができます。
既存の⾃動ルックアップを編集するには、ルックアップを選択して表⽰されたフィールドの値を変更します。
⾃動実⾏する新しいルックアップを追加するには：
1. [⾃動ルックアップ] ページで [新規] を選択します。
66
2. [宛先 App] を選択します。
3. フィールドのルックアップに使⽤する、ルックアップ・テーブル を選択します。
これは、[ルックアップ定義] ページで定義したルックアップ定義の名前です。
4. [適⽤先] メニューで、ルックアップを適⽤するホスト、ソース、またはソースタイプ値を選択し、名前を指定
します。
5. [ルックアップ⼊⼒フィールド] で、1 つまたは複数の⼊⼒フィールドのペアを指定します。
最初のフィールドは、照合するルックアップ・テーブル内のフィールドです。2 番⽬のフィールドは、ルッ
クアップ・テーブルのフィールドと照合する、イベントのフィールドです。たとえば、イベント内の
ip_address フィールドを、ルックアップ・テーブル内の ip フィールドと照合します。この場合、⾃動ルック
アップ定義には、ip = ip_address のように⼊⼒します。
6. [ルックアップ出⼒フィールド] で、1 つまたは複数の出⼒フィールドのペアを指定します。
最初のフィールドは、イベントに出⼒するフィールドに対応しています。2 番⽬のフィールドは、イベント
内での出⼒フィールドの名前です。たとえば、ルックアップ・テーブル内の country フィールドを、イベン
トに ip_city として出⼒することができます。
7. [フィールド値を上書き] を選択して、ルックアップ実⾏時にフィールド値を上書きするかどうかを選択するこ
ともできます。
注意： これは、props.conf にフィールド・ルックアップを設定するのと同じ意味を持ちます。
HTTP ステータスルックアップの例
この例では、Web アクセスイベントに 2 つの情報フィールド status_description と status_type を追加する、静的
ルックアップの定義⽅法を⾒ていきます。これにより、特定のエラーコードが分からないような場合に、⽬的のイ
ベントをサーチすることができます。たとえば、すべてのサーバーエラーコードをサーチする代わり
に、status="Server Error" を使⽤することができます。
Splunk Enterprise へのルックアップテーブルのアップロード
1. http_status.csv ファイルをダウンロードします：
http_status.csv
ファイルの例を以下に⽰します。
status,status_description,status_type
100,Continue,Informational
101,Switching Protocols,Informational
200,OK,Successful
201,Created,Successful
202,Accepted,Successful
203,Non-Authoritative Information,Successful
...
2. サーチ App に戻って、[設定] > [ルックアップ] を選択します。
3. [ルックアップ] ページで、[ルックアップテーブルファイル] の [新規追加] を選択します。
67
4. [新規追加] ページで以下の作業を⾏います。
宛先 App の [サーチ] を選択します。
先ほどダウンロードした CSV ファイルを選択します。
ルックアップテーブルに名前 http_status を指定します。
[保存] をクリックします。
Splunk Enterprise がファイルを保存したら、次のビューが表⽰されます。
[設定] > [ルックアップ] ビューに戻ります。そのためには、ページのブレッドクラムにある [ルックアップ] リ
ンクをクリックします。前のビューに戻るために、いつでもこれを利⽤することができます。
ルックアップの定義
1. [設定] > [ルックアップ] で、[ルックアップ定義] の [新規追加] を選択します。
[新規追加] ページで以下の作業を⾏います。
68
2. 宛先 App の [サーチ] を選択します。
3. ルックアップ定義に名前 http_status を指定します。
4. [タイプ] で、[ファイルベース] を選択します。
5. [保存] をクリックします。
Splunk Enterprise がルックアップ定義を保存したら、次のページが表⽰されます。
ルックアップ定義でいくつかのアクションを利⽤できることにお気づきでしょうか。[権限] では、ルックアップ
テーブルへのアクセス権を変更することができます。ルックアップ定義を [無効] 、[複製] 、および別の App に
[移動] することができます。また、定義を [削除] することができます。
ルックアップを定義したら、サーチに
に設定することができます。
lookup
コマンドを指定して実⾏したり、ルックアップを⾃動実⾏するよう
ルックアップの⾃動実⾏の設定
1. [設定] > [ルックアップ] ビューに戻って、[⾃動ルックアップ] の [新規追加] を選択します。
[新規追加] ページで以下の作業を⾏います。
69
2. 宛先 App の [サーチ] を選択します。
3. ルックアップに名前 http_status を指定します。
4. [ルックアップテーブル] ドロップダウンから [http_status] を選択します。
5. ルックアップを
access_combined
と⾔う名前の
sourcetype
に適⽤します。
6. [ルックアップ⼊⼒フィールド] は、ルックアップテーブルと照合する、イベント内のフィールドです。ここで
は、両⽅とも名前が status になっています (CSV 列名が左、照合するフィールドが右)。
7. [ルックアップ出⼒フィールド] は、イベントに追加するルックアップテーブルからのフィールドです
(status_description と status_type)。CSV 列名が左、照合するフィールドが右になります。
8. [保存] をクリックします。
70
CSV と外部ルックアップの設定
ルックアップは、イベント内に存在しているフィールドの値に基づいて、外部ソースからイベントにフィールドを
追加します。このトピックでは CSV と外部の、2 種類のルックアップを説明していきます。
ルック
アッ
プ・タ
イプ
CSV
ルック
アップ
説明
CSV ファイルから抽出したフィールドをイベントに設定します。CSV ファイルは静的なデータの
テーブルであるため、静的ルックアップと呼ばれることもあります。CSV テーブル内の各列が、
フィールドの潜在的な値であると解釈されます。
外部ルッ Python スクリプトまたはバイナリの実⾏形式ファイルを使って、外部ソースからのフィールド値を
クアップ イベントに設定します。
3 番⽬のルックアップ⼿法として、KV ストアのコレクションを使って定義する、KV ストア・ルックアップがあ
ります。このマニュアルの「KV ストア・ルックアップの設定」を参照してください。
このトピックでは、props.conf および transforms.conf にルックアップ・スタンザを設定することによる、CSV お
よび外部ルックアップの設定、管理⽅法について説明していきます。設定ファイルを利⽤すると、Splunk Web
を使ってルックアップ・ファイルを設定する場合よりも、ルックアップの設計と動作をよりきめ細かく調節するこ
とができます。
ファイルへのアクセス権がない場合、または可能な限り Splunk Web を使ってルックアップを管理したい場
合は、3 種類のルックアップ・タイプすべてを [設定] > [ルックアップ] のページで設定することができます。こ
のマニュアルの「ルックアップを使ったイベントへの情報の追加」を参照してください。
.conf
ステップ 1 - transforms.conf へのルックアップ・スタンザの追加
ルックアップ・スタンザには、ルックアップ・タイプ (CSV または外部) とルックアップ・テーブルの場所を指定
します。必要に応じて、フィールド照合ルールや時間的ルックアップ⽤のルールを指定することもできま
す。transforms.conf へのルックアップの設定⽅法は、ルックアップ・タイプによって異なります。
グローバルにルックアップを利⽤できるようにする場合は、$SPLUNK_HOME/etc/system/local/ にある transforms.conf
にルックアップ・スタンザを追加します。特定の App でのみルックアップを利⽤できるようにする場合
は、$SPLUNK_HOME/etc/apps/<app_name>/local/ にある transforms.conf にルックアップ・スタンザを追加します。
警告： $SPLUNK_HOME/etc/system/default 内の設定ファイルは編集しないでください。
CSV ルックアップ・スタンザの作成
CSV ルックアップは、イベントからのフィールド値を CSV ファイルが表している静的テーブル内のフィールド値
と照合します。次に対応するフィールド値をテーブルからイベントに出⼒します。
1. ルックアップ⽤の CSV ファイルを、Splunk Enterprise に追加します。
CSV ファイルは、以下のいずれかの場所に保管する必要があります。
$SPLUNK_HOME/etc/system/lookups
$SPLUNK_HOME/etc/apps/<app_name>/lookups
ルックアップディレクトリが存在していない場合は作成してください。
CSV ファイルが表すテーブルには、最低 2 つの列が必要です。それらの列の 1 つはイベント内のフィール
ドに含まれる、⼀連の値を持つフィールドを表します。この列は、イベントのフィールドと同じ名前である
必要はありません。任意の列に同じ値の複数のインスタンスを保有することができます。これは、複数値
フィールドを表しています。
CSV ファイルに UTF-8 以外の⽂字を含めることはできません。プレーン ASCII テキスト、および UTF-8
71
で有効な任意の⽂字セットを使⽤できます。
OSX より前 (OS9 以前) の Macintosh 形式の⾏終端 (単なるキャリッジリターン「\r」のみ) を持つ CSV
ファイルはサポートされていません。
2. CSV ルックアップ・スタンザを
transforms.conf
に追加します。
CSV ルックアップ・スタンザは、ルックアップ・テーブルを定義しており、ルックアップに使⽤する CSV
の名前が設定されています。以下のような必須属性を使⽤します。
[<lookup_name>]：ルックアップ名。
filename = <string>：ルックアップが参照する、CSV
ファイルの名前。
CSV ルックアップ・スタンザには、必要に応じて以下のような属性を設定することができます。
フィールド/値照合ルールを定義する。「ルックアップ⽤のオプションのフィールド照合ルール」を参照して
ください。
時間的な CSV ルックアップを定義する (時間ベースのルックアップ)。「時間的なルックアップの設定」を
参照してください。
3. .conf ファイルへの変更内容を保存します。
4. これを⾃動ルックアップにする場合は、ステップ 2 に移動してください。
そうでない場合は、ステップ 3 に移動して、Splunk Enterprise を再起動します。
外部ルックアップ・スタンザの作成
外部ルックアップは、イベント内のフィールドを外部ソースのフィールドと照合し、対応するフィールドを外部
ソースから出⼒して、それをイベントに追加するスクリプトを実⾏します。この種類のルックアップは、スクリプ
ト・ルックアップとも呼ばれています。
1. ルックアップ⽤のスクリプトを、Splunk Enterprise に追加します。
スクリプトは、以下のいずれかの場所に保管する必要があります。
$SPLUNK_HOME/etc/searchscripts
$SPLUNK_HOME/etc/apps/<app_name>/bin
スクリプトの仕組みの詳細は、「外部ルックアップ・スクリプトの詳細」を参照してください。
2. 外部ルックアップ・スタンザを
transforms.conf
に追加します。
外部ルックアップ・スタンザにはルックアップ・テーブル名が定義され、ルックアップを実⾏するスクリプ
トと引数、スクリプト・タイプ、スクリプトがサポートするフィールドのリストなどが設定されます。以下
のような必須属性を使⽤します。
[<lookup_name>]：ルックアップ名。
external_cmd = <string>：Splunk
Enterprise がルックアップを実⾏するために起動する必要があるコマンド
と引数。コマンドは、external_lookup.py のようなスクリプト名です。
external_type = [python|executable|kvstore]：ルックアップに使⽤するスクリプトのタイプです。Python スク
リプトの場合は python、バイナリの実⾏形式ファイルの場合は executable になります。kvstore は、KV スト
アのルックアップ⽤に予約されています。
fields_list = <string>：外部コマンドがサポートしているフィールドの、カンマ/スペース区切りリスト。
外部ルックアップ・スタンザには、必要に応じて以下のような属性を設定することができます。
フィールド/値照合ルールを定義する。「ルックアップ⽤のオプションのフィールド照合ルール」を参照して
ください。
時間的な外部ルックアップを定義する (時間ベースのルックアップ)。「時間的なルックアップの設定」を参
照してください。
3. .conf ファイルへの変更内容を保存します。
4. これを⾃動ルックアップにする場合は、ステップ 2 に移動してください。
そうでない場合は、ステップ 3 に移動して、Splunk Enterprise を再起動します。
ステップ 2 - ルックアップを⾃動にする
このステップでは、props.conf に以下のようなルックアップ設定を作成します。
ステップ 1 で作成したルックアップ・テーブルを参照する
ルックアップでルックアップ・テーブルと照合する、イベント内のフィールドを指定する
ルックアップで、ルックアップ・テーブルからイベントに出⼒する、対応するフィールドを指定する
その結果は、ルックアップ・テーブルからイベントに⾃動的にフィールドを追加する、⾃動ルックアップとなりま
す。
このステップは、ルックアップ・タイプの CSV と外部ルックアップで同じになります。KV ストア・ルックアッ
プには適⽤されせん。
72
注意： このステップは省略することができます。関連するホスト、ソース、またはソースタイプでサーチを実⾏
すると、ルックアップ・テーブルからイベントに⾃動的にフィールドが追加される⾃動ルックアップを作成したく
ない場合は、この⼿順をスキップしてください。⾃動ルックアップを作成しない場合でも、 lookup、inputlookup、
および outputlookup コマンドを使って transforms.conf の設定を実⾏することができます。
⾃動ルックアップは、⾃分に所属している、または共有されている任意のデータにアクセスすることができます。
サーチ・コマンドでルックアップを利⽤する場合は、共有されたデータにのみアクセスすることができます。
1. props.conf で、ルックアップを関連付けるホスト、ソース、またはソースタイプに対応したスタンザを探しま
す。
スタンザが存在しない場合は、それを作成してください。
スタンザのヘッダーの形式は
[<spec>]
です。<spec>には、以下の値を使⽤できます。
<sourcetype>、イベントのソースタイプ。
host::<host>、ここで
<host></code> はイベントのホスト、またはホスト照合パターンです。
は、イベントのソースまたはソース照合パターンです。
source::<source>, where <source>
<spec>
で正規表現の構⽂を使⽤することはできません。
2. 指定した、または作成したスタンザに、LOOKUP-<class> 設定を追加します。
設定は、スタンザのホスト、ソース、またはソースタイプに該当し、ルックアップ・テーブル
内のフィールドに⼀致するフィールドがあるイベントにフィールドを出⼒します。以下の構⽂に従ってくだ
さい。
LOOKUP-<class>
[<spec>]
LOOKUP-<class> = $TRANSFORM <match_field_in_table> OUTPUT|OUTPUTNEW <output_field_in_table>
$TRANSFORM：ルックアップ・テーブルを定義している transforms.conf
スタンザを参照します。
テーブル内の各列が、フィールドと可能な値を表しています。この変数
は、props.conf スタンザと同じホスト、ソース、またはソースタイプを持つイベント内のフィールドと照合
する、CSV テーブルの列です。
output_field_in_table：イベントに追加する、ルックアップ・テーブル内の列です。出⼒フィールドの既存の
値を上書きしない場合は、OUTPUTNEW を使⽤します。
match_field_in_table：CSV テーブル内の各列が、フィールドと可能な値を表しています。この変数
は、props.conf スタンザと同じホスト、ソース、またはソースタイプを持つイベント内のフィールドと照合
する、CSV テーブルの列です。
output_field_in_table：イベントに追加する、ルックアップ・テーブル内の列です。
match_field_in_table：CSV
ルックアップのどちら側にも、複数のフィールドを使⽤できます。たとえば、$TRANSFORM <match_field1>,
<match_field2> OUTPUT|OUTPUTNEW <match_field3>, <match_field4> と指定できます。また、1 つの⼀致したフィー
ルドが 2 つの出⼒フィールドを返す、または 3 つの⼀致したフィールドが 1 つの出⼒フィールドを返すよ
うに指定することもできます。
OUTPUT|OUTPUTNEW
句を含めない場合、ルックアップ・テーブルからイベントにすべてのフィールド名と値が追
加されます。
ルックアップテーブル内のフィールド名とイベント内のフィールド名が⼀致しない、またはイベント内の
フィールド名を変更したい場合は、AS 句を使⽤します。
[<stanza name>]
LOOKUP-<class> = $TRANSFORM <match_field_in_table> AS <match_field_in_event>
OUTPUT|OUTPUTNEW <output_field_in_table> AS <output_field_in_event>
注意： 単⼀の props.conf スタンザ内に複数の LOOKUP-<class> 設定を指定することができます。各ルックアップに
は、独⾃のルックアップ名を設定する必要があります。たとえば、複数のルックアップがある場合、それらに
LOOKUP-table1、LOOKUP-table2 などのように名前を設定することができます。
ステップ 3 - Splunk Enterprise の再起動
設定ファイルに対して⾏った変更は、Splunk Enterprise を再起動するまで反映されません。
⾃動ルックアップを設定した場合、再起動後にフィールド・サイドバー には、ルックアップ・テーブルからの
output フィールドが記載されます。ここから、⼀致するサーチ結果に表⽰するフィールドを選択することができま
す。
CSV ルックアップの例
この例は、access_combined ログ内の HTTP ステータス・コード⽤のルックアップを設定する⽅法について説明し
ています。この例で、イベント内の status フィールドをルックアップ・テーブル http_status.csv 内の status 列と
照合するルックアップを設計します。それで、対応する status_description および status_type フィールドをイベン
トに出⼒するルックアップを作成できます。
http_status.csv
ファイルのテキストを以下に⽰します。
73
status,status_description,status_type
100,Continue,Informational
101,Switching Protocols,Informational
200,OK,Successful
201,Created,Successful
202,Accepted,Successful
203,Non-Authoritative Information,Successful
204,No Content,Successful
205,Reset Content,Successful
206,Partial Content,Successful
300,Multiple Choices,Redirection
301,Moved Permanently,Redirection
302,Found,Redirection
303,See Other,Redirection
304,Not Modified,Redirection
305,Use Proxy,Redirection
307,Temporary Redirect,Redirection
400,Bad Request,Client Error
401,Unauthorized,Client Error
402,Payment Required,Client Error
403,Forbidden,Client Error
404,Not Found,Client Error
405,Method Not Allowed,Client Error
406,Not Acceptable,Client Error
407,Proxy Authentication Required,Client Error
408,Request Timeout,Client Error
409,Conflict,Client Error
410,Gone,Client Error
411,Length Required,Client Error
412,Precondition Failed,Client Error
413,Request Entity Too Large,Client Error
414,Request-URI Too Long,Client Error
415,Unsupported Media Type,Client Error
416,Requested Range Not Satisfiable,Client Error
417,Expectation Failed,Client Error
500,Internal Server Error,Server Error
501,Not Implemented,Server Error
502,Bad Gateway,Server Error
503,Service Unavailable,Server Error
504,Gateway Timeout,Server Error
505,HTTP Version Not Supported,Server Error
1. ファイル http_status.csv を、$SPLUNK_HOME/etc/apps/search/lookups/ に保管します。これは、ルックアップがサー
チ App 固有のものであることを表しています。
2. $SPLUNK_HOME/etc/apps/search/local にある
transforms.conf
ファイルに、以下の項⽬を設定します。
[http_status]
filename = http_status.csv
3. $SPLUNK_HOME/etc/apps/search/local/ にある
props.conf
ファイルに、以下の項⽬を設定します。
[access_combined]
LOOKUP-http = http_status status OUTPUT status_description, status_type
4. Splunk Enterprise を再起動します。
これで、access_combined ソースタイプの Web アクセス情報を返すサーチを実⾏すると、フィールドサイドバーメ
ニューに status_description および status_type が表⽰されるようになります。http_status 値を持つすべてのイベン
トが、ルックアップにより対応する status_description および status_type のフィールド/値のペアを取得します。
外部ルックアップの例
ここでは、Splunk Enterprise に⽤意されている外部ルックアップの例を説明していきます。DNS サーバーから
の情報を照合します。props.conf コンポーネントがないため、⾃動ルックアップではありません。これを利⽤する
には、[[Documentation:Splunk:SearchReference:Lookup|lookup コマンドを使⽤します。
Splunk Enterprise には、$SPLUNK_HOME/etc/system/bin/ に DNS ルックアップスクリプト
されています。
74
external_lookup.py
が⽤意
ホスト名を渡すと IP アドレスが返されます。
IP アドレスを渡すとホスト名が返されます。
Splunk には、$SPLUNK_HOME/etc/system/default/transforms.conf にこのスクリプトの設定も⽤意されています。
[dnslookup]
external_cmd = external_lookup.py clienthost clientip
fields_list = clienthost,clientip
デフォルトの transforms.conf の [dnslookup] スタンザを使⽤す
る、[[Documentation:Splunk:SearchReference:Lookup|lookup コマンドでサーチを実⾏することができます。
sourcetype=access_combined | lookup dnslookup clienthost AS host | stats count by clientip
このサーチは：
外部ルックアップ・テーブルの clienthost フィールドを、次の中にある host フィールドと照合します：イベ
ント</コード>
clienthost の⼀致に対応する各 clientip 値のカウントを提供するテーブルを返します。
このサーチでは、イベントにフィールドは追加されません。
受け取った各 IP アドレスのホスト値を返す、逆引きルックアップを実⾏するサーチを設計することができます。
sourcetype=access_combined | lookup dnslookup clientip | stats count by clienthost
この逆引きルックアップ・サーチに AS 句がないことに注⽬してください。これは、IP アドレスが⾃動的に
clientip として抽出されるからです。
外部ルックアップスクリプトの詳細
外部ルックアップスクリプトは、⼀部が空の CSV ファイルを受け取り、それに記⼊した CSV ファイルを出⼒す
る必要があります。スクリプトに渡す引数は、これらの⼊出⼒ファイルのヘッダーになります。
上記の DNS ルックアップの例では、CSV ファイルには 2 つのフィールド「clienthost」と「clientip」が含まれ
ています。このスクリプトに渡すフィールドは、transforms.conf に external_cmd 属性を使って指定したフィールド
です。これらの引数を渡さないと、スクリプトからはエラーが返されます。
external_cmd = external_lookup.py clienthost clientip
以下のサーチ⽂字列を実⾏した場合：
... | lookup dnsLookup clienthost
これは Splunk Enterprise に以下のことを指⽰したことになります。
1.
2.
に次の項⽬として定義したルックアップ・テーブルを使⽤する： [dnsLookup]
フィールドの値を、外部コマンド・スクリプトに CSV ファイルとして渡す。CSV ファイルは以
下のようになります。
transforms.conf
clienthost
clienthost,clientip
work.com
home.net
これは、clienthost および clientip を列⾒出しとして持つ CSV ファイルですが、clientip の値はありません。ス
クリプトには、2 つのヘッダーが含まれています。これらは、デフォルトの transforms.conf の [dnslookup] スタン
ザに fields_list 属性で指定しているフィールドです。
スクリプトは、以下のような CSV ファイルを出⼒し、それを Splunk Enterprise に返します。Splunk
Enterprise は、結果の clientip フィールドを設定します。
host,ip
work.com,127.0.0.1
home.net,127.0.0.2
注意： スクリプトを作成する際に、外部リソース (ファイルなど) を参照する場合は、スクリプトが存在するディ
レクトリからの相対パスで指定する必要があります。
ルックアップ設定⽤のオプションのフィールド照合ルール
これらの属性は、ルックアップ⽤のフィールド照合ルールを提供しています。これらは、3 種類のルックアップ・
タイプすべてに適⽤できます。ルックアップの transforms.conf スタンザに追加してください。
タ
75
属性
イ
プ
説明
デフォルト
max_matches
イベントからルックアップ・テーブルへの各値⼊⼒に対して可
能な最⼤⼀致数。範囲は 1〜1000です。time_field 属性が指定
されていない場合、ファイルの順序で最初の <integer> エントリ
整 が使⽤されます。time_field 属性が指定されている場合 (時間的
数 なルックアップのため)、時間の降順で最初の <integer> エント
リが使⽤されます。つまり、最⾼ <max_matches> 件までの⼀致が
許可されます。この値を超えた場合、ルックアップ値にもっと
も近い⼀致を使⽤します。
min_matches
イベントからルックアップ・テーブルへの各値⼊⼒に対して可
整 能な最低⼀致数。Splunk Enterprise が与えられた⼊⼒に対し
数 て min_matches 件未満しか⾒つからなかった場合に
は、default_match を使⽤することができます。
default_match
⽂ min_matches が 0 より⼤きく、Splunk Enterprise が⼊⼒に対し
字 て min_matches 件未満しか発⾒できなかった場合、min_matches の 空⽂字列
列 閾値に達するまでこの default_match 値が提供されます。
case_sensitive_match
真 (True) を設定すると、ルックアップ・テーブル内のすべての
論
フィールドに対して⼤⽂字⼩⽂字を区別した照合を実施しま
理
True
値 す。偽 (False) を設定すると、ルックアップ・テーブルの
フィールド照合時に⼤⽂字⼩⽂字は区別されません。
match_type
カンマ/スペース区切りリストに記載した 1 つまたは複数の
フィールドの、不完全照合を許可します。形式は match_type =
⽂ <match_type>(<field_name1>, <field_name2>,...<field_nameN>) で
EXACT (指定する必要
字
す。ワイルドカード照合を適⽤するには、match_type に WILDCARD はありません)
列
を、CIDR 照合 (IP アドレス⽤) を適⽤する場合はこれに CIDR
を設定します。
属性が指
定されていない場合
は、1000 が使⽤さ
れます。time_field
属性が指定されてい
る場合は、1 が使⽤
されます。
time_field
時間的ではない、ま
たは時間的なルック
アップの両⽅で、0
が使⽤されます。こ
の場合、⼀致が⾒つ
からなかった場合
は、イベントには何
も出⼒されません。
時間的なルックアップの設定
ルックアップ・テーブルに時間を表すフィールドがある場合、それを使った時間的なルックアップ (時間ベースの
ルックアップ) を作成することができます。時間的なルックアップとして、3 種類のルックアップ・タイプすべて
を設定することができます。
時間的なルックアップを作成するには、transforms.conf のルックアップ・スタンザに以下の⾏を追加します。
time_field = <field_name>
time_format = <string>
time_field
属性がある場合、デフォルトは
max_matches = 1
で、降順で最初に⼀致した項⽬が適⽤されます。
strptime() フォーマットの time_field を指定するには、time_format キーを使⽤します。time_formatデフォルトは
%s.%Q または UTC の UNIX エポック秒 (必要に応じてミリ秒も) です。
注意： Splunk Enterprise では、⼀部の⾮標準⽇時 strptime() フォーマットを使⽤できます。たとえば、ISO
8601 タイムスタンプを定義する場合、time_format = '%s.%Q' を使⽤することができます。ここで、%s は秒を、%Q
はミリ秒を表しています。これらの追加設定の詳細は、『データの取り込み』マニュアルの「タイムスタンプ認識
の設定」にある「拡張 strptime() サポート」を参照してください。
時間的なルックアップで照合を⾏うためには、最⼩/最⼤時間量のオフセットも指定する必要があります。このた
めには、スタンザに以下の⾏を追加します。
max_offset_secs = <integer>
min_offset_secs = <integer>
デフォルトでは、最⼤オフセットはありません。デフォルトの最⼩オフセットは 0 です。
時間的なルックアップの例
この例では、DHCP ログを使って、IP アドレスとタイムスタンプに基づいて、ネットワーク上のユーザーを識別
する⽅法を⾒ていきます。DHCP ログがファイル dhcp.csv に保存されている場合を考えてみましょう。このファ
イルには、タイムスタンプ、IP アドレス、およびユーザー名と MAC アドレスが含まれています。
1. transforms.conf ファイルに、以下の項⽬を指定します。
[dhcpLookup]
filename = dhcp.csv
time_field = timestamp
76
time_format = %d/%m/%y %H:%M:%S
2. props.conf ファイルに、以下の項⽬を指定します。
[dhcp]
LOOKUP-table = dhcpLookup ip mac OUTPUT user
3. Splunk Enterprise を再起動します。
サーチ結果を使ったルックアップテーブルの設定
ローカルまたは App 固有の
ことができます。
savedsearches.conf
を編集して、レポートの結果をルックアップテーブルに設定する
サーチが結果を返すレポートのスタンザで、以下の作業を⾏います。
1. ックアップ設定アクションを有効にするために、以下の⾏を追加します。
action.populate_lookup = 1
これにより、結果テーブルが CSV ファイルに保存されます。
2. ルックアップテーブルのコピー場所を指⽰するために、以下の⾏を追加します。
action.populate_lookup.dest = <string>
の値は transforms.conf のルックアップ名、またはサーチ結果をコピーした CSV ファイ
ルへのパスになります。CSV ファイルへのパスを指定する場合、パスは $SPLUNK_HOME からの相対パスで指
定します。
action.populate_lookup.dest
たとえば、グローバルルックアップテーブルに結果を保存する場合は、以下のように指定します。
action.populate_lookup.dest = etc/system/lookups/myTable.csv
宛先ディレクトリ $SPLUNK_HOME/etc/system/lookups または
いなければなりません。
$SPLUNK_HOME/etc/<app_name>/lookups
は、すでに存在して
3. Splunk Enterprise 起動時にこのサーチを実⾏する場合は、以下の⾏を追加します。
run_on_startup = true
起動時に実⾏しない場合は、次回のスケジュール時刻に実⾏されます。ルックアップ・テーブルを設定するスケ
ジュール済みサーチに対しては、run_on_startup = true を設定することをお勧めします。
レポートの結果は CSV ファイルにコピーされるため、このルックアップは CSV ルックアップと同じ⽅法で設定
することができます。
ルックアップのトラブルシューティング - ルックアップスタンザで同⼀の名前を使⽤
props.conf
で異なる
ます。
で、テーブル定義は LOOKUP-<class> 属性を使って指定されます。すべての props.conf ルックアップ定義
名を使⽤することをお勧めします。そうすることで、問題が発⽣する可能性を減らすことができ
<class>
複数のルックアップに同じ
能性があります。
<class>
名前を指定すると、その意味を正しく理解していない限り、問題が発⽣する可
同名の複数のルックアップが同じ props.conf スタンザを共有している場合 (同じホスト、ソース、または
ソースタイプ)、fields.conf のそのスタンザ内の最初のルックアップが、他のルックアップに優先されます。
同じホスト、ソース、またはソースタイプを持つルックアップには、異なる名前を使⽤する必要がありま
す。
異なるホスト、ソース、またはソースタイプを持ち、同じ名前を共有するルックアップがある場合、その時
点でそれらのいずれか 1 つのみが適⽤されることになります。故意にそのような設定を⾏うこともできます
が、たいていの場合そのような設定は不便になるだけです。
たとえば、名前が「LOOKUP-table」の以下の 2 つのルックアップがある場合を考えてみましょう。
[host::machine_name]
LOOKUP-table = logs_per_day host OUTPUTNEW average_logs AS logs_per_day
[sendmail]
LOOKUP-table = location host OUTPUTNEW building AS location
これらの 2 つのルックアップが重複するイベントでは、⽚⽅のみが適⽤されます。別の⾔い⽅をすると：
77
ホストが⼀致したイベントは、ホスト (host) ルックアップが適⽤されます。
ソースタイプが⼀致したイベントは、ソースタイプ (sourcetype) ルックアップが適⽤されます。
両⽅が⼀致したイベントは、ホスト (host) ルックアップが適⽤されます。
ルックアップ名を LOOKUP-table のように指定した場合、それは「table」により記述されている、⽬的またはアク
ションを実⾏するルックアップであることを表しています。この例で、これらのルックアップはそれぞれ異なる⽬
的で使⽤されます。あるルックアップは 1 ⽇あたりのログに関する情報を判断し、別のルックアップは場所に関
する処理に使⽤しています。名前を以下のように変更します。
[host::machine_name]
LOOKUP-table = logs_per_day host OUTPUTNEW average_logs AS logs_per_day
[sendmail]
LOOKUP-location = location host OUTPUTNEW building AS location
これで、競合しない 2 つの異なる設定が完成しました。
KV ストア・ルックアップの設定
ルックアップは、イベント内に存在しているフィールドの値に基づいて、外部ソースからイベントにフィールドを
追加します。このトピックは、KV ストア・ルックアップについて説明しています。このルックアップは、App
キー・バリュー・ストア (KV ストア) のコレクションから抽出したフィールドを、イベントに設定します。KV ス
トア・ルックアップは、サーチ・コマンド lookup、inputlookup、および outputlookup を使⽤してのみ実⾏できま
す。KV ストア・ルックアップを⾃動ルックアップとして設定することはできません。
このトピックでは、props.conf にルックアップ・スタンザを指定することによる、KV ストア・ルックアップの設
定、管理⽅法について説明していきます。設定ファイルを利⽤すると、Splunk Web を使ってルックアップ・
ファイルを設定する場合よりも、ルックアップの設計と動作をよりきめ細かく調節することができます。
ファイルへのアクセス権がない場合、または可能な限り Splunk Web を使ってルックアップを管理したい場
合は、[設定] > [ルックアップ] のページで KV ストア・ルックアップを設定することができます。このマニュア
ルの「ルックアップを使ったイベントへの情報の追加」を参照してください。
.conf
また、次のようなルックアップを定義することもできます。
CSV ファイルから抽出したフィールドをイベントに設定する。
Python スクリプトまたはバイナリの実⾏形式ファイルを使って、外部ソースからのフィールド値をイベン
トに設定する。
このマニュアルの「CSV および外部ルックアップの設定」を参照してください。
KV ストア・コレクションについて
KV ストア・ルックアップを作成する前に、collections.conf に KV ストア・コレクションを最低 1 つ定義する必
要があります。Splunk 開発者向けポータルの「Use configuration files to create a KV store collection」を参
照してください。
KV ストア・コレクションは、データベースと似ているデータ⽤のコンテナです。これには、データがキー/値の
ペアとして表⽰されます。KV ストア・ルックアップを作成する場合、コレクションには最低 2 つのフィールドが
必要になります。それらのフィールドの 1 つは、イベント・データ内のフィールドに所属するものを含む、⼀連
の値を持つ必要があります。KV ストアのフィールドが、イベント内のフィールドと同じ名前を持つ必要はありま
せん。各 KV ストアのフィールドは、複数値 にすることができます。
注意： KV ストア・コレクションは、サーチヘッド上で有効になっていますが、CSV ファイルはインデクサーに
複製されます。ルックアップ・データが頻繁に変化する場合、同じような CSV ルックアップよりも KV ストア・
ルックアップの⽅がパフォーマンスが向上することがあります。
transforms.conf への KV ストア・ルックアップ・スタンザの定義
KV ストア・ルックアップは、イベント内のフィールドを、Splunk Enterprise が KV ストア・コレクション内に
保管したフィールドと照合します。KV ストア・ルックアップは、サーチ・コマンド lookup、inputlookup、および
outputlookup を使⽤してのみ実⾏できます。KV ストア・ルックアップを⾃動ルックアップとして設定することは
できません。
KV ストア・ルックアップのスタンザは、ルックアップ・テーブルとして使⽤する必要に応じて、フィールド照合
ルールや時間的ルックアップ⽤のルールを指定することもできます。
グローバルにKV ストアのルックアップを利⽤できるようにする場合は、$SPLUNK_HOME/etc/system/local/ にある
transforms.conf にルックアップ・スタンザを追加します。特定の App でのみルックアップを利⽤できるようにす
る場合は、$SPLUNK_HOME/etc/apps/<app_name>/local/ にある transforms.conf にルックアップ・スタンザを追加しま
す。
警告： $SPLUNK_HOME/etc/system/default 内の設定ファイルは編集しないでください。
KV ストア・ルックアップのフォーマット
transforms.conf
に KV ストア・ルックアップ・スタンザを追加する場合、以下のフォーマットに従う必要がありま
す。
78
[<lookup_name>]
external_type = kvstore
collection = <string>
fields_list = <string>
は、ルックアップの名前です。
は、KV ストア・ルックアップを定義する場合、kvstore に設定する必要があります。
collection は、ルックアップに関連する、KV ストア・コレクション名でなければなりません。
fields_list は、KV ストア・ルックアップがサポートしているフィールドの、カンマ/スペース区切りリスト
です。
[<lookup_name>]
external_type
注意： KV ストア・ルックアップで内部 _key ID フィールドを使⽤する場合、fields_list のフィールドのリストに
_key を追加します。KV ストア・ルックアップ・スタンザには、必要に応じて以下のような属性を設定することが
できます。
フィールド/値照合ルールを定義する。「ルックアップ⽤のオプションのフィールド照合ルール」を参照して
ください。
時間的な KV ストア・ルックアップを定義する (時間ベースのルックアップ)。「時間的なルックアップの設
定」を参照してください。
KV ストア・ルックアップの設定
1. collections.conf に KV ストア・コレクションを定義します。Splunk 開発者向けポータルの「Use
configuration files to create a KV store collection」を参照してください。
2. 前述の構⽂に従って、transforms.conf に KV ストア・ルックアップ・スタンザを作成します。
3. .conf ファイルへの変更内容を保存します。
4. システムにルックアップを追加するために、Splunk Enterprise を再起動します。
KV ストア・ルックアップの例
ここでは、KV ストア・ルックアップ employee_info の例を取り上げていきます。これ
は、$SPLUNK_HOME/etc/system/bin/ にあります。
[employee_info]
external_type = kvstore
collection = kvstorecoll
fields_list = _key, kvs_id, kvs_name, kvs_street, kvs_city, kvs_zip
ルックアップはイベント内の従業員 ID を取得し、それに対応する従業員名、市、番地、郵便番号な
どの従業員情報をイベントに出⼒します。このルックアップは、KV ストア・コレクション kvstorecoll と連携し
ます。
employee_info
サーチ・コマンドと KV ストア・ルックアップ
KV ストア・ルックアップ・スタンザを保存して Splunk を再起動したら、サーチ・コマンドを使って新しい KV
ストア・ルックアップを利⽤できます。
KV ストア・コレクション内の値とサーチ結果のフィールド値を照合し、対応するフィールド値をそれらの結果に
出⼒するには、lookup を使⽤します。このサーチは、先ほどの使⽤事例で定義した employee_info ルックアップを
使⽤します。
... | lookup employee_info kvs_id AS id OUTPUT kvs_name AS name | ...
これは、kvstorecoll 内の従業員 ID 値とイベント内の従業員 ID 値を照合して、イベントに対応する従業員名の値
を出⼒します。
サーチ・コマンドを使って、KV ストア・コレクションのコンテンツに対してサーチを実⾏できます。
『サーチ・リファレンス』の inputlookup に関するトピックを参照してください。
inputlookup
サーチ・コマンドを使って、サーチ・パイプラインからの結果を KV ストア・コレクションに書き込
めます。『サーチ・リファレンス』の outputlookup に関するトピックを参照してください。
outputlookup
Splunk Web を使ったワークフローアクションの作成と管理
ワークフローアクションを使って、インデックスフィールドまたは抽出されたフィールドと他の Web リソース間
のやり取りを有効にすることができます。ワークフローアクションは多彩な⽤途に⽤いられます。たとえば、以下
のようなワークフローを定義することができます。
イベント内に⾒つかった IP アドレスに基づいて、外部 WHOIS ルックアップを実⾏する。
HTTP エラーイベント内のフィールド値を使って、外部問題管理システム内に新しいエントリを作成する。
イベント内に⾒つかった特定のフィールドの値で、外部検索 (Google など) を実⾏する。
79
選択したイベントの 1 つまたは複数のフィールド値を使⽤して、⼆次サーチを実⾏する。
他にも、以下のようなワークフローアクションを定義できます。
特定のフィールドまたはフィールドセットを含む、または特定のイベントタイプに所属するイベントをター
ゲットにする。
サーチ結果のフィールドメニューまたはイベントメニューに表⽰する。特定のフィールドのメニュー、また
は特定のイベントのすべてのフィールドメニューに表⽰するように設定することもできます。
選択した場合に、現在のウィンドウまたは新たなウィンドウに表⽰する。
Splunk Web を使ったワークフローアクションの定義
この章の始めに記載したようなワークフローアクションやその他のワークフローアクションはすべて、Splunk
Web を使って設定することができます。まず、[設定] > [フィールド] > [ワークフローアクション] に移動し
ます。[ワークフローアクション] ページでその名前をクリックすると、既存のワークフローアクションをレ
ビュー、更新することができます。[新規追加] をクリックして、新しいワークフローアクションを作成すること
もできます。どちらの場合も、ワークフローアクションの詳細ページが表⽰されます。このページでは、個別の
ワークフローアクションを定義することができます。
新たなワークフローアクションを作成する場合は、[名前] と [宛先 App] を指定する必要があります。
3 種類のワークフローアクションを設定することができます。
GET ワークフローアクション ：特定の値の Google 検索の実⾏、外部 WHOIS データベースへのドメイ
ン名の照会などを実⾏するための、⼀般的な HTML リンクを作成します。
POST ワークフローアクション ：指定した URI への HTTP POST リクエストを⽣成します。このタイプ
では、⼀連の関連するフィールド値を使って、外部問題管理システム内のエントリを作成するなどの作業を
⾏えます。
サーチワークフローアクション ：指定した時間範囲の、インデックス内の特定の ipaddress と http_status
の組み合わせを探すサーチなど、イベントの特定のフィールド値を使って⼆次サーチを実⾏します。
特定のイベントグループへのワークフローアクションのターゲット設定
Splunk Web でワークフローアクションを作成する場合、必要に応じて特定のイベントグループをワークフロー
アクションのターゲットにすることができます。ワークフローアクションの適⽤範囲は、フィールド、イベントタ
イプ、または両者を組み合わせて制限することができます。
フィールドによるワークフローアクション適⽤範囲の制限
特定のフィールドまたは⼀連のフィールドを持つイベントにのみ、ワークフローを適⽤することができます。たと
えば、http_status フィールドを持つイベントにのみワークフローアクションを適⽤したい場合は、[次のフィール
ドにのみ適⽤] 設定に http_status を指定します。
⼀連のフィールドセットを持つイベントにのみワークフローアクションを適⽤する場合は、[次のフィールドにの
み適⽤] にそれらのフィールドをカンマで区切って指定します。複数のフィールドが指定されている場合は、イベ
ント内にすべてのフィールドが存在する場合にのみ、ワークフローアクションが表⽰されます。
たとえば、ip_client および ip_server フィールドを持つイベントにのみ、ワークフローアクションを定義する場合
を考えてみましょう。そのためには、[次のフィールドにのみ適⽤] に「ip_client, ip_server」と⼊⼒します。
ワークフローアクションのフィールド指定による適⽤制限には、ワイルドカードのアスタリスクを使⽤することも
できます。たとえば、単純に「ip_*」と指定すると、ip_client または ip_server、またはその両⽅を持つイベント
(および他の ip_* に⼀致するフィールドを持つ任意のイベント) に対してワークフローアクションが適⽤されま
す。
デフォルトでは * が指定されていると仮定されます。この場合、すべてのフィールドが⼀致になります。
より複雑な設定を⾏う必要がある場合は、フィールドの代わりに、またはフィールドと組み合わせて、イベントタ
イプによる適⽤制限を設定します。
イベントタイプによるワークフローアクション適⽤範囲の制限
イベントタイプによる適⽤範囲の制限は、フィールドの場合と同じように機能します。[次のイベントタイプにの
み適⽤] には、単⼀のイベントタイプまたはカンマで区切って複数のイベントタイプを指定して、指定した 1 つ
または複数のイベントタイプに所属するイベントにのみ、ワークフローアクションを適⽤することができます。ま
た、ワイルドカードを使って、それに該当するイベントタイプに所属するイベントにのみ適⽤することもできま
す。
フィールドとイベントタイプを組み合わせて適⽤範囲を制限することもできます。たとえば、http_status フィー
ルドがあるけれども、http_status が 500 以上の場合にのみ、そのフィールドを含むイベントにワークフローアク
ションを表⽰したい場合を考えてみましょう。そのためには、まずイベントタイプ errors_in_500_range を設定しま
す。このイベントタイプは次のようなサーチに⼀致するイベントに適⽤されます：
http_status >= 500
次に、[次のフィールドにのみ適⽤] に「http_status」を、[次のイベントタイプにのみ適⽤] に
「errors_in_500_range」を設定します。
イベントタイプの詳細は、このマニュアルの「イベントタイプについて」を参照してください。
フィールドおよびイベントメニューへのワークフローアクションの表⽰設定
80
ワークフローアクションを正しく設定すると、サーチ結果のフィールドやイベントに関連するメニューにそれが表
⽰されます。ワークフローアクションはイベントレベル (イベント全体に適⽤)、フィールドレベル (イベント内の
特定のフィールドに適⽤)、またはその両⽅に設定することができます。
イベントレベルのワークフローアクションを選択するには：
サーチを実⾏します。
[イベント] タブに移動します。
サーチ結果内のイベントを展開して、[イベントアクション] をクリックします。
イベントレベルのワークフローアクション「Show Source」の例を以下に⽰します。クリックすると、raw サー
チデータ内のイベントのソースが表⽰されます。
代わりに、ワークフローアクションを、イベント内のフィールドの [アクション] メニューに表⽰することもでき
ます。選択されたフィールドと値に対して、別のウィンドウに Google サーチを表⽰するワークフローアクション
の例を以下に⽰します。
これらの例のワークフローアクションは両⽅とも「GET」リンクメソッドを使⽤しています。これは、Splunk
Enterprise に実装できる 3 種類のワークフローアクションの中の 1 つです (他の 2 つは「POST」リンクワーク
フローアクションとサーチワークフローアクションです)。3 種類すべてを利⽤するには、該当する説明を参照し
てください。
イベントレベルとフィールドレベルの両⽅に表⽰するワークフローアクションを定義することもできます。たとえ
ば、User_ID などの、イベント内の特定のフィールドの値に対して処理を⾏うワークフローアクションを定義する
ことができます。
GET ワークフローアクションの設定
GET リンクワークフローは、HTML リンクに 1 つまたは複数の値を渡します。リンクをクリックすると、ブラウ
ザで HTTP GET リクエストが実⾏され、情報が外部検索エンジンや IP ルックアップサービスなどの外部 Web
リソースに渡されます。
GET ワークフローアクションを定義するには、詳細ページで [アクションタイプ] に「リンク」を、[リンク⽅
法] に「GET」を設定します。次に、適切な [ラベル] と [URI] を定義します。
注意： URI 経由で GET アクションに渡される変数は、伝送時に⾃動的に URL にエンコードされます。この場
合、単語や区切り⽂字の間にスペースがある値を含めることができます。ただし、HTTP アドレスを値として持つ
フィールドを使⽤し、フィールド値全体を URI として渡す場合は、フィールド値がエスケープ処理されないよう
に、$! プリフィックスを使⽤する必要があります。詳細は、後述する「URL または HTTP フォームフィールド値
のエスケープ処理を防⽌するための $! プリフィックスの使⽤」を参照してください。
サーチ結果の topic フィールドの値に基づいて、Google 検索を実⾏する GET リンクワークフローの設定例を以
下に⽰します。
81
[ラベル] フィールドには、フィールド/イベントメニューに表⽰するテキストを指定します。静的なラベル、また
は関連フィールドの値を⼊れることができます。たとえば、イベント内に topic フィールドが存在しており、その
値を Google ワークフローアクションに⼊れたい場合は、[ラベル] に Google $topic$ を設定します。
上記の例で、イベント内の topic が CreatefieldactionsinSplunkWeb の場合、topic フィールドメニューにワークフ
ローアクションが「Google CreatefieldactionsinSplunkWeb」と表⽰されます。
[URI] フィールドには、フィールド値を送信する外部リソースの場所を指定します。[ラベル] 設定と同様に、
フィールドの値を指定する場合は、フィールド名をドル記号で囲みます。上記の例で、この URI は GET メソッ
ドを使って topic の値を Google に渡して検索を⾏います。
ワークフローアクションをイベントメニューに表⽰するか、フィールドメニューに表⽰するか、または両⽅に表⽰
するかを指定することができます。また、リンクを現在のウィンドウに表⽰するか、または新しいウィンドウに表
⽰するかを指定することもできます。
また、特定のイベントセットにのみワークフローアクションを適⽤することも可能です。ワークフローアクション
を、特定のフィールドセットを持っているイベントのみに表⽰することも、特定のイベントタイプ (または複数の
イベントタイプ) に所属するイベントに表⽰することも可能です。
例 - 外部 IP ルックアップの設定
あなたは Web サービス・ログ内のドメイン名を抽出して、それを domain フィールドに指定するように Splunk
Enterprise App を設定しました。外部の WHOIS データベースをサーチして、それらのドメインの詳細な情報を
取得したいと考えています。
ここでは、これを実現するための GET ワークフローアクションの設定⽅法について⾒ていきます。
ワークフローアクションの詳細ページで [アクションタイプ] に「リンク」を、[リンク⽅法] に「GET」を設定
します。
次に、[ラベル] および [URI] フィールドを使って、⽬的のフィールドを指定します。[ラベル] に、「WHOIS:
$domain$」を設定します。[URI ] に「http://whois.net/whois/$domain$」を設定します。
その後、以下の事項を決定します。
リンクをフィールドメニューに表⽰するか、イベントメニューに表⽰するか、または両⽅に表⽰するか。
リンクをクリックした時に WHOIS サーチを同じウィンドウに表⽰するか、または新たなウィンドウに表⽰
するか。
ワークフローアクションリンクを表⽰するイベントを制限するかどうか。ワークフローアクションのター
ゲットを、特定のフィールドを持つイベント、特定のイベントタイプに属するイベント、または両者の組み
合わせなどで制限することができます。
POST ワークフローアクションの設定
POST ワークフローアクションは、GET リンクアクションと同じように設定することができます。ワークフロー
アクションの詳細ページで、[アクションタイプ] に「リンク」を、[リンク⽅法] に「POST」を、[ラベル] と
[URI] にはそれぞれ適切な値を指定します。
ただし、⼀般的に POST リクエストは HTML 内の form エレメントとして定義され、⼀部の⼊⼒が POST の引数
に変換されます。そのため、指定した URI に送信する POST 引数を指定する必要があります。
82
注意： URI 経由で POST アクションに渡される変数は、伝送時に⾃動的に HTTP 形式 にエンコードされます。
この場合、単語や区切り⽂字の間にスペースがある値を含めることができます。ただし、HTTP アドレスを値とし
て持つフィールドを使⽤し、フィールド値全体を URI として渡す場合は、フィールド値がエスケープ処理されな
いように、$! プリフィックスを使⽤する必要があります。詳細は、後述する「URL または HTTP フォームフィー
ルド値のエスケープ処理を防⽌するための $! プリフィックスの使⽤」を参照してください。
これらの引数は、POST リクエストに応答する Web リソースに送信されるキーと値の組み合わせです。引数の
キーと値の両⽅に対して、フィールド名をドル記号で囲んで、リソースに送信するイベントのフィールド値を指定
することができます。1 つの POST ワークフローアクション内に複数のキー/値のペアを定義することができま
す。
例 - http エラーを使った問題追跡アプリケーション内のエントリの作成
Web サービスログの HTTP ステータスコードを抽出して、http_status フィールドに設定することができます。⼀
般的にイベントには、http_status フィールドとともに、標準の 1 ⾏の記述リクエスト、またはエラーを⽣成する
python プロセスからの複数⾏の python スタックトレースが含まれます。
ここでは、http_status が 500 番台のエラーイベントに対してのみ表⽰されるワークフローアクションを作成しま
す。ワークフローアクションには、関連する python スタックトレースと HTTP ステータスコードを、外部問題
管理システムに送信して、新たなバグレポートを⽣成させます。ただし、問題管理システムは、特定のエンドポイ
ントへの POST リクエストしか受け付けません。
ここでは、以上の要件を満たす POST ワークフローアクションの設定⽅法を以下に⽰します。
最初の POST 引数は、server error $http_status$ を外部問題追跡システムの title フィールドに送信しま
す。http_staus が 500 のイベントに対してこのワークフローアクションを設定した場合、問題追跡システムに
server error 500 と⾔うタイトルの問題が設定されます。
2 番⽬の POST 引数は、_raw フィールドを使って新しい問題の
タックトレースを設定します。
description
フィールドに、複数⾏の python ス
最後に、ワークフローアクションは、errors_in_500_range イベントタイプに所属するイベントに対してのみ適⽤さ
れるように設定されていることに注意してください。これは、典型的な HTTP エラー 500 番台以上の http_error
値を保有しているイベントにのみ適⽤されるイベントタイプです。500 番台未満の HTTP エラーコードを持つイ
ベントのイベント/フィールドメニューには、「submit error report」ワークフローアクションは表⽰されませ
ん。
イベントからのフィールド値を動的に記⼊する⼆次サーチの設定
動的に設定した⼆次サーチを起動するワークフローアクションを設定するには、まずワークフローアクションの詳
細ページで [アクションタイプ] に「サーチ」を設定します。これにより、特定の⼆次サーチの定義に使⽤できる
83
⼀連のサーチ設定 フィールドが表⽰されます。
[サーチ⽂字列] に、フィールド値のプレースホルダを含む 1 つまたは複数のサーチ⽂字列をドル記号で囲んで指
定します。たとえば、イベントに登場するクライアント IP をサーチするワークフローアクションを設定する場
合、そのフィールドには単に clientip=$clientip$ と⼊⼒します。
サーチを実⾏する App を指定します。現在のビュー以外の App でサーチを実⾏する場合は、そのビューを選択
します。すべてのワークフローアクションと同様に、現在のウィンドウに表⽰するか、または新たなウインドウに
表⽰するかを指定することもできます。
[もっとも早い時間] および [もっとも遅い時間] フィールドに相対時間範囲を指定して、サーチの時間範囲を忘れ
ずに設定 (またはフィールドリストを作成したのと同じ時間範囲を使⽤) してください。これらのフィールドが空
欄の場合は、デフォルトではすべての時間に対してサーチが実⾏されます。
最後に、他のワークフローアクションタイプと同様に、ワークフローアクションを特定のフィールドセットを持
つ、または特定のイベントタイプに属するイベントにのみ適⽤することができます。
例 - 特定の Ruby On Rails コントローラに起因するエラーを探すサーチの実⾏
Ruby On Rails を利⽤した Web インフラを使⽤している場合を考えてみましょう。Ruby コントローラに関する
エラーのみを分類するイベントタイプを設定しましたが (controller_error)、特定のコントローラに関連するエラー
のみを表⽰したい場合もあります。ここでは、以下の処理を⾏うワークフローアクションの設定⽅法を⾒ていきま
す。
1. ワークフローアクションの詳細ページで、[ラベル] に次の値を指定したアクションを設定します：See
errors for controller $controller$ over past 24h。
other
2. [アクションタイプ] に「サーチ」を設定します。
3. [サーチ⽂字列] に次の⽂字列を⼊⼒します：
sourcetype=rails controller=$controller$ error=*
4. [もっとも早い時間] に「-24h」を設定します。[もっとも遅い時間] は空欄のままにしてください。
5. [次の〜にのみ適⽤] 設定を使⽤して、error および controller フィールドのみを保有する、controller_error イ
ベントタイプに所属するイベントにのみワークフローアクションを表⽰するように設定します。
これらは基本事項です。ワークフローアクションを実⾏する App やビューを設定したり (たとえば、この情報に
ついて ruby_errors と⾔うタイトルの専⽤のビューを⽤意できます)、現在のウィンドウでアクションを実⾏する
84
か、または新たなウィンドウを開いて実⾏するかを指定することができます。
ワークフローアクションでの特別なパラメータの使⽤
Splunk Enterprise には、「@」で始まるワークフローアクション⽤の特殊パラメータが⽤意されています。これ
らの特殊パラメータの中の 2 つはフィールドメニュー専⽤です。それらを利⽤して、対象イベント内のすべての
フィールドに適⽤するワークフローアクションを設定できます。
@field_name - クリックされたフィールド名を参照します。
@field_value - クリックされたフィールドの値を参照します。
その他の特殊パラメータを以下に⽰します。
@sid - イベントを返したジョブの SID を参照します。
@offset - ジョブのイベントのオフセットを参照します。
@namespace - ジョブがディスパッチされた名前空間を参照します。
@latest_time - 最後にイベントが発⽣した時⾦を参照します。類似のイベントを区別するために⽤いられ
ます。すべてのフィールドで常に利⽤できる訳ではありません。
例 - イベント内のすべてのフィールドに適⽤するワークフローアクションの作成
上記の Google 検索例 (GET リンクワークフローアクション) を更新して、適⽤するイベントの各フィールドの
フィールド名とフィールド値を検索できるようにすることができます。この場合は、タイトルを Google this field
and value に変更して、アクションの URI を http://www.google.com/search?q=$@field_name$+$@field_value$ に置換し
ます。
このワークフローアクションは、フィールドメニューに表⽰される任意のフィールド/値のペアを検索しま
す。sourcetype=access_combined のフィールドメニューを参照して、「Google this field and value 」フィール
ドアクションを選択すると、Google で「sourcetype accesscombined」が検索されます。
注意： @field_name や @field_value パラメータを使⽤するワークフローアクションは、イベントレベルの
メニューとは互換性がありません。
例 - イベントのソースの表⽰
このワークフローアクションは、他の特殊パラメータを使って raw データ内のイベントのソースを表⽰します。
[アクションタイプ] は [リンク]、[リンク⽅法] は [GET] を指定します。[タイトル] には、「Show source」を
指定します。[URI] は /app/$@namespace$/show_source?sid=$@sid$&offset=$@offset$&latest_time=$@latest_time$ です。
これは、_cd フィールドを持つイベントにのみ適⽤されます。
ご利⽤の App にワークフローアクションを設定し (まだインストールしていない場合)、どのように動作するのか
をご確認ください。
actions.conf を使ったワークフローアクションの設定
まもなく掲載予定。それまでの間は、Splunk Web を使ったワークフローアクションの設定と管理⽅法を参照し
てください。
データの正規化：タグとエイリアス
タグとエイリアスについて
データ内で、関連するフィールド値でイベントをグループ化している場合があります。特定のイベントデータグ
ループを効率的にサーチするために、フィールド値にタグを割り当てることができます。任意のフィールド/値の
組み合わせに、1 つまたは複数のタグを割り当てられます (イベントタイプ、ホスト、ソース、またはソースタイ
プを含む)。
以下の⽬的でタグを利⽤できます。
IP アドレスや ID 番号などの、抽象型フィールド値を追跡する 。たとえば、メインオフィスで
192.168.1.2 の IP アドレスを使⽤している場合があります。IPaddress の値にタグ「mainoffice」を設定す
れば、そのタグを使ってその IP アドレスを持つイベントをサーチできます。
1 つのタグを使って⼀連のフィールド値をグループ化することで 、簡単なコマンド 1 つでそれらのサー
チを⾏えます。たとえば、同じコンピュータに関連する 2 つのホスト名が存在していることがあります。こ
のような場合に、両⽅の値に同じタグを設定できます。そのタグをサーチすれば、両⽅のホスト名を持つイ
ベントが返されます。
特定の抽出されたフィールドに、それらの特徴をさまざまな観点から表した複数のタグを付ける こと
で、タグに基づくサーチを実⾏し、素早く⽬的の結果を探し出すことができます。これを理解するために、
以下の例をご覧ください。
例：
社内イントラネットのデータソースの IP アドレスを表す抽出されたフィールド IPaddress を考えてみましょう。
各 IP アドレスにその職務や場所に応じたタグを設定することで、IPaddress を有効活⽤することができます。ルー
ターの IP アドレスにタグ「router」を設定できます。また、各 IP アドレスに「SF」や「Building1」のような場
所に基づいたタグを設定することもできます。 サンフランシスコ (San Francisco) の建物 1 に存在するルーター
の IP アドレスには、タグ「router」、「SF」、および「Building1」が設定されます。
85
サンフランシスコの Building1 以外にあるすべてのルーターをサーチするには、以下のように指定します。
tag=router tag=SF NOT (tag=Building1)
Splunk Web でのフィールド値のタグとエイリアス設定
データ内で、関連するフィールド値でイベントをグループ化している場合があります。これらのフィールドのグ
ループを効率的にサーチするために、フィールド値にタグを割り当てることができます。抽出された任意のフィー
ルドに、1 つまたは複数のタグを割り当てられます (イベントタイプ、ホスト、ソース、またはソースタイプを含
む)。
詳細は、『ナレッジ管理』の「タグとエイリアスについて」を参照してください。
フィールド値のタグとエイリアスの設定⽅法
フィールド/値のペアにタグを設定することができます。また、フィールド名のエイリアスを設定することもでき
ます。
フィールド値のペアのタグ設定
Splunk Web を使って、サーチ結果から任意のフィールド値のペアに直接タグを設定できます。タグを設定した
いフィールド値のペアを持つ任意の結果イベントで、イベントの隣にある⽮印をクリックした後、[アクション]
下でそのフィールド値の隣にある⽮印をクリックして、次に [タグの編集] を選択します。タグを作成して、それ
を保存します。たとえば、syslog ソースタイプを選択すると、以下のように表⽰されます。
フィールド値のペアに対して [タグの編集] アクションを選択したら、[タグの作成] ウィンドウに 1 つまたは複数
のタグを追加できます。
注意： [タグ] に指定する値は、⼆重引⽤符で囲まないでください。
フィールド名のエイリアス設定
フィールド名に複数のエイリアスを設定したり、フィールドのエイリアスを使⽤して異なるフィールド名を正規化
したりできます。エイリアスを設定しても、元のフィールド名が変更されたり、削除されることはありません。
フィールドにエイリアスを設定したら、そのエイリアスを使ってサーチを実⾏することができます。フィールド名
のエイリアスを設定するには、props.conf にアクセスする必要があります。詳細は、『ナレッジ管理』の
「フィールドのエイリアスの作成」を参照してください。
タグ設定した値のサーチ
タグのサーチには 2 種類の⽅法があります。任意のフィールドの値に関連するタグをサーチする場合は、以下の
構⽂を使⽤できます。
tag=<tagname>
特定のフィールドの値に関連するタグをサーチする場合は、以下の構⽂を使⽤できます。
tag::<field>=<tagname>
ワイルドカードを使⽤したタグのサーチ
イベントタイプやタグを含め、キーワードやフィールド値をサーチする場合、ワイルドカード⽂字のアスタリスク
(*) を使⽤することができます。
たとえば、各種 IP アドレスに対して複数のイベントタイプタグがある場合 (IP-src や
指定してそれらのすべてをサーチすることができます。
86
IP-dst
など)、以下のように
tag::eventtype=IP-*
タグに「local」を含むすべてのホストを探す場合は、以下のようにタグをサーチします。
tag::host=*local*
タグのないイベントタイプを持つイベントをサーチする場合は、論理演算式を使⽤します。
NOT tag::eventtype=*
タグの無効化と削除
不要なタグがある場合、または特定のフィールドにタグを関連付けたい場合、タグを無効化または削除することが
できます。以下の作業を⾏えます。
サーチ App を使って、特定のフィールド値のタグ関連付けを削除する。
Splunk Web を使って、複数のフィールド値に関連付けられている場合でも、タグを無効化または削除す
る。
Splunk Web を使ったタグの管理⽅法の詳細は、『ナレッジ管理』マニュアルの「タグの定義と管理」を参照し
てください。
サーチ結果内の特定のフィールド値のタグ関連付けの削除
今後サーチ結果内の特定のフィールド値にタグを関連付けたくない場合は、当該イベントの隣にある⽮印をクリッ
クした後、[アクション] 下のフィールド値の隣にある⽮印をクリックして、次に [タグの編集] を選択して [タグの
作成] ウィンドウを表⽰します。
[タグ] フィールドから無効にするタグを削除して、[保存] をクリックします。システムから特定のタグとフィー
ルドの関連付けが削除されます。タグがそのフィールド値にのみ関連付けられていた場合は、システムからタグが
削除されます。
ソースタイプ名の変更
props.conf でソースタイプを設定する場合、ソースタイプ名を変更することができます。複数のソースタイプが
同じ名前を共有することができます。このことは、サーチ⽬的で⼀連のソースタイプをグループ化する場合に役⽴
ちます。たとえば、分類⼦を削除するために、「-too_small」を含むソースタイプ名を正規化することができま
す。詳細は、『Getting Data In』マニュアルの「Rename source types」を参照してください。
タグの定義と管理
Splunk Enterprise は、タグを作成、管理するための⼀連の⼿段を提供しています。多くのユーザーがもっとも単
純な、サーチ結果からフィールド/値のペアに直接タグを設定する⽅法を利⽤しています。詳細は、このマニュア
ルの「フィールド値のタグとエイリアス設定」を参照してください。
ただし、ナレッジ管理者は、Splunk Web の [タグ] ページを使って、Splunk Enterprise ユーザーが作成したタ
グを管理します。ここでは、以下の作業について説明していきます。
[設定] の [タグ] ページを使って、環境内のタグを管理する。
Splunk Web を使って新しいタグを作成します。
Splunk Web を使って、タグを無効化または削除します。
[タグ] ページに移動するには、[設定] > [タグ] を選択します。
[設定] での [タグ] ページの使⽤
[設定] の [タグ] ページには、Splunk Enterprise のタグに関する 3 種類のビューが⽤意されています。
フィールド値のペアのタグ設定 ：[タグ] ページの [フィールド値のペア別表⽰] をクリックして表⽰しま
す。
タグ名別表⽰ 。
⼀意の ID によるタグ ：[タグ] ページで [⼀意のすべてのタグオブジェクト] をクリックします。
これらのページを使って、タグコレクションをさまざまな⽅法で管理し、タグとフィールド/値のペア間に作成さ
れた関連に素早くアクセスすることができます。また、タグ間の関連を作成、削除することもできます。ご⾃分の
タグ管理ニーズに合うページを選択してください。
特定のフィールド値ペアに関連付けられているタグセットの管理
タグが関連付けられているすべてのフィールド/値のペアを表⽰することができます。また、特定のフィールド/値
のペアに関連付けられている⼀連のタグを確認、更新することができます。特定のフィールド/値のペアに⼀連の
タグを定義することができます。
[フィールド値のペア別表⽰] ページでは、特定のフィールド/値のペアに関連付けられたタグセットのレビュー
と編集を⾏えます。
また、特定のフィールド/値の組み合わせをタグで管理するための、権限を管理することもできます。
特定のフィールド/値のペアに対するタグのリストを表⽰するには、⽬的のフィールド/値ペアをクリックします。
この操作により、ストラテジーのプロパティページに移動します。
87
eventtype=auditd_create
フィールド/値のペアに定義されているタグの例を以下に⽰します。
必要に応じてこの詳細ビューから、他のタグを追加したり、既存のタグを削除したりすることができます (適切な
権限がある場合)。
[フィールド値のペア別表⽰] ページで新しいフィールド/値のペアに⼀連のタグを定義するには、[新規] をク
リックします。
フィールド/値のペアのタグを作成または更新する場合は、当初の⽬的とは異なる種類のフィールド/値のペアにタ
グを作成/関連付ける可能性があることに注意してください。ナレッジ管理者は、⼀連のタグのデザインや管理を
注意深く確認するようにしてください。そうすることにより、データの正規化が容易になり、ユーザーの混乱を最
⼩限に抑えることができます。(詳細は、このマニュアルの「ナレッジオブジェクトの編成と管理」を参照してく
ださい。)
注意： [フィールド/値のペアのタグ設定] ページに追加するフィールド/値のペアが存在しているかどうかを確認
することもできます。システムには、存在しないフィールド/値のペアに対するタグの定義を防⽌する機能はあり
ません。
特定のタグに関連付けられたフィールド/値ペアの確認と更新
システム内の 1 つまたは複数のタグに関連付けられているすべてのタグを表⽰することができます。また、特定
のタグに関連付けられている⼀連のフィールド/値のペアを確認、更新することができます。さらに、新しいタグ
に対してフィールド/値のペアを定義できます。
これらの作業は、Splunk Web の [タグ名別表⽰] ページで⾏います。ここでは、特定のタグに関連付けられてい
る⼀連のフィールド/値のペアを確認、編集することができます。
ただし、このページでタグに関連付けた⼀連のフィールド/値のペアの権限を管理することはできません。
特定のタグのフィールド/値のペア⼀覧を参照することができます。[タグ名別表⽰] ページで⽬的のタグを探
し、［タグ名］ 列のタグ名をクリックしてください。タグの詳細ページが表⽰されます。
modify
タグに関連付けられている、フィールド/値ペアの表⽰例を以下に⽰します。
必要に応じて他のフィールド/値ペアを追加したり、既存のフィールド/値ペアを削除することができます (適切な
権限がある場合)。
新しいタグに対して⼀連のフィールド/値のペアを定義するには、[タグ名別表⽰] ページで [新規] をクリックしま
す。
タグの⼀連のフィールド/値のペアを作成または更新する場合は、新しいフィールド/値のペアを作成している可能
性もあることに注意してください。タグに関連付けるフィールド/値のペアが存在しているのかを確認することも
できます。システムには、存在しないフィールド/値の関連付けの追加を防⽌する機能はありません。
新しいタグを作成する際には注意してください。同じ⽬的のタグがすでに存在している可能性もあります。ナレッ
ジ管理者は、⼀連のタグのデザインや管理を注意深く確認するようにしてください。そうすることにより、データ
の正規化が容易になり、ユーザーの混乱を最⼩限に抑えることができます。(詳細は、このマニュアルの「ナレッ
ジオブジェクトの編成と管理」を参照してください。)
88
⼀意のフィールド/値のペアとタグの組み合わせの確認
[⼀意のすべてのタグオブジェクト] ページには、システム内のすべての⼀意のタグ名とフィールド/値ペアが表
⽰されます。前述の 2 つのページとは違い、このページではタグとフィールド/値ペアの 1 対 1 の関係のみを編
集することができます。
特定のタグをサーチして、関連付けられているフィールド/値のペアを⼿軽に表⽰したり、その逆の作業を⾏うこ
とができます。このページは、特定のタグとフィールド/値ペアの関連付けを無効化/複製したり、そのようなレベ
ルで権限を管理したりする場合に使⽤します。
タグの無効化と削除
不要なタグがある場合、または特定のフィールド/値のペアにタグを関連付けたい場合、タグを無効化または削除
することができます。適切な権限がある場合、以下のような作業を⾏えます。
サーチ結果内の特定のフィールド/値ペアのタグ関連付けを削除する。
[タグ名別表⽰] ページで、複数のフィールド/値ペアに削除されている場合でも、タグを⼀括して無効化/削
除する。
[フィールド値のペア別表⽰] ページで、あるフィールド/値ペアと⼀連のタグとの関連付けを⼀括して無効
化/削除する。
サーチ結果内の特定のフィールド/値のペアとの関連付けを削除する⽅法については、このマニュアルの「フィー
ルド値のタグとエイリアス設定」を参照してください。
複数のフィールド/値ペアとの関連付けがあるタグの削除
Splunk Web を使って、タグが多数のフィールド/値のペアと関連付けられている場合でも、システムから完全に
削除することができます。ここで説明する⽅法では、すべての関連付けを⼀度に削除します。
[設定] > [タグ] > [タグ名別表⽰] に移動します。タグを削除します。そのタグの削除権限がない場合、タグを
削除するためのリンクは表⽰されません。タグを削除する場合は、それが下流の依存関係に与える影響を考慮する
ようにしてください。詳細は、このマニュアルの「[設定] を使った Splunk Enterprise ナレッジの管理」を参照
してください。
注意： 特定のタグの編集ビューから、フィールド/値ペアとの関連付けを削除することもできます。
フィールド/値のペアと⼀連のタグ間の関連付けの無効化/削除
あるフィールド/値のペアに関連付けられている⼀連のタグを⼀括削除する場合に、ここで説明する⽅法を使⽤し
ます。この⽅法では、すべての関連付けを⼀括削除できます。データからフィールド/値のペアが削除されること
はありません。
[設定] > [タグ] > [フィールド値のペア別表⽰] に移動します。フィールド/値のペアを削除します。そのフィー
ルド/値のペアの削除権限がない場合、フィールド/値のペアを削除するためのリンクは表⽰されません。関連付け
を削除する場合は、削除により下流の依存関係に悪影響がでないかどうかを考慮するようにしてください。詳細
は、このマニュアルの「[設定] を使った Splunk Enterprise ナレッジの管理」を参照してください。
注意： 特定のフィールド/値の編集ビューから、直接タグとの関連付けを削除することもできます。
タグの無効化
⼗分な権限がある場合は、上記の 3 つのページを利⽤して、タグとフィールド/値ペアの関連付けを無効化するこ
ともできます。タグとフィールド/値ペアの関連付けを無効にすると、関連付け⾃体は残りますが再び有効になら
ない限り機能することはありません。
フィールドのエイリアスの作成
フィールドに対して複数のエイリアスを作成できます。元のフィールドは削除されません。作成した任意のエイリ
アスを使って元のフィールドをサーチすることができます。
重要： フィールドのエイリアス設定は、キー/値の抽出後、フィールドルックアップの前に⾏われます。そのた
め、エイリアスを使ってルックアップテーブルを指定することができます。このことは、ルックアップテーブル内
の 1 つまたは複数のフィールドがデータ内のフィールドと同⼀だけれども、名前が異なっているような場合に役
⽴ちます。詳細は、このマニュアルの「CSV および外部ルックアップの設定」および「KV ストア・ルックアッ
プの設定」を参照してください。
幾筋に抽出されたフィールドにも、サーチ時に抽出されたフィールドにも、エイリアスを設定することができま
す。
フィールドエイリアスを追加するには、$SPLUNK_HOME/etc/system/local/ または $SPLUNK_HOME/etc/apps/ 内の独⾃の
App ディレクトリにある props.conf を編集します。(カスタムデータを他のインデックスサーバーに⼿軽に転送
したいような場合は、後者のディレクトリを使⽤することをお勧めします。)
注意： Splunk Enterprise のエイリアス機能は、現在の所複数値フィールドをサポートしていません。
フィールドにエイリアスを設定するには：
1. props.conf 内のスタンザに、次の⾏を追加します。
FIELDALIAS-<class> = <orig_field_name> AS <new_field_name>
89
<orig_field_name> は、オリジナルのフィールドの名前です。
<new_field_name> は、フィールドに設定するエイリアスです。
1 つのスタンザ内に複数のエイリアスを設定することができます。
2. 変更内容を有効にするために、Splunk Enterprise を再起動します。
ルックアップ⽤のフィールドエイリアスの追加例
外部の静的CSV ファイルのルックアップを作成する場合を考えてみましょう。サーチ時に抽出した「ip」フィー
ルドを、「ipaddress」として参照します。抽出を定義した props.conf ファイルで、「ipaddress」を「ip」のエ
イリアスとして設定するために、以下の⾏を追加します。
[accesslog]
EXTRACT-extract_ip = (?<ip>\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})
FIELDALIAS-extract_ip = ip AS ipaddress
props.confにルックアップを設定したら、ip
の代わりに
ipaddress
を使⽤できます。
[dns]
lookup_ip = dnsLookup ipaddress OUTPUT host
サーチ時フィールド抽出設定の詳細は、このマニュアルの「設定ファイルを使ったサーチ時フィールド抽出の作成
と管理」を参照してください。
ルックアップ設定の詳細は、このマニュアルの「CSV および外部ルックアップの設定」および「KV ストア・
ルックアップの設定」を参照してください。
ホストフィールドのタグ設定
ホストフィールドにタグを設定すると、ナレッジの収集と共有や厳密なサーチの作成に役⽴ちます。ホストフィー
ルドに複数のタグを設定することができます。タグを使って、機能やタイプ別にグループ化しておけば、ユーザー
は類似のサーバーグループのアクティビティを⼿軽にサーチできます。特定の⼊⼒のホストフィールドの値を変更
した場合は、すでにインデックスが作成されているイベントに新しいホスト名でタグを設定すれば、データセット
全体を⼿軽にサーチすることができます。
Splunk Web を使ったホストフィールドへのタグの追加
Splunk Web でホストフィールド/値ペアにタグを追加するには：
1. タグを設定するホストからデータをサーチします。
2. サーチ結果から、タグを設定するフィールドを含むイベントに対応する⽮印をクリックします。展開されたリ
ストで、フィールドに対応する [アクション] 下の⽮印をクリックして、[タグの編集] を選択します。
3. [タグの作成] ダイアログに、タグを設定するホストフィールド値を⼊⼒します。たとえば、[フィールド値] に
「Tag host= <現在のホスト値> 」のように⼊⼒します。1 つまたは複数のタグをカンマかスペースで区切って
⼊⼒し、[保存] をクリックします。
90
ホスト名 vs. ホストフィールドのタグ設定
ホストフィールドの値は、イベントのインデックス作成時に設定されます。Splunk Enterprise サーバーのホスト
名、特定の⼊⼒、または各イベントのデータからの抽出などによって設定されます。ホストフィールドに代わりの
名前となるタグを設定しても、実際のホストフィールドの値は変わりません。ただし、ホストフィールドの値では
なく、指定したタグを使ってサーチできるようになります。各イベントには、1 つのホスト名しかありませんが、
複数のホストタグを設定することができます。
たとえば、Splunk Enterprise サーバーが特定のホストからコンプライアンスデータを受信している場合、そのホ
ストにタグ「compliance 」を設定しておけば、コンプライアンス関連のサーチを⼿軽に実施できます。ホスト
タグを利⽤すれば、実際のホスト名を変更することなく、データのグループ化を⾏えます。
ある⼊⼒ソースから取り込んだデータのインデックスを作成後、その⼊⼒のホストフィールドの値を変更した場合
に、インデックスデータのホストフィールドに新たなホスト名でタグを設定します。その⼊⼒から今後取り込まれ
るデータのホストフィールドには新しいホスト値が含まれていますが、すでにインデックス内にあるデータのホス
トフィールドの値は古いホスト名になっています。既存のデータのホストフィールドにタグを設定したことによ
り、新しいデータだけではなく、既存のデータもまとめてサーチすることができます。
イベントタイプのタグ設定
イベントタイプにタグを設定することで、データに新たな情報を追加することができます。イベントタイプに複数
のタグを設定することもできます。たとえば、すべてのファイアウォール関連イベントタイプに「firewall 」タグ
を、ファイアウォールイベントタイプの⼀部に「deny 」タグを、残りのファイアウォールイベントタイプに
「allow 」を設定しておくことができます。イベントタイプにタグを設定すると、そのパターンに⼀致する任意の
イベントタイプにタグが設定されます。
注意： Splunk Web でイベントタイプを作成または eventtypes.conf に設定する時に、イベントタイプにタグを
設定できます。
Splunk Web でのイベントタイプへのタグの追加
Splunk Web で、イベントタイプのリストを表⽰、編集することができます。
[設定] > [イベントタイプ] を選択します。
タグを設定するイベントタイプの名前をクリックして、詳細ページに移動します。
注意： イベントタイプは特定の Splunk Enterprise App と関連付けられていることが多いことに注意
してください。また、表⽰/編集を防⽌するロールベースの権限が割り当てられている可能性もありま
す。
イベントタイプの詳細ページの、[タグ] フィールドでタグを追加、編集します。
変更内容を確認して、[保存] をクリックします。
イベントタイプにタグを設定すると、tag::<field>=<tagname> または
を指定したサーチを実⾏できます。
tag=<tagname>
の形式で、サーチバーからタグ
tag=foo
tag::host=*local*
データモデルの作成
データモデルについて
データモデルは、ピボットツールを強化するものです。データモデルはピボットのユーザーに、⽬的のデータを取
得するサーチを設計する⼿間を省いて、魅⼒的なレポートを作成、理解する⼿段を提供しています。データモデル
は、Splunk Enterprise App 開発者などの、他のユーザーにも役⽴ちます。
Splunk Enterprise ナレッジ管理者は、データモデルを設計、保守します。ナレッジ管理者は、インデックスデー
タの形式や仕組みを理解し、Splunk Enterprise のサーチ⾔語に習熟しています。⼀般的なデータモデルの作成
時、ナレッジ管理者は、ルックアップ 、トランザクション 、サーチ時フィールド抽出 、および計算済みフィー
ルド などの、ナレッジオブジェクトタイプを使⽤します。
データモデルとは？
データモデルは 1 つまたは複数のデータセットに関する、意味的ナレッジのサーチ時マッピングで、階層構造に
なっています。データセットに対するさまざまな特殊サーチを作成するために必要な、ドメインナレッジをエン
コードします。これらの特殊サーチは、Splunk Enterprise がピボットユーザー向けの、レポートを⽣成するため
に⽤いられます。
ピボットユーザーがピボットレポートを設計する場合、作業対象のイベントデータのカテゴリを記述しているデー
タモデル (例：Web インテリジェンスやメールのログなど) を選択します。次に、レポートに記載する特定のデー
タセットを表している、データモデル内の「オブジェクト」を選択します。データモデルはオブジェクトで構成さ
れており、親オブジェクトと⼦オブジェクトの階層構造で編成することができます。各⼦オブジェクトは、その親
オブジェクトが表しているデータセットのサブセットを表しています。
リレーショナルデータベースの設計を理解している⽅ならば、データモデルはデータベースと類似していると考え
てみてください。データモデルをピボットエディタに接続すれば、選択した列と⾏の設定に基づいて、統計テーブ
ル、グラフ、視覚エフェクトなどを⽣成することができます。
効果的なデータモデルを作成するためには、データソースとデータの仕組みを理解する必要があります。この情報
は、データモデルのアーキテクチャに影響する可能性があります (データモデルを構成するオブジェクトの編成⽅
法という点で)。
91
たとえば、データセットの内容が .csv ファイルなどのテーブル形式データフォーマットに基づいている場合、そ
れのデータモデルはかなり平坦で、トップレベルのルートオブジェクト 1 つに、テーブルの列で表されるフィー
ルドが含まれているようなものになるでしょう。ルートオブジェクトには、その下位に⼦オブジェクトがあること
があります。しかし、これらの⼦オブジェクトには、ルートオブジェクトから継承する属性セット以外の追加
フィールドは含まれていません。
また、異種システムログから派⽣したデータモデルには、複数のルートオブジェクト (イベント、サーチ、トラン
ザクション) が存在する可能性があります。これらのルートを、ネスト化された親⼦関係を持つオブジェクト階層
に関連付けることができます。各⼦オブジェクトは、上位のオブジェクトから引き継いだフィールドに加えて新た
なフィールドを持つことができます。
データモデルは、[フィールド抽出] で設定した、または直接 props.conf と transforms.conf を編集することで設定
下抽出 からフィールドを取得することができます。データモデルを定義する場合、正規表現ベースの抽出、ルッ
クアップ 、および eval 式を利⽤して、サーチ時に追加のフィールドを取得するように設定することもできます。
データモデルの⽤語では、データモデルが使⽤するフィールドを「属性 」と呼んでいます。属性は、前述のカテ
ゴリ (⾃動抽出、eval 式、正規表現) をより詳細 (ルックアップ、Geo IP) に分類します。後述する「オブジェク
トの属性」を参照してください。
注意： データモデルはナレッジオブジェクト のカテゴリで、権限の設定が可能です。データモデルの権限は、そ
のデータモデルオブジェクト全体をカバーします。データモデル権限の設定⽅法の詳細は、このマニュアルの
「データモデルの管理」を参照してください。
データモデルはサーチを⽣成
データモデルの内容および仕組みを検討する場合、それを異なる種類のサーチを⽣成する構造化情報の集合体と考
えると役⽴ちます。データモデル内の各オブジェクトを使って、特定のデータセットを返すサーチを⽣成すること
ができます。データモデルオブジェクトが「データセットを表す」と⾔う場合、実際に選択したオブジェクトが返
したデータ セットのことを意味しています。
データモデル、データモデルオブジェクト、およびサーチの関係について、以下のサブセクションでさらに詳細に
⾒ていきます。
オブジェクト制約 は、以下の項⽬によりサーチの最初の部分を決定します。
単純なサーチフィルタ (ルートイベントオブジェクトとすべての⼦オブジェクト)
transaction 定義 (ルートトランザクションオブジェクト)
変換コマンドや他のコマンドを使⽤するより複雑なサーチ⽂字列 (ルートサーチオブジェクト)
基本的にオブジェクト属性 はフィールドです。ピボット⽤にオブジェクトを選択する場合、そのオブジェク
トに対して定義されている⾮表⽰ではない属性が、レポート対象の決定時に、ピボットで選択するフィール
ドのリストに表⽰されます。選択したフィールドは、当該オブジェクトが⽣成するサーチに追加されます。
また、計算済みフィールド 、ユーザー定義のフィールド抽出、およびルックアップによりデータに追加さ
れたフィールドを含めることができます。
オブジェクトが⽣成するサーチの最後の部分は、ピボットエディタでの選択内容によって決まります。選択内容に
より、Splunk Enterprise が結果を統計テーブルとしてフォーマットするために使⽤する変換サーチコマンドの性
質が決定します。そして、これが使⽤するグラフの視覚エフェクトの基盤となります。
ピボットエディタを使ってデータモデルオブジェクトに基づくピボットテーブル、グラフ、視覚エフェクトを作成
する⽅法の詳細は、『ピボットマニュアル』の「ピボットの紹介」を参照してください。
オブジェクト
データモデルは、1 つまたは複数のオブジェクト から構成されています。ここでは、データモデルオブジェクト
の基本的な事項を取り上げています。
オブジェクトは、データセットの仕様です。 各データモデルオブジェクトは、インデックス内のデータ
セットに何らかの観点から対応しています。データモデルを異なるインデックスに適⽤して、違うデータ
セットを⼊⼿することができます。
オブジェクトは 4 つのタイプに分類できます。 タイプには、イベントオブジェクト、サーチオブジェク
ト、トランザクションオブジェクト、および⼦オブジェクトがあります。
オブジェクトは階層構造になっています。 データモデル内のオブジェクトは、親/⼦関係で階層的に配置
することができます。データモデル内のトップレベルのイベント、サーチ、およびトランザクションオブ
ジェクトは、総称的に「ルートオブジェクト」と呼ばれています。
⼦オブジェクトには継承があります。 データモデルオブジェクトは、基本的に制約と属性で分類される特
徴により定義されます。⼦オブジェクトはその親オブジェクトから制約と属性を継承し、また他にも独⾃の
制約や属性を保有しています。
これらの特徴およびその他のデータモデルオブジェクトに関する情報の詳細は、以下のサブセクションで説明して
いきます。
⼦オブジェクトは、親オブジェクトからのイベントをフィルタリングする⼿段を提供している - ⼦オ
ブジェクトは親オブジェクトから継承した制約だけではなく、追加の制約も保有しているたれめ、それが表
すデータセットは常に親オブジェクトが表しているデータセットのサブセットになります。
ルートオブジェクトとオブジェクトタイプ
データモデル内のトップレベルのオブジェクトは、「ルートオブジェクト」と呼ばれています。データモデルに
は、さまざまなタイプのルートオブジェクトを複数含めることができます。また、各ルートオブジェクトが、複数
の⼦オブジェクトの親となることができます。ベースオブジェクトとその⼦オブジェクトの関係が「オブジェクト
ツリー」となります。オブジェクトツリーが表す総合的なデータセットは、まずそのルートオブジェクトを選択し
て、次に⼦オブジェクトを定義することで調整、構築していきます。
92
ルートオブジェクトは、サーチ制約、サーチ、またはトランザクションで定義できます。
ルートイベントオブジェクト は、もっとも利⽤されるルートデータモデルオブジェクトのタイプです。各
ルートイベントオブジェクトは、おおまかにはイベントのタイプを表しています。たとえば、HTTP Access
ルートイベントオブジェクトはアクセスログイベントに対応し、Error イベントはエラー メッセージのイベ
ントに対応します。
⼀般的にルートオブジェクトは、簡単な制約 (後述の「オブジェクトの制約」を参照) で定義されています。
そして、それこそが熟練の Splunk Enterprise ユーザーが、サーチ内のパイプ⽂字、コマンド、引数などを
適⽤する前の最初の部分として考えることでもあります。たとえば、イベントオブジェクトの定義として
は、status > 600 や sourcetype=access_* OR sourcetype=iis* などが考えられます。
注意： イベント、トランザクション、およびサーチの 3 種類の⼦オブジェクトタイプはすべて、上位オブ
ジェクトから継承した⼀連のデータをさらに絞り込む、簡単な制約で定義されます。
ルートトランザクションオブジェクト により、⼀定期間の関連イベントをグループ化したトランザクショ
ン を表すデータモデルを作成することができます。トランザクションオブジェクト定義は、イベントまたは
サーチオブジェクト経由でモデルにすでに追加されているフィールドを利⽤します。そのため、トランザク
ションオブジェクトとその⼦オブジェクトのみで構成されるデータモデルを作成することはできません。ト
ランザクションオブジェクトを作成する前に、モデル内に何らかのイベントまたはサーチオブジェクトのツ
リーを⽤意する必要があります。
ルートサーチオブジェクト は、変換コマンドを含む任意の Splunk サーチを使⽤して、それが表すデータ
セットを定義します。データセット全体を集計する 1 つまたは複数のフィールドを含むベースデータセット
を定義する場合は、ルートサーチオブジェクトを使⽤しなければならないことがあります。たとえば、各種
システム侵⼊イベントの推移をカテゴリ別に分類したシステムセキュリティデータセットが挙げられます。
オブジェクトタイプとデータモデル⾼速化：
必要に応じてデータモデル⾼速化 を利⽤して、ピボットテーブルやグラフの⽣成を⾼速化することができます。
ただし、この機能を利⽤するには、データモデルオブジェクトに関連するいくつかの制限事項があります。データ
モデル⾼速化の恩恵を受けるには、データモデルの作成時にいくつかの⼯夫が必要です。
データ・モデル内の、ルート・イベント・オブジェクトとその⼦のみを⾼速化できます。ベースサーチオブジェク
ト、ベーストランザクションオブジェクト、およびそれらのオブジェクトの⼦を⾼速化することはできません。
ベース・サーチ・オブジェクトを⾼速化したい場合、それを使⽤せずに、同じデータセットをカバーするベース・
イベント・オブジェクトを設定できることがあります。
データモデルの⾼速化を有効にする⽅法は、このマニュアルの「データモデルの管理」を参照してください。
以下の例は、「Call Detail Records」データモデル内の最初のいくつかのオブジェクトを表しています。4 つの
トップレベルのルートオブジェクト「All Calls 」、「All Switch Records 」、「Conversations 」、および
「Outgoing Calls 」が表⽰されています。
「All Calls 」および「All Switch Records 」は、それぞれすべての呼び出しレコードとすべてのキャリアス
イッチレコードを表すルートイベントオブジェクトです。これらのルートイベントオブジェクトには、親が保有す
るデータのサブセットを取り扱う⼦オブジェクトが存在しています。「All Calls 」ルートイベントオブジェクト
には、呼び出しの種類を分類する⼦オブジェクト「Voice」、「SMS」、「Data」、および「Roaming」があり
ます。 携帯電話のデータ通信使⽤状況のみのレポートを利⽤したいピボットユーザーは、「Data」オブジェクト
93
を選択するでしょう。しかし、4 種類の呼び出しタイプを⽐較するレポートを作成したい場合は、そうではなく
「All Calls 」ルートイベントオブジェクトを選択する必要があります。
「Conversations 」と「Outgoing Calls 」は、ルートトランザクションオブジェクトです。これらは両⽅と
も、⼀定期間における関連イベントをグループ化したトランザクションを表しています。「Conversations」オブ
ジェクトには、複数の⼈々の間で交わされた会話の呼び出しレコードのみが含まれています。また、各会話呼び出
しレコードイベント間の最⼤中断時間は 2 時間未満で、会話の⻑さ合計が 1 ⽇未満となっています。
各種オブジェクトの定義⽅法の詳細は、「データモデルオブジェクトの設計」を参照してください。
オブジェクトの制約
すべてのデータモデルオブジェクトは、⼀連の制約 で定義されます。オブジェクト制約は、そのオブジェクトに
関連しないイベントをフィルタリングします。制約は、オブジェクトが表すデータセットの定義に⽤いられます。
ルートイベントオブジェクトまたは任意のタイプの⼦オブジェクトの場合、 制約はパイプ記号や他の
サーチコマンドを持たない単純なサーチとなります。たとえば、HTTP Request に対する制約の場合、Web
Intelligence データモデルのルートイベントオブジェクトは、sourcetype=access_* OR sourcetype=iis* などの
ようになります。
ルートサーチオブジェクトの場合、 制約はオブジェクトのベースサーチ⽂字列になります。
ルートトランザクションオブジェクトの場合、 制約はトランザクション定義になります。トランザクショ
ンオブジェクト定義は、グループオブジェクト (1 つまたは複数のイベントオブジェクト、1 つのサーチオ
ブジェクト、または 1 つのトランザクションオブジェクト) および 1 つまたは複数の Group By フィールド
を識別する必要があります。また、必要に応じて [最⼤停⽌] および [最⼤期間] の値を含めることもできま
す。
制約は⼦オブジェクトに継承されます。制約の継承により、各⼦オブジェクトはその親オブジェクトが表すデータ
のサブセットを表すことになります。ピボットユーザーはこれらの⼦オブジェクトを使⽤して、あらかじめフィル
タリングされた外部データを保有するデータセットを利⽤して、レポートを設計できます。
たとえば、Web Intelligence データモデルの HTTP Success オブジェクトは、ルートイベントオブジェクト HTTP
Request の⼦オブジェクトです。このオブジェクトは HTTP Request から sourcetype=access_* OR sourcetype=iis* を継
承し、次に独⾃の制約 status = 2* で⼀連のイベントを成功した HTTP リクエストイベントに絞り込みます。成功
した HTTP リクエストイベントのレポートのみが必要なピボットユーザーは、このオブジェクトを使ってレポー
トを作成することができます。
先ほどの例では、DocAccess オブジェクトの制約を取り上げました。このオブジェクトは、前の段落で説明した
Web Intelligence データモデル階層の HTTP Success オブジェクトから 2 レベル下にあたります。これは、その
親、祖⽗、および曾祖⽗オブジェクト (AssetAccess、HTTP Success、およびHTTP Request) から継承された制約を含
み、また新たな制約も追加されています。最終的な結果は、ベースサーチを各レベルの制約で絞り込んでいった
データとなります。
1. HTTP
Requestは、Web
サーバーアクセスイベントのみを探すサーチの設定を開始します。
sourcetype=access_* OR sourcetype=iis*
2. HTTP
Successはさらにデータを成功した
Web サーバーアクセスイベントのみに絞り込みます。
status=2*
3. Asset Accessには、Web サイトのページビューに関与するすべてのイベントを切り捨てる制約 (資産アクセスイ
ベントのみを残す) が含まれています。
uri_path!=*.php OR uri_path!=*.html OR uri_path!=*.shtml OR uri_path!=*.rhtml OR uri_path!=*.asp
4. 最後に Doc Access の制約により、サーチが返した⼀連の資産アクセスイベントが、ドキュメントのアクセスに関
与するイベント (.doc または .pdf ファイル) に絞り込まれます。
uri_path=*.doc OR uri_path=*.pdf
すべての制約が適⽤されると、オブジェクト
Doc Access
のベースサーチは以下のようになります。
sourcetype=access_* OR sourcetype=iis* status=2* uri_path!=*.php OR uri_path!=*.html OR uri_path!=*.shtml OR
uri_path!=*.rhtml OR uri_path!=*.asp uri_path=*.doc OR search uri_path=*.pdf
94
オブジェクトおよびオブジェクト制約の詳細は、このマニュアルの「データモデルオブジェクトの設計」を参照し
てください。
オブジェクトの属性
オブジェクトの属性は本質的に、オブジェクトが表すデータセットに関連付けられた⼀連のフィールドです。5 種
類のオブジェクト属性があります。
⾃動抽出 ：Splunk Enterprise がサーチ時 に抽出するフィールド。⾃動抽出属性は、ルートオブジェクトに
のみ追加できます。⼦オブジェクトは、それらを継承することのみ可能です。⾃動抽出された属性を⼦オブ
ジェクト独⾃の属性として追加することはできません。⾃動抽出属性は以下のようなものになります。
Splunk Enterprise が⾃動的に認識、抽出する、uri や version のようなフィールド。これには、イン
デックス作成された CSV ファイルのヘッダーから抽出されたフィールドなどの、構造化データ⼊⼒か
らインデックス作成されたフィールドが含まれます。
[設定] または props.conf で定義した、フィールド抽出 、ルックアップ 、または計算済みフィール
ド。
現在オブジェクトデータセット内には存在していないが、将来的には存在する、属性に⼿動で追加し
たフィールド。inputcsv や dbinspect などの⽣成コマンドでオブジェクトデータセットに追加された
フィールドを含めることができます。
Eval 式 ：属性定義に⼊⼒した eval 式から得られるフィールドです。Eval 式にはしばしば 1 つまたは複数
の抽出されたフィールドが含まれます。
ルックアップ ：属性定義に設定したルックアップ を使って、オブジェクトデータセット内のイベントに追
加されたフィールドです。ルックアップは CSV ファイルやスクリプトなどの、外部のデータソースから
フィールドを追加します。ルックアップ属性を定義する場合、[設定] で定義した任意のルックアップを使⽤
して、オブジェクトにすでに関連付けられている他の属性にそれを関連付けることができます。
正規表現 ：この属性タイプは、属性定義に指定した正規表現を使ってオブジェクトのイベントデータから抽
出されるフィールドを表しています。正規表現属性定義は、複数のフィールドを抽出する正規表現を使⽤す
ることができます。この場合、各フィールドはオブジェクトの属性リストに、別個の正規表現属性として表
⽰されます。
Geo IP ：有効な IP アドレスを持つ、オブジェクトのデータセット内のイベントに、緯度、経度、国、市な
どの地域属性を追加する、特別なタイプのルックアップ です。地図に関連する視覚エフェクトを利⽤する場
合に役⽴ちます。
5 種類の属性タイプの定義⽅法の詳細は、このマニュアルの「データモデルオブジェクトの設計」を参照してくだ
さい。
属性のカテゴリ
データモデルエディタは、属性を 3 つのカテゴリに分類しています。
継承 - すべてのオブジェクトには、いくつかの継承された属性があります。⼦属性は、親オブジェクトから
属性を継承し、それらの継承した属性は常に継承カテゴリに表⽰されます。ルートイベント、サーチ、およ
びトランザクションオブジェクトも、Splunk Enterprise が継承として分類するデフォルトの属性を持って
います。
抽出 - オブジェクトに追加した⾃動抽出属性は、「抽出」属性カテゴリに分類されます。
計算済み - 計算済み属性は、計算やある種のルックアップにより得られた属性です。オブジェクトに eval
式、正規表現、ルックアップ、および Geo IP 属性タイプを追加する場合、それらはすべてこの属性カテゴ
リに表⽰されます。
注意： データモデルエディタでは、計算済み属性の順序を変更することができます。Splunk Enterprise は常に
リストの上から下への順序で属性を処理するため、この機能は特定の順序で処理する必要がある⼀連の属性がある
場合などに役⽴ちます。詳細は、「さまざまな⽬的で利⽤される属性」を参照してください。
属性は継承される
すべてのオブジェクトは、継承した属性を保有しています。
⼦オブジェクトは、親オブジェクトに所属するすべての属性を⾃動的に保有することになります。これらの継承さ
れた属性は、親オブジェクトでは別のカテゴリに分類されている場合でも、⼦オブジェクトの「継承」カテゴリに
表⽰されます。
⼦オブジェクトに他の属性を追加することができます。データモデルエディタは、これらのオブジェクトを属性タ
イプに応じて抽出属性または計算済み属性に分類します。
特定のオブジェクトツリーで、必要な属性すべてをルートオブジェクト内に定義した、⽐較的単純なデータモデル
を設計することができます。この場合、そのツリー内の⼦オブジェクトはすべて、ルートオブジェクトと同じ属性
セットを保有することになります。このようなデータモデルでは、⼦オブジェクトのルートオブジェクトとの差異
は、その制約によってのみ決まります。
ルートイベント、サーチ、およびトランザクションオブジェクトも、継承した属性を持っています。これらの継承
属性は、_time、host、source、および sourcetype などの各イベントから抽出されるデフォルトフィールドです。
継承属性を削除することはできません。また、その定義を編集することもできません。⼦オブジェクトに所属して
いる継承属性を編集または削除する唯⼀の⽅法は、その属性の起源となる親オブジェクトの属性 (抽出または計算
済み) を削除または編集することです。属性の起源がルートオブジェクトの継承属性の場合は、削除または編集す
ることはできません。
属性を削除する代わりに、ピボットユーザーに対して属性を⾮表⽰にすることができます。後述の「ピボットユー
ザーへの属性の表⽰/⾮表⽰」を参照してください。
継承属性がオブジェクトデータセットのオプション項⽬か必須項⽬かを指定することもできます。後述の「オブ
ジェクトデータセットに対する必須属性とオプション属性」を参照してください。
95
さまざまな⽬的で利⽤される属性
属性は主に、ピボットユーザーによるレポートの定義、⽣成に⽤いられる、⼀連のフィールドを提供するために使
⽤されます。ピボットユーザーがアクセスできる⼀連のフィールドは、ユーザーがピボットエディタを起動した時
に選択したオブジェクトにより決まります。属性を⼦オブジェクトに追加して、そのオブジェクトがカバーする
データセット固有のフィールドをピボットユーザーに提供することができます。
⼀⽅、他の属性や制約の定義を設定する⽬的のみの計算済み属性を設計することもできます。これが、属性の記
載順序が関係 してくる理由です。Splunk Enterprise は各属性を、データモデルエディタのリストに表⽰されて
いる順番に処理します。そのため、データモデルエディタでは、計算済み属性の記載順序を変更することができま
す。
たとえば、3 つの eval 式のチェーンセットを設計することができます。最初の 2 つの Eval 式属性は、計算済み
フィールド を作成します。3 番⽬の Eval 式属性は、それらの 2 つの計算済みフィールドを Eval 式内で使⽤しま
す。
ピボットユーザーへの属性の表⽰/⾮表⽰
属性の定義時には、その属性をピボットユーザーに表⽰するか、または⾮表⽰にするかを設定することができま
す。このことは、データモデル内の各オブジェクトが多数の属性を持っているけれども、実際にピボットユーザー
が必要なのはオブジェクトのいくつかの属性のみであるような場合に役⽴ちます。
注意： ある属性を⼀部のオブジェクトでは表⽰して、その他の属性では⾮表⽰にすることができます。親オブ
ジェクトで属性を⾮表⽰にしても、下位の⼦オブジェクトでそれが⾮表⽰になることはありません。
デフォルトで、属性は表⽰されます。あるオブジェクトで⾮表⽰にされた属性は、オブジェクトの属性リストでそ
のようにマークされます。
モデルに含める属性、およびオブジェクトのどの属性を公開するかは、ピボットでオブジェクトをどのように利⽤
させるかによって決まります。⼀般的には、各オブジェクトでそのオブジェクトに関連するデータのみを公開すれ
ば、ピボットユーザーが有益なレポートを作成するために役⽴ちます。たとえば、階層内の特定のオブジェクトを
除いてモデル内では⾮表⽰にする属性をルートオブジェクトに追加することができます。この場合、そのオブジェ
クトとその特定のデータセットでのみ、属性を利⽤できます。
前のセクションで取り上げた、3 つの eval 式を連鎖 (チェーン) した eval 式属性の例を考えてみましょう。最初
の 2 つの eval 式属性は、3 番⽬の属性への⼊⼒としてのみ存在しているため、それらの属性は⾮表⽰にすること
ができます。3 番⽬の属性は最終的な「出⼒」であり、ピボットの⽬的となる属性なので、そのまま表⽰します。
オブジェクトデータセットに対する必須属性とオプション属性
属性設計中には、その属性が必須かまたはオプションかを指定することもできます。これは、オブジェクトが表す
イベントセットのフィルタとして利⽤できます。属性を必須にした場合、オブジェクトが表すすべてのイベントが
その属性を保持する必要があります。属性をオプションにした場合、そのオブジェクトは当該属性がないイベント
も保持することになります。
注意： 属性の表⽰/⾮表⽰ (前述) とともに、⼀部のオブジェクトでは属性を必須にして、その他のオブジェクトで
はオプションにすることができます。親オブジェクトで属性を必須にしても、下位の⼦オブジェクトでその属性が
⾃動的に必須になることはありません。
デフォルトでは、属性はオプションです。あるオブジェクトでステータスが必須に変更された属性は、オブジェク
トの属性リストでそのようにマークされます。
データモデルの管理
データモデルの管理ページでは、データモデルの作成および権限や⾼速化などの設定作業を⾏うことができます。
このページでは、以下の作業を⾏えます。
新しいデータモデルの作成 - ボタンをクリックするだけで、簡単に作成することができます。
権限の設定 - データモデルはナレッジオブジェクトなので、権限を設定することができます。権限を設定す
ることで、データモデルを参照、更新できるユーザーを決めることができます。
データモデル⾼速化を有効にする - ⼤きなデータセットを持つデータモデルの、ピボットパフォーマンス
を向上することができます。
データモデルの複製 - 既存のデータモデルをベースにした新しいデータモデルを素早く作成する、または
データモデルを他の App にコピーすることができます。
データモデルのアップロード/ダウンロード - データモデルをダウンロード (Splunk 外にエクスポート)
します。エクスポートしたデータモデルは、別の Splunk 環境にアップロードします。
データモデルの削除 - 不要になったデータモデルを削除します。
このトピックでは、以上のようなデータモデルの管理作業について説明していきます。データモデルを構成するオ
ブジェクト階層を定義する場合は、データモデルエディタに移動します。詳細は、このマニュアルの「データモデ
ルとオブジェクトの設計」を参照してください。
データモデル管理ページへの移動
基本的にデータモデル管理ページは、アラート、レポート、およびダッシュボードを表⽰しているページと同じ
く、リストが表⽰されているページです。ここでは、データモデルの権限と⾼速化の管理、およびデータモデルの
複製と削除作業を⾏えます。このページは、最初にピボットを利⽤した時に表⽰される [データモデルを選択して
ください] ページ (複数のデータモデルがある場合にのみ表⽰されます) とは異なります。[データモデルを選択し
てください] ページは、ピボットの作成に使⽤するデータモデルをユーザーに選択させるためにのみ存在していま
す。
データモデル管理ページには、システム内のすべてのデータモデルが、ページで分けられたテーブルに記載されて
96
います。このテーブルは、App、所有者、および名前でフィルタリングできます。また、選択した App のユー
ザーが表⽰できるすべてのデータモデルを表⽰したり、実際に App 内で作成されたデータモデルのみを表⽰した
りすることもできます。
データモデル管理ページを表⽰するには、いくつかの⽅法があります。
このページには、Splunk Web 内の任意のページの [設定] リストからアクセスできます。[設定] > [データ
モデル] を選択してください。
ピボット内のデータモデル記載ページで、[データモデルの管理] ボタンをクリックします。
データモデルエディタで、[データモデルに戻る] をクリックします。
新しいデータモデルの作成
データモデルを作成するには、データモデル管理ページに移動して (⽅法は上記を参照)、[新しいデータモデル]
をクリックします。
注意： ⾃分のロールに適切な権限がある場合にのみ、データモデルを作成することができます (ロールには最低 1
つの App に対する書き込み権限が必要です)。ロールの権限が不⼗分な場合は、[新しいデータモデル] ボタンは
表⽰されません。詳細は、後述する「ロールへのデータモデル作成の許可」を参照してください。
[新しいデータモデル] をクリックすると、[新しいデータモデルの作成] ダイアログが表⽰されます。データモ
デルの [タイトル] および必要に応じて [説明] を⼊⼒します。
[タイトル] フィールドには、アスタリスク以外の任意の⽂字を使⽤できます。また⽂字間に空⽩⽂字を使⽤する
こともできます。その⽂字列が、[データモデルを選択してください] ページ、データモデル管理ページ、および
Splunk Enterprise 内のデータモデル名の表⽰場所にそのまま表⽰されます。
タイトルを⼊⼒すると、データモデルの [ID] フィールドが⾃動的に記⼊されます。これは変更しないことをお勧
めします。データモデルの ID は、データモデルに対して⼀意でなければなりません。⽂字、数字、およびアン
ダースコアのみを使⽤できます。⽂字の間にスペースを使⽤することもできません。いったん [作成] をクリック
すると、それ以降 ID の値を変更することはできません。
[App] に、現在の App コンテキストが表⽰されます。データモデルを別の App に所属させる場合は、[App] の
値を変更してください。
[作成] をクリックすると、データモデルエディタに新しいデータモデルが表⽰されます。ここから、データモデ
ルを構成するオブジェクトを追加、定義することができます。
データモデルエディタに新しいデータモデルを表⽰した当初は、何もオブジェクトが存在していません。データモ
デルの最初のオブジェクトを定義するには、[オブジェクトの追加] をクリックして、オブジェクトタイプを選択
します。フィールド、サーチ、トランザクション、および⼦オブジェクトなどを追加する、オブジェクトの定義作
業の詳細は、次のセクションを参照してください。
データモデルエディタの詳細およびデータモデルオブジェクトの作成作業については、このマニュアルの「データ
モデルとオブジェクトの設計」を参照してください。
ロールへのデータモデル作成の許可
デフォルトでは、admin または power ロールを持つユーザーのみがデータモデルを作成できます。他のユーザー
の場合、データモデルを作成できるかどうかは、各⾃のロールが、使⽤している App の「書き込み」アクセスを
保有しているかどうかによって決まります。他のロールに App への書き込みアクセスを許可するには、以下の⼿
順に従ってください。
1. ページの上部にある [App] ドロップダウンメニューをクリックし、[App の管理] を選択して [App] ページに移
動します。
2. [App] ページで、データモデルの作成権限を与える App を探して、[権限] をクリックします。
3. App の [権限] ページで、その App のデータモデルの作成を許可するロールに対して [書き込み] を選択しま
す。
4. 変更内容を保存するには、[保存] をクリックします。
97
注意： ロールにデータモデルの作成権限を与える場合、いくつかの事項を考慮する必要があります。詳細は、こ
のマニュアルの「ナレッジオブジェクトの無効化または削除」を参照してください。
データモデルの権限について
データモデルはナレッジオブジェクトなので、それを表⽰、編集できるかどうかは、ロールベースの権限によって
決まります。データモデルの作成当初は、⾃分専⽤のデータモデルになっています。他のユーザーが [データモデ
ルを選択してください] ページやデータモデル管理ページでそれを参照したり、更新したりすることはできませ
ん。
データモデルの権限を編集するには、データモデル管理ページに移動して⽬的のデータモデルを探し、以下のいず
れかの作業を⾏います。
[編集] をクリックして、[権限の編集] を選択します。
⽬的のデータモデルの⾏を展開して、権限の [編集] をクリックします。
この場合、[権限の編集] ダイアログが表⽰されます。このダイアログでは、プライベート・データ・モデルの他
のユーザーとの共有、データ・モデルに対する各種ロールのアクセス・レベルの設定などの作業を⾏えます。
データ・モデルの権限設定の詳細は、このマニュアルの「ナレッジオブジェクトの権限の管理」を参照してくださ
い。デフォルトでは、任意のロールがデータモデルを作成できますが、それらのロールが作成したデータモデル
は、admin または power ロールを持つユーザーがそれを共有しない限り、プライベートになります。admin ま
たは power ロールを持つユーザーのみが、データモデルを作成および共有することができます。
重要： データモデルを共有する場合、そのデータモデルに関連するナレッジオブジェクト (ルックアップやフィー
ルド抽出など) は、同じ権限を持っていなければなりません。そうしないと、他のユーザーがデータモデルを使⽤
する際に、エラーが発⽣する可能性があります。
たとえば、データモデルをサーチ App のすべてのユーザーと共有しているけれども、そのモデルが Admin ロー
ルを持つユーザーとのみ共有されているルックアップテーブルを使⽤している場合、Admin ロールのユーザーは
正常に利⽤できますが、その他のユーザーがピボットでそのデータモデルを使⽤すると、「ルックアップテーブル
が存在していません」などのエラーが発⽣してしまいます。この問題を解決するには、データモデルを Admin
ユーザーのみに制限するか、またはルックアップをサーチ App のすべてのユーザーと共有します。
データモデルがプライベートで、関連するルックアップテーブルとルックアップ定義もプライベートの場合に、
データモデル⾼速化を使⽤すると問題が発⽣します。データモデルを⾼速化するには、モデルを共有する必要があ
ります。関連するルックアップテーブルとルックアップ定義も同じように共有しないと、ユーザーにはルックアッ
プテーブルが存在しない旨のメッセージが表⽰されます。
データモデル⾼速化の有効化
データモデル⾼速化により、データモデルが表すデータセットからのレポート⽣成処理を⾼速化することができま
す。データモデルを⾼速化すると、そのデータモデルを使⽤するピボット、レポート、およびダッシュボードパネ
ルは、そうしない場合と⽐べてより素早く結果を返します。
データモデル⾼速化は、ハイパフォーマンス分析ストア を利⽤しています。データモデル⾼速化機能はハイパ
フォーマンス分析ストアを利⽤して、データモデルのデータサマリーをインデックスレベルで構築します (実際に
このサマリーは、各インデクサーに分散した複数の⼩さなサマリーから構成することができます)。サマリーの作
成が完了すると、⾼速化されたデータモデルオブジェクトを使⽤するピボット操作は、可能な場合は _raw ではな
くサマリーに対して実⾏されます。これにより、ピボットの結果が返されるまでの時間を⼤幅に短縮することがで
きます。
データモデル⾼速化はとても⼤きなデータセットの処理を⾼速化するために役⽴ちますが、いくつかの注意事項が
あります。
デフォルトでは、 admin 権限を持つユーザーのみが、⾼速化されたデータモデルにアクセスできま
す。 データモデル⾼速化はリソースを⼤幅に消費する可能性があるため、できる限り少数の Splunk
Enterprise ユーザーに限定して利⽤させるようにしてください。データモデルの⾼速化を利⽤できるかどう
かは、accelerate_datamodel 権限 に関係しています。
プライベートなデータモデルを⾼速化することはできません。 ⾼速化するためには、データモデルを
App のユーザーと共有する必要があります。この場合、関連するナレッジオブジェクト (ルックアップ属性
が依存しているルックアップテーブルやルックアップ定義など) も同じ⽅法で共有する必要があります。詳
細は、前述の「データモデルの権限について」を参照してください。
データモデルを⾼速化したら、それを編集することはできません。 ⾼速化したデータモデルは、⾼速化
を無効にしない限り編集することはできません。データモデルを再度⾼速化した場合もリソースが消費され
るため、⾼速化を無効にすることはできる限り避けてください。
データ・モデル⾼速化は、ルート・イベント・オブジェクトとその⼦オブジェクトにのみ適⽤できま
す。 Splunk Enterprise では、ルート・サーチおよびルト・トランザクション・オブジェクトに基づくオブ
ジェクト階層を⾼速化することはできません。それらの⾼速化されないオブジェクトを使⽤するピボット
は、_raw データになります。
データモデル⾼速化は、⾼速化対象のルートイベントオブジェクトの初期制約サーチに、Splunk
Enterprise がサーチ対象とするインデックスが含まれている場合にもっとも効果を発揮します。 そう
でない場合は、データモデルで利⽤可能なすべてのインデックスがサーチされるため、Splunk Enterprise
が不要なデータの⾼速化に時間を無駄に費やしてしまう可能性があります。
データ・モデル⾼速化の詳細と⾏われる処理、および「アドホック」データ・モデル⾼速化については、このマ
ニュアルの「データ・モデルの⾼速化」を参照してください。
データモデル⾼速化を有効にするには
データモデル⾼速化に⼗分な権限がある場合は、以下の⼿順に従ってください。
98
1. データモデル管理ページに移動します。
2. ⾼速化するデータモデルを探して、[編集] の [⾼速化の編集] を選択するか、またはデータモデルの⾏を展開し
て、[⾼速化] の [追加] をクリックします。
3. [⾼速化の編集] ダイアログが表⽰されます。データモデルの⾼速化を有効にするには、[⾼速化] チェック ボッ
クスを選択します。
4. [サマリー範囲] フィールドが表⽰されます。データモデル内の⾼速化オブジェクトを使⽤するピボット操作を
実⾏する期間に応じて、[1 ⽇]、[7 ⽇]、[1 ヶ⽉]、[3 ヶ⽉]、[1 年]、または [全時間] を選択します。たとえば、過
去 7 ⽇間に対してピボット操作を実⾏予定の場合は、[7 ⽇] を選択します。
注意： [サマリー範囲] フィールドに表⽰されるサマリー範囲とは異なる範囲が必要な場合、datamodels.conf で⾃
分のデータモデル⽤に範囲を設定することができます。
5. [保存] をクリックして、⾼速化の設定を保存します。データモデルを⾼速化すると、データモデル管理ページ
のモデルに対応する雷記号が⻩⾊で点灯します。
データモデル⾼速化測定基準の検査
データモデルを⾼速化したら、データモデル管理ページでモデルの⾼速化に関する詳細情報を参照することができ
ます。⾼速化したデータモデルの⾏を展開して、[⾼速化] の下に表⽰される情報を確認してください。
[ステータス] は、データモデルの⾼速化サマリー作成処理が完了したかどうかを⽰しています。ステータス
が作成中の場合、サマリー作成処理の完了状況がパーセントで表⽰されます。多くのデータモデルサマリー
は新しいデータで定期的に更新されることに注意してください。つまり現在のステータスが「完了」の場合
でも、今後「作成中」になる可能性があります。
[アクセスカウント] には、データモデルサマリーの作成後に、サマリーがアクセスされた回数、および最
後のアクセス時刻が表⽰されます。あまり使⽤されていないデータモデルを識別する場合などに役⽴ちま
す。データモデル⾼速化はシステムリソースを消費するため、定期的にアクセスされないようなデータモデ
ルは⾼速化しない⽅が良いこともあります。
[ディスク上のサイズ] には、データモデルの⾼速化サマリーが消費しているストレージスペースを表して
います。この測定基準と [アクセスカウント] を使って、システムに無⽤な負荷をかけているため削除する
必要があるサマリーを判断することができます。データモデルの⾼速化サマリーがディスク上の⼤量のス
ペースを消費している場合は、サマリー範囲を狭めることも検討してください。
[サマリー範囲] は、データモデルの範囲を表しており、常に現在からの相対的な期間になります。この範囲
は、データモデルの⾼速化の定義時に設定します。
[バケツ] には、データモデル⾼速化サマリーによる、インデックスバケツ 数が表⽰されます。
最初からサマリーを再構築する場合は、[再構築] をクリックします。この操作は、システムクラッシュやその他
の障害により、データの損傷や消失が疑われるような場合に実施します。サマリーの⾼速化を無効にした後再度有
効にすると (たとえば、データモデルの編集⽬的で)、Splunk Enterprise は⾃動的にサマリーの再構築を開始しま
す。
⾼速化サマリー情報を更新するには、[更新] をクリックします。
[編集] をクリックして [⾼速化の編集] ダイアログを表⽰し、[サマリー範囲] を変更するか、またはデータモデ
99
ルの⾼速化を無効にしてください。
データモデルの複製
データモデルの複製は、既存のデータモデルをベースにして、データモデルを素早く作成するための⼿段を提供し
ています。次に複製したデータモデルを編集して、別のデータセットを表すように修正したり、データセット内の
オブジェクトの分類⽅法を変更して、異なるオブジェクト構造を構築したりすることができます。データモデルを
複製するには、データモデル管理ページに移動して、⽬的のデータモデルの [編集] をクリックし、次に [複製] を
選択します。元のデータモデルと同⼀の新しいデータモデルが作成されます。複製したデータモデルには、⼀意の
名前を指定する必要があります。
注意： また、データモデルエディタからデータモデルを複製することもできます。単純に [編集] をクリックし
て、[複製] を選択します。
複製したデータモデルは、データモデル管理ページ (このトピックで説明) やデータモデルエディタ (このマニュア
ルの「データモデルとオブジェクトの設計」で説明) で編集することができます。
データモデルのアップロード/ダウンロード
Splunk のデータモデルのダウンロード/アップロード機能を使って、Splunk Web インターフェイスから Splunk
外にデータモデルをエクスポートして、次のそれを別の Splunk 環境にアップロードすることができます。この機
能を使って重要なデータモデルのバックアップを作成したり、他の Splunk ユーザーにエクスポートしたデータモ
デルを送信して、データモデルに関する共同作業を⾏ったりすることができます。また、Splunk のステージング
環境とプロダクション環境間でのデータモデルの移動に利⽤することもできます。
注意： Splunk 環境間でデータモデルの JSON ファイルを⼿動で移動することもできますが、この作業はサポー
トしていない⼿順であり、エラーが発⽣する可能性も⾼くなります。詳細は、このトピックの後半にある「データ
モデルの⼿動管理」を参照してください。
データモデルのダウンロード
データモデルエディタからデータモデルをダウンロードします。1 回に 1 つのデータモデルのみをダウンロード
することができます。
データモデルをダウンロードするには、データモデルエディタでデータモデルを開いて、右上にある [ダウンロー
ド] ボタンをクリックします。データモデルの JSON ファイルが、指定したダウンロードディレクトリにダウン
ロードされます。ディレクトリを指定しなかった場合は、ファイルの保存先ディレクトリを指定するように要求す
るダイアログが表⽰されます。
ダウンロードした JSON ファイル名は、データモデルの ID と同じになります。ID は、最初にデータモデルを作
成した時に 1 回のみ指定します。データモデルのタイトル とは違い、モデルの作成時に ID が保存されると、そ
れ以降に変更することはできません。
既存のデータモデルの ID は、データモデルエディタでモデルを表⽰した時に確認することができます。ID はエ
ディタの左上の、モデルのタイトルの下に表⽰されます。
データモデルのアップロード時には、オリジナルのデータモデルの ID とは異なる、新しい ID を指定することが
できます。
データモデルのアップロード
データモデルのアップロードは、データモデルの管理ページから⾏います。1 回に 1 つのデータモデルのみを
アップロードすることができます。
注意： Splunk にアップロードするファイルは、Splunk により検証されます。有効な JSON データ・モデル・
コード以外が含まれている場合、ファイルはアップロードできません。
Splunk にデータモデルをアップロードするには、[データモデルのアップロード] をクリックして、[新しい
データモデルのアップロード] ダイアログボックスを表⽰します。まずアップロードする JSON ファイル を指
定します。
[ID] フィールドには、オリジナルのデータモデルの ID が表⽰されます。必要に応じてこの ID を変更することが
できます。いったんシステムにデータモデルを保存すると、それ以降 ID を変更することはできないことに注意し
てください (データモデルのタイトルは編集可能です)。
データモデルの所属先 App 名を指定して、次にデータモデルがプライベートか、または App 内で共有する
(App の他のすべてのユーザーと共有する) かを指定します。
データモデル権限の詳細は、前述の「データモデルの権限について」を参照してください。
[App 内で共有] を選択した場合、[⾼速化] を選択して [サマリー範囲] を選択することで、データモデルの⾼速
化を有効にできます。
データモデル⾼速化の有効化については、前述の「データモデル⾼速化の有効化」を参照してください。
データモデルの削除
100
データモデル管理ページまたはデータモデルエディタから、データモデルを削除することができます。単純に [編
集] をクリックして、[削除] を選択します。
注意： データモデルの作成権限がある場合は、それを削除する権限もあります。詳細は、前述の「ロールへの
データモデル作成の許可」を参照してください。
データモデルの⼿動管理
データモデルのファイルを⼿動で移動したり、編集したりすることによるデータモデルの管理はお勧めできませ
ん。可能な限りデータモデルの作成と編集には、Splunk Web を使⽤する必要があります。Splunk Web でデー
タモデルを編集する場合、データモデルエディタが変更内容を検証します。⼿動でモデルを作成または編集する
と、この検証作業は⾏われません。
データモデルはディスクに JSON ファイルとして保管され、関連する設定は datamodels.conf に、メタデータは
local.meta (⾃分が作成したモデル⽤) および default.meta (製品が提供するモデル⽤) にあります。
⾃分が作成したモデルは
<yourapp>/local/data/models
<yourapp>/default/data/models
に保管されますが、製品が提供するモデルは
に保管されます。
Splunk 環境間でモデルのファイルを⼿動で移動できますが、Splunk Web のデータモデルのアップロード/ダウ
ンロード機能 (前述) を利⽤する⽅が簡単です。モデルファイルを⼿動で移動する必要がある場合は、作業時にそ
の datamodels.conf スタンザと local.meta メタデータを忘れずに移動してください。
データモデルの削除にも同じことが当てはまります。削除/消去処理が適切に⾏われるように、Splunk Web を可
能な限り利⽤してください。
データモデルとオブジェクトの設計
Splunk Web で、新しいデータモデル の設計や既存のモデルの編集には、データモデルエディタを使⽤します。
ここでは、データモデルエディタを使った、以下の項⽬の作成、編集⽅法について説明していきます。
データモデルにルートオブジェクトと⼦オブジェクトを追加して、データモデルオブジェクト 階層を構築
します。
オブジェクトデータ セットを定義します (制約 、サーチ⽂字列、またはトランザクション定義を指定する)。
オブジェクトの名前を変更します。
オブジェクトを削除します。
データモデルエディタを使って、オブジェクトの属性を作成、編集することもできます。詳細は、「オブジェクト
属性の定義」を参照してください。
注意： このトピックでは、データモデルの基本的な概念の説明には、あまり時間を割きません。Splunk
Enterprise でまだデータモデルに関する作業を⾏ったことがない場合は、このマニュアルの「データモデルにつ
いて」を参照してください。そこには、データモデルおよびデータモデルオブジェクトがどのようなものであるの
か、そしてその仕組みについて詳細に説明されています。
新しいデータモデルの作成と管理については 、このマニュアルの「データモデルの管理」を参照してくださ
い。データモデル管理ページでの新しいデータモデルの作成⽅法のほかに、このトピックではデータモデルの権限
と⾼速化の管理⽅法についても説明していきます。
データモデルエディタ
データモデルは、データモデルオブジェクトの集合を階層構造に編成したものです。新しいデータモデルを設計ま
たは既存のデータモデルを再設計するには、データモデルエディタに移動します。データモデルエディタでは、
データモデル⽤オブジェクトの作成、制約と属性 の定義、論理オブジェクト階層への編成と管理作業を⾏えま
す。
101
既存のデータモデル内のオブジェクトの管理
既存のデータモデルを利⽤するためのデータモデルエディタへのアクセス⼿段には、以下の 5 種類があります。
ピボットの [データモデルを選択してください] ページで、データモデルの⾏を展開してモデルの詳細情報を
表⽰します。[オブジェクトの編集] をクリックすると、そのモデルのデータモデルエディタにアクセスで
きます。
ピボットで、データモデルを選択します。モデルの [オブジェクトを選択してください] ページで、[オブ
ジェクトの編集] をクリックします。
ピボットでデータモデルを選択した後、そのデータモデルからオブジェクトを選択します。[新しいピボッ
ト] ページで [データソース] をクリックして、[オブジェクトの編集] を選択します。
[システム] > [データモデル] に移動して、⽬的のデータモデルの [編集] ドロップダウンをクリック
し、[オブジェクトの編集] を選択します。
または、[システム] > [データモデル] に移動して、⽬的のデータモデルの⾏を展開し、表⽰されてい
るオブジェクトの [編集] を選択します。
注意： ⾃分が適切な権限を持っているデータモデルのみを編集することができます。
データモデルへのルートイベントオブジェクトの追加
⼀般的にデータモデルは、主にルートイベントオブジェクト上に構築されたオブジェクト階層から成り⽴っていま
す。各ルートイベントオブジェクトが、制約で定義された⼀連のデータを表しています。制約 は、オブジェクト
に関連しないイベントをフィルタリングするための、単純なサーチです。制約は、パイプ⽂字の前の最初のサーチ
部に似ており、それに追加のサーチコマンドが追加されます。
ルートイベントオブジェクトの制約は、⼀般的にかなり幅広い範囲のデータを返すように設計されます。ルートイ
ベントに⼦イベントオブジェクトを関連付ける際に、この⼤きなデータセットをどのように処理するかを定義して
いきます。各⼦イベントオブジェクトには、上位のオブジェクトから継承された制約に加えて、独⾃の制約が追加
され、それが表すデータセットの範囲が絞り込まれていきます。
注意： 制約によるオブジェクト階層内のデータの絞り込みの仕組みについては、このマニュアルのトピック
「データモデルについて」にある「オブジェクト制約のセクション」を参照してください。
データモデルにルートイベントオブジェクトを追加するには、データモデルエディタで [オブジェクトの追加] を
クリックして、[ルートイベント] を選択します。[イベントオブジェクトの追加] ページに移動します。
102
ルートイベントオブジェクトに、[オブジェクト名] 、[オブジェクト ID] 、および 1 つまたは複数の [制約] を指
定します。
[オブジェクト名] フィールドには、アスタリスク以外の任意の⽂字を使⽤できます。また⽂字間に空⽩⽂字を使
⽤することもできます。ここに⼊⼒した⽂字列が、[オブジェクトを選択してください] ページやデータモデルオブ
ジェクトが記載される他の場所に表⽰されます。
[オブジェクト ID] は、オブジェクトに対して⼀意でなければなりません。スペースを⼊れることはできませ
ん。または英数字、アンダースコア、またはハイフン (a〜z、A〜Z、0〜9、_、または -) 以外の⽂字は使⽤でき
ません。⽂字の間にスペースを使⽤することもできません。オブジェクト ID を保存した後に、値を変更するこ
とはできません。
ルートイベントオブジェクトの [制約] を⼊⼒したら、[プレビュー] をクリックして、指定した制約で⽬的のイベ
ントが正しく返されるかどうかをテストすることができます。
データモデルへのルートトランザクションオブジェクトの追加
ルートトランザクションオブジェクトを利⽤して、トランザクション イベントから構成されたデータセットに基
づくオブジェクト階層を作成することができます。トランザクションイベントは、⼀定期間内の概念的に関連した
イベントの集合で、単⼀の顧客のホテル予約セッションに関するすべての Web アクセスイベントやファイア
ウォール侵⼊に関連するすべてのイベントなどが例として挙げられます。ルートトランザクションオブジェクトを
定義する場合は、⼀連のトランザクションイベントを抽出するトランザクションを定義します。
まだ仕組みを理解していない場合は、トランザクションおよび transaction コマンドについて説明しているトピッ
クをご覧ください。まず、『サーチマニュアル』の「トランザクションについて 」を参照してくださ
い。transaction コマンドの詳細については、『サーチリファレンス』のこのコマンドに関する項⽬を参照してく
ださい。
注意： ルートトランザクションオブジェクトとその⼦オブジェクトには、データモデル⾼速化は適⽤されませ
ん。
データモデルにルートトランザクションオブジェクトを追加するには、データモデルエディタで [オブジェクト
の追加] をクリックして、[ルートトランザクション] を選択します。[トランザクションオブジェクトの追加] ペー
ジに移動します。
103
ルートトランザクションオブジェクト定義では、[オブジェクト名] 、[オブジェクト ID] 、および最低 1 つの [グ
ループオブジェクト] を指定する必要があります。[グループ化⽅法] 、[最⼤停⽌] 、および [最⼤期間] フィール
ドの指定は省略できますが、最低でもこれらの 3 つのフィールドのいずれかを指定しない限り、トランザクショ
ン定義は不完全になります。
[オブジェクト名] フィールドには、アスタリスク以外の任意の⽂字を使⽤できます。また⽂字間に空⽩⽂字を使
⽤することもできます。ここに⼊⼒した⽂字列が、[オブジェクトを選択してください] ページやデータモデルオブ
ジェクトが記載される他の場所に表⽰されます。
[オブジェクト ID] は、オブジェクトに対して⼀意でなければなりません。スペースを⼊れることはできませ
ん。または英数字、アンダースコア、またはハイフン (a〜z、A〜Z、0〜9、_、または -) 以外の⽂字は使⽤でき
ません。⽂字の間にスペースを使⽤することもできません。オブジェクト ID を保存した後に、値を変更するこ
とはできません。
トランザクションオブジェクトがそのトランザクションを取得するデータのプールを定義するために、すべてのト
ランザクションオブジェクト定義に、1 つまたは複数のグループオブジェクト 名が必要です。ただし、[グルー
プオブジェクト] に追加できる項⽬には制限があります。[グループオブジェクト] には、以下の 3 種類のいずれ
かを指定することができます。
1 つまたは複数のイベントオブジェクト (ルートイベントオブジェクトまたは⼦イベントオブジェクト)
1 つのトランザクションオブジェクト (ルートまたは⼦)
1 つのサーチオブジェクト (ルートまたは⼦)
また、現在選択しているデータモデル内に存在するオブジェクトしか使⽤できません。
コマンドの仕組みを理解している⽅ならば、グループオブジェクト は、transaction コマンドの前に
現れるサーチ⽂字列の⼀部を指定するのと似ていることにお気付きでしょう。ルートトランザクションオブジェク
ト Web Session の定義に、Apache Access Search オブジェクトを追加した、前の画⾯を例に考えてみましょ
う。Apache Access Search は、⼀連の成功した Web サーバーアクセスイベントを表しています。その 2 つの
制約は、status < 600 と sourcetype = access_* OR source = *.log です。そのため、このルートトランザクションオ
ブジェクトが表しているトランザクションサーチの先頭部は以下のようになります。
transaction
status<600 sourcetype=access_* OR source=*.log | transaction...
この後は、transaction 引数の残りの部分を定義するだけになります。
[グループ化⽅法] を利⽤して、ルートトランザクションオブジェクトのフィールドをリスト表⽰することができ
ます。複数のフィールドを選択した場合、transaction は選択したフィールドに対して同じ値を共有するイベント
を検索します。[グループ化⽅法] ドロップダウンは、最低 1 つのグループオブジェクト を指定しないと表⽰さ
れません。また、このドロップダウンでは、指定した (リストに記載されている) グループオブジェクトまたはオ
ブジェクトに所属する属性のみを選択できます。複数のオブジェクトを選択した場合、[グループ化⽅法] では選
択したすべてのオブジェクトが共有している属性のみを選択することができます。
注意： [グループ化⽅法] フィールドの項⽬は、ルートトランザクションオブジェクトに対して選択したグループ
オブジェクト に所属している属性で、これを選択してもそれがルートトランザクションオブジェクトに属性とし
104
て追加されることはありません。これらはトランザクションの定義に⽤いられます。
[グループ化⽅法] フィールドの記載順序は変更することができます。トランザクション内に同じタイムスタンプ
を持つイベントが存在しているような特別な状況下では、フィールドの順序変更が Splunk Enterprise によるそ
れらのイベントのソート⽅法に影響する可能性があります。
期間ベースのオプションの [最⼤停⽌] および [最⼤期間] は、transaction サーチコマンドの maxpause および
maxspan 引数と同じ機能を持っています。これらの設定を利⽤して、トランザクションオブジェクトが探すトラン
ザクションへの、誤ったイベントの混⼊を防⽌することができます。
[最⼤停⽌] フィールドには、単⼀のトランザクションを構成する個別のイベントを区切る時間量の制限値を設定
することができます。たとえば、あるトランザクションに各タイムスタンプ間が 20 秒を超えているイベントを含
めてはいけないことが分かっていれば、最後のイベントの到着後 20 秒を超えてから次の⼀致するイベントがあっ
た場合、それは新たなトランザクションの開始を⽰すイベント、または例外イベントであると判断できます。トラ
ンザクションオブジェクトがこのルールに従ったトランザクションを確実に返すようにするには、[最⼤停⽌] に
[20 秒] を指定します。
[最⼤期間] フィールドには、特定のトランザクションに含める期間を指定できます。たとえば、⽬的のトランザ
クションが 5 分間を超えることがない場合は、対応するトランザクションオブジェクトの [最⼤期間] に [5 分] を
設定できます。
先ほどの画⾯の例に戻り、トランザクションオブジェクトをサーチ⽂字列として表現すると、それは以下のように
なります。
status<600 sourcetype=access_* OR source=*.log | transaction clientip useragent maxspan=1m
これは、status<600 sourcetype=access_* OR source=*.log が返したデータを調査して、「web session」トランザク
ションを探します。このトランザクションは、clientip と useragent の値が同⼀で、トランザクションの期間全体
が 1 分を超えない⼀連のイベントのグループです。
ルートトランザクションオブジェクトの [グループ化⽅法] を定義したら、[プレビュー] をクリックして、指定し
た制約で⽬的のイベントが正しく返されるかどうかをテストすることができます。
データモデルへのルートサーチオブジェクトの追加
ルートサーチオブジェクトを利⽤して、任意の変換サーチ の結果をベースデータセットにしたオブジェクト階層
を作成することができます。変換サーチは、統計コマンドを使ってデータセット全体の 1 つまたは複数のフィー
ルドを集計した、ベースデータセットを定義するサーチです。
ルートサーチオブジェクトとその⼦オブジェクトが返す結果は、基本的にテーブルの⾏となります (サーチが変換
サーチでない場合を除く、その場合はルートイベントオブジェクトおよびその⼦オブジェクトと同様にイベントが
返されます)。
注意： 可能な場合は、オブジェクト階層の作成にルートサーチオブジェクトを使⽤しないようにすることをお勧
めします。ルートサーチオブジェクトとその⼦は、データモデル⾼速化の恩恵を受けることができません 。さ
まざまな種類のサーチを、ルートイベントオブジェクトとして設定できます。詳細は、後述する「ルートサーチオ
ブジェクトを作成しない状況」を参照してください。
データモデルにルートサーチオブジェクトを追加するには、データモデルエディタで [オブジェクトの追加] をク
リックして、[ルートサーチ] を選択します。[サーチオブジェクトの追加] ページに移動します。
ルートサーチオブジェクトに、[オブジェクト名] 、[オブジェクト ID] 、およびサーチ⽂字列を指定します。
ページの下部にあるセクションでサーチ結果をプレビューするには、⾍眼鏡アイコンをクリックしてサーチを実⾏
するか、またはサーチバーにカーソルを置いてキーボードの Enter キーを押してください。
[オブジェクト名] フィールドには、アスタリスク以外の任意の⽂字を使⽤できます。また⽂字間に空⽩⽂字を使
⽤することもできます。ここに⼊⼒した⽂字列が、[オブジェクトを選択してください] ページやデータモデルオブ
ジェクトが記載される他の場所に表⽰されます。
[オブジェクト ID] は、オブジェクトに対して⼀意でなければなりません。スペースを⼊れることはできませ
105
ん。または英数字、アンダースコア、またはハイフン (a〜z、A〜Z、0〜9、_、または -) 以外の⽂字は使⽤でき
ません。⽂字の間にスペースを使⽤することもできません。オブジェクト ID を保存した後に、値を変更するこ
とはできません。
サーチ⽂字列の指定⽅法の詳細は、『サーチマニュアル』を参照してください。
ルートサーチオブジェクトを作成しない状況
前述のように、ルートイベントオブジェクトを使って同じ⽬的のモデルを作成できる場合は、ルートサーチオブ
ジェクトの使⽤を避けるようにしてください。ルートイベントオブジェクトには、ルートサーチオブジェクトと⽐
べて⼤きな利点があります。イベントオブジェクト階層は⾼速化できますが、サーチオブジェクト階層を⾼速化す
ることはできません。データモデルを⾼速化した後に、そのモデルからオブジェクトを選択してピボット操作 (グ
ラフ視覚エフェクトの⽣成など) を実⾏すると、イベントオブジェクト階層からのオブジェクトを使⽤した場合
は、サーチオブジェクト階層からのオブジェクトを使⽤した場合に⽐べて、⼤幅に短い時間で処理が完了します。
以下の場合は、ルートサーチオブジェクトを作成しないでください。
サーチに eval、rex、または lookup コマンドのみが含まれている場合 (またはこれらの 3 つのコマンドの組
み合わせ)。このようなサーチは、ルートイベントサーチでも、Eval 式、正規表現、およびルックアップ属
性を使って設定することができます。
たとえば、以下のようなサーチを例に考えてみましょう。
sourcetype=access_* | eval userid=clientip+useragent
ルートイベントオブジェクトでこのサーチを利⽤するには、まずオブジェクトに制約 sourcetype=access_* を
定義します。このオブジェクトを保存したら、次にデータモデルエディタを使って、オブジェクトにEval
式属性定義 userid=clientip+useragent を追加します。
データモデル⾼速化機能を利⽤したいけれども、.conf ファイルに設定したコマンドを使って、イベントのイ
ンデックス作成に応じて⾃動的にコマンドを実⾏したい場合。フィールドを抽出するコマンドの多くは、こ
の⽅法で設定することができます。この場合、データモデルの定義時に、抽出されたフィールドを⾃動抽出
属性として利⽤できます。
フィールド抽出のために、多くのコマンドを props.conf および transforms.conf ファイルに設定するこ
とができます。
また、普段は multikv コマンドを使って .csv ファイルなどからフィールドを抽出している場合は、.csv
ファイルがインデックス処理されるに応じてフィールドを抽出するように、multikv.conf を設定するこ
とができます。
ルートレベルオブジェクトを⾼速化する必要がない場合は、定義⽤のサーチにこれらのコマンドを使
⽤するルートサーチオブジェクトを作成することができます。
ピボット内で折れ線または⾯グラフを作成する場合。これらのタイプのグラフでは、_time が⾃動抽出属性で
なければなりません。ルートサーチオブジェクトは、変換サーチのテーブル⾏を返すようになっているた
め、_time を属性として⾃動抽出することはありません。
サーチが、単純な transaction サーチの場合。ルートトランザクションオブジェクトとして設定してくださ
い。
Splunk イベントに直接マップしないサーチの場合は、ルートサーチオブジェクトを作成する必要がありま
す。 別の⾔い⽅をすれば、イベントのフォーマットではない⼊⼒または出⼒を含むサーチのことです。これに
は、以下のようなサーチが含まれます。
stats、chart、および timechart
などの変換コマンド を利⽤する。変換コマンドは、返されるデータをイベン
トリストではなくテーブルに編成します。
その他のイベントを返さないコマンドを使⽤する場合。
lookup 以外のコマンドを使って、Splunk 以外の外部ソースからデータを取得する場合。このデータに
は、host、source、sourcetype、または _time などの、デフォルトのフィールドがあることが保証されないた
め、イベントではマップできません。たとえば、inputcsv コマンドを使って外部の .csv ファイルから情報を
取得する場合などが挙げられます。
データモデルへの⼦オブジェクトの追加
ルートオブジェクトや他の⼦オブジェクトに、⼦オブジェクトを追加することができます。⼦オブジェクトは、親
オブジェクトの制約と属性をすべて継承します。ある 1 つのオブジェクトを、複数の⼦オブジェクトに関連付け
ることができます。
新しい⼦オブジェクトの定義時には、それに新たに 1 つまたは複数の制約を追加して、そのオブジェクトが表す
データセットを絞り込みます。たとえば Web Intelligence データモデルに、すべての Web サーバーアクセスイ
ベントを取得する、ルートイベントオブジェクト HTTP Request がある場合、それに 3 つの⼦イベントオブジェ
クト HTTP Success、HTTP Error、および HTTP Redirect を追加することができます。 各⼦イベントオブジェ
クトは、HTTP Request データセットの特定のサブセットに注⽬しています。
⼦イベントオブジェクト HTTP Success は、追加の制約 status = 2* を使って、成功した Web サーバーア
クセスイベントに絞り込んでいます。
HTTP Error は、追加の制約 status = 4* を使って、失敗した Web サーバーアクセスイベントに絞り込んで
います。
HTTP Redirecr は、追加の制約 status = 3* を使って、リダイレクトされた Web サーバーアクセスイベン
トに絞り込んでいます。
親オブジェクトから継承された属性以外の属性の追加は省略することができます。属性定義の詳細は、後述の
「データモデルエディタを使ったオブジェクト属性の管理」を参照してください。
データモデルに⼦オブジェクトを追加するには、データモデルエディタで左側のオブジェクト階層から親オブジェ
クトを選択して、[オブジェクトの追加] をクリックし、[⼦] を選択します。[⼦オブジェクトの追加] ページに移
動します。
106
⼦オブジェクトの [オブジェクト名] および [オブジェクト ID] を指定します。
[オブジェクト名] フィールドには、アスタリスク以外の任意の⽂字を使⽤できます。また⽂字間に空⽩⽂字を使
⽤することもできます。ここに⼊⼒した⽂字列が、[オブジェクトを選択してください] ページやデータモデルオブ
ジェクトが記載される他の場所に表⽰されます。
[オブジェクト ID] は、オブジェクトに対して⼀意でなければなりません。スペースを⼊れることはできませ
ん。または英数字、アンダースコア、またはハイフン (a〜z、A〜Z、0〜9、_、または -) 以外の⽂字は使⽤でき
ません。⽂字の間にスペースを使⽤することもできません。オブジェクト ID を保存した後に、値を変更するこ
とはできません。
⼦オブジェクトの [制約] を定義したら、[プレビュー] をクリックして、指定した制約で⽬的のイベントが正しく
返されるかどうかをテストすることができます。
データモデル設計のベストプラクティス
⽬的通りの機能を発揮するデータモデルを作成するには、しばらくの間試⾏錯誤を繰り返さなければならないこと
もあります。ここには、データモデルを設計するために役⽴ついくつかのヒントを記載しています。
データモデル⾼速化の恩恵を受けるために (そして最適化を容易にするために)、可能な場合はルートイベ
ントオブジェクトを使⽤してください 。
可能な限りオブジェクト階層の深さを最低限に抑えてください。 ツリー階層が深くなると、制約ベース
のフィルタリングは⾮効率的になります。
もっとも階層が深いツリーを持つ (そして⼀致する結果がもっとも多い) ルートイベントオブジェクト
を最初に配置してください。 データモデル⾼速化機能は、最初のルートイベントオブジェクトとその⼦に
のみ適⽤されます。
⾼速化するルートイベントオブジェクトの制約を定義する際には、可能な限り選択元のインデックス
を含めるようにしてください。 データモデルがすべてのインデックスをサーチしないようにすると、デー
タモデル⾼速化の効率が向上します (デフォルトでは、インデックスが含まれていないとすべてのインデッ
クスがサーチされます)。
属性フラグを活⽤して、各オブジェクトで公開する属性を選択的に制限することができます。 オブ
ジェクトによって、異なる属性を表⽰/⾮表⽰にすることができます。⼦オブジェクトで、親オブジェクトで
公開しているのとはまったく別の属性セットを公開することもできます。そうすることで、ピボットユー
ザーがグラフやテーブルを作成する際に、属性の多さや⾒知らぬ属性でまごつかないようにすることができ
ます。また、選択したオブジェクトに対応した、適切な属性のみを表⽰することにもなります。
既存のダッシュボードやサーチをデータモデルにリバースエンジニアリングしてください。 そうする
ことが⽬的のデータモデルを作成するための近道になることもあります。ピボット由来のパネルで作成され
たダッシュボードの⽅が、保守管理が簡単です。
新しいデータモデルの設計時には、まずピボットを利⽤するユーザーが何を望んでいるのかを理解す
るようにしてください。 そこから、順番に設計作業を⾏っていきます。モデルの構造は、ユーザーのニー
ズと⽬的に基づいて決定する必要があります。
オブジェクト属性の定義
このトピックでは、データモデルオブジェクト の属性 の追加と編集について説明していきます。オブジェクト属
性は、オブジェクトが表しているデータセットに関連するフィールドです。ピボットユーザーがレポートを定義、
⽣成する際に取り扱う、⼀連のフィールドを提供しています。
属性はオブジェクトデータセット内に存在することも、ルックアップや eval 式を使って⽣成し、データセットに
追加することもできます。
オブジェクト属性の作成と管理には、データモデルエディタを使⽤します。これを使って、以下の作業を⾏えま
す。
新しい属性を作成する。
継承されない既存の属性を更新または削除する。
継承された属性の特定の設定に優先する設定を⾏う。
107
注意： このトピックでは、オブジェクト属性の背後にある概念の詳細については取り上げません。現在までにま
だデータモデル属性に関する作業を⾏ったことがない場合は、このマニュアルの「データモデルについて」を参照
してください。
データモデルエディタを使って、データモデルオブジェクト階層の構築、オブジェクトデータセットの定義 (制
約、サーチ⽂字列、またはトランザクション定義を指定する)、オブジェクト名の変更、オブジェクトの削除など
の作業を⾏うこともできます。データモデルエディタを使ったこれらの作業については、「データモデルとオブ
ジェクトの設計」を参照してください。
新しいデータモデルの作成と管理については 、このマニュアルの「データモデルの管理」を参照してくださ
い。データモデル管理ページでの新しいデータモデルの作成⽅法のほかに、このトピックではデータモデルの権限
と⾼速化の管理⽅法についても説明していきます。
オブジェクト属性の概要
オブジェクト属性は、ピボットユーザーによるレポートの定義、⽣成に⽤いられる、⼀連のフィールドを提供して
います。
データモデル内のオブジェクトに対して、5 種類の属性を定義することができます。
⾃動抽出： Splunk Enterprise がインデックス時とサーチ時に抽出するフィールドを表しています。⾃動抽
出属性は、ルートオブジェクトにのみ追加できます。⼦オブジェクトは、それらを継承することのみ可能で
す。⾃動抽出された属性を⼦オブジェクト独⾃の属性として追加することはできません。⾃動抽出属性には
以下のものが含まれます。
Splunk Enterprise が⾃動的に認識、抽出する、uri や version のようなフィールド。これには、
CSV、IIS、および JSON ファイルの構造化データ⼊⼒経由でインデックス作成されたフィールドが含
まれます。
[設定] または props.conf で定義した、フィールド抽出 、ルックアップ 、または計算済みフィール
ド。
現在オブジェクトデータセット内には存在していないが、将来的には存在する、属性に⼿動で追加し
たフィールド。inputcsv や dbinspect などの⽣成コマンドでオブジェクトデータセットに追加された
フィールドを含めることができます。
Eval 式： 属性定義に⼊⼒した eval 式から得られるフィールドです。Eval 式にはしばしば 1 つまたは複数
の抽出されたフィールドが含まれます。
ルックアップ： 属性定義に設定したルックアップ を使って、オブジェクトデータセット内のイベントに追
加されたフィールドです。ルックアップ属性を定義する場合、[設定] で定義した任意のルックアップを使⽤
して、オブジェクトにすでに関連付けられている他の属性にそれを関連付けることができます。
正規表現： 属性定義に指定した正規表現を使ってオブジェクトのイベントデータから抽出されるフィールド
を表しています。
GeoIP： 有効な IP アドレスを持つ、オブジェクトのデータセット内のイベントに、緯度、経度、国、市な
どの地域フィールドを追加する、特別なタイプのルックアップです。地図に関連する視覚エフェクトを利⽤
する場合に役⽴ちます。
オブジェクト属性の仕組み、属性が必要な理由など、オブジェクト属性の概要については、このマニュアルの
「データモデルについて」を参照してください。
属性のカテゴリ
データモデルエディタは、属性を 3 つのカテゴリに分類しています。
継承 - すべてのオブジェクトには、いくつかの継承された属性があります。⼦オブジェクトは、親オブジェ
クトの属性をすべて継承します。ルートイベント、サーチ、およびトランザクションオブジェクトは、デ
フォルトで⼀連の継承した属性を保有しています。
抽出 - ⾃動抽出されてオブジェクトに追加された属性が、このカテゴリに表⽰されます。
計算済み - 計算またはルックアップにより⽣成された属性が、このカテゴリに表⽰されます。オブジェクト
に eval 式、正規表現、ルックアップ、および Geo IP 属性タイプを追加する場合、それらはこの属性カテゴ
リに表⽰されます。
108
属性の順序と属性の連鎖
データモデルエディタでは、計算済み属性の順序を変更することができます。Splunk Enterprise は常にリストの
上から下への降順に属性を処理するため、この機能は特定の順序で処理する必要がある⼀連の属性がある場合など
に役⽴ちます。
たとえば、2 つの⾃動抽出された属性の値を使⽤する eval 式を作成することができます。Splunk は抽出した属
性を常に計算済み属性の上に配置するため、この場合は何も⼿を加えずに正しい順序で属性が処理されます。ただ
し、eval 式属性をルックアップ属性の⼊⼒として使⽤したいような場合もあります。eval 式属性とルックアップ
属性は両⽅とも計算済み属性に分類されるため、計算済み属性の順序で eval 式属性が確実にルックアップ属性の
上になるように設定しなければなりません。
これらの属性の順序は以下のようになります。
⾃動抽出属性 1
⾃動抽出属性 2
eval 式属性 (2 つの⾃動抽出属性の値でフィールドを計算する)
ルックアップ属性 (eval 式属性を⼊⼒として使⽤)
属性を⾮表⽰または必須に設定する
デフォルトでは、すべてのオブジェクトが表⽰され、オプションとなっています。
表⽰ 属性は、その属性が所属するオブジェクトを利⽤するピボットユーザーに表⽰され、利⽤することがで
きます。たとえば、HTTP リクエストオブジェクトで url 属性が表⽰するように設定されている場合を考え
てみましょう。ユーザーがピボットで HTTP リクエストオブジェクトを選択すると、ピボットレポートの定
義時に url 属性を使⽤できます。
オプション 属性は、そのオブジェクトが表しているデータセット内の各イベントに存在している必要はあり
ません。つまり、その属性を含まないイベントが、オブジェクトデータセット内に多数存在していることも
あります。
これらの設定はそれぞれ⾮表⽰および必須に変更することができます。そうすると、オブジェクトの属性リストで
それぞれが⾮表⽰または必須としてマークされます。
ピボットユーザーがピボットコンテキスト内でオブジェクトを選択した場合、⾮表⽰ 属性はユーザーに表⽰
されません。ピボットレポートを定義する⽬的で利⽤することはできません。
この設定を利⽤すれば、データモデル内の各オブジェクトに対して異なる属性のサブセットを表⽰す
ることができます (ただし、すべてのオブジェクトは単⼀の親オブジェクトから同じ属性セットを継承
します)。これにより、オブジェクトが表しているデータセット内の特定のコンテキストにおいて意味
をなす属性のみを、ピボットユーザーに利⽤させることができます。
他の属性を定義する⽬的でのみ使⽤されるフィールド属性は、⾮表⽰にすることができます (前述の
「属性の順序と属性の連鎖」を参照)。属性チェーン内の最初の属性をピボットユーザーに表⽰する必
要がないこともあります。
必須 属性は、オブジェクトが表している各イベントに存在する必要があります。これにより、属性を持たな
いイベントは除外されます。実質的にこれは、オブジェクトに関連付ける正式な制約 の上位に存在する、別
の種類の制約です。
これらの属性設定は、データモデル内の各オブジェクトに固有です。つまり、親オブジェクトで ip_address 属性を
必須にしても、その下位にある⼦オブジェクトではオプションとして設定することができます。データモデル内の
すべてのオブジェクトが同じ属性を持つ場合でも (属性は最上位のルートオブジェクトで設定され、階層内の他の
オブジェクトに単純に継承される)、⾮表⽰または必須を設定した属性は、データモデル内のオブジェクトごとに
異なる場合があります。
注意： データモデル内の各オブジェクトの同じ属性に対して、異なる「表⽰/⾮表⽰」および「オプション/必
109
須」設定を⾏える機能には、1 つの例外があります。親オブジェクトで「計算済み」属性に分類されている、
継承した属性に対しては、これらの設定を変更することはできません。 この種の属性では、親オブジェクトで
属性の設定を変更することによってのみ、設定を変更することができます。変更内容は、その親オブジェクトの下
位にある⼦オブジェクトに反映されます。
これらの値は、抽出属性と計算済み属性を最初に定義する際に設定することができます。定義後に、属性の名前や
タイプを変更することもできます。
1. 継承カテゴリ内の属性の [上書き] をクリックするか、または抽出または計算済みカテゴリ内の属性の [編集] を
クリックします。
2. [フラグ] フィールドの値を適切な値に変更します。
3. 変更内容を保存するには、[保存] をクリックします。
[⼀括編集] リストを使って、複数の属性の「表⽰/⾮表⽰」および「オプション/必須」設定をまとめて変更する
ことができます。
1. 編集する属性を選択します。
2. [⼀括編集] をクリックして、[オプション]、[必須]、[⾮表⽰]、または [表⽰] を選択します。
[必須] または [⾮表⽰] を選択した場合、適切な属性が更新され、属性に対して設定されたステータスが反映
されます。親オブジェクトで「計算済み」属性に分類されている、継承した属性に対しては、これらの値を
変更することはできません。詳細は、前述の注意 事項を参照してください。
属性名とタイプの⼊⼒または更新
データモデルエディタでは、抽出 および計算済み カテゴリ内の属性に、任意の表⽰名 を指定することができま
す。また、そのような属性のタイプ を指定することもできます (Splunk が属性に⾃動的にタイプ の値を割り当て
る場合でも)。
Splunk Enterprise は、⾃動抽出した属性に、タイプ の値を割り当てます。Splunk が⾃動抽出した属性のタイ
プ 値を誤って設定した場合は、正しい値を設定することができます。たとえば、⾃動抽出フィールド属性で利⽤可
能な値に基づいて、実際には⽂字列タイプのなのに、Splunk Enterprise がそれを数字タイプの属性と判断するこ
とがあります。そのような場合は、[タイプ] の値を [⽂字列] に変更することができます。
⾃動抽出された属性の表⽰名 を変更しても、Splunk Enterprise インデックス内の関連フィールドの命名⽅法は変
化しません。単にこのデータモデルのコンテキスト内で名前が変更されます。
1. 名前 またはタイプ を変更する属性の [編集] をクリックします。
2. 名前 またはタイプ を変更します。[名前] の値にアスタリスクを使⽤することはできません。
3. 変更内容を保存するには、[保存] をクリックします。
複数の属性に同じタイプ 値を設定するには、[⼀括編集] を使⽤します。
1. 編集する属性を選択します。
2. [⼀括編集] をクリックして、[論理値]、[IPv4]、[数字]、[⽂字列]、または [時間] を選択します。
選択したすべての属性の [タイプ] 値が、選択した値に更新されます。
注意： 継承した属性のタイプ 値は変更できません。継承した属性を選択しても、[⼀括編集] リストの [タイプ]
値は利⽤できません。
⾃動抽出された属性の追加
⾃動抽出された属性を、データモデルのルートオブジェクトに追加することができます。
110
1. データモデルエディタで、⾃動抽出された属性を追加するルートオブジェクトを開きます。
2. [属性の追加] をクリックし、[⾃動抽出] を選択して⾃動抽出属性を定義します。
[⾃動抽出フィールドの追加] ダイアログが表⽰されます。これには、データモデルに⾃動抽出属性として追
加できるフィールドのリストが含まれています。
3. データモデルに追加する属性のチェック ボックスを選択します。
ヘッダーにあるチェック ボックスを選択すると、リスト内のすべてのフィールドを選択できます。
リストに⽬的のフィールドが記載されていない場合は、イベントのサンプルサイズを変更してください。デ
フォルトでは、[最初の 1,000 件のイベント] が設定されています。イベントのサンプル数を⼤きくすると、
最初の 1000 件のイベントでは表⽰されない希なフィールドが表⽰される可能性があります。たとえば、サ
ンプルサイズを「最初の 10,000 件」または「過去 7 ⽇間」のイベントに設定することができます。
4. (オプション) ⾃動抽出フィールドの名前を変更 します。
[名前の変更] を使⽤する場合、新たなフィールド名にアスタリスクは使⽤しないでください。
5. (オプション) ⾃動抽出フィールドのタイプ を修正します。
6. (オプション) ⾃動抽出フィールドのステータス (オプション、必須、⾮表⽰、または⾮表⽰と必須) を必要に応
じて変更します。
7. [保存] をクリックして、選択した属性をルートオブジェクトに追加します。
注意： ⾃動抽出属性を⼦オブジェクトに追加することはできません。⼦オブジェクトは、オブジェクト階層の最
上位にあるルートオブジェクトから⾃動抽出属性を継承します。
[⾃動抽出フィールドの追加] ダイアログには、以下のフィールドのリストが含まれています。
Splunk Enterprise が⾃動的に認識、抽出する、uri や version のようなフィールド。これには、インデック
ス作成された CSV ファイルのヘッダーから抽出されたフィールドなどの、構造化データ⼊⼒からインデッ
クス作成されたフィールドが含まれます。
[設定] または props.conf で定義した、フィールド抽出 、ルックアップ 、または計算済みフィールド 。
フィールドの⾏を展開すると、上位 10 件のサンプル値が表⽰されます。
⼀連の⾃動抽出フィールドへのフィールドの⼿動追加
データモデルの作成時に、特定の⾃動抽出フィールドが失われていることに気が付く場合があります。このような
状況は、さまざまな理由で発⽣します。例：
データセットを構成するデータのインデックス作成前に、データモデルを作成した。
データのインデックスを作成しているけれども、⽬的の希なフィールドの⼀部が、まだインデックスが作成
されていない。
このリストに表⽰されないフィールドを追加する、inputcsv のような⽣成サーチコマンドを使⽤している。
⾃動抽出属性を、ルートオブジェクトに⼿動で追加できます。
注意： ⼿動でフィールドを追加する前に、まず前述の⼿順のようにイベントのサンプルサイズを増やすことをお
試しください。最初の 1000 件には存在していなかった、希なフィールドが表⽰されます。
111
1. [⾃動抽出フィールドの追加] ダイアログの右上にある、[名前で追加] をクリックします。
フィールドテーブルに⾏が追加されます。このトピックの最初の例で、⼿動で追加した ISBN フィールド⽤
に⾏が追加されたことに注意してください。
2. この⾏に、⾃動抽出属性のフィールド名 、タイプ 、およびステータスを⼿動で指定します。
3. もう⼀度 [名前で追加] をクリックして、追加の属性⾏を追加します。
4. 追加した⾏を削除するには、⾏の右上にある [X] をクリックします。
5. 変更内容を保存するには、[保存] をクリックします。
テーブルに追加した任意のフィールドが、および選択した⾃動抽出フィールドが、ルートオブジェクトの抽
出カテゴリに追加されます。
eval 式属性の追加
eval 式属性は、データモデル内の任意のオブジェクトに追加することができます。この属性タイプは計算済み
フィールド と同様の⽅法で、eval 式を使ってオブジェクトデータセット内のイベントに追加できるフィールドを
作成します。
1. データモデルエディタで、属性を追加するオブジェクトを開きます。
2. [属性の追加] をクリックします。eval 式属性を定義するには、[eval 式] を選択します。
[Eval 式で属性を追加] ダイアログが表⽰されます。
3. 属性値を定義する eval 式 を⼊⼒します。
[eval 式] には、eval 構⽂の <eval-expression> 部のみを指定する必要があります。サーチで使⽤する構⽂全
体 (eval <eval-field>=<eval-expression>) を⼊⼒する必要はありません。
4. [属性] で、属性の [フィールド名] と [表⽰名] を⼊⼒します。
[フィールド名] は、オブジェクトデータ内の属性の名前です。[表⽰名] は、ピボットユーザーによるピ
ボットの作成時に表⽰される属性名です。注意： [フィールド名] に、空⽩⽂字、単⼀引⽤符、⼆重引⽤
符、波括弧、またはアスタリスクを含めることはできません。属性の表⽰名 にアスタリスクを使⽤すること
はできません。
5. 属性のタイプ とフラグ を設定します。
[フラグ] の値の詳細は、このマニュアルの「オブジェクト属性の定義」にある、⾮表⽰や必須の設定に関す
るセクションを参照してください。
6. (オプション) [プレビュー] をクリックして、eval 式が想定通りに機能していることを確認します。
新しい eval 属性が列として含まれた、表形式のイベントが表⽰されます。たとえば、イベントベースのオ
ブジェクトに対して作業を⾏っており、eval 属性 gb を追加した場合、イベントテーブルのプレビューに
は、最初の列 (_time ) の右側に「gb 」という名前のラベルが表⽰されるはずです。
112
プレビューパネルには、2 つのタブがあります。デフォルトのタブは、[イベント] です。ここには、イベン
トが表形式で表⽰されます。新しい eval 属性は、最初の列 (_time 列) の右に表⽰されます。
この列に値が表⽰されない場合、またはリストの上部のイベントに同じ値が繰り返し表⽰される場合、サン
プルの後半にはより多くの値が登場する可能性があります。[値] タブを選択して、選択したイベントサンプ
ル内での eval 属性値の分布を確認してください。[サンプル] の値を変更してプレビューサンプルのイベン
ト数を増やすこともできます。そうすることにより、eval 式が作成したフィールドの希な値を発⾒できる可
能性があります。
以下の例では、[サンプル] を [最初の 1,000 件のイベント] から [最初の 10,000 件のイベント] に増やした
場合の値分布に、3 つのリアルタイムサーチのみが登場しています。
7. [保存] をクリックして、変更内容を保存して、データモデルエディタに戻ります。
コマンドおよび eval 式の指定形式の詳細は、eval 式に関するページおよび『サーチリファレンス』の「eval
と where の関数」を参照してください。
eval
eval 式は、すでに定義または計算された属性を活⽤することができます (属性を連鎖 (チェーン) できる)。
Splunk Enterprise は、記載されている順番に上から下へと属性を処理します。そのため、前提条件となる属性
は、それらの属性を使⽤する eval 式属性の上に配置する必要があります。つまり、計算 A に依存する 計算 B が
ある場合、属性リスト内の順序で計算 A を計算 B よりも先に配置する必要があります。詳細は、このマニュアル
の「オブジェクト属性の定義」に記載されている属性の順序と連鎖に関するサブセクションを参照してください。
eval 式属性定義内では、任意のタイプの属性を使⽤することができます。たとえば、⾃動抽出属性と他の eval 式
属性を使⽤する eval 式属性を作成することができます。使⽤する属性が作成する属性の上にある限り、その属性
は正常に機能します。
定義内で他の属性値を使⽤する eval 式属性を作成する場合、必要に応じてそれらの他の属性を「⾮表⽰」にする
ことができます ([フラグ] に [⾮表⽰] を設定)。そうすることにより、最終的な eval 式の値のみをピボットユー
ザーに利⽤させられます。
ルックアップ属性の追加
ルックアップ属性は、データモデル内の任意のオブジェクトに追加することができます。
ルックアップ属性を作成するには、[設定] > [ルックアップ] > [ルックアップ定義] で、最低 1 つのルック
アップ定義 を定義する必要があります。ルックアップ定義は、Splunk Enterprise にルックアップテーブルの場
所と接続⽅法を指⽰します。接続⽅法としては、Splunk Web でアップロードしたテーブルベースの CSV ファイ
ルへの直接接続、または Python スクリプトを使⽤した外部ルックアップテーブルへの接続を利⽤できます。ルッ
クアップ定義を作成すると、Splunk Enterprise は指定された属性の値をルックアップテーブル内のフィールド値
と照合し、対応するフィールド/値のペアをオブジェクトに、ルックアップ属性として適⽤します。
注意： ルックアップ属性で使⽤するルックアップテーブルファイルとルックアップ定義には、データモデルと同
じ権限を持つ必要があります。データモデルの権限がグローバル (すべての App と共有) だけれども、ルックアッ
プテーブルファイルまたは定義がプライベートの場合、その属性は利⽤できません。(⼀般的にデータモデルと関
連するルックアップテーブルファイル/定義は、すべての App とグローバルに共有する必要があります。)
ルックアップ定義の作成 (および CSV ファイルのアップロード) ⽅法の詳細は、「フィールドルックアップを使っ
たイベントへの情報の追加」を参照してください。
113
1. データモデルエディタで、ルックアップ属性を追加するオブジェクトを開きます。
2. [属性の追加] をクリックして、[ルックアップ] を選択します。
[ルックアップで属性を追加] ページに移動します。
3. [ルックアップテーブル] で、⼊⼒属性を照合するルックアップテーブルを選択します。
[ルックアップテーブル] リスト内のすべての値が、以前に [設定] で定義されているルックアップ定義 で
す。
有効なルックアップテーブルを選択すると、ページに [⼊⼒] および [出⼒] セクションが表⽰され、値が⾃
動的に設定されます。[出⼒] セクションには、選択したルックアップテーブル のすべての列のリストが表
⽰されます。
4. [⼊⼒] で、ルックアップ⼊⼒フィールドを定義します。[ルックアップ内のフィールド] を選択し (選択し
たルックアップテーブル からのフィールド)、編集しているオブジェクトの対応する属性 を選択します。
[⼊⼒] ルックアップテーブルのフィールド/属性の組み合わせは、ルックアップテーブル内の⾏を選択する
キーとなります。この⼊⼒キーが選択する各⾏に対して、その⾏からの出⼒フィールド値を⽣成して、⼀致
するイベントにそれを追加することができます。
たとえば、オブジェクトイベントデータ内に⾃動抽出された Product ID 属性に⼀致する、productId ルック
アップテーブル内のフィールド値がオブジェクトに存在している場合があります。ルックアップテーブルの
フィールドとオブジェクト属性は、同じ (またはとても似ている) 値セットを持つ必要があります。⾔い換え
れば、ルックアップテーブルに productId の値が PD3Z002 の⾏がある場合、オブジェクトデータセットには
Product ID = PD3Z002 のイベントがあるはずです。これらの⼀致するイベントは、productId の値が PD3Z002 の
⾏からの出⼒フィールド/値の組み合わせで更新されます。このプロセスの詳細は、「ルックアップ属性の設
定例」を参照してください。
特定の⼊⼒キーで、ルックアップテーブルの複数の⾏が⼀致した場合、最初に⼀致する⾏のみが返されま
す。⼀致する⼀連の⾏を絞り込むために、必要に応じて複数の⼊⼒フィールドのペアを定義することができ
ます。これらの⼊⼒キーはすべて、それを選択してそこから出⼒フィールドの値を返すために、Splunk
Enterprise の⾏と⼀致する必要があります。複数の⼊⼒がある場合、[ルックアップ内のフィールド] の値
を再利⽤することはできません。
5. [出⼒] で、オブジェクトデータセットの対象イベントに、新しいルックアップ属性として追加するフィールド
を決定します。
ここには、選択したルックアップテーブル内の列から抽出した、フィールドのリストがあるはずです。まず
イベントに追加するフィールドを選択します。⼊⼒として指定したルックアップフィールドは利⽤できませ
ん。.ルックアップ属性定義を有効にするために、最低 1 つの出⼒属性を定義する必要があります。
ここにフィールドが何も表⽰されない場合、指定したルックアップテーブル に問題がある可能性がありま
す。
6. [フィールド名] に、データ内でルックアップ属性が保有するフィールド名を指定します。
[フィールド名] の値に、空⽩⽂字、単⼀引⽤符、⼆重引⽤符、波括弧、またはアスタリスクを含めることは
できません。
7. [表⽰名] に、データモデルエディタおよびピボット内でのルックアップ属性の表⽰名を指定します。
[表⽰名] の値にアスタリスクを使⽤することはできません。
8. 定義する各ルックアップ属性に対して、適切な [タイプ] および [フラグ] を設定します。
[タイプ] フィールドの値の詳細は、このマニュアルの「オブジェクト属性の定義」にある、「属性を⾮表⽰
または必須に設定する」を参照してください。
9. (オプション) [プレビュー] をクリックして、出⼒属性が対象イベントに追加されていることを確認します。
対象イベントとは、その⼊⼒属性値がルックアップテーブル内の⼊⼒負ー値と⼀致するイベントです。詳細
114
対象イベントとは、その⼊⼒属性値がルックアップテーブル内の⼊⼒負ー値と⼀致するイベントです。詳細
は、後述する「ルックアップ属性のプレビュー」を参照してください。
10. ルックアップが予定通りに機能している場合、[保存] をクリックして属性を保存し、データモデルエディタに
戻ります。
新しいルックアップ属性がオブジェクト属性リストの下に追加されます。
ルックアップ属性のプレビュー
ルックアップ属性を設定したら [プレビュー] をクリックして、ルックアップ属性が対象イベント (指定した⼊⼒
属性値がルックアップテーブル内の対応する⼊⼒フィールド値と⼀致するイベント) に追加されたかどうかを確認
することができます。Splunk Enterprise は結果を、複数のタブ付きページに表⽰します。
最初のタブには、ベースとなるサーチで返されたイベントのサンプルが表⽰されます。新しいルックアップ属性
は、最初の列 (_time 列) の右に表⽰されます。最初の数ページのルックアップ属性列に何も値が表⽰されない場
合、それらの値は⾮常に希であることを⽰している可能性があります。残りのプレビュータブを参照することで、
これを確認することができます。
[出⼒] セクションで選択した各ルックアップ属性に対してタブが⽤意されています。各属性タブは、選択したイ
ベントサンプル内の値分布のサマリー情報を提供しています。これにはトップ値のリストがあり、カウント と
パーセンテージで編成されています。
ルックアップ属性の設定例
次の事項が真である場合を考えてみましょう。
⾃動抽出属性 Product ID および他の⾃動抽出属性 Product Name があるデータモデルオブジェク
トを保有している。 ルックアップテーブルを使って、商品の価格を提供するデータセットに新しい属性を
追加したいと考えている。
product_lookup と呼ばれる .csv ファイルを持っている。 このテーブルには、productId や product_name (これ
らは、オブジェクト内の類似の名前を持つ属性と⾮常に似ている値セットを保有している) を含む、製品に
関連する複数のフィールドが存在しています。また、オブジェクトにルックアップ属性として追加する、
ルックアップテーブル内のフィールド price も存在しています。
Product Name は同じだけれども、 Product ID の値と価格が異なっている製品が存在していること
が分かっている。 このことは、Product Name にのみ依存するルックアップ定義を⼊⼒フィールドとして
設定することはできないことを意味しています。ルックアップテーブルからの同じ price 値が、複数の製品
に適⽤されるためです。Product Name と Product ID の両⽅を⼊⼒フィールドとして使⽤するルックアッ
プ属性定義を設計する必要があります。⼀致したイベント内の各値の組み合わせを、同じ名前/ID の組み合
115
わせを持つルックアップテーブル内の⾏と照合します。
このような場合に、price をオブジェクトデータに属性として正しく追加する⽅法を以下に⽰します。
1. [設定] で、product_lookup.csv ルックアップファイルを指すルックアップ定義を作成します。このルックアップ
定義の名前は product_lookup とします。
2. ピボットに移動して、ルックアップ属性を追加するオブジェクトをデータモデルエディタで開きます。
3. [属性の追加] をクリックして、[ルックアップ] を選択します。
[ルックアップで属性を編集] ページが表⽰されます。
4. [ルックアップテーブル] で、[product_lookup] を選択します。
[出⼒] 下には、ルックアップテーブルが追跡しているすべてのフィールドが表⽰されます。
5. [⼊⼒] に、2つの [ルックアップ内のフィールド]/[属性] のペアを定義します。最初のペアの [ルックアップ内
のフィールド] の値は [ProductId]、[属性] の値は [Product ID] にします。2 番⽬のペアの [ルックアップ内の
フィールド] の値は [product_name]、[属性] の値は [Product Name] にします。
最初のペアは、ルックアップテーブルの productId フィールドとオブジェクトの [Product ID] 属性を照合し
ます。2 番⽬のペアは、ルックアップテーブルの product_name フィールドとオブジェクトの [Product
Name] 属性を照合します。この作業を⾏うと、[出⼒] の productID および product_name フィールドの⾏が利
⽤できなくなります。
6. [出⼒] で、price フィールドのチェック ボックスを選択します。
これは、⼀致する⼊⼒属性を持つオブジェクトデータセット内のイベントにそれを追加することを Splunk
Enterprise に指⽰しています。
7. price 属性の表⽰名として、[Price] を指定します。
price
属性は、すでに [タイプ] の値が [数字] になっているはずです。
8. [プレビュー] をクリックして、イベントに
price
が追加されているかどうかをテストします。
プレビューイベントは表形式で表⽰されます。price フィールドはタイムスタンプ (timestamp) の後にある
2 番⽬の列になります。
9. プレビュー結果に
を保存します。
price
フィールドが⽬的通りに表⽰された場合は、[保存] をクリックして、ルックアップ属性
これでピボットユーザーがレポートやダッシュボードを作成する際に、Price を属性オプションとして使⽤できる
ようになりました。
正規表現属性の追加
正規表現属性を、データモデル内の任意のオブジェクトに追加することができます。正規表現属性は、正規表現⽂
字列内の名前付きグループを、個別のデータモデル属性に変換します。正規表現は、_raw イベントテキストからの
属性の抽出、および特定のフィールド値の抽出に利⽤できます。
1. データモデルエディタで、正規表現属性を追加するオブジェクトを開きます。
データモデルエディタの概要については、このマニュアルの「データモデルとオブジェクトの設計」を参照
してください。
2. [属性の追加] をクリックして、[正規表現] を選択します。
116
[正規表現で属性を追加] ページに移動します。
3. [抽出元] で、フィールドの抽出元となる属性を選択します。
[抽出元] リストには、現在オブジェクトにあるすべての属性と _raw が含まれているはずです。正規表現が
特定の属性の値から 1 つまたは複数の属性を抽出するように設計されている場合、[抽出元] リストからその
属性を選択します。イベント⽂字列全体を解析するように正規表現が設計されている場合は、[抽出元] リス
トから [_raw] を選択します。
4. 正規表現 を指定します。
正規表現には、最低 1 つの名前付きグループが必要です。正規表現内のそれぞれの名前付き式が、個別の属
性として抽出されます。属性名に、空⽩⽂字、単⼀引⽤符、⼆重引⽤符、波括弧、またはアスタリスクを含
めることはできません。
正規表現を指定したら、[属性] 下にその名前付きグループが表⽰されます。
注意： 現在正規表現は、sed モードまたは sed 式をサポートしていません。
5. (オプション) 属性の表⽰名 に対して別の値を指定します。
属性の[表⽰名] 値にアスタリスクを使⽤することはできません。
6. (オプション) 属性の [タイプ] の値を修正します。
デフォルトは、[⽂字列] になります。
7. (オプション) 属性の [フラグ] 値を、ご⾃分のニーズに応じた適切な値に変更します。
8. (オプション) [プレビュー] をクリックして、オブジェクトデータセット内での属性の表現を確認します。
属性のプレビューの詳細は、後述する「正規表現属性のプレビュー」を参照してください。
9. 変更内容を保存するには、[保存] をクリックします。
データモデルエディタに戻ります。新しい正規表現属性が計算済みオブジェクト属性リストに追加されま
す。
正規表現の構⽂と使⽤⽅法の概要については、Regular-Expressions.info を参照してください。正規表現をテス
トするには、rex サーチコマンドのを使⽤します。正規表現式を作成、テストするために役⽴つサードパーティ製
ツールのリストも⽤意されています。
正規表現属性のプレビュー
1 つまたは複数のフィールド抽出属性の定義後に [プレビュー] をクリックすると、選択した [抽出元] 属性を持
つデータ セット内のオブジェクトに対して (_raw から抽出する場合は raw データに対して)、正規表現が適⽤さ
れ、結果が表⽰されます。プレビュー結果はセットアップフィールドの下の、4 つ以上の⼀連のタブ付きページに
表⽰されます。これらの各タブが、オブジェクトデータセット内のサンプルイベントから取得された情報を表して
います。[サンプル] リストから [最初の 1,000 件のイベント] または [過去 24 時間] などのオプションを選択する
ことで、このサンプルがどのように決定されたかを確認することができます。また、ページあたりに表⽰するイベ
ント数を指定することもできます (デフォルトは 20)。
プレビューで何もイベントが返されない場合、正規表現を調整する必要があるか、または誤った [抽出元] 属性を
選択した可能性があります。
[すべて] タブ
[すべて] タブを利⽤れば、どれくらいのイベントが正規表現に⼀致しているのかを⼿軽に把握することができま
す。このトピックの最初の⽅には、[すべて] タブの画⾯例が表⽰されています。
これは、データ内に [抽出元] 属性を持つイベントがある、フィルタリングされていないサンプルを表していま
す。たとえば、選択した [抽出元] 属性が uri_path の場合、このタブには uri_path の値を持つイベントのみが表⽰
されます。
最初の列は、イベントが正規表現に⼀致するかどうかを⽰しています。⼀致したイベントには、緑⾊のチェック
マークが表⽰されています。⼀致しないイベントには、⾚い「x」マークが表⽰されます。
2 番⽬の列には、イベント内の [抽出元] フィールドの値が表⽰されます。[抽出元] フィールドが _raw の場合、
イベント⽂字列全体が表⽰されます。残りの列には、正規表現により抽出された属性値が表⽰されます (ある場
合)。
[⼀致] および [不⼀致] タブ
[⼀致] および [不⼀致] タブは、[すべて] タブと似ていますが、正規表現と⼀致するイベントのみを表⽰するか、
または正規表現と⼀致しないイベントのみを表⽰するかという点で異なっています。これらのタブは、サンプル内
のフィールド分布をより的確に把握するために役⽴ちます (特に、サンプル内のイベントの⼤半が、⼀致イベント
または不⼀致イベントのセットに該当する場合)。
117
属性のタブ
正規表現で名前で指定された各属性が、独⾃のタブを保有します。属性のタブは、選択したイベントサンプル内の
値分布のサマリー情報を提供しています。これにはトップ値のリストがあり、カウント とパーセンテージで編成
されています。⽬的の値が表⽰されない場合、または値の分布が期待と違う場合は、正規表現を調整する必要があ
る可能性があります。
また、サンプルサイズを増やしてさらなる過去に登場した希な属性値を探すこともできます。以下の例では [サン
プル] に [最初の 10,000 件のイベント] を設定することで、最初の 1,000 件のイベントだけでは分からない path
属性の値を認識することができます。
属性タブのトップ値テーブルは、ドリル ダウンが有効になっています。⾏をクリックすると、その⾏が表すすべ
てのイベントが表⽰されます。たとえば、path 属性に注⽬しており、パスが /numa/ の 6 件のイベントがある場
合、/numa/ ⾏をクリックして、path="/numa/" の 6 件のイベントを表⽰するリストを参照することができます。
Geo IP 属性の追加
属性リストに [タイプ] が [ipv4] の属性を持つデータモデル内のオブジェクトに、Geo IP 属性を追加することが
できます。ipv4 属性は、Geo IP 属性よりも先に配置する必要があります。また、別の Geo IP 属性の計算に使⽤
されていない必要があります。
Geo IP 属性は、ある種のルックアップです。オブジェクトのイベントの IP アドレス値を読み取り、関連する緯
118
度経度、都市、地域、および国などの値を、そのイベントに追加することができます。
1. データモデルエディタで、属性を追加するオブジェクトを開きます。
2. [属性の追加] をクリックして、[Geo IP] を選択し、Geo IP 属性を定義します。
[IP ルックアップで地域属性を追加] ページが表⽰されます。
3. 選択したオブジェクトに複数の IP 属性がある場合、照合する IP 属性を選択します。
4. オブジェクトに追加する属性を選択します。
5. (オプション) 選択した属性の名前を変更するには、[表⽰名] を変更します。
表⽰名にアスタリスクを使⽤することはできません。
6. (オプション) [プレビュー] をクリックして、GeoIP 属性が選択した GeoIP 属性を持つイベントを正しく更新
していることを確認します。
新しい GeoIP 属性が列として含まれた、表形式のイベントが表⽰されます。たとえば、イベントベースの
オブジェクトを処理しており、GeoIP 属性の市 、地域 、および国 を選択した場合、プレビューイベントテー
ブルの最初の列 ('_time ) の右側には、[市] 、[地域] 、および [国] 列が表⽰されます。
プレビューパネルには、2 つのタブがあります。デフォルトのタブは、[イベント] です。ここには、イベン
トが表形式で表⽰されます。[値] タブを選択して、イベント内での GeoIP 属性値の分布を確認してくださ
い。
予想通りの値範囲が表⽰されない場合は、プレビューイベントのサンプル数を増やしてみてください。デ
フォルトでは、サンプルは最初の 1000 件のイベントに設定されています。[サンプル] を増やすために、
[最初の 10,000 件のイベント] や [過去 7 ⽇間] を設定することができます。
7. 変更内容を保存するには、[保存] をクリックします。
データモデルエディタに戻ります。定義した Geo IP 属性は、オブジェクトの計算済み属性に追加されま
す。
注意： Geo IP 属性は、オブジェクトに [必須] 属性として追加され、[タイプ] の値はあらかじめ決まっていま
す。これらの値を変更することはできません。
サーチとピボットジョブの保存と共有
ジョブとジョブ管理について
サーチの実⾏、ピボットの作成、レポートを開く、またはダッシュボードパネルのロード時には、Splunk
Enterprise システム内でジョブ が作成されます。このジョブには、サーチ、ピボット、レポート、またはパネル
から返されたイベントデータが含まれています。[ジョブ] ページでは、最近使⽤したジョブや以前に保存したジョ
ブを確認することができます。また、Admin または同等の権限を持つロールを保有している場合、[ジョブ] ペー
ジでシステム内のすべてのユーザーのジョブを管理することができます。
[ジョブ] ページにアクセスするには、[アクティビティ] ドロップダウンの [ジョブ] をクリックします。
119
[ジョブ] ページの使⽤⽅法の詳細は、『ナレッジ管理マニュアル』の「[ジョブ] ページによるサーチジョブの管
理」を参照してください。
OS のコマンドラインからジョブを管理することもできます。詳細は、このマニュアルの「OS からのサーチジョ
ブの管理」を参照してください。
注意： サーチジョブと保存済みサーチや保存済みレポートは違う物だということに注意してください。レポート
には、サーチ⽂字列、時間範囲、およびグラフやテーブル視覚エフェクトの書式設定などの、レポートの実⾏に使
⽤されるデータが含まれています。ジョブは、以前に実⾏したサーチやレポートなどの成果物 (結果) です。特定
のサーチ/レポート実⾏の結果が含まれています。ジョブは、スケジュール済みサーチまたはサーチ/レポートの⼿
動実⾏により⽣成されます。
サーチをレポートとして保存する⽅法の詳細は、『レポートマニュアル』の「レポートの作成と編集」を参照して
ください。
ユーザーが実⾏できるジョブの制限
あるユーザーが実⾏できるジョブおよび保管できるジョブ成果物の量を制限するには、そのようにロールを制限し
てそれを⽬的のユーザーに割り当てます。システム内の各ユーザーに⼀意のロールを割り当てることで、きめ細か
く管理することができます。
$SPLUNK_HOME/etc/system/local内の authorize.conf
srchDiskQuota:
のコピーに権限を作成して、適切な値を指定してください。
このロールに所属するユーザーのサーチジョブが利⽤できる最⼤ディスクスペース (MB)。
srchJobsQuota：このロールが利⽤できる同時実⾏サーチの最⼤数。
詳細は、『Splunk Enterprise のセキュリティ』マニュアルの「ロールの追加と編集」を参照してください。
⻑期実⾏しているジョブの⾃動停⽌
予期せずに⻑期間実⾏されているサーチジョブに対処するために、Splunk Enterprise には⾃動停⽌機能が⽤意さ
れています。デフォルトでこの機能は、ユーザーがうっかりと「全時間」サーチを実⾏してしまった場合に対処す
るために、サマリーダッシュボードのクリックに対してのみ有効になっています。
特定のサーチビューの⾃動停⽌を有効にすると、サーチ中にビューに⾃動停⽌のカウントダウンフィールドが表⽰
されます。サーチの時間制限に達すると、ユーザーにサーチが停⽌されたことを知らせる情報ウィンドウが表⽰さ
れます。このウィンドウから、実⾏を再開したり、サーチを終了することができます。デフォルトでは、30 秒で
⾃動停⽌されます。
⾃動停⽌は、ビューの開発者のみが設定可能です。システム全体に対して設定したり、ロールに対して設定したり
することはできません。⾃動停⽌機能を有効/無効にするには、⽬的のビューを編集します。『Developer
manual』の「How to turn off autopause」を参照してください。また、⾃動停⽌の実装例として、サマリーダッ
シュボードの host, source, および sourcetypes リンクを参照してください。
Splunk Web を使ったジョブの保存と共有
サーチの開始後は、[サーチ] ページから移動しないでも、サーチのジョブ に関する情報にアクセスして、管理す
ることができます。サーチの実⾏中、⼀時停⽌中、または完了後、[ジョブ] をクリックして、適切なオプション
を選択します。
120
以下の作業を⾏えます。
ジョブ設定の編集： これを選択すると、[ジョブ設定] ダイアログが表⽰されます。ここでは、ジョブの読み
取り権限の変更、ジョブ寿命の延⻑、および他のユーザーとジョブを共有またはブラウザーのブックマーク
に登録するたに使⽤できるジョブ URL の取得などの作業を⾏えます。
ジョブをバックグラウンドに送る： サーチジョブの完了までに時間がかかるため、バックグラウンドで
ジョブを実⾏し、その間に Splunk Enterprise で他の作業 (新規サーチジョブの実⾏を含む) を⾏いたいよ
うな場合に選択します。
ジョブの調査： 別のウィンドウに、[サーチジョブ調査] を使ったサーチジョブの情報と測定基準を表⽰し
ます。
ジョブの削除： 現在実⾏中、⼀時停⽌中、または完了したジョブを削除する場合に使⽤します。ジョブを削
除しても、サーチをレポートとして保存することができます。
サーチジョブ設定の編集
サーチジョブの実⾏、⼀時停⽌、または完了後、[ジョブ設定] ダイアログを開くことができます。単純に [ジョ
ブ] をクリックして、[ジョブ設定の編集] を選択してください。
サーチジョブの権限の変更
サーチジョブの読み取り権限は、[ジョブ] ページで他のユーザーが特定のジョブを参照してアクセスできるかどう
かを決定します。デフォルトではすべてのジョブの読み取り権限が [プライベート] に設定されています。この場
合、ジョブを実⾏したユーザーのみが、その結果を [ジョブ] ページで参照できます。
[ジョブ設定] ダイアログには、[読み取り権限] スイッチがあり、これを使ってジョブの読み取り権限を [全員] に
切り替えることができます。この権限の適⽤範囲はジョブが実⾏された App コンテキストを対象にしているた
め、[全員] を設定しても実際にはそのジョブが所属している App に対して読み取り権限を持っているユーザー全
員が、[ジョブ] ページでそのジョブを参照できることになります。
ジョブの所有者であるならば、ジョブの読み取り権限を [プライベート] に戻すことも可能です。
[ジョブ] ページの使⽤⽅法の詳細は、このマニュアルの「[ジョブ] ページによるサーチジョブの管理」を参照して
ください。
ジョブ寿命の延⻑によるジョブの保存
新しいサーチジョブを実⾏する場合、デフォルトの寿命は 10 分になります。つまり、システムにジョブが保持さ
れ、[ジョブ] ページでそれを確認できる期間は、最初にジョブを実⾏してから 10 分間となります。その時間が経
過すると、ジョブは失効し、システムから削除されます。
既存のジョブにアクセスすると (たとえば、[ジョブ] ページでジョブを実⾏した場合)、そのジョブの寿命がリセッ
トされ、そのアクセス時から設定されている期間までが新たな寿命となります。この期間は、ジョブの [寿命] 設
定 (後述) を変更しない限り、10 分になります。
ジョブを「保存」するために、[ジョブ設定] ダイアログから [寿命] の設定を [7 ⽇間] に変更することができま
121
す。こうすることで、ジョブは 7 ⽇間保持された後、削除されることになります。
ジョブにアクセスすると常に、その寿命がアクセス時点を起点にリセットされます。ジョブの寿命が 10 分でも 7
⽇間でも、このリセットは⾏われます。そのため、ジョブの寿命を 7 ⽇間に設定した後、4 ⽇後にそれにアクセ
スすると (ジョブが返したデータを参照)、その寿命はリセットされてその時点から 7 ⽇間が新たな寿命になりま
す。
ジョブの調査
サーチまたはピボットで実⾏したジョブに関連するさまざまな測定基準やプロパティを、[サーチジョブ調査] で
確認することができます。[ジョブ] をクリックして、[ジョブの調査] を選択すると、別のウィンドウに [サーチ
ジョブ調査] が表⽰されます。
過去のサーチ/ピボット結果が存在している限り (期限が切れていない限り)、そのジョブのサーチジョブ調査にア
クセスすることができます。
サーチジョブ調査およびそれが提供する情報の詳細は、このマニュアルの「サーチジョブ調査によるサーチプロパ
ティの表⽰」を参照してください。
他のユーザーとのジョブの共有
ジョブのリンクを送信することで、他の Splunk Enterprise ユーザーと素早くジョブを共有することができま
す。他のユーザーにジョブが返した結果を⾒せるような場合に、この⽅法が便利です。これはレポートの共有とは
違うことに注意してください。ジョブを共有すると、特定のサーチ実⾏の結果を共有することになります。
このリンクを取得するには、2 種類の⽅法があります。前述の [ジョブ設定] ダイアログを使⽤する、またはサー
チ/ピボット結果の上に表⽰される共有アイコンを使⽤することができます。共有アイコンを使⽤する場合、その
ジョブの読み取り権限が [全員] に⾃動的に設定され、また寿命が 7 ⽇間に延⻑されます。
どちらの⽅法でも、[ジョブにリンク] が表⽰されます。これをメールに貼り付けて、他の Splunk Enterprise
ユーザーに送信することができます。ただし、[ジョブ設定] ダイアログを使ってリンクを⼊⼿する場合は、ジョブ
の読み取り権限 が [全員] に設定されていることを確認し、また寿命 を [7 ⽇間] に設定してください。ジョブの権
限が [プライベート] になっている場合、他のユーザーがリンクを使ってアクセスすることはできません。リンク
を送信するユーザーは、そのジョブが所属している App を使⽤する権限も持っている必要があります。
122
今後⾃分が再利⽤するためにリンクを保存しておくこともできます。[ジョブにリンク] の右にあるブックマーク
アイコンをクリックして、それをブラウザのブックマーク (お気に⼊り) バーにドラッグしてください。
ジョブデータのファイルへのエクスポート
サーチ/ピボットジョブのイベントデータを CSV、XML、JSON、または raw データファイルにエクスポートし
て、それをアーカイブしたり、サードパーティのアプリケーションで使⽤したりすることができます。そのために
はサーチを実⾏して、次にサーチ/ピボット結果の上部に表⽰される [エクスポート] リンクを選択します。
エクスポートするイベント数の制限値を設定したり、サーチ/ピボットから返されたすべての結果をエクスポート
したりすることができます。サーチによっては膨⼤な数のイベントが返されることがあります。ご⾃分の環境の状
況に応じて注意を払うようにしてください。
[ジョブ] ページでのジョブの管理
[ジョブ] ページを使って、⾃分が保有している任意のサーチをレビュー、管理することができます。Admin また
は同等の権限を持つロールを保有している場合、すべてのユーザーが実⾏したサーチジョブを管理することができ
ます。Splunk Web で利⽤できるこれらのジョブは、[ジョブ] ページからアクセスすることができます。そのため
には、Splunk Web で [アクティビティ] > [ジョブ] を選択します。
[ジョブ] をクリックすると、[ジョブ] ページが表⽰されます。[ジョブ] ページには、サーチジョブの⼀覧が表⽰
されます。[ジョブ] ページに記載されるサーチジョブには、以下のものが含まれます。
最近⼿動実⾏したサーチ/ピボットの結果となるジョブ。
ダッシュボード読み込み時に実⾏されたサーチの成果物となるジョブ。
スケジュール済みサーチ (定期的に実⾏されるサーチ) 実⾏の成果物となるジョブ。
保存されたジョブ。
サーチジョブは、[ジョブ] ページで保存することができます。
サーチをバックグラウンドに移動した場合 も、サーチが完了する前にジョブが⾃動保存されます。
注意： [ジョブ] ページの表⽰時にあるジョブがキャンセルされた場合、ページにそのジョブは引き続き表⽰され
ますが、結果を参照することはできません。[ジョブ] ページを閉じてから再表⽰すると、キャンセルされたジョブ
は表⽰されなくなります。
サーチジョブの寿命
サーチジョブは Splunk Enterprise が⾃動削除するまでの間、[ジョブ] ページに表⽰されます。サーチジョブの
デフォルトの寿命は、それがサーチの⼿動実⾏の結果か、またはスケジュール済みサーチの結果なのかによって異
なります。
⼿動実⾏またはダッシュボードの読み込みによるサーチジョブ
サーチを⼿動実⾏して完了した場合、結果となるサーチジョブのデフォルトの寿命は 10 分です。ダッシュボード
パネルの読み込み時に実⾏されるサーチの成果物の寿命も 10 分です。
サーチジョブを保存することで、寿命を 7 ⽇間に延ばすことができます。サーチジョブは 2 種類の⽅法で保存で
きます。[ジョブ] ページを開いてサーチジョブを⼿動保存するか、またはサーチの実⾏中にバックグラウンドに
123
サーチを移動してください。
注意： 保存したジョブの保持期間を延⻑/短縮したい場合は、limits.conf で [search] スタンザの
の値を適切な値に変更してください。(「ttl」は「有効期間」を表す略語です。)
default_save_ttl
サーチジョブの結果を表⽰した場合 ([ジョブ] ページでジョブをクリックして結果を別のウィンドウに表⽰した場
合)、ジョブの有効期限 (寿命) がリセットされ、表⽰した時点からさらに 7 ⽇間保持されます。
スケジュール済みサーチの結果となるサーチジョブ
スケジュール済みサーチは定期的に実⾏されます。デフォルトでは、スケジュール済みサーチの実⾏間隔の 2 倍
の期間サーチジョブが保存されます。つまり、サーチが 6 時間ごとに実⾏される場合は、サーチジョブは 12 時
間保持されます。
注意： 特定のスケジュール済みサーチの結果となるジョブのデフォルトの寿命は変更することができます。そう
するには、savedsearches.conf に移動して⽬的のスケジュール済みサーチを探し、dispatch.ttl の値を変更してくだ
さい (倍数で指定、スケジュール間隔にこの値を乗じた時間だけ保持されます)。
[ジョブ] ページのコントロール
[ジョブ] ページのコントロールを使って以下の作業を⾏えます。
最近実⾏または保存したジョブの⼀覧の表⽰、およびそれを使ったジョブ統計 (実⾏時間、⼀致イベント
数、サイズなど) の⽐較。Admin ロールまたはそれと同等の権限を保有している場合、最近⽣成されたすべ
てのジョブを表⽰することができます。
処理中のバックグラウンドジョブ (リアルタイムサーチおよび⻑期間実⾏されている履歴サーチを含む) また
はスケジュール済みサーチによるジョブの進捗状況の表⽰。
サーチ/ピボットジョブの保存、⼀時停⽌、再開、完了、削除 (個別にまたは⼀括)。⽬的のジョブの左側に
あるチェックボックスを選択して、ページ下部にある⽬的の操作に対応するボタンをクリックしてくださ
い。
サーチ名またはサーチ⽂字列をクリックして、特定のジョブに対応する結果を表⽰する。結果は別のブラウ
ザウインドウに表⽰されます。
ジョブがまだレポートとして保存されていないサーチに関連付けられている場合、結果はサーチ
ビューに表⽰されます。
ジョブがレポートに関連付けられている場合は、レポートに結果が表⽰されます。
［失効］ 列には、各ジョブがシステムから削除されるまでの時間を表しています。失効の時点以降にサー
チジョブを表⽰または他のユーザーと共有したい場合は、ジョブを保存してください。ただし、ジョブを保
存しても 7 ⽇後には失効することに注意してください (期間内にジョブを表⽰した場合は、その時点から 7
⽇間に有効期間が延⻑されます)。詳細は、上記の「サーチジョブの寿命」を参照してください。
[サーチ] では、[ジョブ] ページに移動しないでも、⾃分が最後に実⾏したサーチまたはレポートジョブを保存する
ことができます (ジョブが失効していない場合)。
[サーチ] ビューでサーチを実⾏した後に、サーチジョブを保存したい場合は、[ジョブ] をクリックし
て、[ジョブ設定の編集] を選択し、[ジョブ設定] ダイアログを表⽰します。ここでは、ジョブの読み取り
権限 の設定 (他のユーザーと共有する場合は [全員] を設定) を⾏えます。調査のためにジョブを保持したい
場合は、[寿命] に [7 ⽇間] を設定します。他のユーザーとジョブを共有する ([権限] に [全員] を設定した場
合) ためにリンクを取得する場合は、[ジョブにリンク] を使⽤します。
注意： ジョブの寿命 を [7 ⽇間] に設定すると、その期間が経過するまでにジョブへのアクセスがなかった場合、
そのジョブは削除されます。アクセスがあった場合は、寿命がリセットされその時点から 7 ⽇間に設定されま
す。
⼿動実⾏したサーチジョブは、サーチの実⾏中に [バックグラウンドに送信] アイコンをクリックして保存
することもできます。この操作によりジョブの寿命が⾃動的に 7 ⽇間に延⻑され、また権限も [全員] に設定
されます。Splunk Enterprise は、他のユーザーと共有するために利⽤できるリンクも提供しています。
詳細は、このマニュアルの「ジョブとジョブの管理について」を参照してください。
サーチジョブ調査によるサーチジョブプロパティの表⽰
124
サーチジョブ調査 は、サーチの処理状況や Splunk が時間をもっとも費やしている所を確認するためのツールで
す。
ここでは、サーチジョブ調査を使ったサーチジョブパフォーマンスのトラブルシューティング、およびイベントタ
イプ、タグ、ルックアップなどのナレッジオブジェクトの働きについて説明していきます。詳細は、このマニュア
ルの「[ジョブ] ページによるサーチジョブの管理」を参照してください。
サーチジョブ調査の使⽤
過去のサーチ結果が存在している限り (期限切れでない限り)、サーチジョブ調査でサーチジョブ を調査すること
ができます。サーチが動作している必要はありません。
サーチを調査するには：
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 は、サーチに⼀致するインデックスフィールドを含むイベントを識別
すると、イベント⾃体を調査してその他の基準に⼀致するかどうかを判断し
ます。これらは同時に処理されます。順次処理されるのではありません。
command.search.index - raw データ内の読み取り場所を判断するため
に、TSIDX ファイルの調査にかかった時間を⽰します。
125
command.search.rawdata - raw データファイルから実際のイベントを
読み取るまでにかかった時間を⽰します。
command.search.typer - イベントタイプの識別にかかった時間を⽰し
ます。
command.search.kv - イベントへのフィールド抽出の適⽤にかかった
時間を⽰します。
command.search.fieldalias - props.conf に基づいた、フィールド名の変
更にかかった時間を⽰します。
command.search.lookups - 既存のフィールドに基づいて、新しい
フィールドを作成するためにかかった時間を⽰します (フィールドルッ
クアップを実⾏)。
command.search.filter - ⼀致しないイベントのフィルタリングにか
かった時間を⽰します (たとえば、フィールドとフレーズ)。
command.search.typer - イベントへのイベントタイプの割り当てにか
かった時間を⽰します。
command.search.tags - イベントへのタグの割り当てにかかった時間を
⽰します。
command.search
使⽤するコマンドのタイプと、呼び出し、⼊⼒数/出⼒数に表⽰される項⽬数には関係があります。イベントを⽣
成するサーチの場合、⼊⼒数は 0 で、出⼒数はある程度のイベント数 X になると予測できます。サーチがサーチ
の⽣成とフィルタリングの両⽅を⾏う場合、フィルタリングには⼊⼒ (⽣成サーチの出⼒ X と等しい) および出⼒
= X となります。合計数は、⼊⼒ = X、出⼒ = 2*X になり、呼び出し回数は倍になります。
ディスパッチされたサーチの実⾏コスト
分散サーチコンポーネント名
説明
dispatch.check_disk_usage
このジョブのディスク使⽤状況の確認に費やされた時間。
dispatch.createProviderQueue
すべてのサーチピアに接続する時間。
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
ジョブのディスパッチディレクトリにある 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)
126
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 になったけれども、サーチが完了さ
れていないかどうかを⽰します。
キーワード
このサーチが使⽤するすべての肯定キーワード。肯定キーワードとは、NOT
句内にはないキーワードです。
label
このサーチが作成したカスタム名。
latestTime
サーチジョブの開始が設定されたもっとも遅い時間。進捗状況を⽰すために
利⽤できます。doneProgress の説明を参照してください。
numPreviews
このサーチジョブで現在までに⽣成されたプレビュー数。
messages
エラーとデバッグメッセージ。
performance
実⾏コスト の他の表記法です。
remoteSearch
各サーチピアに送信されるサーチ⽂字列。
reportSearch
レポートコマンドが使⽤された場合のレポート対象サーチ。
request
サーチが
resultCount
サーチが返す結果数合計。別の⾔い⽅をすれば、スキャンしたイベント数
(scanCount で表される) の中で、実際にサーチ単語に⼀致したサブセット。
resultIsStreaming
サーチの最終結果をストリーミングを使って利⽤できるかどうかを⽰します
(たとえば、変換操作なし)。
resultPreviewCount
最新のプレビュー結果の結果⾏数。
runDuration
サーチ完了までにかかった時間 (秒)。
scanCount
スキャンされたまたはディスクから読み込まれたイベント数。
search
サーチ⽂字列。
searchProviders
通信したすべてのサーチピアのリスト。
sid
サーチ ID 番号。
splunkd
に送信する GET 引数。
127
statusBuckets
最⼤タイムラインバケツ数。
ttl
有効期間、またはサーチジョブの完了後、それが失効するまでの時間。
サーチに関するその他の情報へのリンクを⽰します。これらのリンクは利⽤
できない場合もあります。
その他の情報
タイムライン
フィールドサマリー
search.log
注意： サーチパフォーマンスのトラブルシューティングを⾏う場合、scanCount と resultCount のコストの違い
を正しく理解しておくことが重要です。デンスサーチの場合、scanCount と resultCount は等しくなります
(scanCount = resultCount)。スパースサーチの場合、scanCount は resultCount よりも⼤幅に⼤きな値になり
ます (scanCount >> resultCount)。サーチパフォーマンスを測定する際には、resultCount/時間の⽐ではさほど
正確には表せません。scanCount/時間の⽐を使⽤してください。⼀般的に、scanCount/秒のイベントレートが
10,000〜20,000 イベント/秒の場合に、パフォーマンスは良好とみなされます。
デバッグメッセージ
サーチにエラーがある場合、これらのメッセージはサーチジョブ調査ウィンドウの上部に、DEBUG メッセージ
として表⽰されます (以前のバージョンでは、ダッシュボードのバナーとして表⽰されていた)。たとえば、結果に
⼀部のフィールドが存在しない場合、デバッグメッセージがその旨を通知します。
注意： サーチ完了までは、これらのメッセージは表⽰されません。
サーチジョブ調査の出⼒例
全時間実⾏した dedup サーチの実⾏コスト例を以下の⽰します。
* | dedup punct
[実⾏コスト] パネルのサーチコマンドコンポーネントは、以下のような感じで表⽰されます。
command.search コンポーネントおよびその下にある項⽬は、サーチの
影響を表しています (パイプ⽂字の前のすべて)。
search
コマンド部のパフォーマンス上の
は、search コマンドに渡す前の dedup コマンドの結果処理のパフォーマンス上の影響を表していま
す。command.prededup の⼊⼒カウントは、command.search の出⼒カウントに⼀致し、command.prededup の⼊⼒カウント
は、command.prededup の出⼒カウントに⼀致します。この場合、command.prededup の出⼒カウントは、サーチ完了時
に返されたイベント数と⼀致しなければなりません ([サーチジョブプロパティ] 下の resultCount の値)。
command.prededup
Answers
何か質問がありますか？「Splunk Answers」では、Splunk コミュニティに寄せられた、サーチジョブ調査の使
⽤⽅法に関する質問と回答をご覧いただけます。
OS からのジョブの管理
ここでは、OS からのサーチジョブの管理⽅法について説明していきます。以下の 2 種類のプラットフォームを対
象にしています。
*nix
Windows
128
Splunk Web を使ったサーチジョブの管理⽅法については、このマニュアルの「[ジョブ] ページによるジョブの管
理」を参照してください。
*nix でのジョブの管理
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=)
ジョブ ID (id=)
ディスク上に保持されるジョブの成果物 (出⼒) の ttl または有効期間 (ttl=)
ジョブを実⾏しているユーザー (user=)
ユーザーが所属しているロール (roles=)
ジョブの実⾏中、データは $SPLUNK_HOME/var/run/splunk/dispatch/<job_id>/ に書き込まれます。スケジュール済み
ジョブ (スケジュールされた保存済みサーチ) には、ディレクトリ名の⼀部として保存済みサーチ名が含まれま
す。
プロセスの ttl の値により、ここへのデータの保持期間が決まります。OS でジョブを kill する場合、その成果物
も削除するには、実施する前にジョブ ID を確認してください。
Windows でのジョブの管理
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」ファ
イルを削除します。
データサマリーを使ったサーチの⾼速化
サマリーベースのサーチとピボットの⾼速化の概要
129
Splunk Enterprise では、⼤量のデータに対するレポートを⽣成することができます。ただし、そのようなレポー
トを⽣成するまでに要する時間は、処理するイベント数に⽐例します。つまり、⼤量のデータセットに対するレ
ポートを⽣成する場合は、⻑時間かかってしまいます。そのようなレポートをたまにしか⽣成しない場合は、⽣成
までに要する時間は問題にならないかもしれません。しかし、そのようなレポートを定期的に実⾏する (またはよ
く使われるダッシュボードパネルの基盤として使⽤される) ことは実⽤的ではありません。さらに、Splunk
Enterprise 環境内でそのようなレポートを実⾏するユーザーが増加するにつれて、指数関数的にかかる時間が⻑
くなっていきます。
⼤量のデータに対するレポート⽣成を効率化するには、レポートのベースとなるサーチのバックグラウンド実⾏の
結果を設定したデータサマリーを作成する必要があります。この⽅法で要約されたサマリーデータに対してレポー
トを実⾏すれば、⼤幅に処理時間を短縮することができます (元の⼤量のイベントよりもサマリーは⼤幅に⼩さい
ため)。
Splunk Enterprise には、3 種類のデータサマリー作成⼿段が⽤意されています。
レポート⾼速化 - ⾃動的に作成されたサマリーを使って、ある種類のレポートの完了時間を⾼速化します。
データモデル⾼速化 - ⾃動作成されたサマリーを使って、ピボットの完了時間を⾼速化します。
サマリーインデックス - メインインデックスから、個別のサマリーインデックスを⼿動作成することで、
サーチとレポートの⾼速化を実現します。
レポートの⾼速化
レポート⾼速化 は、個別のレポートを⾼速化するために⽤いられます。⼤きなデータセットに対して実⾏され
る、任意の変換サーチ またはレポートに対して簡単に設定することができます。
初期バージョンの Splunk Enterprise では、サマリーインデックスがレポートの⾼速化に使⽤されていました。
レポートの⾼速化は、以下のような理由でサマリーインデックスよりも好まれます。
レポートの⾼速化は、チェックボックスを選択して時間範囲を設定するだけの⼿軽な作業。 それ以降
は何も⾯倒な作業を⾏う必要はありません。以降の⾼速化レポートの実⾏は、設定されている時間範囲内
(または最低でも部分的に)である限り、より短時間で完了します。サマリーインデックスの場合、それを使
⽤するために特別なサーチコマンドを指定したサーチを設計する必要があり、またサマリーインデックスの
作成作業も必要です。
レポート⾼速化サマリーのデータは、類似のサーチと⾃動的に共有される。 社員 Mary が、あるレポー
トに対してレポート⾼速化を有効にした場合を考えてみましょう。この場合、Splunk Enterprise によりレ
ポートのサマリーデータが作成されます。数⽇後に、Joe が Mary といくつかの点が異なるだけで、ほぼ同
じレポートを作成しました。Joe がレポートのレポート⾼速化をオンにして、それを保存すると、そのレ
ポートにはすでに Mary のレポートで構築されているサマリーデータが割り当てられます。つまり、Joe は
サマリーデータが作成されるまで待つ必要がありません。
レポート⾼速化機能の⾃動バックフィル。 何らかの理由でデータの⽋損が発⽣した場合、Splunk
Enterprise はそれを検出して、必要に応じて⾃動的にサマリーを更新/再構築します。
レポート⾼速化サマリーは、インデックスのバケツと⼀緒に保管される。 サマリーインデックスは、
サーチヘッドに保管されます。サマリーデータをインデックスのバケツレベルで保管することにより、サマ
リーインデックスの完全再構築の原因になりかねない、イベントの到着遅延による問題に簡単に対処するこ
とができます。Splunk Enterprise サマリーはホットバケツとウォームバケツにまたがって同時に存在でき
るため、到着遅延データも簡単に要約することができます。遅延データは単純にホットバケツに追加されま
す。
すべてのサーチでレポート⾼速化を使⽤できる訳ではないことに注意してください。変換コマンド を使⽤する
サーチ (結果を統計的テーブルやグラフに変換するサーチ) でのみ利⽤することができます。また、サーチ内の最
初の変換コマンドの前にあるコマンドはすべて、ストリーミングコマンド でなければなりません。この制限は、
サマリーがサーチヘッドではなくインデックスレベルで構築されることに関連しています。
Splunk Web で、レポート⾼速化に適したサーチをレポートとして保存する際に、レポート⾼速化を有効にする
ことができます。レポート⾼速に適した既存のレポートでこの機能を有効にするには、以下の作業を⾏います。
[レポート] ページで、レポートの⾏を展開した後 [編集] をクリックして、[⾼速化の編集] ダイアログを開
きます。レポートが⾼速化に適しており、レポート⾼速化を利⽤できる権限がある場合、[⾼速化の編集] ダ
イアログには [レポートの⾼速化] チェックボックスが表⽰されます。これを選択してください。[サマリー
範囲] フィールドが表⽰されます。レポートの実⾏を予定している時間範囲を選択して、[保存] をクリック
します。
[設定] > [サーチしとレポート] でレポートの詳細ページを開いて、[このサーチを⾼速化] をクリックし
て、[サマリー範囲] を設定します。
詳細は、『レポートマニュアル』の「レポートの⾼速化」を参照してください。
[システム] の [レポート⾼速化サマリー] ページで、レポート⾼速化で作成されたサマリーデータを管理すること
ができます。詳細は、このマニュアルの「レポート⾼速化の管理」を参照してください。このトピックには、要約
の仕組みと利⽤できるサーチ/利⽤できないサーチの例も記載されています。
レポート⾼速化を使⽤する場合
レポート⾼速化は、10 万件以上のホットバケツ イベントを持ち、前述の条件を満たしている、処理に時間がかか
るレポートに対して有効です。
この機能の利⽤に適したサーチと適さないサーチの詳細は、このマニュアルの「レポート⾼速化の管理」を参照し
てください。
データモデル⾼速化
データモデル⾼速化を使って、データモデル内に定義されているすべてのフィールドを⾼速化することができま
す。データモデルを⾼速化すると、そのデータモデルから⽣成されたピボットやレポートは、データモデルが⼤量
のデータセットを表しているような場合でも、⾼速化しない場合と⽐べて⼤幅に短時間で完了します。
130
データモデル⾼速化にはアドホックと永続的の 2 種類のタイプが存在しています。アドホック⾼速化は、単⼀の
オブジェクトに適⽤され、ユーザーのピボットセッション期間中に実施されます。永続的⾼速化は、管理者がオン
にするとバックグラウンドで実⾏され、また、週単位や⽉単位などの短い時間範囲を対象にすることができます。
永続的⾼速化は、⾼速化を有効にしたデータモデル内のオブジェクトに対してサーチを実⾏中、任意の時点で使⽤
することができます。
データモデル⾼速化は Splunk Enterprise のハイパフォーマンス分析ストア (HPAS) 技術を活⽤しています。こ
の技術はレポート⾼速化のような⼿法を使って、インデックス内のバケツ と⼀緒にサマリーを作成します。また
レポート⾼速化と同様に、永続的データモデル⾼速化は簡単に有効化することができます。単純に⾼速化するデー
タモデルのチェックボックスをクリックして、サマリー範囲を選択するだけです。この作業を⾏うと、指定された
時間範囲のサマリー構築が開始されます。サマリー構築が完了すると、⾼速化されたデータモデルオブジェクトを
使⽤する任意のピボット、レポート、またはダッシュボードパネルは、可能な限り _raw 全体ではなくサマリー
データに対して実⾏され、結果が返されるまでの時間も⼤幅に改善されます。
永続的データモデル⾼速化には制限事項があります。
永続的データ・モデル⾼速化は、イベント・オブジェクト階層にのみ適⽤されます。 ルート・サーチお
よびルート・トランザクション・オブジェクトをベースにしたオブジェクト階層は⾼速化できません。
「アドホック」データ・モデル⾼速化の恩恵は、すべてのデータ・モデル・オブジェクトが受けられ
ます。これについては、後述するサブセクションを参照してください。
データ・モデルを永続的に⾼速化したら、それを編集することはできません。 いったんデータモデルの
⾼速化を有効にしたら、⾼速化を無効にしないと編集することはできません。
デフォルトでは、 admin 権限を持つユーザーのみが、永続的に⾼速化されたデータモデルにアクセス
できます。
プライベートなデータモデルを永続的に⾼速化することはできません。 ⾼速化するためには、データモ
デルを最低 1 ⼈の App のユーザーと共有する必要があります。
Splunk Web のデータモデル管理ページでは、⾼速化の適性があるデータモデルの⾼速化を有効にすることがで
きます。このページには、さまざまな⽅法でアクセスできます ([設定] > [データモデル] に移動など)。
永続的データモデル⾼速化を有効にする⽅法の詳細は、このマニュアルの「データモデルの管理」を参照してくだ
さい。
データモデル⾼速化の技術的情報、およびその背後で機能しているハイパフォーマンス分析ストアの詳細は、この
マニュアルの「データモデルの⾼速化」を参照してください。
アドホックデータモデル⾼速化
アドホックデータモデル⾼速化は、「永続的」には⾼速化されていないすべてのデータモデルオブジェクトの背後
で実施されるプロセスです。「永続的」なデータモデル⾼速化と違い、アドホックデータモデル⾼速化は、ルート
サーチオブジェクト、ルートトランザクションオブジェクト、およびその⼦を含めた、すべてのオブジェクトタイ
プに適⽤されます。
⾼速化されていないオブジェクトに基づいてピボットを作成すると、アドホックデータモデル⾼速化を使って⼀時
的な⾼速化サマリーがディスパッチディレクトリに作成されます。これは、ピボットエディタでピボットを定義し
ている間のみ存在します。結果的に、ピボットエディタでピボットを調整するにつれて、ピボットのパフォーマン
スが改善され、当初よりも素早く結果が返されることに気付くことでしょう。
これは、Splunk Enterprise が継続的にデータモデルオブジェクトのサマリーを維持して、ピボットエディタの使
⽤開始時から⾼速なパフォーマンスが保証される、「永続的」なデータモデル⾼速化ほどの効果はありませんが、
それでも⼗分に役に⽴ちます。
アドホックデータモデル⾼速化の詳細は、このマニュアルの「データモデルの⾼速化」を参照してください。
永続的データモデル⾼速化を使⽤する状況
ピボットエディタでピボットの完了時間の遅さに悩んでおり、それらのピボットのソースオブジェクトがルートイ
ベントオブジェクト階層の最上位に所属している場合は、データモデル⾼速化の有効化を検討する必要がありま
す。この機能を利⽤することにより、それらのオブジェクトに基づくピボットは、より短時間で結果を返すことが
できます。
また、永続的に⾼速化されたデータモデルオブジェクトを参照するレポートやダッシュボードパネルも、この⾼速
化の恩恵を受けられます (アドホックデータモデル⾼速化では、このような恩恵はありません)。
レポート⾼速化とデータ・モデル⾼速化
⼀般的にデータ・モデル⾼速化は、レポート⾼速化よりも⾼速です。ただし、レポート⾼速化の⽅がデータ・モデ
ル⾼速化よりも⾼速な、特定の種類のサーチも存在しています。
この場合、変換サーチ処理が多いほど、より⾼速になります。レポート⾼速化は、インデックス・バケツあたり 1
つの項⽬を集計するサーチで特に⾼速になります。たとえば、1 ⽇あたり数⼗億件のイベントを収集しており、そ
の⽉次カウントと平均のみを知りたい場合、データ・モデル⾼速化よりもレポート⾼速化を利⽤する⽅がパフォー
マンスが良くなります。この場合、レポート⾼速化の集計機能が最⼤限に活⽤されます。
レポート⾼速化とデータ・モデル⾼速化は、サーチの⾼速化を類似の⽅法で⾏います。どちらもインデクサー上で
イベントを前処理し、またどちらもバケツ・レベルの⾼速化サマリーを作成します。ただし、データ・モデル⾼速
化の⼀般的な利点は、そのサマリーがレポート⾼速化で作成されるサマリーと違うことにあります。
レポート⾼速化は、事前計算された統計情報を含むサマリーを作成するように設計されています。⼀⽅データ・モ
デル⾼速化は、読み取り効率が⾮常に優れている形式でサマリーを作成し、パフォーマンスを低下することなくオ
ンデマンドで統計情報を計算できるようになっています。そこでサーチが⽐較的に複雑な場合は、データ・モデル
⾼速化の⽅が適していることになります。
131
サマリーインデックス
サマリーインデックス は、変換コマンドの前に⾮ストリーミング コマンドが使われているレポートなどの、レ
ポート⾼速化に適さない、処理に時間がかかるレポートの⾼速化に利⽤できます。サーチの結果を持つデータサマ
リーの構築が関与するという点ではレポート⾼速化と似ていますが、この場合データサマリーは実際に特別なサ
マリーインデックス で、サーチヘッド上で構築、保管されます。このサマリーインデックスは、⽬的のレポート
に基づくスケジュール済みレポートにより構築されます。サマリーインデックスを使⽤する場合は、[設定] >
[サーチとレポート] で、サマリーインデックスに [有効] を設定します。
たとえば、⾼速化するレポートが変換コマンド を使⽤している場合、その変換コマンドの代わりに先頭が「si」
で始まる、サマリーインデックス⽤変換コマンドを使⽤したレポートで、サマリーインデックスを構築することが
できます (sichart、sitimechart、sistats、sitop、および sirare)。
このマニュアルには、サマリーインデックスの設定に関する 2 つのトピックが⽤意されています。
「サマリーインデックスを使ったレポート効率の向上」には、si- コマンドを使⽤するスケジュール済み
サーチによる、サマリーインデックスの簡単な設定⽅法について説明しています。
「サマリーインデックスの設定」では、addinfo、collect、および overlap コマンドを使った、少し複雑で困
難なサマリーインデックスの設定⽅法について説明しています。後者の⽅法は、総統計を考慮するサーチを
設定する場合にのみ使⽤します。
サマリーインデックスを使⽤する場合
使⽤しているレポートにレポート⾼速化の適性がある場合は、そちらを使⽤して⼤量のデータに対するサーチを⾼
速化することをお勧めします。
以下のような場合に、レポート⾼速化の代わりにサマリーインデックスを使⽤します。
⾼速化したいレポートで、変換コマンドの前に⾮ストリーミングコマンドが使⽤されている (レポート⾼速
化と同様に、サマリーインデックスを構築するレポートには変換コマンドが関与します)。
特定のサマリーインデックスに対してレポートを実⾏したい (サーチ⽂字列に index=<summary_index_name> を
指定)。(レポート⾼速化の場合、特定のデータサマリーに対してレポートを実⾏するかどうかは Splunk
Enterprise が判断します。)
raw データは、レポートウィンドウよりも頻繁にロールされます (例：保持ポリシーは 6 ヶ⽉だけども、
ダッシュボード内のパネルに去年のデータを利⽤したい場合)。⼀般的にサマリーインデックスは、それが集
計するイベントよりも消費するスペースが少なく、個別に⻑期間保持することができます。
バッチモードサーチ
バッチモードサーチは、変換サーチのパフォーマンスと信頼性を向上します。イベントを時間順に並べる必要がな
い変換サーチの場合、バッチモードで実⾏することは、サーチを時間順ではなくバケツごとに実⾏ (⼀括処理) す
ることを意味しています。ある種類のレポートでは、この⽅法により変換サーチがより短時間で完了します。また
バッチモードサーチは、サーチ実⾏中にインデクサーが停⽌すると失敗する可能性がある、⻑時間実⾏される分散
サーチの信頼性も向上します。この場合、Splunk Enterprise は停⽌したピアに再接続して、サーチの再実⾏を試
みます。
バッチモードサーチに適した変換サーチの例を以下に⽰します。
サーチ内に localize または transaction コマンドを含まない、⽣成/変換サーチ (stats、chart など) の⽣成。
リアルタイムではなく、またサマリーを⽣成しないサーチ。
ストリーミング状態を把握できない⾮分散サーチ。(たとえば、streamstats サーチが挙げられます)
バッチモードサーチは、設定ファイル limits.conf の [search] スタンザで起動します。変換サーチがバッチモード
で動作しているかどうかを確認するには、サーチ調査を使⽤します。
詳細は、このマニュアルの「バッチモードサーチの設定」を参照してください。
レポート⾼速化の管理
レポート⾼速化は、⼤量のデータを処理するために時間がかかる変換サーチ を⾼速化するための、もっとも簡単
な⼿段です。変換サーチの⾼速化は、それをレポートとして保存する際に有効にします。また、変換サーチを使⽤
するレポートベースのダッシュボードパネルも⾼速化できます。
ここでは、レポート⾼速化の詳細を説明していきます。以下のような事項が取り上げられています。
変換レポートの⾃動⾼速化を有効にする⽅法。
適性のあるレポートと適性のないレポートの例 (レポート⾼速化は特定の種類のレポートにのみ適⽤できま
す)。
Splunk Enterprise によるレポート⾼速化サマリーの作成と管理。
⾃動レポート⾼速化に使⽤するデータサマリーのレビューと管理を⾏うための、[設定] の [レポート⾼速化
サマリー] ページの概要。
レポート⾼速化を有効にする
レポート⾼速化は、レポートの作成時またはレポートの作成後に有効にすることができます。
⼿順の詳細は、『レポートマニュアル』の「レポートの作成と編集」を参照してください。
レポート作成時のレポート⾼速化の有効化
時間がかかる (適性のある) サーチでレポート⾼速化を使⽤するには：
132
時間がかかる (適性のある) サーチでレポート⾼速化を使⽤するには：
1. [サーチ] でサーチを実⾏します。
2. [名前を付けて保存] をクリックして、[レポート] を選択します。[レポートに名前を付けて保存] ダイアログが
表⽰されます。
3. レポートの名前 を指定し、必要に応じて説明 も⼊⼒します。[保存] をクリックして、サーチをレポートとして
保存します。[レポートが作成されました] ダイアログが表⽰されます。
4. レポートを⾼速化するには、[⾼速化] をクリックします。[⾼速化の編集] ダイアログが表⽰されます。
注意： 以下の場合、[⾼速化の編集] ダイアログにはメッセージ「このレポートは⾼速化できません」が表⽰され
ます。
レポートを⾼速化する権限がない。ロール には、schedule_search および accelerate_search 権限 が必要です。
レポートにレポート⾼速化の適性がない。詳細は、後述する「レポート⾼速化に適したレポート」を参照し
てください。
5. レポートが⾼速化に適しており、レポート⾼速化を利⽤できる権限がある場合、[⾼速化の編集] ダイアログには
[レポートの⾼速化] チェックボックスが表⽰されます。これを選択してください。
6. [サマリー範囲] フィールドが表⽰されます。レポートの実⾏対象期間に応じて、[1 ⽇]、[7 ⽇]、[1 ヶ⽉]、[3
ヶ⽉]、[1 年]、または [全時間] を選択します。たとえば、過去 7 ⽇間に対してレポートを実⾏予定の場合は、[7
⽇] を選択します。
7. [保存] をクリックして、⾼速化の設定を保存します。
既存のレポートのレポート⾼速化の有効化
既存のレポートのレポート⾼速化を有効にするには、[レポート] ページでレポートを探して、その⾏を展開して詳
細情報を表⽰します。レポートがまだ有効にされていない場合、[⾼速化] の値は [無効] になります。[編集] をク
リックして、[⾼速化の編集] ダイアログを表⽰します。上記のリストのステップ 5〜7 に従って、レポート⾼速化
の設定を定義、保存します。
注意： レポートを⾼速化する権限がない場合、またはレポートがレポート⾼速化に適していない場合は、[⾼速化
の編集] ダイアログに、メッセージ「このレポートは⾼速化できません」が表⽰されます。
代わりに、[設定] > [サーチとレポート] で、既存のレポートのレポート⾼速化を有効にすることもできます。
レポートの⾼速化を有効にした後
レポートの⾼速化を有効にしたら、Splunk Enterprise がサマリー作成による利点がレポートにあると判断した場
合、レポート⾼速化サマリーの構築が開始されます。レポートを⾼速化してもサマリーが作成されない場合は、
「Splunk Enterprise がサマリーを構築しない場合」を参照してください ([設定] > [レポート⾼速化サマリー]
に移動して、[サマリーステータス] が⻑時間に渡って 0% のまま変化しない場合)。
サマリーの構築が完了したら、それ以降の⾼速化レポートは以前よりも短時間で完了します。サマリーの詳細と仕
組みについては、後続のサブトピックを参照してください。
注意： [サーチ] でレポートを実⾏している場合、レポート⾼速化はサーチモード が [スマート] または [⾼速] に設
定されているレポートでのみ機能することに注意してください。レポート⾼速化を設定したレポートに [詳細]
サーチモードを選択すると、⾼速化されていない場合と同じ速度でしかレポートは実⾏されません。ダッシュボー
ドパネルのベースとなるサーチの場合、サーチモードは影響しません。)サーチモード 設定の詳細は、『サーチマ
ニュアル』の「サーチに合わせたサーチモードの設定」を参照してください。
レポート⾼速化に適したレポート
⾼速化を使⽤するレポートは、サーチ⽂字列に変換コマンド (chart、timechart、stats、top など) を使⽤する必要
があります。
また、最初の変換コマンドの前に指定されているコマンドはすべて、ストリーミングコマンド (サーチが返す各
イベントに変換を適⽤しないコマンド) でなければなりません。たとえば、rex コマンドはストリーミングコマン
ドで、レポートが返す各イベントに適⽤され、コマンドに指定されている正規表現に⼀致するフィールドを抽出し
ます。他の⼀般的に使⽤されるストリーミングコマンドとしては、search、where、eval、regex、bin (明⽰的な期間
を指定しない場合)、および lookup (local=t を除く) が挙げられます。
注意： 最初の変換コマンドの後に⾮ストリーミングコマンドを指定しても、そのレポートは⾃動⾼速化の対象に
なります (適している)。最初の変換コマンドより前に⾮ストリーミングコマンドがある場合に、サーチが不適格と
なります。
⾼速化を利⽤できるサーチ⽂字列の例
レポート⾼速化に適したサーチ⽂字列の例を以下に⽰します。
index=_internal | stats count by sourcetype
index=_audit search=* | rex field=search "'(?.*)'" | chart count by user search
test foo bar | bin _time span=1d | stats count by _time x y
index=_audit | lookup usertogroup user OUTPUT group | top searches by group
⾼速化を利⽤できないサーチ⽂字列の例
133
レポート⾼速化に適さないサーチ⽂字列の例を以下に⽰します。
以下のサーチ⽂字列が適さない理由： これは単純なイベントサーチで変換コマンドがありません。
index=_internal metrics group=per_source_thruput
以下のサーチ⽂字列が適さない理由： eventstatsは変換コマンドではありません。
index=_internal | eventstats avg(x) by y
以下のサーチ⽂字列が適さない理由： transactionはストリーミングコマンドではありません。他の⾮ストリーミ
ングコマンドとしては、dedup、head、tail、および他のストリーミングコマンド のリストにないサーチコマンド
などが挙げられます。
index=_internal | transaction user maxspan=30m | timechart avg(duration) by user
レポート⾼速化を利⽤できるけれどもあまり効果がないサーチ⽂字列
技術的にはレポート⾼速化の要件を満たすけれども、あまり効果がないレポートも存在しています。たとえば、レ
ポートに複数の変換コマンドが指定されており、最初の変換コマンドが⼤量の出⼒⾏ (50000 ⾏以上) を⽣成する
ような、データ濃度が⾼いレポートが挙げられます。例：
index=* | stats count by id | stats avg(count) as avg, count as distinct_ids
レポート⾼速化サマリーの理解
レポートサマリーの仕組みをより理解するために、以降のトピックではサマリーのさまざまな側⾯を取り上げてい
ます。
レポート⾼速化サマリーの時間範囲の設定
レポートのレポート⾼速化を有効にすると、特定の期間 (過去 1 ⽇、過去 7 ⽇、過去 1 ヶ⽉、過去 1 年など) に
対応するサマリーの⽣成が開始されます。この時間範囲は、[サマリー範囲] リストで選択します。
たとえば、サマリー範囲に「7 ⽇間」を選択すると、任意の時点から過去 7 ⽇間 (概算) の範囲をカバーするデー
タサマリーが作成されます。サマリーの構築が完了した後は、レポートのサマリープロセスが継続され、常に設定
されている期間をカバーするために、期限が過ぎた古いサマリーデータは削除され、要約された新しいデータが追
加されます。
注意： サマリー範囲 は、対象とする範囲の概算期間を表しています。わずかにサマリー範囲を超えたデータが保
管されている場合もありますが、最初のサマリー作成中の時点を除いては、それが⼀致するイベントとして表⽰さ
れることはありません。
将来的に、過去 1 週間などのサマリー範囲内の期間に対してレポートを実⾏すると、レポートはソースインデッ
クス (当初のサーチ実⾏対象インデックス) ではなく、サマリーに対して実⾏されます。たいていの場合、サマ
リーにはソースインデックスよりも⼤幅に少ないデータしか存在しておらず、事前に算出されたサーチパイプライ
ン内の⼀部の結果が含まれているため、初回実⾏時よりもレポートが⼤幅に短時間で完了します。
サマリーが⼀部の範囲しかカバーしていないレポートを実⾏する場合、レポートはさほど速くは完了しません。こ
れは、Splunk Enterprise が最低でもレポートの⼀部を、Splunk Enterprise インデックス内の raw データに対
して実⾏する必要があるからです。たとえば、レポートの [サマリー範囲] 設定が 1 週間の場合に、過去 9 ⽇間
を対象にサーチを実⾏すると、過去 7 ⽇間の部分に対してのみレポート⾼速化の恩恵が受けられます。残りの 8
⽇前と 9 ⽇前のデータは、通常の速度でレポートが実⾏されます。
サーチ範囲 の値を設定する際には、このことを考慮するようにしてください。過去 7 ⽇間を超えるけれども過去
30 ⽇は超えないレポートを実⾏する予定の場合は、⾼速化の設定時にサマリー範囲 を 1 ヶ⽉に指定してくださ
い。
注意： 通常 Splunk Enterprise は、設定されているサマリー範囲 がカバーする、ホットバケツ 内のイベント数
が、10 万件以上の場合にのみサマリーを⽣成します。詳細は、「Splunk Enterprise がサマリーを構築/更新しな
い場合」を参照してください。
Splunk Enterprise によるレポート⾼速化サマリー作成の仕組み
適性のあるレポートの⾼速化を有効にし、Splunk Enterprise がレポートのサマリーの構築が妥当と判断した場
合、サマリーを構築するためのレポート実⾏が開始されます。構築が完了しても、10 分間隔でレポートの実⾏が
継続され、サマリーが最新の状態に保たれます。各更新により、⼤きなデータのギャップを⽣じることなくサマ
リーデータは設定されている時間範囲が常にカバーされます。この⽅法によるサマリー構築により、最後に到着し
たデータも複雑化することなく要約されます。
レポートサマリーの構築までには、少し時間がかかります。作成する時間は対象となるイベント数、総合的なサマ
リー範囲、およびサマリー内のタイムスパン⻑ (チャンク) によって異なります。
サマリー構築の進捗状況は、[設定] の [レポート⾼速化サマリー] ページで確認できます。メインページの [サマ
リーステータス] では、完了した割合を確認できます。
注意： 通常のスケジュール済みレポート と同様に、定期的にレポート⾼速化サマリーに⾃動的にデータを追加し
ていくレポートも、レポートスケジューラー により管理されます。デフォルトでレポートスケジューラーには、
レポートを⾼速化するサマリーデータの作成と更新のために、合計サーチ帯域幅の 25% までの利⽤が許可されて
います。
レポートスケジューラーは、レポート⾼速化サマリーにデータを追加するレポートを、最低の優先度で実⾏しま
134
す。これらの「⾃動サマリーデータ作成」レポートが、ユーザーが定義したアラート、サマリーインデックスレ
ポート、および通常のスケジュール済みレポートと競合している場合、ユーザー定義のレポートが常に最初に実⾏
されます。この場合、Splunk Enterprise が他の優先するレポートを実⾏するために、サマリーが作成/更新され
ない可能性があります。
サーチスケジューラーの詳細は、『レポートマニュアル』の「スケジュール済みレポートの優先度の設定」を参照
してください。
サマリーデータは、標準のタイムスパンでチャンクに分割される
Splunk Enterprise がサマリーを構築、管理する場合、統計的な精度を確保するために、全体的なサマリー範囲に
基づいて Splunk Enterprise が⾃動的に判断する「タイムスパン」に従って、データをチャンクに分割します。
たとえば、レポートのサマリー範囲が 1 ヶ⽉の場合、1d (1 ⽇) のタイムスパンで分割されます。
サマリーのタイムスパンは、サマリーが統計的に正確なデータを含む最⼩の時間範囲を表しています。1 時間のタ
イムスパンを持つサマリーに対してレポートを実⾏する場合、レポートにサマリーデータを使⽤させるには、レ
ポートに指定する時間範囲が、そのタイムスパンで割り切れなければなりません。タイムスパンが 1h の場合、過
去 24 時間に対して実⾏されるレポートは正常に機能しますが、過去 90 分に対して実⾏すると、サマリーデータ
を利⽤できない可能性があります。
サマリーには複数のタイムスパンが存在できる
Splunk Enterprise は、サマリーをできる限りサーチ可能にするために、必要に応じてサマリーに複数のタイムス
パンを割り当てます。たとえば、3 ヶ⽉のサマリー範囲に対して、1mon と 1d のタイムスパンを利⽤できます。
また、サマリーが複数のインデックスバケツ にまたがっており、バケツがそれぞれ⾮常に異なる時間量をカバー
している場合には、Splunk Enterprise が追加のタイムスパンを割り当てることがあります。たとえば、サマリー
が 2 つのバケツにまたがっており、最初のバケツのスパンが 2 ヶ⽉で、次のバケツのスパンが 40 分の場合、サ
マリーには 1d と 1m のタイムスパンが使⽤されます。
サマリーのタイムスパンは⼿動設定できる (⾮推奨)
前述のように、サマリーのタイムスタンプが⾃動的に判断します。ただし、savedsearches.conf でレポートレベル
にタイムスパンを変更することができます (auto_summarize.timespan パラメータ)。サマリーのタイムスパンを⼿動
設定する場合は、極めて⼩さなタイムスパンを設定すると、サマリーの作成が極端に遅くなることに注意してくだ
さい (特にサマリー範囲が⻑い場合)。⼀⽅タイムスパンが⼤きすぎると、サマリー構築は素早く完了するけれど
も、短い時間範囲のレポートには利⽤できません。ほぼすべての場合において、最適なパフォーマンスとユーザビ
リティを確保するために、Splunk Enterprise が決定したタイムスパンを使⽤するのが最良です。
レポート⾼速化サマリーの作成/保管場所
⾼速化レポートサマリーはインデクサー上で作成され、サマリー範囲をカバーするバケツと⼀緒に保管されます。
レポートサマリーはインデックスではないことに注意する必要があります。クラスタはレポートサマリーを認識、
複製しません。オリジナルのコピーからそのバケツの他のコピーに優先度 が再割り当てされた場合、サマリーは
新しいプライマリコピーに移動せず、利⽤できなくなります。次回に Splunk Enterprise がサマリー更新レポー
トを実⾏し、サマリーが失われていることに気が付いて、サマリーを再⽣成するまでの間、サマリーは利⽤できな
くなります。
クラスタとバケツ優先度の詳細は、『インデクサーとクラスタの管理』マニュアルの「バケツとクラスタ」を参照
してください。
注意： Splunk Enterprise がサマリーを再⽣成するまでの間、⾼速化レポートの結果は正常に返されますが、実
⾏速度が遅くなります。
レポート⾼速化サマリーのサイズベースの保持の設定
ディスクストレージのスペースを消費しすぎないように、インデックスのサイズベースの保持制限を設定していま
すか？デフォルトでレポート⾼速化サマリーは、理論的に無制限のディスクスペースを利⽤することができます。
インデックスまたはインデックスボリュームの最⼤データサイズもロックしている場合、このことが問題になる可
能性があります。ただし、レポート⾼速化サマリーにも必要に応じて同様の保持制限を設定することができます。
注意： レポート⾼速化サマリーのサイズはデフォルトでは無制限ですが、ウォームおよびホットインデックスバ
ケツ内の raw データと密接に関連しており、存続期間もそれに従います。イベントがホット/ウォームバケツから
コールドバケツに移動すると、関連するサマリーからも同様に削除されます。
重要： レポート⾼速化サマリーのサイズベースの保持制限を設定する前に、まずボリュームを使った各インデッ
クスにまたがるインデックスサイズ制限の設定⽅法について理解しておく必要があります。多くの原則が、これと
同じになります。詳細は、『インデクサーとクラスタの管理マニュアル』の「インデックスサイズの設定」を参照
してください。
デフォルトでレポート⾼速化サマリーは、homePath/../summary/ のインデックスのホット/ウォームバケツと⼀緒に
保管されています。つまり、インデックスのホット/ウォームバケツに対して、indexes.conf 内の homePath が次の
場合：
homePath = /opt/splunk/var/lib/splunk/index1/db
そのインデックスのバケツに対応するサマリーは、次の場所に作成されます：
homePath/opt/splunk/var/lib/splunk/index1/summary
インデックス内のサマリーの、サイズベースの保持の設定⼿順を以下に⽰します。ここに取り上げているすべての
135
設定は、indexes.conf 内に⾏います。
1. ボリューム定義を確認して、レポート⾼速化サマリーのデータのホームとなるボリューム (1 つまたは複数) を
識別します。
適切なボリュームが存在しない場合は、それを作成してください。
インデックス作成した raw データを管理する既存のボリュームを利⽤したい場合は、そのボリュームにホッ
ト/ウォームバケツのディレクトリを提供しているファイルシステムを参照させます (レポート⾼速化サマ
リーもそこに存在しているため)。
ただし、必要に応じてレポート⾼速化サマリーを、独⾃のファイルシステムに配置することもできます。こ
こで唯⼀のルールは：ボリュームあたり 1 つのファイルシステムのみ参照できます。ただし、ファイルシス
テムあたりは複数のボリュームを参照することができます。
2. レポート⾼速化データのホームとなるボリュームに対して、ボリュームの最⼤サイズを設定する
maxVolumeDataSizeMB パラメータを追加します。
これにより、各インデックスにまたがって、レポート⾼速化サマリーデータのサイズベースの保持を管理す
ることができます。
3. インデックス定義を更新します。
サマリーデータを取り扱う各インデックスに summaryHomePath を設定します。パスが、ステップ 1 で決めたサ
マリーデータボリュームを参照していることを確認してください。
は、サマリーのデフォルトのパスに優先します。この値は、インデックス内のホット/ウォー
ムバケツの homePath を補⾜する必要があります。たとえば、前述の homePath 値を補⾜する summaryHomePath を
次に⽰します:
summaryHomePath
summaryHomePath = /opt/splunk/var/lib/splunk/index1/summary
この例の設定は、データサイズ制限がグローバルに、ボリューム単位、およびインデックス単位に設定しているこ
とを表しています。
#########################
# Global settings
#########################
# Inheritable by all indexes: No hot/warm bucket can exceed 1 TB.
# Individual indexes can override this setting. The global
# summaryHomePath setting indicates that all indexes that do not explicitly
# define a summaryHomePath value will write report acceleration summaries
# to the small_indexes # volume.
[global]
homePath.maxDataSizeMB = 1000000
summaryHomePath = volume:small_indexes/$_index_name/summary
#########################
# Volume definitions
#########################
# This volume is designed to contain up to 100GB of summary data and other
# low-volume information.
[volume:small_indexes]
path = /mnt/small_indexes
maxVolumeDataSizeMB = 100000
# This volume handles everything else. It can contain up to 50
# terabytes of data.
[volume:large_indexes]
path = /mnt/large_indexes
maxVolumeDataSizeMB = 50000000
#########################
# Index definitions
#########################
# The report_acceleration and rare_data indexes together are limited to 100GB, per the
# small_indexes volume.
[report_acceleration]
homePath = volume:small_indexes/report_acceleration/db
coldPath = volume:small_indexes/report_acceleration/colddb
thawedPath = $SPLUNK_DB/summary/thaweddb
summaryHomePath = volume:small_indexes/report_acceleration/summary
136
summaryHomePath = volume:small_indexes/report_acceleration/summary
maxHotBuckets = 2
[rare_data]
homePath = volume:small_indexes/rare_data/db
coldPath = volume:small_indexes/rare_data/colddb
thawedPath = $SPLUNK_DB/rare_data/thaweddb
summaryHomePath = volume:small_indexes/rare_data/summary
maxHotBuckets = 2
# Splunk constrains the main index and any other large volume indexes that
# share the large_indexes volume to 50TB, separately from the 100GB of the
# small_indexes volume. Note that these indexes both use summaryHomePath to
# direct summary data to the small_indexes volume.
[main]
homePath = volume:large_indexes/main/db
coldPath = volume:large_indexes/main/colddb
thawedPath = $SPLUNK_DB/main/thaweddb
summaryHomePath = volume:small_indexes/main/summary
maxDataSize = auto_high_volume
maxHotBuckets = 10
# Some indexes reference the large_indexes volume with summaryHomePath,
# which means their summaries are created in that volume. Others do not
# explicitly reference a summaryHomePath, which means that Splunk Enterprise
# directs their summaries to the small_indexes volume, per the [global] stanza.
[idx1_large_vol]
homePath=volume:large_indexes/idx1_large_vol/db
coldPath=volume:large_indexes/idx1_large_vol/colddb
homePath=$SPLUNK_DB/idx1_large/thaweddb
summaryHomePath = volume:large_indexes/idx1_large_vol/summary
maxDataSize = auto_high_volume
maxHotBuckets = 10
frozenTimePeriodInSecs = 2592000
[other_data]
homePath=volume:large_indexes/other_data/db
coldPath=volume:large_indexes/other_data/colddb
homePath=$SPLUNK_DB/other_data/thaweddb
maxDataSize = auto_high_volume
maxHotBuckets = 10
レポート⾼速化サマリーのボリュームがサイズ制限に達すると、スペースを確保するために、ボリューム内のもっ
とも古いサマリーが削除されます。サマリーが削除されると、その対応するバケツ内にマーカーファイルが保管さ
れます。このマーカーファイルは、サマリー⽣成機能にサマリーを再構築しないことを指⽰するものです。
データモデル⾼速化サマリーには、デフォルトのボリューム _splunk_summaries が存在しており、データモデル⾼速
化サマリーのサイズベースの保持の⽬的で、すべてのインデックスから参照されます。デフォルトでこのボリュー
ムに maxVolumeDataSizeMB 設定はありません。この場合、無期限に保持されることを意味しています。
既存のボリュームを使って、データモデル⾼速化サマリーとレポート⾼速化サマリーを 1 つの場所で管理するこ
とができます。以下の作業が必要になります。
レポート⾼速化サマリーの summaryHomePath 参照に _splunk_summaries ボリュームを参照させる。
_splunk_summaries に maxVolumeDataSizeMB 値を設定する。
データモデル⾼速化サマリーのサイズベースの保持の詳細は、このマニュアルの「データモデルの⾼速化」を参照
してください。
単⼀のサマリーに対する複数レポート
複数のレポートが類似しており、類似の結果を返すような場合、単⼀のレポートサマリーをそれらのレポートに関
連付けることができます。すでにレポートサマリーが関連付けられているレポートに類似のレポートサーチに⾼速
化を設定すると (両⽅のサーチが同じベースサーチ (サーチの最初の「|」⽂字より前の部分) を使⽤)、Splunk
Enterprise はそれを検出して⾃動的にそのレポートに既存のサマリーを関連付けます。
たとえば、以下の 2 つのレポートは同じレポートサマリーを使⽤します。
sourcetype=access_* | stats count by price
sourcetype=access_* | stats count by price | eval discount = price/2
サマリーに対して保存していないレポートを実⾏することもできます (基本的なレポートがサマリーを構築するレ
ポートと⼀致して、時間範囲もサマリー範囲に適合する場合)。
[設定] > [レポート⾼速化サマリー] に移動して、サマリーに関連付けられているレポートを確認することがで
きます。
137
Splunk Enterprise がサマリーを構築/更新できない場合
Splunk Enterprise は、要約するデータが以下の条件を満たす場合、レポートのサマリーを⽣成できません。
サマリー範囲 の対象となるホット・バケツ 内のイベント数が、10 万件未満である。この条件を満たす場
合、[サマリー・ステータス] に警告メッセージ「サマリーを作成するために⼗分なデータがありませ
ん。」が表⽰されます。
Splunk Enterprise は、完成したサマリーがデプロイ環境内の合計バケツ・サイズの 10% を超えないこと
を前提にしています。推定値がこの値を超えた場合、サマリー⽣成は 24 時間の間停⽌されます ([サマリー
ステータス] に「Suspended」が表⽰)。
サマリーの [サマリーステータス] を表⽰するには、[設定] > [レポート⾼速化サマリー] に移動します。
サマリーを定義したのにこれらの条件を満たしているためサマリーが作成されない場合でも、Splunk Enterprise
は定期的にこれらの条件が解決されたかどうかを確認します。Splunk Enterprise が、サマリー範囲が対象とする
ホット・バケツ内のイベント数が 10 万件以上で、完成後のサマリーが⼤きすぎないと判断した場合は、サマリー
の作成/更新が開始されます。
レポートがサマリーを使⽤しているかどうかを判断する⽅法
レポートを実⾏して、レポートパフォーマンスが向上したならば (以前よりも速く完了する)、サマリーを利⽤して
いることは明⽩です。
それだけでは⼗分でない場合、またはパフォーマンスが向上したかどうか分からないような場合は、サーチジョブ
調査のデバッグメッセージで、レポートが特定のレポート⾼速化サマリーを使⽤しているかどうかを確認すること
ができます。以下に例を⽰します。
DEBUG: [thething] Using summaries for search, summary_id=246B0E5B-A8A2-484E-840C78CB43595A84_search_admin_b7a7b033b6a72b45, maxtimespan=
この例では、最後の数字を含む⽂字列
リー ID に対応しています。
b7a7b033b6a72b45
が、[レポート⾼速化サマリー] ページに表⽰されるサマ
[レポート⾼速化サマリー] ページの使⽤
[設定] の [レポート⾼速化サマリー] ページで、レポート⾼速化サマリーをレビューしたり、サマリーのさまざま
な側⾯を管理することができます。[設定] > [レポート⾼速化サマリー] に移動してください。
[レポート⾼速化サマリー] ページでは、⾃分が表⽰権限を持っているサマリーに関する基本情報を参照することが
できます。
[サマリー ID] は、Splunk Enterprise が各サマリーに割り当てる⼀意の数字と⽂字で構成される⽂字列です。レ
ポート⽂字列から⽣成され、サマリーファイル⽤に作成されるディレクトリ名の⼀部に使⽤されています。サマ
リー ID をクリックすると、サマリーの詳細が表⽰され、サマリー管理作業を⾏うことができます。この詳細
ビューについては、「サマリー詳細のレビュー」を参照してください。
［サマリーを使っているレポート］ 列には、各サマリーに関連付けられている保存済みレポートが⼀覧表⽰さ
れています。特定のサマリーに関連付けられている各レポートが、そのサマリーによる⾼速化の恩恵を受けます。
レポートのタイトルをクリックすると、そのレポートの詳細ページが表⽰されます。
Splunk Enterprise がサマリーの更新に費やしている労⼒を確認するには、[サマリー作成負荷] をチェックしま
す。この値は、データを追加するレポートの実⾏時間 (秒) を、レポートの実⾏間隔で除算したものです。レポー
トが 10 分 (600 秒) ごとに実⾏され、実⾏時間が 30 秒の場合、サマリー作成負荷は 0.05 になります。サマリー
作成負荷が⾼く、サマリーの [アクセスカウント] からサマリーがほとんど使⽤されていない、または⻑期に渡っ
て使⽤されていないと判断できるような場合は、システムへの負荷を減らすためにそれを削除することを検討して
ください。
［サマリーステータス］ 列には、サマリーの全般的な状態、および前回の新規データによる更新時期が表⽰され
ます。「Complete」、「Pending」、「Suspended」、「Not enough data to summarize」、またはその時点
でのサマリー構築完了割合が表⽰されます。現時点のデータでサマリーを更新する場合は、サマリー ID をクリッ
クして詳細ページに移動して、[更新] をクリックして、サマリー更新レポートを実⾏してください。
[サマリーステータス] が「Pending」の場合、関連付けられているサマリーが更新されたのが 10 分以上前で、
再更新する時期になっていることを表しています。この状態は、サマリーはわずかに古くなっているけれども、じ
きに更新されることを意味しています。
[サマリーステータス] が「Suspended」の場合、作成するサマリーが⼤きすぎるため、サマリーを作成するに値
しないと Splunk Enterprise が判断したことを表しています。Splunk Enterprise はレポートにより作成される
サマリーのサイズを予測し、それが対応するインデックスバケツサイズの 10% を超えると判断した場合、サマ
リーの作成を 24 時間停⽌します。たとえば、サマリーにインデックス全体の 90% のデータが含まれるような場
合、サマリーを作成しても意味はありません。
138
合、サマリーを作成しても意味はありません。
サマリー停⽌を⼿動再開させることはできませんが、次の所にある
停⽌期間を変更することは可能です： savedsearches.conf,
auto_summarize.suspend_period
の値を変更して
[サマリーステータス] に「Not enough data to summarize」が表⽰されている場合、サマリー範囲に対応す
るホットバケツ 内の、レポートによって返されるイベント数が 10 万件未満のため、現在サマリーを⽣成または
更新していないことを表しています。詳細は、「Splunk Enterprise がサマリーを構築/更新しない場合」を参照
してください。
サマリー詳細のレビュー
サマリー詳細ページでは、特定のサマリーの詳細情報を表⽰したり、サマリーに対する操作を⾏ったりすることが
できます。このページに移動するには、[設定] の [レポート⾼速化サマリー] に表⽰されているサマリー ID を
クリックします。
サマリーステータス
[サマリーステータス] には、サマリーの基本的なステータス情報が表⽰されます。ここには、[レポート⾼速化サ
マリー] ページ (前述) の [サマリーステータス] と同じ情報が表⽰されますが、それに加えてサマリーの検証ス
テータスに関する情報も記載されています。
サマリーを現時点の情報で更新する場合は、[アクション] の下にある [更新] ボタンをクリックして、新たなサマ
リー更新レポートを実⾏します。
サマリーの検証を⾏っていない場合、ここに検証ステータスは表⽰されません。検証を開始すると、ここに検証の
完了割合が表⽰されます。それ以外の場合は、前回のサマリー検証結果が表⽰されます。「Verified」または
「Failed to verify 」と⼀緒に、実⾏時間が表⽰されます。
サマリーの検証の詳細は、後述する「サマリーの検証」を参照してください。
サマリーを使っているレポート
[このサマリーを使っているレポート] には、サマリーに関連付けられているレポート、およびその所有者とホー
ム App が表⽰されます。レポートのタイトルをクリックすると、そのレポートの詳細ページが表⽰されます。類
似のレポート (例：同じルートサーチを異なる変換コマンドで変換するサーチ⽂字列を持つレポート) は、同じサ
マリーを使⽤することができます。
サマリー詳細
[詳細] セクションには、サマリーに関する⼀連の測定基準が表⽰されます。
[サマリー作成負荷] および [アクセスカウント] は、[レポート⾼速化サマリー] ページから複写されていま
す。詳細は、「[レポート⾼速化サマリー] ページの使⽤」を参照してください。
[ディスクサイズ] には、サマリーがストレージの観点から消費しているスペースを表しています。この測定基準
と、[サマリー作成負荷] および [アクセスカウント] を参考に、削除した⽅が良いサマリーを判断することがで
きます。
139
注意： [サイズ] の値が 0.00MB から変化しない場合は、サマリーに関連付けられているサーチに⼗分な数のイベ
ントがないか (最低 10 万件のホットバケツイベントが必要)、または予測されるサマリーサイズがレポートに関連
するバケツの 10% を超えているために、このサマリーが現在は⽣成されていないことを表しています。Splunk
Enterprise は定期的にこのようなレポートをチェックして、サマリー作成の条件を満たしたら⾃動的にサマリー
の作成を開始します。
[サマリー範囲] は、サマリーが対象としている期間で、常に現在からの相対的な期間になります。この値は、サ
マリーを構築するレポートの定義時に設定します。詳細は、上記の「レポート⾼速化サマリーの時間範囲の設定」
を参照してください。
[期間] には、サマリーを構成するデータチャンクのサイズ (タイムスパン) が表⽰されます。サマリーのタイムス
パンは、サマリーが統計的に正確なデータを含む最⼩の時間範囲を表しています。1 時間のタイムスパンを持つサ
マリーに対してレポートを実⾏する場合、レポートで良好な結果を取得するには、レポートに指定する時間範囲
が、そのタイムスパンで割り切れなければなりません。タイムスパンが 1h の場合、過去 24 時間に対するレポー
トは正常に機能しますが、過去 90 分を指定すると、問題が発⽣する可能性があります。詳細は、「Splunk
Enterprise のサマリーの構築⽅法」を参照してください。
[バケツ] は、サマリーがいくつのインデックスバケツ にまたがっているかを、[チャンク] はサマリーを構成して
いるデータチャンク数を表しています。両⽅の測定基準はほぼ情報提供⽬的で⽤意されていますが、サマリーに関
するトラブルシューティングにも役⽴つ場合があります。
サマリーの検証
場合によっては、⾼速化されたレポートが返す結果が、作成当時に返されていたレポート結果と違っていることに
気が付くこともあるでしょう。これは、タグ、イベントタイプ、またはサーチが使⽤する抽出ルールの定義の変更
などにより、レポートのある側⾯が変化したような場合に、発⽣する可能性があります。
⾼速化レポートでこのような状態が発⽣したと考えられるような場合は、レポートに関連付けられているサマリー
の詳細ページに移動してください。検証プロセスを実⾏し、サマリーのサブセットを調査して、調査したすべての
データの整合性を検証することができます。データに不整合があった場合、検証が失敗したことを知らせるメッ
セージが表⽰されます。
たとえば、特定の種類のネットワークセキュリティイベントに関連付けられた、イベントタイプ netsecurity を使
⽤するレポートを考えてみましょう。このレポートで⾼速化を有効にし、Splunk Enterprise がサマリーを構築し
ました。その後しばらくして、イベントタイプ netsecurity の定義が変更され、まったく別のイベントセットを指
すようになりました。そのためサマリーには、従来とは異なるデータセットが追加されることになります。この時
点であなたは、⾼速化レポートから返される結果が異なっているとこに気が付きました。そこで、[設定] の [レ
ポート⾼速化サマリー] ページで検証プロセスを実⾏しました。サマリーの検証が失敗したため、ルートレポート
の調査を開始して原因を探します。
サマリー全体の検証には、サマリーの構築の完了と同じ位の時間がかかってしまうため、時間を節約するために
も、検証プロセスではサマリーデータのサブセットのみを調査できれば理想的です。ただし、場合によっては厳密
な検証が必要なこともあります。
[検証] をクリックすると [検証サマリー] ダイアログボックスが表⽰されます。ここには、2 種類の検証オプショ
ンが⽤意されています。
「⾼速検証」は、厳密さを犠牲にして、サマリーデータの⼩さなサブセットを素早く検証します。
「徹底検証」では、速度を犠牲にしてサマリーデータを徹底的に検証します。
どちらの場合でも、予想検証時間が表⽰されます。
[開始] をクリックして検証プロセスを開始すると、サマリーの詳細ページの [サマリーステータス] で、検証の
進捗状況を確認することができます。検証プロセスが完了すると、検証が成功したか、または失敗したかが表⽰さ
れます。どちらの場合でも、検証ステータスをクリックして詳細を確認することができます。
検証が失敗した場合、[検証失敗] ダイアログに理由が表⽰されます。
140
検証プロセス中、ホットバケツと構築中のバケツはスキップされます。
サマリーの検証が失敗した場合、ルートサーチ⽂字列を確認して、修正して正しい結果を得られるかどうかを調査
することができます。レポートが正しく機能するようになったら、[再構築] をクリックし、サマリーを再構築し
て整合性を回復することができます。現在のレポートをそのまま使⽤しても構わない場合は、単純にレポートを再
構築してください。また、最初から新たなレポートを作成する場合は、サマリーを削除して新しいレポートを作成
してください。
サマリーの更新、再構築、削除
[サマリーステータス] が、サマリーがしばらく更新されていないことを⽰しており、サマリーを最新の状態に更
新したい場合は、[更新] をクリックします。[更新] をクリックすると、標準のサマリー更新レポートによりイベ
ントの追加が開始され、たとえば過去数時間の⽋損データが補われます。
注意： サマリーの [サマリーステータス] が「Suspended」の場合、[更新] を使って最新の状態にすることはで
きません。
最初からインデックスを再構築する場合は、[再構築] をクリックします。この操作は、システムクラッシュやそ
の他の障害により⽋損データがある場合、または検証失敗の原因を修復した、または現在の状態でサマリーをその
まま使⽤しても構わない場合に⾏います。
システムからサマリーを削除する (そして今後サマリーを再⽣成しない) 場合は、[削除] をクリックします。サマ
リーがあまり使⽤されておらず、占有しているスペースを他の⽬的で使⽤したいような場合にこの操作を⾏いま
す。Splunk 管理の [サーチとレポート] ページを使って、レポートまたはサマリーに関連付けられているレポート
の⾼速化を、再度有効化することができます。
データモデルの⾼速化
データモデル⾼速化は、とても⼤きなデータセットを表すデータモデルを⾼速化するために利⽤できる機能です。
⾼速化すると、⾼速化されたデータモデルオブジェクトに基づくピボットは以前よりも短時間に完了します。ま
た、それらのピボットをベースにしているレポートやダッシュボードパネルも⾼速化されます。
データモデル⾼速化は、Splunk Enterpriseのハイパフォーマンス分析ストア機能を活⽤しています。この機能
は、レポート⾼速化と類似の⼿段で、背後でデータサマリーを構築します。レポート⾼速化のように、データモデ
ルサマリーは簡単に有効化/無効化できます。また、サマリーは、インデクサー上にサマリー対象のイベントを持
つインデックスバケツと⼀緒に保管されます。
ここでは、以下の事項を取り上げていきます。
データモデル⾼速化とレポート⾼速化、およびサマリーインデックス化の違い。
データモデルの永続的な⾼速化を有効にする⽅法。
Splunk Enterprise によるデータモデル⾼速化サマリー作成の仕組み。
tstats コマンドを使った⾼速化データモデルサマリーへのクエリー⽅法。
永続的に⾼速化されたデータモデルの⾼度な設定。
また、アドホックデータモデル⾼速化 についても説明しています。Splunk Enterprise は、⾼速化されていない
オブジェクトでピボットを作成する場合に、アドホックデータモデル⾼速化を適⽤します。これは、永続的な⾼速
化機能を利⽤できないサーチオブジェクトやトランザクションオブジェクトにも適⽤されます。ただし、これによ
る⾼速化の利点は、ピボットエディタを終了、またはピボットエディタのセッション中にオブジェクトを切り替え
ると失われてしまいます。これらの短所は、永続的な⾼速化オブジェクトにはあてはまりません。正式な⾼速化
は、ピボット経由でアクセスした際に常に適⽤されます。また、「永続的」データモデル⾼速化と違い、アドホッ
ク⾼速化はピボットで作成されたレポートやダッシュボードのパネルには適⽤されません。
データモデル⾼速化とレポート⾼速化/サマリーインデックス化との違い
⼤きな観点からの、データモデル⾼速化とレポート⾼速化/サマリーインデックスの違いを以下に⽰します。
レポート⾼速化とサマリーインデックス化は、レポートごとにレポートの個別のサーチを⾼速化します。こ
れを実現するために、事前に計算されたサーチ結果の集計が作成されます。
データモデル⾼速化は、データモデル内に定義した全体の属性 (フィールド) セットのレポート⽣成を⾼
速化 します。
つまり、データモデル⾼速化はユーザーが使⽤する特定のフィールドセットのサマリーを作成し、データセットに
対する特定のサーチではなく、そのフィールドの集合体が表すデータセットを⾼速化します。
141
ハイパフォーマンス分析ストアとは？
データモデル⾼速化サマリーは、ファイル拡張⼦が .tsidx の、時系列インデックスファイル形式を取ります。各
.tsidx サマリーには、選択したデータセット内のインデックス処理されたフィールド ::値のペアおよびそれらの
フィールド::値のペアのインデックスの場所レコードが含まれています。ハイパフォーマンス分析ストアを構成す
るのが、これらの .tsidx サマリーです。これらのサマリーは、特定のフィールドセット (⾼速化されたデータモデ
ル内に属性として定義されているフィールドセット) が関与する分析サーチを⾼速化するために最適化されていま
す。
⾼速化されたデータモデルのハイパフォーマンス分析ストアは、「サマリー範囲」を設定しています。これは、
データモデルの⾼速化を有効にする時に選択した時間範囲です。⾼速化されたデータセットに対してピボットを実
⾏する場合、ピボットの時間範囲が⼀部だけでもこのサマリー範囲内にないと、⾼速化の恩恵を受けられません。
たとえば、過去 1 ヶ⽉のデータを⾼速化したデータモデルがある場合に、このデータモデルオブジェクトを使っ
た過去 1 年間のデータに対するピボットを作成して実⾏すると、過去 1 ヶ⽉のデータに対して実⾏されるサーチ
処理だけが⾼速化されます。
単⼀のデータモデルに対するハイパフォーマンス分析ストアを構成する .tsidx ファイルは常に、1 つまたは複数
のインデクサーに分散することができます。Splunk Enterprise は .tsidx ファイルをインデクサー上に、ファイ
ル内で参照され、サマリー範囲をカバーしているイベントを含むバケツと⼀緒に保管しています。
注意： 永続的データモデル⾼速化を介して作成されたハイパフォーマンス分析ストアは、アドホックデータモデ
ル⾼速化を介して作成されたサマリーとは異なります。アドホックサマリーは常に、サーチヘッドのディスパッチ
ディレクトリに作成されます。アドホックデータモデルの詳細は、後述の「アドホックデータモデル⾼速化につい
て」を参照してください。
永続的データモデル⾼速化の有効化
データモデルの⾼速化は、[⾼速化の編集] ダイアログを使って有効にします。
1. データモデルの⾼速化を有効にするには、[⾼速化の編集] ダイアログを開きます。このダイアログを表⽰するに
は、3 種類の⽅法があります。
データモデル管理ページで⽬的のモデルを探し、[編集] をクリックして [⾼速化の編集] を選択します。
データモデル管理ページに移動し、⽬的のデータモデルの⾏を展開して、[⾼速化] の [追加] をクリックし
ます。
⽬的のデータモデルのデータモデルエディタを開いて、[編集] をクリックして [⾼速化の編集] を選択しま
す。
2. データモデルの⾼速化を有効にするには、[⾼速化] を選択します。
3. [サマリー範囲] を選択します。
[サマリー範囲] では、[1 ⽇]、[7 ⽇]、[1 ヶ⽉]、[3 ヶ⽉]、[1 年]、または [全時間] を選択できます。これ
は、データモデル内の⾼速化されたオブジェクトに対して、ピボットを実⾏する予定の時間範囲を表してい
ます。たとえば、過去 7 ⽇間に対してピボット操作を実⾏したい場合は、[7 ⽇] を選択します。この設定の
詳細は、後述する「サマリー範囲について」を参照してください。
[サマリー範囲] フィールドに表⽰されるサマリー範囲とは異なる範囲が必要な場合、datamodels.conf で⾃分
のデータモデル⽤に範囲を設定することができます。
注意： 時間範囲を短くすると、.tsidx ファイルが⼩さくなり、ファイルの構築時間やディスク占有スペースも減
少します。そのため、時間範囲はできる限り短くしてください。
サマリー範囲設定の詳細、およびその仕組みについては、後述する「サマリー範囲について」を参照してくださ
い。
データモデル⾼速化の注意事項
⾼速化できるデータモデルオブジェクトには、いくつかの制限があります。
データ・モデル⾼速化は、イベント・オブジェクト階層にのみ影響します。 ルート・サーチおよびルー
ト・トランザクション・オブジェクトをベースにしたオブジェクト階層は⾼速化されません。
⾼速化されていないオブジェクトを使⽤するピボットは _raw データを利⽤するため、当初の実⾏速度
は遅くなります。ただし、アドホック⾼速化の⼀部の恩恵を受けられます。詳細はこのトピックの最
後にある「アドホックデータモデル⾼速化について」を参照してください。
データ・モデル⾼速化は、⾼速化対象のルート・イベント・オブジェクトの初期制約サーチに、
Splunk Enterprise がサーチ対象とするインデックスが含まれている場合にもっとも効果を発揮しま
す。 単⼀のハイパフォーマンス分析ストアが、複数のインデクサーにある複数のインデックスにまたがって
いることもあります。ピボット操作を実⾏するすべてのデータが特定のインデックスまたは⼀部のインデッ
クス上に存在していることが分かっている場合は、Splunk Enterprise に対象を指⽰することで処理を⾼速
化することができます。そうでない場合は、⽬的外の⾼速化データの処理に無駄な時間が費やされる可能性
もあります。
データモデル使⽤の注意/制限事項の詳細は、このマニュアルの「データモデルの管理」を参照してください。
データモデルの⾼速化を有効にした後
データモデルの⾼速化を有効にすると、指定されたサマリー範囲のデータモデル⾼速化サマリーの構築が開始され
ます。サマリーは、データモデルに指定されているフィールドを含むイベントを持つインデックス内に作成されま
す。これらの .tsidx ファイルサマリーは、レポート⾼速化サマリーと同様の⽅法で、対応するインデックスバケ
ツと⼀緒に保管されます。
142
Splunk Enterprise は、5 分間隔でサーチを実⾏し、既存のデータモデルを更新します。また、30 分ごとにメン
テナンスプロセスを実⾏し、古くなったサマリーデータを削除します。これらの実⾏間隔は、それぞれ
datamodels.conf と limits.conf で調整することができます。
データモデルサマリーの参考情報：
Splunk Enterprise インスタンス内の各インデックスの各バケツが、1 つまたは複数のデータモデルサマ
リーを保有することができます (関連データを持つ各⾼速化データモデル)。これらのサマリーは、Splunk
Enterprise がデータを収集するにつれて作成されます。
次にサーチヘッド (またはサーチヘッドプール ID) によりサマリーの範囲が設定され、同じ⽂字列で異なる
結果を⽣成する可能性がある異なる抽出に対応します。
各データモデルには、元となる App と⼀緒に⾼速化されたディレクトリが存在しています。データモデル
⾼速化は、ある App またはグローバルに対応しています。プライベートのデータモデルを⾼速化すること
はできません。こうすることによって、特定のユーザーがプライベートのデータモデル⾼速化サマリーを
使って、ディスクスペースを消費することを防⽌しています。
注意： 必要に応じて、indexes.conf を利⽤して、データモデルサマリーの場所を設定することができます。
サマリー範囲について
⾼速化されたデータモデルのサマリー範囲は、⾼速化されたレポートのサマリー範囲とほぼ同様の役割を果たして
います。
データモデルのサマリー範囲は、時間範囲の近似値です。[サマリー範囲] で [7 ⽇] を選択すると、ほぼ過去 7 ⽇
間を期間とするデータモデルサマリーが作成されます。サマリーの構築が完了した後は、データモデルのサマリー
プロセスが継続され、常に設定されている期間をカバーするために、期限が過ぎた古いサマリーデータが削除さ
れ、要約された新しいデータが追加されます。
注意： サマリー範囲は、対象とする範囲の概算期間を表しています。わずかにサマリー範囲を超えたデータが保
管されている場合もありますが、最初のサマリー作成中の時点を除いては、それが⼀致するイベントとして表⽰さ
れることはありません。
将来的に、過去 1 週間などの期間に対してデータモデルの⾼速化されたオブジェクトを使ってピボットを実⾏す
ると、ピボットはソースインデックスの _raw データではなく、データモデルのサマリーに対して実⾏されます。
たいていの場合、サマリーのデータはソースインデックスのデータよりも⼤幅に少なくなっており、ピボット操作
がより短時間で完了します。
サマリー範囲が⼀部しかカバーしていない期間に対してピボットを実⾏する場合、ピボットはさほど速くは完了で
きません。これは、Splunk Enterprise が最低でもピボットサーチの⼀部を、Splunk Enterprise インデックス内
の raw データに対して実⾏する必要があるからです。たとえば、データモデルのサマリー範囲が 1 週間に設定さ
れている場合に、そのデータモデル内の⾼速化オブジェクトを使ったピボットを過去 9 ⽇間に対して実⾏する
と、処理が⾼速化するのは過去 7 ⽇間の部分だけになります。残りの 8 ⽇前と 9 ⽇前のデータは、通常の速度で
レポートが実⾏されます。このような場合、⾼速化された結果はまずサマリーから返され、次にギャップの部分が
遅い速度で返されます。
サーチ範囲 の値を設定する際には、このことを考慮するようにしてください。過去 7 ⽇間を超えるけれども過去
30 ⽇は超えないレポートを実⾏する予定の場合は、⾼速化の設定時にサマリー範囲 を 1 ヶ⽉に指定してくださ
い。
注意： Splunk には、サマリー範囲 に関連するいくつかの⾼度な設定が⽤意されています。数テラバイトもの
データを処理する⼤規模な Splunk 環境を運⽤する場合などに、それらの設定を使⽤できます。このような環境で
は、初期データモデル⾼速化サマリーを構築するためのサーチ実⾏時間が⻑くなり、またリソース消費も⼤きくな
る可能性があります。詳細は、「永続的に⾼速化されたデータモデルの⾼度な設定」を参照してください。
Splunk Enterprise によるデータモデル⾼速化サマリー作成の仕組み
データモデル⾼速化の有効化で説明したように、Spunk Enterprise はデータモデルの初期サマリー .tsidx ファイ
ルセットを作成し、その後サマリーを最新状態に保つためにバックグラウンドで 5 分間各でスケジュール済み
サーチを実⾏します。各更新により、⼤きなデータのギャップを⽣じることなくサマリーデータは設定されている
時間範囲が常にカバーされます。この⽅法によるサマリー構築により、最後に到着したデータも複雑化することな
く要約されます。
Splunk Enterprise がデータモデルを更新するためのサーチをスケジュールしているかどうかを検証するに
は、log.cfg に category.SavedSplunker=DEBUG を設定し、scheduler.log 内の以下のようなイベントを確認します。
04-24-2013 11:12:02.357 -0700 DEBUG SavedSplunker - Added 1 scheduled searches for accelerated datamodels to the end
of ready-to-run list
サマリー作成の処理速度は、関連するイベントの量とサマリー範囲によって異なります。サマリー作成完了までの
進捗状況は、データモデル管理ページで確認できます。⽬的の⾼速化データモデルを探してその⾏を展開し、[⾼
速化] に表⽰される情報を参照してください。
143
[ステータス] は、データモデルの⾼速化サマリー作成処理が完了したかどうかを⽰しています。ステータスが作
成中の場合、サマリー作成処理の完了状況がパーセントで表⽰されます。データモデルサマリーは新しいデータで
定期的に更新されることに注意してください。つまり現在のステータスが「完了」の場合でも、今後「作成中」に
なる可能性があります。
注意： データモデル⾼速化のステータスは時々更新され、キャッシュに格納されるため、最新のステータスを表
してはいないことがあります。
ディスク上のデータモデルサマリーのサイズ
データモデル管理ページのデータモデル測定基準を使って、ディスク上のデータモデルサマリーの合計サイズを確
認することができます。サマリーは、時には多くのディスクスペースを消費することもあるため、データモデル⾼
速化を乱⽤しないように注意する必要があります。たとえば、ダッシュボードパネルでピボット操作が多⽤されて
いるデータモデル⽤に、データモデル⾼速化を限定することができます。
データモデルが消費するディスクスペース量は、指定したサマリー範囲内に存在するイベント数に関連していま
す。また、データモデルにデータ濃度が⾼い属性 (Name 属性などの、⼀意の値が多い属性) が含まれている場合
も、サイズに悪影響を与えます。
消費サイズに制限がある場合は、まず⼩さなサマリー範囲 で⾼速化を有効にして、データモデル⾼速化サマリー
が消費するスペースを確認し、その後範囲を順次⼤きくして妥当な範囲を判断してください。
データモデルサマリーのサイズベースの保持の設定
ディスクストレージのスペースを消費しすぎないように、インデックスのサイズベースの保持制限を設定していま
すか？デフォルトでデータモデル⾼速化サマリーは、無制限のディスクスペースを利⽤することができます。イン
デックスまたはインデックスボリュームの最⼤データサイズもロックしている場合、このことが問題になる可能性
があります。ただし、データモデル⾼速化サマリーにも必要に応じて同様の保持制限を設定することができます。
注意： データモデル⾼速化サマリーのサイズベースの保持制限を設定する前に、まずボリュームを使った各イン
デックスにまたがるインデックスサイズ制限の設定⽅法について理解しておく必要があります。多くの原則が、こ
れと同じになります。詳細は、『インデクサーとクラスタの管理マニュアル』の「インデックスサイズの設定」を
参照してください。
デフォルトで、データモデル⾼速化サマリーは、次のパスにある事前定義ボリューム
います：
_splunk_summaries
に存在して
$SPLUNK_DB/<index_name>/datamodel_summary/<bucket_id>/<search_head_or_pool_id>/DM_<datamodel_app>_<datamodel_name>
このボリュームは当初は最⼤サイズが指定されていません。そのため、無制限に保持されます。
またデフォルトで indexes.conf には、tstatsHomePath パラメータがグローバル設定として 1 回のみ指定されていま
す。そのパスは、すべてのインデックスに継承されます。etc/system/default/indexes.conf で：
[global]
[....]
tstatsHomePath = volume:_splunk_summaries/$_index_name/datamodel_summary
[....]
このデフォルト動作に優先する設定を⾏うには、特定のインデックスに対して tstatsHomePath を指定して、定義し
た別のボリュームを指すようにします。また、ボリューム設定に maxVolumeDataSizeMB パラメータを指定すること
で、任意のボリューム (_splunk_summaries も含む) にサイズ制限を追加することもできます。
データモデル⾼速化サマリーの、サイズベースの保持の設定⼿順を以下に⽰します。ここに取り上げているすべて
の設定は、indexes.conf 内に⾏います。
1. (オプション) データモデル⾼速化サマリーの結果を、_splunk_summaries 以外のボリュームに保管する場合は、そ
れを作成します。
2. データモデル⾼速化サマリーデータ (_splunk_summariesなど) のホームとなる 1 つまたは複数のボリューム
に、maxVolumeDataSizeMB パラメータを追加します。
このパラメータは、インデクサーにまたがってデータモデル⾼速化サマリーのサイズベースの保持を管理し
ます。
3. インデックス定義を更新します。
データ・モデル⾼速化サマリー・データを取り扱う各インデックスに、tstatsHomePath パラメータを設定しま
す。パスが、ステップ 2 で指定したデータモデル⾼速化サマリーデータボリュームを指していることを確認
してください。
データモデル⾼速化サマリーに対して複数のボリュームを定義した場合、インデックスの
定が、適切なボリュームを指していることを確認してください。
tstatsHomePath
設
この例の設定は、_splunk_summaries ボリュームに、データモデル⾼速化サマリーのデータサイズ制限を指定してい
ます。
144
#########################
# Volume definitions
#########################
# This volume can contain up to 100GB of summary data, per the
# <code>maxVolumeDataSizeMB</code> setting.
[volume:_splunk_summaries]
path = $SPLUNK_DB
maxVolumeDataSizeMB = 100000
#########################
# Index definitions
#########################
# Using the _tstatsHomePath parameter, the _splunk_summaries volume
# manages overall data model acceleration size across each of these
# indexes, limiting it to 100GB.
[main]
homePath
= $SPLUNK_DB/defaultdb/db
coldPath
= $SPLUNK_DB/defaultdb/colddb
thawedPath = $SPLUNK_DB/defaultdb/thaweddb
tstatsHomePath = volume:_splunk_summaries/defaultdb/datamodel_summary
maxMemMB = 20
maxConcurrentOptimizes = 6
maxHotIdleSecs = 86400
maxHotBuckets = 10
maxDataSize = auto_high_volume
[history]
homePath
= $SPLUNK_DB/historydb/db
coldPath
= $SPLUNK_DB/historydb/colddb
thawedPath = $SPLUNK_DB/historydb/thaweddb
tstatsHomePath = volume:_splunk_summaries/historydb/datamodel_summary
maxDataSize = 10
frozenTimePeriodInSecs = 604800
[dm_acceleration]
homePath
= $SPLUNK_DB/dm_accelerationdb/db
coldPath
= $SPLUNK_DB/dm_accelerationdb/colddb
thawedPath = $SPLUNK_DB/dm_accelerationdb/thaweddb
tstatsHomePath = volume:_splunk_summaries/dm_accelerationdb/datamodel_summary
[_internal]
homePath
= $SPLUNK_DB/_internaldb/db
coldPath
= $SPLUNK_DB/_internaldb/colddb
thawedPath = $SPLUNK_DB/_internaldb/thaweddb
tstatsHomePath = volume:_splunk_summaries/_internaldb/datamodel_summary
データモデル⾼速化サマリーのボリュームがサイズ制限に達すると、スペースを確保するために、ボリューム内の
もっとも古いサマリーが削除されます。サマリーが削除されると、その対応するバケツ内にマーカーファイルが保
管されます。このマーカーファイルは、サマリー⽣成機能にサマリーを再構築しないことを指⽰するものです。
注意： データモデル⾼速化サマリーの場合と同様の⽅法で、レポート⾼速化サマリーのサイズベースの保持を設
定することができます。主な違いは、レポート⾼速化サマリーにはデフォルトのボリュームが存在しないことにあ
ります。両⽅の種類のサマリーを管理する場合、両⽅のサマリーでデフォルトの _splunk_summaries ボリュームを使
⽤する⽅が管理が簡単になる場合があります。両⽅の⾼速化サマリータイプのサイズベースの保持を管理する⽅法
の詳細は、このマニュアルの「レポート⾼速化の管理」を参照してください。
データモデル⾼速化サマリーのクエリー
[サーチ] で tstats コマンドを使って、特定の⾼速化データモデルのハイパフォーマンス分析ストアをクエリーす
ることができます。
は、複数のインデックスに分散されている場合を含めて、⾼速化データモデルに所属するすべての
ファイルサマリーを調査することができます。
tstats
.tsidx
この⽅法を利⽤すれば、特定のデータモデルに対して stats ベースのサーチを実⾏し、選択したサマリー範囲内の
収集データが期待通りかどうかを⼿軽に確認することができます。
このためには、FROM
datamodel=<datamodel-name>
を使ってデータモデルを指定します。
| tstats avg(foo) FROM datamodel=buttercup_games WHERE bar=value2 baz>5
上記のクエリーは、「Buttercup Games」データモデル⾼速化サマリー内の
より⼤きいフィールドの平均を返します。
145
foo
の、bar が
value2
で
baz
の値が
5
注意： データモデルの App を指定する必要はありません。Splunk Enterprise がサーチコンテキスト (現在使⽤
している App) から取得します。ただし、App B 内のデータモデルがグローバルに共有されている場合を除き、
App A から App B 内の⾼速化データモデルにクエリーすることはできません。
サマリー専⽤の引数の使⽤
tstats
コマンドの
summariesonly
引数により、データモデルサマリーの特定の情報を取得することができます。
この例では、summariesonly 引数を使って、⾼速化されたデータモデル
ます。
mydm
の、サマリーの時間範囲を取得してい
| tstats summariesonly=t min(_time) as min, max(_time) as max from datamodel=mydm | eval prettymin=strftime(min,
"%c") | eval prettymax=strftime(max, "%c")
この例は summariesonly と timechart を使⽤して、⾼速化されたデータモデル
うなデータのサマリーが作成されたかを表しています。
mydm
の、選択した時間範囲にどのよ
| tstats summariesonly=t prestats=t count from datamodel=mydm by _time span=1h | timechart span=1h count
を使った標準インデックスデータへのクエリー⽅法を含めて、tstats コマンドの使⽤⽅法の詳細は、『サー
チリファレンス』の tstats に関する項⽬ を参照してください。
tstats
永続的に⾼速化されたデータモデルの⾼度な設定
datamodels.conf
に永続的データモデル⾼速化に関する⾼度な設定が必要な、⾮常に特殊な状況もいくつか存在して
います。
サマリー⽣成サーチの実⾏時間が⻑すぎる
ご利⽤の Splunk Enterprise 環境で、⾮常に⼤量のデータを定期的に処理しているような場合、最初の永続的
データモデル⾼速化サマリーの作成が、膨⼤なリソースを消費してしまう可能性があります。これらのサマリーを
作成するサーチの実⾏時間が⻑すぎるため、到着したイベントのサマリー作成が失敗してしまうこともあります。
このような状況に対処するために、Splunk Enterprise の datamodels.conf には 2 種類の設定パラメータが⽤意さ
れています。それらのパラメータは、max_time と backfill_time です。
重要： ⼤部分の Splunk Enterprise ユーザーは、この設定を調整する必要はありません。デフォルトの max_time
の設定 1 時間でも、サマリー作成までに⻑時間かかるサーチが新たなイベントのサーチへの追加を妨げることは
ありません。これらの⾼度なサマリー範囲設定は、サマリー作成に関する問題に対する唯⼀の⼿段とならない限
り、変更しないことをお勧めします。
サマリー⽣成サーチを実⾏可能な最⼤期間の変更
は、指定時間経過後にサマリー⽣成サーチを停⽌します。サマリー⽣成サーチの停⽌後、Splunk
Enterprise は初期のサマリー⽣成サーチ開始後に到着したすべてのイベントを収集するためのサーチを実⾏し、
次に最後のサマリー⽣成サーチが中断された時点からサマリーの追加を継続します。デフォルトで max_time パラ
メータは 3600 秒 (60 分) に設定されています。この設定でも、⼤部分の Splunk Enterprise インスタンスで
は、適切なサマリー作成が保証されます。
max_time
例：データモデル⾼速化を有効にして、サマリーに過去 3 ヶ⽉のイベントを保持したいと考えています。社内の
インデックスには⼤量のデータが存在しており、サマリーを最初に作成するサーチの完了には間違いなく 4 時間
はかかります。残念ながらその処理でサーチを継続的に実⾏する訳にはいきません。4 時間のサーチ処理中に到着
した新たな⼀部のイベントの、インデックス作成が失敗する可能性があります。
パラメータでサーチを 1 時間後に中⽌し、その処理中に到着した新たなイベントを取り込む別のサーチを
実⾏させることができます。その後、過去 3 ヶ⽉のイベントからのイベントの、サマリーへの追加処理が続⾏さ
れます。この 2 番⽬のサーチも 1 時間後に停⽌して、同様の処理が繰り返されます。これは、サマリー作成が完
了するまで継続されます。
max_time
注意： max_time パラメータの時間制限は概算値です。60 分経過後、Splunk Enterprise には現在のバケツのサマ
リー作成を完了する時間が必要です。そうすることにより、作業の無駄を省けます。
サマリー時間範囲よりも短いバックフィル時間範囲の設定
Splunk 環境で膨⼤なデータのインデックスを作成しており、⻑時間かかるサマリー⽣成サーチのために
を調整したくない場合、代わりに backfill_time パラメータを利⽤することができます。
max_time
パラメータはサマリー範囲内に設定する、2 番⽬の「バックフィル時間範囲」を作成します。
Splunk Enterprise は、当初はこの短い時間範囲のみをカバーする、部分サマリーを作成します。その後サマリー
は、にり⼤きなサマリー範囲の限度に達するまで、新たなイベントのサマリーへの追加により増加していきます。
限度に達すると、サマリーの作成が完了し、そのサマリー範囲外になったイベントの保持は中⽌されます。
backfill_time
たとえば、[サマリー範囲] に [1 ヶ⽉] を設定したけれども、その時間範囲のサマリーを構築するサーチによりシ
ステムに負担がかかる場合を考えてみましょう。この問題に対処するために、acceleration.backfill_time = -7d を
設定して、当初は過去 1 週間のみを対象にした部分サマリーを作成するサーチを実⾏します。その制限に達した
ら、Splunk Enterprise は新たなイベントのみをサマリーに追加します。その結果、サマリーがカバーする時間範
囲が増加していきます。ただし、完全なサマリーは 1 ヶ⽉のイベントのみを保持するため、部分サマリーが過去
1 ヶ⽉のサマリー範囲 まで増加すると、通常のデータモデルサマリーと同様に、もっとも古いイベントから破棄
されていきます。
146
永続的⾼速化データモデルを⾃動再構築したくない場合
デフォルトで Splunk Enterprise は、永続的⾼速化データモデルが期限切れだと判断した時に、モデルを⾃動的
に再構築します。savesearches.conf のデータモデル設定に保管されているサーチが、実際のデータモデルのサーチ
と⼀致しなくなった場合に、データモデルは期限切れとなります。これは、⾼速化モデルの JSON ファイルが、
先にモデルの⾼速化を無効にしないで、ディスク上で編集された場合などに発⽣します。
希な状況ですが、特定の⾼速化データモデルに対して、期限切れになった時に⾃動的に再構築を⾏わないよう、こ
の機能を無効にしたい場合もあります。代わりに、管理者に⼿動で再構築を開始させます。管理者はデータモデル
管理ページから、⼿動でデータモデルを再構築することができます。その場合は、対象データモデルの⾏を展開し
て、[再構築] をクリックします。データモデル管理ページの詳細は、このマニュアルの「データモデルの管理」
を参照してください。
特定の永続的⾼速化データモデルの⾃動再構築を無効にするには、datamodels.conf を開いてデータモデルのスタン
ザを探し、次を設定します： acceleration.manual_rebuilds = true
アドホックデータモデル⾼速化について
永続的に⾼速化されていないデータモデルオブジェクトに基づくピボットを作成する場合でも、そのピボットには
「アドホック」データモデル⾼速化の利点が適⽤されます。この場合、ピボットエディタでオブジェクトを使った
ピボットの作成を開始すると、サーチヘッドのディスパッチディレクトリにサマリーが作成されます。
アドホックデータモデル⾼速化サマリーの構築は、オブジェクトを選択してピボットエディタを開いた後に開始さ
れます。アドホックサマリー作成の進捗状況は、進捗バーで確認することができます。
進捗バーに [完了] が表⽰されたら、アドホックサマリーの作成は完了です。それ以降はサマリーを使って、より
迅速にピボット結果が返されます。ただし、このサマリーはピボットエディタで当該オブジェクトに対する作業を
⾏っている間しか保持されません。エディタを終了した、または他のオブジェクトに切り替えてから元のオブジェ
クトに戻った場合は、アドホックサマリーの再構築が必要です。
アドホックデータモデル⾼速化サマリーは、より短い期間のデータを収集する場合に、より素早く完了します。ピ
ボットエディタの時間フィルタ をリセットすることで、ルートイベントオブジェクト、ルートトランザクション
オジ絵、およびその⼦に対して、この範囲を変更することができます。詳細は後述する「アドホックデータモデル
⾼速化のサマリー時間範囲」を参照してください。
アドホックデータモデル⾼速化は、ルートサーチオブジェクトやルートトランザクションオブジェクトを含む、す
べてのオブジェクトタイプに適⽤されます。永続的データモデル⾼速化の主な⽋点は、永続的データモデル⾼速化
では、データモデルの⾼速化を無効にするまでの間、サマリーが常に存在し、ピボットのパフォーマンスを⾼速化
することにあります。アドホックデータモデル⾼速化では、ピボットエディタの起動時に毎回、サマリーの再構築
を待つ必要があります。
アドホックデータモデル⾼速化サマリーの時間範囲について
サーチヘッドは常に、ピボットエディタの時間フィルタ に設定された範囲に適合するように、アドホックデータ
モデル⾼速化サマリーを作成します。オブジェクトをピボットエディタで初めて開いた場合、ピボットの時間範囲
は [全時間] に設定されています。⼤量のデータセットを表すオブジェクトの場合、当初のピボットの完了に時間
がかかった可能性があります (背後でアドホックサマリーを作成するため)。
ピボットに [全時間] 以外の時間範囲を指定すると、できる限り効率的にその範囲に適合するアドホックサマリー
が作成されます。任意のデータモデルオブジェクトに対して、あるピボットの短期間のアドホックサマリーは、同
じピボットのより⻑い期間のサマリーよりも短時間に完了します。
現在の時間範囲を、別の「もっとも遅い」時間を持つ新たな時間範囲に変更すると、サーチヘッドはアドホックサ
マリーの開始から終了への再構築のみを⾏います。これは、サーチヘッドが各アドホックサマリーを、もっとも遅
い時間からもっとも早い時間へと作成するためです。もっとも遅い時間をそのまま保持し、もっとも早い時間を変
更すると、サーチヘッドは必要な他のデータの収集をできる限り試みます。
注意： ここで、ルートサーチオブジェクトとその⼦オブジェクトは、ピボット内で時間範囲フィルタを持たない
ため、特殊な事例となります (属性として _time を抽出しない)。これらのオブジェクトをベースにしたピボット
は、サーチが返すすべてのイベントに対して常にサマリーを作成します。ただし、ルートサーチオブジェクトの
サーチ⽂字列を、「もっとも早い」および「もっとも遅い」⽇付を含めるように設定して、ルートサーチオブジェ
クトとその⼦が表すデータ セットを制限することができます。
アドホックデータモデル⾼速化と永続的データモデル⾼速化の違い
アドホックデータモデル⾼速化と永続的データモデル⾼速化の違いの概要を以下に⽰します。
アドホックデータモデル⾼速化は、インデクサーではなくサーチヘッド上で⾏われます。 これにより、
3 つのオブジェクト (イベント、サーチ、トランザクション) すべてを⾼速化することができます。
Splunk Enterprise は、サーチヘッドのディスパッチディレクトリに、アドホックデータモデル⾼速
化サマリーを作成します。 永続的データモデル⾼速化サマリーは、インデックスバケツと⼀緒にインデッ
クス内に作成、保管します。
アドホックデータモデル⾼速化サマリーは、ピボットエディタの終了時、またはピボットエディタで
オブジェクトを変更した場合に削除されます。 ピボットエディタで同じオブジェクトを再び開いた場合、
サーチヘッドはアドホックサマリーを再構築する必要があります。アドホックデータモデルサマリーを保持
147
して、後ほど再利⽤することはできません。
ピボットジョブ ID はピボット URL 内に保持されます。そのため、ピボットを離れた後すぐに [戻る]
ボタンを使⽤すると (またはパーマリンクでピボットジョブに戻ると)、そのジョブのアドホックサマ
リーを、再構築を待たずに使⽤できることがあります。サーチヘッドは、ピボットから離れた後、ま
たはピボット内で別のモデルに切り替えた後、数分間でディスパッチディレクトリからアドホック
データモデル⾼速化サマリーを削除します。
アドホック⾼速化は、ピボットをベースにしたレポートやダッシュボードパネルには適⽤されませ
ん。 ピボット・ベースのレポートやダッシュボード・パネルを⾼速化したい場合は、永続的⾼速化イベン
ト・オブジェクト階層のオブジェクトを利⽤してそれを作成します。
アドホックデータモデル⾼速化は、永続的データモデル⾼速化がインデクサーに与える負荷よりも⼤
きな負荷をサーチヘッドに与える可能性があります。 永続的に⾼速化されていないピボット内の、特定の
データモデルオブジェクトにアクセスする各ユーザーに対して、サーチヘッドは個別のデータモデル⾼速化
サマリーを作成するためです。⼀⽅、永続的⾼速化データモデルオブジェクトのサマリーは、関連するデー
タモデルの各ユーザー間で共有されます。このデータモデルサマリーは結果を再利⽤するため、インデク
サーの負担が少なくなります。
サマリーインデックスを使ったレポート効率の向上
⼤量のデータのレポートを効率的に⽣成するには、サマリーインデックス を使⽤します。サマリーインデックス
では、定期的に⽬的の情報を正確に抽出するサーチを設定します。Splunk Enterprise がこのサーチを実⾏すると
毎回、指定したサマリーインデックスに結果が保存されます。次にこの⼤幅に⼩さな (そして「⾼速な」) サマ
リーインデックスに対して、サーチやレポートを実⾏します。さらに、これらのレポートは、サマリーインデック
スにデータを追加するサーチの頻度を増やすにより、統計的に正確になります (たとえば、過去 7 ⽇間を対象とす
るサーチを⼿動実⾏する場合、1 時間ごとにサマリーインデックスに対してデータを追加するサーチを実⾏しま
す)。
サマリーインデックスでは、コンピュータ的にコストが⾼いレポートを、時間の経過に応じて分散させることがで
きます。先ほどから取り上げている例では、サマリーインデックスに過去 1 時間のデータを追加するために、毎
時間実⾏されるサーチは 1 分もかかりません。サマリーインデックスを利⽤せずに完全なレポートを⽣成しよう
とすれば、その 168 倍 (7⽇ * 24 時間/⽇) もの時間がかかってしまいます。
サマリーインデックスのさらに重要な特⻑として、異なるレポートまたは時間範囲は違うけれども重なっている部
分がある同⼀のレポートに、コストを分配できることが挙げられます。⽕曜⽇に⽣成された同じサマリーデータ
を、⽔曜、⽊曜、または翌週の⽉曜に実⾏される過去 7 ⽇間のレポートに利⽤することができます。また、⽇当
たりの平均応答サイズが必要な⽉次レポートに使⽤することもできます。
サマリーインデックスの使⽤事例
例 1 - ⻑期間の⼤量のデータセットに対するレポート実⾏の効率化： ある会社で、Splunk Enterprise を使っ
て毎⽇数千万件を超えるイベントのインデックスが作成されている場合を考えてみましょう。各 Web サイトの過
去 30 ⽇間のページビューと訪問者数のレポートを表⽰するダッシュボードを、社員⽤に開発したいと考えていま
す。
このレポートをプライマリデータボリュームに対して実⾏することも可能ですが、⽬的のデータを抽出するため
に、Web トラフィックとは無関係のデータも存在し、膨⼤な数のイベントを処理する必要があるため、実⾏が完
了するまでには⾮常に時間がかかってしまいます。それだけではありません。よく利⽤されるダッシュボードにレ
ポートを表⽰すると⾔うことは、頻繁にサーチが実⾏されることを意味しており、そのせいで平均実⾏時間がさら
に⻑くなり、多くのユーザーの不満につながる可能性があります。
サマリーインデックスを利⽤して週単位、⽇単位、または時間単位に、特定のサマリーインデックスにWeb サイ
トのページビューとビジター数に関する情報を収集して追加する保存済みサーチを設定することができます。次に
⽉末に、この⼤幅に⼩さく必要なデータが集約されたサマリーインデックスに対してサーチを実⾏すれば、レポー
ト⽣成を素早く完了することができます。
例 2：ローリングレポートの作成： ⻑期間に渡る総統計の連続カウントを表⽰するレポートを実⾏する場合を考
えてみましょう。ここでは、たとえば管理している Web サイトからのファイルのダウンロード数をカウントして
います。
まず、指定した期間の合計ダウンロード数を返す保存済みサーチをスケジュールします。次にサマリーインデック
スを使って、そのサーチ結果をサマリーインデックスに保管するように設定します。次に、サマリーインデックス
内のデータに対してレポートを実⾏すれば、最新の合計ダウンロード数を取得することができます。
Splunk Enterprise 開発者向けのビデオを参照して、サマリーインデックスの理論や実例を学習することも可能で
す。
サマリーインデックス⽤レポートコマンドの使⽤
サマリーインデックスを初めて使⽤する場合、サマリーインデックスにデータを追加するサーチを定義するには、
サマリーインデックス⽤レポートコマンド (sichart、sitimechart、sistats、sitop、およびsirare) を使⽤してくだ
さい。これらのコマンドを使⽤すれば、その後サマリーインデックスに対して実⾏するサーチと同じサーチ⽂字列
を使⽤することができます (ただし、後で実⾏するサーチでは、通常のレポートコマンドを使⽤します)。
注意： 伝統的なサマリーインデックス作成サーチの作成⽅法に熟達している場合は、これらの「si」で始まるサマ
リーインデックス⽤サーチコマンドを使⽤する必要はありません。そのような⽅法でサマリーインデックスを作成
し、それが適切に機能している場合は、更新する必要はありません。実際、より効率的な場合もあります。「si」
で始まるコマンドを使⽤すると、⼿動で作成する場合と⽐べて作成されるインデックスがわずかに⼤きくなるた
め、パフォーマンスに影響が出てしまいます。
たいていの場合はさほど影響は出ませんが、作成するサマリーインデックスが⽐較的⼤きい場合は違いに気が付く
こともあります。また、「si」で始まるコマンドで作成されたサマリーインデックスに対して、複数のレポート⽣
成サーチを設定した場合にも、パフォーマンスに影響が出る場合があります。
「si」で始まるサーチコマンドを使⽤しないでサマリーインデックスを作成したい場合は、以降のセクションを参
148
照してください。
特別なコマンドを使わないインデックス⽣成の定義
以前のバージョンの Splunk Enterprise では、サマリーインデックスを⽣成してデータを追加するためのサーチ
の設計に、⼊念な注意を払う必要がありました。特に完成したサマリーインデックスに対して実⾏するサーチに総
統計が含まれている場合は、不正な結果を⽣み出さないように、インデックス設定サーチを⼊念に検討する必要が
ありました。たとえば、完成したサマリーインデックスに対して、平均応答時間をサーバー別に表⽰するサーチを
実⾏する場合、サマリーインデックス⽣成サーチを以下のようには設定することをお勧めします。
サマリーインデックスに対して将来的に実⾏する予定のサーチよりも、より頻繁に実⾏するようにスケ
ジュールされている。
サマリーインデックスに対して将来的に実⾏を予定しているサーチよりも、多くの標本を抽出している。
インデックス⽣成サーチが加重平均を⽣成するようなサーチコマンドが含まれている (最初の段階で平均を
探している場合にのみ必要)。
サマリーインデックス⽤レポートコマンドは、最後の 2 点に注意しています。サマリーインデックスに追加され
るデータが統計的に不正確な結果を産出しないように、調整する必要がある事項を⾃動的に判断しています。ただ
し、それでもサマリーインデックス⽣成サーチは、サマリーインデックスに対して実⾏されるサーチよりも頻繁に
実⾏する必要があります。
「si」で始まるコマンドを使わずにサマリーインデックスを設定しますか？addinfo、collect、overlap コマンドの
詳細、重み付け平均を提供するサーチの策定⽅法、およびsavedsearches.conf を使ったサマリーインデックス設定
例については、このマニュアルの「サマリーインデックスの設定」を参照してください。
サマリーインデックスレポートコマンドの使⽤例
過去 1 年間の時間範囲に対して、以下のサーチを実⾏している場合を考えてみましょう。
eventtype=firewall | top src_ip
このサーチは、過去 1 年間の上位にあるソース IP を返しますが、毎回インデックス全体をサーチするため完了ま
でに膨⼤な時間がかかっています。
そこで必要になるのが、「firewall」イベントタイプからの上位のソース IP データから成り⽴っているサマリー
インデックスを作成することです。以下のサーチを利⽤して、サマリーインデックスを構築することができます。
このサーチを⽇単位で実⾏するようにスケジュールして、毎回過去 24 時間の上位による src_ip 値のみを収集し
ます。各⽇次サーチの結果は、「summary」と⾔う名前のインデックスに追加します。
eventtype=firewall | sitop src_ip
注意： サマリーインデックスデータ追加サーチは、完成したサーチに対して実⾏する予定のサーチよりもより頻
繁に実⾏して標本を抽出するようにスケジュールすると、より統計的に精度が向上します。そこで、この例では 1
年の期間をカバーするサーチの実⾏を予定しているため、情報を⽇単位でサンプリングするサマリーインデックス
データ追加サーチを設定しています。
重要： サマリーインデックスデータ追加サーチを実⾏する場合、メインのサマリーインデックスレポートコマン
ドの後に、他のサーチ演算⼦にパイプしないようにしてください。つまり、| eval などのコマンドを追加しないよ
うにしてください。サマリーインデックスにデータを追加するサーチではなく、サマリーインデックスに対して実
⾏するサーチにサーチ演算⼦を使⽤してください。
重要： サマリーインデックス向けに最適化されたサーチ結果は、特別なフォーマットで保存されるため、最終的
な変換が⾏われるまでの間変更することはできません。つまり、... | sistats <args> を使ってサマリーインデック
スにデータを追加した場合、有効なデータ取得は次のみになります：index=<summary> source=<saved search name> |
stats <args>。| stats <args> コマンドの前の、サマリーインデックスに対するサーチでは、フィールドを作成、変
更することはできません。
さて、このサーチを「Summary - firewall top src_ip」と⾔う名前で保存した場合を考えてみましょう (すべての
保存済みサマリーインデックスデータ追加サーチには、それらを識別するための名前を付ける必要があります)。
サマリーインデックスに結果が追加されたら、サマリーインデックスと情報を追加するために使⽤したサーチ名を
使⽤して、サマリーインデックスに対するサーチやレポートを実⾏します。たとえば、過去 1 年間の上位の
source_ips を取得するために使⽤するサーチは以下のようになります。
index=summary search_name="summary - firewall top src_ip" |top src_ip
このサーチはサーチ名を指定しているため、他のサマリーインデックス追加サーチを使って保管された他のデータ
はフィルタリングされます。このサーチは、時間範囲が 1 年以上の場合でも、⽐較的素早く実⾏が完了します。
注意： サマリーインデックスに対して特定の sourcetype 値を持つイベントを照会するサーチを実⾏する場合、代
わりに orig_sourcetype を使⽤する必要があることに注意してください。つまり、サマリーインデックスに対して
...|stats timechart avg(ip) by sourcetype のようなサーチを実⾏する代わりに、...|stats timechart avg(ip) by
orig_sourcetype を使⽤します。
なぜそうしなければならないのでしょうか？イベントをサマリーインデックスに追加すると、Splunk Enterprise
はその sourcetype の値を「stash」に変更し、元のソースタイプ値を orig_sourcetype に移動します。
Splunk Web でのサマリーインデックスサーチの設定
Splunk Web を使ってサマリーインデックスに対するサーチを設定できます。サマリーインデックス は、スケ
ジュール済みレポートのアラートオプションです。サマリーインデックスの⽣成に使⽤するレポートを決定した
ら、以下の⼿順に従ってください。
149
1. [設定] > [サーチ、レポート、アラート] に移動します。
2. レポートの名前を選択します (新たに作成する場合は [新規] をクリック)。
3. レポートをまだスケジュールしていない場合は、[スケジュールとアラート] で [このサーチをスケジュール] を
選択します。
レポートのスケジュールオプションを表⽰するには、[このサーチをスケジュール] を選択する必要があり
ます。
4. レポートを適切な間隔で実⾏するようにスケジュールします。
統計的に正確な最終レポートを作成するために、サマリーインデックスにデータを追加 (⽣成) するサーチは
⽐較的頻繁に実⾏する必要があります。将来的にサマリーインデックスに対して実⾏するレポートが過去 1
週間の情報を収集する場合、サマリーデータ追加レポートは時間単位に実⾏して時間ごとの情報を収集する
ようにしてください。過去 1 年間のデータに対してレポートを実⾏する場合は、⽇単位に過去 1 ⽇のデータ
をサマリーインデックスに追加します。詳細は、『レポートマニュアル』の「レポートのスケジュール」を
参照してください。
注意： データの取りこぼし (ギャップ) やオーバーラップが発⽣しないようにレポートをスケジュールして
ください。詳細は、後述するこの問題に関するサブトピックを参照してください。
5. [アラート] で、[条件] に [常時] を設定します。
6. [アラートモード] に [サーチ当たり 1 回] を設定します。
そうすることにより、レポート実⾏時に毎回アラートが正しく⽣成されます。
7. [サマリーインデックス] で、[有効] を選択します。
[有効] を選択すると、Splunk Enterprise は⾃動的にアラートの [条件] を [常時] に、そして [アラート
モード] を [サーチ当たり 1 回] に設定します。サマリーインデックスを無効にしないと、これらのフィール
ドに他の値を選択することはできません。
8. [サマリーインデックスを選択] リストで、レポートがデータを追加するサマリーインデックス名を選択しま
す。
デフォルトのサマリーインデックス名は、「summary 」になります。リストには、書き込み権限があるイン
デックスのみが表⽰されます。
9. (オプション) さまざまなサマリーインデックスレポートを利⽤する場合は、個別のサマリーインデックスを作成
しなければならないこともあります。
新たなインデックスの作成の詳細は、『インデクサーとクラスタの管理マニュアル』の「複数のインデック
スの設定」を参照してください。サマリーデータ収集専⽤のインデックスを作成することもお勧めできま
す。
10. (オプション) [フィールドの追加] で、サマリーインデックス定義にフィールド/値のペアを追加することがで
きます。
これらのキー/値のペアは、サマリーインデックスが作成された各イベントに注釈付けられます。そうするこ
とにより、後ほどのサーチで簡単に探すことができます。たとえば、サマリーインデックスにデータを追加
するレポート名 (report=summary_firewall_top_src_ip) または レポートがデータを追加するインデックス
名 (index=summary ) を追加して、後ほどそれらに対してサーチを実⾏することができます。
注意： また、savedsearches.conf 内のサマリーインデックス設定にフィールド/値のペアを追加することもで
きます。詳細は、『ナレッジ管理マニュアル』の「サマリーインデックスの設定」を参照してください。
サーチをレポートまたはアラートとして保存する⽅法の詳細は、「レポートの作成と編集」 (『レポートマニュア
ル』) および「アラートの作成」 (『アラートマニュアル』) を参照してください。
データのギャップと重複を回避するデータ設定レポートのスケジュール
データのギャップやオーバーラップを最低限に抑えるために、サマリーインデックスの⽣成とデータ追加に使⽤す
るレポートのスケジュールには、適切な間隔と期間を設定する必要があります。
サマリーインデックス内のギャップは、サマリーインデックスがイベントのインデックスを作成できなかった期間
です。以下のような場合にギャップが発⽣します。
150
サマリーインデックスにデータを追加するレポートの実⾏に時間がかかりすぎて、次回に予定されて
いる実⾏時間を過ぎてしまった。 たとえば、⼀般的にレポートの実⾏完了までに 7 分ほどかかるサーチ
を、サマリーにデータを追加するレポートとして 5 分間隔で実⾏する場合、先に実⾏されているレポートが
完了するまで後続のレポートは実⾏されません。
サマリーインデックス追加レポートに対してリアルタイムスケジューリングが使⽤された。 たとえば
誤って savedsearches.conf 内のレポート定義を編集して、realtime_schedule 属性に 1 を設定し、リアルタイム
スケジューリングが有効になっている可能性があります。この設定では、複数のレポートを同時実⾏してい
る場合、データコレクションにギャップが発⽣してしまう可能性があります。Splunk Web でサマリーイン
デックス追加レポートを定義する場合、サマリーインデックスオプションを [有効] にして、レポートを保存
します。これにより、Splunk Enterprise は realtime_schedule に 0 を設定し、レポートの定期実⾏がスキッ
プされないようにしています。詳細は、『レポートマニュアル』の「スケジュール済みレポートの優先度の
設定」を参照してください。
splunkd が停⽌している。 Splunk Enterprise がイベントのインデックスを作成できないと、インデックス
サマリーデータにギャップが⽣じてしまいます。
オーバーラップとは、同じタイムスタンプを共有している (同じレポートからの) イベントです。イベントのオー
バーラップにより、サマリーインデックスから作成されるレポートや統計が歪曲されてしまいます。レポートの時
間範囲を、レポートのスケジュール間隔よりも⻑く設定した場合に、オーバーラップが発⽣する可能性がありま
す。そのため、たとえば 1 時間ごとに実⾏するレポートで、過去 90 分のデータを収集するようなことは避ける
ようにしてください。
注意： サマリーインデックスデータにギャップまたはオーバーラップが存在していると考えられる場合に備え
て、Splunk Enterprise にはそれを検出してバックフィル (ギャップの場合) またはオーバーラップを削除する⼿
段が⽤意されています。詳細は、このマニュアルの「サマリーインデックスのギャップとオーバーラップの管理」
を参照してください。
サマリーインデックスの仕組み
サマリーインデックス は、保存されたスケジュール済みサーチ⽤のアラートオプションです。サマリーインデッ
クスを有効にした保存済みサーチを実⾏すると、サーチ結果は⼀時的にファイル
($SPLUNK_HOME/var/spool/splunk/<savedsearch_name>_<random-number>.stash) に保管されます。このファイルから、
Splunk Enterprise は addinfo コマンドを使って、各結果の設定中に現在のサーチに関する全般情報と指定
フィールドを追加します。次にできあがったサマリーインデックス内のイベントデータのインデックスを作成しま
す (デフォルトは index=summary)。
注意： 現在のサーチに関する全般情報を含むフィールドを、サマリーインデックスに⼊れるサーチ結果に追加す
るには、addinfo コマンドを使⽤します。サーチの全般情報を追加することで、サマリーインデックスに保管する
結果のレポートを⼿軽に実⾏することができます。
タイムスタンプを持たないデータのサマリーインデックス
サマリーインデックスイベントの時間を設定するために、Splunk Enterprise は以下の情報を順番に使⽤していき
ます (優先度順)。
1. 要約されるイベントの
_time
値。
2. サマリーインデックスにデータを追加するスケジュール済みサーチのもっとも早い (最⼩の) 時間。たとえば、
サマリーインデックス⽣成サーチが、各サーチ実⾏の 2 分前をカバーしている場合、もっとも早い時間は -2m に
なります。
3. 現在のシステム時刻 (「もっとも早い」の値が指定されていない「全時間」サーチ)
たいていの場合、イベントにはタイムスタンプがあります。そのため、最初の⼿段でサマリーインデックスにタイ
ムスタンプが保持されます。しかし、_time フィールドが含まれていないデータを要約する場合 (ルックアップか
らのデータなど)、結果となるイベントのタイムスタンプはサマリーインデックス⽣成サーチのもっとも早い時間
になります。
たとえば、毎晩午前 0 時にルックアップ「asset_table」を要約しており、このテーブルに _time 列がない場合、
そのサマリーの _time 値はサーチのもっとも早い時間になります。サーチの時間範囲を -24h〜+0sに設定した場
合、要約されたイベントの _time 値は now()-86400 になります (サーチ開始時刻 - 86,400 秒 (24 時間))。つまり、
このサマリーインデックス追加サーチで⾒つかった、_time フィールド値をもたない各イベントに対して、同⼀の
_time 値 (サーチのもっとも早い時間である) が与えられます。
タイムスタンプを持たないデータのサマリーインデックスを作成する際には、サーチの⼀部として
作成することをお勧めします。先ほどの例で作業を続⾏します。
_time
値を⼿動
|inputlookup asset_table | eval _time=now()
「si」で始まるサマリーインデックスコマンドで追加されたフィールド
サマリーインデックスにデータを追加するために、si* コマンドを使ってサーチを実⾏すると、サマリーインデッ
クスデータには⼀連の特殊フィールドが追加されます。これらのフィールドはすべて psrsvd で始まります
(例：psrsvd_ct_bytes や psrsvd_v など)。chart、timechart、stats などのレポートコマンドを使って、サマリーイン
デックスに対してサーチを実⾏すると、psrsvd* フィールドを使ってテーブルやグラフ⽤の統計的に正しい結果が
算出されます。psrsvdは、「prestats reserved」を表しています。
⼤部分の psrsvd フィールドは、データ セット内の元の (サマリーインデックス作成前の) ファイルにある、特定の
フィールドに関する情報を表しています。ただし、⼀部の psrsvd フィールドは、単⼀のフィールドの情報を表す
のではありません。⼀般的なパターンとしては、psrsvd_[type]_[fieldname] が挙げられます。たとえ
ば、psrsvd_ct_bytes は bytes フィールドのカウント情報を表しています。
151
ば、psrsvd_ct_bytes は
このような
psrsvd
bytes
フィールドのカウント情報を表しています。
フィールドの⼀覧を以下に⽰します。
= カウント
= グループカウント (統計の「集団」カウントで単⼀フィールドを対象にしているのではありません)
nc = 数値カウント (数値の数)
sm = 和
ss = 平⽅和
v = バージョン (単⼀のフィールドではない)
vt = 値タイプ (関連フィールドの精度を含む)
ct
gc
サマリーインデックスのギャップの管理
サマリーインデックスに収集されたデータに、ギャップが存在していると、サマリーインデックスサーチの精度が
低下する可能性があります。
サマリーインデックスデータ内のギャップはさまざまな理由で発⽣します。
当初サマリーインデックスには、データの収集を開始した時点からのデータのみが含まれている： 独
⾃にバックフィルスクリプトを使ってサマリーインデックスに追加しない限り、サマリーインデックスには
データの収集開始⽇以前のデータは存在しないことを忘れないでください。
splunkd 機能停⽌： splunkd が⻑時間停⽌すると、サマリーインデックスにデータを追加するサーチの実⾏ス
ケジュールによっては、データにギャップが⽣じる可能性があります。
サーチの実⾏時間がスケジュール間隔よりも⻑かった： データ追加サーチの実⾏時間が次回の実⾏予定
時間を超過した場合、前のサーチの動作中は予定されている次のサーチは実⾏されないため、データの
ギャップが発⽣してしまいます。たとえば、5 分間隔でデータ追加サーチを実⾏するようにスケジュールし
ている場合に、あるサーチの実⾏が 5 分以上かかってしまうと、データコレクションにギャップが発⽣しま
す。
オーバーラップは、同じタイムスタンプを共有している (同じデータ追加サーチからの) サマリーインデックス内
のイベントです。イベントのオーバーラップにより、サマリーインデックスから作成されるレポートや統計が歪曲
されてしまいます。保存済みサーチの時間範囲を、サーチのスケジュール間隔よりも⻑く設定した場合に、オー
バーラップが発⽣する可能性があります。そのため、たとえば 1 時間ごとに実⾏するサーチで、過去 90 分の
データを収集するようなことは避けるようにしてください。
注意： サマリーインデックスの作成と管理に関する⼀般情報については、『ナレッジ管理マニュアル』の「サマ
リーインデックスを使ったレポート効率の向上」を参照してください。
バックフィルスクリプトを使った他のデータの追加/ギャップの埋め戻し
fill_summary_index.pyスクリプトは、サマリーインデックスのギャップをバックフィルするスクリプトで、サマ
リーインデックスにデータを追加する保存済みサーチを、その予定時刻に対象時間範囲に対して実⾏されたかのよ
うに実⾏することで、ギャップを埋め戻します。つまり、新しいサマリーインデックスが今週初めからデータの収
集を開始した場合でも、必要に応じて fill_summary_index.py を使って、サマリーインデックスにたとえば過去 1 ヶ
⽉のデータを追加することができます。
また、fill_summary_index.py の実⾏時に、App とその App に関連付けたサマリーインデックスサーチのリストに
対するバックフィルアクションをスケジュールしたり、単純に App に関連するすべての保存済みサーチをバック
フィルしたりできます。
CLI から fill_summary_index.py コマンドを⼊⼒する場合、バックフィル操作の「もっとも早い時刻」と「もっとも
遅い時刻」を指定して、バックフィルの時間範囲を設定する必要があります。相対時間識別⼦ (例：「3 ⽇前の午
前 0 時」なら -3d@d) や UTC エポック数値を使って、正確な時間を指定することができます。スクリプトは、サ
マリーインデックスを実⾏するはずだった時点の、対象時間範囲を⾃動的に算出します。
注意： fill_summary_index.py スクリプトが⽋損データに対応する時点のデータ追加サーチのみを実⾏するように、
実⾏時には -dedup true を指定する必要があります。
スクリプトには、必要な認証情報 (ユーザー名とパスワード) を指定する必要があります。ス
クリプト実⾏時に有効な Splunk Enterprise キーが分かっている場合は、-sk オプションを利⽤して情報を指定す
ることができます。
fill_summary_index.py
このスクリプトは、コマンドラインに指定されていない任意の必要な情報 (サマリーインデックスサーチ名、認証
情報、時間範囲など) の⼊⼒を要求するように設計されています。
fill_summary_index.py の実⾏例
以下のような状況の場合：
splunkdotcom App のすべてのサマリーインデックスサーチをバックフィルする必要があります。ただし、すで
にサマリーインデックス内にデータが存在しているサーチはスキップする必要があります。
このような場合は、以下のコマンドを CLI に⼊⼒します：
./splunk cmd python fill_summary_index.py -app splunkdotcom -name "*" -et -mon@mon -lt @mon -dedup true -auth
admin:changeme
152
以下のような状況の場合：
過去 1 年の my_daily_search サマリーインデックスサーチをバックフィルする必要がありますが、任意の時点の同
時実⾏サーチ数を 8 件以下にする必要があります (バックフィルデータの収集が Splunk Enterprise のパフォー
マンスに与える影響を減らすため)。すでにサマリーインデックス内にデータが存在しているサーチでも、スキッ
プせずに実⾏します。my_daily_search サマリーインデックスサーチは、「admin」ロールが所有しています。
このような場合は、以下のコマンドを CLI に⼊⼒します：
./splunk cmd python fill_summary_index.py -app search -name my_daily_search -et -y -lt now -j 8 -owner admin -auth
admin:changeme
注意： 特定のユーザーまたはロールが所有しているサーチの場合は、-owner オプションを指定する必要がありま
す。
fill_summary_index.py が実⾏中に中断された場合
fill_summary_index.py を起動する App (デフォルトはサーチ (search)) 内に、ログ (log) ディレクトリがありま
す。このディレクトリには、空の⼀時ファイル「fsidx*lock」があります。
「fsidx*lock」ファイルを削除すれば、fill_summary_index.py を再起動できます。
fill_summary_index.py の使⽤例とコマンド
CLI から、開始するために以下のように⼊⼒します。
python fill_summary_index.py
次に、以下の表を参考に必要なオプションとフィールドを追加してください。
注意： <boolean>オプションは、値 1、t、true、または
(False)」として受け付けます。
yes
を「真 (True)」として、0、f、false、または
フィールド
no
を「偽
値
-et <string>
もっとも早い時間 (必須)。UTC または相対時刻識別⼦。
-lt <string>
もっとも遅い時間 (必須)。UTC または相対時刻識別⼦。
-app <string>
使⽤する App コンテキスト (デフォルトは
-name <string>
単⼀の保存済みサーチ名を指定します。複数回指定して、複数の名前を設定することもできま
す。サマリーインデックスアクションを持つすべての保存済みサーチすべてを有効にする場合
は、ワイルドカード (*) を使⽤します。
-names <string>
保存済みサーチ名のカンマ区切りリストを指定します。
-namefile
<filename>
保存済みサーチを 1 ⾏に 1 つずつ記載したファイルを指定します。# から始まる⾏は注釈とみ
なされて、無視されます。
-owner <string>
使⽤するユーザーコンテキスト (デフォルトは「None」)。
-index <string>
保存済みサーチがデータを追加するサマリーインデックス。インデックスを指定しない場合、
バックフィルスクリプトが⾃動的に判断を試みます。判断できなかった場合は、デフォルトの
「summary」が使⽤されます。
-auth <string>
認証⽂字列は、<username> または <username>:<password> で指定します。ユーザー名のみを指定し
た場合、パスワードを要求するプロンプトが表⽰されます。
-sleep <float>
各サーチ間に待機する秒数。デフォルトは、5 秒です。
-j <int>
最⼤同時実⾏可能サーチ数 (デフォルトは 1)。
-dedup
None)。
このオプションに真 (True) を設定すると、すでにサマリー・インデックス内に当該期間のデー
タが存在している場合、その期間に対応する保存済みサーチは実⾏されません。このオプショ
ンには、デフォルトで「false」が設定されています。
<boolean>
注意： このオプションは、サーチ⾔語の dedup コマンドとは関係ありません。スクリプトに、
イベント・レベルのデータ分析を⾏う機能はありません。特定のイベントが他のイベントと重
複しているかどうかを判断することはできません。
-nolocal
分散環境で作業を⾏っている場合に、サマリーインデックスがサーチヘッド上ではなく、イン
デックス上に存在することを⽰します。-dedup とともに使⽤されます。
<boolean>
-showprogress
<boolean>
このオプションに真 (True) を設定すると、実⾏中の各サーチの進捗状況が定期的に表⽰されま
す。このオプションを省略した場合、デフォルトの偽 (False) が仮定されます。
⾼度なオプション：⼤部分の場合、これらは使⽤しないでください。
-trigger
<boolean>
-dedupsearch
このオプションに偽 (False) を設定すると、各サーチは実⾏されますが、サマリーインデック
ス処理は⾏われません。このオプションを省略した場合、デフォルトの真 (True) が仮定されま
す。
特定のスケジュール時刻の特定の保存済みサーチに対応するデータが存在する場合の、判断に
153
<string>
distdedupsearch
<string>
-namefield
<string>
-timefield
<string>
使⽤するサーチを指定します。
と同じですが、これは分散サーチ⽂字列です。対象はサーチヘッドに限定されませ
ん。インデクサー上のサマリーデータも探します。
-dedupsearch
データを⽣成した保存済みサーチの名前を含む、サマリーインデックスデータ内のフィールド
を⽰します。
データを⽣成した保存済みサーチのスケジュール時刻を含む、サマリーインデックスデータ内
のフィールドを⽰します。
サマリーインデックスの設定
サマリーインデックスの概要および Splunk Web を使ったサマリーインデックスの設定⽅法については、『ナ
レッジ管理マニュアル』の「サマリーインデックスを使ったレポート効率の向上」を参照してください。
保存済みレポートが定期的に実⾏されるスケジュール済みレポートとして設定され、毎回の実⾏が実施され、[サ
マリーインデックスを有効にする] アラートオプションを選択するまでは、savedsearches.conf で保存済みレポー
トのサマリーインデックスを⼿動設定することはできません。
また、レポートがデータを追加するサマリーインデックスの名前を⼊⼒する必要があります。この作業は、[サマ
リーインデックスを有効にする] を選択した後に、[設定] > [サーチとレポート] にあるレポートの詳細ページ
で⾏います。デフォルトのサマリーインデックスは、「summary」です (何も指定しない場合に Splunk
Enterprise が使⽤するサマリーインデックス)。
さまざまなサマリーインデックスレポートを実⾏する予定の場合は、必要に応じて他のサマリーインデックスを作
成します。新たなインデックスの作成の詳細は、『インデクサーとクラスタの管理マニュアル』の「複数のイン
デックスの設定」を参照してください。サマリーデータ収集専⽤のインデックスを作成することもお勧めできま
す。
注意： 存在しないインデックス名を⼊⼒した場合、Splunk Enterprise は設定したスケジュールに従ってレポー
トを実⾏しますが、データはサマリーインデックスには保存されません。
レポートの作成と管理については、このマニュアルの「レポートの作成と編集」を参照してください。
サマリーインデックスを⽣成できるレポートの定義についての詳細は、サマリーインデックスレポートの設定に関
するサブトピックおよびこのマニュアルの「サマリーインデックスを使ったレポート効率の向上」を参照してくだ
さい。
注意： サマリーインデックスの構築に使⽤するレポートを定義する場合、⼤半の場合はレポートのサーチ⽂字列
でサマリーインデックス⽤変換コマンドを使⽤する必要があります。これらのコマンドの前には「si-」が付けら
れます (sichart、sitimechart、sistats、sitop、および sirare)。これらのコマンドを使って作成するレポートは、
将来的に完成したサマリーインデックスに対するレポートとほぼ同じになります (使⽤するコマンドが違う)。
このサマリーインデックス⽤変換コマンドは、「サマリーインデックスレポート定義の検討事項」に説明されてい
る問題 (例：データ追加レポートに短い時間範囲を設定、多数の標本を取得するような設定など) を⾃動的に考慮
します。これらの問題は、サマリーインデックスの作成に使⽤するレポートに、サマリーインデックス⽤変換コマ
ンドを使⽤しない場合にのみ考慮する必要があります。
サマリーインデックス⽤変換コマンドを使⽤しない場合は、addinfo および collect コマンドを使ってレポートを作
成し、それを使ってあらかじめ作成したサマリーインデックスにデータを追加します。詳細は、このトピックの
「サマリーインデックスへのデータの⼿動追加」を参照してください。
スケジュール済みレポートのサマリーインデックスのカスタマイズ
Splunk Web を使って、データ追加⽤のスケジュール済みサマリーインデックス対応レポートのサマリーイン
デックスを有効にすると、$SPLUNK_HOME/etc/system/local/savedsearches.conf 内に⾃動的にスタンザが⽣成されま
す。このスタンザを編集して、レポートのサマリーインデックスをカスタマイズすることができます。
Splunk Web を使ってレポートの保存とスケジュールをしたけれども、Splunk Web を使ってレポートのサマ
リーインデックスを有効にしていない場合、savedsearches.conf を編集して、そのレポートのサマリーインデック
スを有効にすることができます (データを追加するサマリーインデックスが存在している場合)。インデックスの⼿
動設定の詳細は、『インデクサーとクラスタの管理マニュアル』の「インデックスの管理について」を参照してく
ださい。
[ <name> ]
action.summary_index = 0 | 1
action.summary_index._name = <index>
action.summary_index.<field> = <value>
[<name>]：スタンザ名は、サマリーインデックスを有効にしたスケジュール済みレポート名に基づいて指定さ
れます。
action.summary_index = 0 | 1：1
を設定すると、サマリーインデックスが有効になります。サマリーインデッ
クスを無効にする場合は、0 を設定します。
action.summary_index._name = <index> レポートがデータを追加する、サマリーインデックス名を⽰します。こ
のレポートに対して特定のサマリーインデックスを作成した場合は、その名前を <index> に⼊⼒します。デ
フォルトは summary です (Splunk Enterprise で配信されるサマリーインデックス)。
action.summary_index.<field> = <value>：このレポートでサマリーインデックスに追加する各イベントの、
154
フィールド/値のペアを指定します。1 つのサマリーインデックスレポートに対して、複数のフィールド/値
のペアを定義できます。
このフィールド/値のペアは⼀種の「タグ」として機能し、レポート実⾏時に追加される⼤量のイベントデータか
ら、特定のイベントを識別するために役⽴ちます。このキーは省略できますが、最低 1 つのフィールド/値のペア
を指定することをお勧めします。
たとえば、サマリーインデックス (action.summary_index.report = summary_firewall_top_src_ip) にデータを追加する
レポート名、またはレポートがデータを追加するインデックス名 (action.summary_index.index = search) を追加しま
す。
サマリーインデックスに役⽴つサーチコマンド
サマリーインデックスは、⼀連の特別な変換コマンドを活⽤しています。Splunk Web またはサマリーインデッ
クス⽤変換コマンドを使⽤せずに、サマリーインデックスを⼿動で作成する場合は、これらの特別なコマンドを使
⽤する必要があります。
addinfo：addinfo
を使って、現在のレポートに関する全般情報を含むフィールドを、サマリーインデックスに
⼊れるレポート結果に追加します。任意のレポートに | addinfo を追加して、サマリーインデックスに追加
された結果がどのようになるかを確認してください。
collect：collect を使って、レポート結果をサマリーインデックスに追加します。他のインデックスにレポー
ト結果を追加する場合は、| collect を使⽤します (collect コマンドのコマンドラインオプションを使⽤)。
overlap：サマリーインデックス内のギャップやオーバーラップを識別するには、overlap を使⽤しま
す。overlapを使って、サマリーインデックス内のギャップやオーバーラップを判別します。 は、サマリーイ
ンデックス内でタイムスタンプ値がオーバーラップしている、同じ query_id を持つイベントを検出、または
イベントが⽋損している期間を識別します。
サマリーインデックスにデータを追加するレポートの⼿動設定
Splunk Web のレポートオプションダイアログまたはサマリーインデックス⽤変換コマンドを使⽤せずに、サマ
リーインデックスを設定する場合は、まず他のインデックスを設定する場合と同様に、indexes.conf を使ってサマ
リーインデックスを設定する必要があります。インデックスの⼿動設定の詳細は、『インデクサーとクラスタの管
理マニュアル』の「インデックスの管理について」を参照してください。
重要： indexes.conf の変更内容を有効にするには、Splunk Enterprise を再起動する必要があります。
1. Splunk Web で、結果を要約するサーチ⽂字列を設計します。
レポートには、適切な時間範囲を指定してください。レポートが⽣成する結果数は、レポートに設定した最
⼤レポート結果数の制限内でなければなりません。
10 分、2 時間、1 ⽇などの、データに対して適切な時間間隔を選択してください。(Splunk Web を使った
レポートの実⾏間隔のスケジュールについては、『レポートマニュアル』の「スケジュール済みレポート」
を参照してください。)
2. addinfo サーチコマンドを使⽤します。レポートのサーチ⽂字列の最後に
| addinfo
を追加します。
このコマンドは、collect コマンドがサマリーインデックスにイベントを追加するために必要な、レポートに
関する情報をイベントに追加します。
| addinfo を任意のサーチ⽂字列に追加して、サマリーインデックス内で結果がどのようになるのかを、プレ
ビューすることができます。
3. レポートのサーチ⽂字列に、collect サーチコマンドを追加します。サーチ⽂字列の最後に
index=<index_name> addtime=t marker="report_name=\"<summary_report_name>\"" を追加します。
|collect
を、サマリーインデックス名に置換してください。
は、インデックス内のこのレポートの結果を検索するためのキーに置換してください。
⽣成されたイベントに対して、overlap サーチコマンドを使⽤する場合は、summary_report_name を設定する必
要があります。
index_name
summary_report_name
注意： ⼀般的には、⽤意されている summary_index アラートアクションを使⽤することをお勧めします。addinfo と
collect を使った設定には、スケジュール済みレポートからサマリーインデックスイベントを⽣成する場合には不
要な、いくつかの追加作業を⾏う必要があります。すでに経過した時間範囲に対してサマリーインデックスをバッ
クフィルするためには、⼿動設定が必要です。
サマリーインデックスレポート定義の検討事項
何らかの理由で、サマリーインデックス⽤変換コマンドを使⽤せずに、サマリーインデックスにデータを追加する
レポートを設定する場合は、いくつかの事項を検討しておく必要があります。サマリーインデックスの場合、鶏よ
りも卵が先に登場します。サマリーインデックスの⽣成に使⽤するレポートの定義に役⽴てるために、実際に実⾏
するレポートを使⽤して、結果を確認してください。
多くのサマリーサーチレポートに総統計情報が含まれています (例：メインインデックスが 1 ⽇当たり数百万件の
イベントを⽣成する環境での、昨⽇のファイアウォール攻撃に関連する上位 10 件の IP アドレスのサーチ)。
将来的にサマリーインデックスに対して実⾏するレポートと、同じレポートから得られる結果をそのサマリーイン
デックスに追加すると、統計的に不正確な結果になる可能性があります。サマリーインデックスレポートから⽣成
される総統計の精度を向上するために、サマリーインデックスにデータを追加するレポートを定義する場合には、
以下のルールに従ってください。
データ追加レポートに短い時間範囲を指定
155
サマリーインデックスにデータを追加するレポートは、将来的にそれに対して実⾏するレポートよりも、短い間隔
(より頻繁に) 実⾏する必要があります。できる限り⼩さな時間範囲を使⽤してください。たとえば、毎⽇の「トッ
プ」レポートを⽣成する必要がある場合、サマリーインデックスにデータを追加するサーチでは、標本を 1 時間
ごとに取得します。
データ追加レポートが多くの標本を取得するように設定
サマリーインデックスにデータを追加するレポートは、将来的にサマリーインデックスに対して実⾏するレポート
よりも、より多数の標本を取得する必要があります。たとえば、将来的にサマリーインデックスに対して「毎
⽇上位 10 件」の攻撃が多い IP アドレスをサーチする予定の場合、サマリーインデックスにデータを追加
するレポートでは、「時間ごとの上位 100 件」の攻撃が多い IP アドレスをサーチしてサマリーインデッ
クスに追加します。
このようなアプローチには 2 つの利点があります。まず、上位 10 件レポートの⾼い統計的精度が保証されます
(総合的な標本数が多く、頻繁に取得されているため)。また、レポートの報告数を 20 件や 30 件に変更したいよ
うな場合でも、ある程度はそれに対処できる柔軟性が確保されます。
サマリーインデックス⽤変換コマンドでは、完成したサマリーインデックスに対して実⾏するレポートよりも多く
の標本を⾃動的に抽出するため、作成するサマリーインデックスのイベントデータが不正に歪曲されることはあり
ません。これらのコマンドを使⽤しない場合、head コマンドを使って、将来的にサマリーインデックスに対して
実⾏するレポートよりも多数の標本を抽出するように、サマリーインデックスデータ追加レポートを設定すること
ができます。時間ごとのサマリーインデックスデータ追加レポートには | head=100 を使⽤し、完成したサマリーイ
ンデックスに対する⽇次レポートには | head=10 を使⽤します。
加重平均を取得するためのレポート設定
サマリーインデックスデータ追加レポートに平均が関与しており、サマリーインデックス⽤変換コマンドを使⽤し
ていない場合は、レポートが加重平均を取得するように設定する必要があります。
たとえば、時間ごと、⽇ごと、または週ごとの平均応答時間に関するレポートを作成する必要がある場合を考えて
みましょう。あなたはそのために、「時間ごとの平均」を平均化して「⽇ごとの平均」を⽣成しました。残念なが
ら、それぞれの「時間ごとの平均」のイベント数が同じではないと、⽇ごとの平均は歪曲された値になってしまい
ます。正しい「⽇ごとの平均」を取得するには、加重平均関数を使⽤します。
以下の式は、stats コマンドと eval コマンド、および sum 統計集計⼦を併⽤して、加重平均から⽇ごとの平均応答
時間を正確に算出します。この例では、eval コマンドが daily_average フィールドを作成します。このフィールド
には、平均応答時間の合計を平均応答時間数で除算した値が格納されます。
| stats sum(hourly_resp_time_sum) as resp_time_sum, sum(hourly_resp_time_count) as resp_time_count | eval
daily_average= resp_time_sum/resp_time_count | .....
データのギャップとオーバーラップを回避するサマリーインデックス追加レポートのスケジュール
上記の 2 つのルールの他にも、データのギャップやオーバーラップを最低限に抑えるために、サマリーインデッ
クスの⽣成とデータ追加に使⽤するレポートのスケジュールには、適切な間隔と遅延を設定する必要があります。
サマリーインデックス内のギャップ は、サマリーインデックスがイベントのインデックスを作成できなかった期
間です。以下のような場合にギャップが発⽣します。
が停⽌している。
サマリーインデックスにデータを追加する保存済みスケジュールレポートの実⾏に時間がかかりすぎて、次
回に予定されている実⾏時刻を過ぎてしまった。たとえば、⼀般的にレポートの実⾏完了までに 7 分ほどか
かるレポートを、サマリーにデータを追加するレポートとして 5 分間隔で実⾏する場合、先に実⾏されてい
るレポートが完了するまで後続のレポートは実⾏されません。
splunkd
オーバーラップとは、同じタイムスタンプを共有している (同じレポートからの) イベントです。イベントのオー
バーラップにより、サマリーインデックスから作成されるレポートや統計が歪曲されてしまいます。保存済みレ
ポートの時間範囲を、レポートのスケジュール間隔よりも⻑く設定した場合、または collect コマンドを使って⼿
動でサマリーインデックスを作成した場合に、オーバーラップが発⽣する可能性があります。
サマリーインデックス設定の例
この例は、Apache サーバー統計情報のサマリーインデックスの、savedsearches.conf への設定例を表していま
す。以下に記載されているキーで、「Apache Method Summary」レポートのサマリーインデックスが有効にな
ります。
注意： action_summary.index=1 を設定した場合、レポートのサーチ⽂字列内に
⽤する必要はありません。
#name of the report = Apache Method Summary
[Apache Method Summary]
# sets the report to run at each interval
counttype = always
# enable the report schedule
enableSched = 1
# report interval in cron notation (this means "every 5 minutes")
schedule = */5****
156
addinfo
または
collect
コマンドを使
# id of user for report
userid = jsmith
# search string for summary index
search = index=apache_raw startminutesago=30 endminutesago=25 | extract auto=false | stats count by method
# enable summary indexing
action.summary_index = 1
#name of summary index to which report results are added
action.summary_index._name = summary
# add these keys to each event
action.summary_index.report = "count by method"
サマリーインデックスの影響を受けるその他の設定ファイル
savedsearches.conf 内の設定の他にも、indexes.conf および alert_actions.conf にサマリーインデックス⽤の設
定が存在しています。
Indexes.conf には、サマリーインデックスのインデックス設定を指定します。Alert_actions.conf は、レポート
に関連するアラートアクション (サマリーインデックスを含む) を⽰しています。
警告： Splunk Enterprise スタッフからの明確な指⽰がない限り、alert_actions.conf 内の設定を変更しないでく
ださい。
バッチモードサーチの設定
バッチモードでの実⾏は、サーチが⼀度に 1 つのバケツ (バッチ内) を実⾏することを意味しています (時間順で
はない)。イベントを時間順に並べる必要がない特定のレポートサーチ では、これによりレポートサーチがより短
時間で完了します。またバッチモードサーチは、サーチ実⾏中にインデクサー が停⽌すると失敗する可能性があ
る、⻑時間実⾏される分散サーチ の信頼性も向上します。この場合、Splunk Enterprise は停⽌したピア に再接
続するか、またはサーチを残りのピアに再配布して、サーチの完了を試みます。
バッチモードサーチの要件
バッチモードサーチは、リアルタイム サーチとサマリー作成サーチでは機能しません。
バッチモードで実⾏できる、レポートサーチと変換サーチの種類には制限事項があります。
サーチは⽣成サーチでなければなりません。また、stats、chart などの変換コマンドを含めることができま
す。ただし、localize や transaction などのコマンドを含めることはできません。
⾮分散サーチの場合、イベントを時間の降順にする必要があるコマンドを使⽤することはできません。たと
えば、streamstats、head、tail などのコマンドは使⽤できません。
サーチが要件を満たす場合、バッチモードで⾃動実⾏する必要があります。デフォルトでこのモードは、
limits.conf の allow_batch_mode = true でオンになっています。詳細は、次のセクションを参照してください。
サーチジョブ調査を使って、サーチがバッチモードで動作しているかどうかを確認することができます。バッチ
モードサーチは、論理パラメータ isBatchModeSearch で⽰されています。詳細は、『ナレッジ管理』マニュアルの
「サーチジョブ調査によるサーチジョブプロパティの表⽰」を参照してください。
バッチモードサーチの設定
バッチモードサーチは、設定ファイル
limits.conf
の
[search]
スタンザで有効になっています。
[search]
allow_batch_mode = <bool>
batch_search_max_index_values = <int>
の場合、変換サーチがバッチモードで実⾏されることはありません。デフォルトは
真 (True) です。
allow_batch_mode = true の場合、batch_search_max_index_values を使ってインデックスファイル (バケツ)
から読み込むイベント数を制限します。これらのエントリは⼩さく、約 72 バイトとなっています。ただ
し、バッチモードでは⼀度に読み込めるエントリが多いほど、より効率的になります。デフォルトは
1000000 (または 10M) です。
allow_batch_mode = false
batch_search_max_index_values の値を、たとえば 1000000 (1M) に減らして、サーチ中のメモリー消費量を
少なくすることができます。ただし、この設定の値を⼩さくすると、サーチパフォーマンスが低下する可能性があ
ることに注意してください。バッチモードでのサーチ効率と同時実⾏サーチによるシステムのメモリー消費量の間
で、バランスを考慮する必要があります。
limits.conf 内の他の設定で、接続エラーなどの障害発⽣時の、サーチピアへの再試⾏間隔を指定することができ
ます。これは障害から最初の再試⾏まで、およびその後の失敗に対する再試⾏の間隔を表しています。
batch_retry_min_interval = <int>
batch_retry_max_interval = <int>
batch_retry_scaling = <double>
batch_wait_after_end = <int>
157
および batch_retry_max_interval パラメータを使って、障害が発⽣したピアに対して
サーチの再試⾏を試みるまでの最低または最⼤待機間隔 (秒) を指定できます。デフォルトの最低間隔は 5
秒です。デフォルトの最⼤間隔は 300 秒です。
再試⾏が失敗すると、倍率要素 batch_retry_scaling (1.0 より⼤きな値を取る) により、次の再試⾏を実施す
るまでの待機時間が増加します。デフォルトは 1.5 です。
バッチモードでは、通信障害が発⽣しなかったすべてのピアが、明⽰的に完全な結果を提供したことを報告
した場合に、サーチが終了したとみなされます。サーチが完了した後、Splunk Enterprise は
batch_wait_after_end に指定されている期間 (秒) だけ待機した後に、通信が失われたピアへの再試⾏を試みま
す。デフォルトは 900 秒です。
batch_retry_min_interval
失敗したサーチの再起動
サーチピアの再起動処理は、ピアがクラスタ構成かどうかによって異なります。
⾮クラスタ構成の場合、ピアが停⽌すると、Splunk Enterprise がピアへの再接続を試みます。接続が再確
⽴されると、サーチが再開され完了まで続⾏されます。
クラスタ構成の場合は、クラスタのマスターが新しい世代を⽣成するまで待機されます。
158

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

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

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

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

Splunk Enterprise

新しいアルツハイマー病研究用、｢APP770 測定キット」の販売開始について

CoLOS® Enterprise

暗号化通信プロトコル「SSLバージョン3.0」脆弱性への対応について

平成28年8月吉日 「個人インターネットバンキング」ご契約先様 鶴岡信用