Splunk Enterprise 6.2.0
データの取り込み
作成：2014 年 11 ⽉ 21 ⽇ 午後 4 時 11 分
Copyright (c) 2015 Splunk Inc. All Rights Reserved
Table of Contents
はじめに
Splunk Enterprise がインデックス処理できる項⽬
データの取り込みの開始
データの場所：ローカルか、またはリモートか？
フォワーダーを使ったデータの取り込み
App を使ったデータの取り込み
⼊⼒の設定
Splunk Enterprise によるデータの取り扱い (および活⽤⽅法)
5
5
6
7
8
9
9
10
Splunk Enterpri se へのデータの取り込み
データの追加⽅法は？
データのアップロード
データのモニター
データ転送
[ソースタイプの設定] ページ
データへの適切なソースタイプの割り当て
プレビューするデータの準備
イベント・データのソースタイプの表⽰と設定
イベント処理の変更
データプレビューと分散 Splunk Enterprise
⼊⼒設定の変更
12
12
13
14
14
15
17
17
18
19
22
23
ファイルやディレクトリからデータを収集
ファイルとディレクトリのモニター
Splunk Web の使⽤
CLI の使⽤
inputs.conf の編集
ワイルドカードを使った⼊⼒パスの指定
ホワイトリストまたはブラックリスト固有の到着データ
Splunk Enterprise によるログファイルのローテーションの取り扱
い
25
25
26
27
29
32
34
36
ネットワーク・イベントの取得
TCP および UDP ポートからのデータの取り込み
Splunk Enterprise への SNMP イベントの送信
37
37
41
Wi ndows データの取得
Windows データと Splunk Enterprise について
Splunk Enterprise への Windows データの取り込み
リモート Windows データのモニター⽅法決定の検討事項
Active Directory のモニター
Windows イベントログデータのモニター
Windows のファイルシステム変更のモニター
WMI ベースのデータのモニター
Windows レジストリデータのモニター
Windows パフォーマンスのモニター
Windows ホスト情報のモニター
Windows プリンタ情報のモニター
Windows ネットワーク情報のモニター
42
42
43
44
47
53
62
66
71
73
80
84
86
その他の取り込み⽅法
FIFO キューからのデータの取得
ファイルシステムへの変更のモニター
91
91
92
スクリプト⼊⼒を介した API や他のリモートデータインターフェイ 95
スからのデータの取得
crawl を使ったモニター項⽬の発⾒
98
イベント処理の設定
イベント処理の概要
⽂字セットのエンコードの設定
イベント改⾏の設定
イベントのタイムスタンプの設定
インデックス作成フィールド抽出の設定
データの匿名化
99
99
99
102
104
105
105
タイムスタンプの設定
タイムスタンプ割り当ての仕組み
タイムスタンプ認識の設定
複数のタイムスタンプを持つイベントのタイムスタンプ割り当て
の設定
タイムスタンプのタイムゾーンの指定
インデックス作成パフォーマンス向上のためのタイムスタンプ認
識の調整
107
107
108
113
114
115
インデックス作成フィールド抽出の設定
116
インデックス作成フィールドの抽出について
116
デフォルトフィールドについて (host、source、sourcetype など) 116
デフォルトフィールドの動的割り当て
118
インデックス時のカスタムフィールドの作成
118
ヘッダーのあるファイルからのデータの抽出
124
ホスト値の設定
ホストについて
Splunk Enterprise サーバーのデフォルトホストの設定
ファイル/ディレクトリ⼊⼒のデフォルトホストの設定
イベントデータに基づくホスト値の設定
誤って割り当てられたホスト値の取り扱い
128
128
129
130
132
134
ソースタイプの設定
ソースタイプが重要な理由
⾃動ソースタイプ割り当てに優先する設定
ルールベースのソースタイプ認識の設定
事前定義ソースタイプの⼀覧
イベント単位でのソースタイプに優先する設定
ソースタイプの作成
ソースタイプ名の変更
134
134
136
138
139
143
144
145
イベントのセグメント分割の管理
セグメント分割について
イベントデータのセグメント分割の設定
Splunk Web でのサーチ時セグメント分割の設定
145
145
146
148
データ取り込みプロセスの改善
テスト⽤インデックスを使って⼊⼒をテストする
データ損失を防⽌するための persistent queue の使⽤
⼊⼒プロセスのトラブルシューティング
148
148
149
150
レシピ
151
151
151
フォワーダー
ファイルとディレクトリ - ローカル
ファイルとディレクトリ - リモート
Syslog - TCP/UDP
Windows イベントログ - ローカル
Windows イベントログ - リモート
Windows レジストリ - ローカル
Windows パフォーマンスモニタリング - ローカル
Windows パフォーマンスモニタリング - リモート
Windows Active Directory
スクリプト
153
153
154
155
157
158
160
161
162
はじめに
Splunk Enterprise がインデックス処理できる項⽬
Splunk Enterprise を使⽤するための最初の作業が、データを取り込むことです。Splunk Enterprise にデータを
取り込むと、即座にインデックスが作成され、サーチが可能になります。Splunk Enterprise はインデックス作成
機能により、サーチ可能なフィールドから構成されるイベント にデータを変換します。Splunk がデータのイン
デックスを作成する前/後にさまざまな処理を⾏えます。ただし、⼀般的にはそのような作業は必要ありません。
基本的に、Splunk Enterprise にデータを指⽰すると、その後データのサーチを開始したり、それを使ってグラ
フ、レポート、アラート、および他の出⼒を⽣成したりすることができます。
データの種類
任意のデータを利⽤できます。特に、各種 IT ストリーミングデータ、マシンデータ、および履歴データを得意に
しています。Windows イベントログ、Web サーバーログ、ライブアプリケーションログ、ネットワークフィー
ド、システム測定基準、変更のモニター、メッセージキュー、アーカイブファイル、その他さまざまなデータを利
⽤できます。どのようなデータでも利⽤できます。嘘ではありません。
Splunk Enterprise にデータのソースを知らせてください。また、ソースに関するいくつかの情報も指定します。
そのソースが、データ⼊⼒ となります。Splunk Enterprise は取り込んだデータのインデックスを作成し、それ
を個別の⼀連のイベントに変換します。それらのイベントは即座に表⽰、サーチすることができます。望み通りの
結果が得られなかった場合は、⽬的の結果が得られるまでインデックス作成処理を調整することができます。
データは Splunk Enterprise インデクサー と同じマシン上にあっても (ローカルデータ )、他のマシン上にあっ
ても (リモートデータ ) 構いません。リモートデータは、ネットワークフィードを利⽤して、またはデータのソー
スとなるマシン上に Splunk Enterprise フォワーダー をインストールして、簡単に取得することができます。
フォワーダーは軽量版の Splunk で、収集したデータをメインとなる Splunk Enterprise インスタンスに転送し
ます。この Splunk Enterprise インスタンスは開け取ったデータのインデックス作成やサーチを⾏います。ロー
カルデータとリモートデータについては、「データの場所」を参照してください。
作業を簡単に⾏うために、Splunk はさまざまな無料の App やアドオン 、および Windows または Linux 固有の
データ、Cisco セキュリティデータ、Blue Coat データなどに対応する、事前設定されたデータ⼊⼒ (データの取
り込み⼿段) を提供しています。Splunk Apps からご⾃分のニーズに適した App やアドオンをお探しください。
Splunk には、Web サーバーログ、J2EE ログ、Windows パフォーマンス測定基準など、さまざまなデータソー
ス⽤のレシピが⽤意されています。これらのデータソースを利⽤するには、後述するように Splunk Web の
[データの追加] セクションを使⽤します。⽤意されているデータソースや App がニーズを満たしていない場合
は、Splunk Enterprise の汎⽤⼊⼒設定機能を使って、⽬的のデータソースを指定します。これらの汎⽤データ
ソースについては、ここを参照してください。
データ⼊⼒の指定⽅法
新しい種類のデータを Splunk Enterprise に取り込むには、それに対応する設定を⾏います。データの取り込み
を指定するには、さまざまな⽅法があります。
App： Splunk には、各種データソースを取り込むための事前設定が⾏われている、さまざまな App やア
ドオンが⽤意されています。Splunk の App を活⽤して、データ取り込みの設定の⼿間を省きましょう。詳
細は、「App の使⽤」を参照してください。
Splunk Web： ⼤部分のデータ⼊⼒は、Splunk Web のデータ⼊⼒ページから設定できます。この⽅法で
は、GUI を使って取り込むデータを設定できます。Splunk ホームまたは [システム] メニューから、[デー
タの追加] ページにアクセスすることができます。「Splunk Web の使⽤」を参照してください。
Splunk CLI： CLI (コマンドラインインターフェイス) を使って、さまざまな種類のデータ取り込みを設定
できます。「CLI の使⽤」を参照してください。
inputs.conf 設定ファイル： Splunk Web または CLI を使ってデータの取り込みを指定すると、設定内容
は設定ファイル inputs.conf に保存されます。必要に応じてこのファイルを直接編集することができます。
⾼度なデータ取り込みを⾏う場合は、このファイルを編集しなければならないこともあります。
「inputs.conf の編集」を参照してください。
また、フォワーダーを使って他のマシンのデータをインデクサーに送信する場合、フォワーダーのインストール時
にデータの取り込みを指定することができます。「フォワーダーの使⽤」を参照してください。
データ取り込みの設定の詳細は、「データ⼊⼒の設定」を参照してください。
データソースの種類
前述のように、Splunk は特定のアプリケーションニーズに固有のものを含めて、あらゆる種類のデータの取り込
みを設定するためのツールを提供しています。Splunk は、任意のデータ⼊⼒タイプを設定するためのツールも提
供しています。⼀般的に、Splunk のデータ⼊⼒は以下のように分類できます。
ファイルとディレクトリ
ネットワークイベント
Windows ソース
その他のソース
ファイルとディレクトリ
多くの有益なデータが、ファイルやディレクトリに存在している可能性があります。多くの場合、Splunk
5
多くの有益なデータが、ファイルやディレクトリに存在している可能性があります。多くの場合、Splunk
Enterprise のファイル/ディレクトリのモニター ⼊⼒プロセッサを使って、ファイルやディレクトリからのデー
タを取得することができます。
ファイルとディレクトリのモニターについては、「ファイルとディレクトリのデータの取得」を参照してくださ
い。
ネットワークイベント
Splunk Enterprise は、任意のネットワークポートからのデータのインデックスを作成することができます。たと
えば、syslog-ng や他の TCP 経由でデータを伝送するアプリケーションからの、リモートデータのインデックスを
作成することができます。UDP データのインデックスも作成できますが、信頼性の観点から可能な場合は TCP
を使⽤することをお勧めします。
SNMP イベント、リモートデバイスが⽣成したアラートを受信してインデックスを作成することもできます。
ネットワークポートからデータを取得するには、「TCP および UDP ポートからのデータの取得」を参照してく
ださい。
SNMP データの取得については、「Splunk への SNMP イベントの送信」を参照してください。
Windows ソース
Windows 版の Splunk Enterprise には、さまざまな Windows 固有の⼊⼒が⽤意されています。また、以下のよ
うな Windows 固有の⼊⼒タイプを定義することもできます。
Windows イベントログデータ
Windows レジストリデータ
WMI データ
Active Directory データ
パフォーマンスモニターデータ
重要： Windows 版以外の Splunk Enterprise インスタンス上で、Windows データのインデックス作成とサーチ
を⾏う場合は、まず Windows 版のインスタンスを使ってデータを収集する必要があります。詳細は、「リモート
Windows データのモニター⽅法決定の検討事項」を参照してください。
Splunk Enterprise での Windows データの使⽤⽅法の詳細は、「Windows データと Splunk Enterprise につい
て」を参照してください。
その他のソース
Splunk Enterprise は、他の種類のデータソースもサポートしています。例：
先⼊れ先出し (FIFO) キュー
スクリプト⼊⼒
API および他のリモートデータインターフェイスやメッセージキューからデータを取り込みます。
モジュール⼊⼒
Splunk Enterprise フレームワークを拡張する、カスタム⼊⼒機能を定義します。
次の参照先
ここでは、Splunk データの指定時に検討する必要がある問題について説明していきます。
「データの場所」。リモートデータとローカルデータの⽐較、およびそれが影響する事項について説明して
います。
「フォワーダーの使⽤」。フォワーダーを使ったリモートデータ収集の簡素化について説明しています。
「App の使⽤」。Splunk App を使った、Splunk Enterprise へのデータの取り込みについて説明していま
す。
「データの取り込み⽅法」。データソースの取得と設定の概要、およびベストプラクティスについて説明し
ています。
「⼊⼒の設定」。Splunk Enterprise でのデータ⼊⼒の設定⽅法について説明しています。
「Windows データと Splunk Enterprise について」。Windows データを Splunk Enterprise に取り込む
⽅法の概要を説明しています。
「Splunk Enterprise によるデータの取り扱い (および活⽤⽅法)」。Splunk Enterprise に取り込んだデー
タがどのように処理されるのか、そしてデータを活⽤するための Splunk の設定について説明しています。
データの取り込みの開始
Splunk Enterprise へのデータの取り込みを開始するには、[データの追加] ページで、データの取り込みを設
定します。「データの追加⽅法は？」を参照してください。
または、お使いの OS ⽤ App (Splunk App for Windows Infrastructure や Splunk App for Unix and Linux) な
どの、App をダウンロードして、有効にすることもできます。
Splunk Enterprise をインストールして、データの取り込みの設定、または App の有効化を⾏ったら、指定され
たデータの保管と処理が即座に開始されます。その後、サーチ App (Splunk Web の開始ページである Splunk
ホームからアクセス可能) またはメイン App ページに移動して、収集したデータの詳細な調査を開始することが
できます。
新しいデータ取り込みの追加
6
ここでは推奨する⼿順について説明していきます。
1. ⾃分のニーズを把握します。たとえば、以下のような事項を検討します。
Splunk Enterprise でインデックスを作成するデータは？「Splunk がインデックス処理できる項⽬」を参
照してください。
そのデータ⽤の App があるか？「App を使ったデータの取り込み」を参照してください。
データはどこに存在しているか？ローカルか、またはリモートか？「データの場所」を参照してください。
リモートデータへのアクセスにフォワーダーを使⽤するか？「フォワーダーを使ったデータの取り込み」を
参照してください。
インデックス作成したデータで何をするのか？『ナレッジ管理』マニュアルの「Splunk ナレッジとは？」
を参照してください。
2. テスト⽤インデックスを作成し、いくつかのデータ取り込み (⼊⼒) を追加します。「テスト⽤インデックスの
使⽤」を参照してください。テスト⽤データの量は最低限に抑えてください。テスト⽤インデックスに追加された
データは、ライセンスの⽇次インデックス作成量の加算対象となります。
3. データをテスト⽤インデックスに送る前にプレビューを⾏い、必要に応じてデータのインデックス作成⽅法を修
正してください。Splunk Enterprise では、モニターまたはアップロードにより、ファイルから取り込んだデータ
をプレビューすることができます。詳細は「[ソースタイプの設定] ページ」を参照してください。
4. テスト⽤データに対して、いくつかのサーチを実⾏します。
意図通りのデータが表⽰されましたか？
デフォルト設定でイベントが正常に処理されましたか？
データが⾒つからなかったり、おかしくなっていたりしませんか？
最適な結果が表⽰されましたか？
5. 必要に応じて、意図通りのイベントが収集、表⽰されるように、データの取り込みやイベント処理の設定を調整
します。イベント処理の設定⽅法については、このマニュアルの「Splunk Enterprise によるデータの取り扱い」
を参照してください。
6. テスト⽤インデックスからデータを削除して、必要に応じて実際の利⽤を開始します。⽅法については、「イン
デックス・データの削除とやり直し」を参照してください。
7. 実際の利⽤準備が完了したら、デフォルトの「main」インデックスへのデータの取り込みを設定します (ここを
参照)。
他にも追加する⼊⼒がある場合は、この作業を繰り返します。
独⾃のデータを取り込みますか？
Splunk Enterprise は任意の時系列データのインデックスを作成できるため、⼀般的には追加の設定作業を⾏う必
要はありません。独⾃のアプリケーションやデバイスからログを取得する場合、まずデフォルトの設定での処理を
お試しください。⽬的の結果が得られない場合は、イベントのインデックスが正しく作成されるように、いくつか
の設定を調整することができます。
続⾏する前に「イベント処理の概要」および「Splunk Enterprise によるデータのインデックス作成の仕組み」を
参照し、Splunk Enterprise に正しくデータの処理を⾏わせるための知識を確認してください。いくつかの検討し
ておく必要がある問題を以下に⽰します。
イベントは複数⾏イベントか？
データに特殊な⽂字セットが使われているか？
Splunk Enterprise がタイムスタンプを正しく判断できない？
データの場所：ローカルか、またはリモートか？
Splunk Enterprise にデータを初めて取り込む場合、「ローカル」データと「リモート」データの違いは何なの
か、多少混乱するかもしれません。新しいデータ⼊⼒を設定する場合、ローカルとリモートの違いが重要になりま
す。
この問題への回答は、以下のようにさまざまな基準に応じて異なります (ただし、これに限定されるものではあり
ません)。
Splunk Enterprise インスタンスが動作しているオペレーティングシステム
Splunk Enterprise インスタンスに直接接続されているデータストアの種類
インデックスを作成するデータを保管するデータストアにアクセスするために、認証や他の中間ステップを
介する必要があるかどうか
ローカル
ローカル リソースは、Splunk Enterprise サーバー (⾃分) が直接アクセスできる固定リソースです。また、それ
に保管されているデータの種類に関わらず、取り付け、接続、または他の中間操作 (認証やネットワークドライブ
へのマッピングなど) を⾏うことなく、システムからリソースを参照、利⽤することができます。そのようなリ
ソース上にデータが存在している場合、それは「ローカル」データとみなされます。
ローカルデータの例を以下に⽰します。
デスクトップやラップトップに取り付けられているハードディスクや SSD
システム起動時にロードされる RAM ディスク
リモート
7
リモート リソースは、前述の定義に該当しない任意のリソースです。Windows システムからマップされたネット
ワークドライブ、Active Directory スキーマ、NFS または *nix システム上の他のネットワークベースのマウント
などが、これに該当します。このようなリソースから収集されたデータも「リモート」とみなされます。
例外
⼀般的にリモートとみなされるけれども、実際には違うリソースも存在しています。以下にいくつかの例を⽰しま
す。
USB や FireWire などの⾼帯域幅物理接続経由で、常時マウントされているボリュームを持つマシン。コン
ピュータはブート時にリソースをマウントできるため、理論的には後ほどリソースを切り離せる場合でも、
このようなリソースはローカルリソースとして取り扱われます。
iSCSI などの⾼帯域幅ネットワーク標準規格、または SAN への光接続を介して永久的にマウントされるリ
ソースを持つマシン。ローカルのブロックデバイスと同程度のデータ量を処理できる標準規格であるため、
このようなリソースはローカルとみなされます。
フォワーダーを使ったデータの取り込み
フォワーダー は軽量版の Splunk インスタンスで、収集したデータを処理するために Splunk Enterprise インデ
クサー に転送することを⽬的にしています。最低限のリソースしか必要とせず、パフォーマンス上の影響も少な
いため、⼀般的にはデータ⽣成元のマシン上に配置されます。
たとえば、集中的にサーチを実⾏したいデータを⽣成している複数台の Apache サーバーがある場合、Splunk
Enterprise インデクサーをインストールした後、次に各 Apache マシンにフォワーダーを設定することができま
す。各フォワーダーは Apache データを収集して、それをインデクサーに送信します。インデクサーは受け取っ
たデータを統合して保管し、サーチが可能な状態にします。消費リソースが少ないため、フォワーダーが Apache
サーバーのパフォーマンスに与える影響を最低限に抑えられます。
同様に、従業員の Windows デスクトップにフォワーダーをインストールすることもできます。これらのフォワー
ダーはログや他のデータを集中管理⽤ Splunk Enterprise インスタンスに送信します。そのデータを利⽤して、
マルウェアがないかどうか、または他の問題が発⽣していないかどうかを追跡することができます。
フォワーダーが⾏う作業
フォワーダーを使って、リモートマシンからデータを取得することができます。フォワーダーは以下のような機能
により、ネットワークから raw データを供給するよりも、⼤幅に堅牢なソリューションを実現しています。
メタデータのタグ設定 (ソース、ソースタイプ、ホスト)
設定可能なバッファ
データ圧縮
SSL セキュリティ
利⽤可能な任意のネットワークポートの使⽤
ローカルにスクリプト⼊⼒の実⾏
フォワーダーは他の Splunk Enterprise インスタンスと同じ⽅法でデータを収集します。インデクサーと完全に
同じタイプのデータを処理できます。違いは、⼀般的にフォワーダー⾃体がインデックスを作成することはないこ
とです。単純にデータを取得して、それをインデクサーに送信します。インデクサーがインデックスの作成とサー
チを担当します。単⼀のインデクサーで、複数のフォワーダーから転送されるデータを処理することができます。
フォワーダーの詳細は、『データの転送』マニュアルを参照してください。
⼤半の Splunk Enterprise デプロイ環境では、フォワーダーは主なデータ収集役を果たしています。インデク
サーは単⼀マシンのデプロイ環境でのみ、主なデータ収集役にもなります。⼤規模な Splunk Enterprise デプロ
イ環境では、数百台または数千台ものフォワーダーがデータを収集して、それを⼀連のインデクサーグループに転
送することもあります。
フォワーダー⼊⼒の設定⽅法
Splunk Enterprise の軽量版インスタンスであるフォワーダーは、設計上機能が限定されています。たとえば、⼤
半のフォワーダーには Splunk Web が含まれていません。そのため、直接 UI にアクセスしてフォワーダーの
データ取り込みを設定することはできません。ここでは、フォワーダーのデータ取り込みを設定する主な⽅法につ
いて説明していきます。
初期デプロイ時にデータの取り込み (⼊⼒) を指定する。Windows フォワーダーの場合、インストール時に
⼀般的なデータ取り込みを指定することができます。*nix フォワーダーの場合、インストール後にデータの
取り込みを指定できます。
CLI を使⽤する。
inputs.conf を編集する。
⽬的のデータ取り込み機能がある App をデプロイする。
テスト⽤の完全版 Splunk Enterprise インスタンスで Splunk Web を使ってデータの取り込みを設定し、
その結果⽣成された inputs.conf ファイルをフォワーダーに配布する。
その他の参考情報
使⽤事例、⼀般的なトポロジー、および設定も含めたフォワーダーの詳細は、『データの転送』マニュアルの「転
送と受信について」を参照してください。
デプロイサーバー を使った設定ファイルや App の複数フォワーダーへの配布⽅法を含めた、フォワーダーデプ
ロイの詳細は、『データの転送』マニュアルの「ユニバーサルフォワーダーのデプロイの概要」を参照してくださ
い。
リモート Windows データをモニターするためのフォワーダーの使⽤⽅法については、「リモート Windows デー
タのモニター⽅法を決定するための検討事項」を参照してください。
8
App を使ったデータの取り込み
Splunk には、Splunk Enterprise の機能を拡張、強化するためのさまざまな App やアドオン が提供されていま
す。App により、Splunk Enterprise へのデータの取り込みプロセスが簡単になります。特定の環境やアプリ
ケーション向けのデータ取り込みを⾃分で設定する代わりに、データの取り込みがすでに設定されている App を
探して使⽤することもできます。Splunk Apps からApp をダウンロードします。
⼀般的に App は特定のデータタイプを対象にしており、デート取り込みの設定から有益なデータビューの⽣成ま
でさまざまな機能が⽤意されています。たとえば、Splunk App for Windows Infrastructure は、Windows サー
バーおよびデスクトップの管理⽤に、データの取り込み、サーチ、レポート、アラート、およびダッシュボード機
能を提供しています。Splunk App for Unix and Linux は、UNIX/Linux環境向けに同様の機能を提供していま
す。特定のタイプのアプリケーション・データを処理する幅広い App が存在しています。以下に例を⽰します。
Splunk
Splunk
Splunk
Splunk
App
App
App
App
for Blue Coat ProxySG
for F5
for Cisco Security
for Websphere Application Server
Splunk Apps に直接移動して各種 App をダウンロードすることもできます。Splunk Apps には頻繁に新しい
App が追加されるため、定期的に確認してください。
重要： Splunk Web がプロキシサーバーの背後にある場合は、Splunk Enterprise 内からの Splunk Apps へのア
クセス時に問題が発⽣する可能性があります。この問題を解決するには、『管理マニュアル』の「プロキシ・サー
バーの指定」を参照してください。
⼀般的な App についての情報は、『管理マニュアル』の「App とアドオンとは」を参照してください。特に「そ
の他の App やアドオンの⼊⼿場所」には、App のダウンロードとインストール⽅法が記載されています。
独⾃の App の作成⽅法については、『Developing Views and Apps for Splunk Web』マニュアルを参照してく
ださい。
⼊⼒の設定
Splunk Enterprise に新しいタイプのデータを追加するには、データに関するいくつかの事項を設定します。その
ためには、データ⼊⼒ (取り込み⽅法) を設定します。データ⼊⼒を設定するために、さまざまな⽅法が⽤意され
ています。
App ：Splunk には、各種データを取り込むために、⼊⼒が事前設定されているさまざまな App が⽤意さ
れています。Splunk の App を活⽤して、データ取り込みの設定の⼿間を省きましょう。詳細は、「App
を使ったデータの取り込み」を参照してください。
Splunk Web ：⼤部分のデータ⼊⼒は、Splunk Web のデータ⼊⼒ページから設定できます。この⽅法で
は、GUI を使って取り込むデータを設定できます。Splunk ホームから、[データの追加] ページにアクセス
することができます。また、[システム] を使って新たな⼊⼒を追加したり、既存の⼊⼒を管理したりするこ
ともできます。また、ファイルをアップロードまたはモニターする場合、データをインデックスに書き込む
前に、ファイルをプレビューしてインデックスの作成⽅法を調整することができます。
Splunk コマンド・ライン・インターフェイス (CLI) の使⽤： CLI を使って、⼤部分のデータ取り込み
を設定できます。
inputs.conf 設定ファイル ：Splunk Web または CLI を使ってデータの取り込みを指定すると、設定内容
は設定ファイル inputs.conf に保存されます。必要に応じてこのファイルを直接編集することができます。
⾼度なデータ取り込みを⾏う場合は、このファイルを編集しなければならないこともあります。
また、フォワーダー を使って他のマシンのデータをインデクサー に送信するように設定する場合、フォワーダー
のインストール時にデータの取り込みを指定することができます。「フォワーダーを使ったデータの取り込み」を
参照してください。
このトピックでは、Splunk Web、CLI、または
説明していきます。
inputs.conf
を使って、⾃分でデータ⼊⼒を設定する⽅法について
Splunk Web の使⽤
データ⼊⼒は Splunk ホーム、または [システム] から追加することができます。
Splunk ホームから、[データの追加] を選択します。[データの追加] ページが表⽰されます。このページ
には、さまざまな⼊⼒タイプ向けのリンクが記載されています。これを使ってデータ⼊⼒を追加するのが
もっとも簡単な⽅法です。「データの追加⽅法は？」を参照してください。
Splunk Web の任意の場所から、[システム] を選択します。次に [システム] ポップアップの [データ] か
ら、[データ⼊⼒] を選択します。この操作で表⽰されるページから、既存のデータ⼊⼒の表⽰、管理、およ
び新しいデータ⼊⼒の追加を⾏えます。
[データの追加] ページには、データを取り込むための 3 種類のオプション [アップロード]、[モニター]、および
[転送] があります。それぞれのアイコンをクリックすると、アップロード、モニター、または転送するデータを定
義することができます。
Splunk Web を使ったデータ⼊⼒の詳細は、このマニュアルの後半にある、特定の⼊⼒に関する説明を参照して
ください。たとえば、Splunk Web を使ったネットワーク⼊⼒の設定⽅法を学習するには、「TCP/UDP ポート
からのデータの取り込み」を参照してください。
⼤半の⼊⼒は Splunk Web を使って設定できます。⼊⼒タイプが少ない場合は、inputs.conf を直接編集する必要
9
があります。また、他の⼊⼒タイプに対して⾼度な設定を⾏う場合も、inputs.conf を編集する必要があります。
Splunk Web を使って⼊⼒を追加した場合、その⼊⼒は現在使⽤している App に所属する inputs.conf のコピー
に追加されます。この点についても考慮が必要です。たとえば、[サーチ] ページから [システム] に直接移動して
⼊⼒を追加した場合、その⼊⼒は $SPLUNK_HOME/etc/apps/search/local/inputs.conf に追加されます。データ⼊⼒を
追加する際には、⾃分が⽬的の App 内にいることを確認してください。 設定ファイルの仕組みの詳細につい
ては、「設定ファイルについて」を参照してください。
CLI の使⽤
Splunk CLI を使って、⼤部分の⼊⼒を設定することができます。UNIX/Windows コマンドプロンプトから
$SPLUNK_HOME/bin/ ディレクトリに移動して、./splunk コマンドを使⽤します。たとえば、以下のコマンドを実⾏す
ると、データ⼊⼒として /var/log/ が追加されます。
./splunk add monitor /var/log/
何か分からないことがある場合、Splunk CLI にはヘルプが⽤意されています。CLI コマンドの⼀覧を表⽰するに
は、以下のコマンドを⼊⼒します。
./splunk help commands
各コマンドには、それぞれ独⾃のヘルプページが⽤意されています。参照するには、次のように⼊⼒します：
./splunk help <command>
CLI を使った特定の⼊⼒の設定については、このマニュアルの適切な⼊⼒に関する説明を参照してください。たと
えば、CLI を使ったネットワーク⼊⼒の設定⽅法を学習するには、「CLI を使ったネットワーク⼊⼒の追加」を
参照してください。
CLI に関する全般的な情報については、『管理マニュアル』の「CLI について」および他の関連するトピックを
参照してください。
inputs.conf の編集
inputs.conf を編集して直接⼊⼒を追加するには、その⼊⼒のスタンザ を設定します。スタンザ
は、$SPLUNK_HOME/etc/system/local/ 内、または ($SPLUNK_HOME/etc/apps/<app name>/local 内の) 独⾃のカスタム App
ディレクトリ内の inputs.conf ファイルに追加します。Splunk の設定ファイルで初めて作業を⾏う場合は、事前
に「設定ファイルについて」を参照してください。
データ⼊⼒を設定するには、スタンザに属性/値のペアを追加します。⼊⼒スタンザには複数の属性を設定できま
す。属性の値を指定しない場合は、$SPLUNK_HOME/etc/system/default/inputs.conf に定義されているデフォルト値が
使⽤されます。
ネットワーク⼊⼒を追加する簡単な例を以下に⽰します。この設定は、任意 のリモートサーバーからの raw デー
タを、TCP ポート 9995 で待ち受けるように Splunk Enterprise に指⽰しています。Splunk Enterprise は、リ
モート・サーバーの DNS 名を使ってデータのホストを設定します。ソースタイプ「log4j」およびソース
「tcp:9995」をデータに割り当てます。
[tcp://:9995]
connection_host = dns
sourcetype = log4j
source = tcp:9995
特定の⼊⼒の設定⽅法については、このマニュアルのその⼊⼒に関する説明を参照してください。たとえば、ファ
イル⼊⼒の設定⽅法については、ここを参照してください。
各データ⼊⼒のトピックには、その⼊⼒で利⽤できる主な属性が説明されています。利⽤可能な属性の完全な⼀覧
については、inputs.conf spec ファイルを参照する必要があります。spec ファイルには、属性の詳細な説明が記
載されています。複数の例を含むファイルも存在しています。
ソース・タイプについて
データ取り込み処理の⼀環として、Splunk Enterprise はデータにソースタイプ を割り当てます。ソースタイプ
はデータのフォーマットを⽰しています。インデックス作成時に Splunk Enterprise はソースタイプを使⽤し
て、イベントを正しくフォーマットします。通常 Splunk は、どのソースタイプを割り当てるのかを理解していま
す。たとえば、syslog データにはソースタイプ「syslog」が割り当てられます。特定の⼊⼒に Splunk
Enterprise が割り当てるソースタイプに不満がある場合は、別のソースタイプを指定することができます (事前定
義されているソースタイプまたは⾃分で作成したソースタイプ)。ソースタイプは⼊⼒の設定時に設定します。設
定⽅法は、このトピックで説明しています。
ソースタイプの詳細は、「ソースタイプが重要な理由」を参照してください。「⾃動ソースタイプ割り当てに優先
する設定」には、ソースタイプ割り当てオプションが詳細に説明されています。
イベント単位でのソースタイプの設定⽅法については、「⾼度なソースタイプの上書き」を参照してください。
Splunk Enterprise によるデータの取り扱い (および活⽤⽅法)
10
Splunk Enterprise は任意の種類のデータを取り込んで、それのインデックス を作成し、イベント に変換しま
す。イベントは有益でサーチ可能な情報です。以下のデータパイプライン は、インデックス作成時のデータ処理
の主な流れを表しています。これらのプロセスが、イベント処理 を構成しています。データが処理されてイベン
トに変換されたら、イベントをナレッジオブジェクト と関連付けて有⽤性をさらに向上することができます。
データパイプライン
Splunk Enterprise に取り込まれた⼀連のデータは、それをサーチ可能なイベントに変換する、データパイプライ
ンを通過します。データパイプラインの主要なステップを以下の図に⽰します。
データパイプラインの概要については、『分散デプロイ』マニュアルの「Splunk Enterprise 内でのデータの移
動」を参照してください。
Splunk Enterprise はイベント処理時に、ほぼすべてのタイプのデータを適切に認識し、有益でサーチ可能なイベ
ントに変換するための処理を⾏います。ただし、データの種類やデータから抽出したい情報によっては、イベント
処理の⼀部のステップを調整しなければならないこともあります。
イベント処理
イベント処理は、パーシングとインデックス作成の 2 つのステージに分かれて⾏われます。Splunk Enterprise
に取り込まれるデータはすべて、⼤きなデータの塊 (チャンク) としてパーシングパイプライン を通過します。
パーシング中に、これらのチャンクはイベントに分割されます。分割されたイベントは、インデックス作成 パイ
プラインに渡されて、最終処理が⾏われます。
パーシングおよびインデックス作成の両⽅の段階で、Splunk Enterprise はデータを処理し、さまざまな⽅法で変
換を⾏います。これらのプロセスの⼤半は設定を変更することができ、ニーズに合わせて処理を調整することがで
きます。以降の説明でリンクをクリックすると、これらのいずれかのプロセスの説明と、設定⽅法に関する情報を
記載したトピックに移動します。
パーシング中、Splunk Enterprise はさまざまなアクションを実⾏します。以下に例を⽰します。
各イベントに対して、host、source、および
sourcetype
11
などの、⼀連のデフォルトフィールドを抽出する。
⽂字セットのエンコードを設定する。
⾏分割ルールを使って⾏の終端を識別する。⼤半のイベントは短く、1〜2⾏程度ですが、中には⻑いイベン
トも存在しています。Splunk Web の [ソースタイプの設定] ページを使って、対話的に⾏の終端設定を変更
することもできます。
タイムスタンプを識別する、また存在しない場合は作成する。タイムスタンプ処理と同時に、イベント境界
の識別が⾏われます。タイムスタンプの設定は、[ソースタイプの設定] ページを使って、対話形式で⾏うこ
ともできます。
このステージで、重要なイベントデータ (クレジットカード情報や社会保障番号など) をマスクするように
Splunk Enterprise を設定することができます。また、受信したイベントにカスタムメタデータを適⽤する
ように設定することもできます。
インデックス作成パイプラインでは、以下のような追加処理が⾏われます。
すべてのイベントを、サーチ可能なセグメントに分割する。セグメント分割のレベルを指定することができ
ます。セグメント分割レベルは、インデックス作成およびサーチ速度、サーチ能⼒、およびディスクの圧縮
効率に影響します。
インデックスデータ構造を作成する。
raw データとインデックスファイルをディスクに書き込む。ディスクでは、インデックス作成後の圧縮処理
が⾏われます。
パーシングおよびインデックス作成パイプラインの違いは、主にフォワーダーに影響してきます。ヘビーフォワー
ダーは、ローカルにデータの完全パーシングを⾏い、パーシングされたデータをインデクサーに転送できます。イ
ンデクサーは最終的なインデックス作成作業を⾏います。⼀⽅ユニバーサルフォワーダーでは、最低限のパーシン
グ処理を⾏った後にデータを転送します。⼤部分のパーシング処理は、受信側のインデクサーで⾏われます。
イベントおよび処理の詳細は、このマニュアルの「イベント処理の概要」を参照してください。
インデックス作成パイプラインの詳細を表した図とインデックス作成の仕組みについては、Community
Wiki の「How Indexing Works」を参照してください。
イベントの強化と調整
データがイベントに変換されたら、それをイベントタイプ、フィールド抽出、および保存済みサーチなどのナレッ
ジオブジェクトに関連付けて、有⽤性を強化することができます。Splunk ナレッジの管理の詳細は、『ナレッジ
管理』マニュアルの「Splunk のナレッジとは？」を参照してください。
Splunk Enterprise へのデータの取り込み
データの追加⽅法は？
最新版の Splunk Enterprise では、データをとても簡単に追加できるようになりました。適切な権限を持つユー
ザーとしてログインしたら、新しい⼿順に 1 クリックでアクセスできます。このトピックは、更新された⼿順
と、前の⼿順からの変更について説明しています。
データを Splunk に取り込むためのチュートリアルについては、『サーチ・チュートリアル』を参照してくださ
い。
新しい [データの追加] ページ
Splunk Enterprise にログインすると、更新されたホーム・ページが表⽰されます。
データを追加するには、ページの中央左 (App リストの右) にある緑⾊の [データの追加] ボタンをクリックしま
す。[データの追加] ページが表⽰されます。
システム・バーの [設定] メニューをクリックして、[データの追加] ページを表⽰することもできます。メニュー
が表⽰された時、[データの追加] ボタンは左側にあります。
12
このページには、Splunk Enterprise インスタンスにデータを取り込むための 3 つのオプション、[アップロー
ド] 、[モニター] 、および [転送] が表⽰されます。
アップロード
[アップロード] オプションでは、インデックスを作成するために、Splunk Enterprise にファイルまたはファイル
のアーカイブをアップロードすることができます。[アップロード] ボタンをクリックすると、アップロード・プロ
セスを開始するページが表⽰されます。「データのアップロード」を参照してください。
モニター
[モニター] オプションでは、1 つまたは複数のファイル、ディレクトリ、ネットワーク・ストリーム、スクリプ
ト、イベント・ログ (Windows システムのみ)、または Splunk Enterprise インスタンスがアクセスできる他のタ
イプのマシン・データをモニターすることができます。[モニター] ボタンをクリックすると、モニター・プロセス
を開始するページが表⽰されます。「データのモニター」を参照してください。
転送
[転送] オプションでは、フォワーダー からこの Splunk Enterprise インスタンスにデータを取り込むことができ
ます。[転送] ボタンをクリックすると、フォワーダーからのデータ収集プロセスを開始するページが表⽰されま
す。「データの転送」を参照してください。
重要： このオプションを使⽤する前に、追加の設定を⾏う必要があります。これは、単⼀インスタンス環境での
み使⽤してください。データのインデックスを作成する複数の Splunk Enterprise インスタンスがある場合は、
『データの転送』マニュアルの「データの転送と受信について」を参照してください。
データのアップロード
このトピックは、[データの追加] ページで [アップロード] ボタンを選択した場合に表⽰されるページについて説
明しています。
[アップロード] ページ
[アップロード] ページには、以下の項⽬が表⽰されます。
このページでは、以下のいずれかの⽅法を使って、データを Splunk Enterprise にアップロードできます。
13
Splunk Enterprise にインデックスを作成させるファイルをデスクトップからドラッグして、このページの
[ここにデータ・ファイルをドラッグ・アンド・ドロップしてください] 領域にドロップします。
または
画⾯左上の [ファイルの選択] ボタンをクリックして、ダイアログ・ボックスを表⽰し、インデックスを作成
するファイルを選択します。
ファイルがロードされ、ファイルのタイプに応じて処理が⾏われます。ロードが完了したら、右上の [次へ] ボタ
ンをクリックして、次のステップ [データの追加] に進みます。
データのモニター
このトピックは、[データの追加] ページで [モニター] ボタンを選択した場合に表⽰されるページについて説明し
ています。
[モニター] ページ
[モニター] ページには、以下の項⽬が表⽰されます。
このページでは、Splunk Enterprise にモニターさせるデータのタイプを選択できます。デフォルトの⼊⼒が最初
に表⽰されます。デフォルトの⼊⼒の下には、転送されている⼊⼒が表⽰されます。その下には、インスタンスに
インストールされているモジュール⼊⼒が表⽰されます。
データをモニターするには、以下の⼿順に従ってください。
1. 画⾯の左側でソースを 1 回クリックして選択します。
選択したソースに応じて、残りのページにはそれに合わせた内容や項⽬が表⽰されます。たとえば、[ファイ
ルとディレクトリ] を選択した場合、ページにはファイル/ディレクトリ名を⼊⼒するためのフィールド、お
よびファイル/ディレクトリのモニター⽅法を指定する項⽬などが表⽰されます。
注意： Splunk Enterprise には、モニターできるソースのみが表⽰されます。詳細は、「データ・ソースの⼀
覧」を参照してください。モニターする⽬的のデータ・ソースが表⽰されない場合は、以下のような理由が考えら
れます。
⼀部のデータ・ソースは、特定のオペレーティング・システムでのみ利⽤できます。たとえば、Windows
データ・ソースを、*nix 上で動作している Splunk Enterprise インスタンスで利⽤することはできません
(逆も同様)。
Splunk Enterprise にログインしているユーザーが、データの追加またはそのデータ・ソースを参照する権
限を持っていない可能性があります。
2. 画⾯に表⽰される指⽰に従って、モニターするソース・オブジェクトの選択を完了します。
3. 右上の [次へ] ボタンをクリックして、次のステップ [データの追加] に進みます。
データ転送
このトピックは、[データの追加] ページで [転送] ボタンを選択した場合に表⽰される [フォワーダーの選択] ペー
ジについて説明しています。
重要： インデクサーおよびデプロイ・サーバーとして動作している単⼀の Splunk Enterprise インスタンスがあ
る場合にのみ、このページを使⽤してください。インデックスの作成を担当する複数のサーバーがある場合は、
『Splunk Enterprise インスタンスの更新』マニュアルの「デプロイ・サーバーとフォワーダー管理について」を
参照してください。
[フォワーダーの選択] ページ
[転送] ページには、以下の項⽬が表⽰されます。
14
このページでは、データを受信するためにサーバー・クラス を定義して、それらのクラスにフォワーダーを追加
します。
このページには、すでにデータの転送を設定し、このインスタンスのデプロイ・クライアントとして動作するよう
に設定されたフォワーダーのみが表⽰されます。フォワーダーの設定が⾏われていない場合は、設定するように要
求するメッセージが表⽰されます。
リストにフォワーダーが表⽰されるようにするには、以下の作業が必要です。
フォワーダーをデプロイ・クライアント として設定する必要があります。こうすると、デプロイ・サー
バーがフォワーダーの設定を管理できるようになります。詳細は、『Splunk Enterprise インスタンスの更
新』マニュアルの「デプロイ・クライアントの設定」を参照してください。
フォワーダーは、デプロイ・サーバーと正常に接続できる必要があります。
リストにフォワーダーが表⽰されたら、データを追加するためにそれの設定を⾏います。
1. [サーバー・クラスの選択] で、表⽰されているいずれかのオプションを選択します。
[新規] ：サーバー・クラスを定義していない、何らかの理由で新しいサーバー・クラスを作成したい、また
は既存のサーバー・クラスが⼊⼒として設定するフォワーダーのグループに適していない場合。
[既存] ：既存のサーバー・クラスを使⽤する場合。
2. [利⽤可能ホスト] パネルで、このインスタンスにデータを受信させるフォワーダーを選択します。フォワー
ダーが [利⽤可能ホスト] パネルから [選択済みホスト] パネルに移動します。[すべて追加] リンクをクリックし
て、すべてのホストを追加することができます。また、[すべて削除] リンクで、すべてのホストを削除すること
もできます。
重要： サーバー・クラスに追加するホストは、特定のプラットフォームのホストでなければなりません。たとえ
ば、Windows ホストと *nix ホストを同じサーバー・クラスに追加することはできません。
3a. [サーバー・クラスの選択] で [新規] を選択した場合、⼀意のサーバー・クラス名を⼊⼒します。
3b. [既存] を選択した場合、ドロップダウン・リストからサーバー・クラスを選択します。
4. 右上の [次へ] ボタンをクリックして、次のステップ [データの追加] に進みます。
[ソースの選択] ページに、選択したフォワーダーに対して有効なソースタイプが表⽰されます。
5. フォワーダーがこのインスタンスにデータを送信する、データ・ソースを選択します。「データのモニター」を
参照してください。
6. 緑⾊の [次へ] ボタンをクリックして、次のステップ [データの追加] に進みます。
[ソースタイプの設定] ページ
[ソースタイプの設定] ページでは、データのインデックスがどのように作成されるのかをプレビューして、イベ
ントの処理 を改善することができます。このページを使って、データのインデックスが意図通りに作成されるこ
とを確認することができます。
データのインデックスをどのように作成するのかを、簡単に調整することができます。対話形式でインデックス作
成プロセスを調整、改善することができます。そのため、後ほど実際にインデックス作成を⾏った時には、⽬的通
りの形式でイベント・データ のインデックスが作成されます。
15
[ソースタイプの設定] ページは、ローカル・インスタンスの単⼀のファイルをアップロード/モニターする場合に
のみ表⽰されます。データを転送するインスタンスに対しては表⽰されません。ネットワーク⼊⼒やディレクトリ
⼊⼒にも対応していません。ただし、正しくプランニングを⾏えば、それらの⼊⼒タイプに対してもこのページを
利⽤できます。詳細は、「データの準備」を参照してください。
このページの表⽰時には、指定したデータに基づいてソースタイプが選択されます。推奨するソースタイプをその
まま使⽤することも、それを変更することも可能です。
[ソースタイプの設定] ページの例を以下に⽰します。
推奨するソースタイプの表⽰、変更
ファイル内のデータを Splunk Enterprise がどのようにイベントとして分割する予定なのかを確認することがで
きます。このインデックス作成がご⾃分のニーズを満たしていない場合は、別のソースタイプを選択した
り、[ソースタイプ：新しいソースタイプ] ボタンをクリックして、新しいソースタイプを作成したりすることが
できます。「イベント・データのソースタイプの表⽰と設定」を参照してください。
イベント・サマリーの表⽰
ページの右側にある、[イベント・サマリーの表⽰] リンクをクリックして、Splunk Enterprise が収集したデー
タ・サンプル内のイベントのサマリーを参照することができます。このサマリーには、以下の情報が表⽰されま
す。
Splunk Enterprise が収集したサンプル・データのサイズ (バイト)。
サンプル内に存在しているイベント数。
時間の経過に伴うイベント分布を表すグラフ。Splunk Enterprise は、ファイル内の⽇付スタンプを使っ
て、このグラフの表⽰⽅法を決定します。
サンプル内の各イベントの⾏数の内訳。
タイムスタンプとイベント分割の調整
Splunk Enterprise によるタイムスタンプ抽出とイベントの分割⽅法を調整することができます。満⾜のいく結果
が得られたら、変更内容を新しいソースタイプ として保存します。次に、それを実際のデータに適⽤してくださ
い。詳細は、「データへの適切なソースタイプの割り当て」を参照してください。
区切り設定
16
カンマ区切り値 (CSV)、タブ区切り値 (TSV)、またはその他の類似のファイルなどの構造化データ・ファイルを
選択した場合、[区切り設定] バーが表⽰されます。このウィンドウでは、これらの構造化データ・ファイルのパー
シング⽅法に関する設定を調整することができます。以下の項⽬を調整できます。
フィールド区切り⽂字 - Splunk Enterprise がデータをフィールドに分割するために利⽤する⽂字。
引⽤⽂字 - 何かが引⽤されている場合に、Splunk Enterprise がそれを判断するために利⽤する⽂字。
ファイルの不要ヘッダー - 構造化データ・ファイル内の不要な⾏を無視するように指⽰する正規表現式。
フィールド名 - Splunk Enterprise によるフィールド名の決定⽅法、⾃動、⾏番号、カスタム⼊⼒、または
正規表現を利⽤できます。
データへの適切なソースタイプの割り当て
ここでは [ソースタイプの設定] ページを使った、インデックスを作成するデータへの適切なソースタイプの相関
⽅法について説明しています。
[ソースタイプの設定] ページの⽬的は、取り込んだデータへの正しいソースタイプ の適⽤をお⼿伝いすることに
あります。ソースタイプは、Splunk Enterprise が取り込んだすべてのデータに割り当てるデフォルトフィール
ド の 1 つです。ソースタイプは、インデックス作成時のデータのフォーマット⽅法を決定します。データに正し
いソースタイプを割り当てることで、インデックスが作成されたデータ (イベントデータ ) には、適切なタイムス
タンプ の設定とイベント 分割が⾏われ、期待通りのデータが作成されます。
Splunk Enterprise には、多数の事前定義されたソースタイプが⽤意されています。たいていの場合は、データの
取り込み時にデータに正しいソースタイプが⾃動的に割り当てられ、適切にデータが処理されます。特殊なデータ
の場合、データに対して別の事前定義ソースタイプを、⼿動で選択しなければならないこともあります。また、独
⾃のイベント処理を設定した、新たなソースタイプを作成しなければならないこともあります。
[ソースタイプの設定] ページは、データに事前定義されているソースタイプを適⽤した結果を表しています。これ
を参考に、データに適切なソースタイプを割り当てられます。また、ソースタイプの設定を対話形式で変更して、
⽬的の結果が得られるまで設定を調整することもできます。作業が完了したら、変更内容を新たなソースタイプと
して保存することができます。
[ソースタイプの設定] ページでは、以下の作業を⾏えます。
Splunk Enterprise が⾃動的に適⽤するデフォルトのイベント処理を使って、データがどのようになるのか
を、データを変更することなく確認する。
別のソースタイプを適⽤して、さらに良好な結果が得られるかどうかを確認する。
タイムスタンプ⽣成またはイベント分割の設定を変更して、インデックスデータの品質を向上し、変更内容
を新しいソースタイプとして保存する。
新たなソースタイプを最初から作成する。
このページは、新しいソースタイプを props.conf ファイルに保存します。後ほどこのファイルをデプロイ環境内の
各インデクサーに配布することで、全体的にそのソースタイプを利⽤することができます。詳細は、「データプレ
ビューと分散 Splunk Enterprise」を参照してください。
ソースタイプの詳細は、このマニュアルの「ソースタイプが重要な理由」を参照してください。また、「イベント
処理の設定」、「タイムスタンプの設定」、および「ソースタイプの設定」内の各トピックにも、ソースタイプの
処理に関する詳細な情報が記述されています。
プレビューするデータの準備
このトピックでは、[ソースタイプの設定] ページで表⽰するデータの準備⽅法を説明します。
[ソースタイプの設定] ページでは、1 つのファイルに対してのみ作業を⾏えます。また、Splunk Enterprise イン
スタンス上にあるファイル、またはそこにアップロードされたファイルのみを利⽤できます。直接ネットワーク
データやディレクトリを処理することはできませんが、この問題には簡単に対処することができます。
ネットワークデータのプレビュー
サンプル・ネットワーク・データをファイルに書き込んで、そのファイルをアップロードする、またはファイルの
モニター⼊⼒として追加することができます。この⽬的で利⽤できるさまざまな外部ツールがあります。たとえ
17
ば、*nix 系では netcat を利⽤することができます。たとえば、ポート 514 で UDP データを待機している場
合、netcat を使ってネットワークデータの⼀部をファイルに書き込むことができます。
nc -lu 514 > sample_network_data
ベスト・プラクティスは、ファイル・サイズが 2MB に達したら netcat を kill するシェル・スクリプト内で、こ
のコマンドを実⾏することです。デフォルトで、データプレビュー機能は、ファイル内の最初の 2MB のデータの
みを読み込みます。
「sample_network_data」ファイルを作成したら、それを標準の⼊⼒と同様に追加することができます (アップ
ロードする、またはファイル⼊⼒として追加する)。⼊⼒定義プロセスの⼀環として、[ソースタイプの設定] ペー
ジが表⽰されます。ファイル内のデータのプレビューを⾏って、必要な変更をイベント処理に反映させたら、その
ソースタイプを直接ファイルに適⽤することができます。
ディレクトリ内の複数ファイルのプレビュー
ディレクトリ内のすべてのファイルが同じような内容のデータを保有している場合、どれか 1 つのファイルで
データのプレビューを⾏えば、そのディレクトリ内のすべてのファイルに対してほぼ満⾜がいく結果を得ることが
できます。ただし、ディレクトリにさまざまな形式や環境のデータファイルが混在している場合は、データが異な
る⼀連のファイルを個別にプレビューする必要があります。この場合、各タイプのファイルを個別にプレビューす
る必要があります (ワイルドカードを指定すると、[ソースタイプの設定] ページが無効になるため)。
ファイルサイズの制限
Splunk Enterprise は、[ソースタイプの設定] ページのファイルから、最初の 2MB のデータを読み込んで表⽰し
ます。たいていの場合は、これで⼗分なデータ標本を得ることができます。⼤量のデータで試したい場合は、
limits.conf で max_preview_bytes 属性を変更します。代わりにファイルのデータ量を削減し、2MB のデータがオリ
ジナルのファイルの各種データタイプを反映するように編集することもできます。
イベント・データのソースタイプの表⽰と設定
このトピックは、受信データのプレビュー⽅法、およびそのデータのソースタイプの設定/作成⽅法について説明
しています。
Splunk Web でファイル⼊⼒を作成する場合、この機能が⾃動的に利⽤されます。Splunk Web の [ファイルと
ディレクトリ] ページで単⼀ファイルを新しい⼊⼒として追加またはアップロードを開始すると (ここを参照)、
[ソースタイプの設定] ページが表⽰されます。
この時点で、データのインデックスがどのように作成されるのかを確認することができます。次に、変更または新
しいソースタイプの作成、既存のソースタイプの選択、または推奨されているソースタイプをそのまま使⽤して、
直接 [⼊⼒の設定] ページに進むことができます。
ソースタイプの確認と設定
[データの追加] パネルの [ファイルとディレクトリ] でモニターするファイルを選択、または [アップロード]
ページからファイルをアップロードすると、[ソースタイプの設定] ページが表⽰されます。
このページには、3 つのセクションがあります。上部のセクションには、ページの使⽤⽅法が表⽰されます。下部
左側のセクションには、イベント分割、タイムスタンプの設定などの、新しいソースタイプを選択、定義するため
のオプションや、その他のオプションが記載されています。下部右側の [データのプレビュー] パネルには、
Splunk Enterprise が現在データをどのように認識しているのかが表⽰されます。下部左側のセクションで操作を
⾏うと、それが即座に下部右側のセクションに反映されます。
任意の時点で上部の⽩い [<] ボタンをクリックすることで、前のページに戻ってプレビューする新しいファイルを
選択することができます。
1a. まず、Splunk Enterprise がデータをどのように表⽰しているのかを参照します。ここに表⽰されている内容
で、データのインデックスが作成されます。イベントの分割やタイムスタンプを確認してください。
1b. [イベント・サマリー] ダイアログを使って、ファイルのパーシング時に Splunk Enterprise がカウントした⾏
数を参照することができます。ファイル内のカウントされた⾏数が少ない場合、イベントの分割を調整しなければ
ならない可能性があります。
2a. ⽬的通りにデータが表⽰されている場合は、ステップ 3a に進みます。
2b. データが⽬的通りに表⽰されていない場合、このトピックの「既存のソースタイプの選択」に進んで、⽬的通
りにデータが表⽰されるまでソースタイプ・パラメータの変更を⾏います。
3a. Splunk Enterprise が選択した既存のソースタイプをそのまま使⽤する場合は、上部にある緑⾊の [次へ] ボタ
ンをクリックして、[⼊⼒設定] ページに進みます。これでデータのプレビュー・プロセスは完了です。
3b. Splunk Enterprise が選択した既存のソースタイプを使⽤しない、Splunk Enterprise がソースタイプを選択
しない、または新しいソースタイプを定義したい場合は、以下のいずれかの作業を⾏えます。
既存のソースタイプを選択する： データは、このソースタイプでインデックスが作成されます。警告： 別
のソースタイプを選択すると、表⽰されるデータおよびデータのインデックス作成⽅法が変化する可能性が
あります。
新しいソースタイプを保存する： 希にデータは正しくパーシングされたけれども、使⽤する既存のソース
タイプが選択されないことがあります。このような場合、ソースタイプを保存して、それを以降の類似の
ファイルに適⽤することができます。
18
4. ソースタイプを選択または保存したら、上部にある緑⾊の [次へ] ボタンをクリックして、[⼊⼒設定] ページに
進みます。これでデータのプレビュー・プロセスは完了です。
既存のソースタイプの選択
データが意図通りに表⽰されない場合、まず既存の他のソースタイプを利⽤できるかどうかを確認してください。
既存のソースタイプを選択しても⽬的の結果が得られない場合は、このトピックの後半の「新しいソースタイプの
定義」を参考に、⽬的通りの結果が得られるように調整してください。
1. [ソースタイプ：システムのデフォルト] ボタンをクリックします。
ソースタイプのカテゴリ⼀覧が表⽰されます。各カテゴリ下には、その⽅ゴリ内のソースタイプのリストが表⽰さ
れます。
2. データに最適なカテゴリ上にマウス・カーソルを移動します。そのカテゴリ下のソースタイプが、ポップアッ
プ・メニューに表⽰されます。
3. データに適したソースタイプを選択します。新しいソースタイプでデータがどのようになるかを⽰すために、
データのプレビュー・パネルが更新されます。
注意： スクロールしないとカテゴリ内のすべてのソースタイプを参照できないこともあります。
4. 前述の「ソースタイプの確認と設定」に従って、データを再確認します。
新しいソースタイプの定義
既存のソースタイプを選択しても、データが正しく認識されない場合は、新しいソースタイプを定義して、イベン
ト分割、タイムスタンプ認識、およびその他のパラメータを設定して、Splunk Enterprise が正しくデータを認識
できるまで調整を⾏います。
これらのパラメータの変更およびソースタイプの定義については、このマニュアルの「イベント処理の変更」を参
照してください。
イベント処理の変更
Splunk Enterprise によるデータの処理結果 (「イベント・データのソースタイプの表⽰と設定」を参照) に満⾜
できない場合は、データ・プレビュー機能を使ってイベント処理設定を変更し、その設定を新しいソースタイプと
して保存することができます。主な⼿順を以下に⽰します。
1. イベント・データを表⽰します。詳細は、「ソースタイプのイベント・データの表⽰と設定」を参照してくださ
い。
19
2. イベント処理設定を変更します。
3. 変更による影響を確認し、満⾜のいく結果が得られるまで、調整を繰り返します。
4. 設定を新しいソースタイプとして保存します。
新しいソースタイプは、任意の⼊⼒に適⽤することができます。
イベント処理設定の変更
Splunk Enterprise ではデフォルトで、新しいソースタイプを定義することができます。そのためには、[ソース
タイプの設定] ページの [ソースタイプ：システムのデフォルト] ドロップダウンを利⽤します。新しいソースタイ
プを作成するには、後述の説明に従ってイベント分割およびタイムスタンプ・パラメータを設定し、それを保存し
ます。
[ソースタイプの設定] ページの左側には、3 種類の調整作業を⾏うためのタブとリンクがあります。
イベント改⾏： Splunk Enterprise がデータをイベントに分割する⽅法を調整します。
タイムスタンプ： Splunk Enterprise がイベントのタイムスタンプを決定する⽅法を調整します。
詳細： props.conf を直接編集します。
イベント改⾏
イベント分割パラメータを変更するには、[イベント改⾏] バーをクリックして展開します。バーに以下のボタン
が表⽰されます。
⾃動 - データ内で⾒つかったタイムスタンプに基づいてイベント分割を⾏います。
各⾏ - 各⾏が単⼀のイベントとみなされます。
正規表現... - データのイベントへの分割に使⽤する正規表現を指定する場合は、このボタンをクリックしま
す。
イベント分割 (改⾏) の詳細は、「イベントの⾏分割の設定」を参照してください。
正規表現の構⽂と使⽤⽅法の概要については、Regular-Expressions.info を参照してください。正規表現をテス
トするには、rex サーチ・コマンドを使⽤します。正規表現式を作成、テストするために役⽴つサードパーティ製
ツールのリストも⽤意されています。
タイムスタンプ
20
タイムスタンプ認識パラメータを変更するには、[タイムスタンプ] をクリックして、それを展開します。バーに
以下のオプションが表⽰されます。
[抽出] では、以下のいずれかのオプションを選択することができます。
⾃動 - Splunk Enterprise がタイムスタンプを⾃動検出します。
現在の時刻 - ローカル・インスタンス上の現在の時刻が使⽤されます。
詳細 - 調整するための⾼度なパラメータが表⽰されます。
[詳細] パラメータを以下に⽰します。
タイムゾーン - イベントに使⽤するタイムゾーンを選択します。
タイムスタンプ形式 - データ内のタイムスタンプの検索時に使⽤する、タイムスタンプ形式を表す⽂字列を
⼊⼒します。
タイムスタンプ・プリフィックス - タイムスタンプの前に登場する⽂字を表す正規表現を⼊⼒します。
先読み - タイムスタンプのためにイベント (または、[タイムスタンプ・プリフィックス] に指定した正規表
現) を調査する⽂字数を⼊⼒します。
重要： [タイムスタンプ形式] フィールドにタイムスタンプのフォーマットを指定し、タイムスタンプが各イベン
トの開始点付近に存在していない場合は、[タイムスタンプ・プリフィックス] フィールドにプリフィックスを指
定する必要があります。そうしないと、フォーマット処理を⾏えず、各イベントには strptime を使⽤できない旨
の警告が含まれます。(それでも、Splunk が問題にどのように対処するのかによっては、有効なタイムスタンプが
得られる可能性があります。)
タイムスタンプ設定の詳細は、「タイムスタンプの設定」を参照してください。
詳細
詳細パラメータを変更するには、[詳細] バーをクリックして、それを展開します。バーに、props.conf ファイルを
直接編集してソースタイプのプロパティを指定できるオプションが表⽰されます。
ここでは、属性と値のペアを指定することで、ソースタイプのプロパティを追加または変更することができます。
これらのプロパティの設定⽅法の詳細は、props.conf を参照してください。
このボックスは、編集しているソースタイプの、現在の完全なプロパティセットが表⽰されています。これには、
以下の情報が含まれています。
[イベント改⾏] または [タイムスタンプ] タブで⾏われた変更により⽣成された設定 ([適⽤] ボタンをク
リックした後)。
最初にデータプレビュー機能にファイルを取り込んだ時に⾃動検出された、または⼿動で選択したソースタ
イプの既存の設定。
[その他の設定] テキストボックスから適⽤した任意の設定 ([設定の適⽤] ボタンをクリックした後)
21
ソースタイプのプロパティの設定⽅法の詳細は、『Configuration file reference』の props.conf に関するトピッ
クを参照してください。また、タイムスタンプ設定およびイベントの⾏分割に関するトピックも参照してくださ
い。
Splunk Enterprise が複数の設定を組み合わせる⽅法
[詳細] で⾏った設定が常に優先されます。たとえば、[タイムスタンプ] タブでタイムスタンプ設定を変更し、ま
た [詳細] でも競合するタイムスタンプの変更を⾏った場合、どちらの変更を先に⾏った場合でも、[詳細] での変
更が優先されます。
この最⾼優先度の設定から始まって、残りの設定が順番に組み合わせられます。
[詳細] モードでの変更
[イベント改⾏]/[タイムスタンプ] の変更
基盤となるソースタイプの設定
すべてのソースタイプのデフォルトのシステム設定
また、[詳細] で変更を⾏った後に、[イベント改⾏] タブまたは [タイムスタンプ] タブに戻った場合、それらのタ
ブでその変更は表⽰されません。
変更内容の確認
変更の効果を確認する準備ができたら、[設定の適⽤] を選択します。画⾯が更新され、変更した設定がデータに
与える影響を確認することができます。
さらに変更を⾏いたい場合は、これまでに説明した 3 種類の調整⽅法を使って、さらに調整を繰り返します。そ
の後もう⼀度 [変更の適⽤] を選択して、変更がデータに与える影響を確認します。
変更内容を新しいソースタイプとして保存
変更内容を新たなソースタイプとして保存するには、[ソースタイプ] ボタンの隣りにある緑⾊の [名前を付けて保
存] ボタンをクリックします。ダイアログ・ボックスが表⽰されます。ここでは、ソースタイプ名の指定、[ソース
タイプ] ボタンを押した時に表⽰される所属先カテゴリの選択、および使⽤するアプリケーション・コンテキスト
の指定を⾏えます。
1. 新しいソースタイプの [名前] を⼊⼒します。
2. ソースタイプの [説明] を⼊⼒します。
3. [ソースタイプ] ボタンの選択時に、ソースタイプを表⽰させる [カテゴリ] を選択します。
4. 新しいソースタイプを使⽤する [App] を選択します。
5. 緑⾊の [保存] ボタンをクリックしてソースタイプを保存し、[ソースタイプの設定] ページに戻ります。
この時点で、以下の作業を⾏えます。
緑⾊の [次へ] ボタンをクリックしてデータにソースタイプを適⽤し、[⼊⼒設定] ページに進みます。
⽩い [<] ボタンをクリックすると元のページに戻って、アップロード/モニターする新しいファイルを選択す
ることができます。
[データの追加] をクリックすると、[データの追加] ウィザードの先頭に戻ります。
データプレビューと分散 Splunk Enterprise
データプレビュー機能を使って新しいソースタイプを作成し、それを特定のファイル/ディレクトリまたは
TCP/UDP からの⼊⼒に割り当てることができます。データプレビュー機能は新しいソースタイプを、実⾏してい
る Splunk Enterprise インスタンスの props.conf 設定ファイルに保存します。他の Splunk Enterprise インスタ
ンス上でこのソースタイプを使⽤したい場合は、必要に応じてこのファイルを配布することができます。
フォワーダー がデータを収集して、それをインデクサーに転送する分散環境で、新しいソースタイプを使⽤する
には、2 つのステップに分けて作業を⾏います。
1. ソースタイプ定義を含む
props.conf
ファイルを、そのソースタイプを使ってデータのインデックスを作成する任
22
ソースタイプ定義を含む props.conf ファイルを、そのソースタイプを使ってデータのインデックスを作成する任
意のインデクサーに配布します。
2. 次に、それらのインデクサーにデータを転送するフォワーダー上で⼊⼒を定義する際に、その新しいソースタイ
プを使⽤します。
フォワーダーがインデクサーに新しいソースタイプのタグが付いたデータを送信すると、インデクサーはそれを正
しく処理してイベントを作成することができます。
ここでは、まずデータプレビュー機能が作成する設定ファイルについて説明します。次に、デプロイ環境内のイン
デクサーにファイルを配布する⽅法を説明していきます。最後に、フォワーダー上で⼊⼒を定義する際の、新しい
ソースタイプの指定⽅法について説明します。
分散 Splunk Enterprise の詳細は、『分散デプロイ』マニュアルを参照してください。
props.conf ファイル
[ソースタイプの設定] ページで新しいソースタイプを作成すると、ソースタイプの保存時に選択した App 内の
props.confファイルに、ソースタイプ定義がスタンザとして保管されます：たとえば、[サーチとレポート] App
を選択すると、ファイルは $SPLUNK_HOME/etc/apps/search/local/props.conf に保管されます。唯⼀の例外は [システ
ム] App です。ソースタイプの保存時にこの App を選択すると、ファイルは $SPLUNK_HOME/etc/system/local. に保
管されます。
初めてデータ・プレビューを使ってソースタイプを作成する場合、ソースタイプの保存時に選択した App ⽤の
ディレクトリ内に新たな props.conf ファイルが⽣成されます。後ほど他のソースタイプを作成した場合、そのソー
スタイプも同じ props.conf に保管されます。
注意： Splunk Enterprise インスタンスに同じ設定ファイルの異なるバージョンが、それぞれ違うディレクトリ
に保管されている場合もあります。Splunk Enterprise は実⾏時に⼀定の規則に基づいて、これらの設定ファイル
の内容を組み合わせます。設定ファイルの仕組みの詳細については、「設定ファイルについて」および「設定ファ
イルの優先度」を参照してください。
他のインデクサーへの props.conf の配布
新しいソースタイプを作成したら、データプレビューの props.conf ファイルを他の Splunk Enterprise インスタ
ンスに配布することができます。ファイルが配布されたインスタンスは、その新しいソースタイプのタグが設定さ
れている、任意の受信データのインデックスを作成することができます。
⼀般的には、ターゲット Splunk Enterprise インスタンス上の、独⾃の App ディレクトリ
(例：$SPLUNK_HOME/etc/apps/splunk_datapreview/local/) に設定ファイルを保管します。
他の Splunk インスタンスに設定ファイルを配布するために、Splunk のデプロイサーバー や他の配布ツールを
使⽤することができます。デプロイサーバーの使⽤⽅法については、『Splunk インスタンスの更新』マニュアル
を参照してください。
注意： Splunk Enterprise は props.conf 内のソースタイプ定義を使⽤して、受信データをイベントにパーシング
します。そのため、パーシング を実⾏する Splunk Enterprise インスタンス、つまりインデクサーまたはヘビー
フォワーダー にのみファイルを配布することができます。
フォワーダーの⼊⼒への新しいソースタイプの指定
フォワーダー (ヘビーフォワーダーを除く) には Splunk Web が含まれていないため、⼀般的に⼊⼒の設定には
inputs.conf 設定ファイルを使⽤します。このファイルに⼊⼒を指定する場合、⼊⼒のソースタイプも指定するこ
とができます。inputs.conf の詳細は、「設定ファイルリファレンス」の inputs.conf に関するセクションを参照し
てください。
フォワーダーの⼊⼒に新しいソースタイプのタグを設定するには、inputs.conf 内の⼊⼒スタンザにソースタイプ
を追加します。例：
[tcp://:9995]
sourcetype = new_network_type
フォワーダーからデータを受信するすべてのインデクサーに、新しいソースタイプ定義 (例：new_network_type)
が含まれている props.conf ファイルのコピーがあることを確認する必要があります。フォワーダーがインデクサー
にデータを送信すると、インデクサーは新たなソースタイプを識別し、正しくデータをフォーマットすることがで
きます。props.conf の配布⼿順については、「他のインデクサーへの props.conf の配布」を参照してください。
データプレビューとサーチヘッドプーリング
分散サーチ環境 でサーチヘッドプーリング 機能を使っている場合、Splunk Web にデータのプレビューが適切
に表⽰されるように、いくつかのガイドラインに従う必要があります。これは、データプレビュー機能が内蔵の
App として実装されているためです。詳細は、『分散サーチ』マニュアルの「アップグレード後に Splunk Web
に不⾃然または不正確な項⽬が表⽰される」を参照してください。
⼊⼒設定の変更
ここでは、[ソースタイプの設定] ページでデータ・ソースを設定した後に表⽰される [⼊⼒の設定] ページについ
て説明していきます。
23
ソースの選択 (または単⼀ファイルのアップロード/モニター時のソースタイプの設定) 後には、以下のページが表
⽰されます。
このページでは、ソースタイプ、アプリケーション・コンテキスト、ホスト値、⼊⼒からのデータを保管するイン
デックスなどの、データ⼊⼒に対する追加のパラメータを設定できます。
利⽤できる⼊⼒設定を以下に⽰します。
ソースタイプ
[ソースタイプ] では、データに適⽤するソースタイプを指定できます。これは、以下のようなソースを選択した場
合に表⽰されます。
単⼀のファイルではない、または
アップロードしたファイルではない
データ・ソースがどちらの基準も満たさない場合、[ソースタイプ] 設定は表⽰されません。
ソースタイプを指定するには、3 種類のいずれかのボタンを選択します。
⾃動 ：データにデフォルトのソースタイプを適⽤します。
選択 ：データに指定したソースタイプを適⽤します。[選択] をクリックすると、ドロップダウンにそのマシ
ンで利⽤できるすべてのソースタイプが、カテゴリ別に表⽰されます。まず⽬的のソースタイプに合ったカ
テゴリを選択し、次にリストからソースタイプを選択してください。
マニュアル ：以下のフィールドに⼊⼒したソースタイプを使⽤します。
App コンテキスト
[App コンテキスト] 設定には、⼊⼒がデータを収集するコンテキストを指定します。App コンテキストによ
り、⼊⼒およびソースタイプ定義の管理性が向上します。すべての App コンテキストは、優先順位に基づいて読
み込まれます。『管理マニュアル』の「設定ファイルの優先度」を参照してください。
ドロップダウンをクリックして、この⼊⼒に対する⽬的のアプリケーション・コンテキストを選択します。
ホスト値
Splunk Enterprise は、インデックスを作成した各イベントにホスト値でタグを設定します。イベントへのタグの
設定⽅法を指定することができます。
定数値 ：[ホスト・フィールドの値] フィールドに指定した値を使⽤します。host フィールドのこの値で、各
イベントにタグが設定されます。後ほど同じ値を持つこの host フィールドをサーチすることができます。
パスの正規表現 ：データを含むファイルのパスから、ホスト値を抽出する場合に使⽤します。下の [正規表
現] フィールドに、有効な正規表現を⼊⼒します。この正規表現を使って、パスからホスト名が抽出されま
す。「ホストについて」を参照してください。
パスのセグメント ：ソース⼊⼒パス名内のセグメントを使ってホスト値を決定する場合に、この設定を使⽤
します。下の [セグメント番号] フィールドには、セグメント番号を⼊⼒します。
たとえば、ソース⼊⼒のパス名が /var/server/<hostname> で、hostname に基づいてホスト・フィールドを設定したい
場合は、[パスのセグメント] を選択してセグメント番号として 3 を⼊⼒します (<hostname> はパス
/var/log/hostname 内の 3 番⽬のセグメントであるため)。
インデックス
[インデックス] には、この⼊⼒のイベントを保管するインデックスを指定します。デフォルトのインデックスを使
⽤するには、[デフォルト] を設定します。他のインデックスを選択する場合は、ドロップダウン・ボタンをクリッ
クしてデータを保管するインデックスを選択します。データを保管するインデックスがリストに記載されていない
場合、適切な権限があれば、[新しいインデックスの作成] ボタンをクリックして、新しいインデックスを作成す
ることができます。
選択が完了したら、緑⾊の [次へ] ボタンをクリックして、最終ステップの [データの追加] に進むことができま
す。
24
ファイルやディレクトリからデータを収集
ファイルとディレクトリのモニター
Splunk Enterprise には、monitor 、MonitorNoHandle 、および upload の 3 つのファイル⼊⼒プロセッサが
あります。
monitor を使ってファイルやディレクトリからの、ほぼすべてのデータ・ソースを追加することができます。た
だし、履歴データのアーカイブなど、1 回限り取り込むようなデータには、upload を使⽤することもできます。
Windows システムでは、MonitorNoHandle を使って、システムがローテーションを⾃動的に⾏うファイルを
モニターすることができます。MonitorNoHandle は、Windows システム上でのみ機能します。
モニターまたはアップロードする⼊⼒を、以下の任意の⽅法を使って追加することができます。
Splunk Web
CLI
inputs.conf
CLI または inputs.conf を使って、MonitorNoHandle に⼊⼒を追加することができます。
[ソースタイプの設定] ページを使って、Splunk Enterprise がファイルのデータに対してどのようなインデックス
を作成するかを確認することができます。詳細は「[ソースタイプの設定] ページ」を参照してください。
Splunk Enterprise のモニターの仕組み
ファイルやディレクトリへのパスを指定すると、Splunk Enterprise のモニター⽤ monitor プロセッサはその
ファイルまたはディレクトリに書き込まれる新しいデータを取り込みます。これによって、J2EE または .NET ア
プリケーションなどからのライブアプリケーションログ や Web アクセスログなどのログ情報をモニターすること
ができます。Splunk Enterprise は継続的にファイルやディレクトリをモニターし、新たなデータが到着するとイ
ンデックスを作成します。Splunk Enterprise がディレクトリからデータを読み込めるならば、NFS を含めたマ
ウントされたディレクトリや共有ディレクトリを指定することもできます。指定されたディレクトリ内にサブディ
レクトリがある場合、Splunk Enterprise はそれらのディレクトリも再帰的に調査して新たなファイルのデータを
取り込みます。
モニター設定に指定されたファイルまたはディレクトリは、Splunk Enterprise の起動および再起動時にチェック
されます。起動時にファイルやディレクトリが存在していなかった場合、Splunk Enterprise は最後の再起動時刻
から 24 時間ごとに再チェックを⾏います。また Splunk Enterprise は、モニター対象ディレクトリのサブディ
レクトリも、継続的にスキャンします。Splunk Enterprise を再起動せずに新しい⼊⼒を追加したい場合は、
Splunk Web または CLI を使⽤します。Splunk Enterprise に⾃動的に新たな⼊⼒候補を探させる場合は、CLI
コマンドの crawl を使⽤します。
モニターを使⽤する場合、以下の事項に注意してください。
⼤半のファイルシステムでは、書き込み中でもファイルを読み取ることができます。ただし、Windows
ファイルシステムには、書き込み中のファイルの読み取りを防⽌する機能があり、⼀部の Windows プログ
ラムはこの機能を使⽤しています。書き込み中のファイルを読み取りたい場合は、MonitorNoHandle ⼊⼒を使
⽤することができます。
対象とする、または除外するファイルやディレクトリを、ホワイトリスト とブラックリスト を使って指定
することができます。
再起動すると、Splunk Enterprise は処理を中断した時点からファイルの処理を再開します。
アーカイブファイルは、そのインデックスを作成する前に解凍されます。次のような、⼀般的なアーカイブ
ファイルタイプを処理することができます：tar, gz, bz2, tar.gz, tgz, tbz, tbz2, zip、および z。
既存のアーカイブファイルに新しくデータを追加した場合、その新たなデータだけではなく、ファイル内の
すべてのデータのインデックスが再作成されます。そのため、イベントの重複が発⽣する可能性がありま
す。
Splunk Enterprise はログファイルのローテーションを検出して、すでにインデックスを作成している、名
前が変更されたファイルの処理は⾏いません (tar と .gz は例外です、詳細は、このマニュアルの「ログファ
イルのローテーション」を参照してください)。
dir/filename パスの全⻑は、1024 ⽂字以下でなければなりません。
コマンドラインまたは [システム] を使ってファイルベースの⼊⼒を無効化または削除しても、その⼊⼒で処
理中のファイルのインデックス作成は中断されません。ファイルの再チェックは中⽌されますが、中⽌時点
でのすべてのデータのインデックスが作成されます。すべてのデータ処理を中⽌するには、Splunk
Enterprise サーバーを再起動する必要があります。
Splunk Enterprise は、ファイル拡張⼦ .splunk を持つファイルのインデックスを作成しません。これは、
Splunk Enterprise がこの拡張⼦を持つファイルを、メタデータ情報を持つファイルと想定しているためで
す。.splunk 拡張⼦を持つファイルのインデックス作成が必要な場合は、 add oneshot CLI コマンドを使⽤し
てください。
モニター⼊⼒がオーバーラップしている場合もあります。スタンザ名が異なっている限り、Splunk Enterprise は
それらを別個のスタンザとして取り扱い、スタンザにもっとも⼀致するファイルが、そのスタンザの設定に従って
処理されます。
アップロードまたはバッチを使⽤する理由
静的ファイルのインデックスを 1 回作成するには、Splunk 上で [アップロード] を選択します。Splunk
Enterprise はファイルを 1 回のみモニターします。
同じ⽬的で CLI コマンドの
してください。
add oneshot
または
spool
を使⽤することもできます。詳細は、「CLI の使⽤」を参照
25
ファイルを 1 回のみ読み込んで、その後破棄するには、inputs.conf の batch ⼊⼒タイプを使⽤します。デフォル
トで、Splunk の batch プロセッサは、$SPLUNK_HOME/var/spool/splunk にあります。このディレクトリにファイルを
移動すると、それのインデックスが作成され、その後ファイルが削除されます。
注意： ファイルアーカイブの読み込みのベストプラクティスについては、コミュニティ Wiki の「How to index
different sized archives」を参照してください。
MonitorNoHandle の使⽤理由
この Windows 専⽤⼊⼒を利⽤すれば、Windows システム上の書き込み中のファイルを読み取ることができま
す。そのために、カーネルモードのフィルタドライバを使って、ファイルに書き込み中の raw データを捕捉して
います。書き込みのためにロック付きで開かれているファイルを読み込む場合に、この⼊⼒スタンザを使⽤しま
す。Windows DNS サーバーのログファイルなど、システムが書き込み⽤にロック付きで開いているファイルに
対して、この⼊⼒スタンザを使⽤できます。
注意： MonitorNoHandle では、単⼀のファイルのみをモニターできます。ディレクトリをモニターすることはできま
せん。モニター対象として選択したファイルがすでに存在している場合、Splunk は現在の内容のインデックスは
作成せずに、新たにファイルに書き込まれるデータのみインデックスを作成します。
Splunk Web の使⽤
Splunk Web を使って、ファイルやディレクトリからの⼊⼒、または Splunk Enterprise インスタンスがモニ
ターできる他の⼊⼒を追加することができます。
A. [新規追加] ページに移動
⼊⼒ (データの取り込み) は、Splunk Web の [新規追加] ページから追加します。「データの追加⽅法は？」を参
照してください。
2 種類の⽅法でこのページを表⽰できます。
Splunk ホーム
Splunk 設定
Splunk 設定を使⽤する場合：
1. Splunk Web の右上にある [設定] をクリックします。
2. [設定] ポップアップの [データ] セクションで、[データ⼊⼒] をクリックします。
3. [ファイルとディレクトリ] をクリックします。
4. [新規] ボタンをクリックして、⼊⼒を追加します。
Splunk ホームを使⽤する場合：
1. Splunk ホームの [データの追加] リンクをクリックします。
2. ファイルをアップロードするには [アップロード] を、ファイルをモニターするには [モニター] を、ファイル
を転送するには [転送] をクリックします。
注意： ファイルの転送には、追加設定が必要です。『データの転送』マニュアルの「転送と受信の設定」を参照
してください。
B. ⼊⼒ソースの選択
1. ファイルまたはディレクトリ⼊⼒を追加するには、[ファイルとディレクトリ] をクリックします。
2. [ファイルまたはディレクトリ] フィールドで、ファイルまたはディレクトリへのフルパスを指定します。
共有ネットワークドライブをモニターするには、次のように⼊⼒します：<myhost>/<mypath>(Windows の場合は
\\<myhost>\<mypath>)。Splunk Enterprise に、マウントされたドライブ、およびモニター対象ファイルに対する読
み取り権限があることを確認してください。
3. Splunk Enterprise によるファイルのモニター⽅法を選択します。
継続モニター ：継続的なデータ取り込み (⼊⼒) を設定します。Splunk Enterprise はファイルの新しい
データを継続的にモニターします。このオプションの詳細設定については、次のセクションを参照してくだ
さい。
1 回インデックスを作成 ：サーバーから Splunk Enterprise に、ファイルをコピーします。
4. 緑⾊の [次へ] ボタンをクリックします。
[ファイルまたはディレクトリ] フィールドでディレクトリを指定した場合、画⾯が更新され [ホワイトリス
ト] および [ブラックリスト] フィールドが表⽰されます。これらのフィールドには、Splunk Enterprise が
含める (ホワイトリスト) または除外する (ブラックリスト) ファイルを照合するために使⽤する正規表現を
指定できます。「ホワイトリストまたはブラックリスト固有の到着データ」を参照してください。
それ以外の場合は、データのプレビューを⾏えます。
C. データのプレビューとそのソースタイプの設定
26
新しいファイル⼊⼒を追加する場合、データのソースタイプ を設定して、それがインデックス作成後にどのよう
に表⽰されるかを設定します。そうすることにより、データが適切にフォーマットされ、必要な調整が⾏われるこ
とが保証されます。
詳細は、「[ソースタイプの設定] ページ」を参照してください。
ページの使⽤⽅法については、「イベント・データのソースタイプの表⽰と設定」を参照してください。
データ・プレビューをスキップすることを選択すると、[⼊⼒設定] ページが表⽰されます。
注意： Splunk Enterprise では、ディレクトリやアーカイブされたファイルのプレビューを表⽰できません。
D. ⼊⼒設定の指定
[⼊⼒設定] ページでは、アプリケーション・コンテキスト、デフォルトのホスト値、およびインデックスを指定
できます。これらのパラメータは省略することができます。
1. この⼊⼒の適切なアプリケーション・コンテキスト を選択します。
2. ホスト 名の値を設定します。さまざまな選択肢があります。ホスト値の設定の詳細は、「ホストについて」を
参照してください。
注意： [ホスト] は、イベントの host フィールドの設定のみを⾏います。Splunk Enterprise にネットワー
ク上の特定のホストを探すように指⽰するものではありません。
3. この⼊⼒のデータを保管するインデックス を設定します。複数のインデックスを定義しており、それらの中の
1 つを使⽤する場合を除き、この値は「default」のままにしてください。ユーザーデータ⽤のインデックスに加
えて、Splunk Enterprise にはさまざまなユーティリティインデックスが存在しています。これらのインデックス
も、このドロップダウンボックスに表⽰されます。
4. 緑⾊の [確認] ボタンをクリックします。
E. 選択項⽬の確認
⼊⼒設定をすべて指定したら、選択内容をレビューすることができます。Splunk Enterprise には、モニターのタ
イプ、ソース、ソースタイプ、アプリケーション・コンテキスト、インデックスなど (これ以外が表⽰されること
もあります) の、選択したオプションが表⽰されます。
設定を確認します。意図通りの内容でない場合は、灰⾊の [< ] ボタンをクリックして、ウィザードの前のステップ
に戻ります。そうでない場合は、緑⾊の [送信] ボタンをクリックします。
[成功] ページが表⽰され、指定されたファイルまたはディレクトリのインデックス作成が開始されます。
CLI の使⽤
ファイルやディレクトリを Splunk Enterprise のコマンドラインインターフェイス (CLI) を使ってモニターしま
す。CLI を使⽤するには、コマンドプロンプトまたはシェルから $SPLUNK_HOME/bin/ ディレクトリに移動して、そ
こで splunk コマンドを使⽤します。
何か分からないことがある場合、CLI にはヘルプが⽤意されています。CLI メインヘルプにアクセスするに
は、splunk help と⼊⼒します。各コマンドには、それぞれ独⾃のヘルプページが⽤意されています。splunk help
<command> と⼊⼒してください。
⼊⼒設定⽤の CLI コマンド
CLI を使った⼊⼒設定には、以下のコマンドを利⽤できます。
コマン
ド
コマンドの構
⽂
対処
add monitor
add
monitor
<source> [parameter
<source>
からの⼊⼒をモニターします。
value] ...
edit monitor
edit
monitor
<source> [parameter
前に追加した
<source>
の⼊⼒を編集します。
前に追加した
<source>
の⼊⼒を削除します。
value] ...
remove
monitor
list
monitor
add
oneshot
remove monitor
<source>
list monitor
現在設定しているモニター⼊⼒を⼀覧表⽰します。
add oneshot
<source> ディレクトリを Splunk に直接コピーします。これによりファイルが 1
回アップロードされますが、継続的なモニターは⾏われません。
<source> [parameter
value] ...
重要： oneshot コマンドでは、再帰的フォルダやワイルドカードをソースとして使⽤
することはできません。このコマンドを使⽤する場合は、対象ファイルの正確な
27
spool
value] ...
ソースパスを指定してください。
spool <source>
<source> を Splunk に、sinkhole ディレクトリ経由でコピーします。このコマン
ドは add oneshot コマンドと似ていますが、即座に追加されるのではなく、
sinkhole ディレクトリからスプールされるという違いがあります。
追加のパラメータを設定して、各データ⼊⼒の設定を変更します。パラメータは次の構⽂で設定します：parameter value。
注意： コマンドあたり、1 つの
パラメータ
-hostname、-hostregex、または -hostsegmentnum
必
須？
を設定することができます。
説明
新しい⼊⼒をモニター/アップロードするための、ファイルまたはディレクトリへのパ
ス。
はい 注意： 他のパラメータと違い、このパラメータの構⽂は単純に値で、パラメータフラグ
が先頭に付けられることはありません。「<source>」であり、「-source <source>」ではあ
りません。
<source>
sourcetype
いい
⼊⼒ソースからのイベントの sourcetype フィールド値を指定します。
え
index
いい
⼊⼒ソースからのイベントの、宛先インデックスを指定します。
え
hostname
host
⼊⼒ソースからのイベントの、host フィールド値として設定するホスト名を指定しま
または いい す。
え
注意： これらは機能的に同等です。
hostregex
は
また
host_regex
hostsegmentnum
または
host_segment
rename-source
ソースキーから host フィールド値を抽出するために使⽤する、正規表現を指定しま
いい す。
え
注意： これらは機能的に同等です。
整数で、パスのどの「/」で区切られたセグメントを、host フィールドの値として設定
するのかを決定します。たとえば、3 を設定すると、パス内の 3 番⽬のセグメントが使
いい ⽤されます。
え
注意： これらは機能的に同等です。
いい
このファイルからのデータに適⽤する、「source」フィールドの値を指定します。
え
「true」または「false」を設定します。デフォルトは偽 (False) です。
follow-only
真 (True) を設定した場合、Splunk Enterprise はソースの末尾から読み込みます
いい (UNIX コマンドの「tail -f」と同様)。
え
注意： add oneshot に対してこのパラメータを使⽤することはできません。
例 1：ディレクトリ内のファイルのモニター
/var/log/
ディレクトリ内のファイルのモニター⽅法を以下の例に⽰します。
データ⼊⼒として
/var/log/
を追加します。
./splunk add monitor /var/log/
例 2：windowsupdate.log のモニター
Windows Update ログファイル (Windows ログは⾃動的に更新される) をモニターして、データをインデックス
「newindex」に保管する⽅法の例を以下に⽰します。
データ⼊⼒として
C:\Windows\windowsupdate.log
を追加します。
./splunk add monitor C:\Windows\windowsupdate.log -index newindex
例 3：IIS ロギングのモニター
Windows IIS ログのデフォルトの場所をモニターする⽅法を以下の例に⽰します。
28
データ⼊⼒として
C:\windows\system32\LogFiles\W3SVC
を追加します。
./splunk add monitor c:\windows\system32\LogFiles\W3SVC
例 4：ファイルのアップロード
Splunk にファイルをアップロードする⽅法を以下に⽰します。前の例と違い、Splunk Enterprise は 1 回だけ
データを取り込みます。継続的にモニターすることはありません。
add oneshot
コマンドで、/var/log/applog を直接 Splunk にアップロードします。
./splunk add oneshot /var/log/applog
spool
コマンドを使って、sinkhole ディレクトリ経由でファイルをアップロードすることもできます。
./splunk spool /var/log/applog
どちらのコマンドを使っても、結果は同じです。
inputs.conf の編集
⼊⼒を追加するには、$SPLUNK_HOME/etc/system/local/ にある inputs.conf、または $SPLUNK_HOME/etc/apps/ 内の独⾃
のカスタム App ディレクトリにある inputs.conf に、スタンザ を追加します。Splunk の設定ファイルで初めて
作業を⾏う場合は、事前に「設定ファイルについて」を参照してください。
⼊⼒スタンザには複数の属性を設定できます。属性の値を指定しない場合
は、$SPLUNK_HOME/etc/system/default/inputs.conf に定義されているデフォルト値が使⽤されます。
注意： 既存のファイルに新しいコンテンツをコピーして上書きした場合、新たなイベントのインデックスが作成
されるように、ソースの props.conf に CHECK_METHOD = modtime を設定してください。これにより、ファイルの変更
時刻がチェックされ、変更があった場合にインデックスが再作成されます。ファイル全体のインデックスが再作成
されるため、重複するイベントが発⽣する可能性があることに注意してください。
設定の指定
モニター (monitor) とバッチ (batch) には、個別のスタンザタイプが存在しています。モニターとバッチの詳細
は、「ファイルとディレクトリのモニター」を参照してください。
および batch の両⽅の⼊⼒スタンザで使⽤できる属性を以下に⽰します。各⼊⼒タイプ固有の属性につい
ては、後述するセクションを参照してください。
monitor
属性
host = <string>
index = <string>
sourcetype = <string>
説明
ホスト/キーフィールドに、このスタン
ザの静的な値を設定します。
ホストキーの初期値を設定します。この
キーは、パーシング/インデックス作成
時に使⽤されます (特に host フィール
ドの設定時)。サーチ時に使⽤される
host フィールドでもあります。
<string> の前には「host::」が付けられ
ます。
デフォルト
the IP address or
fully-qualified
domain name of the
host where the data
originated.
main またはデフォル
この⼊⼒からのイベントを保管するイン トインデックスに設
デックスを設定します。
定した任意の値
<string> の前には「index::」が付けられ
ます。
インデックスフィールドの詳細は、『イ
ンデクサーとクラスタの管理』マニュア
ルの「インデックス作成の仕組み」を参
照してください。
この⼊⼒からのイベントの sourcetype
キー/フィールドを設定します。
このデータのソースタイプを⾃動的に判
断する代わりに、明⽰的に宣⾔します。
このことは、パーシングおよびインデッ
クス作成中の、このタイプのデータに対
するサーチ可能性と関連するフォーマッ
トの適⽤の両⽅で重要になります。
ソースタイプキーの初期値を設定しま
す。このキーは、パーシング/インデッ
クス作成時に使⽤されます (特に host
29
データのさまざまな
側⾯に基づいてソー
スタイプが選択され
ます。ハードコード
化されたデフォルト
値はありません。
フィールドの設定時)。サーチ時に使⽤
される source type フィールドでもあり
ます。
<string> の前には「sourcetype::」が付
けられます。
ソースタイプの詳細は、このマニュアル
の「ソースタイプが重要な理由」を参照
してください。
queue = parsingQueue | indexQueue
_TCP_ROUTING =
<tcpout_group_name>,<tcpout_group_name>,...
host_regex = <regular expression>
host_segment = <integer>
parsingQueue
⼊⼒プロセッサが、読み込んだイベント
をデポジットするかどうかを指定しま
す。
データに props.conf および他のパーシン
グルールを適⽤する場合は、
「parsingQueue」を設定します。
データを直接インデックスに送信する場
合は、「indexQueue」を設定します。
tcpout グループ名のカンマ区切りリス
トを指定します。
この属性を使⽤して、フォワーダーが
データの転送時に使⽤する tcpout グ
ループを指定することで、データを特定
のインデクサーに選択的に転送すること
ができます。
tcpout グループ名は、outputs.conf の
[tcpout:<tcpout_group_name>] スタンザに
設定します。
この設定のデフォルトは、outputs.conf
の [tcpout] スタンザにある
「defaultGroup」に存在するグループ
になります。
指定した場合、正規表現は各⼊⼒のファ
イル名からホストを抽出します。
特に、最初の正規表現グループがホスト
として使⽤されます。
指定した場合、パスのセグメントがホス
トとして設定されます。セグメント
は、<integer> で判断されます。たとえ
ば、host_segment = 2 の場合、パスの 2
番⽬のセグメントがホストとして設定さ
れます。パスのセグメントは、「/」⽂
字により分割されます。
outputs.conf の
[tcpout] スタンザに
ある
「defaultGroup」
に存在するグルー
プ。
正規表現に⼀致しな
い場合は、デフォル
トの「host =」属性
が使⽤されます。
値が整数でない、ま
たは 1 未満の場合
は、デフォルトの
「host =」属性が使
⽤されます。
モニターの構⽂と例
⼊⼒のモニタースタンザは、<path> 内のすべてのファイル (または、単⼀のファイルを表している場合は <path> の
み) を監視するように Splunk Enterprise に指⽰しています。⼊⼒タイプを指定し、次にパスを指定します。root
ディレクトリから開始する場合はパスに 3 つのスラッシュを配置します。
パスにはワイルドカードを使⽤できます。詳細は、このマニュアルの「ワイルドカードを使った⼊⼒パスの指定」
を参照してください。
[monitor://<path>]
<attrbute1> = <val1>
<attrbute2> = <val2>
...
⼊⼒のモニタースタンザの定義時に使⽤できる、その他の属性を以下に⽰します。
属性
source =
<string>
説明
この⼊⼒からのイベントの source キー/フィールドを設定します。
注意： source キーに優先する設定を⾏うことは、⼀般的にお勧めできません。
通常⼊⼒レイヤーは、データの取得場所を正確に記録し、問題の分析と調査を⽀
援するために、より正確な⽂字列を提供しています。この値に優先する設定を⾏
う前に、ソースタイプ、タグ設定、およびワイルドカードを使ったサーチの使⽤
を検討してください。
30
デ
フォ
ルト
⼊⼒
ファ
イル
パス
<string>
の前には「source::」が付けられます。
N/A
crcSalt =
CRC (周期的冗⻑検査) が⼀致するファイルを取り込むように強制する場合、この
設定を使⽤します。(Splunk は CRC チェックを、ファイルの最初の数⾏に対し
てのみ実⾏します。この動作により、同じファイルのインデックスを 2 回作成す
ることを防⽌します (ログファイルのローテーションなどで、ファイル名を変更
した場合でも)。ただし、CRC はファイルの最初の数⾏のみを使⽤しているた
め、同じ CRC を持つ、異なるファイルが存在する可能性もあります (特に同じ
ヘッダーを保有している場合)。)
設定した場合、string が CRC に追加されます。
<SOURCE> を設定した場合、CRC にはソースのフルパスが追加されます。これによ
り、モニター対象の各ファイルに対して、⼀意の CRC が保証されます。
ローテーションされるログでこの属性を使⽤する場合、注意が必要です。ロー
テーションされた後に、ログファイルが再度インデックスされる可能性がありま
す。
注意： この設定では、⼤⽂字と⼩⽂字が区別されます。
<string>
0
変更時刻 (modtime) が <time window> 閾値を超えた場合に、モニターしている⼊
(無
⼒の、ファイル更新チェックを中⽌します。モニター対象ディレクトリ階層に⼤ 効)
量の履歴ファイルがある場合、これによりファイル追跡操作の速度が改善します
(たとえば、アクティブなログファイルが、もはや書き込まれない古いファイルと
共存している場合)。
注意： 初回モニター時に modtime が <time window> の範囲外のファイルのイン
デックスは作成されません。
次の値でなければなりません：<number><unit>。たとえば、「7d」は⼀週間を表し
ています。有効な単位は「d」 (⽇数)、「h」 (時間数)、「m」 (分数)、および
「s」 (秒) です。
ignoreOlderThan =
<time window>
0
followTail = 0|1
1 を設定した場合、ファイルの末尾からモニタリングが開始されます (*nix の
tail -f と同様)。
これは、ファイルを最初に取得する際にのみ適⽤されます。
その後、Splunk Enterprise は内部ファイル位置レコードを使って、ファイルを
追跡します。
N/A
whitelist =
設定した場合、指定した正規表現に⼀致する名前のファイルのみがモニターされ
ます。
<regular
expression>
N/A
blacklist =
設定した場合、指定した正規表現に⼀致する名前のファイルはモニターされませ
ん。
<regular
expression>
N/A
alwaysOpenFile =
1 を設定すると、Splunk Enterprise はファイルを開いてインデックスがすでに
作成されているかどうかを確認します。
modtime を更新しないファイルでのみ役⽴ちます。
Windows 上のファイルのモニターにのみ使⽤する必要があります (たいていは
IIS ログ)。
重要： 負荷が増加しインデックス作成のパフォーマンスが低下するため、このフ
ラグは最後の⼿段としてのみ使⽤してください。
0 | 1
true
recursive =
を設定すると、モニター対象ディレクトリ内に⾒つかったサブディレクトリ
は調査しません。
false
true|false
3
time_before_close
Splunk Enterprise が EOF でファイルを閉じるためには、Modtime の差分が必
要です。
過去 <integer> 秒内に更新されたファイルを閉じないようにシステムに指⽰しま
す。
= <integer>
true
followSymlink =
の場合、モニター対象ディレクトリ内に⾒つかったシンボリックリンクは無
視されます。
false
true|false
例 1： /apache/foo/logs または
/apache/bar/logs
内のすべてをロードします。
[monitor:///apache/.../logs]
例 2： /apache/ 内の
.log
で終了するものをすべてロードします。
31
[monitor:///apache/*.log]
MonitorNoHandle の構⽂と例
Windows システムでのみ、MonitorNoHandle スタンザを使って、Windows ファイルハンドルを利⽤せずに
ファイルをモニターすることができます。これにより、Windows の DNS サーバーログファイルなどの、特殊な
ログファイルを読み込むことができます。
MonitorNoHandle を使⽤する場合は、ファイルへの有効なパスを指定する必要があります。ディレクトリを指定
することはできません。すでに存在しているファイルを指定した場合、ファイル内の既存のデータのインデックス
は作成されません。システムが新たにファイルに書き込むデータのインデックスのみが作成されます。
monitorNoHandle
は、inputs.conf または CLI を使ってのみ設定できます。Splunk Web で設定することはできませ
ん。
[MonitorNoHandle://<path>]
<attrbute1> = <val1>
<attrbute2> = <val2>
...
バッチ (Batch) の構⽂と例
バッチ (batch) を使って、ソースからの 1 回限りのデータ取り込みを設定することができます。継続的なデータ
の取り込みには、monitor を使⽤します。バッチ⼊⼒のインデックスが作成されたら、ファイルは削除 されるこ
とに注意してください。
[batch://<path>]
move_policy = sinkhole
<attrbute1> = <val1>
<attrbute2> = <val2>
...
重要： バッチ⼊⼒の定義時には、属性 move_policy = sinkhole を含める必要があります。これにより、ファイルは
ロードされた後破棄されます。インデックス作成後に削除したくない場合は、バッチ⼊⼒を使⽤しないでくださ
い。
例： この例では、/system/flight815/ ディレクトリからすべてのファイルを読み込みますが、それ以下のサブディ
レクトリは対象にしません。
[batch://system/flight815/*]
move_policy = sinkhole
ワイルドカードを使った⼊⼒パスの指定
このトピックは、inputs.conf 内のパスへのワイルドカードの指定⽅法について説明しています。inputs.conf を
使って⼊⼒を指定する場合にのみ適⽤されます (このマニュアルの「inputs.conf の編集」を参照)。
重要 ：inputs.conf 内の⼊⼒パスの指定には、正規表現を使⽤せずに、Splunk が定義したワイルドカードを使⽤し
ます。
ワイルドカードの概要
ワイルドカードは、テキストのサーチ時または複数のファイルやディレクトリの選択時に、1 つまたは複数の⽂字
列を表す⽂字です。Splunk Enterprise では、ワイルドカードを使って⼊⼒をモニターする⼊⼒パスを指定するこ
とができます。
ワイ
ルド
カー
ド
同等
の正
規表
現
説明
例
/foo/.../bar.log
はファイル
/foo/1/bar.log、/foo/2/bar.log、/foo/1/2/bar.log
などに⼀致します。
省略記号ワイルドカードは、ディレクトリおよび
任意のレベルのサブディレクトリを対象に⼀致項
⽬を探します。
...
注意：ワイルドカードの後にフォルダ区切り⽂字
が指定されている場合 (//var/log/.../file)、最初
のフォルダ・レベルとは照合されず、サブフォル
ダとのみ照合されます。
32
次の項⽬とは⼀致しません：/foo/bar.log また
は /foo/3/notbar.log
.*
注意： 単⼀の省略記号ですべてのディレクトリ
とサブディレクトリを調査するた
め、/foo/.../bar.log の⼀致項⽬と
/foo/.../.../bar.log の⼀致項⽬は同じになりま
す。
は、/foo/bar、/foo/1/bar、/foo/2/bar
などに⼀致します。ただし、/foo/1/2/bar には
⼀致しません。
/foo/*/bar
アスタリスクは、そのディレクトリパスセグメン
トのすべての項⽬に⼀致します。
*
「...」と違い、「*」はサブディレクトリを対象
にしません。
/foo/m*r/bar
[^/]*
は、/foo/mr/bar、/foo/mir/bar、/foo/moor/bar な
どに⼀致します。
は、拡張⼦が .log のすべてのファイ
ルに⼀致します (/foo/bar.log な
ど)。/foo/bar.txt または /foo/bar/test.log には
⼀致しません。
/foo/*.log
注意： 単⼀のドット (.) はワイルドカードではありません。正規表現の
\.
と同じ意味を持ちます。
より細かく⼀致項⽬を指定するには、... と * を組み合わせて使⽤します。たとえば、/foo/.../bar/* は指定パス
内の /bar ディレクトリ内の任意のファイルに⼀致します。
ワイルドカードと正規表現メタ⽂字
モニター対象の⼀連のファイルやディレクトリを判断する際に、Splunk Enterprise はモニター⽤スタンザのエレ
メントをセグメント (スタンザ定義内のディレクトリ区切り⽂字 (/ または \) 間の⽂字列) に分割します。ワイル
ドカードと正規表現メタ⽂字 ((, ), [, ] や | など) の両⽅のセグメントを含むモニター⽤スタンザを指定した場
合、それらの⽂字に対する処理はスタンザ内のワイルドカードの位置によって異なります。
モニター⽤スタンザで、正規表現メタ⽂字を持つセグメントがワイルドカードを持つセグメントの前に ある場
合、Splunk Enterprise はメタ⽂字を⽂字通りに解釈します (ファイル名やディレクトリ名にそれらの⽂字が使わ
れているものをモニターする)。例：
[monitor://var/log/log(a|b).log]
この場合、/var/log/log(a|b).log ファイルがモニターされます。ワイルドカードが存在しないため、Splunk
Enterprise は (a|b) を正規表現とみなしません。
[monitor://var/log()/log*.log]
この場合、/var/log()/ ディレクトリ内の、log で始まり、拡張⼦ .log を持つすべてのファイルがモニターされま
す。正規表現がワイルドカードよりも前の セグメントにあるため、Splunk Enterprise は () を正規表現としては
取り扱いません。
正規表現がワイルドカードを持つセグメント内 またはそれよりも後 にある場合、Splunk Enterprise はメタ⽂字を
正規表現として取り扱い、それに⼀致するファイルがモニターされます。例：
[monitor://var/log()/log(a|b)*.log]
この場合、/var/log()/ ディレクトリ内の、loga または logb で始まり、拡張⼦ .log を持つすべてのファイルがモニ
ターされます。最初の () は、その後のセグメントにワイルドカードがあるため正規表現としては取り扱われませ
ん。2 番⽬の () は、同じセグメント内にワイルドカード「*」があるため、正規表現として取り扱われます。
[monitor://var/.../log(a|b).log]
ディレクトリの任意のサブディレクトリ内にある、名前が loga.log および logb.log のすべてのファイルをモ
ニターします。前のスタンザセグメントにワイルドカード「...」があるため、(a|b) は正規表現として取り扱われ
ます。
/var/
[monitor://var/.../log[A-Z0-9]*.log]
/var/
ディレクトリの任意のサブディレクトリ内にある、以下の条件を満たすすべてのファイルをモニターしま
す。
で始まり、次に
単⼀の⼤⽂字 (A〜Z) または数字 (0〜9) を含み、次に
他の任意の⽂字を含み、次に
.log で終了する。
log
前のスタンザセグメントにワイルドカード「...」があるため、[A-Z0-9]* は正規表現として取り扱われます。
⼊⼒例
/apache/foo/logs、/apache/bar/logs、/apache/bar/1/logs
などをモニターするには：
33
[monitor:///apache/.../logs/*]
/apache/foo/logs、/apache/bar/logs
などをモニターするけれども、/apache/bar/1/logs または
/apache/bar/2/logs
をモ
ニターしない場合：
[monitor:///apache/*/logs]
/apache/
ディレクトリ下の
.log
で終了するファイルをモニターするには：
[monitor:///apache/*.log]
/apache/
下の
.log
で終了する任意のファイルをモニターするには (任意のレベルのサブディレクトリを含む)：
[monitor:///apache/.../*.log]
「...」の後にフォルダ区切り⽂字を指定すると、ワイルドカード・レベルのフォルダは除外されます。
[monitor:///var/log/.../*.log]
テーリング・ロジックは次のようになります：
'^\/var\/log/.*/[^/]*\.log$'
そのため、/var/log/subfolder/test.log は⼀致しますが、/var/log/test.log は⼀致せず除外されます。すべての
フォルダのすべてのファイルをモニターするには、次のように指定します：
[monitor:///var/log/]
whitelist=\.log$
recurse=true
#true by default
ワイルドカードとホワイトリスト
重要： Splunk Enterprise でホワイトリストとブラックリストは、標準の Perl 互換正規表現 (PCRE) を使って定
義します。前のセクションで説明したファイル⼊⼒パスの構⽂とは異なります。
ファイル⼊⼒パスにワイルドカードを指定する場合、Splunk Enterprise はそのスタンザに対する暗黙の
whitelist を作成します。もっとも⻑いワイルドカードがないパスがモニター⽤スタンザになり、前述の表のよう
にワイルドカードが正規表現に変換されます。
また、変換された正規表現は、パス全体が照合されるように、ファイルパスの右終端にアンカーされます。
たとえば、以下のように指定すると
[monitor:///foo/bar*.log]
Splunk Enterprise はこれを以下のように変換します。
[monitor:///foo/]
whitelist = bar[^/]*\.log$
Windows で、以下のように指定すると
[monitor://C:\Windows\foo\bar*.log]
Splunk Enterprise はこれを以下のように変換します。
[monitor://C:\Windows\foo\]
whitelist = bar[^/]*\.log$
注意： Windows で whitelist と blacklist ルールは、円記号 (バックスラッシュ) を含む正規表現をサポートして
いません。2 つの円記号 \\ を使って、ワイルドカードをエスケープ処理する必要があります。
ファイル⼊⼒でのホワイトリストの使⽤については、「ホワイトリストまたはブラックリスト固有の到着データ」
を参照してください。
ホワイトリストまたはブラックリスト固有の到着データ
ディレクトリをモニター する場合、ホワイトリスト およびブラックリスト ルールを使って、データを取り込む
ファイルを明⽰的に指⽰することができます。また、batch ⼊⼒にこれらの設定を適⽤することもできます。ホワ
34
イトリスト を定義する場合、Splunk Enterprise はそのリストに指定されているファイルのみ インデックスを作
成します。ブラックリスト を定義する場合、Splunk Enterprise はリストに指定されているファイルを無視し
て、残りすべてのインデックスを作成します。ホワイトリストとブラックリストは、inputs.conf 内の特定の⼊⼒
スタンザに定義します。
ホワイトリストとブラックリストの両⽅を定義する必要はありません。それぞれを個別に設定することができま
す。両⽅のリストを定義して、あるファイルがその両⽅に⼀致する場合、そのファイルのインデックスは作成され
ません。blacklist が whitelist よりも優先されます。
ホワイトリストとブラックリストのルールは正規表現構⽂を使って、照合するファイル名/パスを定義します。こ
のルールは、[monitor://<path>] などの設定スタンザ内に指定する必要があります。スタンザ外にホワイトリスト/
ブラックリストを指定しても、それは無視されます。
正規表現の作成⽅法の詳細は、正規表現情報 (http://regular-expressions.info) Web サイトを参照してくださ
い。
重要： ホワイトリスト/ブラックリストの項⽬は、正しい正規表現の構⽂で定義してください。⼊⼒パスへのワ
イルドカード「...」の使⽤ ( ここ で説明) はサポートされていません。
ホワイトリスト/ブラックリストを使⽤する代わりにデータをルーティング/フィルタリン
グする
データ⼊⼒にホワイトリスト/ブラックリストを指定する代わりに、特定のイベントをフィルタリングして、別の
キューやインデックスに送信することができます。データのルーティングやフィルタリングに関する記事を参照し
てください。クロール (crawl) 機能を使って、ファイルシステムに追加されたファイルのインデックスを作成す
る、または作成しないファイルを事前定義することもできます。
ホワイトリスト (許可) ファイル
Splunk Enterprise にインデックスを作成させるファイルを定義するには、その⼊⼒が定義されている App
の 、/local/inputs.conf ファイルの monitor スタンザに以下の⾏を追加します。
whitelist = <your_custom regex>
たとえば、拡張⼦
.log
を持つファイルのみをモニターする場合：
[monitor:///mnt/logs]
whitelist = \.log$
ホワイトリストで「|」 (OR) 演算⼦を使って、複数のファイルを 1 ⾏に指定することができます。たとえ
ば、query.log OR my.log を含むファイル名をホワイトリストに定義するには：
whitelist = query\.log$|my\.log$
または、ホワイトリストに完全⼀致を指定するには：
whitelist = /query\.log$|/my\.log$
注意： 「$」は、正規表現を⾏の終端にアンカーします。「|」演算⼦の前後にスペースはありません。
ホワイトリストでの⼊⼒パス内のワイルドカードの取り扱いについては、「ワイルドカードとホワイトリスト」を
参照してください。
ブラックリスト (無視) ファイル
インデックス作成から除外するファイルを定義するには、その⼊⼒が定義されている App
の 、/local/inputs.conf ファイルの monitor スタンザに以下の⾏を追加します。
blacklist = <your_custom regex>
重要： 無視する各ファイルに対して
拡張⼦
.txt
blacklist
⾏を作成すると、Splunk は最後のフィルタのみを適⽤します。
を持つファイルのみを無視してモニターの対象外にするには：
[monitor:///mnt/logs]
blacklist = \.(txt)$
拡張⼦ .txt または (OR)
使⽤します)：
.gz
を持つすべてのファイルを無視してモニターの対象外にするには (この場合、「|」を
[monitor:///mnt/logs]
blacklist = \.(txt|gz)$
35
モニター⼊⼒下のディレクトリ全体を無視するには：
[monitor:///mnt/logs]
blacklist = (archive|historical|\.bak$)
上記の例は、アーカイブまたは履歴ディレクトリ内の /mnt/logs/ 下のすべてのファイル、および *.bak で終わる
すべてのファイルを無視するように、Splunk に指⽰しています。
名前に特定の⽂字列を含むファイルを無視する場合：
[monitor:///mnt/logs]
blacklist = 2009022[8|9]file\.txt$
上記の例は、/mnt/logs/ 下の
webserver20090228file.txt
と
webserver20090229file.txt
を無視します。
Splunk Enterprise によるログファイルのローテーションの取り扱い
Splunk Enterprise はモニターしているファイル (/var/log/messages など) がオペレーティングシステムによりロー
テーション (/var/log/messages1) されると、そのことを認識し、そのローテーションにより名前が変更されたファ
イルは読み込みません。
圧縮ファイルへのログローテーションへの対処⽅法
Splunk Enterprise は logrotate コマンドにより⽣成された圧縮ファイル (bz2 や gz など) が、圧縮前のオリジナル
ファイルと同じであることを認識できません。そのため、それらのファイルがモニター対象になる場合、データの
重複が発⽣する可能性があります。
この問題を回避するには、2 種類の⽅法があります。
そのようなファイルを、Splunk Enterprise がモニターしていないディレクトリに移動するように、ログの
ローテーションを設定する。
アーカイブのファイルタイプに対してブラックリスト ルールを設定して、それらのファイルが新たなログ
ファイルとして読み込まれないようにする。例：
[monitor:///var/log]
blacklist = \.(gz|bz2|z|zip)$
Splunk Enterprise は、次のアーカイブファイルタイプを認識します：tar,
および z。
gz, bz2, tar.gz, tgz, tbz, tbz2, zip、
ブラックリストルールの設定の詳細は、このマニュアルの「ホワイトリストまたはブラックリスト固有の到着デー
タ」を参照してください。
これに関連して、.gz ファイルなどの既存の圧縮形式アーカイブファイルに新しくデータを追加した場合、その新
たなデータだけではなく、ファイル内のすべてのデータのインデックスが再作成されるという問題があります。そ
のため、イベントの重複が発⽣する可能性があります。
Splunk Enterprise がログのローテーションを認識する仕組み
モニタリングプロセッサは新しいファイルを選んで、ファイルの先頭 256 バイトを読み取ります。次にこのデー
タが開始/終了周期的冗⻑検査 (CRC) にハッシュ化されます。これが、ファイルの内容を表す指紋としての役割を
果たします。Splunk Enterprise はこの CRC を使って、以前に確認したファイルの開始 CRC を保管している、
データベース内のエントリをルックアップします。ルックアップが成功すると、いくつかの値が返されます。この
中で重要なのが、Splunk Enterprise が既知のファイルですでに読み込んでいるバイト数を⽰す、seekAddress
です。また、その場所のデータの指紋を⽰す seekCRC も重要です。
このルックアップの結果を使って、Splunk Enterprise はファイルを判断、分類します。
CRC チェックの結果は 3 種類考えられます。
1. データベース内にファイルの先頭の CRC と⼀致するレコードがない。このことは、新しいファイルであること
を意味しています。Splunk Enterprise はそのファイルの先頭からデータを取り込みます。Splunk Enterprise
は、ファイルを取り込むにつれて、新しい CRC と SeekAddresseでデータベースを更新します。
2. データベース内にファイルの先頭からの CRC が⼀致するレコードがあり、ファイルの SeekAddress の場所が
保管されている CRC の場所と⼀致し、ファイルのサイズが保管されている SeekAddress よりも⼤きい。これ
は、以前に Splunk Enterprise がファイルを処理したことがあるけれども、最後の読み込み以降にデータが追加
されたことを意味しています。Splunk Enterprise はファイルを開いて最後にファイルを読み込んだ終端となる
SeekAddress に移動して、そこからデータの読み込みを開始します。このようにして、新しいデータのみを読み
込んで、以前に読み込んだデータの再読み込みを防⽌することができます。
3. データベース内にファイルの開始 CRC に⼀致するレコードがあるけれども、SeekAddress の場所が、ファイ
ルの CRC の場所と⼀致しない。これは、Splunk Enterprise が以前に同じ開始データを持つファイルを読み込ん
だことがあるけれども、それまでに読み込んだ内容の⼀部が変更されたか、または同じ内容から始まるまったく別
なファイルであることを表しています。コンテンツ追跡⽤の Splunk データベースは開始 CRC を使⽤しているた
36
め、これらの 2 種類の異なるデータストリームの状況を個別に追跡する⼿段はありません。さらなる詳細な設定
が必要です。
重要： CRC 開始チェックはデフォルトで、ファイルの最初の 256 バイトに対してのみ⾏われるため、異なる
ファイルが同じ開始 CRC になる可能性があります (特にそれらのファイルのヘッダーが同じである場合など)。こ
のような問題に対処するには：
の initCrcLength 属性を使って CRC の算出に使⽤する⽂字数を増やす (上記の例では、同じヘッ
ダーの⻑さより⼤きな値に増やす)。
inputs.conf にファイルを設定する際に、crcSalt 属性を使⽤する (このマニュアルの「inputs.conf の編集」
を参照)。crcSalt 属性に <SOURCE> を設定すると、各ファイルが⼀意の CRC を持つことが保証されます。こ
の設定を使⽤すると、各パス名が⼀意のコンテンツを保有すると仮定されます。
inputs.conf
重要： ローリング・ログ・ファイル、またはログ・ファイルが他の名前に変更される状況や、ファイルが他のモ
ニター対象ディレクトリに移動されるような状況では、crcSalt = <SOURCE> を使⽤しない ことをお勧めします。使
⽤すると Splunk Enterprise が名前が変更されたまたは更新されたログを認識できず、同じデータのインデック
スが再度作成されてしまいます。
ネットワーク・イベントの取得
TCP および UDP ポートからのデータの取り込み
任意の TCP または UDP ポートからのデータを取り込むように、Splunk Enterprise を設定することができま
す。Splunk Enterprise はこれらのポートに送信されるデータを取り込むことができます。syslog (デフォルトの
ポートは UDP 514) などのネットワークサービスからのデータを取り込む場合に、この⽅法を使⽤します。
netcat サービスを設定して、それをポートにバインドすることもできます。
TCP は、Splunk Enterprise のデータ配布に使⽤されるネットワークプロトコルで、リモートマシンから Splunk
Enterprise サーバーにデータを送信する場合の推奨⼿段でもあります。Splunk Enterprise は syslog-ng や他の
TCP 経由でデータを伝送するアプリケーションからの、リモートデータのインデックスを作成することができま
す。
Splunk Enterprise は UDP のモニタリングもサポートしていますが、可能な場合は TCP を使⽤することをお勧
めします。⼀般的に UDP は、他にもさまざまな理由がありますが、特に配信が保証されないという点で、伝送⼿
段としては望ましくありません。
UDP を使⽤する必要がある場合は、Splunk コミュニティ Wiki の「Working with UDP connections」を参照し
てください。
Splunk Web を使ったネットワーク⼊⼒の追加
Splunk Web を使ってネットワーク・ポートからの⼊⼒を追加する⽅法については、このマニュアルの「Syslog TCP/UDP」を参照してください。
CLI を使ったネットワーク⼊⼒の追加
Splunk Enterprise の CLI を使⽤するには、$SPLUNK_HOME/bin/ ディレクトリに移動して、./splunk コマンドを使⽤
します。
何か分からないことがある場合、CLI にはヘルプが⽤意されています。CLI メインヘルプにアクセスするに
は、splunk help と⼊⼒します。各コマンドには、それぞれ独⾃のヘルプページが⽤意されています。splunk help
<command> と⼊⼒してください。
ネットワーク⼊⼒の設定には、以下の CLI コマンドを使⽤できます。
コマンド
コマンドの構⽂
アクション
からの⼊⼒を追加します。
add
add tcp|udp <port> [-parameter value] ...
<port>
edit
edit tcp|udp <port> [-parameter value] ...
前に追加した
remove
remove tcp|udp <port>
前に追加したデータ⼊⼒を削除します。
list
list tcp|udp [<port>]
現在設定しているモニター⼊⼒を⼀覧表⽰します。
<port>
の⼊⼒を編集します。
は、データを待ち受けるポート番号です。Splunk を実⾏するユーザーには、このポートへのアクセス権が
必要です。
<port>
以下のような追加パラメータを指定して、各⼊⼒の設定を変更することができます。
パラメータ
必
須？
説明
sourcetype
いい
⼊⼒ソースからのイベントの sourcetype フィールド値を指定します。
え
index
いい
⼊⼒ソースからのイベントの、宛先インデックスを指定します。
え
いい
37
hostname
いい
⼊⼒ソースからのイベントの、host フィールド値として設定するホスト名を指定します。
え
remotehost
いい
排他的にデータを受け付ける IP アドレスを指定します。
え
resolvehost
True または False (T | F) を設定します。デフォルトは False です。⼊⼒ソースからのイ
いい
ベントに対して、DNS を使ってホストフィールドの値を設定する場合、True を設定しま
え
す。
restrictToHost
いい
この⼊⼒が唯⼀接続を受け付ける、ホスト名または IP アドレスを指定します。
え
例
UDP ⼊⼒がポート 514 で待機して、ソースタイプに「syslog」を設定するように指定します。
./splunk add udp 514 -sourcetype syslog
DNS を介して UDP ⼊⼒のホスト値を設定します。auth にユーザー名とパスワードを指定します。
./splunk edit udp 514 -resolvehost true -auth admin:changeme
syslog ⼊⼒設定時の UDP 使⽤のベストプラクティスについては、Best Practices Wiki を参照してください。
TCP ネットワーク⼊⼒の制限されているホストの変更
TCP ⼊⼒の作成時に、特定のホストからの接続のみを受け付けるように設定してその⼊⼒を保存すると、後ほど
Splunk Web または CLI を使ってそのホストを変更、削除することはできません。
ポートの制限されているホストを変更または削除するには、まずその制限されているホストを指定している⼊⼒を
削除する必要があります。次に、新しい制限ホストを指定、または制限なしで、新しい⼊⼒を作成する必要があり
ます。
inputs.conf を使ったネットワーク⼊⼒の追加
⼊⼒を追加するには、$SPLUNK_HOME/etc/system/local/ にある inputs.conf、または $SPLUNK_HOME/etc/apps/ 内の独⾃
のカスタム App ディレクトリにある inputs.conf に、スタンザを追加します。Splunk の設定ファイルで初めて
作業を⾏う場合は、事前に『管理マニュアル』の「設定ファイルについて」を参照してください。
⼊⼒タイプに続いて、任意の数の属性と値を指定することができます。属性に値を指定しない場
合、$SPLUNK_HOME/etc/system/default/ (後述) に事前定義されているデフォルト値が使⽤されます。
TCP
[tcp://<remote server>:<port>]
<attrbute1> = <val1>
<attrbute2> = <val2>
...
このタイプの⼊⼒スタンザは、<port> (ポート) で <remote server> (リモートサーバー) を待機するように
Splunk Enterprise に指⽰します。<remote server> に何も指定しない場合、Splunk は指定ポート上ですべての接
続を待機します。
注意： Splunk Enterprise を実⾏するユーザーには、待機ポートへのアクセス権が必要です。*nix システムで
は、1024 未満のポートで待ち受ける場合、root として実⾏する必要があります。
属性
host = <string>
index =
<string>
sourcetype =
<string>
説明
デフォルト
ホスト/キーフィールドに、このスタンザの静的な値を設定しま
す。
ホストキーの初期値を設定します。このキーは、パーシング/イ
ンデックス作成時に使⽤されます (特に host フィールドの設定
時)。サーチ時に使⽤される host フィールドでもあります。
<string> の前には「host::」が付けられます。
the IP address or
fully-qualified domain
name of the host where
the data originated.
main またはデフォルト
この⼊⼒からのイベントを保管するインデックスを設定します。 インデックスに設定し
<string> の前には「index::」が付けられます。
た任意の値
インデックスフィールドの詳細は、『インデクサーとクラスタの
管理』マニュアルの「インデックス作成の仕組み」を参照してく
ださい。
この⼊⼒からのイベントの sourcetype キー/フィールドを設定
38
データのさまざまな側
⾯に基づいてソースタ
<string>
します。
このデータのソースタイプを⾃動的に判断する代わりに、明⽰的
に宣⾔します。このことは、パーシングおよびインデックス作成
中の、このタイプのデータに対するサーチ可能性と関連する
フォーマットの適⽤の両⽅で重要になります。
ソースタイプキーの初期値を設定します。このキーは、パーシン
グ/インデックス作成時に使⽤されます (特に host フィールドの
設定時)。サーチ時に使⽤される source type フィールドでもあ
ります。
<string> の前には「sourcetype::」が付けられます。
ソースタイプの詳細は、このマニュアルの「ソースタイプが重要
な理由」を参照してください。
イプが選択されます。
ハードコード化された
デフォルト値はありま
せん。
⼊⼒ファイルパス
source =
この⼊⼒からのイベントの source キー/フィールドを設定しま
す。
注意： source キーに優先する設定を⾏うことは、⼀般的にお勧
めできません。通常⼊⼒レイヤーは、データの取得場所を正確に
記録し、問題の分析と調査を⽀援するために、より正確な⽂字列
を提供しています。この値に優先する設定を⾏う前に、ソースタ
イプ、タグ設定、およびワイルドカードを使ったサーチの使⽤を
検討してください。
<string> の前には「source::」が付けられます。
<string>
parsingQueue
queue =
parsingQueue |
indexQueue
connection_host
= ip | dns |
none
⼊⼒プロセッサが、読み込んだイベントをデポジットするかどう
かを指定します。
データに props.conf および他のパーシングルールを適⽤する場合
は、「parsingQueue」を設定します。
データを直接インデックスに送信する場合は、「indexQueue」
を設定します。
ip
「ip」は、ホストにリモートサーバーの IP アドレスを設定しま
す。
「dns」は、ホストにリモートサーバーの DNS エントリを設定
します。
「none」は、ホストを指定通りのまま放置します。
TCP over SSL
[tcp-ssl:<port>]
暗号化された未パーシングデータを、フォワーダーまたはサードパーティ製のシステムから受信する場合にこのス
タンザを使⽤します。<port> には、暗号化された未パーシングデータを送信する、フォワーダーまたはサードパー
ティ製システムのポートを設定します。
UDP
[udp://<remote server>:<port>]
<attrbute1> = <val1>
<attrbute2> = <val2>
...
このタイプの⼊⼒スタンザは TCP の場合と似ていますが、UDP ポートで待機するという違いがあります。
注意：
<remote server>
<remote server>
を指定した場合、指定したポートはそのサーバーからのデータのみを受け付けます。
が空の場合、ポート [udp://<port>] は任意のサーバーから送信されたデータを受け付けま
す。
属性
host = <string>
index = <string>
説明
ホスト/キーフィールドに、このスタンザの静的な値
を設定します。
ホストキーの初期値を設定します。このキーは、パー
シング/インデックス作成時に使⽤されます (特に
host フィールドの設定時)。サーチ時に使⽤される
host フィールドでもあります。
<string> の前には「host::」が付けられます。
この⼊⼒からのイベントを保管するインデックスを設
39
デフォルト
the IP address or fullyqualified domain name of
the host where the data
originated.
またはデフォルトイン
デックスに設定した任意の
main
定します。
<string> の前には「index::」が付けられます。
インデックスフィールドの詳細は、『インデクサーと
クラスタの管理』マニュアルの「インデックス作成の
仕組み」を参照してください。
sourcetype = <string>
source = <string>
queue = parsingQueue |
indexQueue
_rcvbuf = <integer>
no_priority_stripping
= true | false
no_appending_timestamp
= true | false
この⼊⼒からのイベントの sourcetype キー/フィー
ルドを設定します。
このデータのソースタイプを⾃動的に判断する代わり
に、明⽰的に宣⾔します。このことは、パーシングお
よびインデックス作成中の、このタイプのデータに対
するサーチ可能性と関連するフォーマットの適⽤の両
⽅で重要になります。
ソースタイプキーの初期値を設定します。このキー
は、パーシング/インデックス作成時に使⽤されます
(特に host フィールドの設定時)。サーチ時に使⽤さ
れる source type フィールドでもあります。
<string> の前には「sourcetype::」が付けられます。
ソースタイプの詳細は、このマニュアルの「ソースタ
イプが重要な理由」を参照してください。
デックスに設定した任意の
値
データのさまざまな側⾯に
基づいてソースタイプが選
択されます。ハードコード
化されたデフォルト値はあ
りません。
⼊⼒ファイルパス
この⼊⼒からのイベントの source キー/フィールドを
設定します。
注意： source キーに優先する設定を⾏うことは、⼀
般的にお勧めできません。通常⼊⼒レイヤーは、デー
タの取得場所を正確に記録し、問題の分析と調査を⽀
援するために、より正確な⽂字列を提供しています。
この値に優先する設定を⾏う前に、ソースタイプ、タ
グ設定、およびワイルドカードを使ったサーチの使⽤
を検討してください。
<string> の前には「source::」が付けられます。
parsingQueue
⼊⼒プロセッサが、読み込んだイベントをデポジット
するかどうかを指定します。
データに props.conf および他のパーシングルールを適
⽤する場合は、「parsingQueue」を設定します。
データを直接インデックスに送信する場合は、
「indexQueue」を設定します。
UDP ポートの受信バッファ (バイト) を指定します。
値が 0 または負の場合、それは無視されます。
1,572,864 - ただし OS に
対してデフォルト値が⼤き
すぎる場合、バッファサイ
ズが許容できるレベルにな
るまで、このデフォルト値
が順次半減されていきま
す。
偽 (False) (Splunk
syslog データ受信⽤設定。
Enterprise は <priority>
この属性に 真 (True) を設定すると、受信したイベン を削除します。)
トから <priority> syslog フィールドは除去されませ
ん。
この属性に応じて、イベントのタイムスタンプには異
なる設定が⾏われます。
真 (True) を設定した場合、ソースから取得され
たタイムスタンプがそのまま使⽤されます。
偽 (False) を設定した場合、イベントにはロー
カル時刻が割り当てられます。
false
この属性に真 (True) を設定した場合、受信イベント
にタイムスタンプとホストは追加されません。
注意： 受信したイベントにタイムスタンプとホストを
追加したい場合は、この属性を指定しないでくださ
い。
UDP パケットと⾏の結合
各 UDP パケットが個別のイベントとして、インデックスが作成されるとお考えかもしれません。しかし、そのよ
うにはなりません。明確なタイムスタンプがない場合、Splunk Enterprise はデータストリームのイベントの結合
を実⾏し、各イベントが結合されます。
1 ⾏のイベントの場合、props.conf でそのソースタイプを編集して、SHOULD_LINEMERGE 属性に false に設定すること
で、この問題を防⽌することができます。それにより、パケットの結合を防⽌することができます。
Answers
40
何か質問がありますか？Splunk Answers をご覧ください。ここには、Splunk コミュニティに寄せられた UDP
⼊⼒、TCP ⼊⼒、および他の⼊⼒に関する質問と回答が記載されています。
Splunk Enterprise への SNMP イベントの送信
重要
このトピックに記載されている⼿順は (*nix と Windows の両⽅) 、単なる例です。Splunk Enterprise に
SNMP を送信する⽅法は⼿順は他にも存在しています。たとえば、Net-SNMP の代わりに Snare や
SNMPGate などのツールを使って、Splunk Enterprise でモニターする SNMP トラップをファイルストレージ
に書き込むことができます。
SNMP トラップは、リモートデバイスが⽣成するアラートです。このトピックは、Splunk インデクサーでの
SNMP トラップの受信とインデクサーの作成⽅法について説明しています。
注意： Network Management System コンソールなどの、他のシステムに SNMP アラートを送信するためのモ
ニタリングツールとして Splunk Enterprise を使⽤する⽅法については、『管理マニュアル』の「他のシステム
への SNMP トラップの送信」を参照してください。
SNMP トラップのインデックス作成⽅法
SNMP トラップのインデックスを作成するもっとも効率的な⽅法は、まず SNMP トラップを Splunk Enterprise
サーバー上のファイルに書き込むことです。次に、Splunk Enterprise がそのファイルをモニターするように設定
します。
この作業は 3 つのステップから成り⽴っています。
1. リモートデバイスがトラップを、Splunk サーバーの IP アドレスに直接送信するように設定します。SNMP ト
ラップのデフォルトポートは udp:162 です。
2. このトピックで後述するように、SNMP トラップを Splunk サーバー上のファイルに書き込みます。
3. 「ファイルとディレクトリのモニター」の説明に従って、ファイルをモニターするように Splunk を設定しま
す。
注意： このトピックでは、リモートデバイスにポーリングを⾏う SNMP ポーリングについては説明していませ
ん。
SNMP トラップの Splunk サーバー上のファイルへの書き込み
重要： 以下の⼿順は (*nix と Windows の両⽅) 、単なる例です。Splunk Enterprise に SNMP を送信する⽅法は
⼿順は他にも存在しています。たとえば、Net-SNMP の代わりに Snare や SNMPGate などのツールを使って、
Splunk Enterprise でモニターする SNMP トラップをファイルストレージに書き込むことができます。
SNMP ソフトウェアの詳細は、SNMP ポータル (http://www.snmplink.org) Web サイトを参照してください。
*nix の場合
*nix 上では、Net-SNMP プロジェクトの
システムに
snmptrapd
snmptrapd
を使って、ファイルに SNMP トラップを書き込めます。
をインストールする前に、以下のドキュメントを参照してください。
ご利⽤のディストリビューションのツールパッケージ (使⽤している *nix ディストリビューションによって
異なります。たとえば、Red Hat または CentOS Linux の場合、net-snmp RPM パッケージを利⽤できま
す。利⽤できるインストーラパッケージがない場合、ソースファイルからパッケージをビルドしなければな
らないことがあります) ⽤のローカルドキュメント。
snmptrapd の man ページ。
もっとも単純な設定：
# snmptrapd -Lf /var/log/snmp-traps
注意： 従来、snmptrapd はすべての着信通知を受け付け、それを⾃動的にログに記録していました (明⽰的に設定
されていない場合でも)。snmptrapd リリース 5.3 (snmptrapd --version で確認) から、すべての着信通知にアクセス
制御チェックが適⽤されるようになりました。適切なアクセス制御設定を⾏わずに snmptrapd を実⾏すると、その
ようなトラップが処理されることはありません 。これを回避するには、以下のように指定します。
# snmptrapd -Lf /var/log/snmp-traps --disableAuthorization=yes
トラブルシューティング：
デフォルトのポート 162 で待機する場合、このポートは権限が必要なポートなので、snmptrapd を root とし
て実⾏する必要があります。
テスト中に snmptrapd をフォアグラウンドで実⾏させるためには、-f フラグを指定します。標準出⼒に記録
する場合は、-Lf の代わりに -Lo を使⽤します。
snmptrapd コマンドを使って、以下のようにサンプルトラップを⽣成することができます。
41
# snmptrap -v2c -c public localhost 1 1
Windows の場合
SNMP トラップを Windows 上のファイルに記録するには：
1. Net-SNMP Web サイトから Windows 版の
NET-SNMP
をダウンロード、インストールします。
重要： ご利⽤のシステムで利⽤できる、最新版のファイルをダウンロード、インストールしてください。また、
システム上に OpenSSL バージョン 1.0 以降がインストールされていないことを確認してください。
2. NET-SNMP に含まれているスクリプトを使って、snmptrapd をサービスとして登録します。
3. C:\usr\etc\snmp\snmptrapd.conf を編集します。
snmpTrapdAddr [System IP]:162
authCommunity log [community string]
4. ログの場所のデフォルトは、次の場所になります：
C:\usr\log\snmptrapd.log
管理情報ベース (MIB) の使⽤
管理情報ベース (MIB) は、SNMP トラップが報告した数値オブジェクト ID (OID) とユーザーが理解できる形式
のテキスト間のマップを提供しています。snmptrapd は MIB ファイルがなくても動作できますが、各結果を完全に
同じ⽅法では表⽰できません。
SNMP トラップを送信するデバイスのメーカーが、特定の MIB を提供している場合があります。たとえば、すべ
ての Cisco デバイスの MIB を、オンラインの Cisco SNMP Object Navigator を使って検索することができま
す。
新しい MIB ファイルを追加するには、2 ステップの作業を⾏う必要があります。
1. MIB ファイルをダウンロードして、MIB 検索ディレクトリにコピーします。*nix 版の Net-SNMP の場合、デ
フォルトの場所は /usr/local/share/snmp/mibs ですが、snmptrapd に引数 -m を指定して、別のディレクトリを設定す
ることもできます。
2. -m 引数にコロンで区切ったリストを指定することで、snmptrapd に MIB のロードを指⽰します。ここで 2 つの
重要な情報があります。
先頭に「+」を追加すると、デフォルトのリストを上書きする代わりに、デフォルトリストに加えて MIB を
ロードします。
特殊キーワード ALL は、snmptrapd に MIB ディレクトリ内のすべての MIB モジュールをロードすることを指
⽰します。
もっとも安全な引数は、次のようになります：-m
+ALL：
snmptrapd -m +ALL
Windows データの取得
Windows データと Splunk Enterprise について
さまざまな種類の Windows データのインデックスを作成できます。ログ・ファイル、ディレクトリ内のファイ
ル、イベント・ログ、レジストリ、または Active Directory など、任意のデータを利⽤することができます。
Splunk は Windows データをモニターするために、特別な⼊⼒も⽤意されています。以下に例を⽰します。
Windows イベントログ： マシン上で利⽤できる任意のイベント・ログ・チャネルで、Windows イベン
ト・ログサービスが⽣成したイベントをモニターすることができます。ローカル・マシン上のイベントを収
集することも、ユニバーサルフォワーダーや WMI を使ってリモート・イベントを収集することも可能で
す。
パフォーマンスモニタリング： Windows マシン上のパフォーマンス・データを収集して、そのデータに基
づいてアラートやレポートを作成することができます。パフォーマンス・モニターで利⽤できる任意のパ
フォーマンス・カウンタも、Splunk Enterprise で利⽤することができます。パフォーマンスをローカルに
監視することも、または WMI またはユニバーサルフォワーダーを使ってリモートに監視することも可能で
す。
WMI 経由のリモートモニタリング： WMI を使って、リモート・マシン上のイベント・ログやパフォーマ
ンス・データにアクセスすることができます。
レジストリ監視： レジストリ・モニタリング機能を使って、ローカルWindows レジストリへの変更をモニ
ターすることができます。ユニバーサルフォワーダーを使って、リモートマシン上のレジストリデータを収
集することもできます。
Active Directory モニタリング： ユーザー、グループ、マシン、およびグループポリシーオブジェクト
42
などの、Active Directory に対する変更を監視することができます。Active Directory データを、他の
Splunk Enterprise サーバーに転送することができます。
これらの特殊な⼊⼒は、Windows 版の Splunk Enterprise でのみ利⽤できます。ファイルとディレクトリ、ネッ
トワークモニタリング⼊⼒、およびスクリプト⼊⼒などの、標準の Splunk Enterprise ⼊⼒セットを利⽤するこ
ともできます。
Splunk App for Windows インフラ
Splunk App for Windows インフラは、Windows サーバーおよびデスクトップの管理⽤に、データの取り込み、
サーチ、レポート、アラート、およびダッシュボードを提供しています。Windows オペレーティングシステムの
モニター、管理、トラブルシューティングを 1 カ所から⾏えます。この App には、CPU、ディスク I/O、メモ
リー、イベント・ログ、設定、およびユーザー・データ⽤の⼊⼒、そして Windows イベント・ログのインデック
スを作成するための Web ベースのセットアップ UI が含まれています。
Windows への Splunk Enterprise デプロイの初期検討事項
Windows に Splunk Enterprise をインストール、デプロイする場合、以下の事項を検討する必要があります。
認証： ネットワーク内のリモート Windows マシンで操作を実施するには、それらのマシンにアクセスする
ための資格情報を持つユーザーとして Splunk Enterprise を動作させる必要があります。デプロイ前にこれ
らの資格情報を⽤意しておくことをお勧めします。「リモート Windows データのモニター⽅法決定の検討
事項」を参照してください。
ディスクの帯域幅： Splunk Enterprise インデクサーは、⼤量のディスク I/O 帯域幅を必要としています
(特に⼤量のデータのインデックスを作成する場合)。ウィルス対策ソフトウェアがインストールされている
場合、ウィルススキャンなどでパフォーマンスが⼤幅に低下するため、Splunk Enterprise ディレクトリま
たはプロセスを監視対象にしないようにウィルス対策ソフトウェアを設定する必要があります。
共有サーバー： 他のサービスが動作しているサーバー上に Splunk Enterprise をインストールする前に、
『キャパシティ・プランニング』マニュアルの「Splunk Enterprise のキャパシティ・プランニングの概
要」を参照してください。このことは、ドメインコントローラに Splunk Enterprise をインストールする場
合、または Exchange、SQL Server 、または仮想ホストサーバーなどのメモリーを消費するサービスが動
作するコンピュータ上に Splunk Enterprise をインストールする場合に重要になります。
Windows サーバーから効率的にデータを収集するには、データの収集対象マシン上にユニバーサルフォワーダー
をインストールします。ユニバーサルフォワーダーは⼩型軽量で、わずかなリソースしか消費しません。レジスト
リのモニタリングなど、⼀部の状況下では、レジストリの変更をリモート収集できないためフォワーダーを使⽤す
る必要があります。
Splunk Enterprise への Windows データの取り込み
Splunk Enterprise では、さまざまな種類の Windows データを収集することができます。
Splunk Enterprise をダウンロードして Windows マシン上にインストールする場合、以下のような Windows 統
計情報を収集できます。
Windows イベントログ
ファイルシステムの変更
Active Directory
WMI インフラでやり取りされるデータ
レジストリデータ
パフォーマンス測定基準
ホスト情報
印刷情報
ネットワーク情報
これらのすべてのタイプのデータは、Windows マシン上でのみ収集できます。その他のオペレーティング・シス
テムには、ローカルに Windows データを収集する⼿段はありません。ただし、Windows のデータを Windows
以外のシステムが動作している Splunk Enterprise インスタンスに転送することは可能です。
Splunk Web を使った Windows データの収集
Splunk Web では、ほぼすべての Windows ⼊⼒を利⽤して Windows データを収集することができます。例外の
1 つが MonitorNoHandle ⼊⼒で、これを利⽤するには、設定ファイルに設定する必要があります。
Splunk Web を使って⽬的のタイプのデータを収集するには：
1. Splunk Enterprise インスタンスにログインします。
2. 右上の [設定] をクリックして、表⽰されるポップアップウィンドウから [データ⼊⼒] をクリックしま
す。[データ⼊⼒] ページが表⽰されます。
3. 利⽤可能な⼊⼒のリストから、追加する⼊⼒を探します。次にその⼊⼒の [アクション] 列にある [新規追加] を
クリックします。
注意： Windows 以外のシステムで動作している Splunk Enterprise にログインした場合、Windows ⼊⼒は表⽰
されません。
4. 以降に表⽰されるページの指⽰に従って作業を⾏います。⽅法については、上記のページを参照してください。
5. [保存] をクリックして、⼊⼒を保存します。たいていの場合は、即座にデータの収集が開始されます。
43
設定ファイルを使った Windows データの収集
Splunk Web を使ってデータ⼊⼒を作成、有効化できない場合 (ユニバーサルフォワーダーを使ってデータを収集
する場合など) は、設定ファイルを使⽤する必要があります。多くの場合、設定ファイルを利⽤すれば、Splunk
Web よりもきめ細かく設定を制御、調整することができます。⼀部の⼊⼒は、設定ファイルを使ってのみ指定す
ることができます。
注意： ユニバーサルフォワーダーの Windows 版インストーラは、インストール時にいくつかの Windows ⼊⼒を
設定できますが、すべての⼊⼒を設定することはできません。
設定ファイルを使って⼊⼒を設定するには：
1. コマンドプロンプトまたは PowerShell ウィンドウから、%SPLUNK_HOME%\etc\system\default ディレクトリに移動
します。
2. このディレクトリに
します。
inputs.conf
のコピーを作成し、それを
%SPLUNK_HOME%\etc\system\local
注意： このステップは 1 回のみ実施する必要があります (または、local ディレクトリの
い場合)。
3. メモ帳や他のエディタを使って、local ディレクトリの
inputs.conf
ディレクトリに移動
inputs.conf
を上書きした
ファイルを開きます。
4. inputs.conf ファイルにスタンザを定義して⼊⼒を追加します。また、必要に応じて、既存のスタンザを変更し
てください。⽅法については、各⼊⼒のページ上部を参照してください。
5. ファイルを保存して終了します。
6. Splunk Enterprise を再起動します。設定ファイルが再読み込みされ、新しい設定に基づいてデータの収集が開
始されます。
注意： これは、設定ファイルを使った⼊⼒の設定の基本的な説明です。詳細は、『管理マニュアル』の「設定
ファイルについて」を参照してください。
リモート Windows データのモニター⽅法決定の検討事項
このトピックは、Splunk Enterprise を使ってリモート Windows データを収集する際の、検討事項を説明してい
ます。
リモート Windows データの概要
Splunk Enterprise はインデックス作成⽤のリモート Windows データを、2 種類のいずれかの⽅法で収集しま
す。
Splunk フォワーダーから
WMI 経由
フォワーダーの使⽤
フォワーダーを使ってリモート Windows データを収集することができます。ライトフォワーダー、ヘビーフォ
ワーダー、およびユニバーサルフォワーダーの 3 種類のフォワーダーが存在しています。 『データの転送』マ
ニュアルの「データの転送と受信について」を参照してください。
可能な場合はいつでも、リモート Windows データの収集にユニバーサルフォワーダーを使⽤することをお勧めし
ます。ユニバーサルフォワーダーを使⽤する利点を以下に⽰します。
ユニバーサル・フォワーダーは、インストールされているマシン上で最低限のネットワーク/ディスク・リ
ソースを消費します。
ユニバーサル・フォワーダーは権限のないユーザーとしてインストールできますが、WMI を使ったアクセ
スには管理者権限が必要です。
ユニバーサル・フォワーダーを Local System ユーザーとしてインストールした場合、このユーザーはマシ
ンへの管理者権限アクセスを保有しているため、そのデータを取得するために特に認証は必要ありません。
ただし、WMI では必要になります。
また、⼤規模環境にも柔軟に対応でき、デプロイも簡単です。System Center Configuration Manager
(SCCM) や Systems Management Server (SMS) などの、Microsoft のデプロイツール、または
BigFix/Tivoli のようなサードパーティ製の分散ソリューションを使⽤して、⼿動でデプロイすることができ
ます。
ユニバーサルフォワーダーをインストールすると、フォワーダーは情報をローカルに収集して、それを Splunk
Enterprise インデクサーに送信します。収集するデータはインストール時に指定するか、または後ほど⼿動また
はデプロイ・サーバー経由で設定の更新情報を配布して、フォワーダーに指⽰します。ユニバーサルフォワーダー
にアドオンをインストールすることもできます。
ネットワーク構成やレイアウトによっては、ユニバーサルフォワーダーの使⽤にいくつかの⽋点が出ることもあり
ます。後述する「フォワーダーと WMI を使ったリモート収集」を参照してください。
WMI の使⽤
WMI フレームワークを利⽤して、リモート Windows マシンから実質的に任意の種類のデータ を収集することが
できます。この構成では、Splunk Enterprise をインストール時に指定した (または後で [サービス] コントロー
ル・パネルで指定した) ユーザーとして実⾏します。
44
この構成では：
指定したアカウントがリモートアクセス⽤に保有している、最⼤限のネットワークアクセス権が Splunk
Enterprise に与えられます。
全社規模でリモート Windows マシンからデータが収集され、そのデータが集中リポジトリに保管されま
す。
各ネットワークセグメントに最低 1 台のインデクサーが存在する、⼩〜中規模ネットワークに適していま
す。
ただし、この⽅法では収集に関するいくつかの注意事項があります。後述する「フォワーダーと WMI」を参照し
てください。
注意： Active Directory (AD) モニタリングは WMI を使⽤しませんが、使⽤するデータ⼊⼒には同じような認証
上の検討事項が存在しています。Splunk Enterprise が Active Directory をモニターする仕組みについては、こ
のマニュアルの「Active Directory のモニター」を参照してください。
WMI を使ってデータを取得する場合の検討事項
WMI 経由でリモート Windows データを収集する場合、以下の事項を検討する必要があります。
リモート Windows データの認証
Windows でのリモート操作には認証が必要です。ネットワーク経由で Splunk Enterprise が Windows とどのよ
うなやり取りを⾏うのかを正しく理解しないと、最適なサーチ結果を得られない、または何も結果が得られない可
能性があります。ここでは、リモート Windows データを収集するための、セキュリティ上のガイドラインを説明
していきます。
Splunk Enterprise をインストールする際に、Local System ユーザーまたは他のユーザーとして実⾏することを
指定できます。この選択は、インストールとデータ収集の両⾯に影響してきます。
指定した Splunk Enterprise を実⾏するユーザーに応じて、リモート・マシンから取得できるデータのタイプや
量が変わります。⽬的のデータを取得するには、このユーザーに適切なレベルの権限 (アクセス許可) を与える必
要があります。
もっとも簡単な⽅法は、Splunk Enterprise を実⾏するユーザーを、Administrators (または Domain Admins)
グループのメンバーにすることです。これはセキュリティ・リスクを伴い、組織によっては使⽤できないこともあ
ります。この⽅法はお勧めできません。
たいていの場合、Splunk Enterprise ユーザー・アカウントには、⽬的のデータ・ソースにアクセスするために最
低限必要な権限を与える必要があります。これには以下の事項が含まれます。
ユーザーをさまざまなドメインセキュリティグループに追加する
アクセスする必要があるデータソースに応じて、各種 Active Directory オブジェクトのアクセス制御リスト
を変更する
Active Directory ドメインセキュリティポリシーが、定期的なパスワードの変更を強制している場合は、以下の
作業も必要になります。
Splunk Enterprise ユーザーのパスワードが失効しないようにするか、またはパスワード・ポリシーに定義
されているパスワードの失効前に、パスワードを⼿動で変更する。
パスワードを変更したら、ネットワーク上のすべてのサーバーで、そのアカウントとして動作している
Splunk サービスを再起動する。
注意： 最新版の Windows サーバーでは、管理されたサービスアカウント (MSA) を使って、パスワード失効に関
する問題に対処することができます。詳細は、『インストール・マニュアル』の「Windows Server 2008 および
Windows 7 での管理されたサービス・アカウント」を参照してください。
また、ユーザーがワークステーションに対話形式でログインすることを防⽌するために、ローカル・セキュリ
ティ・ポリシーで Splunk Enterprise アカウントに、ユーザー権利の割り当て [ローカルでログオンを拒否する]
を設定する必要もあります。Windows データを収集する場合は、そうする必要はありません。
この⽅法は作業に時間がかかりますが、よりきめ細かく管理でき、またドメイン管理者としてのアクセス権を与え
るよりも安全です。
このマニュアルの、Windows マシンへのリモートアクセスについて説明している各データの取り込み⽅法には、
Splunk Enterprise を実⾏するユーザーに最低限のアクセス許可/権限を設定するための追加情報や推奨事項が記
載されています。これらのページの「セキュリティとリモート・アクセスの検討事項 」セクションを参照して
ください。
ネットワークと I/O 使⽤に関する検討事項
ネットワーク帯域幅の使⽤状況は、⼊念にモニターする必要があります (特に低速の WAN リンクを利⽤している
ネットワークの場合)。この理由からだけでも、⼤量のリモート収集操作を⾏う場合は、ユニバーサル・フォワー
ダーが最善の選択肢になります。
ディスク帯域幅も重要な考慮事項です。ウィルス対策ソフトウェアのドライバ、および Splunk Enterprise とオ
ペレーティングシステム間を中継するドライバは、インストールタイプに関係なく、常に Splunk Enterprise
ディレクトリとプロセスを無視するように設定する必要があります。
Splunk フォワーダーと WMI
リモート Windows ホストからデータを取り込むには、ユニバーサル・フォワーダーを使⽤します。ユニバーサ
ル・フォワーダーは⼤半の種類のデータ・ソースに対応しており、より詳細なデータ (例：パフォーマンス測定基
45
準) を提供します。また、ネットワークのオーバーヘッドを最⼩限に抑え、運⽤上のリスクと複雑さを低減できま
す。また多くの場合、環境の拡張にも WMI よりも柔軟に対応できます。
リモートからデータを収集したい、または収集する必要がある場合 (企業規則やセキュリティ・ポリシーによりプ
ログラムのインストールが制限されている、またはパフォーマンスや相互運⽤性に関する問題がある場合など)、
ネイティブの WMI インターフェイスを使ってイベント・ログやパフォーマンス・データを収集することができま
す。
WMI とフォワーダーの主なトレードオフを以下に⽰します。
パフォーマンス
デプロイ
管理
パフォーマンス
パフォーマンスの点では、以下の場合にフォワーダーの⽅が適しています。
ローカルイベントログまたはフラットファイルを収集する。フォワーダーの⽅が CPU の消費が少なく、ま
たネットワークのオーバーヘッドを減らすために、データの基本的な事前圧縮が⾏われます。
認証の問題に悩まされることなく、マシンからデータを収集したい場合。フォワーダーを Local System
ユーザーとしてインストールする場合、マシンに対する管理者アクセスがあるため、そこから任意のデータ
を収集することができます。
Exchange、SQL Server/Oracle、VMWare、Hyper-V、または SharePoint サーバー、および Active
Directory ドメイン・コントローラまたは継続的に使⽤率が⾼いマシンなどの、処理負荷が⾼いホストから
データを収集する場合。WMI では、これらのサービスが⽣成するデータ量に追随できない可能性がありま
す。設計上 WMI のポーリングはベストエフォート型で、また Splunk Enterprise も意図しないサービス拒
否攻撃を防⽌するために、WMI を抑制します。
CPU およびネットワーク使⽤率を考慮する必要がある場合。フォワーダーはこれらのリソースの使⽤をでき
る限り控えるようにしています。⼀⽅、WMI はデータの転送により多くの CPU およびネットワーク・リ
ソースを使⽤します。
スケーラビリティが関⼼事項の場合。ユニバーサルフォワーダーは環境の拡張にも柔軟に対応できます。ヘ
ビー・フォワーダーはユニバーサル・フォワーダーほど柔軟には対応できませんが、どちらのフォワーダー
も WMI よりは⼤幅に柔軟に対応することができます。
WMI の⽅が適している場合を以下に⽰します。
メモリー使⽤量が⾼いシステム上で、メモリー消費量が関⼼事項の場合。フォワーダーはデータの収集時に
ローカルマシンに常駐し、より多くのポーリングオプションが⽤意されているため、WMI よりも多くのメ
モリーを消費します。
デプロイ
デプロイにフォワーダーが適している場合を以下に⽰します。
システムイメージの作成時など、OS のベースビルドを管理している場合。
収集するデータソース数が多い場合 (特に、データの収集時に何らかの変換が必要な場合)。
注意： いくつかの事例を除いて、インデクサーに送信せずにユニバーサル・フォワーダーでデータを処理するこ
とはできません。インデックス作成前にデータを変更する必要がある場合は、ヘビーフォワーダーを使⽤する必要
があります。
WMI の⽅が適している場合を以下に⽰します。
ベース OS ビルドを管理していない、またはドメイン管理者アクセス権がない、またはデータを収集するマ
シンのローカル Administrotor 権限がない。
多数のホストから、わずかなセットのデータしか必要ない場合 (例：使⽤状況により課⾦するための CPU
データの収集)。
⼀般的なデプロイのシナリオでは、まずリモートポーリングを使ってテストを⾏った後、正常なまたは有益なデー
タ⼊⼒をフォワーダー設定に追加する (または⼀括デプロイ時)。
管理
どちらの⽅法でも、ログとアラート機能を使って、ホストが起動または停⽌した時、または接続できなくなったこ
とを知らせることができます。ただし、Splunk Enterprise では想定外のサービス拒否攻撃を防⽌するために、
WMI ポーリングサービスは⼀定期間ホストと通信できなかった場合、ポーリングの頻度を徐々に減らしていき、
最終的には通信できなくなったホストへのポーリングを中⽌します。そのため、ラップトップや動的にプロビジョ
ニングされる仮想マシンなどの、頻繁にオフラインになるマシンに対して、WMI によるリモートポーリングを使
⽤しないことをお勧めします。
データソースの⼀覧と、各データソースに適したデータ収集タイプを以下の表に⽰します。
データソースと収集⽅法
データソース
ローカルフォワーダー
WMI
イベントログ
はい
はい*
パフォーマンス
はい
はい
レジストリ
はい
いいえ
Active Directory はい
いいえ
46
ログファイル
はい
はい**
クロール
はい
いいえ
* リモート・イベント・ログの収集の場合、収集するイベント・ログの名前を知っている必要があります。ローカ
ルフォワーダー上では、名前に関係なくすべてのログを収集するオプションがあります。
** Splunk Enterprise は、「\\SERVERNAME\SHARE」の構⽂でのリモートログファイルの収集をサポートして
います。ただし、アプリケーション層ファイルアクセスプロトコルとして CIFS (Common Internet File System
またはサーバーメッセージブロック) を使⽤する必要があります。また、Splunk Enterprise には共有とそのファ
イルシステムの両⽅に対して、最低でも読み取りアクセス権が必要です。
Windows 版以外の Splunk Enterprise インスタンス上での Windows データのサーチ
Windows 版以外の Splunk Enterprise インスタンス上で、Windows データのインデックス作成とサーチを⾏え
ます。ただしその場合、まず Windows 版の Splunk インスタンスを使って Windows データを収集する必要があ
ります。そのためには、Windows コンピュータに Splunk フォワーダーをインストールして、その Windows
データを⾮ Windows 版 Splunk Enterprise インスタンスに転送するように設定します。
作業を⾏うには、2 種類の⽅法があります。
データを収集する各 Windows マシン上に、ローカルにフォワーダーを設定する。これらのフォワーダー
は、Windows データを ⾮ Windows Splunk インスタンスに送信することができます。
フォワーダーを 1 台の Windows マシン上に設定する。フォワーダーは WMI を使って、環境内のすべての
Windows マシンからデータを収集することができます。次に収集したデータを、⾮ Windows 版Splunk イ
ンスタンスにまとめて転送します。
⾮Windows 版 Splunk Enterprise インスタンスが Windows データを処理するように、明⽰的に設定する必要が
あります。詳細は、『データの転送』マニュアルの「異なるオペレーティング・システムが動作するフォワーダー
から受信したデータのサーチ」を参照してください。
フォワーダーの設定については、『データの転送』マニュアルの「転送と受信の設定」を参照してください。
Active Directory のモニター
Active Directory (AD) は、Windows ネットワークの中核を為しています。Active Directory データベース (NT
ディレクトリサービス (NTDS) データベース) は、Active Directory ドメイン/フォレスト内のユーザー、コン
ピュータ、ネットワーク、デバイス、およびセキュリティオブジェクトの集中リポジトリです。ユーザー、メン
バーサーバー、またはドメインコントローラの追加や削除など、Active Directory を変更する場合、それらの変
更を記録することができます。Splunk Enterprise では、これらの変更をモニターし、リアルタイムにアラートを
⽣成することができます。
Active Directory モニタリングを設定して、Active Directory フォレストに対する変更を監視し、ユーザーとマ
シンのメタデータを収集することができます。この機能と動的リストルックアップを組み合わせて、Active
Directory で利⽤できる情報をイベントに追加、変更することができます。
Active Directory をモニターするように Splunk を設定したら、Active Directory スキーマのベースラインス
ナップショットが取得されます。このスナップショットを使⽤して、モニターの開始点が確⽴されます。この処理
が完了するまで、少し時間がかかる場合があります。
Active Directory モニタリング⼊⼒は、splunk-admon.exe と呼ばれる別個のプロセスとして実⾏されます。Splunk
に定義されている各 Active Directory モニタリング⼊⼒に対して、1 回実⾏されます。
Active Directory の監視理由
Active Directory の整合性、セキュリティ、およびヘルスの維持管理を担当している場合、⽇々どのような作業
が⾏われているのかを把握することが重要になります。Splunk Enterprise では、誰がまたは何が変更をいつ⾏っ
たのかなど、Active Directory の変更内容を確認することができます。
このデータをレポートに変換して、企業のセキュリティコンプライアンスや法的証拠として利⽤することができま
す。また、取得したデータから侵⼊検知アラートを利⽤して、不正⾏為に即座に対処することができます。さら
に、インデックス作成したデータからヘルスレポートを作成し、操作マスターロール、Active Directory レプリ
カ、およびグローバルカタログの割り当てなどの、将来の Active Directory インフラのプランニングに活⽤する
ことができます。
Active Directory のモニターに何が必要か？
Active Directory スキーマのモニターに必要な、明⽰的なアクセス許可の⼀覧を以下の表に⽰します。
アクティビティ：
Active Directory ス
キーマをモニター
必要なアクセス許可：
* Splunk は Windows 上で実⾏する必要があります。
* Splunk はドメインユーザーとして実⾏する必要があります。
* Splunk を実⾏するユーザーには、モニター対象のすべての Active Directory オブ
ジェクトに対する読み取りアクセスが必要です。
Active Directory モニターの検討事項
Splunk Enterprise を使った Active Directory のモニターで最良の結果を引き出すために、以下の事項に注意し
てください。
47
この機能は Windows 版の Splunk Enterprise でのみ利⽤できます。*nix 版の Splunk で Active Directory
の変更をモニターすることはできません (ただし、Windows 版の Splunk で収集したデータを、*nix インデ
クサーに転送することは可能です)。
Active Directory モニタリングプロセスは、完全版 Splunk インスタンスまたは任意の種類のフォワーダー
で実⾏することができます。
Active Directory への変更をモニターするマシンは、モニター対象のドメインまたはフォレストに所属して
いる必要があります。
Splunk を実⾏するユーザーも、ドメインの⼀部である必要があります。このことは、ユーザーが保有して
いるアクセス許可により、Splunk がモニターできる Active Directory の部分が決まるためです。
Windows データをリモートにモニターする⽅法を決定する際に役⽴つその他の情報については、このマニュアル
の「リモート Windows データのモニター⽅法決定の検討事項」を参照してください。インストール時に指定する
Splunk を実⾏するユーザーの決定に関する情報については、『インストールマニュアル』の「Splunk を実⾏す
るためのユーザーの選択」を参照してください。
Active Directory モニタリングの設定
Splunk Web を使って、または設定ファイルを編集して、Active Directory モニタリングを設定することができ
ます。設定ファイルを使⽤する場合は、複数のドメインコントローラのモニター設定などのオプションを利⽤する
ことができます。
Splunk Web を使った Active Directory モニタリングの設定
Active Directory のモニターを設定する場合は、このマニュアルの「Windows Active Directory」を参照してく
ださい。
設定ファイルを使った Active Directory モニタリングの設定
Active Directory モニター設定は、inputs.conf 設定ファイルで⾏います。%SPLUNK_HOME%\etc\system\local ディレ
クトリ内の inputs.conf のコピーを編修します。デフォルトディレクトリにあるファイルを編集すると、Splunk
のアップグレード時に変更内容が上書きされてしまいます。設定ファイルの優先度については、このマニュアルの
「設定ファイルの優先度」を参照してください。
1. %SPLUNK_HOME%\etc\system\default\inputs.conf のコピーを作成し、%SPLUNK_HOME%\etc\system\local\inputs.conf に保
管します。
2. inputs.conf を編集し、適切な Active Directory モニタリングスタンザと設定を追加します。
注意： デフォルトでは、Active Directory モニタリング⼊⼒を有効にすると、Splunk は接続できる最初のドメイ
ンコントローラから、Active Directory 変更データを収集します。それを許容できる場合は、それ以上の設定は
不要です。
inp u ts.c onf の設定
には、各 Active Directory モニタリング⼊⼒に対して 1 つのスタンザが含まれており、ヘッダーは以
下のようになっています。
inputs.conf
[admon://<name of stanza>]
各スタンザで、以下の項⽬を指定することができます。
属性
targetDc
必須？
はい
説明
Active Directory モニタリングに使⽤するドメインコ
ントローラの⼀意の名前。
デフォルト
N/A
以下の場合に、この属性に⼀意の名前を指定します。
⾮常に⼤きな Active Directory が存在してお
り、特定の組織単位 (OU) やサブドメインなどの
情報のみをモニターしたい場合。
セキュリティが⾮常に⾼度な環境で、モニタリン
グ⽬的で使⽤できる特定の (読み取り専⽤) ドメ
インコントローラがある場合。
推移性の信頼がある複数のドメインまたはフォレ
ストが存在しており、Splunk が常駐している
サーバー以外のツリーを対象にしたい場合。
複数のドメインコントローラを対象にするよう
に、複数の Active Directory モニタリング⼊⼒
を設定する場合。たとえば、分散環境で Active
Directory レプリケーションをモニターする場合
が挙げられます。
注意： 複数のドメインコントローラを対象にする場
合、ツリーに他のターゲットの
[admon://<uniquename>targetDc] スタンザを追加してくだ
さい。
startingNode
いいえ
完全修飾 LDAP 名
(例："LDAP://OU=Computers,DC=ad,DC=splunk,DC=com")。こ
れは、インデックスの作成を開始する Active
48
Splunk がアクセス
できる、ツリー内の
最上位のルートドメ
イン。
Directory ツリー内の場所を表しています。Splunk は
そこから開始して、monitorSubtree 属性の設定に応じて
サブコンテナを列挙します。
イン。
注意： Splunk が正常に Active Directory データを収
集するために、startingNode の値は、対象としているド
メインコントローラのスコープ内でなければなりませ
ん。
monitorSubtree
いいえ
インデックスを作成するターゲット Active Directory
コンテナの量。0 の場合、ターゲットコンテナのみの
インデックスが作成され、そのコンテナのサブコンテ
ナは対象にはなりません。1 の場合、Splunk がアクセ
ス可能なすべてのサブコンテナとドメインが列挙され
ます。
1 (Splunk がアクセ
スできるすべてのド
メインをモニターす
る)
baseline
いいえ
初回実⾏時に、⼊⼒が既存の利⽤可能なすべての
Active Directory オブジェクトを列挙するかどうか。
0 の場合、ベースラインは設定されません。1 の場合
は、ベースラインが設定されます。
1 (ベースラインを設
定)
index
いいえ
Active Directory モニタリングデータを送信するイン
デックス。
デフォルト (default)
のインデックス
disabled
いいえ
Splunk が⼊⼒を実⾏するかどうか。0 の場合⼊⼒が有 0 (有効)。
効なことを、1 の場合⼊⼒が無効なことを Splunk に
指⽰します。
Active Directory モニタリング設定の例
inputs.conf
を使った、Active Directory ネットワークの⽬的の部分のモニター⽅法の例を以下に⽰します。
Active Directory の上部からデータのインデックスを作成するには：
#Gather all AD data that this server can see
[admon://NearestDC]
targetDc =
startingNode =
モニター対象にする OU よりも上位の root レベルにあるドメインコントローラを使⽤するには：
# Use the pri01.eng.ad.splunk.com domain controller to get all AD metadata for
# the Computers OU in this forest. We want schema data for the entire AD tree, not
# just this node.
[admon://DefaultTargetDc]
targetDc = pri01.eng.ad.splunk.com
startingNode = OU=Computers,DC=eng,DC=ad,DC=splunk,DC=com
複数のドメインコントローラをモニターするには：
# Get change data from two domain controllers (pri01 and pri02) in the same AD tree.
# Index both and compare/contrast to ensure AD replication is occurring properly.
[admon://DefaultTargetDc]
targetDc = pri01.eng.ad.splunk.com
startingNode = OU=Computers,DC=eng,DC=ad,DC=splunk,DC=com
[admon://SecondTargetDc]
targetDc = pri02.eng.ad.splunk.com
startingNode = OU=Computers,DC=eng,DC=ad,DC=splunk,DC=com
Active Directory モニタリングの出⼒例
Splunk の Active Directory モニタリングユーティリティを実⾏すると、Active Directory の変更イベントが収
集されます。各変更イベントが、Splunk のイベントとしてインデックスが作成されます。これらのイベントは、
Splunk のサーチ App で参照することができます。
Splunk がインデックスを作成できる、さまざまな種類の Active Directory 変更イベントが存在しています。こ
れらのイベントの例は後述しています。これらのイベントのコンテンツの⼀部は、公開のために曖昧化または変更
されています。
更新イベント
49
Active Directory オブジェクトが何らかの⽅法で変更されると、Splunk はこのタイプのイベントを⽣成します。
Splunk はこの変更を、タイプ admonEventType=Update として記録します。
2/1/10
3:17:18.009 PM
02/01/2010 15:17:18.0099
dcName=stuff.splunk.com
admonEventType=Update
Names:
objectCategory=CN=Computer,CN=Schema,CN=Configuration
name=stuff2
displayName=stuff2
distinguishedName=CN=stuff2,CN=Computers
Object Details:
sAMAccountType=805306369
sAMAccountName=stuff2
logonCount=4216
accountExpires=9223372036854775807
objectSid=S-1-5-21-3436176729-1841096389-3700143990-1190
primaryGroupID=515
pwdLastSet=06:30:13 pm, Sat 11/27/2010
lastLogon=06:19:43 am, Sun 11/28/2010
lastLogoff=0
badPasswordTime=0
countryCode=0
codePage=0
badPwdCount=0
userAccountControl=4096
objectGUID=blah
whenChanged=01:02.11 am, Thu 01/28/2010
whenCreated=05:29.50 pm, Tue 11/25/2008
objectClass=top|person|organizationalPerson|user|computer
Event Details:
uSNChanged=2921916
uSNCreated=1679623
instanceType=4
Additional Details:
isCriticalSystemObject=FALSE
servicePrincipalName=TERMSRV/stuff2|TERMSRV blah
dNSHostName=stuff2.splunk.com
operatingSystemServicePack=Service Pack 2
operatingSystemVersion=6.0 (6002)
operatingSystem=Windows Vista? Ultimate
localPolicyFlags=0
削除イベント
Active Directory オブジェクトに削除のマークが付けられた時に、このイベントタイプが⽣成されます。イベン
トタイプは admonEventType=Update と似ていますが、イベントの最後に isDeleted=True キー/値のペアが含まれていま
す。
2/1/10
3:11:16.095 PM
02/01/2010 15:11:16.0954
dcName=stuff.splunk.com
admonEventType=Update
Names:
name=SplunkTest
DEL:blah
distinguishedName=OU=SplunkTest\0ADEL:blah,CN=Deleted Objects
DEL:blah
Object Details:
objectGUID=blah
whenChanged=11:31.13 pm, Thu 01/28/2010
whenCreated=11:27.12 pm, Thu 01/28/2010
objectClass=top|organizationalUnit
Event Details:
uSNChanged=2922895
50
uSNCreated=2922846
instanceType=4
Additional Details:
dSCorePropagationData=20100128233113.0Z|20100128233113.0Z|20100128233113.0Z|16010108151056.0Z
lastKnownParent=stuff
'''isDeleted=TRUE'''
同期イベント
Active Directory モニタリング⼊⼒が設定されると、Splunk 開始時に Active Directory メタデータのベースラ
インの捕捉が試みられます。Splunk は、1 つの Active Directory オブジェクトのインスタンスとそのすべての
フィールド値を表すイベントタイプ admonEventType=Sync を⽣成します。Splunk は、最後に記録された更新シーケ
ンス番号 (USN) から、すべてのオブジェクトの捕捉を試みます。
注意： Splunk または splunk-admon.exe プロセスを再起動した場合、Splunk は余分な「sync」イベントを記録し
ます。この動作は正常です。
2/1/10
3:11:09.074 PM
02/01/2010 15:11:09.0748
dcName=ftw.ad.splunk.com
admonEventType=Sync
Names:
name=NTDS Settings
distinguishedName=CN=NTDS Settings,CN=stuff,CN=Servers,CN=Default-First-SiteName,CN=Sites,CN=Configuration
cn=NTDS Settings
objectCategory=CN=NTDS-DSA,CN=Schema,CN=Configuration,DC=ad,DC=splunk,DC=com
fullPath=LDAP://stuff.splunk.com/<GUID=bla bla bla>
CN=NTDS Settings
Object Details:
whenCreated=10:15.04 pm, Tue 02/12/2008
whenChanged=10:23.00 pm, Tue 02/12/2008
objectGUID=bla bla bla
objectClass=top|applicationSettings|nTDSDSA
classPath=nTDSDSA
Event Details:
instanceType=4
Additional Details:
systemFlags=33554432
showInAdvancedViewOnly=TRUE
serverReferenceBL=CN=stuff,CN=Domain System Volume (SYSVOL share),CN=File Replication
Service,CN=System
options=1
msDS-hasMasterNCs=DC=ForestDnsZones|DC=DomainDnsZones|CN=Schema,CN=Configuration|CN=Configuration
msDS-HasInstantiatedNCs=
msDS-HasDomainNCs=blah
msDS-Behavior-Version=2
invocationId=bla bla bla
hasMasterNCs=CN=Schema,CN=Configuration|CN=Configuration
dSCorePropagationData=
dMDLocation=CN=Schema,CN=Configuration
nTSecurityDescriptor=NT AUTHORITY\Authenticated Users
SchemaName=LDAP://stuff.splunk.com/schema/nTDSDSA
スキーマイベント
Active Directory モニタリングを設定した後 Splunk を起動すると、スキーマタイプイベント
admonEventType=schema が⽣成されます。
02/01/2010 15:11:16.0518
dcName=LDAP://stuff.splunk.com/
admonEventType=schema
className=msExchProtocolCfgSMTPIPAddress
classCN=ms-Exch-Protocol-Cfg-SMTP-IP-Address
instanceType=MandatoryProperties
nTSecurityDescriptor=MandatoryProperties
objectCategory=MandatoryProperties
objectClass=MandatoryProperties
51
adminDescription=OptionalProperties
adminDisplayName=OptionalProperties
allowedAttributes=OptionalProperties
allowedAttributesEffective=OptionalProperties
allowedChildClasses=OptionalProperties
allowedChildClassesEffective=OptionalProperties
bridgeheadServerListBL=OptionalProperties
canonicalName=OptionalProperties
cn=OptionalProperties
createTimeStamp=OptionalProperties
description=OptionalProperties
directReports=OptionalProperties
displayName=OptionalProperties
displayNamePrintable=OptionalProperties
distinguishedName=OptionalProperties
dSASignature=OptionalProperties
dSCorePropagationData=OptionalProperties
extensionName=OptionalProperties
flags=OptionalProperties
fromEntry=OptionalProperties
frsComputerReferenceBL=OptionalProperties
fRSMemberReferenceBL=OptionalProperties
fSMORoleOwner=OptionalProperties
heuristics=OptionalProperties
isCriticalSystemObject=OptionalProperties
isDeleted=OptionalProperties
isPrivilegeHolder=OptionalProperties
lastKnownParent=OptionalProperties
legacyExchangeDN=OptionalProperties
managedObjects=OptionalProperties
masteredBy=OptionalProperties
memberOf=OptionalProperties
modifyTimeStamp=OptionalProperties
mS-DS-ConsistencyChildCount=OptionalProperties
mS-DS-ConsistencyGuid=OptionalProperties
msCOM-PartitionSetLink=OptionalProperties
msCOM-UserLink=OptionalProperties
msDFSR-ComputerReferenceBL=OptionalProperties
msDFSR-MemberReferenceBL=OptionalProperties
msDS-Approx-Immed-Subordinates=OptionalProperties
msDs-masteredBy=OptionalProperties
msDS-MembersForAzRoleBL=OptionalProperties
msDS-NCReplCursors=OptionalProperties
msDS-NCReplInboundNeighbors=OptionalProperties
msDS-NCReplOutboundNeighbors=OptionalProperties
msDS-NonMembersBL=OptionalProperties
msDS-ObjectReferenceBL=OptionalProperties
msDS-OperationsForAzRoleBL=OptionalProperties
msDS-OperationsForAzTaskBL=OptionalProperties
msDS-ReplAttributeMetaData=OptionalProperties
msDS-ReplValueMetaData=OptionalProperties
msDS-TasksForAzRoleBL=OptionalProperties
msDS-TasksForAzTaskBL=OptionalProperties
msExchADCGlobalNames=OptionalProperties
msExchALObjectVersion=OptionalProperties
msExchHideFromAddressLists=OptionalProperties
msExchInconsistentState=OptionalProperties
msExchIPAddress=OptionalProperties
msExchTurfList=OptionalProperties
msExchUnmergedAttsPt=OptionalProperties
msExchVersion=OptionalProperties
msSFU30PosixMemberOf=OptionalProperties
name=OptionalProperties
netbootSCPBL=OptionalProperties
nonSecurityMemberBL=OptionalProperties
objectGUID=OptionalProperties
objectVersion=OptionalProperties
otherWellKnownObjects=OptionalProperties
ownerBL=OptionalProperties
partialAttributeDeletionList=OptionalProperties
partialAttributeSet=OptionalProperties
possibleInferiors=OptionalProperties
52
proxiedObjectName=OptionalProperties
proxyAddresses=OptionalProperties
queryPolicyBL=OptionalProperties
replicatedObjectVersion=OptionalProperties
replicationSignature=OptionalProperties
replPropertyMetaData=OptionalProperties
replUpToDateVector=OptionalProperties
repsFrom=OptionalProperties
repsTo=OptionalProperties
revision=OptionalProperties
sDRightsEffective=OptionalProperties
serverReferenceBL=OptionalProperties
showInAddressBook=OptionalProperties
showInAdvancedViewOnly=OptionalProperties
siteObjectBL=OptionalProperties
structuralObjectClass=OptionalProperties
subRefs=OptionalProperties
subSchemaSubEntry=OptionalProperties
systemFlags=OptionalProperties
unmergedAtts=OptionalProperties
url=OptionalProperties
uSNChanged=OptionalProperties
uSNCreated=OptionalProperties
uSNDSALastObjRemoved=OptionalProperties
USNIntersite=OptionalProperties
uSNLastObjRem=OptionalProperties
uSNSource=OptionalProperties
wbemPath=OptionalProperties
wellKnownObjects=OptionalProperties
whenChanged=OptionalProperties
whenCreated=OptionalProperties
wWWHomePage=OptionalProperties
Answers
何か質問がありますか？「Splunk Answers」では、Splunk コミュニティに寄せられた、Splunk を使った
Active Directory のモニターに関する質問と回答をご覧いただけます。
Windows イベントログデータのモニター
Windows はその運⽤の⼀環としてログデータを⽣成します。Windows イベントログサービスは、これに関する
ほぼすべての事項を処理します。インストールされているアプリケーション、サービス、およびシステムプロセス
が発⾏したログデータを収集し、それをイベントログチャネルに保管します。このチャネルは中間保管場所で、そ
の後イベントログファイルに書き込まれます。Microsoft のイベントビューアなどのプログラムは、これらのログ
チャネルを参照して、システムに発⽣したイベントを表⽰します。
Splunk Enterprise は Windows イベントログのモニタリングもサポートしています。イベントログチャネルや
ローカルマシンに保管されているログファイルをモニターしたり、リモートマシンからログを収集したりすること
ができます。
イベントログモニターは、splunkd サービス内の⼊⼒プロセッサとして実⾏されます。Splunk Enterprise に定義
されている各イベントログ⼊⼒に対して、1 回実⾏されます。
イベントログをモニターする理由
Windows イベントログは、Windows サーバーの運⽤に関する中⼼的な測定基準です。Windows システムに何か
問題がある場合は、おそらくイベントログにそれに関する情報が記載されています。Splunk Enterprise のイン
デックス作成、サーチ、およびレポート機能により、ログ情報にアクセスできるようになります。
イベント・ログのモニターに何が必要か？
アクティビティ：
必要なアクセス許可：
ローカルイベント
ログのモニター
* Splunk Enterprise はWindows 上で実⾏する必要があります。
* すべてのローカルイベントログを読み取るには、Splunk Enterprise を Local System
ユーザーとして実⾏する必要があります。
リモートイベント
ログのモニター
* Splunk Enterprise は Windows 上で実⾏する必要があります。
および
* Splunk Enterprise は、イベントログを収集するサーバー上にインストールされている、
ユニバーサルフォワーダー上で動作する必要があります。
または
* ターゲットサーバー上の WMI への読み取りアクセスを持つドメインまたはリモートユー
ザーとして、Splunk Enterprise を実⾏する必要があります。
* Splunk Enterprise を実⾏するユーザーには、⽬的のイベントログへの読み取りアクセス
が必要です。
53
セキュリティとリモートアクセスの検討事項
Splunk Enterprise は、WMI またはフォワーダーを使って、リモートマシンからイベントログデータを収集しま
す。リモートマシンからインデクサーへのイベントログデータの送信には、ユニバーサルフォワーダーを使⽤する
ことをお勧めします。イベントログデータを収集するための、フォワーダーのインストール、設定、使⽤⽅法につ
いては、『データの転送』マニュアルの「ユニバーサルフォワーダーの紹介」を参照してください。
イベントログデータを収集するために、リモートマシン上にフォワーダーをインストールする場合、それらのマシ
ンにはフォワーダーを Local System ユーザーとしてインストールすることができます。Local System ユーザー
は、ローカルマシン上のすべてのデータにアクセスできますが、リモートマシンにアクセスすることはできませ
ん。
WMI を使ってリモートマシンからイベントログデータを収集する場合、ネットワークと Splunk Enterprise イン
スタンスが適切に設定されていることを確認する必要があります。Splunk を Local System ユーザーとしてイン
ストールすることはできません。また、インストールするユーザーによって、Splunk が参照できるイベントログ
が決まります。Splunk が WMI を使ってリモートデータを適切に収集するために、満たす必要がある要件につい
ては、このマニュアルの「WMI ベースのデータのモニター」の「セキュリティとリモートアクセスの検討事項」
を参照してください。
デフォルトでは、Windows のバージョンに応じて、⼀部のイベントログへのアクセスが制限されます。特に、デ
フォルトでセキュリティイベントログは、ローカル Administrators またはグローバル Domain Admins グループ
のメンバーのみが参照することができます。
リモート Windows マシンからのイベントログの収集
Splunk Enterprise を使ってリモートマシンからイベントログを収集する場合、2 種類の選択肢があります。
WMI を使ってリモートにログを収集する。このオプションは、Splunk Web で [リモートイベントログの収
集] を選択した場合に使⽤します。
収集するログがあるマシン上に、ユニバーサル・フォワーダー をインストールする。
WMI を使ってイベントログを収集する場合、Splunk Enterprise を Active Directory ドメインユーザーとしてイ
ンストールする必要があります。リモート Windows マシンからのデータの収集については、「リモート
Windows データのモニター⽅法決定の検討事項」を参照してください。選択したドメインユーザーが
Administrators または Domain Admins グループのメンバーでない場合、ドメインユーザーをイベントログにア
クセスさせるための、イベントログセキュリティを設定する必要があります。
リモートマシンからイベントログにアクセスするために、イベントログセキュリティを変更するには、以下の条件
を満たす必要があります。
収集するイベントログがあるサーバーへの管理者アクセスを保有している。
SDDL (Security Description Definition Language) (外部リンク) の仕組み、およびそれを使った アクセス
許可の割り当て⽅法を理解している。
Windows XP および Windows Server 2003/2003 R2 でのイベントログセキュリティアクセス許可の設定⽅法に
ついては、Microsoft サポート技術情報の記事を参照してください。Windows Vista、Windows 7、または
Windows Server 2008/2008 R2 を利⽤している場合は、wevtutil ユーティリティを使ってイベントログセキュ
リティを設定します。
⼀部のシステムではイベントログに変則的なホスト名が表⽰される
Windows Vista および Server 2008 システムで、⼀部のイベントログにランダムに⽣成されたホスト名が表⽰さ
れることがあります。これは、OS のインストールプロセス中に、ユーザーがシステム名を指定する前にシステム
がイベントを記録したためです。
このような変則的な名称は、上記のバージョンの Windows から WMI 経由でリモートにログを収集した場合にの
み発⽣します。
Splunk Web を使ったイベントログのモニタリング
ローカル・マシンから Windows イベント・ログ・データを収集するには、このマニュアルの「Windows イベン
ト・ログ - ローカル」を参照してください。
リモートイベントログのモニタリングの設定
リモート・イベント・ログのモニタリング⼿順は、ローカル・イベント・ログのモニター⼿順とほぼ同じです。
リモート Windows マシンから Windows イベント・ログ・データを収集するには、このマニュアルの
「Windows イベント・ログ - リモート」を参照してください。
inputs.conf を使ったイベントログモニタリングの設定
を使ってイベントログのモニタリングを設定することができます。inputs.conf を使ったデータ⼊⼒の
設定の詳細は、このマニュアルの「⼊⼒の設定」を参照してください。
inputs.conf
注意： 設定ファイルのデフォルトは、%SPLUNK_HOME%\etc\system\default 内のファイルまたは『管理マニュアル』で
確認することができます。
設定ファイルの編集⽅法については、『管理マニュアル』の「設定ファイルについて」を参照してくださ
い。
54
inputs.conf
を編集してイベントログ⼊⼒を有効にするには：
1. inputs.conf を
%SPLUNK_HOME%\etc\system\default
2. エクスプローラまたは
ATTRIB
から
etc\system\local
にコピーします。
コマンドを使って、ファイルの読み取り専⽤フラグを削除します。
3. ファイルを開いて編集し、Windows イベントログ⼊⼒を有効にします。
4. Splunk を再起動します。
次のセクションでは、イベントログのモニタリングのための、利⽤可能な設定値について説明していきます。
イベントログモニターの設定値
Windows イベントログ (*.evt) ファイルはバイナリ形式です。標準のテキストファイルのようにモニターすること
はできません。splunkd サービスは、適切な API を使ってこれらのバイナリファイルを読み取り、ファイル内の
データのインデックスを作成しています。
Splunk は
inputs.conf
内の以下のスタンザを使って、デフォルトの Windows イベントログをモニターします。
# Windows platform specific input processor.
[WinEventLog://Application]
disabled = 0
[WinEventLog://Security]
disabled = 0
[WinEventLog://System]
disabled = 0
また、デフォルト以外の Windows イベントログをモニターするように、Splunk Enterprise を設定することもで
きます。作業を⾏う前に、ログを Windows イベントビューアにインポートする必要があります。ログをインポー
トしたら、以下のようにそれを inputs.conf のローカルコピーに追加することができます。
[WinEventLog://DNS Server]
disabled = 0
[WinEventLog://Directory Service]
disabled = 0
[WinEventLog://File Replication Service]
disabled = 0
注意：インデックス作成には、ログプロパティの「Full Name:」を使⽤します。[Microsoft] > [Windows] > [タ
スクスケジューラ] > [稼働中] 内のタスクスケジューラをモニターするには、[稼働中] を右クリックしてプロパ
ティを選択します。WinEventLog: スタンザに追加するには、「Full Name」を使⽤します。
[WinEventLog://Microsoft-Windows-TaskScheduler/Operational]
disabled = 0
イベントログのインデックス作成を無効にするには、%SPLUNK_HOME%\etc\system\local\inputs.conf のスタンザのリス
ト下に disabled = 1 を追加します。
Splunk Enterprise は inputs.conf 内の以下の属性を使って、イベントログファイルをモニターします。
属性
start_from
説明
時系列的なイベントの読み込み⽅法を⽰します。
oldest (古いものから新しいものへとログを読み込む) および newest (新しいも
のから古いものへとログを読み込む) を指定できます。
属性に newest を設定すると、最新のものから古いものへとログを読み込んだ
後、処理を終了します。
デフォ
ルト
oldest
注意： current_only 属性に 1 を設定した場合、この属性に newest を設定することは
できません (⽭盾しているため)。この組み合わせは無視されます。
current_only
0
Splunk Enterprise 開始後の、イベントのインデックス作成⽅法を⽰しま
す。
1 (*nix システムの 「tail -f」のように、⼊⼒の取り込み開始後に到着したイ
ベントのみを取得する) または 0 (ログ内の既存のすべてのイベントを取得し
て、それ以降に到着するイベントを継続的かつリアルタイムにモニターする)
を指定できます。
注意： start_from 属性に newest を設定した場合、この属性に 1 を設定することはで
きません (⽭盾しているため)。この組み合わせは無視されます。
55
checkpointInterval
evt_resolve_ad_obj
evt_dc_name
evt_dns_name
suppress_text
whitelist
5
Windows イベントログ⼊⼒が、チェックポイントを保存する頻度 (秒) を指
定します。
チェックポイントは、取得したイベントの eventID を保管しています。
これにより、シャットダウンや機能停⽌後にも、正しくイベントのモニター
を継続することができます。
1
Windows イベントログイベントのインデックス作成中の、Active Directory
とのやり取り⽅法を⽰します。
1 (特定の Windows イベントログチャネルに対して、GUID オブジェクトや
SID オブジェクトなどの Active Directory オブジェクトを正規名に解決す
る) および 0 (解決は⾏わない) を指定できます。
1 を設定した場合、必要に応じてドメインコントローラ名やバインド先ドメ
インの DNS 名を指定することができます。Splunk はこれを使って、Active
Directory オブジェクトを解決します。
この値を設定しない場合は、Splunk が Active Directory オブジェクトの解
決を試みます。
N/A
Active Directory オブジェクトを解決するためにバインドする、Active
Directory ドメインコントローラを指定します。
これには、ドメインコントローラの NetBIOS 名または完全修飾 DNS 名を使
⽤できます。
どちらの種類の名前でも、必要に応じて前に 2 ⽂字の円記号 (バックスラッ
シュ) を付けることができます。
N/A
Active Directory オブジェクトを解決するためにバインドする、ドメインの
完全修飾 DNS 名を指定します。
0
セキュリティイベントに付属のメッセージテキストを含めるかどうかを指定
します。
1 はメッセージテキストを抑制します。0 はテキストを保持します。
N/A
指定したテキスト⽂字列に⼀致するイベントのインデックスを作成します。
この属性は省略することができます。
2 種類のいずれかのフォーマットで指定することができます。
1 つまたは複数のイベントログイベントコードまたはイベント ID。
1 つまたは複数のキーと正規表現のセット。詳細は、このトピックの後
半にある「whitelist と blacklist による ⾼度なフィルタの作成」を参照
してください。
単⼀の項⽬に、複数のフォーマットを混在して指定することはできません。
また、同じスタンザ内に複数のフォーマットを混在指定することもできませ
ん。
Splunk Enterprise は、まずホワイトリストを処理した後に、ブラックリス
トを処理します。
ホワイトリストがない場合は、すべてのイベントのインデックスが作成され
ます。
イベントコード/ID フォーマットを使⽤する場合：
複数のコード/ID を使⽤する場合は、カンマで区切ります。
範囲を指定する場合は、ハイフンを使⽤します (例：0-1000,5000-1000)。
⾼度なフィルタリングフォーマットを使⽤する場合：
⾼度なフィルタリングの場合、フィルタを表すキーと正規表現の間には「=」
を使⽤します (例：whitelist = EventCode=%^1([8-9])$%)。
単⼀の⾼度なフィルタリング項⽬内に、複数のキー/正規表現のセットを指定
することができます。Splunk Enterprise は論理的に各セットを結合しま
す。つまり、エントリ内のすべてのセットが 真 (True) の場合にのみ、その
エントリは有効になります。
whitelist 属性の最後に数字を付けることで、スタンザあたり最⾼ 10 件のホ
ワイトリストを指定することができます (例：whitelist1...whitelist9)。
blacklist
指定されたテキスト⽂字列に⼀致するイベントのインデックスを作成しな
い ことを指定します。
この属性は省略することができます。
2 種類のいずれかのフォーマットで指定することができます。
1 つまたは複数のイベントログイベントコードまたはイベント ID。
1 つまたは複数のキーと正規表現のセット。詳細は、このトピックの後
半にある「whitelist と blacklist による ⾼度なフィルタの作成」を参照
してください。
単⼀の項⽬に、複数のフォーマットを混在して指定することはできません。
また、同じスタンザ内に複数のフォーマットを混在指定することもできませ
ん。
56
Splunk Enterprise は、まずホワイトリストを処理した後に、ブラックリス
トを処理します。
ブラックリストがない場合は、すべてのイベントのインデックスが作成され
ます。
イベントログコード/ID フォーマットを使⽤する場合：
複数のコード/ID を使⽤する場合は、カンマで区切ります。
範囲を指定する場合は、ハイフンを使⽤します (例：0-1000,5000-1000)。
⾼度なフィルタリングフォーマットを使⽤する場合：
⾼度なフィルタリングの場合、フィルタを表すキーと正規表現の間には「=」
を使⽤します (例：blacklist = EventCode=%^1([8-9])$%)。
単⼀の⾼度なフィルタリング項⽬内に、複数のキー/正規表現のセットを指定
することができます。Splunk Enterprise は論理的に各セットを結合しま
す。つまり、エントリ内のすべてのセットが 真 (True) の場合にのみ、その
エントリは有効になります。
blacklist 属性の最後に数字を付けることで、スタンザあたり最⾼ 10 件のブ
ラックリストを指定することができます (例：blacklist1...blacklist9)。
renderXml
index
disabled
イベント・データを Windows イベント・ログ・サブシステムが提供する
XML として表⽰することを指⽰します。
この属性は省略することができます。
「1」または「true」を指定すると、イベントが XML として表⽰されます。
「0」または「false」を指定すると、イベントが普通のテキストとして表⽰
されます。
この⼊⼒がデータを送るインデックスを指定します。
0
(false)
デフォ
ルトの
イン
デック
ス
0
⼊⼒を実⾏するかどうかを指定します。
0 (⼊⼒を実⾏する) および 1 (⼊⼒を実⾏しない ) を指定できます。
セキュリティイベントログを使ったファイル変更のモニター
システム上のファイル変更をモニターするには、⼀連のファイル/ディレクトリのセキュリティ監査を有効にし
て、次にセキュリティイベントログチャネルの変更イベントをモニターします。イベントログモニタリング⼊⼒に
は、inputs.conf で使⽤できる 3 種類の属性が含まれています。以下に例を⽰します。
[WinEventLog://Security]
disabled = 0
start_from = oldest
current_only = 0
evt_resolve_ad_obj = 1
checkpointInterval = 5
# only index events with these event IDs.
whitelist = 0-2000,3001-10000
# exclude these event IDs from being indexed.
blacklist = 2001-3000
⼀連のファイル/ディレクトリのセキュリティ監査を有効にするには、MS Technet の「セキュリティ イベントの
監査の操作⽅法」 (http://technet.microsoft.com/ja-jp/library/cc727935%28v=ws.10%29.aspx) を参照して
ください。
また、suppress_text 属性を使って、セキュリティイベントに付いているメッセージテキストを含めるまたは除外す
ることもできます。
[WinEventLog://Security]
disabled = 0
start_from = oldest
current_only = 0
evt_resolve_ad_obj = 1
checkpointInterval = 5
# suppress message text, we only want the event number.
suppress_text = 1
# only index events with these event IDs.
whitelist = 0-2000,2001-10000
# exclude these event IDs from being indexed.
blacklist = 2001-3000
57
デフォルトで、suppress_text は 0 (偽 (False)) です。
「ホワイトリスト」と「ブラックリスト」による⾼度なフィルタの作成
イベントコードに基づいたフィルタリングに加えて、whitelist および blacklist 属性を使って、到着したイベント
をさらにフィルタリングすることができます。そのためには、属性にキー/正規表現を指定します。
whitelist = key=<regular expression> [key=<regular expression] ...
このフォーマットで、key は以下のリストからの有効なエントリです。
キー
説明
$TimeGenerated イベントを⽣成したコンピュータの時刻。イベントの時刻⽂字列のみが⽣成されます。
$Timestamp
イベント・ログ・サービスがイベントを受信、記録した時刻。イベントの時刻⽂字列のみが
⽣成されます。
Category
特定のイベント・ソースのカテゴリ番号。
CategoryString
カテゴリの⽂字列変換。変換はイベント・ソースによって異なります。
ComputerName
イベントを⽣成したコンピュータ名。
EventCode
イベントのイベント ID 番号。イベント・ビューアでのイベント ID に対応しています。
EventType
ログに記録できる 5 種類のイベント (「Error」、「Warning」、「Information」、
「Success Audit」、および「Failure Audit」) のいずれかを表す数値。Windows Server
2003 以前が動作するサーバーまたは Windows XP 以前が動作するクライアント・マシン上
でのみ利⽤できます。MSDN の「Win32_NTLogEvent class (Windows)」
(http://msdn.microsoft.com/en-us/library/aa394226(v=vs.85).aspx) を参照してくださ
い。
Keywords
イベント・ログ・チャネル内の異なるタイプのイベントを分類するために使⽤されるエレメ
ント。たとえば、セキュリティ・イベント・ログ・チャネルがこのエレメントを保有してい
ます。
LogName
イベントを受信したイベント・ログ・チャネル名。イベント・ビューアのログ名に対応して
います。
Message
イベント内のメッセージ・テキスト。
OpCode
イベントの重⼤度レベル (イベント・ビューアの「オペコード」)。
RecordNumber
Windows イベント・ログのレコード番号。Windows サーバー上の各イベントがレコード番
号を受け取ります。システム上で最初に⽣成されたイベントの番号が 0 で始まり、最⼤数の
4294967295 に達するまで新たなイベントが⽣成されるたびに値が増加していきます。最
⼤値に達すると、再び 0 に戻ります。
Sid
イベントに関連する、またはイベントを⽣成したプリンシパル (ユーザー、グループ、コン
ピュータ、または他のエンティティなど) のセキュリティ ID (SID)。MSDN の
「Win32_UserAccount class」(http://msdn.microsoft.com/enus/library/windows/desktop/aa394507%28v=vs.85%29.aspx) を参照してください。
SidType
イベントに関連付けられている SID のタイプを表す数値。MSDN の
「Win32_UserAccount class」(http://msdn.microsoft.com/enus/library/windows/desktop/aa394507%28v=vs.85%29.aspx) を参照してください。
SourceName
イベントを⽣成したエンティティのソース (イベント・ビューアの「ソース」)。
TaskCategory
イベントのタスク・カテゴリ。イベント・ソースでカテゴリを定義して、イベント・ビュー
アでの表⽰時にフィルタリングを⾏えます ([タスク・カテゴリ] フィールドを使⽤)。MSDN
の「Event Categories (Windows)」 (http://msdn.microsoft.com/enus/library/aa363649%28VS.85%29.aspx) を参照してください。
Type
ログに記録できる 5 種類のイベント (「Error」、「Warning」、「Information」、
「Success Audit」、および「Failure Audit」) のいずれかを表す数値。Windows Server
2008 以降が動作するサーバー・マシン、または Windows Vista 以降が動作するクライアン
トでのみ利⽤できます。MSDN の「Win32_NTLogEvent class (Windows)」
(http://msdn.microsoft.com/en-us/library/aa394226(v=vs.85).aspx) を参照してくださ
い。
User
イベントに関連するユーザー。イベント・ビューアの「ユーザー」に対応しています。
は含める (whitelist 属性と⼀緒に使⽤) または除外する (blacklist 属性と⼀緒に使⽤) フィル
タを表す、有効な正規表現です。
<regular expression>
正規表現の詳細と使⽤⽅法については、Regularexpressions.info (http://www.regular-expressions.info) Web
サイトを参照してください。
単⼀のエントリ⾏に、複数のキー/正規表現セットを指定することができます。そうした場合、それらのセットは
論理的に連結されます。つまり、すべてのセットを満たすイベントのみが、含める/除外の対象となります。例：
whitelist = EventCode="^1([0-5])$" Message="^Error"
58
この場合、EventCode が 10〜15 で、単語
Error
を含む
Message
があるイベントが含められます。
各スタンザには、最⼤で 10 件の個別のホワイトリストまたはブラックリストエントリを指定することができま
す。そのためには、個別の⾏の whitelist または blacklist エントリに、数字を付けます。
whitelist = key=<regular expression>
whitelist1 = key=<regular expression> key2=<regular expression 2>
whitelist2 = key=<regular expression>
注意： 同じキーを参照する、複数のキー/正規表現セットを持つエントリを指定することはできません。たとえ
ば、以下のように指定すると：
whitelist = EventCode="^1([0-5])$" EventCode="^2([0-5])$"
最初のセットは無視されて、2 番⽬のセットに⼀致するイベントのみが含められます。この場合、EventCode が 20
〜25 のイベントのみが⼀致します。EventCode が 10〜15 のイベントは⼀致にはなりません。エントリの最後の
セットのみが照合されます。
この問題に対処するには、スタンザ内に 2 つの個別のエントリを指定します。
whitelist = EventCode="^1([0-5])$"
whitelist1 = EventCode="^2([0-5])$"
イベントログファイル内の Active Directory オブジェクトの解決
特定のイベントログチャネルに対して、グローバル⼀意識別⼦ (GUID) やセキュリティ識別⼦ (SID) などの
Active Directory オブジェクトを解決するかどうかを指定するには、inputs.conf のローカルコピーの、該当する
チャネルのスタンザに evt_resolve_ad_obj 属性を指定します (1=有効、0=無効)。デフォルトでは、セキュリティ
チャネルに対して evt_resolve_ad_obj 属性がオンになっています。
例：
[WinEventLog://Security]
disabled = 0
start_from = oldest
current_only = 0
evt_resolve_ad_obj = 1
checkpointInterval = 5
Active Directory オブジェクトを解決するために、Splunk がバインドする必要があるドメインのドメインコント
ローラを指定するには、evt_dc_name 属性を使⽤します。
属性に指定する⽂字列は、ドメインコントローラの NetBIOS 名または完全修飾ドメイン名 (FQDN)
でなければなりません。どちらの種類の名前でも、必要に応じて前に 2 ⽂字の円記号 (バックスラッシュ) を付け
ることができます。
evt_dc_name
正しい形式のドメインコントローラ名を使⽤した例を以下に⽰します。
FTW-DC-01
\\FTW-DC-01
FTW-DC-01.splunk.com
\\FTW-DC-01.splunk.com
バインドするドメインの完全修飾ドメイン名を指定するには、evt_dns_name 属性を使⽤します。
例：
[WinEventLog://Security]
disabled = 0
start_from = oldest
current_only = 0
evt_resolve_ad_obj = 1
evt_dc_name = ftw-dc-01.splunk.com
evt_dns_name = splunk.com
checkpointInterval = 5
制約
evt_dc_resolve_obj
属性の使⽤時には、いくつかの理解しておく必要がある事項があります。
この属性を指定すると、Splunk はまず
evt_dc_name
属性に指定されているドメインコントローラを使⽤し
59
て、SID および GUID の解決を試みます。そのドメインコントローラを使って SID を解決できなかった場
合、デフォルトのドメインコントローラにバインドして解決を試みます。
SID を解決するためのドメインコントローラと通信できなかった場合は、次にローカルマシンを使った解決
が試みられます。
これらの⼿段がどれも利⽤できなかった場合、Splunk はイベントに捕捉された SID を出⼒します。
Splunk は、S-1-N-NN-NNNNNNNNNN-NNNNNNNNNN-NNNNNNNNNN-NNNN の形式ではない SID を解決することはできませ
ん。
Splunk が SID を適切に解決/変換できていない場合は、インデクサーの splunkd.log を参照して問題を調査
してください。
もっとも早いまたは最新のイベントからインデックス作成を開始するかどうかの指定
Splunk Enterprise がもっとも早いイベントまたは最新のイベントからインデックスの作成を開始するかどうかを
指定するには、start_from 属性を使⽤します。デフォルトで、Splunk はもっとも古いデータからインデックスの
作成を開始して、新しいデータへと進んでいきます。変更するには、この属性に newest を設定します。この場
合、最新のイベントからインデックスの作成が開始され、古いデータへと処理を進めます。Splunk はこの⽅法を
使ってバックログのインデックスを作成した後、インデックス作成を中⽌するため、この設定を変更することはお
勧めできません。
特定のログチャネルにある既存のすべてのイベントのインデックスを作成するかどうかを指定するに
は、current_only 属性を使⽤します。1 を設定すると、Splunk が開始された時点から新たに登場したイベントの
み、インデックスが作成されます。0 を設定すると、すべてのイベントのインデックスが作成されます。
例：
[WinEventLog://Application]
disabled = 0
start_from = oldest
current_only = 1
イベントを XML で表⽰
イベントを XML で⽣成するには、renderXml 属性を使⽤します。
[WinEventLog://System]
disabled = 0
renderXml = 1
evt_resolve_ad_obj = 1
evt_dns_name = \"SV5DC02\"
この⼊⼒スタンザは、以下のようなイベントを⽣成します。
<Event xmlns='http://schemas.microsoft.com/win/2004/08/events/event'>
<System>
<Provider Name='Service Control Manager' Guid='{555908d1-a6d7-4695-8e1e-26931d2012f4}' EventSourceName='Service
Control Manager'/>
<EventID Qualifiers='16384'>7036</EventID>
<Version>0</Version>
<Level>4</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x8080000000000000</Keywords>
<TimeCreated SystemTime='2014-04-24T18:38:37.868683300Z'/>
<EventRecordID>412598</EventRecordID>
<Correlation/>
<Execution ProcessID='192' ThreadID='210980'/>
<Channel>System</Channel>
<Computer>SplunkDoc.splunk-docs.local</Computer>
<Security/>
</System>
<EventData>
<Data Name='param1'>Application Experience</Data>
<Data Name='param2'>stopped</Data>
<Binary>410065004C006F006F006B00750070005300760063002F0031000000</Binary>
</EventData>
</Event>
注意： イベントを XML で表⽰するように設定した場合、XML 内のイベント・キーはマシンのシステム⾔語に関
係なく英語で⽣成されます。フランス語版の Windows サーバーで⽣成された以下のイベントを⽐較してくださ
い。
標準イベント：
60
04/29/2014 02:50:23 PM
LogName=Security
SourceName=Microsoft Windows security auditing.
EventCode=4672
EventType=0
Type=Information
ComputerName=sacreblue
TaskCategory=Ouverture de session spéciale
OpCode=Informations
RecordNumber=2746
Keywords=Succès de l’audit
Message=Privilèges spéciaux attribués Ã
la nouvelle ouverture de session.
Sujet :
ID de sécurité :
AUTORITE NT\Système
Nom du compte :
Système
Domaine du compte :
AUTORITE NT
ID d’ouverture de session :
Privilèges :
0x3e7
SeAssignPrimaryTokenPrivilege
SeTcbPrivilege
SeSecurityPrivilege
SeTakeOwnershipPrivilege
SeLoadDriverPrivilege
SeBackupPrivilege
SeRestorePrivilege
SeDebugPrivilege
SeAuditPrivilege
SeSystemEnvironmentPrivilege
SeImpersonatePrivilege
XML イベント：
<Event xmlns='http://schemas.microsoft.com/win/2004/08/events/event'>
<System><Provider Name='Microsoft-Windows-Security-Auditing' Guid='{54849625-5478-4994-A5BA3E3B0328C30D}'/>
<EventID>4672</EventID>
<Version>0</Version>
<Level>0</Level>
<Task>12548</Task>
<Opcode>0</Opcode>
<Keywords>0x8020000000000000</Keywords>
<TimeCreated SystemTime='2014-04-29T22:15:03.280843700Z'/>
<EventRecordID>2756</EventRecordID>
<Correlation/><Execution ProcessID='540' ThreadID='372'/>
<Channel>Security</Channel>
<Computer>sacreblue</Computer>
<Security/>
</System>
<EventData>
<Data Name='SubjectUserSid'>AUTORITE NT\Système</Data>
<Data Name='SubjectUserName'>Système</Data>
<Data Name='SubjectDomainName'>AUTORITE NT</Data>
<Data Name='SubjectLogonId'>0x3e7</Data>
<Data Name='PrivilegeList'>SeAssignPrimaryTokenPrivilege
SeTcbPrivilege
SeSecurityPrivilege
SeTakeOwnershipPrivilege
SeLoadDriverPrivilege
SeBackupPrivilege
SeRestorePrivilege
SeDebugPrivilege
SeAuditPrivilege
SeSystemEnvironmentPrivilege
SeImpersonatePrivilege</Data>
</EventData>
</Event>
XML イベント内の
されます。
Data Name
キーは、標準イベントではシステムの使⽤⾔語で表⽰される場合でも、英語で表⽰
61
CLI を使ったローカル・イベント・ログのモニタリング
CLI を使って、ローカル・イベント・ログのモニタリングを設定できます。CLI を使⽤する前に、inputs.conf に
スタンザのエントリを作成する必要があります。「inputs.conf を使ったイベント・ログ・モニタリングの設定」
を参照してください。
注意： リモート・イベント・ログ・コレクションに対しては、CLI を使⽤できません。
ローカルマシン上に設定されているすべてのイベント・ログ・チャネルを表⽰するには：
> splunk list eventlog
名前を指定することで、特定のチャネルを表⽰することもできます：
> splunk list eventlog <ChannelName>
イベント・ログ・チャネルを有効にするには：
> splunk enable eventlog <ChannelName>
チャネルを無効にするには：
> splunk disable eventlog <ChannelName>
エクスポートされたイベントログ (.evt または .evtx) ファイルのインデックスの作成
エクスポートした Windows イベントログファイルのインデックスを作成するには、ファイルとディレクトリのモ
ニターの説明に従って、エクスポートしたファイルを保管しているディレクトリをモニターします。
制約
Windows XP および Server 2003 システムでは API とログチャネルの処理上の制約により、それらのシス
テムからインポートした .evt ファイルには、「Message」フィールドが含まれていません。つまり、
「Message」フィールドの内容が、Splunk インデックスには含まれません。
Windows XP および Windows Server 2003/2003 R2 上で動作している Splunk は、Windows Vista 以降
または Windows Server 2008/2008 R2 以降が動作しているシステムからエクスポートされた、.evtx ファ
イルのインデックスを作成できません。
Windows Vista 以降および Windows Server 2008/2008 R2 以降上で動作する Splunk は、.evt および
.evtx の両⽅のファイルのインデックスを作成することができます。
.evt または .evtx ファイルが標準のイベントログチャネルからのファイルでない場合は、そのチャネルが必
要とする DLL ファイルが、インデックスを作成するコンピュータ上にあることを確認する必要がありま
す。
.evt または .evtx ファイルのインデックスは、それを収集したコンピュータのプライマリロケール/⾔語で作
成されます。
警告： 現在書き込み中の .evt または .evtx ファイルのモニターは、試みないようにしてください。Windows
は、そのようなファイルに対する読み取りアクセスを禁⽌しています。代わりにイベントログのモニタリング機能
を使⽤してください。
注意： あるシステム上で .evt または .evtx ファイルを⽣成し、それを別のシステムでモニターする場合、イベン
トを⽣成したシステムのように、各イベントの⼀部のフィールドが展開されない可能性があります。この問題は
DLL のバージョンの違い、DLL の有無、API のバリエーションなどが原因です。OS のバージョン、⾔語、
Service Pack のレベル、およびインストールされているサードパーティ製 DLL などの要因により、この問題が
発⽣することもあります。
Answers
何か質問がありますか？「Splunk Answers」では、Splunk コミュニティに寄せられた、Windows イベントログ
に関する質問と回答をご覧いただけます。
Windows のファイルシステム変更のモニター
Splunk Enterprise は Windows ファイルシステムの変更を、セキュリティイベントログチャネルを介してモニ
ターすることができます。ファイルやディレクトリに対する変更のモニタリングを有効にするには、まず変更をモ
ニターするファイル/ディレクトリのセキュリティ監査を有効にします。次に、イベントログモニター機能で、セ
キュリティイベントログチャネルをモニターします。
このファイルシステム変更のモニター⼿順は、廃⽌予定のファイルシステムモニター⼊⼒に代わるものです。
ファイル・システム変更のモニターに何が必要か？
アクティビ
ティ：
ファイルシ
ステム変更
必要なアクセス許可：
Splunk Enterprise は Windows 上で実⾏する必要があります、および
62
の監視
Splunk Enterprise は Local System ユーザー、またはセキュリティイベントログを読み取
るための、特定のセキュリティポリシー権限を持つドメインユーザーとして実⾏する必要が
あります、および
変更をモニターするファイル/ディレクトリのセキュリティ監査を有効にする必要がありま
す。
セキュリティイベントログを使ったファイル変更のモニター
システム上のファイル変更をモニターするには、⼀連のファイル/ディレクトリのセキュリティ監査を有効にし
て、次にセキュリティイベントログチャネルの変更イベントをモニターします。イベントログモニタリング⼊⼒に
は、inputs.conf で使⽤できる 3 種類の属性が含まれています。
属性
whitelist
説明
デ
フォ
ルト
N/A
指定したテキスト⽂字列に⼀致するイベントのインデックスを作成します。
この属性は省略することができます。
2 種類のいずれかのフォーマットで指定することができます。
1 つまたは複数のイベントログイベントコードまたはイベント ID。
1 つまたは複数のキーと正規表現のセット。詳細は、このトピックの後半にあ
る「whitelist と blacklist による ⾼度なフィルタの作成」を参照してくださ
い。
単⼀の項⽬に、複数のフォーマットを混在して指定することはできません。
また、同じスタンザ内に複数のフォーマットを混在指定することもできません。
Splunk Enterprise は、まずホワイトリストを処理した後に、ブラックリストを処理
します。
ホワイトリストがない場合は、すべてのイベントのインデックスが作成されます。
イベントコード/ID フォーマットを使⽤する場合：
複数のコード/ID を使⽤する場合は、カンマで区切ります。
範囲を指定する場合は、ハイフンを使⽤します (例：0-1000,5000-1000)。
⾼度なフィルタリングフォーマットを使⽤する場合：
⾼度なフィルタリングの場合、フィルタを表すキーと正規表現の間には「=」を使⽤
します (例：whitelist = EventCode=%^1([8-9])$%)。
単⼀の⾼度なフィルタリング項⽬内に、複数のキー/正規表現のセットを指定するこ
とができます。Splunk Enterprise は論理的に各セットを結合します。つまり、エン
トリ内のすべてのセットが 真 (True) の場合にのみ、そのエントリは有効になりま
す。
whitelist 属性の最後に数字を付けることで、スタンザあたり最⾼ 10 件のホワイトリ
ストを指定することができます (例：whitelist1...whitelist9)。
blacklist
指定されたテキスト⽂字列に⼀致するイベントのインデックスを作成しない ことを指
定します。
この属性は省略することができます。
2 種類のいずれかのフォーマットで指定することができます。
1 つまたは複数のイベントログイベントコードまたはイベント ID。
1 つまたは複数のキーと正規表現のセット。詳細は、このトピックの後半にあ
る「whitelist と blacklist による ⾼度なフィルタの作成」を参照してくださ
い。
単⼀の項⽬に、複数のフォーマットを混在して指定することはできません。
また、同じスタンザ内に複数のフォーマットを混在指定することもできません。
Splunk Enterprise は、まずホワイトリストを処理した後に、ブラックリストを処理
します。
ブラックリストがない場合は、すべてのイベントのインデックスが作成されます。
イベントログコード/ID フォーマットを使⽤する場合：
複数のコード/ID を使⽤する場合は、カンマで区切ります。
範囲を指定する場合は、ハイフンを使⽤します (例：0-1000,5000-1000)。
⾼度なフィルタリングフォーマットを使⽤する場合：
⾼度なフィルタリングの場合、フィルタを表すキーと正規表現の間には「=」を使⽤
します (例：blacklist = EventCode=%^1([8-9])$%)。
単⼀の⾼度なフィルタリング項⽬内に、複数のキー/正規表現のセットを指定するこ
とができます。Splunk Enterprise は論理的に各セットを結合します。つまり、エン
トリ内のすべてのセットが 真 (True) の場合にのみ、そのエントリは有効になりま
す。
blacklist 属性の最後に数字を付けることで、スタンザあたり最⾼ 10 件のブラックリ
ストを指定することができます (例：blacklist1...blacklist9)。
suppress_text
セキュリティイベントに付属のメッセージテキストを含めるかどうかを指定します。1 は
メッセージテキストを抑制します。0 はテキストを保持します。
63
0
注意： これらの属性は、セキュリティイベントログおよびファイルシステム変更のコンテキスト外で使⽤できま
す。また、これらの属性リストは inputs.conf で利⽤できる属性の⼀部でしかありません。その他の属性について
は、このマニュアルの「Windows イベントログデータのモニター 」を参照してください。
⾼度なフィルタの作成： whitelist および
blacklist
イベントコードに基づいたフィルタリングに加えて、whitelist および blacklist 属性を使って、到着したイベント
をさらにフィルタリングすることができます。そのためには、属性にキー/正規表現を指定します。
whitelist = key=<regular expression> [key=<regular expression] ...
このフォーマットで、key は以下のリストからの有効なエントリです。
キー
説明
$TimeGenerated イベントを⽣成したコンピュータの時刻。イベントの時刻⽂字列のみが⽣成されます。
$Timestamp
イベント・ログ・サービスがイベントを受信、記録した時刻。イベントの時刻⽂字列のみが
⽣成されます。
Category
特定のイベント・ソースのカテゴリ番号。
CategoryString
カテゴリの⽂字列変換。変換はイベント・ソースによって異なります。
ComputerName
イベントを⽣成したコンピュータ名。
EventCode
イベントのイベント ID 番号。イベント・ビューアでのイベント ID に対応しています。
EventType
ログに記録できる 5 種類のイベント (「Error」、「Warning」、「Information」、
「Success Audit」、および「Failure Audit」) のいずれかを表す数値。Windows Server
2003 以前が動作するサーバーまたは Windows XP 以前が動作するクライアント・マシン上
でのみ利⽤できます。MSDN の「Win32_NTLogEvent class (Windows)」
(http://msdn.microsoft.com/en-us/library/aa394226(v=vs.85).aspx) を参照してくださ
い。
Keywords
イベント・ログ・チャネル内の異なるタイプのイベントを分類するために使⽤されるエレメ
ント。たとえば、セキュリティ・イベント・ログ・チャネルがこのエレメントを保有してい
ます。
LogName
イベントを受信したイベント・ログ・チャネル名。イベント・ビューアのログ名に対応して
います。
Message
イベント内のメッセージ・テキスト。
OpCode
イベントの重⼤度レベル (イベント・ビューアの「オペコード」)。
RecordNumber
Windows イベント・ログのレコード番号。Windows サーバー上の各イベントがレコード番
号を受け取ります。システム上で最初に⽣成されたイベントの番号が 0 で始まり、最⼤数の
4294967295 に達するまで新たなイベントが⽣成されるたびに値が増加していきます。最
⼤値に達すると、再び 0 に戻ります。
Sid
イベントに関連する、またはイベントを⽣成したプリンシパル (ユーザー、グループ、コン
ピュータ、または他のエンティティなど) のセキュリティ ID (SID)。MSDN の
「Win32_UserAccount class」(http://msdn.microsoft.com/enus/library/windows/desktop/aa394507%28v=vs.85%29.aspx) を参照してください。
SidType
イベントに関連付けられている SID のタイプを表す数値。MSDN の
「Win32_UserAccount class」(http://msdn.microsoft.com/enus/library/windows/desktop/aa394507%28v=vs.85%29.aspx) を参照してください。
SourceName
イベントを⽣成したエンティティのソース (イベント・ビューアの「ソース」)。
TaskCategory
イベントのタスク・カテゴリ。イベント・ソースでカテゴリを定義して、イベント・ビュー
アでの表⽰時にフィルタリングを⾏えます ([タスク・カテゴリ] フィールドを使⽤)。MSDN
の「Event Categories (Windows)」 (http://msdn.microsoft.com/enus/library/aa363649%28VS.85%29.aspx) を参照してください。
Type
ログに記録できる 5 種類のイベント (「Error」、「Warning」、「Information」、
「Success Audit」、および「Failure Audit」) のいずれかを表す数値。Windows Server
2008 以降が動作するサーバー・マシン、または Windows Vista 以降が動作するクライアン
トでのみ利⽤できます。MSDN の「Win32_NTLogEvent class (Windows)」
(http://msdn.microsoft.com/en-us/library/aa394226(v=vs.85).aspx) を参照してくださ
い。
User
イベントに関連するユーザー。イベント・ビューアの「ユーザー」に対応しています。
は含める (whitelist 属性と⼀緒に使⽤) または除外する (blacklist 属性と⼀緒に使⽤) フィル
タを表す、有効な正規表現です。
<regular expression>
正規表現の詳細と使⽤⽅法については、Regularexpressions.info (http://www.regular-expressions.info) Web
サイトを参照してください。
単⼀のエントリ⾏に、複数の正規表現を指定することができます。そうした場合、それらの式は論理的に連結され
ます。つまり、その⾏のすべての式を満たすイベントのみが、含める/除外の対象となります。例：
64
whitelist = EventCode="^1([0-5])$" Message="^Error"
この場合、EventCode が 10〜15 で、単語
Error
を含む
Message
があるイベントが含められます。
各スタンザには、最⼤で 10 件の個別のホワイトリストまたはブラックリストエントリを指定することができま
す。そのためには、個別の⾏の whitelist または blacklist エントリに、数字を付けます。
whitelist = key=<regular expression>
whitelist1 = key=<regular expression> key2=<regular expression 2>
whitelist2 = key=<regular expression>
注意： 同じキーを参照する、複数の式を持つエントリを指定することはできません。たとえば、以下のように指
定すると：
whitelist = EventCode="^1([0-5])$" EventCode="^2([0-5])$"
最初の式は無視されて、2 番⽬の式に⼀致するイベントのみが含められます。この場合、EventCode が 20〜25 の
イベントのみが⼀致します。EventCode が 10〜15 のイベントは⼀致にはなりません。エントリの最後の式のみが
照合されます。
この問題に対処するには、スタンザ内に 2 つの個別のエントリを指定します。
whitelist = EventCode="^1([0-5])$"
whitelist1 = EventCode="^2([0-5])$"
ファイルシステム変更の監視
⼀連のファイル/ディレクトリに対するファイルシステムの変更をモニターするには：
1. MS Technet の「セキュリティ イベントの監査の操作⽅法」 (http://technet.microsoft.com/jajp/library/cc727935%28v=ws.10%29.aspx) を参考に、セキュリティを有効にします。
重要： この作業を⾏うには、管理者権限が必要です。
2. セキュリティイベントログチャネルをモニターするように、イベントログモニター⼊⼒を設定します。
注意： イベントログモニター⼊⼒の設定⽅法については、このマニュアルの「Windows イベントログデータの
モニター 」を参照してください。
例
ファイルシステム変更をモニターするための、inputs.conf スタンザの例を以下に⽰します。
このスタンザは、イベント ID コードが 0〜2000、および 3001〜10000 のセキュリティイベントを収集しま
す。
[WinEventLog:Security]
disabled = 0
start_from = oldest
current_only = 0
evt_resolve_ad_obj = 1
checkpointInterval = 5
# only index events with these event IDs.
whitelist = 0-2000,2001-10000
# exclude these event IDs from being indexed.
blacklist = 2001-3000
このスタンザは、イベント ID コードが 0〜2000、および 3001〜10000 のセキュリティイベントを収集しま
す。また、特定のイベント ID のメッセージテキストを抑制します。
[WinEventLog:Security]
disabled = 0
start_from = oldest
current_only = 0
evt_resolve_ad_obj = 1
checkpointInterval = 5
# suppress message text, we only want the event number.
suppress_text = 1
# only index events with these event IDs.
whitelist = 0-2000,2001-10000
# exclude these event IDs from being indexed.
blacklist = 2001-3000
65
WMI ベースのデータのモニター
Splunk Enterprise では、リモートマシン上のパフォーマンスおよびイベントログデータにエージェントレスでア
クセスするために、WMI を使⽤することができます。このことは、環境内のすべての Windows マシンに何もイ
ンストールすることなく、それらのマシンからイベント・ログを収集できることを意味しています。
重要： 可能な場合は、WMI ではなく ユニバーサル・フォワーダーを使ってリモート・マシンからデータを収集し
てください。多くの場合 WMI のリソース負荷は、ユニバーサルフォワーダーよりも⾼くなります。特に、各ホス
トから複数のイベント・ログやパフォーマンス・カウンタを収集する場合、またはドメイン・コントローラのよう
な処理負荷が⼤きなホストに対しては、フォワーダーを使⽤してください。このマニュアルの「リモート
Windows データのモニター⽅法決定の検討事項」を参照してください。
WMI ベースのデータ⼊⼒は、複数の WMI プロバイダに接続できます。⼊⼒は、splunk-wmi.exe と呼ばれる別個の
プロセスとして実⾏されます。これはスクリプト⼊⼒ です。
WMI ベースのデータのモニターに何が必要か？
WMI ベースのデータをモニターするための、最低の基本要件を以下に⽰します。モニターするログやパフォーマ
ンスカウンタによっては、他のアクセス許可が必要になることもあります。
WMI ベースのデータのモニターに必要な事項については、このトピック後半の「セキュリティとリモート・アク
セスの検討事項」を参照してください。
アクティビティ：
必要なアクセス許可：
WMI 経由のリモートイベントロ
グのモニター
* Splunk Enterprise は Windows 上で実⾏する必要があります。
* Splunk Enterprise は、最低でも WMI への読み取りアクセスを持つドメイ
ンユーザーとして実⾏する必要があります。
* Splunk Enterprise は、⽬的のイベントログへの適切なアクセス権を持つ、
ドメインユーザーとして実⾏する必要があります。
WMI 経由のリモートパフォーマ
ンスモニターカウンタのモニ
ター
* Splunk Enterprise は Windows 上で実⾏する必要があります。
* Splunk Enterprise は、最低でも WMI への読み取りアクセスを持つドメイ
ンユーザーとして実⾏する必要があります。
* Splunk Enterprise は、パフォーマンスデータヘルパーライブラリへの適切
なアクセス権を持つ、ドメインユーザーとして実⾏する必要があります。
セキュリティとリモートアクセスの検討事項
Splunk Enterprise と Windows ネットワークを、WMI データにアクセスするために正しく設定する必要があり
ます。Splunk Enterprise を使って WMI データの収集を試みる前に、以下の前提条件を確認してください。
Splunk Enterprise が WMI ベースのデータを取得する前に：
リモートネットワーク接続を実施するアクセス許可を持つユーザーとしてインストールする必要がありま
す。
Splunk Enterprise を実⾏するユーザーは、Active Directory ドメイン/フォレストのメンバーで、WMI プ
ロバイダにクエリーするための適切な権限を持っている必要があります。
また Splunk Enterprise ユーザーは、Splunk Enterprise を実⾏するコンピュータのローカル
Administrators グループのメンバーでなければなりません。
Splunk Enterprise を実⾏するコンピュータは、リモートマシンに接続でき、また接続後にはリモートマシ
ンから⽬的のデータを取得するための、アクセス許可を保有している必要があります。
Splunk Enterprise インスタンスと、ターゲット・マシンの両⽅が、同じ Active Directory ドメイン/フォ
レストに存在している必要があります。
Splunk ユーザーは Domain Admins グループのメンバーになる必要はありません (セキュリティ上の理由から、
そうしないでください)。ただし、Splunk ユーザーのアクセスを設定するには、ドメイン管理者権限が必要になり
ます。ドメイン管理者権限がない場合は、他の適切な権限を持っているユーザーに、Splunk ユーザー・アクセス
の設定、または⾃分へのドメイン管理者権限の割り当てを依頼してください。
注意： Splunk Enterprise を Local System ユーザーとしてインストールした場合、WMI 経由のリモート認証は
機能しません。Local System ユーザーには、ネットワーク上の他のマシンに対するアクセス権がありません。マ
シンの Local System アカウントに、他のマシンにアクセスするための権限を与えることはできません。
Splunk ユーザーに WMI プロバイダへのアクセス権を割り当てるには、以下のいずれかの作業を⾏います。
ユーザーを、ポーリングを⾏う各メンバーサーバーの、ローカル Administrators グループに追加する (セ
キュリティ上の理由からお勧めできません)。
Domain Admins グローバルグループに追加する (セキュリティ上の理由からお勧めできません)。
後述するように、必要最低限の権限のみを割り当てる (推奨)。
グループメンバーシップとリソースアクセス制御リスト (ACL) に関する重要な注意事項
セキュリティ整合性を維持するためには、Splunk ユーザーをドメイン・グローバル・グループに配置して、ユー
ザーに直接アクセス許可を割り当てる代わりに、そのグループに Windows マシンのアクセス許可とリソース
ACL を割り当てます。ユーザーに直接アクセス許可を割り当てるとセキュリティリスクが⽣じてしまい、セキュ
リティ監査時や将来の変更により問題が発⽣する可能性があります。
必要最低限のアクセスを与えるための WMI の設定
Splunk Enterprise を実⾏するユーザーがドメイン管理者でない場合、そのユーザーにアクセス権を提供するよう
66
に WMI を設定する必要があります。WMI も含めてすべての Windows リソースに対する、必要最低限のアクセ
ス権のみを与えるようにしてください。このようなアクセス権を与えるために、以下のチェックリストに従ってく
ださい。その他の情報と作業⼿順については、『インストール・マニュアル』の「Splunk Enterprise インストー
ル⽤の Windows ネットワークの準備」を参照してください。
WMI 経由でデータを収集するためには、Splunk Enterprise を動作させるユーザーに、「最低限必要な権限を与
える」⼿法で、各レベルのアクセス権を割り当てる必要があります。
1.ローカルセキュリティポリシーアクセス許可。 Splunk ユーザー向けに、WMI ベースのデータをポーリング
する各マシン上で、以下のローカルセキュリティポリシーの、ユーザー権利の割り当てを定義する必要がありま
す。
ネットワーク経由でコンピュータへアクセス
オペレーティング システムの⼀部として機能
バッチジョブとしてログオン
サービスとしてログオン
システム パフォーマンスのプロファイル
プロセスレベルトークンの置き換え
注意： これらのユーザー権利の割り当てをドメイン全体にデプロイするには、ドメイン・セキュリティ・ポリ
シー (dompol.msc) Microsoft 管理コンソール (MMC) スナップインを使⽤します。デプロイが完了すると、それら
の権利割り当ては次回の Active Directory レプリケーション・サイクル時に、ネットワーク上のメンバー・サー
バーに継承されます。変更内容を反映するには、それらのマシン上で Splunk Enterprise インスタンスを再起動
する必要があります。
このアクセスをドメインコントローラにまで拡張するには、ドメインコントローラセキュリティポリシー
(dcpol.msc) スナップインを使って権限を割り当てます。
2.Distributed Component Object Model (DCOM) の設定とアクセス許可。 モニターする各マシン上
で、DCOM を有効にする必要があります。また、Splunk Enterprise ユーザーには、DCOM にアクセスするた
めのアクセス許可を割り当てる必要があります。そのためにはさまざまな⽅法がありますが、「Distributed
COM Users」ドメイン・グローバル・グループを、モニターする各マシン上の「Distributed COM Users」ロー
カル・グループに⼊れ⼦して、次に Splunk ユーザーを「Distributed COM Users」ドメイン・グローバル・グ
ループに追加することをお勧めします。Splunk Enterprise ユーザーに DCOM へのアクセス権を与えるための⾼
度なオプションについては、MSDN の「Securing a Remote WMI Connection」
(http://msdn.microsoft.com/en-us/library/aa393266(VS.85).aspx) を参照してください。
3.パフォーマンスモニターの設定とアクセス許可。 WMI 経由でリモート・パフォーマンス・オブジェクトにア
クセスするには、Splunk Enterprise ユーザーが「Performance Log Users」ローカル・グループのメンバーでな
ければなりません。このためには、「Performance Log Users」ドメイン・グローバル・グループを、各メン
バー・サーバーの「Performance Log Users」ローカル・グループに⼊れ⼦して、次にユーザーをグローバル・
グループに割り当てることをお勧めします。
4.WMI 名前空間のセキュリティ。 Splunk Enterprise がアクセスする WMI 名前空間 (⼀般的には Root\CIMV2)
には、適切なアクセス許可セットが必要です。グローバル WMI セキュリティは存在しないため、企業内の各サー
バーに以下のアクセス許可を設定する必要があります。Splunk ユーザーの Root 名前空間で、各ホストに対して
WMI ツリー上で以下のアクセス許可を有効にするには、WMI セキュリティ MMC スナップイン (wmimgmt.msc) を
使⽤します。
メソッドの実⾏
アカウントの有効化
リモートの有効化
セキュリティの読み取り
これらの権限は、Root 名前空間とその下のすべてのサブ名前空間に割り当てる必要があります。詳細は、
Microsoft サポート技術情報の記事「[HOWTO] Windows Server 2003 で WMI 名前空間のセキュリティを設定
する⽅法」 (http://support.microsoft.com/kb/325353) を参照してください。
重要： グループポリシーを使って、複数のリモートマシンに WMI セキュリティ設定を⼀度にデプロイするため
の、標準機能はありません。ただし、MSDN ブログの「Set WMI namespace security via GPO」
(http://blogs.msdn.com/spatdsg/archive/2007/11/21/set-wmi-namespace-security-via-gpo-script.aspx) に
は、グループ・ポリシー・オブジェクト (GPO) 内に配置できる起動スクリプトの作成⽅法の説明が記載されてい
ます。GPO が⽬的のホストに適⽤されると、このスクリプトが名前空間のセキュリティを設定します。次に
GPO をドメイン全体、または 1 つまたは複数の組織単位 (OU) にデプロイすることができます。
5.ファイアウォールの設定。 ファイアウォールを有効にしている場合、WMI へのアクセスを許可するように設
定する必要があります。最新版の Windows に同梱されている Windows ファイアウォールを使⽤する場合は、例
外リストに WMI が明⽰的に含まれます。この例外は、発信元とターゲットの両⽅のマシンに設定する必要があり
ます。詳細は、MSDN の「Connecting to WMI Remotely Starting with Vista」
(http://msdn.microsoft.com/en-us/library/aa822854(VS.85).aspx) を参照してください。
6.ユーザーアクセス制御 (UAC) の設定。 Windows Vista、Windows 7、Windows 8.1 または Windows
Server 2003/2008/2012 のファミリーを使⽤している場合、UAC が Windows によるアクセス許可の割り当て
⽅法に影響してきます。MSDN の「User Account Control and WMI」 (http://msdn.microsoft.com/enus/library/aa826699(v=vs.85).aspx) を参照してください。
WMI プロバイダへのテストアクセス
WMI を設定して、Splunk ユーザーのドメインへのアクセスを設定したら、リモート・マシンへのアクセスをテ
ストします。
重要： この⼿順には、⼀時的に Splunk Enterprise のデータ保管ディレクトリ (SPLUNK_DB が指している場所) を変
更する作業が含まれています。この作業は、WMI にアクセスする前に⾏う必要があります。そうしないと、WMI
イベントが失われる可能性があります。これは、splunk-wmi.exe プロセスが、実⾏時には毎回 WMI チェックポ
67
イントファイルを更新するためです。
WMI プロバイダにテストアクセスするには：
1. Splunk ユーザーとして Splunk Enterprise を実⾏するマシンにログインします。
注意： ドメインコントローラにログインする場合、ドメインコントローラのセキュリティポリシーを編集して、
そのユーザーに「ローカル ログオンを許可する」ポリシーを割り当てなければならないことがあります。
2. コマンドプロンプトを開きます ([スタート] -> [ファイル名を指定して実⾏] をクリックして、cmd と⼊⼒す
る)。
3. Splunk Enterprise インストールディレクトリ (例：cd
に移動します。
c:\Program Files\Splunk\bin)
下の
bin
サブディレクトリ
4. Splunk Enterprise が現在データを格納している場所を確認します。
> splunk show datastore-dir
注意： この作業を⾏うには、Splunk Enterprise インスタンスの認証を受ける必要があります。確認した Splunk
Enterprise のデータ保管場所は忘れないように記録してください。後ほどの作業で必要になります。
5. 以下のコマンドを実⾏して、⼀時的に Splunk Enterprise データ保管ディレクトリを変更します。
> splunk set datastore-dir %TEMP%
注意： この例では、データ保管ディレクトリを、現在 TEMP 環境変数に指定されているディレクトリに変更しま
す。別のディレクトリを指定することもできますが、そのディレクトリはすでに存在している必要があります。
6. Splunk Enterprise を再起動します。
> splunk restart
注意： Splunk Enterprise の再起動には、少し時間がかかることもあります。これは、ステップ 5 で指定した、
新しいデータ・ストアが作成されるためです。
7. Splunk Enterprise を再起動したら、WMI プロバイダへのアクセスをテストします。ここで、<server> は、リ
モート・サーバー名に置き換えてください。
> splunk cmd splunk-wmi -wql "select * from win32_service" -namespace \\<server>\root\cimv2
8. データがストリーム配信され、エラーメッセージが何も表⽰されなければ、Splunk Enterprise が WMI プロバ
イダに接続できて、クエリーが成功しています。
9. エラーがあった場合は、エラーの理由を⽰すメッセージが表⽰されます。出⼒の
に、問題解決の⼿がかりを探してください。
error="<msg>"
⽂字列を参考
WMI アクセスをテストしたら、以下のコマンドを実⾏してデータベースディレクトリを元の場所に戻してから、
Splunk Enterprise を再起動します。
> splunk set datastore-dir <directory shown from Step 4>
WMI ベースの⼊⼒の設定
Windows 上で Splunk Enterprise が⾏うすべてのリモートデータ収集作業は、WMI プロバイダまたはフォワー
ダーを介して⾏われます。このマニュアルの「リモート Windows データのモニター⽅法決定の検討事項」を参照
してください。
Splunk Web を使って、または設定ファイルを編集して、WMI ベースの⼊⼒を設定することができます。設定
ファイルを使⽤する場合は、より多くのオプションを利⽤することができます。
Splunk Web を使った WMI ベースの⼊⼒の設定
WMI ベースの⼊⼒を追加するには、このマニュアルの適切なトピックを参照してください。
Splunk Web を使ったリモート Windows パフォーマンスモニタリングの設定
リモート Windows イベントログのモニタリングの設定
設定ファイルを使った WMI ベースの⼊⼒の設定
wmi.conf は、リモートデータ収集の設定を担当しています。WMI ベースの⼊⼒のデフォルト値は、このファイ
ルを参照してください。デフォルト値を変更する場合は、%SPLUNK_HOME%\etc\system\local\ 内の wmi.conf のコピーを
編集してください。特定のタイプのデータ⼊⼒の、変更が必要な属性にのみ値を設定してください。『管理マニュ
アル』の「設定ファイルについて」を参照してください。
wmi.conf
には、さまざまなスタンザが存在しています。
スタンザは、グローバル WMI パラメータを指定します。
1 つまたは複数の⼊⼒固有のスタンザは、WMI プロバイダに接続して、リモートマシンからデータを収集す
るための⽅法を定義しています。
[settings]
68
グローバル設定
スタンザは、グローバル WMI パラメータを指定します。スタンザ全体およびその中の各パラメータ
は、すべてオプションで省略することができます。このスタンザがない場合、Splunk Enterprise はデフォルト値
を仮定します。
[settings]
Splunk Enterprise が定義されている WMI プロバイダに接続できない場合、splunkd.log にエラーが記録されま
す。
05-12-2011 02:39:40.632 -0700 ERROR ExecProcessor - message from ""C:\Program Files\Splunk\bin\splunk-wmi.exe"" WMI
- Unable to connect to WMI namespace "\\w2k3m1\root\cimv2" (attempt to connect took 42.06 seconds) (error="The RPC
server is unavailable." HRESULT=800706BA)
以下の属性はエラー発⽣時に、指定されている WMI プロバイダに Splunk Enterprise が再接続する⽅法を定義
します。
属性
説明
デ
フォ
ルト
値
initial_backoff
初めてのエラー発⽣後に、WMI プロバイダへの再接続を試みるまでに待機す
る時間を秒で指定します。引き続き接続エラーが発⽣する場合は、max_backoff
に指定されている値に達するまで、待機時間を 2 倍に増やしながら再試⾏し
ます。
max_backoff
max_retries_at_max_backoff
5
を発⾏するまでに、各接続試⾏間に待機する最⼤秒
20
数を指定します。
max_retries_at_max_backoff
接続試⾏間の待機時間が max_backoff に達した場合に、max_backoff 秒間隔でさ 2
らに再試⾏する回数を指定します。これらの接続試⾏を⾏った後もエラーが発
⽣する場合は、接続が断念されます。Splunk Enterprise を再起動しない限
り、問題のあるプロバイダへの接続は試みられません。ただし、上記の例のよ
うに、エラーの記録は継続されます。
checkpoint_sync_interval
状態データ (イベントログチェックポイント) をディスクに書き込むまでに待
機する秒数を指定します。
2
⼊⼒固有の設定
⼊⼒固有のスタンザは、WMI プロバイダへの接続⽅法を Splunk Enterprise に指⽰しています。これは、
Splunk Enterprise が収集するデータのタイプを⽰す 2 種類のいずれかの属性で定義します。任意のスタンザ名
を使⽤できますが、通常は WMI: から始まる名前を指定します。例：
[WMI:AppAndSys]
Splunk Web で WMI ベースの⼊⼒を設定する場合、Splunk Enterprise はこの命名規則で⼊⼒固有のスタンザの
⾒出しを定義します。
⼊⼒固有のスタンザには、2 種類の中のいずれかのデータ⼊⼒タイプを指定できます。
イベントログ： event_log_file 属性は、スタンザ内に定義されているソースからイベントログデータを収集
することを⽰します。
Windows Query Language (WQL)： wql 属性は、WMI プロバイダからデータを収集する予定であるこ
とを⽰します。この属性を使⽤する場合は、有効な WQL ステートメントも指定する必要があります。パ
フォーマンスデータを収集する場合は、この属性を使⽤する必要があります。
警告： 1 つのスタンザに、これらの両⽅の属性は定義しないでください。どちらか 1 つのみを使⽤してくださ
い。そうしないと、スタンザが定義する⼊⼒は機能しません。
両⽅のタイプの⼊⼒に共通のパラメータを以下に⽰します。
属性
説明
デフォル
ト値
server
データを取得するサーバーのカンマ区切りリスト。このパラメータを指定しない場合、
Splunk Enterprise はローカルマシンへの接続を仮定します。
ローカル
サーバー
interval
新しいデータのポーリングを⾏う頻度を秒で指定します。この属性が指定されていない場
合、スタンザが定義している⼊⼒は機能しません。
N/A
disabled
⼊⼒が有効か無効かを⽰します。⼊⼒を無効にするには 1 を、有効にするには 0 を設定し 0 (有効)
ます。
イベントログ固有のパラメータを以下に⽰します。
属性
説明
デ
フォ
ルト
値
event_log_file
モニターするイベントログチャネルのカンマ区切りリスト。
current_only
稼働中に発⽣したイベントのみを収集するかどうかを⽰します。Splunk 0 (す
69
N/A
current_only
disable_hostname_normalization
Enterprise が停⽌中にイベントが⽣成された場合、その後の再起動時に
それらのイベントのインデックス作成は⾏われません。1 を設定する
と、Splunk Enterprise は稼働中に発⽣したイベントのみを収集しま
す。0 を設定すると、Splunk Enterprise はすべてのイベントを収集し
ます。
べての
イベン
トを収
集)
WMI イベントから取得したホスト名を正規化しないことを⽰します。
デフォルトでは、Splunk Enterprise はホスト名を正規化します。正規
化により、ローカルシステムの各種同等ホスト名が判別され、単⼀のホ
スト名が⽣成されます。イベント内のホスト名の正規化を無効にするに
は、このパラメータに 1 を設定します。0 を設定すると、イベント内の
ホスト名が正規化されます。
0
(WMI
イベン
トのホ
スト名
を正規
化す
る)
WQL 固有のパラメータ名を以下に⽰します。
属性
説明
デフォルト値
wql
有効な WQL ステートメント。
N/A
namespace
(オプション) WMI プロバイダへのパスを指定します。ローカルマシンは、代
理認証を使ってリモートマシンに接続できなければなりません。リモートマシ
ンへのパスを指定しない場合、Splunk Enterprise はデフォルトのローカル名
前空間 (\Root\CIMV2) に接続します。デフォルトの名前空間は、クエリーする可
能性がある⼤半のプロバイダが常駐している場所です。Microsoft は、
Windows XP 以降の名前空間の⼀覧を提供しています
(http://msdn.microsoft.com/en-us/library/aa394084(VS.85).aspx)。
\\<local
イベント通知クエリーを想定しているかどうかを⽰します。詳細は、「WQL
クエリ：イベント通知と標準」を参照してください。イベント通知クエリーを
想定している場合は 1 を、標準クエリーを想定している場合は 0 を設定しま
す。
0 (標準クエリー
を想定)
current_only
server>\Root\CIMV2
WQL クエリータイプ：イベント通知と標準
WQL スタンザ内の current_only 属性は、スタンザが WMI ベースのデータの収集に使⽤するクエリーのタイプを
決定します。この属性に 1 を設定すると、イベント通知データを予期します。イベント通知データは、着信イベ
ントを知らせるデータです。イベント通知データを取得するには、イベント通知クエリーを使⽤する必要がありま
す。
たとえば、リモート・サーバーがプロセスを⽣成する時期を知りたい場合は、イベント通知クエリーを使⽤する必
要があります。標準クエリーには、イベント発⽣時に通知する機能はありません。すでに存在している結果情報の
みを返します。
逆に、システム上ですでに実⾏されているプロセスの中で「splunk」で始まるものを知りたい場合は、標準クエ
リーを使⽤する必要があります。イベント通知クエリーは、静的な既存の情報を知らせることはできません。
イベント通知クエリーの場合、スタンザに定義されている WQL ステートメントが、構造的および構⽂的に正しく
なければなりません。不適切に WQL が定義されていると、そのスタンザが定義している⼊⼒は機能しません。詳
細と例については、wmi.conf 設定ファイルを参照してください。
WQL クエリースタンザが WMI チェックポイントファイルを更新しない
WQL クエリー・スタンザを使って WMI 経由でデータを収集する場合、WMI チェックポイント・ファイル (WMI
データのインデックスがすでに作成されたかどうかを判断するためのファイル) は更新されません。これは設計上
の仕様です。WQL クエリーは動的データを返すため、⽣成されたデータの保存⽤チェックポイントを作成できな
いためです。つまり、WQL クエリースタンザ経由で収集された WMI データは、スタンザの処理時に毎回新規
データとしてインデックスが作成されます。そのため重複するイベントのインデックスが作成され、ライセンスボ
リュームに影響が出る可能性もあります。
イベントログなどのように定期的にデータのインデックスを作成する必要がある場合は、ユニバーサルフォワー
ダー上で適切なモニターを使⽤してください。WMI を使⽤する必要がある場合、WQL は使⽤しないでくださ
い。
wmi.conf の例
wmi.conf
ファイルの例を以下に⽰します。
[settings]
initial_backoff = 5
max_backoff = 20
max_retries_at_max_backoff = 2
checkpoint_sync_interval = 2
[WMI:AppAndSys]
server = foo, bar
interval = 10
event_log_file = Application, System, Directory Service
70
disabled = 0
[WMI:LocalSplunkWmiProcess]
interval = 5
wql = select * from Win32_PerfFormattedData_PerfProc_Process where Name = "splunk-wmi"
disabled = 0
# Listen from three event log channels, capturing log events that occur only
# while Splunk Enterprise runs.
Gather data from three machines.
[WMI:TailApplicationLogs]
interval = 10
event_log_file = Application, Security, System
server = srv1, srv2, srv3
disabled = 0
current_only = 1
# Listen for process-creation events on a remote machine
[WMI:ProcessCreation]
interval = 1
server = remote-machine
wql = select * from __InstanceCreationEvent within 1 where TargetInstance isa 'Win32_Process'
disabled = 0
current_only = 1
# Receive events whenever someone plugs/unplugs a USB device to/from the computer
[WMI:USBChanges]
interval = 1
wql = select * from __InstanceOperationEvent within 1 where TargetInstance ISA 'Win32_PnPEntity' and
TargetInstance.Description='USB Mass Storage Device'
disabled = 0
current_only = 1
WMI データのフィールド
Splunk Enterprise が WMI ベース⼊⼒からのデータのインデックスを作成する場合、受信したイベントのソー
ス には wmi が設定されます。着信イベントのソースタイプ は、以下の条件に基づいて設定されます。
イベントログデータの場合、Splunk Enterprise はソースタイプに WinEventLog:<name of log file> を設定し
ます。例：WinEventLog:Application。
WQL データの場合、Splunk Enterprise はソースタイプに、⼊⼒を定義しているスタンザ名を設定しま
す。たとえば、スタンザ名が [WMI:LocalSplunkdProcess] の場合、ソースタイプには WMI:LocalSplunkdProcess が
設定されます。
送信元ホストは受信データから⾃動的に定義されます。
WMI およびイベント変換
インデックス時には、WMI イベントの変換は利⽤できません。つまり、インデックス作成時に、WMI イベント
を変更または抽出することはできません。これは、WMI イベントは単⼀のソース (スクリプト⼊⼒) として到着
し、単⼀のソースとしてしか照合できないためです。
ただし、サーチ時には WMI イベントの変更や抽出を⾏えます。また、ソースタイプ
パーシング時に WMI ベースの⼊⼒を処理することもできます。
[wmi]
を指定することで、
Splunk Enterprise に取り込まれたイベントの変換⽅法の詳細は、このマニュアルの「インデックス作成した
フィールドの抽出について」を参照してください。
WMI ⼊⼒のトラブルシューティング
WMI プロバイダ経由のイベント受信に問題が発⽣した、または想定する結果が得られない場合は、
『Troubleshooting Manual』の「Common Issues with Splunk and WMI」を参照してください。
Windows レジストリデータのモニター
Windows レジストリは、Windows マシンの集中設定データベースです。ほぼすべての Windows プロセスと
サードパーティ製プログラムがやり取りを⾏っています。正常なレジストリがないと、Windows は実⾏しませ
ん。Splunk Enterprise では、Windows レジストリ設定を捕捉して、リアルタイムにレジストリへの変更をモニ
ターすることができます。
プログラムが設定を変更する場合、それらの変更をレジストリに書き込みます。後ほどプログラムを再び実⾏する
と、プログラムはレジストリからそれらの設定を探します。Windows プログラムがシステムにレジストリエント
リを追加、更新、削除する時期を知ることができます。レジストリエントリが変更されると、Splunk Enterprise
は変更を⾏ったプロセス名、および変更されたエントリへのパス全体を取得します。
Windows レジストリ⼊⼒モニターは、splunk-regmon.exe と呼ばれるプロセスとして実⾏されます。
71
レジストリのモニター理由
レジストリはおそらくもっとも使⽤されているけれども、ほとんど理解されていない Windows 運⽤コンポーネン
トです。レジストリは常時使⽤されており、さまざまなプログラムがレジストリを読み書きしています。何かが正
常に動作しない場合、Microsoft はしばしば管理者やユーザーに RegEdit ツールを使って直接レジストリを変更
することを指⽰しています。これらの編集作業や他の変更をリアルタイムに捕捉することは、レジストリの重要性
を理解するための最初のステップになります。
レジストリのヘルス状態を理解することも⾮常に重要です。Splunk Enterprise はレジストリの変更を知らせるだ
けでなく、それらの変更が成功したかどうかも確認することができます。プログラムやプロセスがレジストリを読
み書きできない場合、Windows システムに障害などの不具合が⽣じる可能性があります。Splunk Enterprise は
レジストリ操作に関する問題のアラートを⽣成できるため、バックアップから設定を復元してシステムの正常動作
を維持できます。
レジストリのモニターに何が必要か？
レジストリのモニターに必要な、明⽰的なアクセス許可の⼀覧を以下の表に⽰します。モニターするレジストリ
キーに基づいて、他のアクセス許可が必要な場合もあります。
アクティビ
ティ：
必要なアクセス許可：
レジストリの
モニター
* Splunk Enterprise は Windows 上で実⾏する必要があります。
および
* Splunk Enterprise は Local System ユーザーとして実⾏するか
または
* Splunk Enterprise をモニターするレジストリハイブまたはキーへの読み取りアクセスを持つ
ドメインユーザーとして実⾏する必要があります。
パフォーマンスの検討事項
レジストリのモニターを有効にする場合、ユーザー・ハイブ (RegEdit の HKEY_USERS) または マシン・ハイブ
(HKEY_LOCAL_MACHINE) のどちらのレジストリ・ハイブをモニターするのかを指定します。ユーザーハイブには、
Windows やプログラムが必要とするユーザー固有の設定が含まれています。マシンハイブには、サービス、ドラ
イバ、オブジェクトクラス、およびセキュリティ記述⼦の場所などの、マシン固有の設定情報が含まれています。
レジストリは Windows マシン運⽤の中⼼的な役割を果たしているため、両⽅のレジストリパスを有効にすると
Splunk Enterprise は⼤量のデータをモニターしなければならない可能性があります。最適なパフォーマンスを達
成するために、inputs.conf を設定し、Splunk Enterprise がインデックスを作成するレジストリデータ量を、フィ
ルタリングで制限してください。
同様に、最初に Splunk Enterprise を起動する際に、現在の Windows レジストリの状態のスナップショットと
なるベースラインを取得し、その後も指定時間経過後に再取得していくことができます。このスナップショットに
より、ある時点でのレジストリの内容と⽐較し、時間の経過に伴うレジストリ変更の追跡を容易にします。
スナップショットの処理にはある程度 CPU を消費し、処理の完了まで数分ほどかかることもあります。ベースラ
イン・スナップショットの取得は、Splunk Enterprise でモニターするレジストリ・エントリの範囲を絞り込むま
で延期することができます。
の詳細およびそれを使った着信レジストリイベントのフィルタリング⽅法については、後述する「着
信レジストリイベントのフィルタリング」を参照してください。
inputs.conf
Splunk Web でレジストリのモニターを有効にする
ローカル Windows マシンでレジストリ・モニタリングを有効にするには、このマニュアルの「Windows レジス
トリ - ローカル」を参照してください。
レジストリ変更データの表⽰
Splunk Enterprise がインデックスを作成したデータのレジストリ変更を表⽰するには、サーチ App でソースが
WinRegistry のイベントをサーチします。ユーザーがドメインにログインした時に、グループ・ポリシーが⽣成す
るイベントの例を以下に⽰します。
3:03:28.505 PM
06/19/2011 15:03:28.505
event_status="(0)The operation completed successfully."
pid=340
process_image="c:\WINDOWS\system32\winlogon.exe"
registry_type="SetValue"
key_path="HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\History\DCName"
data_type="REG_SZ"
data="\\ftw.ad.splunk.com"
各レジストリモニタリングイベントには、以下の項⽬が含まれます。
属性
説明
レジストリ変更の試⾏結果。これは常に「(0)
72
The operation completed successfully.」でなければ
event_status
なりません。そうでない場合は、バックアップからの復元が必要なレジストリに関する問題にな
る可能性があります。
pid
レジストリの変更を試みたプロセスのプロセス ID。
process_image
レジストリの変更を試みたプロセス名。
registry_type process_image
が実⾏しようとしたレジストリ操作のタイプ。
key_path
process_image
が変更を試みたレジストリキーのパス。
data_type
レジストリの変更を⾏う
process_image
が取得または設定を試みた、レジストリデータのタイプ。
data
レジストリの変更を⾏う
process_image
が読み取りまたは書き込みを試みたデータ。
Splunk Enterprise のサーチコマンドやレポート機能を使って、着信データに基づくレポートを作成したり、ア
ラート機能を使って何か問題が発⽣した時にアラートを送信したりすることができます。
着信レジストリイベントのフィルタリング
Windows レジストリは、ほぼ常時利⽤されるため、⼤量のイベントを⽣成します。そのためライセンス上の問題
が発⽣する可能性があります。レジストリのモニタリングでは、⽇あたり数百メガバイトものデータが⽣成される
可能性があります。
Splunk の Windows レジストリモニタリング機能は、設定ファイル inputs.conf を使ってシステムの何を監視す
るのかを決定します。このファイルは、レジストリモニターを実⾏するサーバーの $SPLUNK_HOME\etc\system\local\
に保管する必要があります。
には、レジストリハイブのパスを限定、フィルタリングする正規表現を指定して、Splunk にモニター
させる項⽬を指⽰します。
inputs.conf
inputs.conf
内の各スタンザが、特定のフィルタを表しています。定義には、以下の項⽬が含まれます。
属性
proc
説明
モニターするプロセスへのパスを含む正規表現。
モニターするエントリへのパスを含む正規表現。Splunk は、Windows に事前定義されてい
る root キー値のマッピングをサポートしています。
または次の項⽬にマップします： HKU
は HKEY_CLASSES_ROOT または次の項⽬にマップします： HKCR
\\REGISTRY\\MACHINE は、次の項⽬にマップします： HKEY_LOCAL_MACHINE or HKLM
\\REGISTRY\\MACHINE\\SOFTWARE\\Classes は HKEY_CLASSES_ROOT または次の項⽬にマップしま
す： HKCR
\\REGISTRY\\MACHINE\\SYSTEM\\CurrentControlSet\\Hardware Profiles\\Current は
HKEY_CURRENT_CONFIG または次の項⽬にマップします： HKCC
注意： Splunk のレジストリモニターはカーネルモードで実⾏されるた
め、HKEY_CURRENT_USER または HKCU に対する直接のマッピングはありません。ただ
し、\\REGISTRY\\USER\\.* を使⽤すると (最後のピリオドとアスタリスクに注意してくだ
さい)、ログインユーザーのセキュリティ ID (SID) を含むイベントが⽣成されます。
代わりに、\\REGISTRY\\USER\\<SID> を使って、モニターするレジストリキーを持つユー
ザーを指定することができます。ここで、SID はユーザーの SID です。
\\REGISTRY\\USER\\
は
HKEY_USERS
\\REGISTRY\\USER\\_Classes
hive
type
モニターするイベントタイプのサブセット。1 つまたは複数の delete, set, create, rename,
open, close または query を使⽤できます。ここの値は sysmon.conf に設定した event_types の値
のサブセットでなければなりません。
baseline
その特定のハイブパスのベースラインスナップショットを取得するかどうか。はいの場合は
1、いいえの場合は 0 を設定します。
baseline_interval
Splunk Enterprise がここに指定した時間 (秒数) を超えて停⽌していた場合に、スナップ
ショットを再取得します。デフォルトは 86,400 秒 (1 ⽇) です。
disabled
フィルタを有効にするかどうか。フィルタを無効にするには 1 を、有効にするには 0 を設定
します。
ベースラインスナップショットの取得
レジストリ・モニタリングを有効にした場合、次回の Splunk Enterprise 起動時にレジストリ・ハイブのベース
ライン・スナップショットを記録することができます。デフォルトで、スナップショットは
HKEY_CURRENT_USER and HKEY_LOCAL_MACHINE ハイブをカバーしています。また、デフォルトでス
ナップショットを再取得する時期も決定しています。前回のチェックポイントから 24 時間を超えて Splunk が停
⽌していた場合、ベースライン・スナップショットが再取得されます。inputs.conf 内の各フィルタに対して、こ
の値をカスタマイズできます (baseline_interval に値 (秒) を設定)。
Windows パフォーマンスのモニター
Splunk Enterprise は、すべての Windows パフォーマンス・カウンタの、リアルタイム・モニタリングをサポー
73
トしています。また、ローカル/リモートの両⽅のパフォーマンス・データを収集することができます。
Splunk Enterprise のパフォーマンス・モニタリング・ユーティリティによる、Web インターフェイスでパ
フォーマンスをモニターすることができます。Splunk Enterprise はパフォーマンスデータヘルパー (PDH) API
を使って、ローカルマシンのパフォーマンスカウンタのクエリーを⾏います。
Splunk Enterprise で利⽤できるパフォーマンスオブジェクト、カウンタ、およびインスタンスのタイプは、シス
テムにインストールされているパフォーマンスライブラリによって異なります。Microsoft とサードパーティベン
ダーの両⽅が、パフォーマンスカウンタを含むライブラリを提供しています。パフォーマンスモニタリングの詳細
は、MSDN の「Performance Counters」 (http://msdn.microsoft.com/enus/library/aa373083%28v=VS.85%29.aspx) を参照してください。
完全版 Splunk Enterprise インスタンスとユニバーサルフォワーダーの両⽅が、パフォーマンス測定基準のロー
カル収集をサポートしています。リモート・パフォーマンス・モニタリングは、WMI (Windows Management
Instrumentation) を介して実⾏します。この場合、適切な Active Directory 資格情報を持つユーザーとして、
Splunk Enterprise を実⾏する必要があります。
パフォーマンスモニター⼊⼒は、splunk-perfmon.exe と呼ばれるプロセスとして実⾏されます。これは定義されて
いる各⼊⼒に対して、⼊⼒に指定されている間隔で 1 回実⾏されます。パフォーマンス・モニタリングの設定に
は Splunk Web、または inputs.conf (ローカル・パフォーマンス・データ) または wmi.conf (リモート・マシンか
らのパフォーマンス・データ) を使⽤します。
パフォーマンス測定基準のモニター理由
パフォーマンスのモニタリングは、Windows 管理者にとって重要な役割を果たします。Windows は、システム
のヘルス状態に関するさまざまなデータを⽣成します。このデータを適切に分析することが、正常で円滑に動作す
るシステムと、頻繁に停⽌するシステムの違いを⽣み出します。
パフォーマンス・カウンタのモニターに何が必要か？
Windows でパフォーマンスカウンタのモニターに必要な、アクセス許可の⼀覧を以下の表に⽰します。モニター
するパフォーマンスオブジェクトやカウンタによっては、他のアクセス許可が必要になることもあります。
パフォーマンス測定基準のモニターに必要な事項については、このトピック後半の「セキュリティとリモートアク
セスの検討事項」を参照してください。
アクティビティ：
必要なアクセス許可：
ローカルパフォーマンス測定基
準のモニター
* Splunk Enterprise は Windows 上で実⾏する必要があります。
* Splunk Enterprise は Local System ユーザーとして実⾏する必要がありま
す。
WMI を介した他のコンピュー
タ上のパフォーマンス測定基準
のリモートモニター
* Splunk Enterprise は Windows 上で実⾏する必要があります。
* Splunk Enterprise は、最低でもターゲットコンピュータ上の WMI への読
み取りアクセスを持つドメインユーザーとして実⾏する必要があります。
* Splunk Enterprise は、ターゲットコンピュータ上のパフォーマンスデータ
ヘルパーライブラリへの適切なアクセス権を持つ、ドメインまたはリモート
ユーザーとして実⾏する必要があります。
セキュリティとリモートアクセスの検討事項
Splunk Enterprise は、WMI またはフォワーダーを使って、リモートマシンからデータを収集します。リモート
マシンからインデクサーへのパフォーマンスデータの送信には、ユニバーサルフォワーダーを使⽤することをお勧
めします。『データの転送』マニュアルの「ユニバーサル・フォワーダーの紹介」を参照してください。
パフォーマンスデータを収集するために、リモートマシン上にフォワーダーをインストールする場合、それらのマ
シンにはフォワーダーを Local System ユーザーとしてインストールすることができます。Local System ユー
ザーは、ローカルマシン上のすべてのデータにアクセスできますが、リモートコンピュータにアクセスすることは
できません。
WMI を使ってリモート・マシンからパフォーマンス・データを収集する場合、Splunk Enterprise とネットワー
クの両⽅を設定する必要があります。Splunk Enterprise を Local System ユーザーとしてインストールすること
はできません。また、選択したユーザーによって、Splunk Enterprise が参照できる情報が決まります。このマ
ニュアルの「WMI データのモニター」にある「セキュリティとリモート・アクセスの検討事項」を参照してくだ
さい。
適切なユーザーとして Splunk Enterprise をインストールしたら、ローカルパフォーマンスモニター⼊⼒を有効
にする前に、そのユーザーを以下のグループに追加します。
Performance Monitor Users (ドメイングループ)
Performance Log Users (ドメイングループ)
ローカル Windows のパフォーマンスモニタリングを有効にする
Splunk Web を使って、または設定ファイルを編集して、ローカルのパフォーマンス・モニタリングを設定する
ことができます。
パフォーマンスモニタリングデータ⼊⼒の追加には、Splunk Web の使⽤をお勧めします。設定ファイルを使⽤
する場合、指定誤りが発⽣する可能性があります。パフォーマンス API に定義されている通りに、正確にパ
フォーマンスモニターオブジェクトを指定することが重要です。詳細は、このトピック後半にある「inputs.conf
にパフォーマンス・モニター・オブジェクトを指定する場合の重要な情報」を参照してください。
74
Splunk Web を使ったローカル Windows パフォーマンスモニタリングの設定
ローカル・マシンで Windows パフォーマンス・モニタリングを設定するには、このマニュアルの「Windows パ
フォーマンス・モニタリング - ローカル」を参照してください。
設定ファイルを使ったローカル Windows パフォーマンスモニタリングの設定
inputs.conf がパフォーマンスモニタリングの設定を管理しています。設定ファイルを使ってパフォーマンスモニ
タリングを設定する場合、%SPLUNK_HOME%\etc\system\local に inputs.conf を作成して、それを編集します。Splunk
の設定ファイルで初めて作業を⾏う場合は、事前に「設定ファイルについて」を参照してください。
スタンザは、inputs.conf にパフォーマンス・モニタリング⼊⼒を定義します。モニターする各
パフォーマンスオブジェクトに対して、それぞれ 1 つのスタンザを定義します。
[perfmon://<name>]
各スタンザでは、以下の属性を指定することができます。
属性
必
須？
説明
interval
はい 新しいデータのポーリングを⾏う頻度を秒で指定します。この属性が指定、定
義されていない場合、デフォルト値は存在しないためその⼊⼒は機能しませ
ん。
object
はい 収集するパフォーマンスオブジェクト。⼤⽂字⼩⽂字の区別も含めて正確に、
既存のパフォーマンスモニターオブジェクトの名前を指定するか、または複数
のオブジェクトを指定するために正規表現を使⽤します。この属性が指定、定
義されていない場合、デフォルト値は存在しないためその⼊⼒は機能しませ
ん。
counters
はい
instances
いい counters に指定されているパフォーマンスカウンタに関連する、1 つまたは複
え
数の有効なインスタンス。複数のインスタンスを指定する場合は、セミコロン
で区切ります。すべてのインスタンスを指定するには、アスタリスク (*) を使
⽤します。スタンザ内にこの属性を定義しない場合、デフォルトではすべての
インスタンスが対象になります (アスタリスク指定と同じ)。
index
いい パフォーマンスカウンタデータを送るインデックス。指定しない場合は、
え
「default」インデックスが使⽤されます。
disabled
いい この⼊⼒に定義されているパフォーマンスデータを収集するかどうか。このス
え
タンザを無効にするには 1 を、有効にするには 0 を設定します。指定しない
場合、デフォルトの 0 (有効) が使⽤されます。
samplingInterval
いい 詳細オプション： Splunk がパフォーマンスデータを収集する頻度 (ミリ秒)。
え
この属性は、⾼頻度のパフォーマンスサンプリングを有効にします。⾼頻度の
パフォーマンス・サンプリングを有効にすると、Splunk Enterprise は指定さ
れた間隔でパフォーマンス・データを収集し、データの平均値および他の統計
情報をレポートします。デフォルトは 100 ミリ秒です。また、interval 属性に
指定した値未満でなければなりません。
stats
いい 詳細オプション： ⾼頻度のパフォーマンスサンプリングで Splunk
え
Enterprise が報告する、統計値のセミコロン区切りリスト。
に指定されているオブジェクトに関連する、1 つまたは複数の有効なパ
フォーマンスカウンタ。複数のカウンタを指定する場合は、セミコロンで区切
ります。object で利⽤できるすべてのカウンタを指定するには、アスタリスク
(*) を使⽤します。この属性が指定、定義されていない場合、デフォルト値は存
在しないためその⼊⼒は機能しません。
object
利⽤可能な値：average,
min, max, dev、および count。
デフォルトの設定はありません (無効)。
mode
いい 詳細オプション： ⾼頻度のパフォーマンスサンプリングを有効にする場合、
え
この属性で Splunk Enterprise によるイベントの出⼒⽅法を制御できます。
利⽤可能な値：single,
multikv, multiMS、および multikvMS
または multikvMS を有効にした場合、収集された各パフォーマンス測定
基準に対して 2 つのイベントが出⼒されます。最初のイベントは平均値、2 番
⽬は統計イベントになります。統計イベントは、使⽤する出⼒モードに応じて
特別なソースタイプを保有します (multiMS の場合は perfmonMSStats、multikvMS
の場合は perfmonMKMSStats)。
multiMS
⾼頻度のパフォーマンスサンプリングを有効にしない場合、multikvMS 出⼒モー
ドと multikv 出⼒モードは同じです。
デフォルトは
useEnglishOnly
single
です。
いい 詳細オプション： ロケールが英語ではないシステム上のパフォーマンス測定
え
基準の、インデックスの作成⽅法を⽰します。特に、英語を使⽤していない
75
サーバー上でパフォーマンス測定基準のインデックスを作成する際に使⽤す
る、Windows パフォーマンス・モニター API を⽰しています。
真 (True) を設定すると、システムのロケールに関係なく英語でパフォーマン
ス測定基準が収集されます。カウンタ⽂字列の追加に
は、PdhAddEnglishCounter() API が使われます。また、object および counter 属
性の正規表現とワイルドカード照合も無効になります。
偽 (False) を設定した場合、システムで使⽤されている⾔語でパフォーマンス
測定基準が収集されます。また、その⾔語の object および counter 属性が設定
されていると仮定されます。カウンタ⽂字列の追加には、PdhAddCounter() API
が使われます。ワイルドカードと正規表現を利⽤できますが、オペレーティン
グ・システムのロケールに固有の、有効な object、counters、および instances
値を指定する必要があります。
デフォルトは偽 (False) です。
システム・ロケールに関係なく英語のパフォーマンス測定基準を収集
Splunk Enterprise が英語以外の⾔語で動作している場合でも、パフォーマンス測定基準を英語で収集することが
できます。
そのためには、inputs.conf 内のスタンザで
定する⽅法はありません。
useEnglishOnly
属性を使⽤します。Splunk Web で
useEnglishOnly
を設
注意： inputs.conf スタンザで useEnglishOnly を使⽤する場合、いくつかの注意事項があります。このトピックの
後半にある、注意事項のセクションを参照してください。
パフォーマンス・モニタリング⼊⼒スタンザの例
inputs.conf を使ったパフォーマンス・モニター・オブジェクトのモニター⽅法を表した、スタンザの例を以下に
⽰します。
# Query the PhysicalDisk performance object and gather disk access data for
# all physical drives installed in the system. Store this data in the
# "perfmon" index.
# Note: If the interval attribute is set to 0, Splunk resets the interval
# to 1.
[perfmon://LocalPhysicalDisk]
interval = 0
object = PhysicalDisk
counters = Disk Bytes/sec; % Disk Read Time; % Disk Write Time; % Disk Time
instances = *
disabled = 0
index = PerfMon
# Gather SQL statistics for all database instances on this SQL server.
# 'object' attribute uses a regular expression "\$.*" to specify SQL
# statistics for all available databases.
[perfmon://SQLServer_SQL_Statistics]
object = MSSQL\$.*:SQL Statistics
counters = *
instances = *
# Gather information on all counters under the "Process" and "Processor"
# Perfmon objects.
# We use '.*' as a wild card to match the 'Process' and 'Processor' objects.
[perfmon://ProcessandProcessor]
object = Process.*
counters = *
instances = *
# Collect CPU processor usage metrics in English only on a French system.
[perfmon://Processor]
object = Processor
instances = _Total
counters = % Processor Time;% User Time
useEnglishOnly = 1
interval = 30
disabled = 0
# Collect CPU processor usage metrics in the French system's native locale.
76
# Note that you must specify the counters in the language of that locale.
[perfmon://FrenchProcs]
counters = *
disabled = 0
useEnglishOnly = 0
interval = 30
object = Processeur
instances = *
inputs.conf にパフォーマンスモニターオブジェクトを指定する場合の重要な情報
perfmon キーワードの指定時にはすべて⼩⽂字を使⽤する
にパフォーマンスモニター⼊⼒を作成する場合、perfmon キーワードにはすべて⼩⽂字を使⽤する必要
があります。以下に例を⽰します。
inputs.conf
正しい
[perfmon://CPUTime]
誤り
[Perfmon://CPUTime]
[PERFMON://CPUTime]
キーワードで⼤⽂字を使⽤、または⼤⽂字⼩⽂字を混在すると、Splunk Enterprise 起動時にその問題の警告が表
⽰され、指定されているパフォーマンスモニター⼊⼒は機能しません。
複数のパフォーマンスモニターオブジェクトを取得する場合は有効な正規表現を指定する
単⼀のパフォーマンスモニタースタンザ内に複数のオブジェクトを指定する必要がある場合、有効な正規表現を
使ってそれらのオブジェクトを取得する必要があります。たとえば、⼀定の⽂字数を超える⽂字列と⼀致するワイ
ルドカードを指定するには、* ではなく .* を使⽤します。オブジェクトにドル記号または類似の特殊⽂字が含ま
れている場合は、円記号 (\)、またはバックスラッシュを使ってエスケープ処理する必要があります。
上記の場合を除いて、値はパフォーマンスモニター API に定義されている通りに正しく指定する必要があります
スタンザに object、counters、および instances 属性の値を指定する場合、それらの値は⼤⽂字⼩⽂字
の区別も含めてパフォーマンスモニター API に定義されてい通りに正確に指定する必要があります。そうしない
と、誤ったデータが返されるか、またはまったくデータが返されないことがあります。指定したパフォーマンスオ
ブジェクト、カウンタ、またはインスタンス値に⼀致する項⽬が⾒つからない場合、その旨が splunkd.log に記録
されます。例：
[perfmon://]
01-27-2011 21:04:48.681 -0800 ERROR ExecProcessor - message from ""C:\Program Files\Splunk\bin\splunk-perfmon.exe" noui" splunk-perfmon - PerfmonHelper::enumObjectByNameEx: PdhEnumObjectItems failed for object - 'USB' with error
(0xc0000bb8): The specified object is not found on the system.
正しくオブジェクト、カウンタ、およびインスタンスを指定する最良の⽅法は、Splunk Web を使ってパフォー
マンスモニターデータ⼊⼒を追加することです。
WMI を介したリモート Windows パフォーマンスのモニタリングを有効にする
Splunk Web を使って、または設定ファイルを編集して、リモートのパフォーマンスモニタリングを設定するこ
とができます。
WMI 経由でパフォーマンス測定基準を収集する場合、リモートのパフォーマンス測定基準コレクションにアクセ
スするための、適切な権限を持つ Active Directory ユーザーとして Splunk Enterprise を実⾏する必要がありま
す。それらの測定基準の収集を試みる前に、この作業を実施する必要があります。Splunk を実⾏するマシンと、
Splunk がリモートにパフォーマンスデータを収集するマシンは、同じ Active Directory ドメイン/フォレスト内
に存在している必要があります。
注意： WMI は設計上、サービス拒否攻撃を防⽌するために⾃⼰抑制を⾏います。Splunk Enterprise も WMI 呼
び出しがエラーを返した場合の予防⼿段として、呼び出し数を減らします。ネットワークのサイズ、設定、および
セキュリティプロファイルによっては、パフォーマンス測定基準を収集するシステム上に、ローカルにフォワー
ダーをインストールする⽅が適していることもあります。詳細は、このマニュアルの「リモート Windows データ
のモニター⽅法決定の検討事項」を参照してください。
WMI ベースのパフォーマンス測定基準に関する重要な情報
WMI 経由でリモートのパフォーマンス測定基準を収集する場合、⼀部の測定基準が 0 を返す、またはパフォーマ
ンスモニターが返す値とは異なる値が返されることがあります。これは、パフォーマンスモニターカウンタ⽤の
WMI の実装の制限によるもので、Splunk Enterprise の問題でも WMI ベースのデータの取得⽅法の問題でもあ
りません。
WMI は、Win32_PerfFormattedData_* クラスを使って、パフォーマンス測定基準を収集します。特定のクラスに関す
る情報は、MSDN の「Win32 Classes」 (http://msdn.microsoft.com/enus/library/aa394084%28v=vs.85%29.aspx) を参照してください。
WMI は、これらのクラス内のデータ構造を、ご利⽤の Windows のバージョンに応じて、32 ビットまたは 64
ビットの符号なし整数として定義します。⼀⽅パフォーマンスモニターオブジェクトは、浮動⼩数点型変数として
定義されます。これは、WMI ベースの測定基準が、丸められることにより変則的に⾒えることがあることを意味
しています。
77
たとえば、「Average Disk Queue Length」 (ディスクキューの平均の⻑さ) パフォーマンスモニターカウンタ上
のデータと同時に WMI を介して Win32_PerfFormattedData_PerfDisk_PhysicalDisk\AvgDiskQueueLength 測定基準を収集
する場合、パフォーマンスモニターの測定基準の値が 0 より⼤きい (ただし 0.5 未満の) 場合でも、WMI ベース
の測定基準は値として 0 を返すことがあります。これは、 WMI は表⽰する前に値を丸めることが原因です。
よりきめ細かなパフォーマンス測定基準が必要な場合は、パフォーマンスデータを収集する各マシン上にユニバー
サルフォワーダーをインストールして、パフォーマンスモニタリング⼊⼒を設定することをお勧めします。次に、
そのデータをインデクサーに転送します。この⽅法を使って取得したデータは、WMI ベースの⼊⼒を使ってリ
モートに収集したデータよりも信頼性が⾼くなります。
Splunk Web を使ったリモート Windows パフォーマンスモニタリングの設定
リモート Windows マシンで Windows パフォーマンス・モニタリングを設定するには、このマニュアルの
「Windows パフォーマンス・モニタリング - リモート」を参照してください。
設定ファイルを使ったリモート Windows パフォーマンスモニタリングの設定
リモートパフォーマンスモニタリングの設定は、wmi.conf で管理します。設定ファイルを使ってリモートパ
フォーマンスモニタリングを設定する場合、%SPLUNK_HOME%\etc\system\local に wmi.conf を作成して、それを編集し
ます。設定ファイルの作業を初めて⾏う場合は、事前に「設定ファイルについて」をお読みください。
警告： リモートパフォーマンスモニター⼊⼒を作成する場合、Splunk Web を使⽤することを強くお勧めしま
す。これは、パフォーマンスモニターオブジェクト、カウンタ、およびインスタンスの名前は、⼤⽂字⼩⽂字の区
別も含めて、パフォーマンスモニターが定義しているのと、完全に 同じでなければならないためです。Splunk
Web は、WMI を使って適切な形式の名前を取得するため、誤⼊⼒を防⽌することができます。
には、モニター対象各リモートパフォーマンスモニターのスタンザが含まれています。各スタンザでは、
以下の項⽬を指定することができます。
wmi.conf
グローバル設定
属性
必
須？
説明
デフォル
ト
initial_backoff
いい エラー発⽣時に WMI プロバイダへの接続を再試⾏するまでに待
5
え
機する秒数です。プロバイダへの接続に引き続き問題が発⽣する
場合は、接続を試みるまでの待機時間を 2 倍にしながら、接続が
成功するか、または待機時間が max_backoff に指定される値以上に
なるまで接続を試みていきます。
max_backoff
いい WMI プロバイダへの再接続を試みる最⼤時間 (秒)。
え
20
max_retries_at_max_backoff
いい WMI プロバイダとの再接続試⾏が max_backoff の秒数に達した場
え
合に、そのプロバイダとの再接続を試⾏する回数。
2
checkpoint_sync_interval
いい 状態データをディスクからフラッシュするまでに待機する秒数。
え
2
必
須？
デフォル
ト
⼊⼒固有の設定
属性
説明
interval
はい 新しいデータのポーリングを⾏う頻度を秒で指定します。この属
性がない場合、デフォルト値は存在しないためその⼊⼒は機能し
ません。
N/A
server
いい パフォーマンスをモニターする 1 つまたは複数の有効なサー
え
バー。複数の項⽬を指定する場合は、カンマで区切ります。
ローカル
マシン
event_log_file
いい ポーリングする 1 つまたは複数の Windows イベントログチャネ
え
ル。この属性は、着信データがイベントログ形式であることを
Splunk Enterprise に指⽰します。
N/A
注意： すでに wql 属性があるスタンザには、event_log_file 属性を
指定しないでください。
wql
いい リモートにポーリングするパフォーマンスオブジェクト、カウン
N/A
え
タ、およびインスタンスを⽰す、有効な WQL ステートメント。
この属性は、WMI プロバイダからデータを収集する予定であるこ
とを⽰します。
注意： すでに event_log_file 属性があるスタンザには、wql 属性を
指定しないでください。
namespace
いい クエリーする WMI プロバイダが存在する名前空間。この属性の
え
値は、相対値 (Root\CIMV2) または絶対値 (\\SERVER\Root\CIMV2) にで
78
Root\CIMV2
きます。ただし、server 属性を指定する場合は相対値でなければ
なりません。
注意： wql 属性があるスタンザでのみ、namespace 属性を使⽤して
ください。
index
いい パフォーマンスカウンタデータを送るインデックス。
え
default
current_only
いい WMIベースのイベント収集の特徴とやり取り。
え
N/A
を定義した場合、この属性は Splunk Enterprise がイベ
ント通知クエリーを予期すべきかどうかを⽰します。イベン
ト通知クエリーを予定している場合は 1 を、標準クエリー
を予定している場合は 0 を設定します。WQL およびイベン
ト通知クエリーの追加要件は以下を参照してください。
event_log_file を定義した場合、Splunk が動作中に発⽣した
イベントのみを収集するかどうかを⽰します。Splunk 動作
中に発⽣したイベントのみを収集する場合は 1 を、最後の
チェックポイントからのイベントを収集する場合は 0 を設
定します。0 を指定して、チェックポイントが存在していな
い場合は、利⽤可能なもっとも古いイベントから収集されま
す。
wql
disabled
いい この⼊⼒に定義されているパフォーマンスデータを収集するかど
え
うかを⽰します。このスタンザのパフォーマンスモニタリングを
無効にするには 1 を、有効にするには 0 を設定します。
0
ローカルディスクおよびメモリーのパフォーマンス測定基準を収集し、「wmi_perfmon」インデックスに保管す
る wmi.conf の例を以下に⽰します。
[settings]
initial_backoff = 5
max_backoff = 20
max_retries_at_max_backoff = 2
checkpoint_sync_interval = 2
# Gather disk and memory performance metrics from the local system every second.
# Store event in the "wmi_perfmon" Splunk index.
[WMI:LocalPhysicalDisk]
interval = 1
wql = select Name, DiskBytesPerSec, PercentDiskReadTime,PercentDiskWriteTime, PercentDiskTime from \
Win32_PerfFormattedData_PerfDisk_PhysicalDisk
disabled = 0
index = wmi_perfmon
[WMI:LocalMainMemory]
interval = 10
wql = select CommittedBytes, AvailableBytes, PercentCommittedBytesInUse, Caption from \
Win32_PerfFormattedData_PerfOS_Memory
disabled = 0
index = wmi_perfmon
WQL クエリーステートメントの追加情報
WQL クエリーは構造的および構⽂的たに正確でなければなりません。誤っている場合は、指定しても望ましくな
い結果が得られるか、またはまったく結果が得られない可能性があります。特に、イベント通知クエリーの作成時
(WQL クエリーが存在するスタンザ内に current_only=1 を指定)、WQL ステートメントにはそのようなクエリーを
指定する句 (WITHIN, GROUP, や HAVING) を含める必要があります。詳細は、WQL のクエリーに関する MSDN の記
事を参照してください。
Splunk Web を使ってパフォーマンスモニター⼊⼒を作成する場合、適切な WQL クエリーが⽣成されるため、
WQL 構⽂に関する問題を防⽌することができます。
注意事項
パフォーマンス測定基準の収集時はメモリー使⽤量が増加する
「Thread」オブジェクトやそれに関連するカウンタなどの、⼀部のパフォーマンスオブジェクトのデータ収集時
には、Splunk のメモリー使⽤量が増加することがあります。これは正常な動作です。⼀部のパフォーマンスオブ
ジェクトは、収集プロセス時に他のオブジェクトよりも多くのメモリーを消費します。
79
Processor Time カウンタが 100 より⼤きい値を返さない
Microsoft が Processor:% Processor Time および Process:% Processor Time カウンタを使って CPU 使⽤率を算出する
⽅法により、これらのカウンタはシステムの CPU 数やコア数に関係なく 100 を超える値を返すことはありませ
ん。これは仕様です。これらのカウンタは、アイドルプロセスが費やした時間量を、100% から減算していきま
す。
⾮英語版のインストール環境では、useEnglishOnly 属性の使⽤に制限がある
⾮英語版システムで inputs.conf を編集してパフォーマンス・モニタリングを有効にする場合、useEnglishOnly 属
性の機能にいくつかの制限事項があります。
この属性に true を設定すると、object および counters 属性に対してワイルドカードや正規表現を使⽤できませ
ん。これらの属性には、パフォーマンス・データ・ヘルパー・ライブラリに定義されている、有効な英語の値に基
づいて、特定のエントリを指定する必要があります。instances 属性にはワイルドカードを指定できます。以下に
例を⽰します。
[perfmon://Processor]
object = Processor
instances = _Total
counters = % Processor Time;% User Time
useEnglishOnly = 1
interval = 30
disabled = 0
システムで使⽤されている⾔語が英語以外の場合でも、counters 属性には英語の値が含まれることに注意してくだ
さい。
この属性に false を設定した場合、これらの属性に対してワイルドカードや正規表現を使⽤できますが、オペレー
ティング・システムの⾔語に基づいた値を指定する必要があります。フランス語版のシステムのスタンザの例を以
下に⽰します。
[perfmon://FrenchProcs]
counters = *
disabled = 0
useEnglishOnly = 0
interval = 30
object = Processeur
instances = *
この例で object 属性には Processeur が設定されていることに注意してください。これは、Processor のフランス語
です。ここに英語の値を指定すると、Splunk Enterprise はパフォーマンス・オブジェクトやインスタンスを⾒つ
けることができません。
u seEnglish Only 属性を使⽤する場合のその他の影響
この属性を使⽤する際には、他にも検討事項があります。
Splunk Web を使って⾮英語版オペレーティング・システムにパフォーマンス・モニター⼊⼒を作成する場
合、常に useEnglishOnly = false を指定します。
また、Splunk Web でこれらのスタンザを有効化、無効化、複製、または削除することができます。ただ
し、オペレーティング・システムのロケールがスタンザに指定されているロケールと⼀致しない限り、
Splunk Web でそれを編集することはできません。
useEnglishOnly 属性に真 (True) を設定すると、Splunk Web でパフォーマンス・モニター・スタンザを有効
化、無効化、複製、または削除することができます。ただし、システムのロケールが英語でない限り、それ
を Splunk Web で編集することはできません。
Windows ホスト情報のモニター
Splunk Enterprise は、Windows ホスト情報 (ローカル Windows マシンの詳細な統計情報) のモニターをサポー
トしています。Windows ホストに関する以下の情報を収集することができます。
⼀般のコンピュータ： コンピュータのメーカーとモデル、そのホスト名と参加している Active Directory
ドメイン。
オペレーティングシステム： コンピュータにインストールされているオペレーティングシステムのバー
ジョンとビルド番号、およびサービスパック、コンピュータ名、前回起動時刻、搭載メモリーと空きメモ
リー量、およびシステムドライブ。
プロセッサ： システムの CPU のメーカーとモデル、動作速度とバージョン、プロセッサ/コア数、および
プロセッサ ID。
ディスク： システムが利⽤できるすべてのドライブ⼀覧、および利⽤できる場合はファイルシステムタイプ
と合計/利⽤可能スペース。
ネットワークアダプタ： 製造業者、製品名、および MAC アドレスを含めた、システムに取り付けられて
いるネットワークアダプタに関する情報。
サービス： 名前、表⽰名、説明、パス、サービスタイプ、開始モード、状態、およびステータスを含めた、
システムにインストールされているサービスに関する情報。
プロセス： 名前、実⾏時のコマンドライン (および引数)、および実⾏形式ファイルのパスを含めた、システ
80
ムで動作中のプロセスに関する情報。
アプリケーション： 名前とシリアル番号、インストール⽇時とインストール場所、ベンダー、およびバー
ジョン番号を含めた、システムにインストールされているアプリケーションに関する情報。
完全版 Splunk Enterprise インスタンスとユニバーサルフォワーダーの両⽅が、ホスト情報のローカル収集をサ
ポートしています。
ホストモニター⼊⼒は、splunk-winhostmon.exe と呼ばれるプロセスとして実⾏されます。このプロセスは定義され
ている各⼊⼒に対して、⼊⼒に指定されている間隔で 1 回実⾏されます。ホストのモニタリングは、Splunk Web
または inputs.conf を使って設定できます。
ホスト情報のモニター理由
Windows ホストのモニタリングにより、Windows システムに関する詳細な情報を収集することができます。ソ
フトウェアのインストールと削除、サービスの起動と停⽌、および稼働時間などの、システムに対する任意の変更
をモニターすることができます。システム障害が発⽣した場合、まず Windows ホストモニタリング情報を⼿がか
りに調査を進めていくことができます。Splunk Enterprise のサーチ⾔語を利⽤して、Windows ネットワーク内
のすべてのマシンの統計情報を⼀⽬で把握できる、ダッシュボードやビューを作成することができます。
ホスト情報のモニターに何が必要か
アクティビ
ティ：
必要なアクセス許可：
ホスト情報の * Splunk Enterprise はWindows 上で実⾏する必要があります。
モニター
* すべてのローカルホスト情報を読み取るには、Splunk Enterprise を Local System ユーザー
またはローカル管理者として実⾏する必要があります。
セキュリティとリモートアクセスの検討事項
デフォルトでは、Windows ホスト情報を収集するために、Splunk Enterprise を Local System ユーザーとして
実⾏する必要があります。
リモートマシンからインデクサーへのホスト情報の送信には、ユニバーサルフォワーダーを使⽤することをお勧め
します。Windows ホストデータを収集するための、フォワーダーのインストール、設定、使⽤⽅法については、
『データの転送』マニュアルの「ユニバーサルフォワーダーの紹介」を参照してください。
Windows ホストデータを収集するために、リモートマシン上にフォワーダーをインストールする場合、それらの
マシンにはフォワーダーを Local System ユーザーとしてインストールすることができます。Local System ユー
ザーは、ローカルマシン上のすべてのデータにアクセスできますが、リモートマシンにアクセスすることはできま
せん。
Splunk Enterprise を「Local System」以外のユーザーとして実⾏する場合、そのユーザーには収集するホスト
データがあるマシンに対する、ローカル Administrator 権限が必要です。また、『インストールマニュアル』の
「Splunk Enterprise を実⾏する Windows ユーザーの選択」で説明しているように、ユーザーには他の明⽰的な
アクセス許可が必要です。
Splunk Web を使ったホストモニタリングの設定
A. [新規追加] ページに移動
⼊⼒ (データの取り込み) は、Splunk Web の [新規追加] ページから追加します。「データの追加⽅法は？」を参
照してください。
2 種類の⽅法でこのページを表⽰できます。
Splunk ホーム
Splunk 設定
Splunk 設定を使⽤する場合：
1. Splunk Web の右上にある [設定] をクリックします。
2. [設定] ポップアップの [データ] セクションで、[データ⼊⼒] をクリックします。
3. [ファイルとディレクトリ] をクリックします。
4. [新規] ボタンをクリックして、⼊⼒を追加します。
Splunk ホームを使⽤する場合：
1. Splunk ホームの [データの追加] リンクをクリックします。
2. ローカル Windows マシンからホスト情報をモニターするには、[モニター] をクリックします。
B. ⼊⼒ソースの選択
'1.左側のパネルで、[ローカル Windows ホスト監視] を探して選択します。
2. [コレクション名] フィールドに、この⼊⼒の覚えやすい⼀意の名前を⼊⼒します。
81
3. [イベント・タイプ] リスト・ボックスで、この⼊⼒でモニターするホスト・モニタリング・イベント・タイプ
を探します。
4. モニターする各タイプを、1 回クリックします。Splunk Enterprise は、タイプを [利⽤可能なタイプ] ウィン
ドウから [選択されたタイプ] ウィンドウに移動します。
5. タイプの選択を解除するには、[選択されたタイプ] ウィンドウでその名前をクリックします。Splunk
Enterprise は、カウンタを [選択されたタイプ] ウィンドウから [利⽤可能なタイプ] ウィンドウに移動します。
6. すべてのタイプを選択/選択解除するには、[すべて追加] または [すべて削除] リンクをクリックします。重
要： すべてのタイプを選択すると⼤量のデータのインデックスを作成することになり、ライセンスの上限を超え
てしまう可能性があります。
7. [間隔] フィールドで、⼊⼒のポーリング間隔を秒で指定します。
8. 緑⾊の [次へ] ボタンをクリックします。
C. ⼊⼒の設定
[⼊⼒設定] ページでは、アプリケーション・コンテキスト、デフォルトのホスト値、およびインデックスを指定
できます。これらのパラメータは省略することができます。
1. この⼊⼒の適切なアプリケーション・コンテキスト を選択します。
2. ホスト 名の値を設定します。さまざまな選択肢があります。ホスト値の設定の詳細は、「ホストについて」を
参照してください。
注意： [ホスト] は、イベントの host フィールドの設定のみを⾏います。Splunk Enterprise にネットワー
ク上の特定のホストを探すように指⽰するものではありません。
3. データを保管するインデックス を設定します。異なる種類のイベントを取り扱うために、複数のインデックス
を定義している場合を除き、この値は「default」のままにしてください。ユーザーデータ⽤のインデックスに加
えて、Splunk Enterprise にはさまざまなユーティリティインデックスが存在しています。これらのインデックス
も、このドロップダウンボックスに表⽰されます。
4. 緑⾊の [確認] ボタンをクリックします。
D. 選択項⽬の確認
⼊⼒設定をすべて指定したら、選択内容をレビューすることができます。Splunk Enterprise には、モニターのタ
イプ、ソース、ソースタイプ、アプリケーション・コンテキスト、インデックスなど (これ以外が表⽰されること
もあります) の、選択したオプションが表⽰されます。
設定を確認します。意図通りの内容でない場合は、⽩い [< ] ボタンをクリックして、ウィザードの前のステップに
戻ります。そうでない場合は、緑⾊の [送信] ボタンをクリックします。
[成功] ページが表⽰され、指定されたホスト情報のインデックス作成が開始されます。
inputs.conf を使ったホストモニタリングの設定
を使ってホストのモニタリングを設定することができます。inputs.conf を使ったデータ⼊⼒の設定の
詳細は、このマニュアルの「⼊⼒の設定」を参照してください。
inputs.conf
注意： 設定ファイルのデフォルトは、%SPLUNK_HOME%\etc\system\default 内のファイルまたは『管理マニュアル』で
確認することができます。
設定ファイルの編集⽅法については、『管理マニュアル』の「設定ファイルについて」を参照してくださ
い。
inputs.conf
を編集してホストのモニタリング⼊⼒を有効にするには：
1. %SPLUNK_HOME%\etc\system\local に inputs.conf を作成し、編集のためにそれを開きます。
2. %SPLUNK_HOME%\etc\system\default\inputs.conf を開いて、有効にする Windows イベントログ⼊⼒を確認します。
3. %SPLUNK_HOME%\etc\system\default\inputs.conf から、有効にする Windows イベントログ⼊⼒スタンザをコピーし
ます。
4. コピーしたスタンザを、%SPLUNK_HOME%\etc\system\local\inputs.conf に貼り付けます。
5. スタンザを、⽬的の Windows イベントログデータを収集するように編集します。
6. %SPLUNK_HOME%\etc\system\local\inputs.conf を保存して終了します。
7. Splunk Enterprise を再起動します。
次のセクションでは、ホストのモニタリングのための、特定の設定値について説明していきます。
Windows ホストのモニター設定値
Splunk Enterprise は、Windows ホスト情報をモニターするために、inputs.conf 内の以下の属性を使⽤していま
82
す。
属性
必
須？
説明
interval
はい 新しいデータのポーリングを⾏う頻度を秒で指定します。負の値を指定した場
合は、1 回のみ⼊⼒を実⾏します。この属性を定義しない場合、デフォルト値
は存在しないためその⼊⼒は機能しません。
type
はい モニターするホスト情報のタイプ。Computer, operatingSystem, processor, disk,
networkAdapter, service, process, driver のいずれか、または application を使⽤
できます。この変数が存在しない場合、⼊⼒は実⾏されません。
disabled
いい ⼊⼒をまったく実⾏しないかどうか。この属性に
え
されません。
1
を設定すると、⼊⼒は実⾏
Windows ホストモニタリング設定の例
次のファイル内の、Windows ホストモニタリング設定属性の、使⽤⽅法の例を以下に⽰します：
inputs.conf
# Queries computer information.
[WinHostMon://computer]
type = Computer
interval = 300
# Queries OS information.
# 'interval' set to a negative number tells Splunk Enterprise to
# run the input once only.
[WinHostMon://os]
type = operatingSystem
interval = -1
# Queries processor information.
[WinHostMon://processor]
type = processor
interval = -1
# Queries hard disk information.
[WinHostMon://disk]
type = disk
interval = -1
# Queries network adapter information.
[WinHostMon://network]
type = networkAdapter
interval = -1
# Queries service information.
# This example runs the input ever 5 minutes.
[WinHostMon://service]
type = service
interval = 300
# Queries information on running processes.
# This example runs the input every 5 minutes.
[WinHostMon://process]
type = process
interval = 300
# Queries information on installed applications.
# This example runs the input every 5 minutes.
[WinHostMon://application]
type = application
interval = 300
Windows ホストモニタリングデータのフィールド
Splunk Enterprise が Windows ホストモニタリング⼊⼒からのデータのインデックスを作成する場合、受信した
イベントのソース には windows が設定されます。受信イベントのソースタイプ には、WinHostMon が設定されます。
Answers
83
何か質問がありますか？「Splunk Answers」では、Splunk コミュニティに寄せられた、Windows ホスト情報に
関する質問と回答をご覧いただけます。
Windows プリンタ情報のモニター
Splunk Enterprise は、Windows 印刷サブシステム情報のモニターをサポートしています。ローカルマシン上の
プリンタとドライバ、印刷ジョブ、およびプリンタポートなど、あらゆる統計情報をモニターすることができま
す。以下の印刷システム情報を収集することができます。
プリンタ： 接続されているプリンタのステータス、およびプリンタの追加/削除⽇時などの、印刷サブシス
テムに関する情報。
ジョブ： 誰が何を印刷したか、ジョブの詳細、既存のジョブのステータスなどの、印刷ジョブに関する情
報。
ドライバ： 既存のプリントドライバ情報、プリントドライバの追加/削除⽇時などの、プリントドライバサ
ブシステムの情報。
ポート： システムにインストールされているプリンタポートの情報、および追加/削除⽇時。
完全版 Splunk Enterprise インスタンスとユニバーサルフォワーダーの両⽅が、プリンタサブシステム情報の
ローカル収集をサポートしています。
プリンタモニター⼊⼒は、splunk-winprintmon.exe と呼ばれるプロセスとして実⾏されます。このプロセスは定義さ
れている各⼊⼒に対して、⼊⼒に指定されている間隔で 1 回実⾏されます。プリンタサブシステムのモニタリン
グは、Splunk Web または inputs.conf を使って設定できます。
プリンタ情報のモニター理由
プリンタのモニタリングにより、プリンタサブシステムに関する詳細な情報を収集することができます。プリン
タ、プリントドライバ、およびポートのインストールと削除、印刷ジョブの開始と完了、誰が何をいつ印刷したか
などの、システムに対する任意の変更をモニターできます。プリンタ障害が発⽣した場合、まずプリンタモニタリ
ング情報を⼿がかりに調査を進めていくことができます。Splunk のサーチ⾔語を利⽤して、Windows ネット
ワーク内のすべてのプリンタの統計情報を⼀⽬で把握できる、ダッシュボードやビューを作成することができま
す。
プリンタ情報のモニターに何が必要か
アクティビ
ティ：
必要なアクセス許可：
ホスト情報のモ * Splunk Enterprise はWindows 上で実⾏する必要があります。
ニター
* すべてのローカルホスト情報を読み取るには、Splunk Enterprise を Local System ユー
ザーとして実⾏する必要があります。
セキュリティとリモートアクセスの検討事項
デフォルトでは、Windows 印刷サブシステム情報を収集するために、Splunk Enterprise を Local System ユー
ザーとして実⾏する必要があります。
リモートマシンからインデクサーへのプリンタ情報の送信には、ユニバーサルフォワーダーを使⽤することをお勧
めします。印刷サブシステムデータを収集するための、フォワーダーのインストール、設定、使⽤⽅法について
は、『データの転送』マニュアルの「ユニバーサルフォワーダーの紹介」を参照してください。
印刷サブシステムデータを収集するために、リモートマシン上にフォワーダーをインストールする場合、それらの
マシンにはフォワーダーを Local System ユーザーとしてインストールすることができます。Local System ユー
ザーは、ローカルマシン上のすべてのデータにアクセスできますが、リモートマシンにアクセスすることはできま
せん。
Splunk Enterprise を「Local System」以外のユーザーとして実⾏する場合、そのユーザーには収集する印刷情
報があるマシンに対する、ローカル Administrator 権限が必要です。また、『インストールマニュアル』の
「Splunk Enterprise を実⾏する Windows ユーザーの選択」で説明しているように、ユーザーには他の明⽰的な
アクセス許可が必要です。
Splunk Web を使ったプリンタ情報の設定
A. [新規追加] ページに移動
⼊⼒ (データの取り込み) は、Splunk Web の [新規追加] ページから追加します。「データの追加⽅法は？」を参
照してください。
2 種類の⽅法でこのページを表⽰できます。
Splunk ホーム
Splunk 設定
Splunk 設定を使⽤する場合：
1. Splunk Web の右上にある [設定] をクリックします。
2. [設定] ポップアップの [データ] セクションで、[データ⼊⼒] をクリックします。
3. [ローカル印刷モニター] をクリックします。
84
4. [新規] ボタンをクリックして、⼊⼒を追加します。
Splunk ホームを使⽤する場合：
1. Splunk ホームの [データの追加] リンクをクリックします。
2. ローカル Windows マシンから印刷情報をモニターするには、[モニター] をクリックします。
3. 左側のパネルで、[ローカル Windows 印刷監視] を探して選択します。
B. ⼊⼒ソースの選択
1. [コレクション名] フィールドに、この⼊⼒の覚えやすい⼀意の名前を⼊⼒します。
2. [イベント・タイプ] リスト・ボックスで、この⼊⼒でモニターする印刷モニタリング・イベント・タイプを探
します。
3. モニターする各タイプを、1 回クリックします。Splunk Enterprise は、タイプを [利⽤可能なタイプ] ウィン
ドウから [選択されたタイプ] ウィンドウに移動します。
4. タイプの選択を解除するには、[選択されたタイプ] ウィンドウでその名前をクリックします。Splunk
Enterprise は、カウンタを [選択されたタイプ] ウィンドウから [利⽤可能なタイプ] ウィンドウに移動します。
5. すべてのタイプを選択/選択解除するには、[すべて追加] または [すべて削除] リンクをクリックします。重
要： すべてのタイプを選択すると⼤量のデータのインデックスを作成することになり、ライセンスの上限を超え
てしまう可能性があります。
6. Splunk Enterprise 起動後すぐに⼊⼒を実⾏するには、[ベースライン] で [はい] ラジオボタンをクリックしま
す。[間隔 (分)] フィールドで指定した間隔で⼊⼒を実⾏する場合は、[いいえ] をクリックします。
7. 緑⾊の [次へ] ボタンをクリックします。
C. ⼊⼒の設定
[⼊⼒設定] ページでは、アプリケーション・コンテキスト、デフォルトのホスト値、およびインデックスを指定
できます。これらのパラメータは省略することができます。
1. この⼊⼒の適切なアプリケーション・コンテキスト を選択します。
2. ホスト 名の値を設定します。さまざまな選択肢があります。ホスト値の設定の詳細は、「ホストについて」を
参照してください。
注意： [ホスト] は、イベントの host フィールドの設定のみを⾏います。Splunk Enterprise にネットワー
ク上の特定のホストを探すように指⽰するものではありません。
3. データを保管するインデックス を設定します。異なる種類のイベントを取り扱うために、複数のインデックス
を定義している場合を除き、この値は「default」のままにしてください。ユーザーデータ⽤のインデックスに加
えて、Splunk Enterprise にはさまざまなユーティリティインデックスが存在しています。これらのインデックス
も、このドロップダウンボックスに表⽰されます。
4. 緑⾊の [確認] ボタンをクリックします。
D. 選択項⽬の確認
⼊⼒設定をすべて指定したら、選択内容をレビューすることができます。Splunk Enterprise には、モニターのタ
イプ、ソース、ソースタイプ、アプリケーション・コンテキスト、インデックスなど (これ以外が表⽰されること
もあります) の、選択したオプションが表⽰されます。
設定を確認します。意図通りの内容でない場合は、⽩い [< ] ボタンをクリックして、ウィザードの前のステップに
戻ります。そうでない場合は、緑⾊の [送信] ボタンをクリックします。
[成功] ページが表⽰され、指定された印刷情報のインデックス作成が開始されます。
inputs.conf を使ったホストモニタリングの設定
を使ってホストのモニタリングを設定することができます。inputs.conf を使ったデータ⼊⼒の設定の
詳細は、このマニュアルの「⼊⼒の設定」を参照してください。
inputs.conf
注意： 設定ファイルのデフォルトは、%SPLUNK_HOME%\etc\system\default 内のファイルまたは『管理マニュアル』で
確認することができます。
設定ファイルの編集⽅法については、『管理マニュアル』の「設定ファイルについて」を参照してくださ
い。
inputs.conf
を編集して印刷のモニタリング⼊⼒を有効にするには：
1. inputs.conf を
%SPLUNK_HOME%\etc\system\default
2. エクスプローラまたは
ATTRIB
から
etc\system\local
にコピーします。
コマンドを使って、ファイルの読み取り専⽤フラグを削除します。
3. ファイルを開いて編集し、Windows 印刷モニタリング⼊⼒を有効にします。
85
4. Splunk を再起動します。
次のセクションでは、ホストのモニタリングのための、特定の設定値について説明していきます。
印刷モニタリングの設定値
Splunk Enterprise は、Windows プリンタサブシステムをモニターするために、inputs.conf 内の以下の属性を使
⽤しています。
属性
必
須？
説明
interval
はい 新しいデータのポーリングを⾏う頻度を秒で指定します。この属性が指定、定
義されていない場合、デフォルト値は存在しないためその⼊⼒は機能しませ
ん。
type
はい モニターするホスト情報のタイプ。printer, job, driver のいずれか、または
port を使⽤できます。この変数が存在しない場合、⼊⼒は実⾏されません。
baseline
いい 既存のプリンタ、ジョブ、ドライバ、またはポートの状態のベースラインを⽣
え
成するかどうかを⽰します。この属性に 1, を設定すると、ベースラインが⽣
成されます。この場合、Splunk Enterprise の起動までに時間がかかり、CPU
リソースも消費される可能性があります。
disabled
いい ⼊⼒をまったく実⾏しないかどうか。この属性に
え
されません。
1
を設定すると、⼊⼒は実⾏
Windows ホストモニタリング設定の例
inputs.conf
での、Windows ホストモニタリング設定属性の、使⽤⽅法の例を以下に⽰します。
# Monitor printers on system.
[WinPrintMon://printer]
type = printer
baseline = 0
# Monitor print jobs.
[WinPrintMon://job]
type = job
baseline = 1
# Monitor printer driver installation and removal.
[WinPrintMon://driver]
type = driver
baseline = 1
# Monitor printer ports.
[WinPrintMon://port]
type = port
baseline = 1
Windows 印刷モニタリングデータのフィールド
Splunk Enterprise が Windows 印刷モニタリング⼊⼒からのデータのインデックスを作成する場合、受信したイ
ベントのソース には windows が設定されます。受信イベントのソースタイプ には、WinPrintMon が設定されます。
Answers
何か質問がありますか？「Splunk Answers」では、Splunk コミュニティに寄せられた、Windows 印刷モニタリ
ングに関する質問と回答をご覧いただけます。
Windows ネットワーク情報のモニター
Splunk Enterprise は Windows ネットワーク情報のモニタリングをサポートしています。Windows マシンとや
り取りされるネットワークアクティビティに関する、詳細な統計情報をモニターできます。以下のネットワーク情
報を収集することができます。
ネットワーク活動： Windows マシンプラットフォームが任意のネットワーク活動を⾏う場合、Splunk
Enterprise を使ってそれをモニターすることができます。
アドレスファミリー： IPv4 または IPv6 プロトコル経由でネットワークトランザクションが⾏われたかど
うか。
パケットタイプ： トランザクションで送信されたパケットタイプ (例：「connect」または「transport」パ
ケット)。
プロトコル： TCP または UDP プロトコル経由でネットワークトランザクションが⾏われたかどうか。
ホスト： ローカル/リモートホスト、ホストが通信したポート、利⽤可能な DNS 情報などの、ネットワー
クトランザクションに関与したホストに関する情報。
86
アプリケーション： ネットワークトランザクションを開始したアプリケーション。
ユーザー： ネットワークトランザクションを開始したユーザー、およびその ID と SID。
その他： 伝送ヘッダーサイズやトランザクションが IPSec で保護されていたかどうかなどを含めた、ネッ
トワークトランザクションに関するその他の情報。
完全版 Splunk Enterprise インスタンスとユニバーサルフォワーダーの両⽅が、ネットワーク情報のローカル収
集をサポートしています。
ネットワークモニター⼊⼒は、splunk-netmon.exe と呼ばれるプロセスとして実⾏されます。このプロセスは定義さ
れている各⼊⼒に対して、⼊⼒に指定されている間隔で 1 回実⾏されます。ネットワークのモニタリングは、
Splunk Web または inputs.conf を使って設定できます。
重要： Splunk Enterprise の Windows ネットワーク・モニタリングは、64 ビット Windows システムでのみ利
⽤できます。32 ビットの Windows システムでは利⽤できません。
ネットワーク情報のモニター理由
Windows ネットワークのモニタリングにより、Windows ネットワークアクティビティに関する詳細な情報を収
集することができます。ユーザーまたはプロセスによるネットワーク接続の開始、トランザクションが IPv4 また
は IPv6 アドレスを使⽤しているかどうかなど、ネットワーク上のトランザクションをモニターすることができま
す。Splunk Enterprise のネットワークモニタリングを利⽤すれば、サービス拒否攻撃の受信/発信に関与してい
るマシンを通知して、攻撃を検出、防⽌することができます。Splunk のサーチ⾔語を利⽤して、Windows ネッ
トワーク内のすべてのネットワーク操作の統計情報を⼀⽬で把握できる、ダッシュボードやビューを作成すること
ができます。
ネットワーク情報のモニターに何が必要か
アク
ティビ
ティ：
ネット
ワーク
情報の
モニ
ター
要件：
Splunk は Windows 上で実⾏する必要があります
マシンの Windows は以下のいずれかでなければなりません
Windows Vista
Windows 7
Windows 8
Windows Server 2008
Windows Server 2008 R2
Windows Server 2012
Windows システムには、Windows Vista、Windows 7、Windows Server 2008、および
Windows Server 2008 R2 が動作するマシンのカーネルモード・ドライバ・フレームワーク・
バージョン 1.11 アップデートを含め、利⽤可能なすべてのアップデートやサービス・パックを
適⽤する必要があります。
すべてのローカルホスト情報を読み取るには、Splunk Enterprise を Local System ユーザーま
たはローカル管理者アカウントとして実⾏する必要があります。
セキュリティとリモートアクセスの検討事項
デフォルトでは、Windows ネットワーク情報を収集するために、Splunk Enterprise を Local System ユーザー
として実⾏する必要があります。
リモートマシンからインデクサーへのホスト情報の送信には、ユニバーサルフォワーダーを使⽤することをお勧め
します。Windows ホストデータを収集するための、フォワーダーのインストール、設定、使⽤⽅法については、
『データの転送』マニュアルの「ユニバーサルフォワーダーの紹介」を参照してください。
Windows ネットワーク情報を収集するために、リモートマシン上にフォワーダーをインストールする場合、それ
らのマシンにはフォワーダーを Local System ユーザーとしてインストールすることができます。Local System
ユーザーは、ローカルマシン上のすべてのデータにアクセスできますが、リモートマシンにアクセスすることはで
きません。
Splunk Enterprise を「Local System」以外のユーザーとして実⾏する場合、そのユーザーには収集するホスト
データがあるマシンに対する、ローカル Administrator 権限が必要です。また、『インストールマニュアル』の
「Splunk Enterprise を実⾏する Windows ユーザーの選択」で説明しているように、ユーザーには他の明⽰的な
アクセス許可が必要です。
Splunk Web を使ったホストモニタリングの設定
A. [新規追加] ページに移動
⼊⼒ (データの取り込み) は、Splunk Web の [新規追加] ページから追加します。「データの追加⽅法は？」を参
照してください。
2 種類の⽅法でこのページを表⽰できます。
Splunk ホーム
Splunk 設定
Splunk 設定を使⽤する場合：
1. Splunk Web の右上にある [設定] をクリックします。
87
2. [設定] ポップアップの [データ] セクションで、[データ⼊⼒] をクリックします。
3. [ローカル Windows ネットワークモニタリング] をクリックします。
4. [新規] ボタンをクリックして、⼊⼒を追加します。
Splunk ホームを使⽤する場合：
1. Splunk ホームの [データの追加] リンクをクリックします。
2. ローカル Windows マシンのネットワーク情報をモニターするには、[モニター] をクリックします。他の
Windows マシンからネットワーク情報を転送するには、[転送] をクリックします。[データの追加 - ソースの選
択] ページが表⽰されます。
注意： ネットワーク情報の転送には、追加設定が必要です。
3. 左側のパネルで、[ローカル Windows ネットワーク監視] を探して選択します。
B. ⼊⼒ソースの選択
1. [ネットワーク・モニター名] フィールドに、この⼊⼒の覚えやすい⼀意の名前を指定します。
2. [アドレス・ファミリー] で、モニターする IP アドレスファミリーのタイプ (IPv4 または IPv6) を選択しま
す。
3. [パケット・タイプ] で、モニターするパケット・タイプ (connect 、accept 、transport .) を選択します。
4. [⽅向] で、モニターするネットワークの⽅向を選択します ([着信] (モニターしているホストが受信) または [発
信] (モニターしているホストから送信))。
5. [プロトコル] で、モニターするプロトコルの種類を選択します ([tcp] または [udp] )。
6. [リモートアドレス] フィールドに、モニターしているホストとネットワーク通信する、モニター対象リモート
ホストのホスト名または IP アドレスを⼊⼒します。
注意： 複数のホストをモニターする場合は、このフィールドに正規表現を指定します。
7. [プロセス] フィールドに、ネットワーク通信をモニターするプロセスの、名前の⼀部または全部を⼊⼒しま
す。
注意： リモートアドレスと同様に、正規表現を使って複数のプロセスをモニターすることができます。
8. [ユーザー] フィールドに、ネットワーク通信をモニターするユーザーの、名前の⼀部または全部を⼊⼒しま
す。
注意： リモートアドレスやプロセスの場合と同様に、正規表現を使って複数のプロセスをモニターすることがで
きます。
9. 緑⾊の [次へ] ボタンをクリックします。
C. ⼊⼒の設定
[⼊⼒設定] ページでは、アプリケーション・コンテキスト、デフォルトのホスト値、およびインデックスを指定
できます。これらのパラメータは省略することができます。
1. この⼊⼒の適切なアプリケーション・コンテキスト を選択します。
2. ホスト 名の値を設定します。さまざまな選択肢があります。ホスト値の設定の詳細は、「ホストについて」を
参照してください。
注意： [ホスト] は、イベントの host フィールドの設定のみを⾏います。Splunk Enterprise にネットワー
ク上の特定のホストを探すように指⽰するものではありません。
3. データを保管するインデックス を設定します。異なる種類のイベントを取り扱うために、複数のインデックス
を定義している場合を除き、この値は「default」のままにしてください。ユーザーデータ⽤のインデックスに加
えて、Splunk Enterprise にはさまざまなユーティリティインデックスが存在しています。これらのインデックス
も、このドロップダウンボックスに表⽰されます。
4. 緑⾊の [確認] ボタンをクリックします。
D. 選択項⽬の確認
⼊⼒設定をすべて指定したら、選択内容をレビューすることができます。Splunk Enterprise には、モニターのタ
イプ、ソース、ソースタイプ、アプリケーション・コンテキスト、インデックスなど (これ以外が表⽰されること
もあります) の、選択したオプションが表⽰されます。
設定を確認します。意図通りの内容でない場合は、⽩い [< ] ボタンをクリックして、ウィザードの前のステップに
戻ります。そうでない場合は、緑⾊の [送信] ボタンをクリックします。
[成功] ページが表⽰され、指定された印刷情報のインデックス作成が開始されます。
inputs.conf を使ったネットワークモニタリングの設定
88
を使ってネットワークのモニタリングを設定することができます。inputs.conf を使ったデータ⼊⼒の
設定の詳細は、このマニュアルの「⼊⼒の設定」を参照してください。
inputs.conf
注意： 設定ファイルのデフォルトは、%SPLUNK_HOME%\etc\system\default 内のファイルまたは『管理マニュアル』で
確認することができます。
設定ファイルの編集⽅法については、『管理マニュアル』の「設定ファイルについて」を参照してくださ
い。
inputs.conf
を編集してネットワークのモニタリング⼊⼒を有効にするには：
1. inputs.conf を
%SPLUNK_HOME%\etc\system\default
2. エクスプローラまたは
ATTRIB
から
etc\system\local
にコピーします。
コマンドを使って、ファイルの読み取り専⽤フラグを削除します。
3. ファイルを開いて編集し、Windows ネットワークモニタリング⼊⼒を有効にします。
4. Splunk を再起動します。
次のセクションでは、ホストのモニタリングのための、特定の設定値について説明していきます。
Windows ホストのモニター設定値
Windows ネットワークモニタリング⼊⼒を定義するには、inputs.conf で [WinNetMon://<name>] スタンザを定義し
ます。Splunk Enterprise は Windows ネットワークモニター⼊⼒の設定に、以下の属性を使⽤します。
属性：
説明：
disabled = [0|1]
デフォルト：
0 (有効)
⼊⼒を有効にするかどうかを⽰します。
⼊⼒を無効にするには 1 を、有効にするには
0 を設定します。
index = <⽂字列>
デフォルトのインデックス
データを保管するインデックスを指定しま
す。
この属性は省略することができます。
remoteAddress = <正規表
現>
(空⽂字列 - すべてに⼀致)
設定した場合、ネットワークトランザクショ
ンに関与している IP アドレスと照合します。
IP アドレスを表す正規表現のみを使⽤できま
す (ホスト名は不可)。
正規表現に⼀致しないリモートアドレスのイ
ベントはフィルタリングされます。
正規表現に⼀致するリモートアドレスを持つ
イベントは収集されます。
例：192\.163\..* は、192.163.x.x の範囲の
すべての IP アドレスと⼀致します。
process = <正規表現>
設定した場合、ネットワークアクセスを実⾏
したプロセスまたはアプリケーション名と照
合されます。
正規表現に⼀致しないプロセスが⽣成したイ
ベントはフィルタリングされます。
正規表現に⼀致するプロセスが⽣成したイベ
ントは収集されます。
user = <正規表現>
設定した場合、ネットワークアクセスを実⾏
したユーザー名と照合されます。
正規表現に⼀致しないユーザーが⽣成したイ
ベントはフィルタリングされます。
正規表現に⼀致するユーザーが⽣成したイベ
ントは収集されます。
addressFamily =
[ipv4;ipv6]
packetType =
[connect;accept;transport]
(空⽂字列 - すべてのプロセ
スまたはアプリケーションに
⼀致)
(空⽂字列 - すべてのユー
ザーによるアクセスが含まれ
ます)
(空⽂字列 - すべての IP トラ
設定した場合、ネットワークアクセスに使⽤ フィックが含まれます)
されたアドレスファミリーに対して照合が⾏
われます。
「ipv4;ipv6」のように、セミコロンで区切っ
た値を使⽤できます。
設定した場合、トランザクション内で使⽤さ
れているパケットタイプに対して照合が⾏わ
れます。
「connect;transport」のように、セミコロン
89
(空⽂字列 - すべてのパケッ
トタイプが含まれます)
で区切った値を使⽤できます。
direction =
[inbound;outbound]
(空⽂字列 - 両⽅の⽅向が含
設定した場合、ネットワークトラフィックの まれます)
⽅向に対して照合が⾏われます。
「Inbound」はモニターを⾏っているマシン
に到着するトラフィックを、「outbound」は
モニターを⾏っているマシンから出て⾏くト
ラフィックを表しています。
「inbound;outbound」のように、セミコロ
ンで区切った値を使⽤できます。
protocol = [tcp;udp]
(空⽂字列 - 両⽅のプロトコ
設定した場合、指定したネットワークプロト ルタイプが含まれます)
コルに対して照合が⾏われます。
「tcp」は、トランザクションの設定にハンド
シェークと状態を使⽤する、TCP を表してい
ます。
「udp」は、状態を持たない UDP を表して
います。
「tcp;udp」のように、セミコロンで区切っ
た値を使⽤できます。
readInterval = <整数>
100
ネットワークモニターフィルタドライバを読
み込む間隔 (ミリ秒) を指定します。
詳細オプション： ⼊⼒のパフォーマンスに問
題がない限り、デフォルト値の使⽤をお勧め
します。
カーネルドライバの呼び出し頻度を調整する
ことができます。頻度を多くするとネット
ワークパフォーマンスに影響する可能性があ
ります。頻度を少なくすると、イベントが失
われる可能性があります。
妥当な最⼩値は 10、最⼤値は 1000 です。
driverBufferSize = <整数>
1024
ネットワークモニターフィルタドライバの
バッファに保持するネットワークパケット数
を⽰します。
詳細オプション： ⼊⼒のパフォーマンスに問
題がない限り、デフォルト値の使⽤をお勧め
します。
ドライバがキャッシュに格納するパケットの
量を制御します。値を⼩さくするとイベント
が失われる可能性が、⼤きくすると⾮ページ
メモリーサイズが増加する可能性がありま
す。
妥当な最⼩値は 128、最⼤値は 8192 です。
mode = <⽂字列>
各イベントの出⼒⽅法を⽰します。
Splunk Enterprise は各イベントを、single
または multikv (キー/値のペア) モードで出⼒
することができます。
multikvMaxEventCount =
<整数>
mode
multikvMaxTimeMs = <整
数>
mode
single
100
に multikv を設定した場合に、出⼒する
イベントの最⼤量を⽰します。
詳細オプション： ⼊⼒のパフォーマンスに問
題がない限り、デフォルト値の使⽤をお勧め
します。
妥当な最⼩値は 10、最⼤値は 500 です。
1000
に multikv を設定した場合に、mulitkv イ
ベントを出⼒するための最⼤時間を⽰しま
す。
詳細オプション： ⼊⼒のパフォーマンスに問
題がない限り、デフォルト値の使⽤をお勧め
します。
妥当な最⼩値は 100、最⼤値は 5000 です。
Windows ネットワークモニタリングデータのフィールド
Splunk Enterprise が Windows ネットワークモニタリング⼊⼒からのデータのインデックスを作成する場合、受
信したイベントのソース には windows が設定されます。受信イベントのソースタイプ には、WinNetMon が設定され
90
ます。
Windows マシンにすべてのパッチを適⽤していることを確認してください
Windows Vista、Windows 7、Windows Server 2008、または Windows Server 2008 R2 マシン上でネット
ワーク・モニタリング⼊⼒を利⽤中に問題が発⽣した場合は、マシンに利⽤可能なすべてのパッチを適⽤している
ことを確認してください。これには、カーネル・モード・ドライバ・フレームワーク・バージョン 1.11 アップ
デートも含まれています。このアップデートについては、Microsoft サポート技術情報の記事 2685811
(http://support.microsoft.com/kb/2685811) を参照してください。システムにこのアップデートが適⽤されて
いない場合、ネットワーク・モニタリング⼊⼒が正常に機能しない可能性があります。
Answers
何か質問がありますか？「Splunk Answers」では、Splunk コミュニティに寄せられた、Windows ネットワーク
モニタリングに関する質問と回答をご覧いただけます。
その他の取り込み⽅法
FIFO キューからのデータの取得
このトピックでは、inputs.conf を使った FIFO ⼊⼒の設定⽅法を説明していきます。現在 Splunk Web では
FIFO ⼊⼒を定義できません。
警告 ：FIFO 経由で送信されるデータはメモリーには保持されないため、データソースとしては信頼性に⽋ける場
合があります。データを失わないようにするためには、代わりにモニター⼊⼒を使⽤してください。
inputs.conf への FIFO の追加
FIFO ⼊⼒を追加するには、$SPLUNK_HOME/etc/system/local/ にある inputs.conf、または $SPLUNK_HOME/etc/apps/ 内の
独⾃のカスタム App ディレクトリにある inputs.conf に、スタンザを追加します。設定ファイルで初めて作業を
⾏う場合は、事前に『管理マニュアル』の「設定ファイルについて」を参照してください。
FIFO スタンザを追加するための基本的な構⽂を以下に⽰します。
[fifo://<path>]
<attrbute1> = <val1>
<attrbute2> = <val2>
...
この⼊⼒スタンザは、指定したパスにある FIFO から読み込むことを Splunk Enterprise に指⽰するものです。
FIFO スタンザでは、以下の属性を使⽤することができます。
属性
host = <string>
説明
ホスト/キーフィールドに、このスタンザの静的な値を設定し
ます。
ホストキーの初期値を設定します。このキーは、パーシ
ング/インデックス作成時に使⽤されます (特に host
フィールドの設定時)。サーチ時に使⽤される host
フィールドでもあります。
<string> の前には「host::」が付けられます。
index = <string>
この⼊⼒からのイベントを保管するインデックスを設定しま
す。
の前には「index::」が付けられます。
インデックスフィールドの詳細は、『インデクサーとク
ラスタの管理』マニュアルの「インデックス作成の仕組
み」を参照してください。
<string>
sourcetype = <string>
デフォルト
データの起源となる
ホストの IP アドレ
スまたは完全修飾ド
メイン名。
main、またはデフォ
ルトのインデックス
として設定した任意
の値になります。
この⼊⼒からのイベントの sourcetype キー/フィールドを設定 * データのさまざま
します。
な側⾯に基づいて
ソースタイプが選択
このデータのソースタイプを⾃動的に判断する代わり
されます。ハード
に、明⽰的に宣⾔します。このことは、パーシングおよ
コード化されたデ
びインデックス作成中の、このタイプのデータに対する
フォルト値はありま
サーチ可能性と関連するフォーマットの適⽤の両⽅で重
せん。
要になります。
ソースタイプキーの初期値を設定します。このキーは、
パーシング/インデックス作成時に使⽤されます (特に
host フィールドの設定時)。サーチ時に使⽤される
source type フィールドでもあります。
<string> の前には「sourcetype::」が付けられます。
ソースタイプの詳細は、このマニュアルの「ソースタイ
プが重要な理由」を参照してください。
91
source = <string>
* この⼊⼒からのイベントの source キー/フィールドを設定し
ます。
⼊⼒ファイルパス。
注意： source キーに優先する設定を⾏うことは、⼀般的
にお勧めできません。通常⼊⼒レイヤーは、データの取
得場所を正確に記録し、問題の分析と調査を⽀援するた
めに、より正確な⽂字列を提供しています。この値に優
先する設定を⾏う前に、ソースタイプ、タグ設定、およ
びワイルドカードを使ったサーチの使⽤を検討してくだ
さい。
<string> の前には「source::」が付けられます。
queue =
[parsingQueue|indexQueue]
* ⼊⼒プロセッサが、読み込んだイベントをデポジットするか
どうかを指定します。
デフォルトは
parsingQueue です。
データに props.conf および他のパーシングルールを適⽤
する場合は、「parsingQueue」を設定します。
データを直接インデックスに送信する場合は、
「indexQueue」を設定します。
ファイルシステムへの変更のモニター
この機能は廃⽌予定です。
この機能は、Splunk Enterprise バージョン 5.0 から⾮推奨 (廃⽌予定) となりました。このことは、Splunk
Enterprise 6.x でこの機能はまだ機能しますが、将来のバージョンでは削除される可能性があることを意味して
います。代替案：
Windows システムでのファイルシステム変更のモニター⽅法を学習する。
*nix システムで auditd デーモンを使って、デーモンからの出⼒をモニターする。
⾮推奨で廃⽌予定の機能の⼀覧は、リリースノートの「⾮推奨 (廃⽌予定) の機能」を参照してください。
Splunk Enterprise のファイルシステム変更モニター 機能は、ファイルシステム内の変更を追跡する場合に役⽴
ちます。ファイルシステム変更モニターは、指定した任意のディレクトリを監視して、そのディレクトリに何らか
の変更が⾏われた場合に、イベントを⽣成します。さまざまな設定を変更することができ、システム上の任意の
ファイル (Splunk 固有のファイルだけでなく) の編集、削除、追加を検知することができます。たとえ
ば、/etc/sysconfig/ を監視して、システム設定が変更された時にアラートを⽣成するように設定することができま
す。
ファイルシステム変更モニターは、inputs.conf に設定します。
重要： この機能と転送 機能を使ってリモートインデクサーにイベントを送信する場合は、ヘビーフォワーダー を
使⽤するか、または「ユニバーサルフォワーダーでの使⽤」の説明に従って設定を⾏う必要があります。
注意： Windows でのファイル読み取りの監査については、Splunk コミュニティのベストプラクティス Wiki を
参照してください。ユーザーによっては、Windows のネイティブ監査ツールを利⽤する⽅が簡単なこともありま
す。
ファイルシステム変更モニター機能の仕組み
ファイルシステム変更モニターは、以下の情報を使って変更を検出します。
変更⽇時
グループ ID
ユーザー ID
ファイルモード (読み取り/書き込み属性など)
ファイルコンテンツの SHA256 ハッシュ (オプション)
ファイルシステム変更モニターの以下の機能を設定することができます。
正規表現を使ったホワイトリスト
監視対象ファイルの指定
正規表現を使ったブラックリスト
スキップするファイルの指定
ディレクトリ再帰
シンボリックリンクトラバーサルを含める
複数ディレクトリのスキャン、およびそれぞれに対する独⾃のポーリング頻度の指定
暗号化署名
ファイルシステム変更の分散監査データの作成
追加/変更時にファイル全体を 1 つのイベントとしてインデックス作成
ファイル全体やハッシュの送信⽤にサイズ削減
すべての変更イベントのインデックス作成と Splunk Enterprise を使ったサーチ
警告： root ファイルシステムのモニターに、ファイルシステム変更モニターを使⽤しないでください。そうする
と、ディレクトリ再帰が有効になっている場合に危険で、また時間もかかります。
92
ファイルシステム変更モニターの設定
デフォルトでファイルシステム変更モニターは、$SPLUNK_HOME/etc/ の内容が変更、削除、または追加された場合
に、監査イベント を⽣成します。Splunk Enterprise を初めて起動する場合、$SPLUNK_HOME/etc/ ディレクトリとそ
のサブディレクトリ内の各ファイルに対して、監査イベントが⽣成されます。その後は、設定に変更が⾏われると
(⼿段に関係なく)、影響するファイルに対して監査イベントが作成されます。signedaudit=true の場合、ファイルシ
ステム変更監査イベントは監査インデックス (index=_audit) に保管されます。signedaudit が有効になっていない
場合は、他のインデックスを指定しない限り、デフォルトでイベントは main インデックスに書き込まれます。
注意： ファイルシステム変更モニターは、変更を⾏ったアカウントのユーザー名は追跡しません。変更の発⽣の
みを追跡しています。ユーザーレベルのモニタリングの場合は、その情報にアクセスするネイティブのオペレー
ティングシステム監査ツールの使⽤を検討してください。
ファイルシステム変更モニターを使ってディレクトリを監視するには、$SPLUNK_HOME/etc/system/local/ 内または
$SPLUNK_HOME/etc/apps/ の独⾃の App ディレクトリ内の、inputs.conf に [fschange] スタンザを追加または編集しま
す。設定ファイルの⼀般情報については、『管理マニュアル』の「設定ファイルについて」を参照してください。
注意： [fschange] スタンザを変更した場合は、Splunk Enterprise を再起動する必要があります。
構⽂
[fschange]
スタンザの構⽂を以下に⽰します。
[fschange:<directory or file to monitor>]
<attribute1> = <val1>
<attribute2> = <val2>
...
以下の事項に注意してください。
指定ディレクトリとそのサブディレクトリの、すべての追加/更新/削除操作がモニターされます。
任意の変更により、Splunk がインデックスを作成するイベントが⽣成されます。
<directory or file to monitor> デフォルトは $SPLUNK_HOME/etc/ です。
属性
すべての属性は任意で、省略することができます。利⽤可能な属性の⼀覧を以下に⽰します。
属性
説明
デフォルト
index=<indexname>
⽣成されたすべてのイベントを保管するイ
ンデックス。
recurse=<true | false>
真 (True) の場合、
true
<code[fschange]</code> で指定されてい
るディレクトリ内のすべてのディレクトリ
が再帰されます。
followLinks=<true | false>
真 (True) の場合、ファイルシステム変更
モニターはシンボリックリンクを追いま
す。
false
このディレクトリに対する変更を、N 秒ご
とにチェックします。
3600 秒
pollPeriod=N
(監査イベント署名を
有効にしていない場合)。
main
警告： followLinks の設定
には注意を払う必要があ
ります。そうしないと、
システムループが発⽣す
る可能性があります。
何らかの変更
を⾏った場
合、そのシス
テム監査イベ
ントが⽣成さ
れ、それが監
査⽤サーチに
利⽤できるよ
うになるま
で、1〜3600
秒ほどかかり
ます。
hashMaxSize=N
* N バイト以下の各ファイルの SHA1 ハッ
シュを算出します。
このハッシュは、ファイル/ディレク
トリの変更を検出するための、追加
の⼿段として利⽤することができま
す。
93
-1 (変更検出にハッシュを
使⽤しない)。
signedaudit=<true | false>
* 暗号化署名した追加/更新/削除イベント
を送信します。
false
真 (True) を設定すると、_audit イン
デックス内にイベントが⽣成されま
す。
index 属性を設定している場合は、偽
(False) を設定する必要があります。
注意： signedaudit に真 (True) を設定する
場合は、audit.conf で監査が有効になって
いることを確認してください。
fullEvent=<true | false>
* 追加または更新を検出した場合に、完全
なイベントを送信します。
sendEventMaxSize
false
属性でさらに修飾さ
れます。
sendEventMaxSize=N
* イベントのサイズが N バイト以下の場合
にのみ、完全なイベントを送信します。
-1 (無制限)
これにより、インデックス作成され
たファイルデータのサイズを制限し
ます。
sourcetype = <string>
* この⼊⼒からのイベントのソースタイプ
を設定します。
audittrail
* <integer> 件のファイルの処理
後、delayInMills に指定されている時間に
相当する遅延を挟みます。
N/A
(signedaudit=true の場合)
または fs_notification
<string> の前には「sourcetype::」が
(signedaudit=false の場合)
⾃動的に追加されます。
filesPerDelay = <integer>
これは、CPU を消費しすぎないよう
に、ファイルシステムのモニタリン
グを抑制するために⽤いられます。
delayInMills = <integer>
* filesPerDelay に指定されているよう
に、<integer> 件のファイルの処理ごとに使
⽤する遅延時間 (ミリ秒)。
これは、CPU を消費しすぎないよう
に、ファイルシステムのモニタリン
グを抑制するために⽤いられます。
filters=<filter1>,<filter2>,...<filterN>
これらの各フィルタは、モニターのポーリ
ングサイクル中に⾒つかった各ファイルや
ディレクトリに対して、左から右へと適⽤
されていきます。フィルタの定義について
は、次のセクションを参照してください。
N/A
フィルタの定義
filters
属性で使⽤するフィルタを定義するには、以下のように
[filter...]
スタンザを定義します。
[filter:blacklist:backups]
regex1 = .*bak
regex2 = .*bk
[filter:whitelist:code]
regex1 = .*\.c
regex2 = .*\.h
[fschange:/etc]
filters = backups,code
fschange ホワイトリスト/ブラックリストは、⼀般的なファイアウォールのロジックと同様に処理されます。イ
ベントは、最初に⼀致するフィルタが⾒つかるまで、フィルタのリストと順番に照合されていきます。イベントと
最初に⼀致したフィルタがホワイトリストの場合、そのイベントのインデックスが作成されます。イベントと最初
に⼀致したフィルタがブラックリストの場合、そのイベントのインデックスは作成されません。⼀致するフィルタ
が⾒つからなかった場合は、イベントのインデックスが作成されます。これは、暗黙的に「すべて通過」フィルタ
が存在し、すべてに該当しないイベントのインデックスが作成されることを意味しています。そのような場合にイ
94
ンデックスを作成させたくない 場合は、リストの最後に残りのイベントに⼀致するブラックリストを設定しま
す。
例：
...
filters = <filter1>, <filter2>, ... terminal-blacklist
[filter:blacklist:terminal-blacklist]
regex1 = .?
重要： ⼀連のホワイトリストの最後にある最終ブラックリストも含めて 、あるディレクトリをブラックリスト
の対象にした場合、そのすべての サブフォルダとファイルが⾃動的にブラックリストの対象となり、ホワイトリ
ストに渡されることはありません。これに対処するために、ブラックリストフィルタの前に、必要なフォルダとサ
ブフォルダすべてを明⽰的にホワイトリストに指定してください。
例
指定ディレクトリ内の拡張⼦が .config、.xml、.properties、および
を無視する設定を以下に⽰します。
.log
のファイルをモニターし、その他すべて
注意： この例では、1 つのディレクトリがブラックリストに該当する可能性があります。その場合、そのすべ
て のサブフォルダとファイルも⾃動的にブラックリスト化されます。ホワイトリストに指定されたディレクトリ内
のファイルのみがモニターされます。
[filter:whitelist:configs]
regex1 = .*\.config
regex2 = .*\.xml
regex3 = .*\.properties
regex4 = .*\.log
[filter:blacklist:terminal-blacklist]
regex1 = .?
[fschange:/var/apache]
index = sample
recurse = true
followLinks = false
signedaudit = false
fullEvent = true
sendEventMaxSize = 1048576
delayInMills = 1000
filters = configs,terminal-blacklist
ユニバーサルフォワーダーでの使⽤
ユニバーサルフォワーダーからファイルシステム変更モニターイベントを転送するには、signedaudit
index=_audit を設定する必要があります。
= false
と
[fschange:<directory or file to monitor>]
signedaudit = false
index=_audit
この⽅法では、ファイルシステムモニターイベントのインデックスが、_audit インデックスに作成さ
れ、sourcetype に fs_notification が、source に fschangemonitor が設定されます (sourcetype と source の両⽅に対し
てデフォルト値の audittrail ではない)。
スクリプト⼊⼒を介した API や他のリモートデータインターフェイス
からのデータの取得
Splunk Enterprise は、指定したスクリプトからのイベントを受け取ることができます。スクリプト⼊⼒
は、vmstat、iostat、netstat、top、などの Windows/*nix コマンドラインツールと連携使⽤する場合に役⽴ちま
す。スクリプト⼊⼒を使って、API や他のリモートデータインターフェイス/メッセージキューからデータを取得
することができます。次にそのデータに対して vmstat や iostat などのコマンドを使って、測定基準やステータス
データを⽣成することができます。
注意： このトピックは、すでに⼀連の⼊⼒に書き込んだスクリプト⼊⼒の追加⽅法を説明しています。スクリプ
ト⼊⼒の開発⽅法については、『Developing Views and Apps for Splunk Web』マニュアルの「Build scripted
inputs」を参照してください。
Splunk Apps にあるさまざまな App が、特定の⽤途向けのスクリプト⼊⼒を提供しています。検索するに
は、[App] メニューで [Browse more apps] (他の App を参照) オプションを使⽤します。
95
スクリプト⼊⼒を設定するには、[システム] を使⽤するか、または inputs.conf を編集します。
注意： Windows プラットフォームでは、中継 Windows バッチ (.bat) または PowerShell (.ps1) ファイルを使っ
て、perl や python などのテキストベースのスクリプトを有効にすることができます。
警告： スクリプト⼊⼒経由で起動されたスクリプトは、Splunk Enterprise 環境を継承します。スクリプトの動
作に影響する環境変数は、忘れずに消去してください。問題が発⽣する可能性が⾼い唯⼀の環境変数が、ライブラ
リパスの環境変数です (⼀般的に Linux、Solaris、および FreeBSD では LD_LIBRARY_PATH)。
Splunk Enterprise は stderr I/O チャネルに送信される任意のメッセージを、スクリプト⼊⼒を使って
splunkd.log に記録します。
Splunk Web を使ったスクリプト⼊⼒の追加
Splunk Web にスクリプト⼊⼒を追加するには、このマニュアルの「スクリプト」を参照してください。
inputs.conf を使ったスクリプト⼊⼒の追加
スクリプト⼊⼒を追加するには、inputs.conf に
[script]
スタンザを追加します。
構⽂
[script]
スタンザの構⽂を以下に⽰します。
[script://$SCRIPT]
<attrbute1> = <val1>
<attrbute2> = <val2>
...
以下の事項に注意してください。
は、スクリプトのある場所への完全パスです。
ベストプラクティスとして、スクリプトを指定した inputs.conf から、もっとも近い bin/ ディレクトリにス
クリプトを保管してください。たとえば、$SPLUNK_HOME/etc/system/local/inputs.conf を設定した場合、スクリ
プトは $SPLUNK_HOME/etc/system/bin/ に保管してください。$SPLUNK_HOME/etc/apps/$APPLICATION/ 内のアプリケー
ションに対して作業を⾏っている場合は、Splunk を $SPLUNK_HOME/etc/apps/$APPLICATION/bin/ に保管します。
$SCRIPT
属性
すべての属性は任意で、省略することができます。利⽤可能な属性の⼀覧を以下に⽰します。
属性
interval =
<number>|<cron
schedule>
説明
デフォルト
* 指定したコマンドの実⾏頻度を⽰します。秒を表す整 60 秒
数値または有効な cron スケジュールを指定します。
を指定した場合、起動時にスクリプ
トは実⾏されません。cron スケジュールに定義
されている時間に実⾏されます。
Splunk Enterprise はインスタンスあたり 1 つ
のスクリプト呼び出しを維持します。間隔は、ス
クリプトの完了時期に基づいています。そのた
め、10 分ごとに実⾏するように設定したスクリ
プトがあり、スクリプトの実⾏完了に 20 分か
かった場合、次回のスクリプト実⾏は最初の実⾏
から 30 分後に⾏われます。
常時データストリームがある場合は、1 (また
は、スクリプトの間隔よりも⼩さな値) を⼊⼒し
ます。
単発のデータストリームの場合は、-1 を⼊⼒し
ます。interval に -1 を設定すると、毎回 Splunk
デーモンの再起動時にスクリプトが実⾏されま
す。
cron schedule
index = <string>
* この⼊⼒からのイベントを保管するインデックスを設 main、またはデフォルトのイン
定します。
デックスとして設定した任意の
値になります。
<string> の前に index:: が付けられます。
インデックスフィールドの詳細は、『インデク
サーとクラスタの管理』マニュアルの「インデッ
クス作成の仕組み」を参照してください。
sourcetype = <string>
この⼊⼒からのイベントの sourcetype キー/フィール
ドを設定します。
データのさまざまな側⾯に基づ
いてソースタイプが選択されま
す。ハードコード化されたデ
このデータのソースタイプを⾃動的に判断する代 フォルト値はありません。
わりに、明⽰的に宣⾔します。このことは、パー
96
シングおよびインデックス作成中の、このタイプ
のデータに対するサーチ可能性と関連するフォー
マットの適⽤の両⽅で重要になります。
ソースタイプキーの初期値を設定します。この
キーは、パーシング/インデックス作成時に使⽤
されます (特に host フィールドの設定時)。サー
チ時に使⽤される source type フィールドでも
あります。
<string> の前には「sourcetype::」が付けられま
す。
ソースタイプの詳細は、このマニュアルの「ソー
スタイプが重要な理由」を参照してください。
source = <string>
* この⼊⼒からのイベントの source キー/フィールド
を設定します。
⼊⼒ファイルパス
注意： ソースキーに優先する設定は⾏わないこ
とをお勧めします。通常⼊⼒レイヤーは、データ
の取得場所を正確に記録し、問題の分析と調査を
⽀援するために、より正確な⽂字列を提供してい
ます。この値に優先する設定を⾏う前に、ソース
タイプ、タグ設定、およびワイルドカードを使っ
たサーチの使⽤を検討してください。
<string> の前に source:: が付けられます。
disabled = <true |
false>
* disabled は、⼊⼒を無効にしたい場合に真 (True) を
設定する論理値です。
false
スクリプトを継続的に実⾏する場合は、終了しないようにスクリプトを作成し、それに短い間隔を設定します。こ
れにより、何か問題があった場合でも、Splunk が再起動されます。Splunk Enterprise は実⾏されたスクリプト
を追跡し、終了時にはシャットダウンを⾏います。
ラッパースクリプトの使⽤
スクリプト⼊⼒⽤に、引数を指定したコマンドを使⽤するラッパースクリプトを作成するのもお勧めできます。コ
マンドに、Splunk Web が⼊⼒されたテキストの検証時にエスケープ処理を⾏う、特殊⽂字を使⽤できることも
あります。この場合、以前に設定した⼊⼒の更新すると、保存に失敗してしまいます。
注意： Splunk Enterprise がテキストの検証時にエスケープ処理を⾏う⽂字とは、等号 (=) やセミコロン (;)
などの、パスに使⽤できない⽂字のことです。
たとえば、以下のスクリプト⼊⼒を Splunk Web で編集した場合、Splunk Enterprise がパラメータ内の等号
(=) をエスケープ処理して myUtil.py ユーティリティに渡すため、正しく保存されません。
[script://$SPLUNK_HOME/etc/apps/myApp/bin/myUtil.py file=my_datacsv]
disabled = false
この問題を回避するために、スクリプト⼊⼒を含むラッパースクリプトを作成してください。(conf ファイルの直
接編集による⼊⼒の更新は、この⼊⼒検証の対象にはなりません。)ラッパースクリプトの作成については、
『Developing Views and Apps for Splunk Web』マニュアルの「Scripted inputs overview」を参照してくだ
さい。
inputs.conf の使⽤例
データ⼊⼒のソースとして UNIX の
top
コマンドを使⽤する例を以下に⽰します。
1. 新しいアプリケーションディレクトリを作成します。この例では、scripts/ を使⽤します。
$ mkdir $SPLUNK_HOME/etc/apps/scripts
2. すべてのスクリプトは、アプリケーションディレクトリ内の
bin/
ディレクトリから実⾏する必要があります。
$ mkdir $SPLUNK_HOME/etc/apps/scripts/bin
3. この例は、⼩さなシェルスクリプト
top.sh
を使⽤します。
$ #!/bin/sh
top -bn 1
# linux only - different OSes have different parameters
4. スクリプトが実⾏形式であることを確認してください。
chmod +x $SPLUNK_HOME/etc/apps/scripts/bin/top.sh
5. シェルを介してスクリプトを実⾏することで、スクリプトが正しく機能することを確認してください。
97
$SPLUNK_HOME/etc/apps/scripts/bin/top.sh
スクリプトは 1 つの
top
出⼒を送信する必要があります。
6. スクリプトのエントリを
$SPLUNK_HOME/etc/apps/scripts/local/
内の
inputs.conf
に追加します。
[script:///opt/splunk/etc/apps/scripts/bin/top.sh]
interval = 5
# run every 5 seconds
sourcetype = top
# set sourcetype to top
source = script://./bin/top.sh
# set source to name of script
注意： props.conf を変更しなければならない場合もあります。
デフォルトで Splunk Enterprise は、単⼀の top エントリを複数のイベントに分割します。
この問題に対処するには、出⼒に存在していない何らかの項⽬の前でのみ分割するように、サーバーに指⽰
します。
たとえば、$SPLUNK_HOME/etc/apps/scripts/default/props.conf に以下の項⽬を追加すると、すべての⾏が単⼀のイベ
ントに含まれます。
[top]
BREAK_ONLY_BEFORE = <stuff>
top 出⼒にはタイムスタンプがないため、現在の時刻を使⽤するように指定する必要があります。そのために
は、props.conf に以下の項⽬を設定します。
DATETIME_CONFIG = CURRENT
cron スケジュールへの interval 属性の設定
上記の例で、以下のような⽂字列を使⽤して、「cron」スケジュールに
す。
0 * * * *：1
interval
属性を設定することもできま
時間に 1 回、時間の開始時に実⾏することを⽰します。
*/15 9-17 * * 1-5：⽉〜⾦曜の午前
9 時から午後 5 時までの間、15 分ごとに実⾏することを⽰します。
15,35,55 0-6,20-23 1 */2 *：各偶数⽉
(2 ⽉、4 ⽉、6 ⽉...など) の始めに、午前 0 時〜午前 7 時および午後 8 時〜
午前 0 時の間の各時間の 15、35、および 55 分に実⾏することを⽰します。
cron スケジュールの詳細は、Crontab Web サイトの CRONTAB(5) を参照してください。
crawl を使ったモニター項⽬の発⾒
この機能は廃⽌予定です。
この機能は、Splunk Enterprise バージョン 6.0 から⾮推奨 (廃⽌予定) となりました。このことは、この機能
はまだ利⽤できますが、将来のバージョンでは削除される可能性があることを意味しています。代わりに、ファ
イルやディレクトリをサーチして、⼿動でモニターすることができます。
⾮推奨で廃⽌予定の機能の⼀覧は、リリースノートの「⾮推奨 (廃⽌予定) の機能」を参照してください。
ファイルシステムまたはネットワークをサーチして、インデックスに追加する新たなデータソースを探すに
は、crawl サーチコマンドを使⽤します。
デフォルトの crawl 設定を変更するには、crawl.conf を編修します。crawl 実⾏時の crawl のデフォルトに優先す
る設定を⾏えます。
crawl
は、crawl アクティビティのログを⽣成し、$SPLUNK_HOME/var/log/splunk/crawl.log に保管します。
crawl のデフォルトの変更
crawl のデフォルトの設定を変更するには、$SPLUNK_HOME/etc/system/local/crawl.conf を編集します。ファイルと
ネットワークの crawl は、それぞれ独⾃のスタンザに個別に定義します。
構⽂
には、2 つのスタンザが存在しています。[files]と
の crawl のデフォルトを定義しています。
crawl.conf
[network]
は、それぞれがファイルとネットワーク
これらのスタンザに定義できる属性とデフォルト値の詳細は、crawl.conf spec ファイルを参照してください。
例
98
ファイルとネットワークの両⽅に対して crawl 設定が定義されている、crawl.conf ファイルの例を以下に⽰しま
す。
[files]
bad_directories_list= bin, sbin, boot, mnt, proc, tmp, temp, home, mail, .thumbnails, cache, old
bad_extensions_list= mp3, mpg, jpeg, jpg,
m4, mcp, mid
bad_file_matches_list= *example*, *makefile, core.*
packed_extensions_list= gz, tgz, tar, zip
collapse_threshold= 10
days_sizek_pairs_list= 3-0,7-1000, 30-10000
big_dir_filecount= 100
index=main
max_badfiles_per_dir=100
[network]
host = myserver
subnet = 24
</pre>
イベント処理の設定
イベント処理の概要
イベントは、ログファイル内のアクティビティレコードで、インデックスに保管されます。これが主に Splunk
Enterprise がインデックスを作成するデータです。イベントは、ログファイルを⽣成したシステムに関する情報
を提供しています。「イベントデータ 」と呼ばれる⽤語は、Splunk インデックスの内容を表しています。
イベントの例を以下に⽰します。
172.26.34.223 - - [01/Jul/2005:12:05:27 -0700] "GET /trade/app?action=logout HTTP/1.1" 200 2953
Splunk Enterprise がイベントのインデックスを作成する場合、以下のような処理が⾏われます。
⽂字セットのエンコードを設定する。
複数⾏イベントの⾏分割を設定する。
イベントのタイムスタンプを識別する (イベントにタイムスタンプが存在しない場合はタイムスタンプを割
り当てる)。
host、source、および sourcetype などの、役に⽴つ⼀連の標準フィールドを抽出する。
イベントをセグメントに分割する。
イベントに動的にメタデータを割り当てる (指定されている場合)。
データを匿名化する (指定されている場合)。
Splunk Enterprise のインデックス作成処理の概要については、『インデクサーとクラスタの管理』マニュアルの
「インデックスの概要」を参照してください。
⽂字セットのエンコードの設定
Splunk Enterprise では、データソースの⽂字セットのエンコード を設定することができます。Splunk
Enterprise には、Splunk デプロイ環境 の国際化をサポートするために、内蔵の⽂字セット規格が⽤意されてい
ます。Splunk Enterprise は、さまざまな⾔語をサポートしています (UTF-8 エンコードを使⽤しない⼀部の⾔語
も含む)。
デフォルトでは、ソースに対して UTF-8 エンコードの適⽤が試みられます。ソースが UTF-8 エンコードを使⽤
していない場合、または⾮ ASCII ファイルの場合、props.conf に CHARSET キーを設定して使⽤する⽂字セットを指
定していない限り、Splunk Enterprise はソースからのデータの UTF-8 エンコードへの変換を試みます。
⼤部分の *nix システムでは、iconv -l コマンドを使って有効な⽂字エンコード規格の⼀覧を取得することができ
ます。Windows では iconv のポートを利⽤できます。
サポートする⽂字セット
Splunk Enterprise は、以下のような⽂字セットを含め、多彩な⽂字セットをサポートしています。
UTF-8
UTF-16LE
Latin-1
BIG5
SHIFT-JIS
完全な⼀覧については、このトピックの最後にある「サポートするすべての⽂字セットの⼀覧」を参照してくださ
い。
ここでは、Splunk Enterprise がサポートしている主要な⽂字セットと対応する⾔語の⼀覧を記載しています。
⾔語
コード
99
アラビア語
CP1256
アラビア語
ISO-8859-6
アルメニア語 ARMSCII-8
ベラルーシ語 CP1251
ブルガリア語 ISO-8859-5
チェコ語
ISO-8859-2
グルジア語
Georgian-Academy
ギリシャ語
ISO-8859-7
ヘブライ語
ISO-8859-8
⽇本語
EUC-JP
⽇本語
SHIFT-JIS
韓国語
EUC-KR
ロシア語
CP1251
ロシア語
ISO-8859-5
ロシア語
KOI8-R
スロバキア語 CP1250
スロベニア語 ISO-8859-2
タイ語
TIS-620
ウクライナ語 KOI8-U
ベトナム語
VISCII
⽂字セットの⼿動指定
⼊⼒に適⽤する⽂字セットを⼿動で指定するには、props.conf に
CHARSET
キーを設定します。
[spec]
CHARSET=<string>
たとえば、ギリシャ語のデータを⽣成しているホスト (この例では「GreekSource」) があり、そのホストが ISO8859-7 エンコードを使⽤している場合は、props.conf 内でそのホストに対して CHARSET=ISO-8859-7 を設定します。
[host::GreekSource]
CHARSET=ISO-8859-7
注意： Splunk Enterprise は、UTF-8 マッピングのある⽂字エンコードのみをパーシングします。⼀部の EUCJP ⽂字セットには、UTF-8 エンコードへのマッピングがありません。
⽂字セットの⾃動指定
Splunk Enterprise は、その洗練された⽂字セットエンコードアルゴリズムを使って、⾃動的に⾔語と適切な⽂字
セットを認識することができます。
特定の⼊⼒に対して⾃動的に適切な⾔語と⽂字セットを認識するには、props.conf 内でその⼊⼒に CHARSET=AUTO を
設定します。たとえば、ホスト「my-foreign-docs」の⽂字セットエンコードを⾃動的⻩に認識させる場合
は、props.conf 内でそのホストに CHARSET=AUTO を設定します。
[host::my-foreign-docs]
CHARSET=AUTO
Splunk が⽂字セットを認識しない場合
Splunk Enterprise が認識できない⽂字セットエンコードを使⽤する場合は、以下のパスにサンプルファイルを追
加して、⽂字セットの認識⽅法を学習させます。
$SPLUNK_HOME/etc/ngram-models/_<language>-<encoding>.txt
⽂字セット仕様ファイルを追加したら、Splunk Enterprise を再起動する必要があります。再起動後、新しい⽂字
セットを使⽤するソースを認識できるようになり、インデックス時にそれが⾃動的に UTF-8 に変換されます。
100
たとえば、「vulcan-ISO-12345」⽂字セットを使⽤する場合、仕様ファイルを以下のパスにコピーします。
/SPLUNK_HOME/etc/ngram-models/_vulcan-ISO-12345.txt
サポートするすべての⽂字セットの⼀覧
前述の共通の⽂字セットは、CHARSET 属性がサポートする⽂字セットの⼩さなサブセットに過ぎません。
Splunk Enterprise がサポートしている⽂字セットやエイリアスのリストは膨⼤で、*nix の iconv ユーティリティ
がサポートしているリストと同じです。ここでは、すべての⽂字セットのリストを記載します。また、括弧内はエ
イリアスを表しています。
utf-8 (aka、CESU-8、ANSI_X3.4-1968、ANSI_X3.4-1986、ASCII、CP367、IBM367、ISO-IR-6、
ISO646-US ISO_646.IRV:1991、US、US-ASCII、CSASCII)
utf-16le (aka、UCS-2LE, UNICODELITTLE)
utf-16be (aka、ISO-10646-UCS-2、UCS-2、CSUNICODE、UCS-2BE、UNICODE-1-1、
UNICODEBIG、CSUNICODE11、UTF-16)
utf-32le (aka、UCS-4LE)
utf-32be (aka、ISO-10646-UCS-4、UCS-4、CSUCS4、UCS-4BE、UTF-32)
utf-7 (aka、UNICODE-1-1-UTF-7、CSUNICODE11UTF7)
c99 (aka、java)
utf-ebcdic
latin-1 (aka、CP819、IBM819、ISO-8859-1、ISO-IR-100、ISO_8859-1:1987、L1、CSISOLATIN1)
latin-2 (aka、ISO-8859-2、ISO-IR-101、ISO_8859-2:1987、L2、CSISOLATIN2)
latin-3 (aka、ISO-8859-3、ISO-IR-109、ISO_8859-3:1988、L3、CSISOLATIN3)
latin-4 (aka、ISO-8859-4、ISO-IR-110、ISO_8859-4:1988、L4、CSISOLATIN4)
latin-5 (aka、ISO-8859-9、ISO-IR-148、ISO_8859-9:1989、L5、CSISOLATIN5)
latin-6 (aka、ISO-8859-10、ISO-IR-157、ISO_8859-10:1992、L6、CSISOLATIN6)
latin-7 (aka、ISO-8859-13、ISO-IR-179、L7)
latin-8 (aka、ISO-8859-14、ISO-CELTIC、ISO-IR-199、ISO_8859-14:1998、L8)
latin-9 (aka、ISO-8859-15、ISO-IR-203、ISO_8859-15:1998)
latin-10 (aka、ISO-8859-16、ISO-IR-226、ISO_8859-16:2001、L10、LATIN10)
ISO-8859-5 (aka、CYRILLIC、ISO-IR-144、ISO_8859-5:198,8 CSISOLATINCYRILLIC)
ISO-8859-6(aka、ARABIC、ASMO-708、ECMA-114、ISO-IR-127、ISO_8859-6:1987、
CSISOLATINARABIC、MACARABIC)
ISO-8859-7 (aka、ECMA-118、ELOT_928、GREEK、GREEK8、ISO-IR-126、ISO_8859-7:1987、
ISO_8859-7:2003、CSISOLATINGREEK)
ISO-8859-8 (aka、HEBREW、ISO-8859-8、ISO-IR-138、ISO8859-8、ISO_8859-8:1988、
CSISOLATINHEBREW)
ISO-8859-11
roman-8 (aka、HP-ROMAN8、R8、CSHPROMAN8)
KOI8-R (aka、CSKOI8R)
KOI8-U
KOI8-T
GEORGIAN-ACADEMY
GEORGIAN-PS
ARMSCII-8
MACINTOSH (aka、MAC、MACROMAN、CSMACINTOSH) [注意：これらの MAC* ⽂字セットは
MacOS 9 ⽤です。Mac OS X は Unicode を使⽤しています。]
MACGREEK
MACCYRILLIC
MACUKRAINE
MACCENTRALEUROPE
MACTURKISH
MACCROATIAN
MACICELAND
MACROMANIA
MACHEBREW
MACTHAI
NEXTSTEP
CP850 (aka、850、IBM850、CSPC850MULTILINGUAL)
CP862 (aka、862、IBM862、CSPC862LATINHEBREW)
CP866 (aka、866、IBM866、CSIBM866)
CP874 (aka、WINDOWS-874)
CP932
CP936 (aka、MS936、WINDOWS-936)
CP949 (aka、UHC)
CP950
CP1250 (aka、MS-EE、WINDOWS-1250)
CP1251 (aka、MS-CYRL、WINDOWS-1251)
CP1252 (aka、MS-ANSI、WINDOWS-1252)
CP1253 (aka、MS-GREEK、WINDOWS-1253)
CP1254 (aka、MS-TURK、WINDOWS-1254)
CP1255 (aka、MS-HEBR、WINDOWS-1255)
CP1256 (aka、MS-ARAB、WINDOWS-1256)
CP1257 (aka、WINBALTRIM、WINDOWS-1257)
CP1258 (aka、WINDOWS-1258)
CP1361 (aka、JOHAB)
BIG-5 (aka、BIG-FIVE、CN-BIG5、CSBIG5)
BIG5-HKSCS(aka、BIG5-HKSCS:2001)
CN-GB (aka、EUC-CN、EUCCN、GB2312、CSGB2312)
EUC-JP (aka、EXTENDED_UNIX_CODE_PACKED_FORMAT_FOR_JAPANESE、
CSEUCPKDFMTJAPANESE)
EUC-KR (aka、CSEUCKR)
101
EUC-TW (aka、CSEUCTW)
GB18030
GBK
GB_1988-80 (aka、ISO-IR-57、ISO646-CN、CSISO57GB1988、CN)
HZ (aka、HZ-GB-2312)
GB_2312-80 (aka、CHINESE, ISO-IR-58、CSISO58GB231280)
SHIFT-JIS (aka、MS_KANJI、SJIS, CSSHIFTJIS)
ISO-IR-87 (aka、JIS0208 JIS_C6226-1983、JIS_X0208 JIS_X0208-1983、JIS_X0208-1990、
X0208、CSISO87JISX0208、ISO-IR-159、JIS_X0212、JIS_X0212-1990、JIS_X0212.1990-0、
X0212、CSISO159JISX02121990)
ISO-IR-14 (aka、ISO646-JP、JIS_C6220-1969-RO、JP、CSISO14JISC6220RO)
JISX0201-1976 (aka、JIS_X0201、X0201、CSHALFWIDTHKATAKANA)
ISO-IR-149 (aka、KOREAN、KSC_5601、KS_C_5601-1987、KS_C_5601-1989、CSKSC56011987)
VISCII (aka、VISCII1.1-1、CSVISCII)
ISO-IR-166 (aka、TIS-620、TIS620-0、TIS620.2529-1、TIS620.2533-0、TIS620.2533-1)
注意： Splunk Enterprise は、CHARSET の照合時に句読点と⼤⽂字⼩⽂字の区別を無視します。たとえば、
「utf-8」、「UTF-8」、および「utf8」はすべて同⼀とみなされます。
イベント改⾏の設定
イベントの中には複数の⾏から構成されているものもあります。デフォルトで Splunk Enterprise は、⼤部分の
複数⾏イベントを正確に処理できます。正しく処理されない複数⾏イベントがある場合は、ソフトウェアの⾏分割
動作を変更するように設定する必要があります。
Splunk Enterprise がイベント境界を判別する仕組み
Splunk Enterprise は 2 つのステップで、イベント境界を判別しています。
1. 改⾏、LINE_BREAKER 属性の正規表現値を使って、受信ストリームのバイトを個別の⾏に分割します。デフォルト
で、LINE_BREAKER は任意の改⾏または復帰改⾏ (([\r\n]+)) になります。
2. ⾏の結合、SHOULD_LINEMERGE 属性が真 (True) (デフォルト) の場合にのみ⾏われます。このステップは、他のすべ
ての⾏結合設定 (例：BREAK_ONLY_BEFORE, BREAK_ONLY_BEFORE_DATE, MUST_BREAK_AFTER, など) を使って、以前に分割した
⾏を結合してイベントを作成します。
2 番⽬のステップが実⾏されない場合 (SHOULD_LINEMERGE に偽 (False) を設定した場合)、イベントは単純に
LINE_BREAKER により決定される、個別の⾏になります。最初のステップは⽐較的効率的に⾏われますが、2 番⽬の
ステップの処理には⽐較的時間がかかります。LINE_BREAKER 正規表現を熟知していれば、最初のステップだけ実施
して、2 番⽬のステップを⾶ばしても、⼗分に⽬的の結果を得られることがあります。データの⼤部分が複数⾏イ
ベントである場合などに、この⽅法が特に役⽴ちます。
イベント境界の設定⽅法
多くのログは厳密に 1 ⾏に 1 つのイベントの形式を採⽤していますが、そうではないログも存在しています。⼀
般的には、Splunk Enterprise が⾃動的にイベント境界を認識することができます。イベント境界の認識が正しく
⾏われない場合には、props.conf にカスタムルールを設定することができます。
複数⾏イベントを設定するには、まずイベントの形式を調査します。イベントの開始または終了を設定するため
に、イベント内のパターンを判断します。次に $SPLUNK_HOME/etc/system/local/props.conf を編集して、データを設
定するために必要な属性を指定します。
複数⾏イベントを処理するには、2 種類の⽅法があります。
データストリームを⾏に分割し、それをイベントに再構築する。⼀般的にこの⽅法は、複数の属性を使って
⾏結合ルールを定義できるため、設定プロセスが簡単になります。データを複数の⾏に分割するに
は、LINE_BREAKER 属性を使⽤します。それと⼀緒に、SHOULD_LINEMERGE=true を設定し、また⾏結合属性
(BREAK_ONLY_BEFORE など) を設定して、⾏を再構築してイベントを作成する⽅法を Splunk に指⽰します。
データがデフォルトの LINE_BREAKER 設定 (任意の数の改⾏と復帰改⾏) に正しく準拠している場合
は、LINE_BREAKER を変更する必要はありません。単純に SHOULD_LINEMERGE=true を設定して、再構築するための
⾏結合属性を使⽤します。
LINE_BREAKER 機能を使って、データストリームを直接イベントに分割する。この⽅法はインデックス作成速
度が向上する可能性がありますが、作業はある程度複雑で困難になります。インデックス作成に時間がかか
り、⼤量のデータが複数⾏イベントから成り⽴っている場合は、この⽅法でパフォーマンスを⼤幅に改善す
ることができます。LINE_BREAKER 属性と SHOULD_LINEMERGE=false を使⽤します。
これらの属性については後述します。
⾏分割の⼀般属性
⾏分割に影響する
属性
TRUNCATE = <nonnegative integer>
props.conf
属性を以下に⽰します。
説明
デフォルト
デフォルトの最⼤⾏⻑ (バイト) を変更します。この
属性の単位はバイトですが、複数バイト⽂字のために
⽂字の途中で終了する場合、⾏の⻑さが丸められるこ
とに注意してください。
切り詰めを⾏わない場合は 0 を設定します (た
102
10000 バイト
だし、⾮常に⻑い⾏はしばしば無効なデータの
兆候でもあります)。
LINE_BREAKER = <regular
expression>
* ⾏の結合処理 (後述の SHOULD_LINEMERGE 属性が指定さ
れている場合) を⾏う前の、raw テキストを初期イベ
ントに分割する⽅法を決定する正規表現を指定しま
す。
正規表現には、捕捉グループ (⼀致項⽬の識別さ
れたサブコンポーネントを定義する括弧のペア)
を含める必要があります。
正規表現に⼀致する場合、Splunk Enterprise
は最初の捕捉グループの開始点を前のイベント
の終了点とみなし、最初の捕捉グループの終了
点を次のイベントの開始点とみなします。
最初の捕捉グループの内容は破棄されます。こ
の内容は、どのイベントにも存在しません。こ
れは、Splunk にそのテキストが⾏間に存在して
いることを知らせるものです。
注意： LINE_BREAKER を使って複数⾏イベントを分
割した場合 (SHOULD_LINEMERGE を使って個別の⾏
を複数⾏イベントに再構築しない)、処理速度が
⼤幅に向上することを実感できると思います。
データの⼤部分が複数⾏イベントである場合な
どに、この⽅法の使⽤を検討してください。
LINE_BREAKER と分岐式の使⽤⽅法の詳細は、
props.conf 仕様ファイルを参照してください。
LINE_BREAKER_LOOKBEHIND
= <integer>
SHOULD_LINEMERGE =
[true|false]
(この場合、任意の数
の復帰改⾏ (\r) または改⾏ (\n)
⽂字で区切られている各⾏が、
それぞれ 1 つのイベントに分割
されます。)
([\r\n]+)
* 前の raw データチャンクからの残りデータがある場
合、Splunk が LINE_BREAKER 正規表現を適⽤する raw
データチャンクの終了 (次のチャンクを連結した状態
で) までの⽂字数を LINE_BREAKER_LOOKBEHIND に指定し
ます。特に巨⼤なイベントや複数⾏イベントを処理す
る場合に、この値をデフォルト値よりも増やした⽅が
良い場合があります。
100 ⽂字
* 真 (True) を設定すると、Splunk Enterprise は複数
の⼊⼒⾏を単⼀のイベントにまとめ、次のセクション
で説明している属性に基づいて設定を⾏います。
true
SHOULD_LINEMERGE に真 (True) を設定した場合にのみ適⽤される属性
SHOULD_LINEMERGE=true
(デフォルト) の場合、これらの属性を使って⾏分割動作を定義します。
属性
BREAK_ONLY_BEFORE_DATE
= [true|false]
BREAK_ONLY_BEFORE =
<regular expression>
MUST_BREAK_AFTER =
<regular expression>
説明
デフォルト
真 (True) を設定すると、⽇付のある改⾏に遭遇した場 true
合にのみ新しいイベントが作成されます。
注意： DATETIME_CONFIG に
CURRENT または NONE を設定
した場合、Splunk はタイ
ムスタンプを識別しない
ため、この属性は意味を
持たなくなります。
真 (True) を設定すると、正規表現に⼀致する改⾏に遭 空⽂字列
遇した場合にのみ新しいイベントが作成されます。
設定した場合に、現在の⾏と正規表現が⼀致すると、
次の⼊⼒⾏⽤の新しいイベントが常に作成されます。
空⽂字列
他のルールと⼀致した場合、現在の⾏の前で分割
されることもあります。
設定した場合に、現在の⾏が正規表現と⼀致すると、
以降の⾏は MUST_BREAK_AFTER 式に⼀致するまでの間分
割されません。
空⽂字列
<regular expression>
MUST_NOT_BREAK_BEFORE
設定した場合に、現在の⾏が正規表現に⼀致すると、
現在の⾏の前の最後のイベントは分割されません。
空⽂字列
任意のイベントに追加する⼊⼒⾏数の最⼤値を指定し
ます。
256 ⾏
MUST_NOT_BREAK_AFTER =
= <regular expression>
MAX_EVENTS = <integer>
指定した⾏数を読み込んだ後に分割されます。
例
103
イベント分割の指定
[my_custom_sourcetype]
BREAK_ONLY_BEFORE = ^\d+\s*$
数字のみで構成されている⾏を新しいイベントの開始として、イベントを分割する例を以下に⽰します。ソースタ
イプが my_custom_sourcetype の任意のデータに対して処理を⾏います。
複数⾏を単⼀のイベントに結合
以下のログイベントには、同じリクエストの⼀部となる複数の⾏が含まれています。各リクエスト間の違いはパス
(Path) です。この例では、これらのすべての⾏を単⼀のイベントエントリとして表⽰する必要があることを前提
にしています。
{{"2006-09-21, 02:57:11.58", 122, 11, "Path=/LoginUser
Query=CrmId=ClientABC&ContentItemId=TotalAccess&SessionId=3A1785URH117BEA&Ticket=646A1DA4STF896EE&SessionTime=25368&ReturnUrl=http://www.client
Method=GET, IP=209.51.249.195, Content=", ""}}
{{"2006-09-21, 02:57:11.60", 122, 15, "UserData:<User CrmId="clientabc"
UserId="p12345678"><EntitlementList></EntitlementList></User>", ""}}
{{"2006-09-21, 02:57:11.60", 122, 15, "New Cookie:
SessionId=3A1785URH117BEA&Ticket=646A1DA4STF896EE&CrmId=clientabc&UserId=p12345678&AccountId=&AgentHost=man&AgentId=man,
MANUser:
Version=1&Name=&Debit=&Credit=&AccessTime=&BillDay=&Status=&Language=&Country=&Email=&EmailNotify=&Pin=&PinPayment=&PinAmount=&PinPG=&PinPGRate
""}}
この複数⾏イベントのインデックスを正しく作成するには、設定に Path を使⽤しま
す。$SPLUNK_HOME/etc/system/local/props.conf に以下の項⽬を追加します。
[source::source-to-break]
SHOULD_LINEMERGE = True
BREAK_ONLY_BEFORE = Path=
このコードは、イベントの各⾏を結合して、⽤語
Path=
の前でのみ分割することを表しています。
複数⾏イベントの⾏分割とセグメント分割の制限事項
極端に⼤きなイベントには、⾏分割とセグメント分割制限が適⽤されます。
10,000 バイトを超える⾏： Splunk Enterprise は、10,000 バイトを超える⾏のインデックスを作成する
場合、それぞれが 10,000 バイトの複数⾏に分割します。切り詰められた各セクションの最後に
は、meta::truncated フィールドが追加されます。ただし、Splunk Enterprise は引き続きこれらの⾏を単⼀
のイベントにグループ化します。
100,000 バイトを超えるイベントのセグメント分割： サーチ結果には、イベントの最初の 100,000 バ
イトしか表⽰されません。ただし、⾮常に⻑い⾏の最初の 100,000 バイト以降のセグメントを、サーチす
ることは可能です。
1,000 セグメントを超えるイベントのセグメント分割： サーチ結果では、イベントの最初の 1,000 件の
セグメントが、セグメントとして空⽩⽂字で区切られて表⽰されます。マウスカーソルをセグメントの上に
移動すると、強調表⽰されます。イベントの残りの部分は raw テキストとして表⽰され、対話形式の書式は
設定されません。
Answers
何か質問がありますか？「Splunk Answers」では、Splunk コミュニティに寄せられた、⾏分割に関する質問と
回答をご覧いただけます。
イベントのタイムスタンプの設定
このトピックは、Splunk Enterprise でのタイムスタンプの設定⽅法について説明しています。
次のサンプルイベントを調査します。
172.26.34.223 - - [01/Jul/2005:12:05:27 -0700] "GET /trade/app?action=logout HTTP/1.1" 200 2953
イベント内の時間情報に注⽬してください：[01/Jul/2005:12:05:27 -0700]。これが、タイムスタンプ になります。
Splunk Enterprise はタイムスタンプを使って、時間別にイベントを相関させ、Splunk Web でのヒストグラムの
作成やサーチの時間範囲の設定を⾏います。⼤部分のイベントにはタイムスタンプが含まれています。イベントに
タイムスタンプ情報が含まれていない場合は、インデックス時のタイムスタンプ値がイベントに割り当てられま
す。
たいていの場合、タイムスタンプの処理は正しく⾏われますが、状況によってはタイムスタンプの処理⽅法を設定
しなければならないこともあります。たとえば、⼀部のソースを利⽤している、または分散デプロイ環境を運⽤し
ている場合、タイムスタンプの認識とフォーマットを再設定しなければならないことがあります。
タイムスタンプの詳細は、このマニュアルの「タイムスタンプの設定」を参照してください。
104
インデックス作成フィールド抽出の設定
Splunk がインデックス時に抽出できるフィールドは 3 種類あります。
デフォルトフィールド
カスタムフィールド
ファイルヘッダーフィールド
Splunk Enterprise は各イベントに対して、常に⼀連のデフォルトフィールドを抽出しています。カスタムフィー
ルド、またデータによってはファイルヘッダーフィールドを抽出するように設定することも可能です。
インデックス作成フィールドの抽出の詳細は、このマニュアルの「インデックス作成フィールドの抽出」を参照し
てください。
データの匿名化
このトピックは、Splunk Enterprise に取り込まれる、クレジットカード番号や社会保障番号などのデータの匿名
化について説明しています。
ログイベントのインデックス作成時に、個⼈の機密情報を隠したい場合もあります。クレジットカード番号や社会
保障番号などは、インデックスに表⽰させたくないデータです。このトピックでは、プライバシーを保護するため
に機密情報フィールドの⼀部をマスクしながら、残りのデータでイベントを追跡できるようにする⽅法を説明して
います。
Splunk Enterprise では、2 種類の⽅法でデータを匿名化することができます。
正規表現変換を使⽤する
ストリームエディタ処理 (sed) スクリプトを使⽤する
正規表現変換を使ったデータの匿名化
transforms.conf
で正規表現を利⽤して、データをマスクすることができます。
この例では、アプリケーションサーバーログの
いて残りの⽂字をマスクします。
SessionId
および
Ticket number
フィールドの、最後の 4 ⽂字を除
⽬的の出⼒は以下のようになります。
SessionId=###########7BEA&Ticket=############96EE
⼊⼒のサンプルは以下のようになります。
"2006-09-21, 02:57:11.58",
122, 11, "Path=/LoginUser Query=CrmId=ClientABC&
ContentItemId=TotalAccess&SessionId=3A1785URH117BEA&Ticket=646A1DA4STF896EE&
SessionTime=25368&ReturnUrl=http://www.clientabc.com, Method=GET,IP=209.51.249.195,
Content=", ""
"2006-09-21, 02:57:11.60",
122, 15, "UserData:<User CrmId="clientabc"
UserId="p12345678"><EntitlementList></EntitlementList></User>", ""
"2006-09-21, 02:57:11.60",
122, 15, "New Cookie: SessionId=3A1785URH117BEA&
Ticket=646A1DA4STF896EE&CrmId=clientabcUserId=p12345678&AccountId=&AgentHost=man&
AgentId=man, MANUser: Version=1&Name=&Debit=&Credit=&AccessTime=&BillDay=&Status=
&Language=&Country=&Email=&EmailNotify=&Pin=&PinPayment=&PinAmount=&PinPG=
&PinPGRate=&PinMenu=&", ""
データをマスクするには、$SPLUNK_HOME/etc/system/local/ ディレクトリ内の
イルを変更します。
props.conf
および
transforms.conf
ファ
props.conf の設定
$SPLUNK_HOME/etc/system/local/props.conf
を編集して、以下のスタンザを追加します。
[<spec>]
TRANSFORMS-anonymize = session-anonymizer, ticket-anonymizer
以下の事項に注意してください。
<spec>
には、以下のいずれかを使⽤する必要があります。
<sourcetype>、イベントのソースタイプ。
host::<host>、ここで <host>
はイベントのホストを表します。
はイベントのソースを表します。
および ticket-anonymizer は任意の TRANSFORMS クラス名で、そのアクショ
ファイル内のスタンザに定義されています。transforms.conf 内に作成したクラ
source::<source>、ここで <source>
この例で、session-anonymizer
ンは対応する transforms.conf
ス名を使⽤してください。
transforms.conf の設定
105
$SPLUNK_HOME/etc/system/local/transforms.conf
に、適切な TRANSFORMS を追加します。
[session-anonymizer]
REGEX = (?m)^(.*)SessionId=\w+(\w{4}[&"].*)$
FORMAT = $1SessionId=########$2
DEST_KEY = _raw
[ticket-anonymizer]
REGEX = (?m)^(.*)Ticket=\w+(\w{4}&.*)$
FORMAT = $1Ticket=########$2
DEST_KEY = _raw
以下の事項に注意してください。
REGEX
には、イベント内の匿名化する⽂字列を指す正規表現を指定する必要があります。
注意： 正規表現プロセッサは、複数⾏イベントを処理しません。この問題に対処するためには、イベントが複数
⾏であることを指定する必要があります。transforms.conf 内の正規表現の前に、(?m) を設定してください。
は、マスク値を⽰します。$1は正規表現までのすべてのテキスト、$2 は正規表現後のすべてのテキス
トです。
FORMAT
DEST_KEY = _raw
は、FORMAT からの値をログ内の raw 値に書き込んでイベントを変更することを⽰していま
す。
sed
スクリプトを使ったデータの匿名化
sed
スクリプトを使ってイベント内の⽂字列を置換/代替することで、データを匿名化することもできます。
UNIX ユーザーの⽅ならば、おそらく UNIX ユーティリティ sed をご存じかと思います。このユーティリティ
は、ファイルを読み込んで、指定されている⼀連のコマンドに従って⼊⼒を変更します。Splunk Enterprise で
は、props.conf 内で sed 類似の構⽂を使って、データを匿名化することができます。
props.conf への sed スクリプトの定義
$SPLUNK_HOME/etc/system/local
sed script
内に
props.conf
のコピーを作成または編集します。
を指定するには、SEDCMD を使⽤するスタンザを
props.conf
に作成します。
[<spec>]
SEDCMD-<class> = <sed script>
以下の事項に注意してください。
<spec>
には、以下のいずれかを使⽤する必要があります。
<sourcetype>、イベントのソースタイプ。
host::<host>、ここで <host>
はイベントのホストを表します。
はイベントのソースを表します。
source::<source>、ここで <source>
は、インデックス時に _raw フィールドにのみ適⽤されます。現在 Splunk Enterprise は、以下の
コマンドのサブセットをサポートしています。
置換 (s)
⽂字代替 (y)
sed script
sed
注意： props.conf を変更したら、変更内容を反映するために Splunk Enterprise を再起動してください。
正規表現照合による⽂字列の置換
sed
置換の構⽂を以下に⽰します。
SEDCMD-<class> = s/<regex>/<replacement>/flags
以下の事項に注意してください。
は、PERL 正規表現です。
は、正規表現に⼀致した項⽬と置換する⽂字列です。「\n」は逆参照を⽰しており、n は単⼀の
数字です。
flags に「g」を指定すると、すべての⼀致項⽬が置換されます。また、数字を指定すると、指定された⼀致
項⽬が置換されます。
regex
replacement
例
以下の例では、社会保障番号とクレジットカード番号を含むデータのインデックスを作成します。インデックス時
に、イベント内でこれらの値は最後の 4 桁のみを表⽰し、残りはマスクします。props.conf スタンザは以下のよう
106
になります。
[source::.../accounts.log]
SEDCMD-accounts = s/ssn=\d{5}(\d{4})/ssn=xxxxx\1/g s/cc=(\d{4}-){3}(\d{4})/cc=xxxx-xxxx-xxxx-\2/g
これで、イベント内で社会保障番号は
⽰されるようになります。
ssn=xxxxx6789、クレジットカード番号は cc=xxxx-xxxx-xxxx-1234
のように表
⽂字の代替
sed
⽂字代替の構⽂を以下に⽰します。
SEDCMD-<class> = y/<string1>/<string2>/
これにより、string1 内の各⽂字が、string2 内の⽂字で代⽤されます。
例
インデックスを作成するファイル abc.log があり、イベント内では⼩⽂字の「a」、「b」、「c」の代わりに、⼤
⽂字の「A」、「B」、および「C」を使⽤したい場合を考えてみましょう。props.conf に以下の項⽬を追加しま
す。
[source::.../abc.log]
SEDCMD-abc = y/abc/ABC/
これで、source="*/abc.log" でサーチしても、データ内に⼩⽂字の「a」、「b」、「c」は⾒つからないはずです。
Splunk Enterprise により、各「a」が「A」に、「b」が「B」に、「c」が「C」に代替されています。
タイムスタンプの設定
タイムスタンプ割り当ての仕組み
Splunk Enterprise でタイムスタンプ は⾮常に重要な役割を果たします。Splunk Enterprise はタイムスタンプ
を使って、時間別にイベント を相関させ、Splunk Web でのタイムラインヒストグラムの作成やサーチの時間範
囲の設定を⾏います。
イベントへのタイムスタンプの割り当ては、インデックス時 に⾏われます。通常タイムスタンプ値は、raw イベ
ントデータ内の情報を使って⾃動的に割り当てられます。イベントに明⽰的なタイムスタンプがない場合は、他の
⼿段でのタイムスタンプ値の割り当てが試みられます。⼀部のデータでは、タイムスタンプの認識⽅法を設定しな
ければならないこともあります。
Splunk Enterprise はタイムスタンプ値を
_time
フィールドに 保管します (UTC 形式)。
タイムスタンプ処理は、イベント処理 時の主要ステップの 1 つです。イベント処理の詳細は、このマニュアルの
「イベント処理の設定」を参照してください。
Splunk Enterprise によるタイムスタンプの割り当て⽅法
Splunk Enterprise は、以下の優先ルールを使って、イベントにタイムスタンプを割り当てます。
1. TIME_FORMATが明⽰的に指定されている場合は、それを使ってイベントの⽇時を探します。props.conf に
TIME_FORMAT 属性を設定します。
2. データに TIME_FORMAT が設定されていない場合は、Splunk Enterprise がイベントのタイムスタンプを判別しよ
うと試みます。イベントのソースタイプ (TIME_FORMAT 情報が含まれている) を使ってタイムスタンプを探します。
3. イベントに時間または⽇付がない場合は、同じソースからの直前のイベントを使⽤します。
4. ソース内のイベントに⽇付がない場合は、ソース名またはファイル名から⽇付を探します。ファイル名で時刻は
識別されません。(この場合、イベントには⽇付がなくとも、時刻が存在している必要があります。)
5. ファイルソースの場合、ファイル名から⽇付を特定できなかった場合、そのファイルの変更時刻を使⽤します。
6. 最後の⼿段として、各イベントのインデックス作成時に、現在のシステム時刻をタイムスタンプとして設定しま
す。
注意： Splunk Enterprise はソースから⽇付のみを抽出できます。時間は抽出できません。ソースから時刻を抽
出する必要がある場合は、transform を使⽤します。
タイムスタンプの設定
⼤部分のイベントでは、特別なタイムスタンプ処理を⾏う必要はありません。Splunk Enterprise が⾃動的にタイ
ムスタンプを認識して抽出します。ただし、⼀部のソースや分散デプロイ環境では、タイムスタンプが適切に
フォーマットされるように、タイムスタンプの抽出⽅法を設定しなければならないことがあります。
107
タイムスタンプ抽出を設定するには、2 種類の⽅法があります。
サンプル・データのタイムスタンプを対話的に調整するには、Splunk Web の [ソースタイプの設定] ページ
を使⽤します。満⾜できる結果が得られたら、変更内容を新しいソースタイプに保存して、そのソースタイ
プをデータ⼊⼒に適⽤します。「[ソースタイプの設定] ページ」を参照してください。
props.conf を直接編集する。詳細は、「タイムスタンプ認識の設定」を参照してください。
以下の⽬的で、タイムスタンプ抽出プロセッサを設定することも可能です。
タイムゾーンオフセットを適⽤する。
複数のタイムスタンプを使ってイベントから正確なタイムスタンプを取得する。
インデックス作成パフォーマンスを向上する。
新しい⼊⼒からデータを追加する場合の注意事項
新しい⼊⼒からのデータのインデックスを作成した後に、タイムスタンプの抽出処理を調整する必要があることに
気が付いた場合は、設定を変更した後に、データのインデックスを再作成する必要があります。そのため、「デー
タのプレビュー」で説明しているように、データのプレビューを⾏うことをお勧めします。
または、新しいデータ⼊⼒をテスト⽤ Splunk Enterprise インスタンスで (または実働環境 Splunk インスタンス
の別のインデックスを使⽤して) テストしてから、実働環境のインスタンスにデータを追加します。そうすること
で、何か調整が必要な場合でも、データを⼿軽に削除してから、インデックスを再作成して、⽬的の結果が得られ
るまで調整を⾏うことができます。
タイムスタンプ認識の設定
⼤部分のイベントでは、特別なタイムスタンプ処理を⾏う必要はありません。Splunk Enterprise が⾃動的にタイ
ムスタンプを認識して抽出します。ただし、⼀部のソースや分散デプロイ環境では、タイムスタンプが適切に
フォーマットされるように、タイムスタンプの抽出⽅法を設定しなければならないことがあります。
タイムスタンプ抽出を設定するには、2 種類の⽅法があります。
サンプル・データのタイムスタンプを対話的に調整するには、Splunk Web の [ソースタイプの設定] ページ
を使⽤します。満⾜できる結果が得られたら、変更内容を新しいソースタイプに保存して、そのソースタイ
プをデータ⼊⼒に適⽤します。「[ソースタイプの設定] ページ」を参照してください。
props.conf を直接編集する。タイムスタンプ抽出のための、props.conf の編集⽅法については、このまま読
み進めてください。
タイムスタンププロセッサ
Splunk Enterprise のタイムスタンププロセッサは、デフォルトでは $SPLUNK_HOME/etc/datetime.xml に存在してい
ます。例外的な独⾃のタイムスタンプを処理するのではない限り、通常このファイルを編集する必要はありませ
ん。何らかの⽅法でタイムスタンプ認識⽅法を設定する必要がある場合は、通常は後述のように props.conf のタイ
ムスタンプ属性設定を変更することで問題を解決できます。
の設定では対処できない独⾃のタイムスタンプがある場合は、DATETIME_CONFIG 属性を使って、独⾃のタ
イムスタンププロセッサで代⽤することができます (次のセクションを参照)。この属性には、Splunk Enterprise
がタイムスタンプ処理に使⽤するファイルを指定します。
props.conf
props.conf でのタイムスタンププロパティの編集
タイムスタンプの認識⽅法を設定するには、props.conf を編修します。タイムスタンプに関連するさまざまな属
性が存在しています。特に、TIME_FORMAT 属性を使ってタイムスタンプの strptime() フォーマットを指定すること
で、Splunk Enterprise によるタイムスタンプの認識⽅法を決定することができます。また、その他のタイムスタ
ンプ関連属性を設定することもできます。たとえば、イベント内のタイムスタンプの位置、使⽤するタイムゾー
ン、さまざまな単位のタイムスタンプの処理⽅法などを指定することができます。
内、または $SPLUNK_HOME/etc/apps/ の独⾃のカスタムアプリケーションディレクトリ
内にある、props.conf ファイルを編集します。設定ファイルの⼀般情報については、『管理マニュアル』の「設定
ファイルについて」を参照してください。
$SPLUNK_HOME/etc/system/local/
タイムスタンプ認識を設定するには、props.conf 内の 1 つまたは複数のタイムスタンプ属性を設定します。これら
の属性およびその他の属性の詳細は、props.conf 仕様ファイルを参照してください。
構⽂の概要
タイムスタンプ属性の構⽂の概要を以下に⽰します。
[<spec>]
DATETIME_CONFIG = <filename relative to $SPLUNK_HOME>
TIME_PREFIX = <regular expression>
MAX_TIMESTAMP_LOOKAHEAD = <integer>
TIME_FORMAT = <strptime-style format>
TZ = <posix time zone string>
MAX_DAYS_AGO = <integer>
MAX_DAYS_HENCE = <integer>
108
MAX_DIFF_SECS_AGO = <integer>
MAX_DIFF_SECS_HENCE = <integer>
この構⽂で、<spec> には以下のものを使⽤できます。
<sourcetype>、イベントのソースタイプ。
host::<host>、ここで <host>
source::<source>、<source>
はイベントのホストを表します。
はイベントのソース値を表します。
イベントに <spec> の値と⼀致するデータが含まれている場合、スタンザに定義されているタイムスタンプルール
がそのイベントに適⽤されます。異なる <spec> 値に対処するために、複数のスタンザを設定することができま
す。
タイムスタンプ属性
props.conf
に設定できるタイムスタンプ属性を以下に⽰します。
属性
説明
DATETIME_CONFIG = <filename
Splunk Enterprise のタイムスタンププロセッサの
設定に使⽤するファイルを指定します。
relative to $SPLUNK_HOME>
デフォルト
$SPLUNK_HOME/etc/datetime.xml
標準環境下では、独⾃のタイムスタンププロ
セッサファイルを作成したり、デフォルトの
datetime.xml ファイルを修正したりする必要
はありません。⼀般的には、このトピックに
記述されている他の props.conf 属性を使っ
て、ご⾃分のニーズを満たすように、Splunk
Enterprise のタイムスタンプ認識機能を調整
することができます。ただし、データに独⾃
のタイムスタンプ形式が存在している場合
は、このファイルに代わる独⾃のファイルを
作成して、それで機能を代⽤しなければなら
ないこともあります。
タイムスタンププロセッサの実⾏を防⽌する
場合は、DATETIME_CONFIG = NONE を設定しま
す。タイムスタンプ処理をオフにすると、イ
ベント内のタイムスタンプ・テキストが調査
されることはありません。代わりにイベント
の「受信時刻」が使⽤されます (⼊⼒からイ
ベントを受信した時刻)。ファイルベースの⼊
⼒の場合、イベントのタイムスタンプは、⼊
⼒ファイルの変更時刻から取得されます。
DATETIME_CONFIG = CURRENT を設定すると、イン
デックス作成時に現在のシステム時刻が各イ
ベントに割り当てられます。
注意： CURRENT と NONE の両⽅が、明⽰的にタ
イムスタンプの識別を無効にします。そのた
め、デフォルトのイベント境界検出
(BREAK_ONLY_BEFORE_DATE = true) は、⽬的通り
には機能しません。これらの設定を使⽤する
場合は、SHOULD_LINEMERGE や BREAK_ONLY_* ,
MUST_BREAK_* 設定を使ってイベントの結合を
管理します。
TIME_PREFIX = <regular
expression>
設定した場合、Splunk Enterprise はタイムスタン 空⽂字列
プの抽出を試みる前に、この正規表現と⼀致する
イベントテキスト内の項⽬を探します。タイムス
タンプアルゴリズムは、最初の正規表現⼀致項⽬
の最後に続くイベントテキスト内のみで、タイム
スタンプを探します。
イベントのタイムスタンプの直前を正確に指
⽰する正規表現を使⽤する必要があります。
たとえば、フレーズ「abc123」に続いてタイ
ムスタンプが登場する場合、TIME_PREFIX には
abc123 を設定する必要があります。
イベントテキスト内に TIME_PREFIX が⾒つか
らなかった場合、タイムスタンプの抽出は⾏
われません。
MAX_TIMESTAMP_LOOKAHEAD =
<integer>
Splunk Enterprise がイベント内でタイムスタンプ 150 ⽂字
をどこまで探すのかを、⽂字数で指定します。
これらの制約は、TIME_PREFIX が⽰す位置
から適⽤されます。
たとえば、TIME_PREFIX の位置がイ
ベント内の 11 ⽂字⽬で、
MAX_TIMESTAMP_LOOKAHEAD に
109
10 が設定されている場合、タイムスタ
ンプ抽出は、11〜20 ⽂字に制限されま
す。
0 または-1 を設定した場合、タイムスタンプ
認識の⻑さ制約は事実上無効になります。こ
のことは、⼊⼒⾏の⻑さ (またはイベント分
割⽤に LINE_BREAKER が再定義された時
のイベントサイズ) に応じて負の影響が出る
可能性があります。
TIME_FORMAT = <strptimestyle format>
タイムスタンプを抽出するための、strptime()
フォーマット⽂字列を指定します。
空⽂字列
は、時間フォーマットを指定する
ための UNIX 標準規格です。詳細は、後述す
る「拡張 strptime() サポート」を参照してく
ださい。
TIME_FORMAT は、TIME_PREFIX の後 (TIME_PREFIX
属性が指定されていない場合はイベントの開
始点) から読み込みを開始しま
す。TIME_PREFIX を使⽤する場合、タイムスタ
ンプの開始点前の⽂字列と⼀致し、それらの
⽂字が含まれるように指定する必要がありま
す。TIME_PREFIX を設定せずに TIME_FORMAT を
設定する場合、タイムスタンプは各イベント
の開始点に登場する必要があります。そうし
ないと、設定されているフォーマットに従っ
て処理することができないため、各イベント
には警告が含まれ、strptime を使⽤すること
はできません。(それでも、Splunk が問題に
どのように対処するのかによっては、有効な
タイムスタンプが得られる可能性がありま
す。)
最良の結果を得るために、<strptime-style
format> には年の⽇付、および⽇の時刻を記述
する必要があります。
<strptime-style format> に時間コンポーネント
が含まれているけれども、分コンポーネント
が含まれていない場合、TIME_FORMAT は
時間コンポーネントを無視します。フォー
マットは例外として取り扱われ、精度は⽇付
のみとみなされます。
strptime()
TZ = <time zone identifier>
* Splunk Enterprise は以下のように、特定のイベ
ントのタイムゾーンを判断します。
空⽂字列
イベントの raw テキストにタイムゾー
ンがある場合は (UTC や -08:00 など)、
それが使⽤されます。
そうでない場合は、TZ に有効なタイム
ゾーン⽂字列が設定されていれば、そ
れが使⽤されます。zoneinfo TZ デー
タベースからの値を使って、タイム
ゾーン設定を指定します。
インデクサーに到着したイベントの起
源がフォワーダーで、インデクサーと
フォワーダーの両⽅で Splunk
Enterprise 6.0 以降が動作している場
合は、フォワーダーのタイムゾーンを
使⽤します。
それ以外の場合は、splunkd が動作して
いるシステムのタイムゾーンを使⽤し
ます。
詳細と例については、このマニュアルの「タ
イムスタンプのタイムゾーンの指定」を参照
してください。
TZ_ALIAS =
<key=value>[,<key=value>]...
* イベントから抽出されたタイムゾーン⽂字列の解 未設定
釈⽅法に対して、管理者レベルの制御を提供しま
す。たとえば、EST は⽶国の東部標準時 (Eastern
Standard Time) または豪州の東部標準時
(Eastern Standard Time) と解釈することができ
ます。その他にも、複数のタイムゾーンに解釈で
きる、3 ⽂字のタイムゾーン省略形が存在していま
す。
これらの値に対する従来の Splunk デフォル
トマッピングが期待通りに機能する場
合、TZ_ALIAS の使⽤に関する要件はありませ
ん。たとえば、デフォルトで EST は⽶国東
部標準時にマップされます。
110
の値には効果がありません。TIME_FORMAT に
設定されている、またはパターンベースの推
測フォールバックからの、イベントテキスト
内のタイムゾーン⽂字列にのみ影響します。
この設定は key=value ペアをカンマで区切っ
たリストです。
このキーは、イベントのタイムゾーン指定⼦
のテキストに対して照合され、値はタイムス
タンプを UTC/GMT にマッピングする際に
使⽤するタイムゾーン指定⼦になります。
値は、必要なオフセットを表す他の TZ 指定
⼦です。
例：TZ_ALIAS = EST=GMT+10:00(その他の例につ
いては、「設定ファイルリファレンス」の
props.conf サンプルファイルを参照してくだ
さい)。
TZ
MAX_DAYS_AGO = <integer>
* 抽出した⽇付が有効になる、現在の⽇付から過去
への最⼤⽇数を指定します。
2000 ⽇
注意： 2000 ⽇より古
いデータがある場合
は、この値を増やして
ください。
たとえば、MAX_DAYS_AGO = 10 の場合、現在の
⽇付から 10 ⽇を超えて古い⽇付は無視され
ます。
設定可能な過去最⼤⽇数は、10951 です。
MAX_DAYS_HENCE = <integer>
* 抽出した⽇付が有効になる、現在の⽇付から将来
への最⼤⽇数を指定します。
2⽇
たとえば、MAX_DAYS_HENCE = 3 の場合、3 ⽇を
超えて将来の⽇付は無視されます。
重要： ウィンドウを限定すると、誤判定の可
能性が低くなります。変更する際には細⼼の
注意を払ってください。
サーバーに誤った⽇付セットがある場合、ま
たはサーバーが 1 ⽇先のタイムゾーンに存在
している場合は、3 以上の値を設定してくだ
さい。
この場合、1 ⽇先までのタイムスタンプ抽出
を⾏えます。
設定可能な最⼤⽇数は、10950 です。
MAX_DIFF_SECS_AGO =
<integer>
イベントのタイムスタンプが 1 つ前のタイムスタ
ンプよりも <integer> 秒を超えて前 の場合、ソース
からのタイムスタンプの⼤半と時間フォーマット
が同じ場合にのみそれを受け付けます。
3600 秒 (1 時間)
重要： タイムスタンプの順序が乱雑な場合
は、この値を増やすことを検討してくださ
い。
設定可能な最⼤秒数は、2147483646 で
す。
MAX_DIFF_SECS_HENCE =
<integer>
イベントのタイムスタンプが 1 つ前のタイムスタ
ンプよりも <integer> 秒を超えて後 の場合、ソース
からのタイムスタンプの⼤半と時間フォーマット
が同じ場合にのみそれを受け付けます。
604800 秒 (1 週間)
重要： タイムスタンプの順序が乱雑な場合、
または週に 1 回未満しか書き込まれないログ
がある場合は、この値を増やすことを検討し
てください。
設定可能な最⼤秒数は、2147483646 で
す。
拡張 strptime() サポート
タイムスタンプのパーシングを設定するには、props.conf で TIME_FORMAT 属性を使⽤します。この属性
は、strptime() フォーマット⽂字列を取ります。この⽂字列は、タイムスタンプの抽出に⽤いられます。
Splunk Enterprise は拡張版の UNIX strptime() を実装しており、マイクロ秒、ミリ秒、任意の時間幅フォー
マット、および互換性を保つための他の時間フォーマットの利⽤を可能にする、追加の時間フォーマットがサポー
トされています。次のような追加のフォーマットがあります：
%N
%Q,%q
GNU ⽇付-時刻ナノ秒⽤。width: %3N = ミリ秒、 %6N = マイクロ秒、 %9N = ナノ秒を
指定して、1 秒未満の任意のパーシングを指定します。
ミリ秒⽤、Apache Tomcat の場合はマイクロ秒⽤。 width を指定した場合、%Q およ
び %q で、任意の時間分解能をフォーマットできます。
111
%I
12 時間形式の時間⽤。%I が %S または %s の後にある場合 (「%H:%M:%S.%l」など)、
log4cpp の観点からのミリ秒として解釈されます。
%+
標準 UNIX ⽇付形式タイムスタンプ⽤。
%v
BSD および OSX 標準⽇付フォーマット⽤。
%Z, %z, %::z, %:::z GNU libc サポート。
%o
AIX タイムスタンプサポート⽤ (%o は、 %Y のエイリアスとして使⽤されます)。
%p
ロケールの AM または PM との同等。(注意：存在しない場合もあります。)
%s
エポック (10 桁)
注意： リテラルドットと %Q、%q、%N などの 1 秒未満の指定⼦で終わる strptime 式は、終点のドットと変換
指定⼦をオプションとして取り扱います。テキストに .subseconds 部が存在しない場合でも、抽出は⾏われま
す。
strptime() フォーマット式の例
strptime()
式で処理するサンプルの⽇付形式を以下に⽰します。
1998/12/31
%Y-%m-%d
98-12-31
%y-%m-%d
1998 years, 312 days
%Y years, %j days
Jan 24, 2003
%b %d, %Y
January 24, 2003
%B %d, %Y
1397477611.862
%s.%3N
注意： 現在 Splunk Enterprise は、タイムスタンプ内の英語以外の⽉名を認識しません。ログファイルに英語以
外の⽉名を書き込む App がある場合、可能な場合は数値の⽉を使⽤するように App を再設定してください。
例
データには、以下のような簡単に認識できるタイムスタンプが含まれていることがあります。
...FOR:
04/24/07 PAGE 01...
このようなタイムスタンプを抽出するには、props.conf に以下のスタンザを追加します。
[host::foo]
TIME_PREFIX = FOR:
TIME_FORMAT = %m/%d/%y
データには、Splunk Enterprise がタイムスタンプとしてパーシングしてしまうような情報が含まれていることも
あります。以下に例を⽰します。
...1989/12/31
16:00:00 ed May 23 15:40:21 2007...
Splunk Enterprise は⽇付を Dec 31, 1989 (1989 年 12 ⽉ 31 ⽇) として抽出しますが、この情報は役に⽴ちま
せん。この場合、host::foo のイベントから正しいタイムスタンプを抽出するように、props.conf を設定してくださ
い。
[host::foo]
TIME_PREFIX = \d{4}/\d{2}/\d{2} \d{2}:\d{2}:\d{2} \w+\s
TIME_FORMAT = %b %d %H:%M:%S %Y
この設定は、host::foo からのすべてのタイムスタンプが、同じフォーマットであることを前提にしています。潜
在的なタイムスタンプ設定エラーを防⽌するために、props.conf のスタンザは、できる限りきめ細かく設定してく
ださい。
複数のタイムスタンプを持つイベントから正しいタイムスタンプを抽出する⽅法の詳細は、「複数のタイムスタン
プを持つイベントのタイムスタンプ割り当ての設定」を参照してください。
特定のニーズに合わせたタイムスタンプの設定
このトピックで説明している属性を使って、以下のような特定の⽬的に合わせてタイムスタンプ抽出プロセッサを
設定することができます。
タイムゾーンオフセットを適⽤する。
複数のタイムスタンプを使ってイベントから正確なタイムスタンプを取得する。
インデックス作成パフォーマンスを向上する。
112
サーチ結果へのタイムスタンプの表⽰⽅法の設定
ブラウザのロケール設定を使って、ブラウザによるサーチ結果内のタイムスタンプの、フォーマット⽅法を設定す
ることができます。ブラウザのロケールの設定については、「ユーザーの⾔語とロケール」を参照してください。
raw データ内のタイムスタンプの表⽰⽅法の再設定
Splunk Enterprise はブラウザのロケールを使ってサーチ結果内のタイムスタンプの表⽰⽅法を設定しています。
raw データのフォーマットは引き続き元の形式で保持されています。raw データとサーチ結果の両⽅のデータ
フォーマットを標準化するために、これを変更することができます。そのためには、props.conf および
transforms.conf を使⽤します。以下に例を⽰します。
raw イベント内のタイムスタンプデータが、以下のようになっていると仮定してみましょう。
06/07/2011 10:26:11 PM
このデータを、以下のようにしたいと考えています (サーチ結果の表⽰⽅法と合わせるために)。
07/06/2011 10:26:11 PM
この例では、props.conf および
しています。
transforms.conf
transforms.conf
を使った、raw イベント内のタイムスタンプの変換⽅法の概要を表
に以下のスタンザを追加します。
[resortdate]
REGEX = ^(\d{2})\/(\d{2})\/(\d{4})\s([^/]+)
FORMAT = $2/$1/$3 $4
DEST_KEY = _raw
props.conf
に以下のスタンザを追加します。ここで、<spec> がデータを修飾します。
[<spec>]
TRANSFORMS-sortdate = resortdate
Answers
何か質問がありますか？「Splunk Answers」では、Splunk コミュニティに寄せられた、タイムスタンプの認識
と設定に関する質問と回答をご覧いただけます。
複数のタイムスタンプを持つイベントのタイムスタンプ割り当ての設
定
イベントに複数のタイムスタンプが含まれている場合、Splunk Enterprise が使⽤するタイムスタンプを指定する
ことができます。これは、特に syslog のホストチェーンデータが含まれているイベントのインデックスを作成す
る場合に役⽴ちます。
props.conf を編修して、位置的タイムスタンプ抽出を設定します。props.conf のタイムスタンプ編集については、
「タイムスタンプ認識の設定」を参照してください。
位置的タイムスタンプ抽出の設定
イベント内の任意の場所にあるタイムスタンプを認識するように Splunk Enterprise を設定するには、props.conf
のスタンザに TIME_PREFIX および MAX_TIMESTAMP_LOOKAHEAD 属性を追加します。TIME_PREFIX に正規表現を設定するこ
とで、タイムスタンプ検索の開始場所を⽰す⽂字パターンを Splunk Enterprise に指⽰することができま
す。MAX_TIMESTAMP_LOOKAHEAD の値を設定して、Splunk Enterprise にどの程度先までイベントのタイムスタンプを
探すのか (TIME_PREFIX の) を指⽰する値を設定します。先読みを制限することで、正確性とパフォーマンスの
両⽅を改善することができます。
を設定した場合、タイムスタンプの抽出を試みる前に、その正規表現に⼀致するイベントのテキスト
が検索されます。Splunk Enterprise のタイムスタンプアルゴリズムは、最初に正規表現に⼀致した項⽬に続くテ
キスト内のタイムスタンプのみに注⽬します。そのため、TIME_PREFIX に abc123 を設定すると、最初に登場した
abc123 に続くテキストのみが、タイムスタンプ抽出に利⽤されます。
TIME_PREFIX
は、MAX_TIMESTAMP_LOOKAHEAD の開始点も設定します。先読みは TIME_PREFIX 正規表現内の、⼀致するテキ
スト項⽬の後から開始されます。たとえば、TIME_PREFIX がイベントの最初の 11 ⽂字からのテキストと⼀致して、
抽出するタイムスタンプが常に次の 30 ⽂字内に存在する場合、MAX_TIMESTAMP_LOOKAHEAD=30 を設定することができ
ます。タイムスタンプ抽出は、12 ⽂字⽬から始まり、41 ⽂字⽬で終了するテキストに限定されます。
TIME_PREFIX
例
以下のようなイベントがある場合を考えてみましょう。
113
1989/12/31 16:00:00 Wed May 23 15:40:21 2007 ERROR UserManager - Exception thrown
Ignoring unsupported search for eventtype: /doc sourcetype="access_combined"
NOT eventtypetag=bot
タイムスタンプを時間情報
を設定します。
May 23 15:40:21 2007
の 2 番⽬の⽂字列として識別するには、以下のように
props.conf
[source::/Applications/splunk/var/spool/splunk]
TIME_PREFIX = \d{4}/\d{2}/\d{2} \d{2}:\d{2}:\d{2} \w+\s
MAX_TIMESTAMP_LOOKAHEAD = 21
この設定は、最初のタイムスタンプ構造に⼀致するイベントを検索しますが、それは無視してそれに続く 21 ⽂字
(MAX_TIMESTAMP_LOOKAHEAD 属性から取得された値) 内にあるタイムスタンプに注⽬します。2 番⽬のタイムスタンプ
は、常にその 21 ⽂字の範囲内に存在するため、それが発⾒されます。
注意： タイムスタンプ抽出速度を最適化するには、MAX_TIMESTAMP_LOOKAHEAD の値を変更して、イベント内の⽬的の
タイムスタンプを発⾒するために必要な部分のみを検索するように調整します。この例で、MAX_TIMESTAMP_LOOKAHEAD
はイベントの正規表現値から 21 ⽂字のみを検索するように最適化されています。
タイムスタンプのタイムゾーンの指定
異なるタイムゾーンからのデータのインデックスを作成する場合、タイムゾーンオフセットを使って、サーチ時に
正しく相関されるように調整することができます。タイムゾーンは、イベントのホスト、ソース、またはソースタ
イプに基づいて設定することができます。
props.conf へのタイムゾーンの設定props.conf のタイムスタンプ編集については、「タイムスタンプ認識の設定」
を参照してください。
Splunk がタイムゾーンを適⽤する仕組み
デフォルトで、Splunk Enterprise は以下の順序でこれらのルールを使ってタイムゾーンを適⽤します。
1. Splunk Enterprise は raw イベントデータに指定されている任意のタイムゾーンを使⽤します (例：PST, 0800)。
2. イベントがスタンザに指定されているホスト、ソース、またはソースタイプに⼀致する場合、props.conf に設定
されている TZ 属性の値を使⽤します。
3. インデクサーに到着したイベントの起源がフォワーダーで、フォワーダーと受信側インデクサーの両⽅で
Splunk Enterprise 6.0 以降が動作している場合は、フォワーダーのタイムゾーンが使⽤されます。
4. それ以外の場合は、イベントのインデックスを作成するサーバーのタイムゾーンが使⽤されます。
注意： Splunk Enterprise が動作しているシステムのタイムゾーン設定を変更した場合、変更内容を反映するに
は Splunk Enterprise を再起動する必要があります。
props.conf へのタイムゾーンの指定
タイムゾーンを設定するには、$SPLUNK_HOME/etc/system/local/ 内、または $SPLUNK_HOME/etc/apps/ の独⾃のカスタム
App ディレクトリ内の、props.conf を編集します。設定ファイルの⼀般情報については、『管理マニュアル』の
「設定ファイルについて」を参照してください。
タイムゾーンを設定するには、props.conf 内の適切なスタンザに TZ 属性を追加します。Splunk TZ 属性は、
zoneinfo TZ ID を認識します。(zoneinfo (TZ) データベース内のすべてのタイムゾーン TZ ID を参照)ホスト、
ソース、またはソースタイプのスタンザ内で、TZ 属性に⽬的のタイムゾーンの TZ ID を設定します。これは、そ
のホスト、ソース、またはソースタイプからのイベントのタイムゾーンでなければなりません。
インデクサーのタイムゾーンは Splunk Enterprise で設定されているのではなく、オペレーティングシステムの
タイムゾーンが使われていることに注意してください。インデクサーのホストシステムで時刻が正しく設定されて
いる限り、イベントのタイムゾーンのオフセットは正しく算出されます。
例
このインデクサーには、New York City (タイムゾーンは⽶国東部標準時 (US/Eastern)) および Mountain View,
California (太平洋標準時 (US/Pacific)) からのイベントが到着します。これらの 2 種類のイベントセットのタイ
ムスタンプを正しく処理するには、インデクサーの props.conf に、⽶国東部標準時と⽶国太平洋標準時の両⽅のタ
イムゾーンを指定する必要があります。
最初の例では、名前が正規表現
標準時に設定します。
nyc.*
と⼀致するホストから到着する、任意のイベントのタイムゾーンを⽶国東部
[host::nyc*]
TZ = US/Eastern
2 番⽬の例では、バス
/mnt/ca/...
内のソースから到着する、任意のイベントのタイムゾーンを⽶国太平洋標準時
114
に設定します。
[source::/mnt/ca/...]
TZ = US/Pacific
zoneinfo (TZ) データベース
zoneinfo データベースは、公的に管理されているタイムゾーン値のデータベースです。
UNIX 版の Splunk は、ご利⽤の UNIXディストリビューションに含まれている TZ データベースを使⽤し
ています。UNIX ディストリビューションの⼤半は、次のディレクトリ内にデータベースを保管していま
す：/usr/share/zoneinfo。
Solaris 版の Splunk は、TZ 情報を次のディレクトリに保管しています：/usr/share/lib/zoneinfo。
Windows 版の Splunk には、TZ データベースのコピーが同梱されています。
可能な
TZ
値については、zoneinfo (TZ) データベースを参照してください。
イベントデータから抽出されたタイムゾーン⽂字列のマップ
イベントデータ内に登場するタイムゾーンの省略形の解釈⽅法を変更するには、props.conf で TZ_ALIAS 属性を使⽤
します。たとえば、「EST」はデフォルトで⽶国東部標準時を表していますが、イベントデータによってはそれが
豪州東部標準時を表していることもあります。「EST」を後者の意味に変更するには、以下のように属性を設定し
ます。
TZ_ALIAS = EST=GMT+10:00
次に Splunk がイベントデータ内に「EST」を発⾒した場合、それはデフォルトの「GMT- 5:00」ではなく、
「GMT+10:00」として解釈されます。
この例のように、タイムゾーン⽂字列を「既存の⽂字列 + オフセット値」にマップすることができます。また、1
つの TZ ⽂字列を他の⽂字列に直接マップすることもできます。
タイムゾーン⽂字列のマッピング時には、夏時間と冬時間の両⽅のタイムゾーンを処理するようにしてください。
たとえば、EST をマッピングする場合は、EDT もマップします。ご利⽤の地域で⽤いられている組み合わせに応
じて、適切なマップを⾏ってください。ソフトウェアをテストして、⽣成されるタイムゾーン⽂字列を確認してく
ださい。
複数のマッピングを指定することができます。TZ_ALIAS の構⽂を以下に⽰します。
TZ_ALIAS = <key=value>[,<key=value>]...
詳細と例については、「設定ファイルリファレンス」の props.conf ファイルの仕様と例を参照してください。
ユーザーのサーチ結果のタイムゾーン設定
Splunk ビルトイン認証を使ってユーザーを追加、編集する場合、ユーザーのタイムゾーンを設定することができ
ます。そのユーザーのサーチ結果は、設定したタイムゾーンで表⽰されます。ただし、この設定によりインデック
ス時に決定された、実際のイベントデータのタイムゾーンが変更されることはありません。この値の設定について
は、『Splunk のセキュリティ』マニュアルの「Splunk Web を使ったユーザーの設定」を参照してください。
インデックス作成パフォーマンス向上のためのタイムスタンプ認識の
調整
インデックス作成を⾼速化するために、Splunk Enterprise のタイムスタンププロセッサがイベントを調査する度
合いを調整したり、タイムスタンププロセッサをオフにすることができます。そのためには、props.conf を編集
します。
props.conf
のタイムスタンプ編集については、「タイムスタンプ認識の設定」を参照してください。
タイムスタンプ先読みの調整
タイムスタンプ先読みは、イベントを調査する度合い (何⽂字先まで) を決定します。この設定に
は、MAX_TIMESTAMP_LOOKAHEAD 属性を使⽤します。
タイムスタンププロセッサがイベント内を調査するデフォルトの⽂字数は 150 ⽂字です。MAX_TIMESTAMP_LOOKAHEAD
の値を減らすと、インデックス作成速度を向上することができます。特にタイムスタンプが常にイベントの最初の
部分に登場する場合は、この値を調整してください。
例：
この例では、ソース
foo
から到着するイベントの最初の 20 ⽂字のみ、タイムスタンプを探します。
[source::foo]
MAX_TIMESTAMP_LOOKAHEAD = 20
115
...
タイムスタンププロセッサを無効にする
インデックス作成パフォーマンスを改善するために、タイムスタンププロセッサを無効にすることができます。特
定のホスト、ソース、またはソースタイプに⼀致するイベントのタイムスタンプ処理をオフにするに
は、DATETIME_CONFIG 属性に NONE を設定します。DATETIME_CONFIG=NONE の場合、Splunk Enterprise はイベントのテ
キストからタイムスタンプを探しません。代わりに「イベントの受信時刻」、つまり⼊⼒からイベントを受け取っ
た時の時刻が使⽤されます。ファイルベースの⼊⼒ (モニターなど) の場合、タイムスタンプは⼊⼒ファイルの変
更時刻から取得されます。
また、DATETIME_CONFIG に CURRENT を設定して、インデックス作成のパフォーマンスを向上することもできます。こ
の場合、インデックス時に現在のシステム時刻が、各イベントに割り当てられます。
例：
この例は、ソース
foo
からのイベントのタイムスタンプ抽出をオフにします。
[source::foo]
DATETIME_CONFIG = NONE
...
注意： CURRENT と NONE の両⽅が、明⽰的にタイムスタンプの識別を無効にします。そのため、デフォルトのイベン
ト境界検出 (BREAK_ONLY_BEFORE_DATE = true) は、⽬的通りには機能しません。これらの設定を使⽤する場合
は、SHOULD_LINEMERGE や BREAK_ONLY_* , MUST_BREAK_* 設定を使ってイベントの結合を管理します。
インデックス作成フィールド抽出の設定
インデックス作成フィールドの抽出について
Splunk Enterprise がデータのインデックスを作成する場合、データストリームをパーシングして⼀連のイベン
ト を作成します。このプロセスの⼀環として、イベントデータ にさまざまなフィールド が追加されます。これら
のフィールドには、⾃動的に追加されるデフォルトフィールド や、⾃分が指定したカスタムフィールド が含ま
れます。
イベントへのフィールドの追加プロセスは、フィールドの抽出 と呼ばれています。2 種類のフィールド抽出が存
在しています。
インデックス作成フィールドの抽出 ：このトピックの始めに簡単に説明しましたが、これがこの章で説明
する主な項⽬になります。これらのフィールドはインデックス内に保管され、フィールドはイベントデータ
の⼀部となります。
サーチ時フィールドの抽出 ：データのサーチ時に処理が⾏われます。それらのフィールドはその場で作成
されますが、インデックス内には保管されません。この種類のフィールド抽出については、『ナレッジ管
理』マニュアルの「フィールドについて」を参照してください。
2 種類のインデックスされたフィールドが存在しています。
デフォルトフィールド ：Splunk が各イベントに⾃動的に追加します。この章の「デフォルトフィールドに
ついて」を参照してください。
カスタムフィールド ：⾃分が指定したフィールドです。このマニュアルの「インデックス時のカスタム・
フィールドの作成」を参照してください。
注意： フィールドに関する作業を⾏う場合、⼤部分のマシンデータは構造を持たないか、または常に変化する構
造を持っていることを考慮するようにしてください。このような種類のデータには、柔軟性の観点からサーチ時
フィールド抽出を使⽤することをお勧めします。サーチ時フィールド抽出の設定後、その変更は簡単に⾏えます。
より固定された構造のデータや、すでにファイル内のデータやイベントに構造がすでに定義されているデータもあ
ります。Splunk Enterprise には、このような種類のファイルの構造を読み込むためのオプションが⽤意されてお
り (カンマ区切りファイル (CSV)、タブ区切りファイル (TSV)、パイプ区切りファイル、JSON データ・ソースな
ど)、インデックス時にフィールドのマッピングが⾏われます。仕組みについては、このマニュアルの「ヘッダー
のあるファイルからのデータ抽出」を参照してください。
デフォルトフィールドについて (host、source、sourcetype など)
データのインデックス作成時には、各イベントにさまざまなフィールドが追加されます。これらのフィールドは、
インデックスのイベントデータ の⼀部となります。Splunk が⾃動的に追加するフィールドは、デフォルト
フィールド と呼ばれます。
デフォルトのフィールドは、さまざまな⽬的に利⽤されます。たとえば、デフォルトフィールド index はイベント
が存在しているインデックスを⽰します。デフォルトフィールド linecount はイベントに含まれる⾏数
を、timestamp はイベントの発⽣時刻を⽰します。Splunk はデータのインデックス作成時に、⼀部のフィールドの
値、特に sourcetype の値を利⽤して、正しくイベントを作成します。データのインデックスが作成されたら、サー
チにデフォルトフィールドを使⽤できます。
すべてのデフォルトフィールドの⼀覧を以下に⽰します。
116
フィー
ルドの
タイプ
内部
フィー
ルド
基本的
なデ
フォル
ト
フィー
ルド
フィールドの
リスト
_raw, _time,
_indextime, _cd
これらのフィールドには、Splunk が内部処理の⽬的で使⽤する情報が含まれていま
す。
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_* フィールドがある場合、それはイベ
ント⾃体からの直接の時間/⽇付値を表しています。インデックス時/⼊⼒時にタイム
ゾーン変換や時間/⽇付値の変更を⾏った場合 (例：タイムスタンプがインデックス
時または⼊⼒時になるように設定した)、これらのフィールドはそれを表さないよう
になります。
サーチの観点からのデフォルトフィールドについての情報は、『ナレッジ管理』マニュアルの「デフォルトフィー
ルドの使⽤」を参照してください。
注意： インデックスに追加する、独⾃のカスタムフィールドを指定することもできます。この章の「インデック
ス時のカスタムフィールドの作成」を参照してください。
このトピックは、3 つの主要デフォルトフィールドを取り上げていきます。
host
source
sourcetype
host、source、および sourcetype の定義
host、source、および sourcetype フィールドは以下のように定義されます。
host - イベントの host の値は、⼀般的にはイベントの発⽣元となるホスト名、IP アドレス、またはネット
ワークホストの完全修飾ドメイン名になります。host 値を利⽤すれば、特定のデバイスから収集されたデー
タを⼿軽に特定することができます。ホストの詳細は、「ホストについて」を参照してください。
source - イベントの source は、イベントの起源となるファイル、ストリーム、または他の⼊⼒の名前で
す。ファイルやディレクトリからモニターされるデータの場合、source の値は
/archive/server1/var/log/messages.0 や /var/log/ などのフルパスになります。ネットワークベースのデータ
ソースの場合、source は「UDP:514」のようなプロトコルとポートになります。
sourcetype - イベントの sourcetype は、access_combined や cisco_syslog などの、データ⽣成元のデータ⼊
⼒の形式です。sourcetype は、Splunk によるデータのフォーマット⽅法を決定します。ソースタイプの詳
細は、「ソースタイプが重要な理由」を参照してください。
ソースとソースタイプ
ソースとソースタイプを混同しないようにしてください。どちらもデフォルトフィールドですが、それ以外はまっ
たく違います。
ソース (source) は、イベントが由来するファイル、ストリーム、または他の⼊⼒名です。
ソースタイプ (sourcetype) は、イベントのフォーマットを⽰します。Splunk はこのフィールドを使っ
て、受信したデータストリームを個別のイベントにフォーマットする⽅法を決定します。
同じソースタイプを持つイベントが、異なるソースから来ることもあります。 たとえ
ば、source=/var/log/messages をモニターしており、また udp:514 から syslog⼊⼒を直接受信している場合を考えて
みましょう。sourcetype=linux_syslog をサーチした場合、それらの両⽅のソースからのイベントが返されます。
ホストおよびソースタイプの割り当てに優先する設定を⾏う状況
ほとんどの場合、Splunk は正確かつ有益なソースとソースタイプの値を、⾃動認識することができます。ただし
状況によっては、この処理に介⼊して優先する値を設定しなければならないこともあります。
ホスト割り当てに優先する設定
以下のような場合に、デフォルトの
host
割り当てを変更することができます。
当初は別のホストで⽣成されたアーカイブデータを⼀括ロードしており、それらのイベントにそのホスト値
を設定したい場合。
データが別のホストから転送されている場合。(特に指定のない限り、フォワーダーがホストになります。)
どこで⽣成されたログでも、そのログデータを受信したサーバーがホストになるような、集中ログサーバー
環境で作業を⾏っている場合。
117
ホストの詳細は、「ホスト値の設定」を参照してください。
ソースタイプ割り当てに優先する設定
以下のような場合に、デフォルトの
sourcetype
割り当てを変更することができます。
Splunk がデータを適切に⾃動フォーマットできず、誤ったタイムスタンプ設定やイベントの⾏分割が⾏わ
れるなどの問題が発⽣する場合。
離散グループのホストに由来するイベント、または特定の IP アドレスやユーザー ID に関連するイベントな
ど、特定の⼊⼒から受信した特定のイベントにソースタイプを適⽤したい場合。
Splunk が⾃動的に認識できるソースタイプを拡張することも、または単にソースタイプの名前を変更することも
可能です。
ソースタイプの詳細は、「ソースタイプの設定」を参照してください。
デフォルトフィールドの動的割り当て
Splunk への取り込み時に、ファイルにデフォルトフィールド (メタデータ) を動的に割り当てることができます。
この機能を利⽤して、受信データにソースタイプ、ホスト、またはソースを動的に指定できます。この機能は主
に、スクリプト⼊⼒ やスクリプトが処理した既存のファイルからのデータを処理する場合に役⽴ちます。
重要： 継続的なファイルモニタリング (tail) ⼊⼒に動的メタデータ割り当てを使⽤することはお勧めできません。
ファイル⼊⼒の詳細は、このマニュアルの「ファイルとディレクトリのモニター」を参照してください。
注意 ：モジュール⼊⼒機能は、この ***SPLUNK*** ヘッダー機能よりも⼤幅に優れています。host、source、およ
び sourcetype tの動的に⽣成された値を Splunk に提⽰する必要がある場合は、モジュール⼊⼒の作成を検討し
てください。
この機能を使⽤するには、ファイルに単⼀の動的⼊⼒ヘッダーを追加して、値を割り当てるメタデータフィールド
を指定します。利⽤可能なメタデータフィールドは、sourcetype、host、および source です。
inputs.conf、props.conf、および transforms.conf を編集する代わりに、この⽅法を使ってメタデータを割り当
てることができます。
単⼀の⼊⼒ファイルの設定
既存の⼊⼒ファイルに対してこの機能を使⽤するには、ファイルを編集して単⼀の⼊⼒ヘッダーを追加します (⼿
動またはスクリプトを使って)。
***SPLUNK*** <metadata field>=<string> <metadata field>=<string> ...
には、有効なメタデータ/値のペアを設定します。複数のペアを指定することがで
きます。例：sourcetype=log4j host=swan。
単⼀のヘッダーをファイル内の任意の場所に追加します。EOF に達するまで、ヘッダーに続く任意のデータ
が、割り当てた属性と値に追加されます。
ファイルを $SPLUNK_HOME/var/spool/splunk または Splunk がモニターしている他のディレクトリに追加しま
す。
<metadata field>=<string>
スクリプトによる設定
スクリプトを作成して、受信するデータストリームに動的に⼊⼒ヘッダーを追加することができます。また、⼊⼒
ファイルの内容に基づいて、動的にヘッダーを設定することもできます。
インデックス時のカスタムフィールドの作成
警告： Splunk がインデックス時 に⾃動的に抽出してインデックスを作成する⼀連のデフォルトフィールド
(timestamp、punct、host、source、sourcetype など)に、カスタムフィールドを追加することはお勧め できません 。
このフィールドリストに追加すると、インデックス作成された各フィールドがサーチ可能インデックスのサイズを
増やすため、インデックス作成のパフォーマンスとサーチ時間に悪影響を与える可能性があります。インデックス
作成フィールドは柔軟性にも⽋けています。⼀連のフィールドを変更すると、データセット全体のインデックスを
再作成する必要があります。詳細は、『インデクサーとクラスタの管理』マニュアルの「インデックス時とサーチ
時」を参照してください。
これらの注意事項や問題があっても、カスタムフィールドを追加しなければならないことがあります。たとえば、
特定のサーチ時フィールド抽出が、サーチのパフォーマンスに⼤きな影響を与えるような環境が挙げられます。た
とえば、頻繁に⼤きなイベントセットに対してfoo!=bar や NOT foo=bar などの式でサーチを実⾏し、foo フィールド
がほぼ常に値 bar を取る場合がこれにあたります。
反対に、サーチ時抽出フィールドの値が、ほぼフィールド外に存在している場合に、インデックス作成フィールド
を追加したいこともあります。たとえば、foo=1 のみをサーチするような場合に、foo=1 を持たない多くのイベント
内に 1 が存在している場合、インデックス時に抽出されるフィールドのリストに foo を追加する⽅が効率的なこ
とがあります。
⼀般的には、サーチ時にカスタムフィールドを抽出するようにしてください。詳細は、『ナレッジ管理』マニュア
ルの「フィールドについて」を参照してください。
追加のインデックス作成フィールドの定義
118
追加のインデックス作成フィールドを定義するには、props.conf、transforms.conf、および fields.conf を編集し
ます。
内、または $SPLUNK_HOME/etc/apps/ の独⾃のカスタムアプリケーションディレクトリ
内にある、これらのファイルを編集します。設定ファイルの⼀般情報については、『管理マニュアル』の「設定
ファイルについて」を参照してください。
$SPLUNK_HOME/etc/system/local/
分散環境での設定変更の保管場所
分散サーチ デプロイ環境の場合、処理はサーチピア (インデクサー) とサーチヘッドに分けて⾏われます。変更内
容は、以下の⽅法でデプロイする必要があります。
props.conf
および transforms.conf の変更を、各サーチピアにデプロイします。
の変更をサーチヘッドにデプロイします。
fields.conf
注意： サーチピアへのデータ転送にヘビーフォワーダーを使⽤している場合、props および transforms の処理は
サーチピアではなくフォワーダー上で⾏われます。そのため、props と transforms に関する変更は、サーチピア
ではなくフォワーダーにデプロイする必要があります。
Splunk Enterprise 分散コンポーネントの詳細は、『分散デプロイ』マニュアルの「コンポーネントとロール」を
参照してください。
設定の保管場所については、『管理マニュアル』の「設定パラメータとデータパイプライン」を参照してくださ
い。
フィールド名構⽂の制限事項
Splunk では、フィールド名に英数字とアンダースコアのみを使⽤できます。
フィールド名に使⽤できる⽂字は、a-z、A-Z、0-9 、_ です。
フィールド名の先頭に、0-9 または _ を使⽤することはできません。先頭のアンダースコアは、Splunk の
内部変数⽤に予約されています。
国際⽂字は使⽤できません。
transforms.conf への新規フィールド⽤正規表現スタンザの追加
にインデックス時フィールド変換を定義する場合は、以下のフォーマットに従ってください (注
意：LOOKAHEAD や DEST_KEY など⼀部の属性は、特定の⽤途でのみ必要になります)：
transforms.conf
[<unique_transform_stanza_name>]
REGEX = <regular_expression>
FORMAT = <your_custom_field_name>::$1
WRITE_META = [true|false]
DEST_KEY = <KEY>
DEFAULT_VALUE = <string>
SOURCE_KEY = <KEY>
REPEAT_MATCH = [true|false]
LOOKAHEAD = <integer>
以下の事項に注意してください。
REGEX
のように、すべての変換に
REGEX
は、データからフィールドを抽出するための正規表現です。
REGEX の名前付きグループは、直接フィールドに抽出されます。単純なフィールド抽出の場合
は、FORMAT を指定する必要はありません。
REGEX でフィールド名と対応する値の両⽅を抽出する場合、以下の特殊グループを使って FORMAT 属性の
マッピング指定をスキップすることができます。
<unique_stanza_name>
が必要になります。
_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
119
す。
インデックス時変換の場合、$n を使って各 REGEX 照合の出⼒を指定します (例：$1、$2 など)。
REGEX に n グループがない場合、照合は失敗します。
FORMAT のデフォルトは <unique_transform_stanza_name>::$1 です。
特殊識別⼦ $0 は、REGEX 実⾏前に DEST_KEY 内に存在していた情報を表します (インデックス時フィール
ド抽出の場合 DEST_KEY は _meta です)。詳細は、後述する「Splunk によるインデックス作成フィール
ドの構築⽅法」を参照してください。
インデックス時フィールド抽出の場合、さまざまな⽅法で FORMAT を設定することができます。<fieldname>::<field-value> を使って以下のように設定することもできます。
FORMAT = field1::$1 field2::$2 (REGEX
は、捕捉グループ「field1」および「field2」のフィールド値を抽
出します。)
または：
FORMAT = $1::$2 (REGEX
は、フィールド名とフィールド値の両⽅を抽出します)
また、連結フィールドを作成するインデックス時フィールド抽出を設定することもできます。
FORMAT = ipaddress::$1.$2.$3.$4
を使って連結フィールドを作成する場合、$ が唯⼀の特殊⽂字であることを理解しておくことが重要
です。これは、その後に数字が続き、そしてその数字が既存の捕捉グループに適⽤される場合にのみ 、正規
表現捕捉グループのプリフィックスとして処理されます。
FORMAT
正規表現に捕捉グループが 1 つのみ存在し、その値が
bar
の場合：
で⽣成される値： foobar
で⽣成される値： foo$bar
foo$1234 で⽣成される値： foo$1234
foo$1\$2 で⽣成される値： foobar\$2
FORMAT = foo$1
FORMAT = foo$bar
FORMAT =
FORMAT =
は抽出されたフィールド名と値を、_meta (Splunk によるインデックス作成フィールドの保
管場所) に書き込みます。この属性は、DEST_KEY = _meta の場合を除いて、すべてのインデックス時フィール
ド抽出に設定する必要があります (後述する DEST_KEY の説明を参照)。
_meta に関する情報、およびそれがインデックス作成フィールドの作成時に果たす役割については、後
述する「Splunk によるインデックス作成フィールドの構築⽅法」を参照してください。
WRITE_META = true
が、インデックス時フィールド抽出には必要です (WRITE_META = false、または何も設定されていない
場合)。これは、REGEX の結果の保管場所を⽰します。
インデックス時サーチの場合は DEST_KEY = _meta (Splunk がインデックス作成フィールドを保管する場
所) です。その他の可能な KEY 値については、このマニュアルの transforms.conf に関するページを参照
してください。
_meta に関する情報、およびそれがインデックス作成フィールドの作成時に果たす役割については、後
述する「Splunk によるインデックス作成フィールドの構築⽅法」を参照してください。
DEST_KEY = _meta を使⽤する場合、FORMAT 属性の先頭に $0 を追加する必要があります。$0は、Splunk
がREGEX を実⾏する前の DEST_KEY 値を表しています (_meta)。
注意： $0 の値が、REGEX から得られることはありません。
DEST_KEY
DEFAULT_VALUE
は省略することができます。REGEX が失敗した場合、この属性の値は
DEST_KEY
に書き込まれま
す。
デフォルトは空です。
は省略することができます。これを使って、REGEX を適⽤する値の KEY を指定します。
デフォルトは SOURCE_KEY = _raw で、この場合すべてのイベントに丸ごと適⽤されます。
⼀般的には、REPEAT_MATCH とともに使⽤されます。
その他の可能な KEY 値については、このマニュアルの transforms.conf に関するページを参照してくだ
さい。
SOURCE_KEY
REPEAT_MATCH
は省略することができます。SOURCE_KEY に対して
REGEX
を複数回実⾏する場合は、true を設定し
ます。
は、前回照合が停⽌された場所から開始し、⼀致する項⽬が⾒つからなくなるまで処理を
続⾏します。イベントあたりに予測される、フィールド/値の⼀致項⽬数が不明な場合などに役⽴ちま
す。
デフォルトは false です。
REPEAT_MATCH
は省略することができます。イベント内のサーチ⽂字数を指定します。
デフォルトは 4096 です。⾏の⻑さが 4096 ⽂字を超えるイベントがある場合は、LOOKAHEAD の値を増
やすことができます。
特に照合する必要があるテキストがこの⽂字数よりも後にある場合は、この値を増やす必要がありま
す。
ただし、⼤きなテキストセグメントをスキャンする場合、複雑な正規表現のコストが⾮常に⾼くなる
可能性があることに注意してください。複数の最⻑マッチや先読み/前読みを使⽤する場合、速度が⼤
幅に低下する可能性があります。
LOOKAHEAD
注意： 正規表現の構⽂と使⽤⽅法の概要については、Regular-Expressions.info を参照してください。正規表現
をテストするには、サーチ内で rex サーチコマンドを使ってそれらを指定します。正規表現式を作成、テストする
ために役⽴つサードパーティ製ツールのリストも⽤意されています。
120
注意： 正規表現内の捕捉グループには、フィールド名構⽂の制限事項に従ってフィールド名を指定する必要があ
ります。ASCII ⽂字 (a〜z、A〜Z、0〜9 または _) のみを使⽤できます。国際⽂字は使⽤できません。
props.conf への新しいフィールドのリンク
props.conf
に、以下の⾏を追加します。
[<spec>]
TRANSFORMS-<class> = <unique_stanza_name>
以下の事項に注意してください。
には、以下の値を使⽤できます。
<sourcetype>、イベントのソースタイプ。
host::<host>、<host> はイベントのホストです。
source::<source>、<source> はイベントのソースです。
注意： <spec> の設定時には、正規表現型構⽂を使⽤できます。また、ソースおよびソースタイプスタ
ンザの照合では⼤⽂字と⼩⽂字が区別されますが、ホストスタンザでは区別されません。詳細
は、props.conf 仕様ファイルを参照してください。
<class> は、抽出するフィールド (キー) の名前空間を識別する⼀意のリテラル⽂字列です。注意： <class>の
値は、フィールド名構⽂の制限 (前述) に従う必要はありません。a-z、A-Z、および 0-9 以外の⽂字を使⽤
でき、またスペースも利⽤できます。
<unique_stanza_name> は、transforms.conf のスタンザ名です。
<spec>
注意： インデックス時フィールド抽出の場合、props.conf は TRANSFORMS-<class> を使⽤します。⼀⽅、EXTRACT<class> は、サーチ時フィールド抽出の設定に⽤いられます。
fields.conf への新規フィールド⽤エントリの追加
fields.conf
に新しいインデックス作成フィールド⽤のエントリを追加します。
[<your_custom_field_name>]
INDEXED=true
以下の事項に注意してください。
は、transforms.conf に追加する⼀意のスタンザ内に設定する、カスタムフィールド
の名前です。
フィールドのインデックスが作成されることを⽰すために、INDEXED=true を設定します。
<your_custom_field_name>
注意： サーチ時に同名のフィールドが抽出される場合は、フィールドに対して INDEXED=false を設定する必要があ
ります 。また、そのフィールドの、インデックス時には取得されないけれども、サーチ時には抽出される値を持
つイベントが存在する場合も、INDEXED_VALUE=false を設定する必要があります。
たとえば、インデックス時に単純な <field>::1234 抽出を⾏う場合を考えてみましょう。これは機能します
が、A(\d+)B のような正規表現に基づいてサーチ時フィールド抽出も⾏うような場合は、⽂字列 A1234B がその
フィールドの値 1234 を⽣み出すため、問題が発⽣してしまいます。これによりサーチ時に 1234 のイベントが登場
するため、Splunk は <field>::1234 抽出を使ってインデックス時を特定することができなくなってしまいます。
変更内容を反映するための Splunk の再起動
や transforms.conf などの設定ファイルの変更は、影響するすべてのコンポーネント上で Splunk を
シャットダウンして再起動しないと反映されません。
props.conf
Splunk によるインデックス作成フィールドの構築⽅法
Splunk は
す。
_meta
に書き込むことで、インデックス作成フィールドを構築しています。その詳細を以下に⽰しま
は、transforms.conf 内の、DEST_KEY = _meta または WRITE_META = true を含むすべての⼀致する変換によ
り変更されます。
⼀致する各変換は、_meta を上書きすることができます。_meta に追加する場合は、WRITE_META = true を使⽤
します。
WRITE_META を使⽤しない場合は、$0 で FORMAT を開始します。
パーシング中に _meta が完全に構築されたら、Splunk は以下の⽅法でテキストを変換します。
テキストはユニットに分割されます。各ユニットは空⽩⽂字で区切られます。
空⽩⽂字の有無に関係なく、引⽤符 (" ") で⽂字を⼤きなユニットにグループ化します。
引⽤符直前の円記号 (\) またはバックスラッシュは、引⽤符のグループ化特性を無効にします。
円記号の前に円記号があると、その円記号が無効になります。
2 つの連続するコロン (::) を含むテキストユニットは、抽出フィールドに変換されます。2 つの連続す
るコロンの左側がフィールド名、右側が値になります。
_meta
注意： ⼀般的に正規表現抽出値を持ち引⽤符を含むインデックス作成フィールドは機能せず、円記号がある場合
にも問題があります。サーチ時に抽出されるフィールドには、これらの制限はありません。
121
引⽤符と円記号を含んでおり、それらが無効になるような、⼀連のインデックス時抽出の例を以下に⽰します。
WRITE_META = true
FORMAT = field1::value field2::"value 2" field3::"a field with a \" quotation mark" field4::"a field which
ends with a backslash\\"
Splunk によるフィールド名の作成時
注意： Splunk がフィールド名を作成する場合、フィールド名構⽂の制限事項が適⽤されます。
1. a-z、A-Z、および 0-9 以外のすべての⽂字は、アンダースコア (_) に置換されます。
2. 先頭のアンダースコアはすべて削除されます。Splunk で先頭のアンダースコアは、内部フィールド ⽤に予約
されています。
インデックス時フィールド抽出の例
ここには、インデックス時フィールド抽出の、設定ファイルの設定例をいくつか記載しています。
新しいインデックス作成フィールドの定義
この基本的な例では、インデックス作成フィールド
err_code
を作成します。
tra nsform s.c onf
transforms.conf
に以下の項⽬を追加します。
[netscreen-error]
REGEX =
device_id=\[\w+\](?<err_code>[^:]+)
FORMAT = err_code::"$1"
WRITE_META = true
このスタンザは、device_id= に続けて⾓括弧に囲まれた単語、およびコロンで終了するテキスト⽂字列を取りま
す。イベントのソースタイプは testlog です。
コメント：
⾏には、以下の値が含まれています。
は、フィールド名です。
$1 は、インデックスに書き込まれる新しいフィールドを表しています。REGEX により抽出された値で
す。
WRITE_META = true は、FORMAT の内容をインデックスに書き込むことを表しています。
FORMAT =
err_code::
p rop s.c onf
props.conf
に以下の⾏を追加します。
[testlog]
TRANSFORMS-netscreen = netscreen-error
field s.c onf
fields.conf
に以下の⾏を追加します。
[err_code]
INDEXED=true
設定ファイルの変更内容を反映するために、Splunk を再起動します。
1 つの正規表現で 2 つの新規インデックス作成フィールドを定義
この例では、インデックス作成フィールド
username
および
login_result
tra nsform s.c onf
transforms.conf
に以下の項⽬を追加します。
[ftpd-login]
REGEX = Attempt to login by user: (.*): login (.*)\.
FORMAT = username::"$1" login_result::"$2"
122
を作成します。
WRITE_META = true
このスタンザは、リテラルテキスト Attempt to login by user: を探し、後ろにコロンが付いたユーザー名を抽出
し、次に後ろにピリオドが付いた結果を抽出します。⾏は以下のようになります。
2008-10-30 14:15:21 mightyhost awesomeftpd INFO Attempt to login by user: root: login FAILED.
p rop s.c onf
props.conf
に以下の⾏を追加します。
[ftpd-log]
TRANSFORMS-login = ftpd-login
field s.c onf
fields.conf
に以下の⾏を追加します。
[username]
INDEXED=true
[login_result]
INDEXED=true
設定ファイルの変更内容を反映するために、Splunk を再起動します。
インデックス時のイベントセグメントからのフィールド値の連結
この例は、インデックス時変換を使った、イベントの個別のセグメントの抽出、および
結合して、単⼀のフィールドを作成する⽅法を表しています。
FORMAT
を使ってそれらを
以下のイベントが存在する場合を考えてみましょう。
20100126 08:48:49 781 PACKET 078FCFD0 UDP Rcv 127.0.0.0 8226 R Q [0084 A NOERROR] A (4)www(8)google(3)com(0)
⽬的は、(4)www(8)google(3)com(0) を dns_requestor フィールドの値として抽出することです。ただし、それらの無
意味な括弧と数字は不要で、単純に www.google.com のみを抽出たいと考えています。そのためにはどうすれば良い
のでしょうか？
tra nsform s.c onf
まず、transforms.conf 内に変換
dnsRequest
を設定します。
[dnsRequest]
REGEX = UDP[^\(]+\(\d\)(\w+)\(\d\)(\w+)\(\d\)(\w+)
FORMAT = dns_requestor::$1.$2.$3
この変換は、dns_requestor という名前のカスタムフィールドを定義します。その REGEX を使って、値 dns_requestor
の 3 つのセグメントを抜き出します。次に FORMAT を使って、それらのセグメントの間にピリオドを付けながら並
べ、適切な URL のようにフォーマットします。
注意： このイベントセグメントを連結してフィールド値を作成する⽅法は、インデックス時抽出でのみ実⾏する
ことができます。サーチ時抽出では、実⽤上の制限から実⾏できません。この⽅法で FORMAT を使⽤する必要があ
る場合は、実⾏するために新しいインデックス作成フィールドを作成する必要があります。
p rop s.c onf
次に、dnsRequest 変換を参照し、それを
を、props.conf に定義します。
server1
ソースタイプから受け取るイベントに適⽤するフィールド抽出
[server1]
TRANSFORMS-dnsExtract = dnsRequest
field s.c onf
最後に、fields.conf に以下のスタンザを設定します。
[dns_requestor]
INDEXED = true
123
設定ファイルの変更内容を反映するために、Splunk を再起動します。
ヘッダーのあるファイルからのデータの抽出
カンマ区切り形式 (CSV) ファイルなどの構造化データの多くが、ファイルヘッダーに情報を保有しています。
Splunk Enterprise はその情報を使って、インデックス時イベント処理中にフィールドを抽出することができま
す。これらのフィールドを⾃動抽出するように、Splunk Enterprise を設定することができます。
たとえば、⼀般的に従来の CSV ファイルは、それ以降の⾏の値に対する列⾒出しを含む⾏から始まります。以下
に例を⽰します。
host,status,message,"start date"
srv1.splunk.com,error,"No space left on device",2013-06-10T06:35:00
srv2.splunk.com,ok,-,2013-06-11T06:00:00
設定ファイルを使ったヘッダーベースの⾃動フィールド抽出の有効化
ヘッダーがあるファイル (カンマ区切り形式ファイル、IIS Web サーバーログ、および他の構造化データファイル
など) からデータを抽出するには、inputs.conf と props.conf を組み合わせて使⽤しま
す。$SPLUNK_HOME/etc/system/local/ 内、または $SPLUNK_HOME/etc/apps/<app_name>/local の独⾃のカスタムアプリケー
ションディレクトリ内にある、これらのファイルを編集します。Inputs.conf には、モニターするファイル、およ
びモニターするために使⽤するソースタイプを指定します。props.conf には、ソースタイプ⾃体を定義します。
設定ファイルの⼀般情報については、『管理マニュアル』の「設定ファイルについて」を参照してください。
重要：props.conf に対して⾏った変更は (ヘッダーベースの⾃動フィールド抽出など)、Splunk Enterprise を再起
動しない限り反映されません。
構造化データ⽤の Props.conf 属性
props.conf には、ヘッダーを含むファイルを処理するために以下の属性が含まれています。他の props.conf 属性
については、props.conf 仕様ファイルを参照してください。
属性
説明
デフォルト
ファイルのタイプと抽出、またはファイルに対して使⽤するパーシン
グ⽅法を指定します。
N/A (設定さ
れない)
PREAMBLE_REGEX
ファイルによってはプリアンブル⾏が含まれていることもあります。
この属性には、指定パターンに基づいてそれらのプリアンブル⾏を無
視するための、正規表現を指定します。
N/A
FIELD_HEADER_REGEX
プリフィックスが付いたヘッダー⾏のパターンを⽰す正規表現。
Splunk Enterprise は、正規表現に⼀致する最初の⾏を探して、それ
をヘッダーフィールドとしてパーシングします。実際のヘッダーは⼀
致したパターンの後から始まり、それ⾃⾝はパーシングされたヘッ
ダーフィールドには含まれないことに注意してください。この属性に
は、特殊⽂字を指定することができます。
N/A
INDEXED_EXTRACTIONS =
{CSV|W3C|TSV|PSV|JSON}
FIELD_DELIMITER
モニター対象ファイルまたはソース内のフィールドを区切る/分割する
⽂字を⽰します。この属性には、特殊⽂字を指定することができま
N/A
す。
FIELD_QUOTE
指定ファイルまたはソース内の、引⽤に使⽤する⽂字を⽰します。こ
の属性には、特殊⽂字を指定することができます。
N/A
HEADER_FIELD_DELIMITER
ヘッダー⾏内のフィールド名を区切る⽂字を⽰します。この属性に
は、特殊⽂字を指定することができます。
HEADER_FIELD_DELIMITER が指定されていない場合、ヘッダー
⾏には FIELD_DELIMITER が適⽤されます。
N/A
HEADER_FIELD_QUOTE
ヘッダー⾏内のフィールド名を囲む⽂字を⽰します。この属性には、
特殊⽂字を指定することができます。HEADER_FIELD_QUOTE が指
定されていない場合、ヘッダー⾏には FIELD_QUOTE が適⽤されま N/A
す。
HEADER_FIELD_LINE_NUMBER
ヘッダーフィールドを含むファイル内の、⾏の⾏番号を⽰します。0
を設定すると、Splunk がファイル内のヘッダーフィールドを⾃動的
に検索します。
TIMESTAMP_FIELDS =
⼀部の CSV および構造化ファイルには、区切り⽂字で区切られた、
イベント内の複数のフィールドにまたがるタイムスタンプが存在して
いることもあります。この属性は、タイムスタンプを構成するそのよ
うなフィールドを、カンマ区切り形式で指定することを Splunk に指
⽰します。
field1,field2,...,fieldn
0
Splunk
Enterprise
は、イベン
トのタイム
スタンプの
⾃動抽出を
試みます。
FIELD_NAMES
⼀部の CSV および構造化ファイルには、ヘッダーが存在しないこと
があります。この属性は、ヘッダーフィールドを直接指定することを
Splunk に指⽰します。
N/A
MISSING_VALUE_REGEX
構造化データファイル内に指定された正規表現が⾒つかった場合、⾏
N/A
124
MISSING_VALUE_REGEX
内のフィールドの値は空とみなされます。
N/A
⼀部の属性では特殊⽂字または値を使⽤できる
⼀部の属性には、円記号 (\) またはバックスラッシュを使⽤することで、スペース、垂直タブ、⽔平タブ、フォー
ムフィードなどの特殊⽂字や値を指定することができます。
特殊値
Props.conf の表記
フォームフィード
\f
スペース
space
⽔平タブ
\t
垂直タブ
\v
空⽩⽂字
whitespace
なし
none
ファイル区切り⽂字
fs
または
\034
グループ区切り⽂字
gs
または
\035
レコード区切り⽂字
rs
または
\036
単位区切り⽂字
us
または
\037
または
または
' '
tab
または
\0
これらの特殊⽂字は、以下の属性に指定することができます。
FIELD_DELIMITER
FIELD_HEADER_REGEX
FIELD_QUOTE
設定ファイルの編集によるソースタイプの作成と参照
これらの属性を使⽤するには、props.conf を編集する必要があります。Splunk がヘッダーデータを持つファイル
から、フィールドを抽出するための⽅法を定義した新しいソースタイプを作成するには、props.conf を編集しま
す。
を編集したら、次に Splunk がインデックスを作成するファイル内に新たに作成されたソースタイプを
参照するように、inputs.conf を編集します。
props.conf
ヘッダーを持つファイル抽出⽤の新しいソースタイプを作成、参照するには：
1. テキストエディタを使って、適切な場所にある props.conf ファイルを開きます。前述の「設定ファイルを使った
ヘッダーベースの⾃動フィールド抽出の有効化」を参照してください。
注意： このファイルが存在しない場合は、作成する必要があります。
2. 前述の属性を使って、Splunk Enterprise にファイルヘッダーおよび構造化ファイルデータの抽出⽅法を指⽰す
るスタンザを作成することで、新しいソースタイプを定義します。例：
[HeaderFieldsWithFewEmptyFieldNamesWithSpaceDelim]
FIELD_DELIMITER=,
HEADER_FIELD_DELIMITER=\s
FIELD_QUOTE="
注意： 必要に応じて、任意の数のスタンザ (ソースタイプ) を定義することができます。
3. props.conf ファイルを保存して終了します。
4. inputs.conf ファイルが存在していない場合は、同じディレクトリにファイルを作成します。
5. 編集するためにファイルを開きます。
6. ファイルヘッダーおよび構造化データを抽出するファイルを表すスタンザを追加します。複数追加することもで
きます。例：
[monitor:///opt/test/data/StructuredData/HeaderFieldsWithFewEmptyFieldNamesWithSpaceDelim.csv]
sourcetype=HeaderFieldsWithFewEmptyFieldNamesWithSpaceDelim
注意： ヘッダーと構造化データを抽出するファイルやディレクトリのために、任意の数のスタンザを追加するこ
とができます。
7. inputs.conf ファイルを保存して終了します。
125
8. 変更内容を有効にするために、Splunk Enterprise を再起動します。
ヘッダーファイルから抽出したデータの転送
ヘッダーを持つファイルから抽出したフィールドを、他の Splunk Enterprise インスタンスに転送することもで
きます。
構造化データファイルから抽出したフィールドを転送するには、以下の⼿順に従ってください。
1. ファイルをモニターするインスタンス上で、このトピック前半の「設定ファイルの編集によるソースタイプの作
成と参照」の説明に従って props.conf および inputs.conf を編集します。
2. 次に、データを他の Splunk Enterprise インスタンスに転送するようにシステムを設定します。
注意： データの転送と受信のための設定⽅法については、『データの転送』マニュアルの「転送と受信の設定」
を参照してください。
3. データを受信するインスタンス上で、Splunk Enterprise をレシーバーとして設定します。
4. 受信側インスタンスの $SPLUNK_HOME/etc/system/local に
レクトリにファイルを作成します。
5. モニターする Splunk インスタンス上の
成した props.conf にコピーします。
props.conf
props.conf
ファイルが存在していない場合は、そのディ
から適切なスタンザを、受信側 Splunk インスタンス上に作
6. 受信側インスタンスで Splunk Enterprise を再起動します。
7. モニター側インスタンスで Splunk Enterprise を再起動します。
8. 受信側インスタンス上でサーチ App を使って、構造化データ・ファイルからフィールドが正しく抽出され、イ
ンデックスが作成されたことを確認します。
注意事項
⾏にデータが含まれているヘッダーフィールドのみインデックスが作成される
構造化データファイルからヘッダーフィールドを抽出する場合、最低 1 つの⾏にデータが存在しているフィール
ドのみが抽出されます。ヘッダーフィールドのどの⾏にもデータが含まれていない場合、そのフィールドはスキッ
プされ、インデックスは作成されません。たとえば、以下の CSV ファイルを考えてみましょう。
header1,header2,header3,header4,header5
one,1,won,,111
two,2,too,,222
three,3,thri,,333
four,4,fore,,444
five,5,faiv,,555
Splunk Enterprise がこのファイルを読み込むと、header4 列の⾏はすべて空のため、このヘッダーフィールドま
たはその⾏のインデックスを作成することはありません。このことは、インデックス内で header4 またはその⾏内
のデータをサーチできないことを意味しています。
ただし、header4 フィールドに空⽂字列 (例："") が存在する⾏が含まれている場合、そのフィールドおよびそのす
べての⾏のインデックスが作成されます。
Splunk Enterprise は中間ファイルのヘッダーフィールド名変更をサポートしていない
Internet Information Server などの⼀部のソフトウェアは、ファイル処理中のヘッダーフィールド名の変更をサ
ポートしています。Splunk はこのような変更を認識できません。ファイル内でヘッダーフィールドの名前が変更
されたファイルのインデックス作成を試みても、名前が変更されたヘッダーフィールドのインデックスは作成され
ません。
設定およびデータファイルの例
ファイルヘッダー抽出属性の使⽤⽅法を表す、inputs.conf と props.conf ファイルの例を以下に⽰します。
データをローカルに抽出するには、inputs.conf と props.conf を編集して、構造化データファイルの⼊⼒とソー
スタイプを定義し、次に前述の属性を使って Splunk Enterprise にファイルの処理⽅法を指⽰します。このデー
タを他の Splunk に転送するには、転送側インスタンスの inputs.conf と props.conf、および受信側インスタン
スの props.conf を編集します。
Inputs.conf
[monitor:///opt/test/data/StructuredData/CSVWithFewHeaderFieldsWithoutAnyValues.csv]
sourcetype=CSVWithFewHeaderFieldsWithoutAnyValues
[monitor:///opt/test/data/StructuredData/VeryLargeCSVFile.csv]
126
sourcetype=VeryLargeCSVFile
[monitor:///opt/test/data/StructuredData/UselessLongHeaderToBeIgnored.log]
sourcetype=UselessLongHeaderToBeIgnored
[monitor:///opt/test/data/StructuredData/HeaderFieldsWithFewEmptyFieldNamesWithSpaceDelim.csv]
sourcetype=HeaderFieldsWithFewEmptyFieldNamesWithSpaceDelim
[monitor:///opt/test/data/FieldHeaderRegex.log]
sourcetype=ExtractCorrectHeaders
Props.conf
[CSVWithFewHeaderFieldsWithoutAnyValues]
FIELD_DELIMITER=,
[VeryLargeCSVFile]
FIELD_DELIMITER=,
[UselessLongHeaderToBeIgnored]
HEADER_FIELD_LINE_NUMBER=35
TIMESTAMP_FIELDS=Date,Time,TimeZone
FIELD_DELIMITER=\s
FIELD_QUOTE="
[HeaderFieldsWithFewEmptyFieldNamesWithSpaceDelim]
FIELD_DELIMITER=,
HEADER_FIELD_DELIMITER=\s
FIELD_QUOTE="
[ExtractCorrectHeaders]
FIELD_HEADER_REGEX=Ignore_This_Stuff:\s(.*)
FIELD_DELIMITER=,
サンプルファイル
設定したファイルがどのようになるのかを理解するために、先ほど取り上げた inputs.conf および props.conf の
⼀部を抜粋した、サンプルファイルを以下に⽰します。
注意： 内容をすべて参照するために、右⽅向に少しスクロールしなければならないかもしれません。
CS VWith FewHea d erField sWith ou tAnyVa lu es.c sv
vqmcallhistoryid,serialnumber,vqmavgjbenvdelay,vqmavgjbenvnegdelta,vqmavgjbenvposdelta,vqmbitrate,vqmburstcount,vqmburstlengthavgms,vqmburstlen
99152,CFG0730084,-3,-2,356,64000,1,280,14,14.29,36,3499,201000,[email protected],2011-06-29
12:37:37.292,0,4.68,1.43,0.19,0,0,0,0,52,60,15,17,60,10,0,Loopback,0.48,48,46,0,30,1334,10,99.55,10008,9962,0,0,,,,,6096147095,2,100590,5029,0.
60,975,488,179,192,999.3,0,0,4.07,,4.12,,4.2,,4.03,,0.02,63,76,76,,,,43,0,6.8,0,520,10054,87,87,89,93,9,79,12,12,12,6096147089,10.255.43.12,100
0/1,2,0,54,80,80,18500,6096147089,48,1,0,2011-06-29 12:41:47.303,2011-06-29 12:41:47.303
99154,CFG0730084,-3,-1,251,64000,4,195,9,20.52,28,3494,359000,[email protected],2011-06-29
12:35:02.324,0,2.88,1.11,3.44,0,0,0,0,40,40,26,24,50,10,0,Loopback,0.31,54,46,0,31,2455,10,99.8,17769,17732,0,0,,,,,6096147095,5,71556,3577,0.6
62,993,496.5,126,139,3404.7,0,0,4.04,,4.07,,4.2,,3.94,,0.36,58,64,69,,,,49,0,286,0,529,17839,86,86,87,93,9,137,8,8,8,6096147089,10.255.43.12,10
0/1,2,0,48,60,70,30400,6096147089,54,1,0,2011-06-29 12:41:47.342,2011-06-29 12:41:47.342
VeryL a rgeCS VFile.c sv
IncidntNum,Category,Descript,DayOfWeek,Date,Time,PdDistrict,Resolution,Location,X,Y
030203898,FRAUD,"FORGERY, CREDIT CARD",Tuesday,02/18/2003,16:30,NORTHERN,NONE,2800 Block of VAN NESS AV,122.424612993055,37.8014488257836
000038261,WARRANTS,WARRANT ARREST,Thursday,04/17/2003,22:45,NORTHERN,"ARREST, BOOKED",POLK ST / SUTTER ST,122.420120319211,37.7877570602182
030203901,LARCENY/THEFT,GRAND THEFT PICKPOCKET,Tuesday,02/18/2003,16:05,NORTHERN,NONE,VAN NESS AV / MCALLISTER ST,122.42025048261,37.7800745746105
030203923,DRUG/NARCOTIC,SALE OF BASE/ROCK COCAINE,Tuesday,02/18/2003,17:00,BAYVIEW,"ARREST, BOOKED",1600 Block of
KIRKWOOD AV,-122.390718076188,37.7385560584619
030203923,OTHER OFFENSES,CONSPIRACY,Tuesday,02/18/2003,17:00,BAYVIEW,"ARREST, BOOKED",1600 Block of KIRKWOOD AV,122.390718076188,37.7385560584619
030203923,OTHER OFFENSES,PROBATION VIOLATION,Tuesday,02/18/2003,17:00,BAYVIEW,"ARREST, BOOKED",1600 Block of
KIRKWOOD AV,-122.390718076188,37.7385560584619
127
UselessL ongHea d erToBeIgnored .log
************ Start Display Current Environment ************
WebSphere Platform 6.1 [ND 6.1.0.21 cf210844.13]
running with process name
sammys_cell_A\fsgwws189Node_A\sammys_A_c01_s189_m06 and process id 17904
Detailed IFix information: ID: 6.1.0-WS-WASSDK-AixPPC32-FP0000021
BuildVrsn: null
Desc: Software Developer Kit
6.1.0.21
ID: 6.1.0-WS-WAS-AixPPC32-FP0000021
BuildVrsn: null
ID: 6.1.0-WS-WASSDK-AixPPC32-FP0000019
ID: 6.1.0-WS-WAS-AixPPC32-FP0000019
Desc: WebSphere Application Server 6.1.0.21
BuildVrsn: null
BuildVrsn: null
Desc: Software Developer Kit 6.1.0.19
Desc: WebSphere Application Server 6.1.0.19
ID: sdk.FP61021
BuildVrsn: null
Desc: WebSphere Application Server 6.1.0.21
ID: sdk.FP61019
BuildVrsn: null
Desc: WebSphere Application Server 6.1.0.19
ID: was.embed.common.FP61021
ID: was.embed.FP61021
BuildVrsn: null
BuildVrsn: null
Desc: WebSphere Application Server 6.1.0.21
Desc: WebSphere Application Server 6.1.0.21
Hea d erField sWith FewEm p tyField Na m esWith S p a c eDelim .c sv
"Field 1"
"Field 3" "Field 4"
"Field 6"
Value11,Value12,Value13,Value14,Value15,Value16
Value21,Value22,Value23,Value24,Value25
Value31,Value32,Value33,Value34,Value35, Value36
Field Hea d erRegex.log
Garbage
Garbage
Garbage
Ignore_This_Stuff: Actual_Header1 Actual_Header2
Answers
何か質問がありますか？「Splunk Answers」では、Splunk コミュニティに寄せられた、フィールドの抽出に関
する質問と回答をご覧いただけます。
ホスト値の設定
ホストについて
イベントの host フィールドの値は、イベントが⽣成された物理デバイスの名前です。これは Splunk Enterprise
がインデックスを作成した各イベントにホストを割り当てる、デフォルトフィールド のため、特定のホストが⽣
成したすべてのイベントを、ホスト名を使ってサーチすることができます。
⼀般的に host の値は、イベントの⽣成元となるホスト名、IP アドレス、またはネットワークホストの完全修飾ド
メイン名になります。
Splunk Enterprise による host 値の割り当て
Splunk Enterprise は以下の順序で設定を調査し、最初に⾒つかったホスト設定を使って各イベントに host 値を
割り当てます。
1. transforms.conf に指定されている、イベント固有のホスト割り当て。
2. イベントの⼊⼒の、デフォルトのホスト値 (ある場合)。
3. 最初にデータを取り込んだ Splunk インスタンス (インデクサーまたはフォワーダー) の、デフォルトのホスト
値。
これらの割り当て⽅法の概要と使⽤事例は、後述します。以降のトピックでは、これらの⽅法を詳細に説明してい
きます。
デフォルトのホスト値
ソースに対して他のホストルールが指定されていない場合、任意の⼊⼒からインスタンスに取り込まれる、すべて
のデータに適⽤されるデフォルト値が、host フィールドに割り当てられます。デフォルトのホスト値は、最初に
データを取り込んだ Splunk Enterprise インスタンス (インデクサーまたはフォワーダー) のホスト名または IP
アドレスになります。イベントが発⽣したサーバー上で Splunk Enterprise インスタンスが動作している場合
は、このホスト名は正確で⼿動による介⼊は必要ありません。
詳細は、このマニュアルの「Splunk Enterprise サーバーのデフォルトホストの設定」を参照してください。
ファイル/ディレクトリ⼊⼒のデフォルトホスト
128
Splunk Enterprise を集中ログアーカイブマシン上で実⾏している場合、または環境内の他のホストから転送され
たファイルを処理している場合、特定の⼊⼒から取り込まれるイベントの、デフォルトのホスト割り当てに優先す
る設定を⾏わなければならないことがあります。
特定の⼊⼒から取り込まれたデータのホスト値を割り当てるには、2 種類の⽅法があります。特定の⼊⼒から取り
込まれるすべてのデータに対して、静的なホスト値を定義する、またはパスの⼀部やソースのファイル名などを、
ホスト値に動的に割り当てることができます。各ホストのログアーカイブを異なるサブディレクトリに分類するよ
うなディレクトリ構造を採⽤している場合は、後者の⽅法が役⽴ちます。
詳細は、このマニュアルの「ファイル/ディレクトリ⼊⼒のデフォルトホストの設定」を参照してください。
イベント固有の割り当て
状況によっては、イベントデータを調査してホスト値を割り当てなければならないこともあります。たとえば、イ
ベントを Splunk Enterprise に送信する集中ログホストがある場合、そのメインのログサーバーには複数のホス
トサーバーがデータを送信しています。各イベントにその⽣成元サーバーのホスト値を確実に設定するには、その
イベントのデータを使ってホスト値を決定する必要があります。
詳細は、このマニュアルの「イベントデータに基づくホスト値の設定」を参照してください。
誤って割り当てられたホスト値の取り扱い
イベントデータに誤ったホスト値が割り当てられた場合でも、⼼配することはありません。このような問題を修正
するための、さまざまな⼿段が存在しています。
詳細は、このマニュアルの「誤って割り当てられたホスト値の取り扱い」を参照してください。
ホスト値のタグ設定
正確なサーチを実⾏する⼿助けとして、ホスト値にタグを設定することができます。タグを利⽤することで、さま
ざまなホストのグループを有⽤なサーチ可能カテゴリに変換することができます。
詳細は、『ナレッジ管理』マニュアルの「タグとエイリアスについて」を参照してください。
Splunk Enterprise サーバーのデフォルトホストの設定
イベントのホスト値は、イベントが⽣成されたネットワーク上の物理デバイスの、IP アドレス、ホスト名、また
は完全修飾ドメイン名です。Splunk Enterprise はインデックス時に、インデックスを作成した各イベントに対し
て host 値を割り当てるため、ホスト値でサーチを実⾏することで、特定のデバイスに由来するデータを⼿軽に発
⾒することができます。
デフォルトのホスト割り当て
ソースに対して他のホストルールを指定していない場合 (この章で説明している情報を使って)、イベントのデフォ
ルトのホスト値は、最初にイベントデータを取り込んだ Splunk インスタンス (フォワーダーまたはインデクサー)
が動作しているサーバーの、ホスト名または IP アドレスになります。イベントが Splunk Enterprise インスタン
スが動作しているサーバー上で⽣成された場合、そのホスト名割り当ては正確で、何も設定を変更する必要はあり
ません。ただし、すべてのデータが他のホストから転送される、またはアーカイブデータの⼀括ロードを⾏う場
合、そのデータのデフォルトのホスト値を変更した⽅が良いことがあります。
host フィールドのデフォルト値を設定するには、Splunk Web を使⽤するか、または
inputs.conf
を編集します。
Splunk Web を使ったデフォルトホスト値の設定
Splunk Web を使って、サーバーのデフォルトホスト値を設定します。
1. Splunk Web で、画⾯の右上にある、[システム] リンクをクリックします。
2. [システム] で、[システム設定] をクリックします。
3. [システム設定] ページで、[全般設定] をクリックします。
4. [全般設定] ページで、[インデックス設定] セクションまでスクロールして、[デフォルトのホスト名] を変更
します。
5. 変更内容を保存します。
この Splunk Enterprise インスタンスに取り込まれるすべてのイベントの、host フィールドのデフォルト値が設
定されます。この章の後半で説明しているように、個別のソースまたはイベントに対して、この値に優先する設定
を⾏うことができます。
inputs.conf を使ったデフォルトホスト値の設定
インストール時に、デフォルトのホスト割り当ては inputs.conf に設定されます。$SPLUNK_HOME/etc/system/local/
内、または $SPLUNK_HOME/etc/apps/ の独⾃のカスタム App ディレクトリ内にあるファイルを編集して、ホスト値を
変更することができます。
ホスト割り当ては、[default] スタンザに保管されています。
129
inputs.conf
内の、デフォルトのホスト割り当ての形式を以下に⽰します。
[default]
host = <string>
にデフォルトのホスト値を設定します。<string>のデフォルトは、データの起源となるホストの IP アドレ
スまたはドメイン名です。
<string>
警告： <string> の値を引⽤符で囲まないでください。host=fooで、host="foo" ではありません。
inputs.conf
への変更内容を反映するために、Splunk Enterprise を再起動してください。
注意： デフォルトで、host 属性には $decideOnStartup 変数が設定されています。これは、splunkd が動作している
マシンのホスト名が設定されることを意味しています。splunk デーモンの開始時には毎回、値が再解釈されま
す。
特定の⼊⼒から取り込んだデータのデフォルトホスト値に優先する設定
Splunk Enterprise を集中ログアーカイブマシン上で実⾏している場合、または環境内の他のホストから転送され
たファイルを処理している場合、特定の⼊⼒から取り込まれるイベントの、デフォルトのホスト割り当てに優先す
る設定を⾏わなければならないことがあります。
特定の⼊⼒から取り込まれたデータのホスト値を割り当てるには、2 種類の⽅法があります。特定の⼊⼒から取り
込まれるすべてのデータに対して、静的なホスト値を定義する、またはパスの⼀部やソースのファイル名などを、
ホスト値に動的に割り当てることができます。各ホストのログアーカイブを異なるサブディレクトリに分類するよ
うなディレクトリ構造を採⽤している場合は、後者の⽅法が役⽴ちます。
詳細は、このマニュアルの「ファイル/ディレクトリ⼊⼒のデフォルトホストの設定」を参照してください。
イベントデータを使ったデフォルトホスト値に優先する設定
状況によっては、イベントデータを調査してホスト値を割り当てなければならないこともあります。たとえば、イ
ベントを Splunk Enterprise に送信する集中ログホストがある場合、そのメインのログサーバーには複数のホス
トサーバーがデータを送信しています。各イベントにその⽣成元サーバーのホスト値を確実に設定するには、その
イベントのデータを使ってホスト値を決定する必要があります。
詳細は、このマニュアルの「イベントデータに基づくホスト値の設定」を参照してください。
ファイル/ディレクトリ⼊⼒のデフォルトホストの設定
特定のファイル/ディレクトリ⼊⼒のすべてのデータに、ホスト値を設定することができます。ホストは静的にま
たは動的に設定することができます。
ホスト値を静的 に設定する場合、指定したファイル/ディレクトリ⼊⼒から取り込まれる各イベントには、
同じホスト名が割り当てられます。
ホスト値を動的 に設定する場合、正規表現またはソースのディレクトリ・パスのセグメントを使って、ソー
ス⼊⼒の⼀部がホスト名として抽出されます。
また、ソースまたはソースタイプの値 (および他の種類の情報) に基づいて、特定のファイル/ディレクトリ⼊⼒か
ら取り込まれるイベントにホスト値を割り当てることも可能です。詳細は、このマニュアルの「イベントデータに
基づくホスト値の設定」を参照してください。
注意： 現在 Splunk Enterprise では、TCP、UDP、またはスクリプト⼊⼒ 経由で取り込んだイベントデータ
の、デフォルトのホスト設定は有効にはなっていません。
デフォルトホスト値の静的設定
この⽅法では、特定のファイル/ディレクトリ⼊⼒から取り込まれた各イベントに、単⼀のデフォルトホスト値が
適⽤されます。
注意： 静的なホスト値割り当ては、対応する⼊⼒から新たに取り込まれるデータにのみ適⽤されます。すでにイ
ンデックスが作成されたデータに、デフォルトのホスト値を割り当てることはできません。代わりに、ホスト値に
タグを設定することは可能です。
Splunk Web の使⽤
Splunk Web の [システム] にある [データ⼊⼒] ページから、ファイル/ディレクトリタイプの⼊⼒を新たに追加
した場合、そのファイル/ディレクトリ⼊⼒のホストを定義することができます。
1. Splunk Web の左上にある [システム] をクリックします。
2. [システム] ポップアップの [データ] セクションで、[データ⼊⼒] をクリックします。
3. [ファイルとディレクトリ] をクリックします。
4. [ファイルとディレクトリ] ページで、既存の⼊⼒の名前をクリックするか (更新する場合)、または [新規] をク
リックして、新しいファイル/ディレクトリ⼊⼒を作成します。
5. [ホスト] セクションで、[ホスト設定] ドロップダウンから [定数値] オプションを選択します。
130
6. [ホストフィールドの値] フィールドに、この⼊⼒⽤の静的なホスト値を⼊⼒します。
7. [保存 ] をクリックします。
⼊⼒および⼊⼒タイプの詳細は、このマニュアルの「Splunk Enterprise がモニターできる項⽬」を参照してくだ
さい。
inputs.conf の編集
inputs.conf を直接編集して、モニター対象ファイル/ディレクトリ⼊⼒のホスト値を指定することができます。
適切なスタンザに host 属性を設定してください。
[monitor://<path>]
host = <your_host>
内、または $SPLUNK_HOME/etc/apps/ の独⾃のカスタムアプリケーションディレクトリ
内にある inputs.conf を編集してください。設定ファイルの⼀般情報については、『管理マニュアル』の「設定
ファイルについて」を参照してください。
$SPLUNK_HOME/etc/system/local/
⼊⼒および⼊⼒タイプの詳細は、このマニュアルの「Splunk Enterprise がモニターできる項⽬」を参照してくだ
さい。
静的ホスト値割り当ての例
この例は、/var/log/httpd から取り込まれる任意のイベントを対象にしています。この⼊⼒から取り込まれるイベ
ントには、webhead-1 の host 値が割り当てられます。
[monitor:///var/log/httpd]
host = webhead-1
デフォルトホスト値の動的設定
この⽅法は、ソース⼊⼒パスのセグメントまたは正規表現から、ファイル/ディレクトリ⼊⼒のホスト値を動的に
抽出します。たとえば、アーカイブディレクトリのインデックスを作成する場合に、ディレクトリ内の各ファイル
の名前に、関連するホスト情報が含まれている場合、その情報を抽出してそれを host フィールドに割り当てるこ
とができます。
注意： 正規表現の構⽂と使⽤⽅法の概要については、Regular-Expressions.info を参照してください。正規表現
をテストするには、サーチ内で rex サーチ・コマンドを使ってそれらを指定します。正規表現式を作成、テストす
るために役⽴つサードパーティ製ツールのリストも⽤意されています。
Splunk Web の使⽤
1. Splunk Web の左上にある [システム] をクリックします。
2. [システム] ポップアップの [データ] セクションで、[データ⼊⼒] をクリックします。
3. [ファイルとディレクトリ] をクリックします。
4. [ファイルとディレクトリ] ページで、既存の⼊⼒の名前をクリックするか (更新する場合)、または [新規] をク
リックして、新しいファイル/ディレクトリ⼊⼒を作成します。
5. [ホスト] セクションで、[ホスト設定] ドロップダウンから、次のいずれかのオプションを選択します。
正規表現パス - 正規表現を使ってホスト名を抽出する場合、このオプションを選択します。次に、[正規表
現] フィールドに、ホストを抽出する正規表現を⼊⼒します。
セグメントパス - データソースのパス内のセグメントからホスト名を抽出する場合、このオプションを選択
します。次に [セグメント番号] フィールドに、セグメント番号を⼊⼒します。たとえば、ソースへのパス
が /var/log/<host server name> で、3 番⽬のセグメント (ホストサーバー名) をホスト値にする場合は、3 を
⼊⼒します。
6. [保存 ] をクリックします。
inputs.conf の編集
inputs.conf
を直接編集して、動的なホスト抽出ルールを設定することができます。
内、または $SPLUNK_HOME/etc/apps/ の独⾃のカスタムアプリケーションディレクトリ
内にある inputs.conf を編集してください。設定ファイルの⼀般情報については、『管理マニュアル』の「設定
ファイルについて」を参照してください。
$SPLUNK_HOME/etc/system/local/
正規表現を使って抽出した値で host フィールドを上書きするには、host_regex を使⽤します。
[monitor://<path>]
host_regex = <your_regular_expression>
131
正規表現は各⼊⼒のファイル名から、host 値を抽出します。正規表現の最初の捕捉グループが、ホストとして使⽤
されます。
注意： 正規表現に⼀致する項⽬がない場合、デフォルトの
host
属性がホストとして設定されます。
データソースのパス内のセグメントから抽出した値で、host フィールドを上書きするには、host_segment を使⽤し
ます。たとえば、ソースへのパスが /var/log/<host server name> で、3 番⽬のセグメント (ホストサーバー名) をホ
スト値にする場合は、⼊⼒スタンザは以下のようになります。
[monitor://var/log/]
host_segment = 3
動的なホスト割り当ての例
この例では、正規表現により
/var/log/foo.log
からのすべてのイベントに、ホスト値「foo」が割り当てられます。
[monitor://var/log]
host_regex = /var/log/(\w+)
この例は、パス
apache/logs
内の 3 番⽬のセグメントをホスト値に割り当てます。
[monitor://apache/logs/]
host_segment = 3
注意事項
inputs.conf スタンザで
同じスタンザ内に
host_segment
host_regex
属性を使⽤する場合、いくつかの注意事項があります。
と
host_segment
属性を同時に指定することはできません。
同じスタンザ内に host_segment と source 属性を同時に指定すると、host_segment 属性の動作が変化します。
ソースに対して指定した値に / (スラッシュ) が含まれている場合、host_segment に指定したセグメント
番号に基づいてホスト値が抽出されます。
source に / がない場合、または source で利⽤できるセグメント数よりも⼤きな host_segment 値を指定
すると、Splunk Enterprise はホスト値を抽出できません。代わりに、データを抽出したホスト名が使
⽤されます。以下の例を参照してください。
例 1： ホスト名は server01、ソース・パスは
/mnt/logs/server01、inputs.conf
には以下の項⽬を設定：
[monitor:///mnt/logs/]
host_segment = 3
この場合、Splunk Enterprise はホスト名
フィールドにこの値を設定します。
server01
例 2： ホスト名は server01、ソース・パスは
をソース・パス (/mnt/logs/server01/*) から抽出し、ホスト・
/mnt/logs/server01、inputs.conf
には以下の項⽬を設定：
[monitor:///mnt/logs/server01]
source = /mnt/logs/server01
host_segment = 3
この場合、Splunk Enterprise はホスト名
定します。
server01
例 3： ホスト名は server02、ソース・パスは
を
source
属性から抽出し、ホスト・フィールドにこの値を設
/mnt/logs/server02、inputs.conf
には以下の項⽬を設定：
[monitor:///mnt/logs/server02]
source = serverlogs
host_segment = 3
この場合、指定された source からホスト・セグメント値を抽出できないため、Splunk Enterprise はホスト・
フィールドとして server02 を使⽤します。
注意： 絶対に必要な場合を除いて、明⽰的に source を指定しないでください。この属性を指定してデフォルトの
ソース値に優先する設定を⾏う代わりに、ソースタイプ、タグ設定、およびサーチでのワイルドカードの使⽤を検
討してください。
イベントデータに基づくホスト値の設定
132
Splunk Enterprise では、イベント内のデータに基づいて、イベントにホスト名を割り当てることができます。こ
のトピックでは、イベントデータを使った、デフォルトのホスト割り当てに優先する設定を⾏う⽅法を説明してい
きます。
設定
イベント単位の優先設定を⾏うには、transforms.conf に 1 つ、そして props.conf にもう 1 つ、合計 2 つのスタン
ザを作成する必要があります。$SPLUNK_HOME/etc/system/local/ 内、または $SPLUNK_HOME/etc/apps/ の独⾃のカスタム
アプリケーションディレクトリ内にある、これらのファイルを編集します。設定ファイルの⼀般情報については、
『管理マニュアル』の「設定ファイルについて」を参照してください。
transforms.conf
以下の構⽂に従って、transforms.conf にスタンザを作成します。
[<unique_stanza_name>]
REGEX = <your_regex>
FORMAT = host::$1
DEST_KEY = MetaData:Host
以下の事項に注意してください。
は、関連するホスト値を反映する必要があります。この名前は、後ほど
ンザで使⽤します。
<your_regex> は、ホスト値を抽出するイベント内の位置を⽰す正規表現です。
FORMAT = host::$1 は、REGEX の値を host:: フィールドに書き込みます。
<unique_stanza_name>
props.conf
スタ
注意： 正規表現の構⽂と使⽤⽅法の概要については、Regular-Expressions.info を参照してください。正規表現
をテストするには、サーチ内で rex サーチコマンドを使ってそれらを指定します。正規表現式を作成、テストする
ために役⽴つサードパーティ製ツールのリストも⽤意されています。
props.conf
次に、props.conf に、transforms.conf のスタンザを参照するスタンザを作成します。
[<spec>]
TRANSFORMS-<class> = <unique_stanza_name>
以下の事項に注意してください。
<spec>
には、以下の値を使⽤できます。
<sourcetype>、イベントのソースタイプ。
host::<host>、ここで <host>
はイベントのホストを表します。
はイベントのソース値を表します。
<class> は、変換に割り当てる任意で⼀意の識別⼦です。
<unique_stanza_name> は、transforms.conf で作成したスタンザ名です。
source::<source>、<source>
例
ファイルから、以下のイベントセットを処理する場合を考えてみましょう。ホストは 3 番⽬にあり
ます (「fflanda」など) 。
houseness.log
41602046:53 accepted fflanda
41602050:29 accepted rhallen
41602052:17 accepted fflanda
まず、transforms.conf に新しいスタンザを作成し、ホスト値を抽出する正規表現を設定します。
[houseness]
DEST_KEY = MetaData:Host
REGEX = \s(\w*)$
FORMAT = host::$1
次に、props.conf スタンザで
transforms.conf
スタンザを参照します。例：
[source::.../houseness.log]
TRANSFORMS-rhallen=houseness
SHOULD_LINEMERGE = false
上記のスタンザには、追加の属性/値のペア
改⾏ごとに分割することを⽰しています。
SHOULD_LINEMERGE = false
133
が存在しています。この指定は、イベントを
これでサーチ結果には、イベントが以下のように表⽰されるようになります。
誤って割り当てられたホスト値の取り扱い
何らかの理由で、⼀部のイベントに誤ったホスト値が割り当てられていることに気が付くこともあるでしょう。た
とえば、Splunk Enterprise サーバー上のディレクトリにいくつかの Web プロキシのログを収集して保管してお
り、host フィールドの値に優先する設定を忘れたまま、そのディレクトリを⼊⼒として追加し、それらのすべて
のイベントのオリジナルのホスト値が、Splunk Enterprise ホストと同じになってしまうことがあります。
このような事態が発⽣した場合の対処⽅法を、複雑さの順番に記載していきます。
データセット全体を削除して、再度インデックス作成する。
サーチを使って誤ったホスト値を持つイベントを削除して、その後それらのイベントのインデックスを再作
成する。
不正なホスト値にタグを設定し、サーチにはそのタグを使⽤する。
CSV ルックアップを設定してホストをルックアップし、ルックアップ・ファイル内のそれを新しいフィール
ド名にマップして、その新しい名前をサーチに使⽤する。
host フィールドから新しいフィールド (temp_host など) へのエイリアスを設定し、名前 temp_host を使って正
しいホスト名をルックアップする CSV ルックアップを設定し、次にルックアップでオリジナルの host を新
しいルックアップ値で上書きする (ルックアップの定義時に OUTPUT オプションを使⽤)。
これらの⽅法の中で、データのインデックスを削除してからインデックスを再作成できないけれども、データを削
除して再インデックスを作成できれば最⾼のパフォーマンスを実現できるような場合は、最後の⽅法が最適です。
ソースタイプの設定
ソースタイプが重要な理由
ソースタイプ は、Splunk Enterprise が取り込んだすべてのデータに割り当てるデフォルトフィールド の 1 つ
です。これは、Splunk がインデックス作成時にデータを正しくフォーマットできるように、収集したデータの種
類を表しています。また、これはデータの分類⽅法でもあり、これを使ってデータを⼿軽にサーチすることができ
ます。
ソースタイプに関する重要事項
Splunk Enterprise はソースタイプを使ってデータのフォーマット⽅法を判断するため、データには正しいソース
タイプを割り当てることが⾮常に重要になります。これにより、インデックスが作成されたデータ (イベントデー
タ ) は、適切なタイムスタンプ およびイベント分割 を使って、期待通りのデータが作成されます。そのため、以
降のデータに対するサーチがとても簡単になります。
たいていの場合、データに正しいソースタイプを割り当てるのはとても簡単です。Splunk Enterprise には、多数
の事前定義されたソースタイプが⽤意されています。⼀般的には、データの取り込み時に Splunk Enterprise が
正しいソースタイプを⾃動的に選択します。ただし、ユーザーによる介⼊が必要な場合もあります。特殊なデータ
の場合、別の事前定義ソースタイプを⼿動で選択しなければならないこともあります。またデータが⾮常に特殊な
場合は、独⾃のイベント処理設定を持つ新たなソースタイプを作成する必要があります。データソースに異機種環
境データが含まれている場合は、イベント単位 (ソース単位ではない) にソースタイプを割り当てなければならな
いこともあります。
データのインデックスが作成されたら他のフィールドと同様に、ソースタイプを使ってイベントデータをサーチす
ることもできます。ソースタイプはデータを分類する主要な⼿段であるため、しばしばサーチで頻繁に利⽤されま
す。
⼀般的なソースタイプ
⼀般的な任意のデータ⼊⼒フォーマットを、ソースタイプにすることができます。ソースタイプの⼤半は、ログ
フォーマットです。Splunk Enterprise が⾃動的に認識できる、⼀般的なソースタイプの例を以下に⽰します。
access_combined ：NCSA 結合フォーマットの HTTP Web サーバーログ⽤。
apache_error ：標準の Apache Web サーバーエラーログ⽤。
cisco_syslog ：Cisco ネットワークデバイス (PIX ファイアウォール、ルーター、および ACS を含む) が
⽣成する標準 syslog ⽤、⼀般的には集中ログホストへのリモート syslog 経由。
websphere_core ：WebSphere からのコアファイルエクスポート。
注意 ：Splunk Enterprise が⾃動的に認識するソースタイプの⼀覧については、このマニュアルの「事前定義ソー
スタイプの⼀覧」を参照してください。
ソースタイプの設定
134
ソースタイプに関連する、2 種類の基本的な設定タイプがあります。
取り込んだデータに明⽰的にソースタイプを割り当てる。
最初から、または既存のソースタイプを変更して、新しいソースタイプを作成する。
ソースタイプの割り当て
たいていの場合、Splunk Enterprise がデータに最適なソースを判断し、取り込んだイベントに⾃動的にそれを割
り当てます。ただし、データにソースタイプを明⽰的に割り当てなければならないこともあります。通常この作業
は、データ⼊⼒の定義時に⾏います。ソースタイプ割り当ての改善⽅法の詳細は、以下のトピックを参照してくだ
さい。
「⾃動ソースタイプ割り当てに優先する設定」
「イベント単位でのソースタイプに優先する設定」
「ルールベースのソースタイプ認識の設定」
「ソースタイプ名の変更」
このトピックの後半では、Splunk Enterprise によるソースタイプの割り当て⽅法が説明されています。
新しいソースタイプの作成
ご利⽤のデータのニーズに既存のソースタイプでは対応できない場合は、新しいソースタイプを作成することがで
きます。
Splunk のデータプレビュー機能を利⽤すれば、ユーザーインターフェイスを使ってデータに合わせてソースタイ
プの設定を⼿軽に調整することができます。本質的にこの機能は、ビジュアルなソースタイプエディタと呼ぶこと
ができます。詳細は、「データへの適切なソースタイプの割り当て」を参照してください。
また、props.conf を直接編集して、ソースタイプのスタンザを追加することで、新しいソースタイプを作成する
こともできます。新しいソースタイプの作成⽅法を学習するには、「ソースタイプの作成」を参照してください。
データプレビュー機能を使ったソースタイプのテストと変更
Splunk Web のデータプレビュー機能は、⼊⼒に適⽤したソースタイプの効果を⼿軽に参照することができま
す。この機能では、実際にインデックスにイベントを書き込まずに、結果となるイベントをプレビューすることが
できます。また、データのプレビュー機能を使って、タイムスタンプとイベント分割設定を対話形式で編集し、変
更内容を新たなソースタイプとして保存することもできます。データ・プレビュー機能をソースタイプ・エディタ
として活⽤する⽅法については、「データへの適切なソースタイプの割り当て」を参照してください。
ソースタイプのサーチ
は、ソースタイプサーチフィールド名です。sourcetype フィールドを使って、任意のソースタイプから
の類似のデータタイプを探すことができます。たとえば、sourcetype=weblogic_stdout をサーチして、WebLogic が
複数のドメイン (Splunk の⽤語では「ホスト」) からログを記録している場合でも、すべての WebLogic サー
バーイベントを探すことができます。
sourcetype
Splunk Enterprise によるソースタイプの割り当て⽅法
Splunk Enterprise には、インデックス時にイベントデータにソースタイプを割り当てるためのさまざまな⽅法が
⽤意されています。イベントデータの処理時には、定義されている優先順位に従ってこれらの⽅法が適⽤されま
す。まず、inputs.conf および props.conf 内のハードコード化されたソースタイプ設定から始めて、ルールベース
のソースタイプ関連付けに移⾏し、次に⾃動ソースタイプ認識や⾃動ソースタイプ学習などの⽅法を利⽤します。
複数の⽅法を順次利⽤することで、Splunk Enterprise が特定の種類のイベントにソースタイプ値を適⽤する⽅法
を設定する⼀⽅で、他のイベントにはソースタイプ値を⾃動的に設定することができます。
Splunk Enterprise が、データ⼊⼒のソースタイプを決定するための処理⽅法を以下のリストに⽰します。
Splunk Enterprise は最初の⽅法から開始して、ソースタイプを判断できるまで、必要に応じてその他の⽅法を試
していきます。このリストでは、各レベルでのソースタイプ割り当ての設定⽅法の概要も説明されています。
1. データ⼊⼒に基づく明⽰的なソースタイプ指定
データ⼊⼒に対する明⽰的なソースタイプが⾒つかった場合は、ここで処理が中⽌されます。
これは、inputs.conf または Splunk Web で設定します。ファイル⼊⼒にソースタイプを割り当てるための
inputs.conf 構⽂を以下に⽰します。
[monitor://<path>]
sourcetype=<sourcetype>
Splunk Web で⼊⼒の定義時に、ソースタイプを割り当てることもできます。このファイル⼊⼒に対する作業に
ついては、このマニュアルの「Splunk Web の使⽤」を参照してください。このプロセスは、ネットワークや他
の⼊⼒のプロセスと似ています。
詳細は、「⼊⼒のソースタイプの指定」を参照してください。
2. データソースに基づく明⽰的なソースタイプ指定
特定のソースに対する明⽰的なソースタイプが⾒つかった場合は、ここで処理が中⽌されます。
135
これは、以下の構⽂を使って props.conf に設定できます。
[source::<source>]
sourcetype=<sourcetype>
詳細は、「ソースのソースタイプの指定」を参照してください。
3. ルールベースのソースタイプ認識
ソースタイプに対して作成された、任意のルールが適⽤されます。
props.conf
でソースタイプ分類ルールを作成することができます。
[rule::<rule_name>]
sourcetype=<sourcetype>
MORE_THAN_[0-100] = <regex>
LESS_THAN_[0-100] = <regex>
ソースタイプ認識ルールの設定の詳細は、「ルールベースのソースタイプ認識の設定」を参照してください。
4. ソースタイプの⾃動照合
次に、類似のファイルと照合して、ソースタイプの⾃動認識を⾏い、ソースタイプを割り当てます。
Splunk Enterprise はファイルまたはネットワーク⼊⼒ストリームの最初の数千⾏から、パターン⽤の署名を算出
します。これらの署名は、繰り返される単語パターン、句読点パターン、⾏の⻑さなどを識別します。Splunk
Enterprise が署名を算出する際に、既知の事前定義されている⼀連のソースタイプと⽐較が⾏われます。⼀致す
る項⽬があった場合は、そのソースタイプがデータに割り当てられます。
Splunk Enterprise が最初から認識できるソースタイプの⼀覧については、このマニュアルの「事前定義ソースタ
イプの⼀覧」を参照してください。
5. 遅延型ルールベースのソースタイプ関連付け
ここまでにソースタイプが特定できなかった場合、遅延型ルールが参照されます。
これは、ルールベースの関連付け (前述のステップ 3) と同じように機能します。props.conf に delayedrule:: スタ
ンザを作成します。これは、Splunk が前述の照合で何も分からなかった場合に役⽴つ、汎⽤型のルールになりま
す。
遅延型ルール関連付けは、前述のステップ 3 で rule:: を使って定義したソースタイプの汎⽤版として使⽤しま
す。たとえば、rule:: を使って、「sendmail syslog」や「cisco syslog」などの特定の syslog ソースタイプから
イベントデータを取得して、次に delayedrule:: で汎⽤型の「syslog」ソースタイプを残りの syslog イベントデー
タに適⽤します。
構⽂を以下に⽰します。
[delayedrule::$RULE_NAME]
sourcetype=$SOURCETYPE
MORE_THAN_[0-100] = $REGEX
LESS_THAN_[0-100] = $REGEX
ソースタイプ認識の遅延型ルールの設定と削除の詳細は、「ルールベースのソースタイプ認識の設定」を参照して
ください。
6. ソースタイプの⾃動学習
ここまでの⽅法でイベントにソースタイプを割り当てることができなかった場合、イベント署名⽤の新しいソース
タイプが作成されます (前述のステップ 4 を参照)。Splunk Enterprise は、学習パターン情報を
sourcetypes.conf に保存します。
⾃動ソースタイプ割り当てに優先する設定
Splunk Enterprise はデータへのソースタイプの⾃動割り当てを試みます。割り当てるソースタイプを明⽰的に指
定することができます。データ⼊⼒またはデータソースに基づいて、ソースタイプを割り当てるように設定するこ
とができます。
データへのソースタイプ割り当てルールの優先順位については、「Splunk によるソースタイプの割り当て⽅法」
を参照してください。
重要： 優先する設定は、ファイル/ディレクトリ⼊⼒にのみ機能します。ネットワーク⼊⼒のソースタイプに優先
する設定は⾏えません。また、優先設定はそれが設定された後に取り込まれたデータにのみ適⽤されます。すでに
インデックスが作成されたイベントのソースタイプを修正するには、代わりにソースタイプのタグを設定してくだ
さい。
ここでは、データに関する以下の事項に基づいた、ソースタイプの指定⽅法を説明していきます。
⼊⼒
136
ソース
⼊⼒のソースタイプの指定
などの、特定の⼊⼒から取り込まれたデータのソースタイプを明⽰的に割り当てることができます。こ
の作業は、Splunk Web または inputs.conf 設定ファイルを使って⾏います。
/var/log/
注意： ⼊⼒によるソースタイプの割り当ては⼿軽な⽅法に⾒えますが、きめ細かく調整することはできません。
この⽅法では、ある⼊⼒からのすべて のデータに同じソースタイプが割り当てられてしまいます (⼀部のデータが
別のソースやホストから取り込まれる場合でも)。より対象を絞り込み、ソースタイプの⾃動割り当てをバイパス
するには、このトピックの後半で説明しているように、データのソースに基づいてソースタイプを割り当てます。
Splunk Web の使⽤
[システム] でデータ⼊⼒を定義する場合、その⼊⼒から取り込まれるすべてのデータに適⽤する、ソースタイプ値
を設定することができます。[システム] では、リストからソースタイプを選択したり、独⾃のソースタイプ値を⼊
⼒したりすることができます。
⼊⼒のソースタイプを選択するには、[システム] から⽬的のデータ⼊⼒の設定を探します。ファイル⼊⼒の場合の
例を以下に⽰します。
1. Splunk Web の左上にある [システム] をクリックします。
2. [システム] ポップアップの [データ] セクションで、[データ⼊⼒] をクリックします。
3. [ファイルとディレクトリ] をクリックします。
4. [新規] ボタンをクリックして、⼊⼒を追加します。
5. [その他の設定] ボックスを選択します。
6. [ソースタイプ] には、ソースタイプを設定するための 3 種類の選択肢があります。
⾃動： このデフォルト設定では、データのソースタイプが⾃動的に選択されます。
リストから： ⼀般的な事前定義ソースタイプのリストが表⽰されます。このオプションの詳細は、次のセク
ションを参照してください。
マニュアル： ドロップダウンリストに⽬的のソースタイプがないけれども、事前定義ソースタイプには含ま
れている場合は、その値を⼿動で⼊⼒することができます。また、独⾃のソースタイプを⼿動で⼊⼒するこ
ともできます。このオプションの詳細は後述しています。
ドロップダウンリストからのソースタイプの選択
⼀般的な事前定義ソースタイプかのリストから、ソースタイプを選択することができます。
1. [ソースタイプを設定] ドロップダウンリストから、[リストから] を選択します。
2. 表⽰された [リストからソースタイプを選択] ドロップダウン リストから、ソースタイプを選択します。
3. ⼊⼒の設定を保存します。
その⼊⼒から取り込まれ、インデックスが作成されるすべてのイベントに対して、選択したソースタイプが割り当
てられるようになります。
注意： ドロップダウンリストには、⼀般的なソースタイプのみが表⽰されます。利⽤可能なすべての事前定義さ
れたソースタイプについては、「事前定義ソースタイプの⼀覧」を参照してください。
ソースタイプの⼿動⼊⼒
特定の⼊⼒から取り込まれるデータに対するソースタイプを、⼿動で⼊⼒することができます。
1. [ソースタイプを設定] ドロップダウンリストから、[マニュアル] を選択します。
2. 表⽰された [ソースタイプ] フィールドに、ソースタイプを⼊⼒します。Splunk の事前定義ソースタイプまた
は独⾃のソースタイプを指定できます。
3. ⼊⼒の設定を保存します。
その⼊⼒から取り込まれ、インデックスが作成されるすべてのイベントに対して、指定したソースタイプが割り当
てられるようになります。
inputs.conf 設定ファイルを使⽤
inputs.conf に⼊⼒を設定する場合、その⼊⼒のソースタイプを指定することができま
す。$SPLUNK_HOME/etc/system/local/ 内、または $SPLUNK_HOME/etc/apps/ の独⾃のカスタムアプリケーションディレク
トリ内にある inputs.conf を編集してください。設定ファイルの⼀般情報については、『管理マニュアル』の「設
定ファイルについて」を参照してください。
ソースタイプを指定するには、⼊⼒のスタンザ内に
sourcetype
137
属性を設定します。例：
[tcp://:9995]
connection_host=dns
sourcetype=log4j
source=tcp:9995
この例では、ポート 9995 の TCP ⼊⼒から取り込まれる、任意のイベントに対してソースタイプ「log4j」が設
定されます。
警告： 属性値は引⽤符で囲まないでください。sourcetype=log4jで、sourcetype="log4j" ではありません。
ソースのソースタイプの指定
ソースタイプの⾃動割り当てに優先して、特定のソースから取り込まれるすべてのデータに対して、単⼀のソース
タイプを明⽰的に割り当てるには、props.conf を使⽤します。
内、または $SPLUNK_HOME/etc/apps/ の独⾃のカスタムアプリケーションディレクトリ
内にある props.conf を編集してください。設定ファイルの⼀般情報については、「設定ファイルについて」を参照
してください。
$SPLUNK_HOME/etc/system/local/
重要： データを転送している場合に、ソースのソースタイプを割り当てるには、この作業をフォワーダー上の
props.conf で⾏う必要があります。レシーバー上の props.conf で作業を⾏うと、その優先設定は機能しません。
ソースタイプ割り当ての優先設定を⾏うには、props.conf にソース⽤のスタンザを追加します。スタンザにはソー
スパスを指定します。必要に応じて正規表現を使⽤してください。次に、sourcetype 属性でソースタイプを指定し
ます。例：
[source::.../var/log/anaconda.log(.\d+)?]
sourcetype=anaconda
この例は、/var/log/anaconda.log の後に任意の数の数字が続く⽂字列を含む、任意のソースから取り込まれるイベ
ントに対して、ソースタイプ「anaconda」を設定します。
重要： スタンザのソースパス正規表現 ([source::.../web/....log] など) は、できる限り対象を限定するように設定
する必要があります。「...」で終了する正規表現は使⽤しないでください。たとえば、以下のようには指定しない
でください。
[source::/home/fflanda/...]
sourcetype=mytype
このような設定は危険です。この場合、Splunk は /home/fflanda 内のすべての gzip ファイルを、gzip ファイルで
はなく「mytype」ファイルとして処理してしまいます。
以下のように指定することをお勧めします。
[source::/home/fflanda/....log(.\d+)?]
sourcetype=mytype
注意： 正規表現の構⽂と使⽤⽅法の概要については、Regular-Expressions.info を参照してください。正規表現
をテストするには、サーチ内で rex サーチコマンドを使ってそれらを指定します。正規表現式を作成、テストする
ために役⽴つサードパーティ製ツールのリストも⽤意されています。
ルールベースのソースタイプ認識の設定
ルールベースのソースタイプ認識を使って、Splunk Enterprise が認識するソースタイプの種類を増やすことがで
きます。props.conf に、特定のソースタイプと⼀連の基準を関連付ける rule:: スタンザを作成します。データの取
り込み時に、ルールの基準を満たすファイル⼊⼒に、指定したソースタイプが割り当てられます。
には、ルールと遅延型ルールの 2 種類のルールを作成することができます。これらのルールの違いは、
ソースタイプ処理プロセス中に、Splunk Enterprise がそれを確認する時期のみです。取り込まれたデータセット
の処理時に、Splunk Enterprise はさまざまな⽅法でソースタイプを決定します。
props.conf
データ⼊⼒またはソースに基づいて明⽰的なソースタイプ定義を確認後、props.conf に定義されている任意
の rule:: スタンザを参照し、それらのスタンザに定義されている分類ルールに基づいて、データのソースタ
イプの特定が試みられます。
rule:: スタンザを参照しても⼀致するソースタイプがない場合、過去に学習したソースタイプと類似のパ
ターンを識別する、ソースタイプの⾃動認識が試みられます。
それでも特定できない場合は、props.conf 内の delayedrule:: スタンザを参照して、それらのスタンザ内に定
義されているルールを使って、データのソースタイプの判断を試みます。
データへのソースタイプ割り当てルールの優先順位については、「Splunk Enterprise によるソースタイプの割り
当て⽅法」を参照してください。
スタンザに特別なソースタイプ⽤の分類ルールを指定し、また delayedrule:: スタンザには汎⽤ソースタイ
プ向けの分類ルールを指定することができます。このように、専⽤のソースタイプに当てはまらない各種イベント
rule::
138
には、汎⽤のソースタイプが適⽤されます。たとえば、rule:: スタンザを使って、sendmail_syslog や
cisco_syslogなどの特定の syslog ソースタイプを処理し、次に delayedrule:: スタンザを設定して、残りの syslog
データに汎⽤型の syslog ソースタイプを適⽤できます。
設定
ソースタイプルールを設定するには、$SPLUNK_HOME/etc/system/local/ 内、または $SPLUNK_HOME/etc/apps/ の独⾃のカ
スタムアプリケーションディレクトリ内にある props.conf を編集してください。設定ファイルの⼀般情報について
は、『管理マニュアル』の「設定ファイルについて」を参照してください。
ルールを作成するには、props.conf に rule:: または delayedrule:: スタンザを追加します。スタンザのヘッダーに
はルール名を指定して、スタンザ本⽂にソースタイプを定義します。ソースタイプを定義したら、ソースタイプ割
り当てルールを設定します。これらのルールは 1 つまたは複数の MORE_THAN および LESS_THAN ステートメントを使
⽤して、データ内の正規表現に⼀定割合以上適合するパターンを探します。
ルールを作成するには、以下の構⽂を使⽤します。
[rule::<rule_name>] OR [delayedrule::<rule_name>]
sourcetype=<source_type>
MORE_THAN_[0-99] = <regex>
LESS_THAN_[1-100] = <regex>
および LESS_THAN 属性には数値を設定します。これは、正規表現に指定された⽂字列を含む⼊⼒⾏の割合
(パーセント) を表しています。たとえば、MORE_THAN_80 の場合、⾏数の 80% 以上に、関連する式が含まれていな
ければなりません。LESS_THAN_20は、⾏数の 20% 以下が関連する式を含んでいることを表しています。
MORE_THAN
注意： 属性名は MORE_THAN_ となっていますが、実際にはこの属性は「〜を超える」ではなく、「以上」の意味を
持っています。同様に、LESS_THAN_ 属性は「以下」の意味で使⽤します。
ルールには、任意の数の MORE_THAN および LESS_THAN 条件を指定することができます。データファイルがルール内
のすべてのステートメントに合致する場合にのみ、そのルールのソースタイプが割り当てられます。たとえば、⾏
の 60% 以上がある正規表現に⼀致し、別の正規表現に⼀致する⾏が 20% 以下の場合にのみ、ファイル⼊⼒にそ
のソースタイプを割り当てるルールを定義することができます。
注意： 正規表現の構⽂と使⽤⽅法の概要については、Regular-Expressions.info を参照してください。正規表現
をテストするには、サーチ内で rex サーチコマンドを使ってそれらを指定します。正規表現式を作成、テストする
ために役⽴つサードパーティ製ツールのリストも⽤意されています。
例
Postfix syslog ファイル
# postfix_syslog sourcetype rule
[rule::postfix_syslog]
sourcetype = postfix_syslog
# If 80% of lines match this regex, then it must be this type
MORE_THAN_80=^\w{3} +\d+ \d\d:\d\d:\d\d .* postfix(/\w+)?\[\d+\]:
分割可能テキスト⽤遅延型ルール
# breaks text on ascii art and blank lines if more than 10% of lines have
# ascii art or blank lines, and less than 10% have timestamps
[delayedrule::breakable_text]
sourcetype = breakable_text
MORE_THAN_10 = (^(?:---|===|\*\*\*|___|=+=))|^\s*$
LESS_THAN_10 = [: ][012]?[0-9]:[0-5][0-9]
事前定義ソースタイプの⼀覧
Splunk Enterprise には、多数のソースタイプ定義が最初から⽤意されています。これらのソースタイプは、事前
定義ソースタイプと呼ばれています。
Splunk Enterprise は取り込んだデータの⼤半に、これらの事前定義ソースタイプを⾃動的に認識して割り当てる
ことができます。また、⾃動的には認識できないけれども、Splunk Web または inputs.conf を使って⼿動で割り
当てられる事前定義ソースタイプも⽤意されています (「⾃動ソースタイプ割り当てに優先する設定」など、この
章の各トピックを参照)。
事前定義ソースタイプが⽬的のデータに適合する場合は、それを使⽤することをお勧めします。Splunk
Enterprise は、事前定義ソースタイプのデータに対して、インデックスを適切に作成する⽅法を理解していま
す。ただし、データが事前定義ソースタイプに適していない場合は、独⾃のソースタイプを作成することができま
す (「ソースタイプの作成」を参照)。Splunk Enterprise は、独⾃のプロパティがない場合でも、実質的に任意の
形式のデータのインデックスを作成することができます。
139
ソースタイプの概要については、「ソースタイプが重要な理由」を参照してください。
⾃動認識されるソースタイプ
ソースタイプ名
access_combined
起源
例
NCSA 連結フォーマッ
ト http Web サーバーログ
(Apache や他の Web サーバー
が⽣成可能)
10.1.1.43 - webdev [08/Aug/2005:13:18:16 0700] "GET / HTTP/1.0" 200 0442 "-"
"check_http/1.10 (nagios-plugins 1.4)"
"66.249.66.102.1124471045570513" 59.92.110.121
NCSA 連結フォーマット http
Web サーバーログ (Apache や
access_combined_wcookie 他の Web サーバーが⽣成可
能)、最後に cookie フィールド
を追加
- - [19/Aug/2005:10:04:07 -0700] "GET
/themes/splunk_com/images/logo_splunk.png
HTTP/1.1" 200 994
"http://www.splunk.org/index.php/docs"
"Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.7.8) Gecko/20050524 Fedora/1.0.4-4
Firefox/1.0.4" "61.3.110.148.1124404439914689"
access_common
apache_error
NCSA 共通フォーマット
httpWeb サーバーログ
(Apache や他の Web サーバー
が⽣成可能)
標準 Apache Web サーバーロ
グ
10.1.1.140 - - [16/May/2005:15:01:52 -0700]
"GET /themes/ComBeta/images/bullet.png
HTTP/1.1" 404 304
[Sun Aug 7 12:17:35 2005] [error] [client
10.1.1.015] File does not exist:
/home/reba/public_html/images/bullet_image.gif
"","5106435249","1234","default","""James
asterisk_cdr
標準 Asterisk IP PBX コール詳
細レコード
Jesse""<5106435249>","SIP/52491ce3","","VoiceMail","u1234","2005-05-26
15:19:25","2005-05-26 15:19:25","2005-05-26
15:19:42",17,17,"ANSWERED","DOCUMENTATION"
asterisk_event
標準 Asterisk イベントログ (管
理イベント)
asterisk_messages
標準 Asterisk メッセージログ
(エラーと警告)
Aug 24 14:08:05 asterisk[14287]: Manager
'randy' logged on from 127.0.0.1
Aug 24 14:48:27 WARNING[14287]: Channel
'Zap/1-1' sent into invalid extension 's' in
context 'default', but no invalid handler
asterisk_queue
標準 Asterisk キューログ
1124909007|NONE|NONE|NONE|CONFIGRELOAD|
Sep 14 10:51:11 stage-test.splunk.com Aug 24
cisco_syslog
PIX ファイアウォール、ルー
ター、ACS などを含めて、す
べての Cisco ネットワークデ
バイスが⽣成する標準 Cisco
syslog、通常はリモート
syslog 経由で集中ログホスト
に送信される
2005 00:08:49: %PIX-2-106001: Inbound TCP
connection denied from IP_addr/port to
IP_addr/port flags TCP_flags on interface
int_name Inbound TCP connection denied from
144.1.10.222/9876 to 10.0.253.252/6161 flags
SYN on interface outside
2005-07-01-14.08.15.304000-420 I27231H328
LEVEL: Event PID
db2_diag
標準 IBM DB2 データベース管
理およびエラーログ
: 2120 TID
: 4760 PROC :
db2fmp.exe INSTANCE: DB2 NODE : 000 FUNCTION:
DB2 UDB, Automatic Table Maintenance,
db2HmonEvalStats, probe:900 STOP
: Automatic
Runstats: evaluation has finished on database
TRADEDB
2005-08-19 09:02:43 1E69KN-0001u6-8E =>
exim_main
Exim MTA メインログ
[email protected]
R=send_to_relay T=remote_smtp
H=mail.int.splunk.com [10.2.1.10]
2005-08-08 12:24:57 SMTP protocol violation:
exim_reject
synchronization error (input sent without
Exim 拒否ログ
waiting for greeting): rejected connection
from H=gate.int.splunk.com [10.2.1.254]
linux_messages_syslog
標準 Linux syslog (⼤半のプ
ラットフォームで
/var/log/messages)
linux_secure
Linux securelog
Aug 19 10:04:28 db1 sshd(pam_unix)[15979]:
session opened for user root by (uid=0)
Aug 18 16:19:27 db1 sshd[29330]: Accepted
publickey for root from ::ffff:10.2.1.5 port
40892 ssh2
log4j
log4j を使⽤する任意の J2EE
サーバーが⽣成する log4j 標準
140
2005-03-07 16:44:03,110 53223013 [PoolThread-
log4j
サーバーが⽣成する log4j 標準
出⼒
0] INFO [STDOUT] got some property...
050818 16:19:29 InnoDB: Started; log sequence
number 0 43644 /usr/libexec/mysqld: ready for
mysqld_error
標準 mysql エラーログ
connections. Version: '4.1.10a-log' socket:
'/var/lib/mysql/mysql.sock' port: 3306 Source
distribution
mysqld
postfix_syslog
標準 mysql クエリーログ、テ
キスト変換した mysql のバイ
ナリログにも対応
53 Query SELECT xar_dd_itemid, xar_dd_propid,
UNIX/Linux syslog 経由で報
告される標準 Postfix MTA ロ
グ
Mar 1 00:01:43 avas postfix/smtpd[1822]:
xar_dd_value FROM xar_dynamic_data WHERE
xar_dd_propid IN (27) AND xar_dd_itemid = 2
0141A61A83: client=host76117.pool80180.interbusiness.it[80.180.117.76]
Aug 6 04:03:32 nmrjl00 sendmail[5200]:
sendmail_syslog
UNIX/Linux syslog 経由で報
告される標準 Sendmail MTA
ログ
q64F01Vr001110: to=root, ctladdr=root (0/0),
delay=00:00:01, xdelay=00:00:00, mailer=relay,
min=00026, relay=[101.0.0.1] [101.0.0.1],
dsn=2.0.0, stat=Sent (v00F3HmX004301 Message
accepted for delivery)
sugarcrm_log4php
log4php ユーティリティを使っ
て報告される、標準 Sugarcrm
アクティビティログ
Fri Aug 5 12:39:55 2005,244 [28666] FATAL
layout_utils - Unable to load the application
list language file for the selected
language(en_us) or the default language(en_us)
####<Sep 26, 2005 7:27:24 PM MDT> <Warning>
weblogic_stdout
標準のネイティブ BEA 形式の
Weblogic サーバーログ
<WebLogicServer> <bea03> <asiAdminServer>
<ListenThread.Default> <<WLS Kernel>> <> <BEA000372> <HostName: 0.0.0.0, maps to multiple
IP addresses:169.254.25.129,169.254.193.219>
-------------------------------------ComponentId: Application Server ProcessId:
2580 ThreadId: 0000001c ThreadName: Nondeferrable Alarm : 3 SourceId:
com.ibm.ws.channel.framework.impl.
WSChannelFrameworkImpl ClassName: MethodName:
websphere_activity
Websphere アクティビティロ
グ、サービスログと呼ばれるこ
ともあります
Manufacturer: IBM Product: WebSphere Version:
Platform 6.0 [BASE 6.0.1.0 o0510.18]
ServerName: nd6Cell01\was1Node01\TradeServer1
TimeStamp: 2005-07-01 13:04:55.187000000
UnitOfWork: Severity: 3 Category: AUDIT
PrimaryMessage: CHFW0020I: The Transport
Channel Service has stopped the Chain labeled
SOAPAcceptorChain2 ExtendedMessage: -----------------------------------------NULL---------------------------------------------- 0SECTION TITLE subcomponent dump routine
NULL=============================== 1TISIGINFO
signal 0 received 1TIDATETIME Date: 2005/08/02
at 10:19:24 1TIFILENAME Javacore filename:
websphere_core
Websphere からの Corefile エ
クスポート
/kmbcc/javacore95014.1122945564.txt NULL ---------------------------------------------0SECTION XHPI subcomponent dump routine NULL
============================== 1XHTIME Tue Aug
2 10:19:24 20051XHSIGRECV SIGNONE received at
0x0 in <unknown>. Processing terminated.
1XHFULLVERSION J2RE 1.3.1 IBM AIX build ca13120031105 NULL
[7/1/05 13:41:00:516 PDT] 000003ae SystemErr R
websphere_trlog_syserr
IBM のネイティブ tr 形式の標
準 Websphere システムエラー
ログ
at com.ibm.ws.http.channel.
inbound.impl.HttpICLReadCallback.complete
(HttpICLReadCallback.java(Compiled Code))
(truncated)
[7/1/05 13:44:28:172 PDT] 0000082d SystemOut O
websphere_trlog_sysout
IBM のネイティブ trlog 形式の
標準 Websphere system out
ログ、Resin および Jboss の
log4j サーバーログと似ていま
すが (システムエラーログのサ
141
Fri Jul 01 13:44:28 PDT 2005 TradeStreamerMDB:
100 Trade stock prices updated: Current
Statistics Total update Quote Price message
count = 4400 Time to receive stock update
すが (システムエラーログのサ
ンプル形式)、重⼤度が低いイ
ベントおよび情報通知イベント
が含まれています
alerts messages (in seconds): min: -0.013 max:
527.347 avg: 1.0365270454545454 The current
price update is: Update Stock price for s:393
old price = 15.47 new price = 21.50
0050818050818 Sep 14 10:49:46 stagetest.splunk.com Windows_Host MSWinEventLog 0
Security 3030 Day Aug 24 00:16:29 2005 560
Security admin4 User Success Audit Test_Host
windows_snare_syslog
サードパーティ製 Intersect
Alliance Snare エージェント
経由で UNIX/Linux サーバー
上の syslog に報告される、標
準 Windows イベントログ
Object Open: Object Server: Security Object
Type: File Object Name:
C:\Directory\secrets1.doc New Handle ID: 1220
Operation ID: {0,117792} Process ID: 924
Primary User Name: admin4 Primary Domain:
FLAME Primary Logon ID: (0x0,0x8F9F) Client
User Name: - Client Domain: - Client Logon ID:
- Accesses SYNCHRONIZE ReadData (or
ListDirectory) Privileges -Sep
特殊ソースタイプ
ソースタイプ名
known_binary
起源
例
ファイル名が⼀般的にログファイルではな
くバイナリファイルとして知られているパ
ターンと⼀致
mp3 ファイル、画像ファイル、.rdf、.dat
など。これは明らかに⾮テキスト形式であ
るファイルを取得することを⽬的にしてい
ます。
事前定義ソースタイプ
⾃動的に認識されるもの、および⾃動的には認識されないものも含めた、すべての事前定義ソースタイプを以下に
⽰します。
カテゴ
リ
ソースタイプ
アプリ
ケー
ション
サー
バー
log4j、log4php、weblogic_stdout、websphere_activity、websphere_core、websphere_trlog
データ
ベース
mysqld、mysqld_error、mysqld_bin
メール
exim_main、exim_reject、postfix_syslog、sendmail_syslog、procmail
オペ
レー
ティン
グシス
テム
linux_messages_syslog、linux_secure、linux_audit、linux_bootlog、anaconda、
anaconda_syslog、osx_asl、osx_crashreporter、osx_crash_log、osx_install、osx_secure、
osx_daily、osx_weekly、osx_monthly、osx_window_server、windows_snare_syslog、dmesg、
ftp、ssl_error、syslog, sar、rpmpkgs
ネット
ワーク
novell_groupwise、tcp
プリン
タ
cups_access、cups_error、spooler
ルー
ターと
ファイ
ア
ウォー
ル
cisco_cdr、cisco_syslog、clavister
VoIP
asterisk_cdr、asterisk_event、asterisk_messages、asterisk_queue
Web
サー
バー
access_combined、access_combined_wcookie、access_common、apache_error、iis
その他
snort
事前定義ソースタイプの設定の表⽰
Splunk Enterprise がどのような設定情報を使って特定のソースタイプのインデックスを作成するのかを理解する
ために、btool ユーティリティを実⾏してプロパティの⼀覧を参照することができます。btool の使⽤⽅法の詳細
は、『Troubleshooting manual』の「Use btool to troubleshoot configurations」を参照してください。
tcp
ソースタイプの設定の表⽰例を以下に⽰します。
142
$ ./splunk btool props list tcp
[tcp]
BREAK_ONLY_BEFORE = (=\+)+
BREAK_ONLY_BEFORE_DATE = True
CHARSET = UTF-8
DATETIME_CONFIG = /etc/datetime.xml
KV_MODE = none
LEARN_SOURCETYPE = true
MAX_DAYS_AGO = 2000
MAX_DAYS_HENCE = 2
MAX_DIFF_SECS_AGO = 3600
MAX_DIFF_SECS_HENCE = 604800
MAX_EVENTS = 256
MAX_TIMESTAMP_LOOKAHEAD = 128
MUST_BREAK_AFTER =
MUST_NOT_BREAK_AFTER =
MUST_NOT_BREAK_BEFORE =
REPORT-tcp = tcpdump-endpoints, colon-kv
SEGMENTATION = inner
SEGMENTATION-all = full
SEGMENTATION-inner = inner
SEGMENTATION-outer = foo
SEGMENTATION-raw = none
SEGMENTATION-standard = standard
SHOULD_LINEMERGE = True
TRANSFORMS =
TRANSFORMS-baindex = banner-index
TRANSFORMS-dlindex = download-index
TRUNCATE = 10000
maxDist = 100
pulldown_type = true
イベント単位でのソースタイプに優先する設定
ここでは、イベント単位にソースタイプに優先する設定を⾏う⽅法を説明していきます。この処理は、「Splunk
Enterprise によるソースタイプの割り当て⽅法」で説明しているように、Splunk Enterprise が初期割り当てを
完了した後のパーシング時に⾏います。
イベント単位の優先設定を⾏うには、transforms.conf と
props.conf
を使⽤します。
注意： この種類の優先設定処理はパーシング時に⾏われるため、インデクサーまたはヘビーフォワーダー上での
み機能します。ユニバーサルフォワーダーでは利⽤できません。⼊⼒/パーシング/インデックス作成プロセスの過
程で利⽤できる設定については、『管理マニュアル』の「設定パラメータとデータパイプライン」を参照してくだ
さい。
特定の⼊⼒またはソースから取り込まれたイベントデータの、基本的な (イベントタイプではない ) ソースタイプ
優先設定については、このマニュアルの「⾃動ソースタイプ割り当てに優先する設定」を参照してください。
設定
イベント単位の優先設定を⾏うには、transforms.conf に 1 つ、そして props.conf にもう 1 つ、合計 2 つのスタン
ザを作成する必要があります。$SPLUNK_HOME/etc/system/local/ 内、または $SPLUNK_HOME/etc/apps/ の独⾃のカスタム
アプリケーションディレクトリ内にある、これらのファイルを編集します。設定ファイルの⼀般情報については、
『管理マニュアル』の「設定ファイルについて」を参照してください。
transforms.conf
以下の構⽂に従って、transforms.conf にスタンザを作成します。
[<unique_stanza_name>]
REGEX = <your_regex>
FORMAT = sourcetype::<your_custom_sourcetype_value>
DEST_KEY = MetaData:Sourcetype
以下の事項に注意してください。
は、関連するソースタイプを反映する必要があります。この名前は、後ほど props.conf
スタンザで使⽤します。
<your_regex> は、独⾃のソースタイプを適⽤するイベントを表す正規表現です (特定のホスト名や他のフィー
ルド値を持つイベントなど)。
<your_custom_sourcetype_value> は、正規表現に⼀致したイベントに適⽤するソースタイプです。
<unique_stanza_name>
143
注意： 正規表現の構⽂と使⽤⽅法の概要については、Regular-Expressions.info を参照してください。正規表現
をテストするには、サーチ内で rex サーチコマンドを使ってそれらを指定します。正規表現式を作成、テストする
ために役⽴つサードパーティ製ツールのリストも⽤意されています。
props.conf
次に
props.conf
に、transforms.conf のスタンザを参照するスタンザを作成します。
[<spec>]
TRANSFORMS-<class> = <unique_stanza_name>
以下の事項に注意してください。
<spec>
には、以下の値を使⽤できます。
<sourcetype>、イベントのソースタイプ。
host::<host>、ここで <host>
はイベントのホストを表します。
はイベントのソース値を表します。
<class> は、変換に割り当てる任意で⼀意の識別⼦です。
<unique_stanza_name> は、transforms.conf で作成したスタンザ名です。
source::<source>、<source>
例：単⼀の⼊⼒から取り込まれた異なるホストを持つイベントへのソースタイプの割り当
て
共有 UDP ⼊⼒ UDP514 がある場合を考えてみましょう。Splunk Enterprise インスタンスはこの⼊⼒を使っ
て、さまざまなホストからのデータのインデックスを作成します。UDP514 経由で Splunk に取り込まれるデー
タの中で、3 台のホスト (host1、host2、および host3) からのデータに、特定のソースタイプ「my_log」を割り
当てる必要があります。
まず始めに、Splunk が⼀般的に使⽤する、syslog イベントの host フィールドを抽出する正規表現を利⽤するこ
とができます。これは、system/default/transforms.conf 内にあります。
[syslog-host]
REGEX = :\d\d\s+(?:\d+\s+|(?:user|daemon|local.?)\.\w+\s+)*\[?(\w[\w\.\-]{2,})\]?\s
FORMAT = host::$1
DEST_KEY = MetaData:Host
この正規表現を、⽬的のホスト名 (この例では host1、host2、host3) からのイベントにのみ⼀致するように修正
します。
REGEX = :\d\d\s+(?:\d+\s+|(?:user|daemon|local.?)\.\w+\s+)*\[?(host1|host2|host3)[\w\.\-]*\]?\s
これらの 3 台のホストからのイベントに
します。
my_log
ソースタイプを適⽤する変換内で、この修正した正規表現を使⽤
[set_sourcetype_my_log_for_some_hosts]
REGEX = :\d\d\s+(?:\d+\s+|(?:user|daemon|local.?)\.\w+\s+)*\[?(host1|host2|host3)[\w\.\-]*\]?\s
FORMAT = sourcetype::my_log
DEST_KEY = MetaData:Sourcetype
次にその変換を、特定の⼊⼒を識別する
props.conf
のスタンザ内に指定します。
[source::udp:514]
TRANSFORMS-changesourcetype = set_sourcetype_my_log_for_some_hosts
ソースタイプの作成
新しいソースタイプは、2 種類の⽅法で作成することができます。
Splunk Web の [ソースタイプの設定] を使⽤する。
props.conf 設定ファイルを編集する
Splunk Web でのソースタイプの設定
Splunk Web の [ソースタイプの設定] ページでは、データにソースタイプを適⽤した効果を⼿軽に参照し、必要
に応じてソースタイプの設定を調整することができます。変更内容を新たなソースタイプとして保存して、それを
データ⼊⼒に割り当てることができます。
このページでは、タイムスタンプ やイベント の分割を調整するための、⼀般的な種類の調整オプションが⽤意さ
れています。その他の変更を⾏う場合は、props.conf ファイルを直接編集します。設定を変更すると、即座にイベ
ントデータの変化を確認することができます。
詳細は、このマニュアルの「[ソースタイプの設定] ページ」を参照してください。
144
props.conf の編集
を編集して新しいスタンザを追加することで、新しいソースタイプを作成できます。props.conf の詳細
は、『管理マニュアル』の props.conf に関する記事を参照してください。
props.conf
内、または $SPLUNK_HOME/etc/apps/ の独⾃のカスタムアプリケーションディレクトリ
内にある、props.conf ファイルを編集します。設定ファイルの⼀般情報については、『管理マニュアル』の「設定
ファイルについて」を参照してください。
$SPLUNK_HOME/etc/system/local/
データプレビュー機能の [詳細モード] タブから、新しいソースタイプの props.conf スタンザを直接作成すること
もできます。詳細は、「イベント処理の変更」の詳細モードに関するセクションを参照してください。
ソースタイプを作成する場合、サーチ可能イベントを作成するためのデータの処理⽅法を設定します。特に、2 つ
の重要な設定を指定する必要があります。
イベント改⾏： props.conf を使ったイベント分割の指定⽅法については、「イベントの⾏分割の設定」を参
照してください。
タイムスタンプ： props.conf を使ったタイムスタンプの指定⽅法については、「タイムスタンプ認識の設
定」、およびこのマニュアルの「タイムスタンプの設定」内の、他のトピックを参照してください。
その他のさまざまな設定を⾏うこともできます。詳細は、props.conf の仕様を参照してください。
ソースタイプ名の変更
状況によっては、ソースタイプ名の変更が必要なこともあります。たとえば、⼊⼒に誤ったソースタイプ名を割り
当ててしまった場合に、ソースタイプ名の変更が必要になります。また、2 つの異なる名前のソースタイプを、
サーチ時に同時に処理しなければならないこともあります。
内で rename 属性を使って、サーチ時に新しいソースタイプをイベントに割り当てることができます。そ
の後もそれを使ってサーチする必要がある場合、オリジナルのソースタイプは別のフィールド _sourcetype に移動
されます。
props.conf
注意： インデックス作成されたイベントには、引き続きオリジナルのソースタイプが含まれます。名前の変更は
サーチ時にのみ⾏われます。また、ソースタイプ名を変更しても、最初に誤ったソースタイプを割り当てたことに
より⽣成された、イベントデータのインデックスフォーマットが修正される訳ではありません。
ソースタイプ名を変更するには、ソースタイプスタンザに
rename
属性を追加します。
rename = <string>
注意： ソースタイプ名には⽂字 a〜z、数字 0〜9、および
_
(アンダースコア) ⽂字のみ使⽤できます。
たとえば、アプリケーションサーバーに対して、ソースタイプ「cheese_shop」を使⽤している場合を考えてみ
ましょう。その後誤って、⼀連のデータをソースタイプ「whoops」としてインデックスを作成してしまいまし
た。ソースタイプ名「whoops」を「cheese_shop」に変更するには、props.conf に以下のスタンザを指定しま
す。
[whoops]
rename=cheese_shop
これで、「cheese_shop」でサーチを⾏うと、最初に使⽤していた「cheese_shop」ソースタイプのイベントだ
けではなく、「whoops」ソースタイプのイベントも表⽰されるようになります。
sourcetype=cheese_shop
「whoops」イベントを選出する必要がない場合は、サーチに
_sourcetype
を使⽤することができます。
_sourcetype=whoops
重要： 名前を変更したソースタイプからのデータは、ターゲットソースタイプ (この例では「cheese_shop」) の
サーチ時設定のみを使⽤します。オリジナルのソースタイプ (この例では「whoops」) で抽出されたフィールドは
無視されます。
イベントのセグメント分割の管理
セグメント分割について
セグメント分割 は、インデックス 時にサーチ可能セグメント にイベントを分割し、もう⼀度サーチ 時に分割す
るために⽤いられます。セグメント分割は、メジャー またはマイナー に分類できます。マイナーセグメントは、
メジャーセグメント内の分割セグメントです。たとえば、IP アドレス 192.0.2.223 は、メジャーセグメントです。
しかし、このメジャーセグメントは、192 のようなマイナーセグメント、または 192.0.2 のようなマイナーセグメ
ントのグループに分割することができます。
145
イベントのセグメント分割の度合いを定義することができます。インデックス時セグメント分割 はインデックス
作成とサーチ速度、ストレージサイズ、および先⾏⼊⼒機能 (Splunk Web が提供する、サーチバーに⼊⼒したテ
キストに⼀致する項⽬を表⽰する機能) の使⽤可否に影響するため、このことが重要になります。⼀⽅サーチ時セ
グメント分割 はサーチ速度、および Splunk Web に表⽰された結果から項⽬を選択してサーチを作成できるかど
うかに影響します。
「インデックス時」と「サーチ時」の違いについては、『インデクサーとクラスタの管理』マニュアルの「イン
デックス時とサーチ時」を参照してください。
props.conf で、特定のカテゴリのイベントに、セグメント分割を割り当てることができます。詳細は、「イベン
トデータのセグメント分割の設定」を参照してください。
イベントのセグメント分割のタイプ
インデックス時またはサーチ時に設定できる、主に 3 種類のセグメント分割タイプ (レベル) があります。
インナーセグメント分割 は、細分可能なもっとも⼩さなマイナーセグメントにまでイベントを分割しま
す。たとえば、192.0.2.223 のような IP アドレスにインナーセグメント分割を⾏うと、192、0、2、および
223 に分割されます。インデックス時にインナーセグメント分割を設定すると、インデックス作成および
サーチ処理が⾼速化され、ディスクの使⽤量が減少します。ただし、先⾏⼊⼒機能は制限され、ユーザーは
マイナーセグメントレベルでのみ先⾏⼊⼒を⾏えます。
アウターセグメント分割 は、インナーセグメント分割の反対です。アウターセグメント分割では、メ
ジャーセグメントのインデックスのみが作成されます。たとえば、IP アドレス 192.0.2.223 は、192.0.2.223
としてインデックスが作成されます。この場合、フレーズ内の個別の部分はサーチできません。ただし、ワ
イルドカードを使ってフレーズ内の⼀部をサーチすることは可能です。たとえば、192.0* でサーチする
と、192.0 から始まる IP アドレスを持つ、任意のイベントを取得することができます。また、アウターセグ
メント分割では、IP アドレスの 192.0 の部分 (セグメント) などの、サーチ結果内の個別のセグメントをク
リックしてサーチを実⾏することはできません。アウターセグメント分割は、フルセグメント分割に⽐べて
少し効率性が⾼い傾向がありますが、インナーセグメント分割の⽅が⼤幅に効率が⾼くなります。
フルセグメント分割 は、インナーセグメント分割とアウターセグメント分割の組み合わせです。フルセグ
メント分割の場合、IP アドレスはメジャーセグメントと、192.0 や 192.0.2 などの各種マイナーセグメントの
両⽅に対して、インデックスが作成されます。このオプションは効率的がもっとも低くなりますが、多彩な
サーチ機能を利⽤することができます。
にある segmenters.conf ファイルは、利⽤可能なセグメント分割タイプを定義しま
す。デフォルトで、インデックス時セグメント分割は indexing タイプ (インナーセグメント分割とアウターセグメ
ント分割の組み合わせ) に設定されています。サーチ時セグメント分割には、フルセグメント分割が設定されてい
ます。
$SPLUNK_HOME/etc/system/default
セグメント分割なし
スペース効率がもっとも⾼いセグメント分割設定が、セグメント分割を完全に無効にすることです。ただし、これ
がサーチに与える影響は⼤きくなります。セグメント分割なしでインデックスを作成するように設定すると、
time、source、host、および source type などの、インデックス作成フィールドに対するサーチが制限されま
す。キーワードに対するサーチでは、結果が返されません。サーチにパイプを使⽤して、結果を制限する必要があ
ります。この設定は、⾼度なサーチ機能が不要な場合にのみ使⽤してください。
セグメント分割タイプの設定
segmenters.conf はセグメント分割タイプを定義しています。必要に応じて独⾃のセグメント分割タイプを定義す
ることもできます。
デフォルトで利⽤できるセグメント分割タイプについては、$SPLUNK_HOME/etc/system/default 内の
ファイルを参照してください。
segmenters.conf
重要： デフォルトのファイルは変更しないでください。既存のセグメント分割スタンザを変更、または新しいス
タンザを作成する場合は、デフォルトファイルを $SPLUNK_HOME/etc/system/local/ または $SPLUNK_HOME/etc/apps/ 内の
カスタム App ディレクトリにコピーしてください。設定ファイルとディレクトリの場所については、「設定ファ
イルについて」を参照してください。
特定のホスト、ソース、またはソースタイプへのセグメント分割の設定
特定のホスト、ソース、またはソースタイプに、適⽤するインデックス時およびサーチ時セグメント分割を設定す
ることができます。特定のソースタイプが関与するサーチを定期的に実⾏する場合、この機能を使ってそれらサー
チのパフォーマンスを向上することができます。同様に、⽇常的に⼤量の syslog イベントのインデックスを作成
する場合に、この機能を使ってそれらのイベントが占有するディスクスペースを減らすことができます。
特定のイベントカテゴリへのセグメント分割タイプの適⽤⽅法については、「イベントデータのセグメント分割の
設定」を参照してください。
イベントデータのセグメント分割の設定
デフォルトでは、柔軟なサーチを可能にするために、インデックス作成中にイベントのセグメント分割が⾏われま
す。さまざまなタイプのセグメント分割を利⽤できます。また、必要に応じてタイプを作成することもできます。
使⽤するセグメント分割のタイプは、インデックス作成速度、サーチ速度、およびインデックスが占有するディス
ク量に影響を与えます。セグメント分割の詳細および各セグメント分割タイプのトレードオフについては、「セグ
メント分割について」を参照してください。
Splunk Enterprise では、サーチ時にイベントをセグメント分割することもできます。サーチ時セグメント分割
は、Splunk Web で設定できます。「Splunk Web でのサーチ時セグメント分割の設定」を参照してください。
146
特定のホスト、ソース、またはソースタイプからのイベントの、サーチまたは処理⽅法が分かっている場合、その
タイプのイベントにインデックス時セグメント分割を設定することができます。特定のタイプのイベントに、サー
チ時セグメント分割を設定することもできます。
props.conf へのセグメント分割の指定
特定のホスト、ソース、またはソースタイプを持つイベントに対してセグメント分割を指定するには、props.conf
内の適切なスタンザにセグメント分割タイプを割り当てます。スタンザには、segmenters.conf に定義されたセグ
メント分割タイプまたは「ルール」を割り当てます。事前定義されたタイプ (inner、outer、または full)、または
独⾃に定義したカスタムタイプを使⽤できます。独⾃のタイプの定義については、「セグメント分割タイプの設
定」を参照してください。
これらのタイプに対して props.conf に設定する属性は、インデックス時セグメント分割を設定するのか、または
サーチ時セグメント分割を設定するのかによって異なります。
インデックス時セグメント分割の場合は、SEGMENTATION 属性を使⽤します。
サーチ時セグメント分割の場合は、SEGMENTATION-<segment selection> 属性を使⽤します。
スタンザ内にはいずれかの属性、または両⽅の属性を指定することができます。
スタンザは、$SPLUNK_HOME/etc/system/local/props.conf に追加します。
インデックス時セグメント分割
SEGMENTATION
属性は、インデックス時に使⽤されるセグメント分割タイプを決定します。構⽂を以下に⽰します。
[<spec>]
SEGMENTATION = <seg_rule>
[<spec>]
には、以下の値を使⽤できます。
<sourcetype>：イベントデータ内のソースタイプ。
host::<host>：イベントデータ内のホスト値。
source::<source>：イベントデータ内のソース。
SEGMENTATION = <seg_rule>
これは、[<spec>] イベントに対してインデックス時に使⽤する、セグメント分割タイプを⽰します。
<seg_rule>
次の所に定義されているセグメント分割タイプ、または「ルール」: segmenters.conf
⼀般的な設定は、inner、outer、none、および full ですが、デフォルトファイルには他の事前定義ルー
ルも存在しています。
独⾃のルールを作成するには、$SPLUNK_HOME/etc/system/local/segmenters.conf を編集します。詳細は、
「セグメント分割タイプの設定」を参照してください。
サーチ時セグメント分割
SEGMENTATION-<segment_selection>
属性は、サーチ時に使⽤されるセグメント分割タイプを決定します。構⽂を以下
に⽰します。
[<spec>]
SEGMENTATION-<segment_selection> = <seg_rule>
[<spec>]
には、以下の値を使⽤できます。
<sourcetype>：イベントデータ内のソースタイプ。
host::<host>：イベントデータ内のホスト値。
source::<source>：イベントデータ内のソース。
SEGMENTATION-<segment_selection> = <seg_rule>
これは、[<spec>] イベントに対して、Splunk Web でサーチ時に使⽤する、セグメント分割タイプを⽰しま
す。
は、以下のいずれかになる可能性があります。full、inner、outer、または raw。
これらの 4 つの値は、Splunk Web のサーチ結果の上にある [オプション] から表⽰する、[結果表⽰
オプション] パネルの [イベントのセグメント化] ドロップダウンに表⽰するオプションです。
これらの値は、単純に Splunk Web のドロップダウンで利⽤できるオプションです。この属性を使っ
て、オプションが実⾏する実際のセグメント分割タイプを指定することができます (ドロップダウンに
表⽰されるオプションとは違う名前のタイプにすることもできます)。たとえば、通常そうすることは
ありませんが、「inner」ドロップダウンオプションを定義して、「outer」セグメント分割タイプを実
⾏することもできます。
ドロップダウンオプションを <seg_rule> にマップすることで、後ほどサーチ結果を参照する際に、そ
のオプションを使ってサーチ時セグメント分割を設定することができます。詳細は、「Splunk Web
でのサーチ時セグメント分割の設定」を参照してください。
<segment_selection>
147
<seg_rule>
次の所に定義されているセグメント分割タイプ、または「ルール」: segmenters.conf
⼀般的な設定は、inner、outer、none、および full ですが、デフォルトファイルには他の事前定義ルー
ルも存在しています。
独⾃のルールを作成するには、$SPLUNK_HOME/etc/system/local/segmenters.conf を編集します。詳細は、
「セグメント分割タイプの設定」を参照してください。
例
この例では、syslog イベントに対して、インデックス時およびサーチ時の両⽅のセグメント分割ルールを設定しま
す。
props.conf
の
[syslog]
ソースタイプスタンザに、以下の項⽬を追加します。
[syslog]
SEGMENTATION = inner
SEGMENTATION-full= inner
このスタンザは、syslog ソースタイプを持つすべてのイベントに対して、インデックス時のセグメント分割をイン
ナーセグメント分割に変更します。また、Splunk Web 内で、[full] ラジオボタンを使って、それらのイベントの
インナーセグメント分割を実⾏できるようになります。
注意： サーチ時セグメント分割の変更を反映するには、Splunk Enterprise を再起動する必要があります。既存
のデータにインデックス時セグメント分割の変更を適⽤するには、データのインデックスを再作成する必要があり
ます。
Splunk Web でのサーチ時セグメント分割の設定
Splunk Web では、サーチ結果のセグメント分割を設定することができます。これは、インデックス時のセグメ
ント分割には何も影響しません。ただし、Splunk Web でのサーチ時セグメント分割では、ブラウザの操作性に
影響し、サーチ結果の取得を⾼速化できる可能性があります。
サーチ結果のセグメント分割を設定するには：
1. サーチを実⾏します。結果を参照します。
2. 返されたイベントセットの上にある、[オプション...] をクリックします。
3. [イベントのセグメント化] ドロップダウンで、利⽤可能ないずれかのオプション (full、inner、outer、または
raw) を選択します。デフォルトは「full」です。
これらのドロップダウンの意味を設定することができます。詳細は、「イベントデータのセグメント分割の設定」
を参照してください。
データ取り込みプロセスの改善
テスト⽤インデックスを使って⼊⼒をテストする
新しい⼊⼒を実働環境のインデックスに追加する前に、まずテストを実施することをお勧めします。⼊⼒をテスト
⽤インデックスに追加してください。⼊⼒から正しいデータが取り込まれ、⽣成されるイベントの形式も良好な場
合は、その⼊⼒にデフォルトの「main」インデックスを設定します。その後も新しい⼊⼒は、この⽅法でテスト
してください。
⼊⼒から⽬的のデータが取り込まれない場合、またはインデックスが作成されたイベントの形式が誤っている場合
は、適切な結果が出るまでテストと修正を⾏います。良好な結果が得られた場合は、⼊⼒を編集して main イン
デックスを設定します。
Splunk Enterprise がテスト⽤インデックスに、どのようにデータのインデックスを作成するかをプレビューする
ことができます。プレビュー中、いくつかのイベント処理設定を対話的に調整することができます。詳細は
「[ソースタイプの設定] ページ」を参照してください。
テスト⽤インデックスの使⽤
カスタムインデックスの作成と使⽤の詳細は、『インデクサーとクラスタの管理マニュアル』の「複数のインデッ
クスの設定」を参照してください。基本的ないくつかのステップが存在しています。それぞれのステップは、対応
するトピックで詳細に説明しています。
1. Splunk Web または CLI を使⽤して、または直接 indexes.conf を編集して、テスト⽤インデックスを作成しま
す。詳細は、「複数インデックスの設定」を参照してください。
2. データ⼊⼒の設定時に、イベントをテスト⽤インデックスにルーティングします。通常この作業は、Splunk
Web を使って⾏えます。各⼊⼒に対して：
a. [データの追加] ページで [その他の設定] オプションを選択します。「インデックス 」も含めて、さまざまな
新しいフィールドが表⽰されます。
b. [インデックス] ドロップダウンで、テスト⽤インデックスを選択します。そのデータ⼊⼒のすべてのイベント
148
が、選択したインデックスに送られます。
c. テスト⽤インデックスを送信する各データ⼊⼒に対して、この作業を繰り返します。
inputs.conf
に⼊⼒を設定する際にインデックスを指定することも可能です。
3. サーチを実⾏する際に、サーチコマンドにテスト⽤インデックスを指定します。(デフォルトで Splunk
Enterprise は「main」インデックスをサーチします。)index= コマンドを使⽤します。
index=test_index
注意 ：テスト⽤インデックスで新しく作成した⼊⼒から取り込んだイベントをサーチする場合、フィールドサイ
ドバー で時間範囲として [リアルタイム] > [全時間 (リアルタイム)] を使⽤することをお勧めします。リアルタイ
ムサーチ の結果には、抽出されたタイムスタンプに関係なく、そのインデックスに書き込まれたすべてのイベン
トが表⽰されます。この⽅法は、特に [過去 1 時間] または [リアルタイム] > [30 分のウィンドウ] のサーチでは
表⽰されない、履歴データのインデックスを作成している場合に役⽴ちます。
インデックスデータの削除とやり直し
テスト⽤インデックスを消去してもう⼀度やり直したい場合は、CLI コマンドの
clean
を使⽤します。
⼊⼒へのデフォルトインデックスの指定
結果が良好で実際にインデックスを作成する準備ができたら、データ⼊⼒を編集してテスト⽤インデックスの代わ
りにデフォルトの「main」インデックスを設定します。この作業は簡単です。最初にテスト⽤インデックスを作
成した作業の設定内容を元に戻すだけです。すでに設定した各データ⼊⼒に対して：
1. 当初⼊⼒を設定した場所に戻ります。たとえば、Splunk Web の [データの追加] ページで⼊⼒を設定した場合
は、その⼊⼒の設定画⾯に戻ります。
a. [システム] > [システム設定] > [データ⼊⼒] を選択します。
b. ⼊⼒のデータタイプを選択して、設定されているそのタイプのすべての⼊⼒を⼀覧表⽰します。
c. 編集するデータ⼊⼒を選択します。編集画⾯が表⽰されます。
d. [詳細設定を表⽰] オプションを選択します。[インデックス] フィールドに移動します。
e. [インデックス] ドロップダウンで、[main] インデックスを選択します。そのデータ⼊⼒のすべてのイベント
が、選択したインデックスに送られます。
inputs.conf
を使って⼊⼒を設定した場合は、そのファイルを編集してインデックスを変更することができます。
2. これで、サーチを実⾏する際に、サーチコマンドにインデックスを指定する必要がなくなります。デフォルトで
Splunk Enterprise は「main」インデックスをサーチします。
データ損失を防⽌するための persistent queue の使⽤
persistent queue を使⽤することで、⼊⼒キュー内のデータをディスクに保管することができます。そうする
ことで、フォワーダー やインデクサー をバックアップする場合に、データの損失の防⽌に役⽴ちます。
デフォルトで、フォワーダーとインデクサーは、メモリー内に 500KB の⼊⼒キューを確保しています。⼊⼒スト
リームがフォワーダー/インデクサーの処理限度を超え、キューが⼀杯になった場合、望ましくない事態が発⽣し
てしまいます。UDP の場合は、データがキューから破棄されて、失われてしまいます。他の⼊⼒タイプの場合、
データを⽣成しているアプリケーションがバックアップされます。
persistent queue を採⽤することで、このような問題の発⽣を防⽌することができます。persistent queue を使
⽤すると、メモリー内のキューが⼀杯になった場合、⼊⼒ストリームはディスク上のファイルに書き込まれます。
次に、データストリームを直接処理できるようになるまでの間、キューからのデータ (メモリー内とディスク上の
両⽅) が処理されます。
重要： persistent queue は、Splunk Enterprise がバックアップされた場合のデータ損失を防⽌するために役⽴
ちます。ただし、完全な解決策とはなりません。Splunk Enterprise がクラッシュした場合は、データが失われる
可能性があります。たとえば、⼊⼒データの⼀部をメモリー内キュー、および persistent queue ファイルに保管
している場合を考えてみましょう。クラッシュが発⽣した場合、メモリー内のデータは失われてしまいます。同様
に、パーシングまたはインデックス作成パイプライン内にあり、まだディスクに書き込まれていないデータも、ク
ラッシュ時に失われてしまう可能性があります。
注意： Splunk Enterprise 4.2 以降では、persistent queue が⼤幅に改良されて再実装されました。これはデー
タ⼊⼒ (取り込み) の機能となり、inputs.conf で設定を⾏います。従来の outputs.conf で設定する、廃⽌予定の
persistent queue 機能とは何の関連もなくなりました 。
persistent queue を使⽤できる場合
persistent queue は、特定のタイプの⼊⼒に対して利⽤できます。すべてのタイプで利⽤できる訳ではありませ
ん。⼀般的にこのキューは、ネットワーク⼊⼒などの短期的な性質を持つ⼊⼒に対して利⽤できます。ファイルの
モニタリングなどの、継続的な性質がある⼊⼒には利⽤できません。
persistent queue は、以下の⼊⼒タイプで使⽤できます。
TCP
UDP
149
FIFO
スクリプト⼊⼒
Windows イベントログ⼊⼒
persistent queue は、以下の⼊⼒タイプでは使⽤できません。
モニター
バッチ
ファイルシステム変更監視
splunktcp (Splunk フォワーダーからの⼊⼒)
persistent queue の設定
persistent queue を設定するには、inputs.conf ファイルを使⽤します。
複数の⼊⼒がキューを共有することはありません。persistent queue は、特定の⼊⼒のスタンザ内に設定しま
す。
構⽂
persistent queue を作成するには、特定の⼊⼒のスタンザ内に、以下の 2 つの属性を指定します。
persistentQueueSize = <integer>(KB|MB|GB|TB)
* Max size of the persistent queue file on disk.
* Defaults to 0 (no persistent queue).
例
TCP ⼊⼒への persistent queue の設定例を以下に⽰します。
[tcp://9994]
persistentQueueSize=100MB
persistent queue の場所
persistent queue はハードコード化された場所を持ち、⼊⼒タイプによって異なります。
ネットワーク⼊⼒の場合、persistent queue は以下の場所にあります。
$SPLUNK_HOME/var/run/splunk/[tcpin|udpin]/pq__<port>
注意： ファイル名には 2 つのアンダースコアが使⽤されています。pq__<port>で、pq_<port> ではありません。
例：
TCP ポート 2012 の persistent queue：
UDP ポート 2012 の persistent queue：
FIFO ⼊⼒の場合、persistent queue は
$SPLUNK_HOME/var/run/splunk/tcpin/pq__2012
$SPLUNK_HOME/var/run/splunk/udpin/pq__2012
$SPLUNK_HOME/var/run/splunk/fifoin/<encoded path>
スクリプト⼊⼒の場合は、$SPLUNK_HOME/var/run/splunk/exec/<encoded
FIFO/スクリプト⼊⼒スタンザは、<encoded path> を取得します。
path>
下に保管されます。
下に保管されます。inputs.conf 内の
⼊⼒プロセスのトラブルシューティング
⽬的のイベントが⾒つかりませんか？
Splunk Enterprise にデータ⼊⼒を追加する場合、そのデータ⼊⼒は使⽤している App に対して追加されます。
*nix および Windows App など⼀部の App は、⼊⼒から取り込まれたデータを特定のインデックスに書き込みま
す (*nix および Windows App の場合は、「os」インデックス)。Splunk Enterprise に取り込んだはずのデータ
が⾒つからない場合は、適切なインデックスを使⽤しているかどうかを確認してください。使⽤しているロールに
対して、デフォルトインデックスのリストに「os」インデックスを追加することもできます。ロールの詳細は、
『Splunk Enterprise のセキュリティ』のロールに関するトピックを参照してください。
注意： inputs.conf を編集して⼊⼒を追加した場合、Splunk Enterprise がそれを即座には認識できない可能性が
あります。Splunk Enterprise は前回再起動された時点から、24 時間ごとに⼊⼒を確認します。つまり、ディレ
クトリやファイルをモニターするスタンザを新たに追加した場合、Splunk Enterprise がそのディレクトリまたは
ファイルの内容のインデックス作成を開始するまでに、最⾼で 24 時間かかることを意味しています。⼊⼒が即座
に認識され、インデックス作成が開始されるようにするには、Splunk Web を使⽤するか、または CLI で add コ
マンドを使って、⼊⼒を追加してください。
tail が実⾏されたファイルのトラブルシューティング
FileStatus
REST エンドポイントを使って、tail が実⾏されたファイルのステータスを取得することができます。
150
例：
curl https://serverhost:8089/services/admin/inputstatus/TailingProcessor:FileStatus
モニター⼊⼒のトラブルシューティング
モニター⼊⼒の問題に対処するためのさまざまな情報については、コミュニティ Wiki の「Troubleshooting
Monitor Inputs」を参照してください。
フォワーダーから送られてくるデータが⾒つからない場合
フォワーダーが正常に機能しており、インデクサーから⾒えることを確認してください。デプロイモニター App
を使って、Splunk トポロジーのトラブルシューティングを⾏って、フォワーダーに関する問題の主原因を調査す
ることができます。詳細は、『Deploy and Use Splunk Deployment Monitor App』マニュアルを参照してくだ
さい。
レシピ
フォワーダー
フォワーダーの⼊⼒の設定は、インデクサーでの設定と同じ⽅法で⾏えます。唯⼀の違いが、フォワーダーには
Splunk Web が含まれていないため、⼊⼒を CLI または inputs.conf を使って設定する必要があることです。⼊⼒
を設定する前に、このレシピで説明するように、フォワーダーをデプロイ、設定する必要があります。
Splunk のフォワーダー を使って、レシーバー と呼ばれるインデクサーにデータを送信することができます。こ
れが、リモート・データをインデクサーに取り込むために推奨する⽅法です。
フォワーダー、特にユニバーサルフォワーダーを使⽤してリモートデータを取り込む場合、フォワーダーとレシー
バーのトポロジーを構築して、データ⼊⼒を設定する必要があります。
1. Splunk Enterprise インスタンスをレシーバーとしてインストールします。『インストール・マニュアル』を参
照してください。
2. Splunk Web または CLI を使って、これらのインスタンスの受信を有効にします。『データの転送』マニュア
ルの「レシーバーを有効にする」を参照してください。
3. 受信側 Splunk Enterprise インスタンスのいずれかを、デプロイ・サーバーとして設定します。詳細は、
『Splunk Enterprise インスタンスの更新』マニュアルの「デプロイのプランニング」を参照してください。
4. App を $SPLUNK_HOME/etc/deployment_apps ディレクトリに保管して、デプロイ・サーバーに最低 1 つの App をデ
プロイします。詳細は、『Splunk Enterprise インスタンスの更新』マニュアルの「デプロイ App の作成」を参
照してください。
5. フォワーダーをインストール、設定、デプロイします。設定中：
受信側インデクサーを指定します。*nix および Windows での⽅法を参照してください。
デプロイサーバーを指定します。
注意： 転送ニーズに応じて、さまざまなデプロイのベスト・プラクティスが存在しています。詳細は、『データ
の転送』マニュアルの「ユニバーサル・フォワーダーのデプロイの概要」を参照してください。これらのシナリオ
の⼀部では、インストール時にフォワーダーを設定することができます。
6. 各ユニバーサル・フォワーダーへのデータ⼊⼒設定のデプロイには、フォワーダー管理機能を使⽤します。この
マニュアルの「データの転送」を参照してください。
7. テストを⾏って、転送やロード・バランシング、フィルタリングなどの、他の設定した動作が、⽬的通りに動作
することを確認します。結果データをサーチするには、レシーバーに移動します。
フォワーダーの詳細は、『データの転送』マニュアルの「転送と受信について」を参照してください。また、この
マニュアルの「フォワーダーを使ったデータの取り込み」も参照してください。
ファイルとディレクトリ - ローカル
Splunk Enterprise は、ファイルとディレクトリのイベントをモニターすることができます。システムがイベント
を⽣成したら、Splunk Enterprise がそれのインデックスを作成して、サーチ、レポート、およびアラートを作
成、実⾏することができます。
ファイルやディレクトリから Splunk Enterprise にデータを取り込むには：
A. [新規追加] ページに移動
⼊⼒ (データの取り込み) は、Splunk Web の [新規追加] ページから追加します。2 種類の⽅法でこのページを表
⽰できます。
Splunk ホーム
Splunk 設定
Splunk 設定を使⽤する場合：
151
1. Splunk Web の右上にある [設定] をクリックします。
2. [設定] ポップアップの [データ] セクションで、[データ⼊⼒] をクリックします。
3. [ファイルとディレクトリ] をクリックします。
4. [新規] ボタンをクリックして、⼊⼒を追加します。
Splunk ホームを使⽤する場合：
1. Splunk ホームの [データの追加] リンクをクリックします。
2. ファイルをアップロードするには [アップロード] を、ファイルをモニターするには [モニター] を、ファイル
を転送するには [転送] をクリックします。
注意： ファイルの転送には、追加設定が必要です。このマニュアルの「データの転送」を参照してください。
B. ⼊⼒ソースの選択
1. ファイルまたはディレクトリ⼊⼒を追加するには、[ファイルとディレクトリ] をクリックします。
2. [ファイルまたはディレクトリ] フィールドで、ファイルまたはディレクトリへのフルパスを指定します。
共有ネットワークドライブをモニターするには、次のように⼊⼒します：<myhost>/<mypath>(Windows の場合は
\\<myhost>\<mypath>)。Splunk Enterprise に、マウントされたドライブ、およびモニター対象ファイルに対する読
み取り権限があることを確認してください。
3. Splunk Enterprise によるファイルのモニター⽅法を選択します。
継続モニター ：継続的なデータ取り込み (⼊⼒) を設定します。Splunk Enterprise はファイルの新しい
データを継続的にモニターします。このオプションの詳細設定については、次のセクションを参照してくだ
さい。
1 回インデックスを作成 ：サーバーから Splunk Enterprise に、ファイルをコピーします。
4. 緑⾊の [次へ] ボタンをクリックします。
[ファイルまたはディレクトリ] フィールドでディレクトリを指定した場合、画⾯が更新され [ホワイトリス
ト] および [ブラックリスト] フィールドが表⽰されます。これらのフィールドには、Splunk Enterprise が
含める (ホワイトリスト) または除外する (ブラックリスト) ファイルを照合するために使⽤する正規表現を
指定できます。「ホワイトリストまたはブラックリスト固有の到着データ」を参照してください。
それ以外の場合は、データのプレビューを⾏えます。
C. データのプレビューとそのソースタイプの設定
新しいファイル⼊⼒を追加する場合、データのソースタイプ を設定して、それがインデックス作成後にどのよう
に表⽰されるかを設定します。そうすることにより、データが適切にフォーマットされ、必要な調整が⾏われるこ
とが保証されます。
[ソースタイプの設定] ページについては、「[ソースタイプの設定] ページ」を参照してください。
ページの使⽤⽅法については、「イベント・データのソースタイプの表⽰と設定」を参照してください。
データ・プレビューをスキップすることを選択すると、[⼊⼒設定] ページが表⽰されます。
注意： Splunk Enterprise では、ディレクトリやアーカイブされたファイルのプレビューを表⽰できません。
D. ⼊⼒設定の指定
[⼊⼒設定] ページでは、アプリケーション・コンテキスト、デフォルトのホスト値、およびインデックスを指定
できます。これらのパラメータは省略することができます。
1. この⼊⼒の適切なアプリケーション・コンテキスト を選択します。
2. ホスト 名の値を設定します。さまざまな選択肢があります。ホスト値の設定の詳細は、「ホストについて」を
参照してください。
注意： [ホスト] は、イベントの host フィールドの設定のみを⾏います。Splunk Enterprise にネットワー
ク上の特定のホストを探すように指⽰するものではありません。
3. この⼊⼒のデータを保管するインデックス を設定します。複数のインデックスを定義しており、それらの中の
1 つを使⽤する場合を除き、この値は「default」のままにしてください。ユーザーデータ⽤のインデックスに加
えて、Splunk Enterprise にはさまざまなユーティリティインデックスが存在しています。これらのインデックス
も、このドロップダウンボックスに表⽰されます。
4. 緑⾊の [確認] ボタンをクリックします。
E. 選択項⽬の確認
⼊⼒設定をすべて指定したら、選択内容をレビューすることができます。Splunk Enterprise には、モニターのタ
イプ、ソース、ソースタイプ、アプリケーション・コンテキスト、インデックスなど (これ以外が表⽰されること
もあります) の、選択したオプションが表⽰されます。
設定を確認します。意図通りの内容でない場合は、バナーの⽩い [< ] ボタンをクリックして、ウィザードの前のス
152
テップに戻ります。そうでない場合は、緑⾊の [送信] ボタンをクリックします。
[成功] ページが表⽰され、指定されたファイルまたはディレクトリのインデックス作成が開始されます。
ファイルやディレクトリからのデータの取り込みの詳細は、このマニュアルの「ファイルとディレクトリのモニ
ター」を参照してください。
ファイルとディレクトリ - リモート
リモート・マシンから Splunk Enterprise にログを取り込むもっとも簡単な⽅法は、ユニバーサル・フォワー
ダー を使⽤することです。フォワーダーは、データを⽣成しているマシン上にインストールして、インデクサー
にデータを送信するように設定します。フォワーダーはデータを取得して、イベントをインデクサーに転送しま
す。インデクサーはイベントを処理、保管して、サーチで利⽤できるようにします。
これには、2 つのステップがあります。
1. リモートマシン上にフォワーダーを設定し、データの転送先となるインデクサーを設定します。「フォワー
ダー」のレシピを参照してください。
2. データをモニターするように、フォワーダーの⼊⼒を設定します。この作業は、インデクサー上にデータがある
場合と同様です。ただし、フォワーダーには Splunk Web がないため、⼊⼒の設定には CLI を使⽤するか、また
は inputs.conf を直接編集する必要があります。
ファイルをモニターするための⼊⼒の設定については、このマニュアルの「ファイルとディレクトリのモニ
ター」を参照してください。
フォワーダーの設定に関するその他の情報は、このマニュアルの「フォワーダーを使ったデータの取り込
み」を参照してください。
Syslog - TCP/UDP
Splunk Enterprise は TCP/UDP ポートで、1 つまたは複数のマシンの syslog サービスから送られてくるデータ
を待ち受けることができます。これらのホストからの syslog データを収集して、⼿軽にサーチ、レポート、およ
びアラートを利⽤することができます。
TCP または UDP 経由で syslog データを取得するには、syslog データが到着するネットワークポートで待機す
るように、Splunk Enterprise を設定します。
A. [新規追加] ページに移動
ネットワーク⼊⼒は、Splunk Web の [データの追加] ページから追加します。このマニュアルの「データの追加
⽅法は？」を参照してください。
2 種類の⽅法でこのページを表⽰できます。
Splunk ホーム
Splunk 設定
Splunk 設定を使⽤する場合：
1. Splunk Web の右上にある [設定] をクリックします。
2. [設定] ポップアップの [データ] セクションで、[データ⼊⼒] をクリックします。
3. [TCP] または [UDP] を選択します。
4. [新規] ボタンをクリックして、⼊⼒を追加します。
Splunk ホームを使⽤する場合：
1. Splunk ホームの [データの追加] リンクをクリックします。
'2.ローカル・マシンのネットワーク・ポートをモニターするには、 [モニター] を、または 他のマシンから
ネットワーク・データを受け取る場合は [転送] をクリックします。
注意： ファイルの転送には、追加設定が必要です。
3. [転送] を選択した場合、この⼊⼒を適⽤するフォワーダーのグループを選択または作成します。このマニュア
ルの「データの転送」を参照してください。
'4.緑⾊ の [次へ] ボタンをクリックします。
B. ネットワーク⼊⼒の指定
1. 左パネルで、[TCP / UDP] をクリックして、⼊⼒を追加します。
2. TCP または UDP ⼊⼒を選択するには、[TCP] または [UDP] ボタンをクリックします。
2. [ポート] フィールドにポート番号を⼊⼒します。
注意： Splunk Enterprise を実⾏するユーザーには、ポートへのアクセス権が必要です。ストック UNIXシステ
ムで 1024 未満のポートで待ち受ける場合、Splunk Enterprise を root として実⾏する必要があります。
153
3. 必要に応じて、[ソース名上書き] フィールドに、デフォルト値に優先する新たなソース名を⼊⼒します。
重要： この値を変更する前に、Splunk サポートにお問い合わせください。
4. TCP ⼊⼒の場合 [次からの接続のみを受け付け] フィールドで、ポートがすべてのホストからの接続を受け付
けるか、または 1 台のホストからの接続を受け付けるかを指定することができます。
1 台のホストからの接続のみを受け付ける場合は、そのホストのホスト名または IP アドレスを指定しま
す。ワイルドカードを使⽤して、複数のホストを指定できます。
5. [次へ] をクリックして、[⼊⼒設定] ページで作業を続⾏します。
C. ⼊⼒の設定
[⼊⼒設定] ページでは、ソースタイプ、アプリケーション・コンテキスト、デフォルトのホスト値、およびイン
デックスを指定できます。これらのパラメータは省略することができます。
1. [ソースタイプ] を設定します。これは、イベントに追加されるデフォルトのフィールドです。ソースタイプ
は、タイムスタンプやイベント境界などの、処理する特徴の決定に⽤いられます。Splunk の⾃動ソースタイプ設
定に優先する設定を⾏うには、このマニュアルの「ソースタイプの⾃動割り当てに優先する設定」を参照してくだ
さい。
2. ホスト 名の値を設定します。さまざまな選択肢があります。
IP： ⼊⼒プロセッサが、リモートサーバーの IP アドレスでホストを再書き込みするように設定します。
DNS： ホスト名にリモートサーバーの DNS エントリを設定します。
カスタム： ホストにユーザー定義ラベルを設定します。
ホスト値の設定の詳細は、「ホストについて」を参照してください。
注意： [ホスト] は、イベントの host フィールドの設定のみを⾏います。Splunk Enterprise にネットワー
ク上の特定のホストを探すように指⽰するものではありません。
3. この⼊⼒のデータを保管するインデックス を設定します。異なる種類のイベントを取り扱うために、複数のイ
ンデックスを定義している場合を除き、この値は「default」のままにしてください。ユーザーデータ⽤のイン
デックスに加えて、Splunk Enterprise にはさまざまなユーティリティインデックスが存在しています。これらの
インデックスも、このドロップダウンボックスに表⽰されます。
4. 緑⾊の [確認] ボタンをクリックします。
D. 選択項⽬の確認
⼊⼒設定をすべて指定したら、選択内容をレビューすることができます。Splunk Enterprise には、モニターのタ
イプ、ソース、ソースタイプ、アプリケーション・コンテキスト、インデックスなど (これ以外が表⽰されること
もあります) の、選択したオプションが表⽰されます。
設定を確認します。意図通りの内容でない場合は、灰⾊の [< ] ボタンをクリックして、ウィザードの前のステップ
に戻ります。そうでない場合は、緑⾊の [送信] ボタンをクリックします。
[成功] ページが表⽰され、指定されたネットワーク⼊⼒のインデックス作成が開始されます。
ネットワークからのデータの取得の詳細は、このマニュアルの「TCP および UDP ポートからのデータの取得」
を参照してください。
Windows イベントログ - ローカル
Splunk Enterprise はローカル Windows のイベント・ログを収集できます。この⼊⼒を使って、セキュリティに
関するアラートを⽣成したり、Windows システムの状態を判断するために特定のイベント ID をサーチしたりす
ることができます。
ローカルイベントログデータを取得するには、イベントログサービスを指定します。
A. [新規追加] ページに移動
Windows イベント・ログ⼊⼒は、Splunk Web の [新規追加] ページから追加します。このマニュアルの「データ
の追加⽅法は？」を参照してください。
2 種類の⽅法でこのページを表⽰できます。
Splunk ホーム
Splunk 設定
Splunk 設定を使⽤する場合：
1. Splunk Web の右上にある [設定] をクリックします。
2. [設定] ポップアップの [データ] セクションで、[データ⼊⼒] をクリックします。
3. [ローカル・イベント・ログの収集] をクリックします。
4. [新規] ボタンをクリックして、⼊⼒を追加します。
154
Splunk ホームを使⽤する場合：
1. Splunk ホームの [データの追加] リンクをクリックします。
2. ローカル Windows マシンのイベント・ログ・データをモニターするには、[モニター] をクリックします。他
の Windows マシンからイベント・ログ・データを転送するには、[転送] をクリックします。[データの追加 ソースの選択] ページが表⽰されます。
3. [転送] を選択した場合、この⼊⼒を適⽤するフォワーダーのグループを選択または作成します。このマニュア
ルの「データの転送」を参照してください。
4. 緑⾊の [次へ] ボタンをクリックします。
B. ⼊⼒ソースの選択
1. 左側のパネルで、[ローカル・イベント・ログ] を探して選択します。
2. [イベント・ログの選択] リスト・ボックスで、この⼊⼒でモニターするイベント・ログ・チャネルを探しま
す。
3. モニターする各イベント・ログ・チャネルを、それぞれ 1 回クリックします。Splunk Enterprise は、チャネ
ルを [利⽤可能な項⽬] ウィンドウから [選択項⽬] ウィンドウに移動します。
4. チャネルの選択を解除するには、[選択項⽬] ウィンドウでその名前をクリックします。Splunk Enterprise は、
チャネルを [選択項⽬] ウィンドウから [利⽤可能な項⽬] ウィンドウに移動します。
5. すべてのイベント・ログを選択/選択解除するには、[すべて追加] または [すべて削除] リンクをクリックしま
す。重要： すべてのチャネルを選択すると⼤量のデータのインデックスを作成することになり、ライセンスの上
限を超えてしまう可能性があります。
6. 緑⾊の [次へ] ボタンをクリックします。
C. ⼊⼒の設定
[⼊⼒設定] ページでは、アプリケーション・コンテキスト、デフォルトのホスト値、およびインデックスを指定
できます。これらのパラメータは省略することができます。
1. この⼊⼒の適切なアプリケーション・コンテキスト を選択します。
2. ホスト 名の値を設定します。さまざまな選択肢があります。ホスト値の設定の詳細は、「ホストについて」を
参照してください。
注意： [ホスト] は、イベントの host フィールドの設定のみを⾏います。Splunk Enterprise にネットワー
ク上の特定のホストを探すように指⽰するものではありません。
3. データを保管するインデックス を設定します。異なる種類のイベントを取り扱うために、複数のインデックス
を定義している場合を除き、この値は「default」のままにしてください。ユーザーデータ⽤のインデックスに加
えて、Splunk Enterprise にはさまざまなユーティリティインデックスが存在しています。これらのインデックス
も、このドロップダウンボックスに表⽰されます。
4. 緑⾊の [確認] ボタンをクリックします。
D. 選択項⽬の確認
⼊⼒設定をすべて指定したら、選択内容をレビューすることができます。Splunk Enterprise には、モニターのタ
イプ、ソース、ソースタイプ、アプリケーション・コンテキスト、インデックスなど (これ以外が表⽰されること
もあります) の、選択したオプションが表⽰されます。
設定を確認します。意図通りの内容でない場合は、⽩い [< ] ボタンをクリックして、ウィザードの前のステップに
戻ります。そうでない場合は、緑⾊の [送信] ボタンをクリックします。
[成功] ページが表⽰され、指定されたイベント・ログ・チャネルのインデックス作成が開始されます。
Windows イベント・ログ・データの取得の詳細は、『データの取り込み』マニュアルの「Windows イベント・
ログ・データの監視」を参照してください。
Windows イベントログ - リモート
Splunk Enterprise は Windows イベント・ログをローカルに、または WMI 経由でリモートにモニターすること
ができます。この⼊⼒を使って、セキュリティに関するアラートを⽣成したり、Windows システムの状態を判断
するために特定のイベント ID をサーチしたりすることができます。
重要： Windows イベント・ログをリモートに収集するには、リモート Windows マシンにアクセスするための適
切な権限があるユーザーとして、Splunk インスタンスをインストールする必要があります。このマニュアルの
「リモート Windows データのモニター⽅法決定の検討事項」を参照してください。
リモート Windows イベント・ログ・データを取得するには、リモート Windows マシンの Splunk Enterprise
インスタンスを指定します。
A. [新規追加] ページに移動
155
⼊⼒ (データの取り込み) は、Splunk Web の [新規追加] ページから追加します。このマニュアルの「 データの
追加⽅法は？ 」 を参照してください。
2 種類の⽅法でこのページを表⽰できます。
Splunk ホーム
Splunk 設定
Splunk 設定を使⽤する場合：
1. Splunk Web の右上にある [設定] をクリックします。
2. [設定] ポップアップの [データ] セクションで、[データ⼊⼒] をクリックします。
3. [リモートイベントログの収集] をクリックします。
4. [新規] ボタンをクリックして、⼊⼒を追加します。
Splunk ホームを使⽤する場合：
1. Splunk ホームの [データの追加] リンクをクリックします。
2. リモート Windows マシンのイベント・ログ・データをモニターするには、[モニター] をクリックします。
B. ⼊⼒ソースの選択
1. 左側のパネルで、[リモート・イベント・ログ] を探して選択します。
2. [イベント・ログ・コレクション名] フィールドに、この⼊⼒の覚えやすい⼀意の名前を⼊⼒します。
3. [このホストからログを選択] フィールドに、モニター対象イベント・ログ・チャネルを持つマシンの、ホスト
名または IP アドレスを⼊⼒します。
4. [ログの検索] ボタンをクリックして、指定したサーバー上の利⽤可能なイベント・ログ・チャネルのリストを
持つページを更新します。
5. モニターする各イベント・ログ・チャネルを、それぞれ 1 回クリックします。Splunk Enterprise は、チャネ
ルを [利⽤可能な項⽬] ウィンドウから [選択項⽬] ウィンドウに移動します。
6. チャネルの選択を解除するには、[選択項⽬] ウィンドウでその名前をクリックします。Splunk Enterprise は、
チャネルを [選択項⽬] ウィンドウから [利⽤可能な項⽬] ウィンドウに移動します。
7. すべてのイベント・ログを選択/選択解除するには、[すべて追加] または [すべて削除] リンクをクリックしま
す。重要： すべてのチャネルを選択すると⼤量のデータのインデックスを作成することになり、ライセンスの上
限を超えてしまう可能性があります。
8. [他のホストから同じセットのログを収集] フィールドに、前に選択したイベント・ログを持つ、その他のマ
シンのホスト名または IP アドレスを⼊⼒します。複数のホストはカンマで区切ります。
9. 緑⾊の [次へ] ボタンをクリックします。
C. ⼊⼒の設定
[⼊⼒設定] ページでは、アプリケーション・コンテキスト、デフォルトのホスト値、およびインデックスを指定
できます。これらのパラメータは省略することができます。
1. この⼊⼒の適切なアプリケーション・コンテキスト を選択します。
2. ホスト 名の値を設定します。さまざまな選択肢があります。ホスト値の設定の詳細は、「ホストについて」を
参照してください。
注意： [ホスト] は、イベントの host フィールドの設定のみを⾏います。Splunk Enterprise にネットワー
ク上の特定のホストを探すように指⽰するものではありません。
3. データを保管するインデックス を設定します。異なる種類のイベントを取り扱うために、複数のインデックス
を定義している場合を除き、この値は「default」のままにしてください。ユーザーデータ⽤のインデックスに加
えて、Splunk Enterprise にはさまざまなユーティリティインデックスが存在しています。これらのインデックス
も、このドロップダウンボックスに表⽰されます。
4. 緑⾊の [確認] ボタンをクリックします。
D. 選択項⽬の確認
⼊⼒設定をすべて指定したら、選択内容をレビューすることができます。Splunk Enterprise には、モニターのタ
イプ、ソース、ソースタイプ、アプリケーション・コンテキスト、インデックスなど (これ以外が表⽰されること
もあります) の、選択したオプションが表⽰されます。
設定を確認します。意図通りの内容でない場合は、⽩い [< ] ボタンをクリックして、ウィザードの前のステップに
戻ります。そうでない場合は、緑⾊の [送信] ボタンをクリックします。
[成功] ページが表⽰され、指定されたイベント・ログ・チャネルのインデックス作成が開始されます。
Windows イベントログからのデータの取り込みの詳細は、このマニュアルの「Windows イベントログデータの
モニター」を参照してください。
156
Windows レジストリ - ローカル
Windows マシンのレジストリの変更をモニターすることができます。ハイブ全体をモニターする場合でも、1 つ
のキーのみをモニターする場合でも、Splunk Enterprise のレジストリ・モニタリング・サービスはそれらのデー
タを収集して、それに対してサーチ、レポート、アラートを実⾏することができます。
ローカル Windows のレジストリ変更データを収集するには、Splunk Enterprise をレジストリに接続します。
A. [新規追加] ページに移動
⼊⼒ (データの取り込み) は、Splunk Web の [新規追加] ページから追加します。「データの追加⽅法は？」を参
照してください。
2 種類の⽅法でこのページを表⽰できます。
Splunk ホーム
Splunk 設定
Splunk 設定を使⽤する場合：
1. Splunk Web の右上にある [設定] をクリックします。
2. [設定] ポップアップの [データ] セクションで、[データ⼊⼒] をクリックします。
3. [レジストリ監視] をクリックします。
4. [新規] ボタンをクリックして、⼊⼒を追加します。
Splunk ホームを使⽤する場合：
1. Splunk ホームの [データの追加] リンクをクリックします。
2. ローカル Windows マシンのレジストリ・データをモニターするには、[モニター] をクリックします。
B. ⼊⼒ソースの選択
1. 左側のパネルで、[レジストリ監視] を探して選択します。
2. [コレクション名] フィールドに、この⼊⼒の覚えやすい⼀意の名前を⼊⼒します。
3. [レジストリハイブ] フィールドに、モニターするレジストリキーへのパスを⼊⼒します。
4. パスが分からない場合は、[参照] ボタンをクリックして、モニターするレジストリキーのパスを選択します。
[レジストリハイブ] ウィンドウに、レジストリがツリービューで表⽰されます。ハイブ、キー、およびサブキー
はフォルダで表され、値はドキュメントアイコンで表されます。
注意： HKEY_USERS, HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE, および HKEY_CURRENT_CONFIG ハイブは、トップレベルのオ
ブジェクトとして表⽰されます。HKEY_CLASSES_ROOT ハイブは、そのハイブの最初のサブレベルに存在しているサブ
キー数のため、表⽰されません。HKEY_CLASSES_ROOT の項⽬にアクセスするには、HKEY_LOCAL_MACHINE\Software\Classes
を選択します。
5. [レジストリハイブ] ウィンドウで、キー名をクリックして⽬的のレジストリキーを選択します。
キーの修飾名は、ウィンドウ下部にある [修飾名] フィールドに表⽰されます。
6. [選択] をクリックして、選択内容を確認してウィンドウを閉じます。
7. 開始ハイブ下の⼦ノードもモニターする場合は、[サブノードをモニター] を選択します。
注意： [サブノードをモニター] ノードは、Splunk Web でレジストリ・モニター⼊⼒を定義する際に作成され
た、inputs.conf ファイルに追加する項⽬を⽰します。
モニターするキーまたはハイブの選択にツリー・ビューを使⽤し、[サブノードをモニター] を選択した場合、
Splunk Enterprise は正規表現 を、定義している⼊⼒のスタンザに追加します。正規表現 (\\\\?.*) は、選択した
キーまたはそのサブキーを直接参照しないイベントをフィルタリングします。
[サブノードをモニター] を選択しない場合、Splunk Enterprise は選択したキーを直接参照しないイベントを
フィルタリングする⼊⼒スタンザに、正規表現が追加されます (選択したキーのサブキーを参照するイベントを含
む)。
モニターするキーの指定にツリー・ビューを使⽤しない場合は、[サブノードをモニター] を選択し、[レジスト
リ・ハイブ] に独⾃の正規表現を⼊⼒していない場合にのみ、正規表現が追加されます。
8. [イベントタイプ] で、選択したレジストリハイブに対してモニターするレジストリイベントタイプを選択しま
す。
イベント
タイプ
Set
説明
Splunk Enterprise は、プログラムがレジストリサブキーに SetValue メソッドを実⾏した場合に、
157
Set
Set イベントを⽣成し、既存のレジストリエントリの値の設定または上書きを⾏います。
Create
Splunk Enterprise は、レジストリハイブ内でプログラムが CreateSubKey メソッドを実⾏した場
合に Create イベントを⽣成し、既存のレジストリハイブ内に新たなサブキーを作成します。
Delete
Splunk Enterprise は、プログラムが DeleteValue または DeleteSubKey メソッドを実⾏した場合
に、Delete イベントを⽣成します。この⽅法は、特定の既存のキーの値を削除するか、または既存
のハイブからキーを削除します。
Rename Splunk Enterprise は RegEdit でレジストリキーまたはサブキーの名前を変更した場合、Rename
イベントを⽣成します。
Open
Splunk Enterprise は、プログラムがレジストリサブキー上で OpenSubKey メソッドを実⾏した場
合に、Open イベントを⽣成します (レジストリに含まれている設定情報をプログラムが必要とする
場合の処理など)。
Close
Splunk Enterprise はプログラムがレジストリキーで Close メソッドを実⾏した場合に、Close イ
ベントを⽣成します。これは、プログラムがキーのコンテンツの読み取りを完了した場合、または
RegEdit でキーの値を変更した後に、値⼊⼒ウィンドウを終了した場合に発⽣します。
Query
Splunk Enterprise はプログラムがレジストリサブキーで GetValue メソッドを実⾏した場合に、
Query イベントを⽣成します。
9. [プロセス・パス] フィールドに適切な値を⼊⼒して、Splunk Enterprise がレジストリをモニターするプロセ
スを Splunk に指⽰します。または、すべてのプロセスをモニターする場合は、デフォルトの C:\.* を使⽤しま
す。
10. レジストリ変更のモニタリングを開始する前に、レジストリ全体のベースラインスナップショットを取得する
かどうかを指定します。ベースラインを設定するには、[ベースラインインデックス] で [はい] をクリックしま
す。
注意： ベースラインスナップショットは、スナップショット取得時のレジストリ全体のインデックスです。ベー
スラインインデックスを設定するためのレジストリのスキャンは、CPU を消費するためある程度時間がかること
があります。
11. 緑⾊の [次へ] ボタンをクリックします。
C. ⼊⼒の設定
[⼊⼒設定] ページでは、アプリケーション・コンテキスト、デフォルトのホスト値、およびインデックスを指定
できます。これらのパラメータは省略することができます。
1. この⼊⼒の適切なアプリケーション・コンテキスト を選択します。
2. ホスト 名の値を設定します。さまざまな選択肢があります。ホスト値の設定の詳細は、「ホストについて」を
参照してください。
注意： [ホスト] は、イベントの host フィールドの設定のみを⾏います。Splunk Enterprise にネットワー
ク上の特定のホストを探すように指⽰するものではありません。
3. データを保管するインデックス を設定します。異なる種類のイベントを取り扱うために、複数のインデックス
を定義している場合を除き、この値は「default」のままにしてください。ユーザーデータ⽤のインデックスに加
えて、Splunk Enterprise にはさまざまなユーティリティインデックスが存在しています。これらのインデックス
も、このドロップダウンボックスに表⽰されます。
4. 緑⾊の [確認] ボタンをクリックします。
D. 選択項⽬の確認
⼊⼒設定をすべて指定したら、選択内容をレビューすることができます。Splunk Enterprise には、モニターのタ
イプ、ソース、ソースタイプ、アプリケーション・コンテキスト、インデックスなど (これ以外が表⽰されること
もあります) の、選択したオプションが表⽰されます。
設定を確認します。意図通りの内容でない場合は、⽩い [< ] ボタンをクリックして、ウィザードの前のステップに
戻ります。そうでない場合は、緑⾊の [送信] ボタンをクリックします。
[成功] ページが表⽰され、指定されたレジストリ・ノードのインデックス作成が開始されます。
警告： レジストリ・モニターの実⾏中は、splunk-regmon.exe プロセスを⼿動で停⽌または kill しないでください。
そうすると、システムが不安定な状態になる可能性があります。レジストリのモニターを停⽌するには、[サービ
ス] コントロールパネルまたは CLI から、splunkd サーバープロセスを停⽌します。
Windows パフォーマンスモニタリング - ローカル
ディスク⼊出⼒、メモリー測定基準 (空きページ数やコミット・チャージなど)、ネットワーク統計情報などを監視
する場合、Splunk Enterprise は Windows パフォーマンス・モニターの代役を⼗分に果たすことが可能です。
Splunk Enterprise でパフォーマンス測定基準を収集するには：
A. [新規追加] ページに移動
⼊⼒ (データの取り込み) は、Splunk Web の [新規追加] ページから追加します。このマニュアルの「データの追
加⽅法は？」を参照してください。
158
2 種類の⽅法でこのページを表⽰できます。
Splunk ホーム
Splunk 設定
Splunk 設定を使⽤する場合：
1. Splunk Web の右上にある [設定] をクリックします。
2. [設定] ポップアップの [データ] セクションで、[データ⼊⼒] をクリックします。
3. [ローカルパフォーマンス監視] をクリックします。
4. [新規] ボタンをクリックして、⼊⼒を追加します。
Splunk ホームを使⽤する場合：
1. Splunk ホームの [データの追加] リンクをクリックします。
'2.ローカル Windows マシンのパフォーマンス・データをモニターするには、[モニター] を、または他のマシン
からパフォーマンス・データを受け取る場合は [転送] をクリックします。
3. [転送] を選択した場合、この⼊⼒を適⽤するフォワーダーのグループを選択または作成します。このマニュア
ルの「データの転送」を参照してください。
4. 緑⾊の [次へ] ボタンをクリックします。
B. ⼊⼒ソースの選択
1. 左側のパネルで、[ローカル・パフォーマンス監視] を探して選択します。
2. [コレクション名] フィールドに、この⼊⼒の覚えやすい⼀意の名前を⼊⼒します。
3. [オブジェクトを選択] ボタンをクリックして、この Windows マシンで利⽤できるパフォーマンス・オブジェ
クトのリストを表⽰し、リストからモニターするオブジェクトを選択します。[カウンタの選択] および [インスタ
ンスの選択] リスト・ボックスが表⽰されます。
注意： データ⼊⼒あたり 1 つのパフォーマンスオブジェクトのみを追加できます。これは、Microsoft によるパ
フォーマンスモニターオブジェクトの取り扱い⽅法によるものです。多くのオブジェクトが、選択時に⾃⼰を動的
に記述するクラスを列挙します。このことは、⼊⼒に定義されている、どのパフォーマンスカウンタやインスタン
スが、どのオブジェクトに所属しているのかを判断するための混乱や妨げになる可能性があります。複数のオブ
ジェクトをモニターする必要がある場合は、各オブジェクトに対して追加のデータ⼊⼒を作成してください。
4. [カウンタの選択] リスト・ボックスで、この⼊⼒でモニターするパフォーマンス・カウンタを探します。
5. モニターする各カウンタを、1 回クリックします。カウンタが [利⽤可能なカウンタ] ウィンドウから [選択され
たカウンタ] ウィンドウに移動します。
6. カウンタの選択を解除するには、[選択されたカウンタ] ウィンドウでその名前をクリックします。カウンタが
[選択されたカウンタ] ウィンドウから [利⽤可能なカウンタ] ウィンドウに移動します。
7. すべてのカウンタを選択/選択解除するには、[すべて追加] または [すべて削除] リンクをクリックします。重
要： すべてのカウンタを選択すると⼤量のデータのインデックスを作成することになり、ライセンスの上限を超
えてしまう可能性があります。
8. [インスタンスの選択] リスト・ボックスで、[利⽤可能なインスタンス] ウィンドウからインスタンスを 1 回ク
リックして、この⼊⼒でモニターするインスタンスを選択します。インスタンスが [選択されたインスタンス]
ウィンドウに移動します。
注意： 「_Total」インスタンスは特殊なインスタンスで、多くのタイプのパフォーマンスカウンタに存在していま
す。このインスタンスは、同じカウンタ下の任意の関連するインスタンスの平均です。このインスタンスで収集さ
れるデータは、同じカウンタ下の個別のインスタンスとは⼤幅に異なっています。
たとえば、2 台のディスクを搭載したシステム上の、「PhysicalDisk」オブジェクト下にある「Disk
Bytes/Sec」パフォーマンス・カウンタのパフォーマンス・データをモニターする場合、表⽰されるインスタンス
には、それぞれの物理ディスク「0 C:」と「1 D:」、そして「_Total」インスタンスが含まれます。この場合、
「_Total」インスタンスが 2 台の物理ディスクインスタンスの平均になります。
9. [ポーリング間隔] フィールドで、⼊⼒のポーリング間隔を秒で指定します。
10. 緑⾊の [次へ] ボタンをクリックします。
C. ⼊⼒の設定
[⼊⼒設定] ページでは、アプリケーション・コンテキスト、デフォルトのホスト値、およびインデックスを指定
できます。これらのパラメータは省略することができます。
1. この⼊⼒の適切なアプリケーション・コンテキスト を選択します。
2. ホスト 名の値を設定します。さまざまな選択肢があります。ホスト値の設定の詳細は、「ホストについて」を
参照してください。
注意： [ホスト] は、イベントの host フィールドの設定のみを⾏います。Splunk Enterprise にネットワー
ク上の特定のホストを探すように指⽰するものではありません。
159
3. データを保管するインデックス を設定します。異なる種類のイベントを取り扱うために、複数のインデックス
を定義している場合を除き、この値は「default」のままにしてください。ユーザーデータ⽤のインデックスに加
えて、Splunk Enterprise にはさまざまなユーティリティインデックスが存在しています。これらのインデックス
も、このドロップダウンボックスに表⽰されます。
4. 緑⾊の [確認] ボタンをクリックします。
D. 選択項⽬の確認
⼊⼒設定をすべて指定したら、選択内容をレビューすることができます。Splunk Enterprise には、モニターのタ
イプ、ソース、ソースタイプ、アプリケーション・コンテキスト、インデックスなど (これ以外が表⽰されること
もあります) の、選択したオプションが表⽰されます。
設定を確認します。意図通りの内容でない場合は、⽩い [< ] ボタンをクリックして、ウィザードの前のステップに
戻ります。そうでない場合は、緑⾊の [送信] ボタンをクリックします。
[成功] ページが表⽰され、指定されたパフォーマンス測定基準のインデックス作成が開始されます。ファイルや
ディレクトリからのデータの取り込みの詳細は、このマニュアルの「リアルタイムの Windows パフォーマンスモ
ニタリング」を参照してください。
Windows パフォーマンスモニタリング - リモート
ディスク⼊出⼒、メモリー測定基準 (空きページ数やコミット・チャージなど)、ネットワーク統計情報などを監視
する場合、Splunk Enterprise は Windows パフォーマンス・モニターの代役を⼗分に果たすことが可能です。
Splunk Enterprise でパフォーマンス測定基準をリモート収集するには：
A. [新規追加] ページに移動
⼊⼒ (データの取り込み) は、Splunk Web の [新規追加] ページから追加します。2 種類の⽅法でこのページを表
⽰できます。
Splunk ホーム
Splunk 設定
どちらの⽅法を使⽤しても構いません。同じ [新規追加] ページが表⽰されます。
Splunk 設定を使⽤する場合：
1. Splunk Web の右上にある [設定] をクリックします。
2. [設定] ポップアップの [データ] セクションで、[データ⼊⼒] をクリックします。
3. [リモートパフォーマンス監視] をクリックします。
4. [新規] ボタンをクリックして、⼊⼒を追加します。
Splunk ホームを使⽤する場合：
1. Splunk ホームの [データの追加] リンクをクリックします。
2. ローカル Windows マシンのパフォーマンス・データをモニターするには、[モニター] をクリックします。他
の Windows マシンからパフォーマンス・データを転送するには、[転送] をクリックします。[データの追加 ソースの選択] ページが表⽰されます。
注意： パフォーマンス・データの転送には、追加設定が必要です。
3. 左側のパネルで、[ローカル・パフォーマンス監視] を探して選択します。
B. ⼊⼒ソースの選択
1. [コレクション名] フィールドに、この⼊⼒の覚えやすい⼀意の名前を⼊⼒します。
2. [ターゲット・ホストの選択] フィールドに、パフォーマンス・データの収集対象となる Windows コンピュー
タのホスト名または IP アドレスを⼊⼒します。
3. [クエリー] ボタンをクリックして、[ターゲット・ホストの選択] フィールドに指定した Windows マシン上で利
⽤できる、パフォーマンス・オブジェクトのリストを表⽰します。
注意： Win32_PerfFormattedData_*クラスは、Splunk Web に利⽤可能なオブジェクトとしては表⽰されませ
ん。Win32_PerfFormattedData_* クラスをモニターしたい場合は、直接 wmi.conf に追加する必要があります。
4. [クラスの選択] リストから、モニター対象オブジェクトを選択します。[カウンタの選択] および [インスタンス
の選択] リスト・ボックスが表⽰されます。
注意： データ⼊⼒あたり 1 つのパフォーマンスオブジェクトのみを追加できます。これは、Microsoft によるパ
フォーマンスモニターオブジェクトの取り扱い⽅法によるものです。多くのオブジェクトが、選択時に⾃⼰を動的
に記述するクラスを列挙します。このことは、⼊⼒に定義されている、どのパフォーマンスカウンタやインスタン
スが、どのオブジェクトに所属しているのかを判断するための混乱や妨げになる可能性があります。複数のオブ
ジェクトをモニターする必要がある場合は、各オブジェクトに対して追加のデータ⼊⼒を作成してください。
5. [カウンタの選択] リスト・ボックスで、この⼊⼒でモニターするパフォーマンス・カウンタを探します。
160
6. モニターする各カウンタを、1 回クリックします。カウンタが [利⽤可能なカウンタ] ウィンドウから [選択され
たカウンタ] ウィンドウに移動します。
7. カウンタの選択を解除するには、[選択されたカウンタ] ウィンドウでその名前をクリックします。カウンタが
[選択されたカウンタ] ウィンドウから [利⽤可能なカウンタ] ウィンドウに移動します。
8. すべてのカウンタを選択/選択解除するには、[すべて追加] または [すべて削除] リンクをクリックします。重
要： すべてのカウンタを選択すると⼤量のデータのインデックスを作成することになり、ライセンスの上限を超
えてしまう可能性があります。
9. [インスタンスの選択] リスト・ボックスで、[利⽤可能なインスタンス] ウィンドウからインスタンスを 1 回ク
リックして、この⼊⼒でモニターするインスタンスを選択します。インスタンスが [選択されたインスタンス]
ウィンドウに移動します。
注意： 「_Total」インスタンスは特殊なインスタンスで、多くのタイプのパフォーマンスカウンタに存在していま
す。このインスタンスは、同じカウンタ下の任意の関連するインスタンスの平均です。このインスタンスで収集さ
れるデータは、同じカウンタ下の個別のインスタンスとは⼤幅に異なっています。
たとえば、2 台のディスクを搭載したシステム上の、「PhysicalDisk」オブジェクト下にある「Disk
Bytes/Sec」パフォーマンス・カウンタのパフォーマンス・データをモニターする場合、表⽰されるインスタンス
には、それぞれの物理ディスク「0 C:」と「1 D:」、そして「_Total」インスタンスが含まれます。この場合、
「_Total」インスタンスが 2 台の物理ディスクインスタンスの平均になります。
10. [ポーリング間隔] フィールドで、⼊⼒のポーリング間隔を秒で指定します。
11. 緑⾊の [次へ] ボタンをクリックします。
C. ⼊⼒の設定
[⼊⼒設定] ページでは、アプリケーション・コンテキスト、デフォルトのホスト値、およびインデックスを指定
できます。これらのパラメータは省略することができます。
1. この⼊⼒の適切なアプリケーション・コンテキスト を選択します。
2. ホスト 名の値を設定します。さまざまな選択肢があります。ホスト値の設定の詳細は、「ホストについて」を
参照してください。
注意： [ホスト] は、イベントの host フィールドの設定のみを⾏います。Splunk Enterprise にネットワー
ク上の特定のホストを探すように指⽰するものではありません。
3. データを保管するインデックス を設定します。異なる種類のイベントを取り扱うために、複数のインデックス
を定義している場合を除き、この値は「default」のままにしてください。ユーザーデータ⽤のインデックスに加
えて、Splunk Enterprise にはさまざまなユーティリティインデックスが存在しています。これらのインデックス
も、このドロップダウンボックスに表⽰されます。
4. 緑⾊の [確認] ボタンをクリックします。
D. 選択項⽬の確認
⼊⼒設定をすべて指定したら、選択内容をレビューすることができます。Splunk Enterprise には、モニターのタ
イプ、ソース、ソースタイプ、アプリケーション・コンテキスト、インデックスなど (これ以外が表⽰されること
もあります) の、選択したオプションが表⽰されます。
設定を確認します。意図通りの内容でない場合は、⽩い [< ] ボタンをクリックして、ウィザードの前のステップに
戻ります。そうでない場合は、緑⾊の [送信] ボタンをクリックします。
[成功] ページが表⽰され、指定されたパフォーマンス測定基準のインデックス作成が開始されます。
リモートマシンからのパフォーマンスモニターデータの取り込みの詳細は、『データの取り込み』マニュアルの
「WMI データのモニター」を参照してください。
Windows Active Directory
Splunk を使って、任意の Active Directory 変更データを収集することができます。
パスワードの変更、ユーザーまたはマシンアカウントの追加、またはグループポリシーオブジェクトへの権限の委
任などを⾏ったユーザーを確認したいと思いませんか？Splunk の Active Directory モニター機能を利⽤すれ
ば、このような情報をすべて⼿軽に収集、確認することができます。さらに、1 台のノードから Active Directory
フォレスト全体まで、変更を監視する Active Directory の部分を⾃由に選択することができます。
注意： Active Directory の任意の部分をモニターするには、Active Directory スキーマに対する読み取りアクセ
ス許可を持つユーザーとして Splunk を実⾏する必要があります。
Active Directory データを収集するには、Splunk Enterprise に Active Directory を指⽰します。
A. [新規追加] ページに移動
⼊⼒ (データの取り込み) は、Splunk Web の [新規追加] ページから追加します。このマニュアルの「データの追
加⽅法は？」を参照してください。
2 種類の⽅法でこのページを表⽰できます。
161
Splunk ホーム
Splunk 設定
Splunk 設定を使⽤する場合：
1. Splunk Web の右上にある [設定] をクリックします。
2. [設定] ポップアップの [データ] セクションで、[データ⼊⼒] をクリックします。
3. [Active Directory モニタリング] をクリックします。
4. [新規] ボタンをクリックして、⼊⼒を追加します。
Splunk ホームを使⽤する場合：
1. Splunk ホームの [データの追加] リンクをクリックします。
2. ローカル Windows マシンの Active Directory をモニターするには、[モニター] をクリックします。
B. ⼊⼒ソースの選択
1. 左側のパネルで、[Active Directory 監視] を探して選択します。
2. [コレクション名] フィールドに、この⼊⼒の覚えやすい⼀意の名前を⼊⼒します。
3. 必要に応じて [ターゲット・ドメイン・コントローラ] フィールドに、Active Directory のモニターに使⽤す
る、ドメイン・コントローラのホスト名または IP アドレスを⼊⼒します。
4. 必要に応じて、[開始ノード] フィールドに、モニターを開始する Active Directory ノードを⼊⼒しま
す。DC=Splunk-Docs,DC=com のように、LDAP 形式で指定する必要があります。
[参照] ボタンをクリックして利⽤可能な Active Directory ノードのリストから、利⽤可能な Active Directory ド
メインを参照、選択することができます。
5. [開始ノード] フィールドに⼊⼒したノードの、すべてのサブノードをモニターする場合は、[サブツリーのモニ
ター] ボタンを選択します。
6. 緑⾊の [次へ] ボタンをクリックします。
C. ⼊⼒の設定
[⼊⼒設定] ページでは、アプリケーション・コンテキスト、デフォルトのホスト値、およびインデックスを指定
できます。これらのパラメータは省略することができます。
1. この⼊⼒の適切なアプリケーション・コンテキスト を選択します。
2. ホスト 名の値を設定します。さまざまな選択肢があります。ホスト値の設定の詳細は、「ホストについて」を
参照してください。
注意： [ホスト] は、イベントの host フィールドの設定のみを⾏います。Splunk Enterprise にネットワー
ク上の特定のホストを探すように指⽰するものではありません。
3. データを保管するインデックス を設定します。異なる種類のイベントを取り扱うために、複数のインデックス
を定義している場合を除き、この値は「default」のままにしてください。ユーザーデータ⽤のインデックスに加
えて、Splunk Enterprise にはさまざまなユーティリティインデックスが存在しています。これらのインデックス
も、このドロップダウンボックスに表⽰されます。
4. 緑⾊の [確認] ボタンをクリックします。
D. 選択項⽬の確認
⼊⼒設定をすべて指定したら、選択内容をレビューすることができます。Splunk Enterprise には、モニターのタ
イプ、ソース、ソースタイプ、アプリケーション・コンテキスト、インデックスなど (これ以外が表⽰されること
もあります) の、選択したオプションが表⽰されます。
設定を確認します。意図通りの内容でない場合は、⽩い [< ] ボタンをクリックして、ウィザードの前のステップに
戻ります。そうでない場合は、緑⾊の [送信] ボタンをクリックします。
[成功] ページが表⽰され、指定された Active Directory ノードのインデックス作成が開始されます。
Active Directory のモニターの詳細は、このマニュアルの「Active Directory のモニター」を参照してくださ
い。
スクリプト
スクリプト⼊⼒を追加するには：
A. [新規追加] ページに移動
⼊⼒ (データの取り込み) は、Splunk Web の [新規追加] ページから追加します。2 種類の⽅法でこのページを表
⽰できます。
162
Splunk ホーム
Splunk 設定
Splunk 設定を使⽤する場合：
1. Splunk Web の右上にある [設定] をクリックします。
2. [設定] ポップアップの [データ] セクションで、[データ⼊⼒] をクリックします。
3a. ローカル・マシン上のスクリプトからデータを収集するには、[スクリプト] をクリックします。または、
3b. リモート・マシン上で動作するスクリプトからデータを取得するには、[転送されたデータ] の [スクリプト]
をクリックします。
4. [新規] ボタンをクリックして、⼊⼒を追加します。
Splunk ホームを使⽤する場合：
1. Splunk ホームの [データの追加] リンクをクリックします。
2. ローカル・マシン上のスクリプトからのデータをモニターするには [モニター] を、リモート・マシン上のスク
リプトからデータを転送する場合は [転送] をクリックします。[データの追加 - ソースの選択] ページが表⽰され
ます。
注意： スクリプト⼊⼒からデータを転送するには、追加の設定が必要です。
3. 左側のパネルで、[スクリプト] を探して選択します。
B. ⼊⼒ソースの選択
1. [スクリプト・パス] ドロップ・ダウンで、スクリプトへのパスを選択します。ページに新しい [スクリプト名]
ドロップダウンが表⽰されます。
2. [スクリプト名] ドロップ・ダウンに、実⾏するスクリプトを選択します。ページの [コマンド] フィールドにス
クリプト名が設定されます。
注意： ⽬的のスクリプトが⾒つからない場合、ご利⽤のオペレーティング・システムのファイル管理ツールを
使って適切な場所にそれを保存する必要があります。
3. [コマンド] フィールドに、スクリプトの実⾏に必要な引数を追加します。
4. [間隔] フィールドに、スクリプト実⾏前に Splunk Enterprise を待機させる時間 (秒) を⼊⼒します。
5. 必要に応じて、[ソース名上書き] フィールドに、デフォルト値に優先する新たなソース名を⼊⼒します。
6. 緑⾊の [次へ] ボタンをクリックします。
C. ⼊⼒の設定
[⼊⼒設定] ページでは、アプリケーション・コンテキスト、デフォルトのホスト値、およびインデックスを指定
できます。これらのパラメータは省略することができます。
1. スクリプトのソースタイプを選択します。[選択] を選択して、ローカル・マシンで利⽤できるソースタイプの
リストから選択、または [⼿動] を選択してソースタイプ名を⼊⼒することができます。
2. この⼊⼒の適切なアプリケーション・コンテキスト を選択します。
3. ホスト 名の値を設定します。さまざまな選択肢があります。ホスト値の設定の詳細は、「ホストについて」を
参照してください。
注意： [ホスト] は、イベントの host フィールドの設定のみを⾏います。Splunk Enterprise にネットワー
ク上の特定のホストを探すように指⽰するものではありません。
4. データを保管するインデックス を設定します。異なる種類のイベントを取り扱うために、複数のインデックス
を定義している場合を除き、この値は「default」のままにしてください。ユーザーデータ⽤のインデックスに加
えて、Splunk Enterprise にはさまざまなユーティリティインデックスが存在しています。これらのインデックス
も、このドロップダウンボックスに表⽰されます。
5. 緑⾊の [確認] ボタンをクリックします。
D. 選択項⽬の確認
⼊⼒設定をすべて指定したら、選択内容をレビューすることができます。Splunk Enterprise には、モニターのタ
イプ、ソース、ソースタイプ、アプリケーション・コンテキスト、インデックスなど (これ以外が表⽰されること
もあります) の、選択したオプションが表⽰されます。
設定を確認します。意図通りの内容でない場合は、⽩い [< ] ボタンをクリックして、ウィザードの前のステップに
戻ります。そうでない場合は、緑⾊の [送信] ボタンをクリックします。
[成功] ページが表⽰され、指定された Active Directory ノードのインデックス作成が開始されます。
163

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

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

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

Splunk Enterprise

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

Enterprise II シリーズに登載している

「BigFix Enterprise Suite」の日本国内販売を開始

新しい段階に入ったグローバル化時代の経営 GLOBAL ENTERPRISE

株式会社小松製作所 様 Enterprise Commerce 事例