Table of Contents Splunk へのデータの取り込み Splunk がインデックス処理できる項 データの場所 : ローカルまたはリモート? フォワーダーの使 App の使 データの取り込み 法 の設定 Windows データと Splunk について Splunk によるデータの取

Transcription

1 Splunk Enterprise 6.0 データの取り込み 作成 :2013 年 午後 3 時 27 分 Copyright (c) 2014 Splunk Inc. All Rights Reserved

2 Table of Contents Splunk へのデータの取り込み Splunk がインデックス処理できる項 データの場所 : ローカルまたはリモート? フォワーダーの使 App の使 データの取り込み 法 の設定 Windows データと Splunk について Splunk によるデータの取り扱い ( および活 法 ) ファイルやディレクトリからデータを収集ファイルとディレクトリのモニター Splunk Web の使 CLI の使 inputs.conf の編集ワイルドカードを使った パスの指定ホワイトリストまたはブラックリスト固有の到着データ Splunk によるログファイルのローテーションの取り扱い Get net work event s TCP および UDP ポートからのデータの取り込み Splunk への SNMP イベントの送信 Get Windows dat a リモート Windows データのモニター 法決定の検討事項 Active Directory のモニター Windows イベントログデータのモニター Windows のファイルシステム変更のモニター WMI ベースのデータのモニター Windows レジストリデータのモニターリアルタイム Windows パフォーマンスモニタリング Windows ホスト情報のモニター Windows プリンタ情報のモニター Windows ネットワーク情報のモニター Ot her ways t o get st uff in 72 FIFO キューからのデータの取得 72 ファイルシステムへの変更のモニター 73 スクリプト を介した API や他のリモートデータインターフェイスか 76 らのデータの取得 crawl を使ったモニター項 の発 79 レシピ フォワーダーファイルとディレクトリ - ローカルファイルとディレクトリ - リモート Syslog - ローカル

3 Syslog - TCP Syslog - UDP Windows イベントログ - ローカル Windows イベントログ - リモート Windows イベントログ - 多数のリモート Windows レジストリ - ローカル Windows レジストリ - リモート Windows パフォーマンスモニタリング - ローカル Windows パフォーマンスモニタリング - リモート Windows パフォーマンスモニタリング - 多数のリモート Windows Active Directory UNIX ログ - ローカル FSChange - ローカル WebSphere - ローカル IIS ログ - ローカル Apache ログ - ローカル JMS/JMX - 独 のスクリプトの作成 イベント処理の設定イベント処理の概要 字セットのエンコードの設定イベントの 分割の設定イベントのタイムスタンプの設定インデックス作成フィールド抽出の設定データの匿名化 タイムスタンプの設定タイムスタンプ割り当ての仕組みタイムスタンプ認識の設定複数のタイムスタンプを持つイベントのタイムスタンプ割り当ての設定タイムスタンプのタイムゾーンの指定インデックス作成パフォーマンス向上のためのタイムスタンプ認識の調整 インデックス作成フィールド抽出の設定インデックス作成フィールドの抽出についてデフォルトフィールドについて (host source sourcetype など ) デフォルトフィールドの動的割り当てインデックス時のカスタムフィールドの作成ヘッダーのあるファイルからのデータの抽出 ホスト値の設定ホストについて Splunk サーバーのデフォルトホストの設定ファイル / ディレクトリ のデフォルトホストの設定イベントデータに基づくホスト値の設定誤って割り当てられたホスト値の取り扱い ソースタイプの設定ソースタイプが重要な理由 動ソースタイプ割り当てに優先する設定

4 ルールベースのソースタイプ認識の設定事前定義ソースタイプの 覧イベント単位でのソースタイプに優先する設定ソースタイプの作成ソースタイプ名の変更 イベントのセグメント分割の管理セグメント分割についてイベントデータのセグメント分割の設定 Splunk Web でのサーチ時セグメント分割の設定 Preview your dat a データプレビューの概要データプレビューとソースタイプデータの準備イベントデータの表 イベント処理の変更データプレビューと分散 Splunk データ取り込みプロセスの改善テスト インデックスを使って をテストするデータ損失を防 するための persistent queue の使 プロセスのトラブルシューティング

5 Splunk へのデータの取り込み Splunk がインデックス処理できる項 Splunk を使 するための最初の作業が データを取り込むことです Splunk にデータを取り込むと 即座にインデックスが作成され サーチが可能になります Splunk はインデックス作成機能により サーチ可能なフィールドから構成される個別のイベントにデータを変換します Splunk がデータのインデックスを作成する前 / 後にさまざまな処理を えますが 般的にそのような作業は必要ありません たいていの場合 Splunk は取り込んだデータのタイプを判断し 適切な処理を えます 基本的に Splunk にデータを指 すれば 残りの作業は Splunk が います その後 データのサーチを開始したり それを使ってグラフ レポート アラート および他の出 を 成したりすることができます データの種類 任意のデータを利 できます 特に あらゆる IT ストリーミングデータと履歴データを得意にしています イベントログ Web ログ ライブアプリケーションログ ネットワークフィード システムメトリックス 変更のモニター メッセージキュー アーカイブファイル その他各種データなども利 できます どのようなデータでも利 できます 嘘ではありません Splunk にデータのソースを指 してください また ソースに関するいくつかの情報も指定します そのソースが Splunk へのデータ となります Splunk は取り込まれるデータのインデックスを作成し それを個別の 連のイベントに変換します それらのイベントは即座に表 サーチすることができます 望み通りの結果が得られなかった場合は 的の結果が得られるまでインデックス作成処理を調整することができます データは Splunk インデクサーと同じマシン上でも ( ローカルデータ ) 他のマシン上でも ( リモートデータ ) 構いません リモートデータは ネットワークフィードを利 またはデータのソースとなるマシン上に Splunk フォワーダーをインストールして 簡単に取得することができます フォワーダーは軽量版の Splunk で 収集したデータをメインとなる Splunk インスタンスに転送します この Splunk インスタンスは開け取ったデータのインデックス作成やサーチを います ローカルデータとリモートデータについては データの場所 を参照してください 作業を簡単に うために Splunk はさまざまな無料の App やアドオン および Windows または Linux 固有のデータ Cisco セキュリティデータ Blue Coat データなどに対応する 事前設定されたデータ ( データの取り込み 段 ) を提供しています Splunkbase からご 分のニーズに適した App やアドオンをお探しください Splunk には Web ログ J2EE ログ Windows パフォーマンス測定基準など さまざまなデータソースにも対応しています これらのデータソースを利 するには 後述するように Splunk Web の [ データの追加 ] セクションを使 します 意されているデータソースや App ではニーズを満たしていない場合は Splunk の汎 設定機能を使って 的のデータソースを指定します これらの汎 データソースについては ここを参照してください データ の指定 法 新しい種類のデータを Splunk に取り込むには それを設定します データの取り込みを指定するには さまざまな 法があります 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 のデータ は以下のように分類できます ファイルとディレクトリネットワークイベント 5

6 Windows ソースその他のソース ファイルとディレクトリ 多くの有益なデータが ファイルやディレクトリに存在している可能性があります 多くの場合 Splunk のファイル / ディレクトリのモニター プロセッサを使って ファイルやディレクトリからのデータを取得することができます ファイルとディレクトリのモニターについては ファイルとディレクトリのデータの取得 を参照してください ネットワークイベント Splunk は 任意のネットワークポートからのデータのインデックスを作成することができます たとえば syslog-ng や他の TCP 経由でデータを伝送するアプリケーションからの リモートデータのインデックスを作成することができます UDP データのインデックスも作成できますが 信頼性の観点から可能な場合は TCP を使 することをお勧めします SNMP イベント リモートデバイスが 成したアラートを受信してインデックスを作成することもできます ネットワークポートからデータを取得するには TCP および UDP ポートからのデータの取得 を参照してください SNMP データの取得については Splunk への SNMP イベントの送信 を参照してください Windows ソース Windows 版の Splunk には さまざまな Windows 固有の が 意されています また 以下のような Windows 固有の タイプを定義することもできます Windows イベントログデータ Windows レジストリデータ WMI データ Active Directory データパフォーマンスモニターデータ 重要 :Windows 版以外の Splunk インスタンス上で Windows データのインデックス作成とサーチを えますが その場合はまず Windows 版のインスタンスを使ってデータを収集する必要があります そのためには Windows 上で動作する Splunk フォワーダーを使 します フォワーダーで Windows データを収集し それを Windows インスタンスに転送するように設定します 詳細は リモート Windows データのモニター 法決定の検討事項 を参照してください Splunk での Windows データの使 法の詳細は Windows データと Splunk について を参照してください その他のソース Splunk は 他の種類のデータソースもサポートしています 例 : FIFO キュースクリプト - API および他のリモートデータインターフェイスやメッセージキューからのデータ取り込み その他の検討事項 ここでは Splunk データの指定時に検討する必要がある問題について説明していきます データの場所 リモートデータとローカルデータの 較 およびそれが影響する事項について説明しています フォワーダーの使 フォワーダーを使ったリモートデータ収集の簡素化について説明しています App の使 Splunk App を使った Splunk へのデータの取り込みについて説明しています データの取り込み 法 データソースの取得と設定の概要 およびベストプラクティスについて説明しています の設定 Splunk でのデータ の設定 法について説明しています Windows データと Splunk について Windows データを Splunk に取り込む 法の概要を説明しています Splunk によるデータの取り扱い ( および活 法 ) データを Splunk に取り込んだ後どのようにそれが処理されるのか およびデータを活 するための Splunk の設定について説明しています データの場所 : ローカルまたはリモート? Splunk にデータを初めて取り込む場合 ローカル データと リモート データの違いは何なのか混乱するかもしれません 新しいデータ を設定する場合 ローカルとリモートの違いが重要になります この問題への回答は 以下のようにさまざまな基準によって異なります ( ただし これに限定されるものではありません ) Splunk インスタンスが動作しているオペレーティングシステム Splunk インスタンスに直接接続されているデータストアの種類インデックスを作成するデータを保管するデータストアにアクセスするために 認証や他の中間ステップを介する必要があるかどうか 6

7 ローカル ローカルリソースは Splunk サーバー ( 分 ) が直接アクセスできる固定リソースです また それに保管されているデータの種類に関わらず 取り付け 接続 または他の中間操作 ( 認証やネットワークドライブへのマッピングなど ) を うことなく システムからリソースを参照 利 することができます そのようなリソース上にデータが存在している場合 それは ローカル データとみなされます ローカルデータの例を以下に します リモート デスクトップやラップトップに取り付けられているハードディスクや SSD システム起動時にロードされる RAM ディスク リモートリソースは 前述の定義に該当しない任意のリソースです Windows システムからマップされたネットワークドライブ Active Directory スキーマ NFS または *nix システム上の他のネットワークベースのマウントなどが これに該当します このようなリソースから収集されたデータも リモート とみなされます 例外 般的にリモートとみなされるけれども 実際には違うリソースも存在しています 以下にいくつかの例を します USB や FireWire などの 帯域幅物理接続経由で 常時マウントされているボリュームを持つマシン コンピュータはブート時にリソースをマウントできるため 理論的には後ほどリソースを切り離せる場合でも このようなリソースはローカルリソースとして取り扱われます iscsi などの 帯域幅ネットワーク標準規格 または SAN への光接続を介して永久的にマウントされるリソースを持つマシン ローカルのブロックデバイスと同程度のデータ量を処理できる標準規格であるため このようなリソースはローカルとみなされます フォワーダーの使 フォワーダーは軽量版の Splunk インスタンスで データを収集してそれを処理するために Splunk インデクサーに転送することを主な 的にしています 最低限のリソースしか必要とせず パフォーマンス上の影響も少ないため 般的にはデータ 成元のマシン上に配置されます たとえば サーチを実 したいデータを 成する 連の Apache サーバーがある場合を考えてみましょう Splunk インデクサーを独 の Linux マシン上にインストールして 次に各 Apache マシン上にフォワーダーを設定することができます 各フォワーダーは Apache データを収集して それを Splunk インデクサーに送信します インデクサーを受け取ったデータを統合して インデックスを作成し サーチが可能な状態にします 消費リソースが少ないため フォワーダーが Apache サーバーのパフォーマンスに影響することはありません 同様に 従業員の Windows デスクトップにフォワーダーをインストールすることもできます これらのフォワーダーはログや他のデータを集中管理 Splunk インスタンスに送信し それを利 してマルウェアや他の問題が発 していないかどうかを追跡することができます フォワーダーが う作業 フォワーダーを使って リモートマシンからデータを取得することができます フォワーダーは以下のような機能により ネットワークから raw データを供給するよりも 幅に堅牢なソリューションを実現しています メタデータのタグ設定 ( ソース ソースタイプ ホスト ) 設定可能なバッファデータ圧縮 SSL セキュリティ利 可能な任意のネットワークポートの使 ローカルにスクリプト の実 フォワーダーは他の Splunk インスタンスと同じ 法でデータを収集します Splunk インデクサーと完全に同じタイプのデータを処理できます 違いは 般的にフォワーダー 体がインデックスを作成することはないことです 単純にデータを取得して それを Splunk インデクサーに送信します インデクサーがインデックスを作成し サーチを担当します 単 のインデクサーで 複数のフォワーダーから転送されるデータのインデックスを作成することができます フォワーダーの詳細は データの転送 マニュアルを参照してください 半の Splunk デプロイ環境で フォワーダーは主なデータ収集役を果たしています 単 マシンのデプロイ環境でのみ Splunk インデクサーが主なデータ収集役にもなります 規模な Splunk デプロイ環境では 数百台または数千台ものフォワーダーがデータを収集して それを 連のインデクサーグループに転送しています フォワーダー の設定 法 軽量版の Splunk インスタンスであるフォワーダーは 設計上その機能が限定されています たとえば 半のフォワーダーには Splunk Web が含まれていません そのため 直接 Splunk システムにアクセスしてフォワーダーのデータ取り込みを設定することはできません ここでは フォワーダーのデータ取り込みを設定する主な 法について説明していきます 7

8 初期デプロイ時にデータの取り込み ( ) を指定する Windows フォワーダーの場合 インストール時に 般的なデータ取り込みを指定することができます *nix フォワーダーの場合 インストール後にデータの取り込みを指定てできます CLI を使 する inputs.conf を編集する 的のデータ取り込み機能がある App をデプロイする テスト の完全版 Splunk インスタンスで Splunk Web を使 してデータの取り込みを設定し その結果 成された inputs.conf ファイルをフォワーダーに配布する その他の参考情報 使 事例 般的なトポロジー および設定も含めたフォワーダーの詳細は データの転送 マニュアルの 転送と受信について を参照してください デプロイサーバーを使った設定ファイルや App の複数フォワーダーへの配布 法を含めた フォワーダーデプロイの詳細は データの転送 マニュアルの ユニバーサルフォワーダーのデプロイの概要 を参照してください リモート Windows データをモニターするためのフォワーダーの使 法については リモート Windows データのモニター 法を決定するための検討事項 を参照してください App の使 Splunk には Splunk の機能を拡張 強化するためのさまざまな App やアドオンが提供されています App により Splunk へのデータの取り込みプロセスが簡単になります 特定の環境やアプリケーション向けのデータ取り込みを 分で設定する代わりに データの取り込みが事前に設定されている App を探して使 することもできます App は Splunkbase からダウンロードできます 般的に App は特定のデータタイプを対象にしており デート取り込みの設定から有益なデータビューの 成までさまざまな機能が 意されています たとえば Windows サーバーおよびデスクトップ向けに データの取り込み サーチ レポート アラート およびダッシュボードを提供する Windows App が存在しています また UNIX/Linux 環境向けに同じ機能を提供する *nix App も存在しています 他にも Splunk for Blue Coat ProxySGapp Splunk for F5 app Cisco Security Suite app Splunk App for Websphere Application Server などの 特定のタイプのアプリケーションデータを取り扱うさまざまな種類の App が 意されています 始めに Splunk Web の [ データの追加 ] ページ をお読みください このデータ取り込みページのリンクから さまざまな App にアクセスすることができます また SplunkBase に移動して各種 App をダウンロードすることもできます SplunkBase には頻繁に新しい App が追加されるため 定期的に確認してください 重要 :Splunk Web がプロキシサーバーの背後に配置されている場合は Splunk 内からの SplunkBase へのアクセス時に問題が発 する可能性があります この問題に対処するために 管理マニュアル の プロキシサーバーの設定 の説明に従って http_proxy 環境変数を設定する必要があります App に関する全般的な情報については 管理マニュアル の App とアドオンとは およびそれ以降のセクションを参照してください その他の App やアドオンの 場所 は特に App のダウンロードとインストール 法について説明しています 独 の App の作成 法については Developing Views and Apps for Splunk Web マニュアルを参照してください データの取り込み 法 Splunk で作業を開始するのは簡単です [ データの追加 ] ページで 単純にデータの取り込みを設定するだけです または お使いの OS App (Splunk App for Windows や Splunk App for Unix and Linux) などの 関連 App をダウンロードして 有効にすることもできます データの取り込みを設定 または App を有効にしたら Splunk は指定されたデータのインデックス作成を即座に開始します その後 サーチ App (Splunk Web の開始ページである Splunk ホームからアクセス可能 ) に移動して データの詳細な調査を開始することができます 作業は簡単ですが まずテスト インデックスで試してみるのも良いでしょう 新しいデータ取り込みの追加 ここでは推奨する 順について説明していきます 1. 分のニーズを把握します たとえば 以下のような事項を検討します Splunk でインデックスを作成するデータは?Splunk がインデックスを作成できるデータの種類については ここを参照してください そのデータ の App があるか? ご 分のニーズを満たす事前設定された App があるかどうかを確認するには App の使 を参照してください データはどこに存在しているか? ローカルか またはリモートか? データの場所 を参照してください リモートデータへのアクセスにフォワーダーを使 するか? フォワーダーの使 を参照してください インデックス作成したデータで何をするのか? 何ができるのかを考えるために まず Splunk ナレッジとは を参照してください 2. まず さなテスト インデックスを作成し またいくつかのデータ取り込み ( ) を追加します テスト インデックスの設定については ここを参照してください 8

9 重要 : テスト データの量は最低限に抑えてください テスト インデックスに追加されたデータは ライセンスの 次インデックス作成量の加算対象となります 3. データをテスト インデックスに送る前に Splunk のデータプレビュー機能を使って Splunk がどのようにデータのインデックスを作成するかを確認し 必要に応じて修正してください 詳細は データプレビューの概要 を参照してください 4. テスト データに対して いくつかのサーチを実 します 意図通りのデータが表 されましたか? Splunk のデフォルト設定でイベントが正常に処理されましたか? 何か つからなかったり おかしな点はありませんか? 最適な結果が表 されましたか? 5. 必要に応じて 意図通りのイベントが収集 表 されるように データの取り込みやイベント処理の設定を調整します イベント処理の設定 法については このマニュアルの Splunk によるデータの取り扱い を参照してください 6. テスト インデックスからデータを削除して 必要に応じて実際の利 を開始します 詳細は ここを参照してください 7. 利 準備が完了したら デフォルトの main インデックスへのデータの取り込みを設定します ( ここを参照 ) 他のデータ を追加する場合も 同じアプローチで作業を ってください 独 のデータを取り込みますか? 余分な TLC が必要かもしれません Splunk は任意の時系列データのインデックスを作成できるため 般的には追加の設定作業を う必要はありません 独 のアプリケーションやデバイスからログを取得する場合は まず Splunk のデフォルトでお試しください 的の結果が得られない場合は イベントのインデックスが正常に作成されるように いくつかの設定を調整することができます 続 する前に イベントの処理および Splunk がデータのインデックスを作成する 法について学習し データに必要な TLC を判断できるようにしておくことをお勧めします いくつかの検討しておく必要がある問題を以下に します イベントは複数 イベントか? データに特殊な 字セットが使われているか? Splunk がタイムスタンプを正常に認識できないか? の設定 Splunk に新しいタイプのデータを追加するには まずデータに関するいくつかの事項を設定する必要があります そのためには データ ( 取り込み 法 ) を設定します データ を設定するために さまざまな 法が 意されています App:Splunk には 各種データを取り込むために が事前設定されているさまざまな App が 意されています Splunk の App を活 して データ取り込みの設定の 間を省きましょう 詳細は App の使 を参照してください Splunk Web: データ取り込みの 半は Splunk Web のデータ ページから設定できます この 法では GUI を使って取り込むデータを設定できます Splunk ホームから [ データの追加 ] ページにアクセスすることができます また [ システム ] を使って新たな を追加したり 既存の を管理したりすることもできます また Splunk Web のデータプレビュー機能を使って 実際にインデックスにデータを書き込む前に Splunk がデータのインデックスをどのように作成するのかを確認し 必要に応じて設定を調整することができます Splunk の CLI: CLI を使って 部分のデータ取り込みを設定できます inputs.conf 設定ファイル :Splunk Web または CLI を使ってデータの取り込みを設定すると その設定は設定ファイル inputs.conf に保存されます 必要に応じてこのファイルを直接編集することができます 度なデータ取り込みを う場合は このファイルを編集しなければならないこともあります また フォワーダーを使って他のマシンのデータをインデクサーに送信するように設定する場合 フォワーダーのインストール時にデータの取り込みを指定することができます フォワーダーの使 を参照してください このトピックでは Splunk Web CLI または inputs.conf を使って 分でデータ を設定する 法について説明していきます Splunk Web の使 データ は Splunk ホーム または [ システム ] から追加することができます Splunk ホームから [ データの追加 ] を選択します [ データの追加 ] ページが表 されます このページには さまざまな タイプ向けのリンクが記載されています これを使ってデータ を追加するのがもっとも簡単な 法です Splunk Web の任意の場所から [ システム ] を選択します 次に [ システム ] ポップアップの [ データ ] から [ デー 9

10 タ ] を選択します この操作で表 されるページから 既存のデータ の表 管理 および新しいデータ の追加を えます [ データの追加 ] ページには 2 つのリンクグループが記載されています 最初のグループには いくつかの 般的なデータタイプ向けのリンクと説明が含まれています 2 番 のグループには 設定できるすべての タイプへのリンクが含まれています 初めての場合は 最初のグループ内のリンクから ご 分のニーズに適したデータタイプがあるかどうかを確認してください たとえば [Syslog] をクリックすると 各種 Syslog データに関する情報と それぞれのタイプに応じた設定 法へのリンクが表 されます また [Apache ログ ] をクリックすると そのデータタイプ の設定 法が表 されます Splunk Web を使ったデータ の詳細は このマニュアルの後半にある 特定の に関する説明を参照してください たとえば Splunk Web を使ったネットワーク の設定 法を学習するには TCP/UDP ポートからのデータの取り込み を参照してください 半の は Splunk Web を使って設定できます ファイルシステム変更のモニタリングなどの 部の タイプは inputs.conf を直接編集する必要があります また 他の タイプに対して 度な設定を う場合も 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/ 何か分からないことがある場合 CLI にはヘルプが 意されています CLI コマンドの 覧を表 するには 以下のコマンドを します./splunk help commands 各コマンドには それぞれ独 のヘルプページが 意されています 参照するには./splunk help <command> と します CLI を使った特定の の設定については このマニュアルの適切な に関する説明を参照してください たとえば CLI を使ったネットワーク の設定 法を学習するには CLI を使ったネットワーク の追加 を参照してください. CLI に関する全般的な情報については 管理マニュアル の CLI について および他の関連するトピックを参照してください inputs.conf の編集 inputs.conf を編集して直接 を追加するには その のスタンザを設定します スタンザは $SPLUNK_HOME/etc/system/local/ 内 または独 のカスタム App ディレクトリ ($SPLUNK_HOME/etc/apps/<app name>/local) 内の inputs.conf ファイルに追加します Splunk の設定ファイルで初めて作業を う場合は 事前に 設定ファイルについて を参照してください データ を設定するには スタンザに属性 / 値のペアを追加します スタンザには複数の属性を設定できます 属性の値を指定しない場合は $SPLUNK_HOME/etc/system/default/inputs.conf に定義されているデフォルト値が使 されます ネットワーク を追加する簡単な例を以下に します この設定は 任意のリモートサーバーからの raw データを TCP ポート 9995 で待ち受けるように Splunk に指 しています データのホストは リモートサーバーの DNS 名で設定します すべてのデータには ソースタイプ log4j およびソース tcp:9995 が割り当てられます [tcp://:9995] connection_host = dns sourcetype = log4j source = tcp:9995 特定の の設定 法については このマニュアルのその に関する説明を参照してください たとえば ファイル の設定 法については ここを参照してください 各データ のトピックには その で利 できる主な属性が説明されています 利 可能な属性の完全な 覧については inputs.conf spec ファイルを参照する必要があります spec ファイルには 属性の詳細な説明が記載されています また 複数の例も記載されています 10

11 ソースタイプについて データ取り込み処理の 環として Splunk はデータにソースタイプを割り当てます ソースタイプはデータのフォーマットを しています インデックス作成時に Splunk はソースタイプを使 して イベントを正しくフォーマットします 通常 Splunk は どのソースタイプを割り当てるのかを理解しています たとえば syslog データにはソースタイプ syslog が割り当てられます 特定の に Splunk が割り当てるソースタイプに不満がある場合は 別のソースタイプを指定することができます ( 事前定義されているソースタイプまたは 分で作成したソースタイプ ) ソースタイプは の設定時に設定します 設定 法は このトピックで説明しています ソースタイプの詳細は ソースタイプが重要な理由 を参照してください 動ソースタイプ割り当てに優先する設定 には ソースタイプ割り当てオプションが詳細に説明されています イベント単位でのソースタイプの設定 法については 度なソースタイプの上書き を参照してください データに適切なソースタイプを割り当てるために Splunk Web のデータプレビュー機能を利 することができます また この機能を使ってソースタイプ設定を編集したり 新たなソースタイプを作成したりすることもできます 詳細は データプレビューとソースタイプ を参照してください Windows データと Splunk について Splunk は拡張可能な強 なツールです さまざまな種類の Windows データのインデックスを作成できます ログファイル ディレクトリ内のファイル イベントログ レジストリ または Active Directory など 任意のデータを利 することができます Splunk は Windows データをモニターするために 特別な も 意されています 以下に例を します Windows イベントログ : マシン上で利 できる任意のイベントログチャネルで Windows イベントログサービスが 成したログをモニターすることができます ローカルマシン上のログを収集することも ユニバーサルフォワーダーや WMI を使ってリモートログデータを収集することも可能です パフォーマンスモニタリング :Windows マシン上のパフォーマンスデータを収集して そのデータに基づくアラートやレポートを作成することができます パフォーマンスモニターで利 できる任意のパフォーマンスカウンタも Splunk で利 することができます パフォーマンスをローカルに監視することも または WMI またはユニバーサルフォワーダーを使ってリモートに監視することも可能です WMI 経由のリモートモニタリング : WMI を使って リモートマシン上のイベントログやパフォーマンスデータにアクセスすることができます レジストリ監視 :Splunk 内蔵のレジストリモニタリング機能を使って ローカル Windows レジストリへの変更をモニターすることができます ユニバーサルフォワーダーを使って リモートマシン上のレジストリデータを収集することもできます Active Directory モニタリング : ユーザー グループ マシン およびグループポリシーオブジェクトなどの Active Directory に対する変更を監視することができます これらの特殊な は Windows 版の Splunk でのみ利 できます ファイルとディレクトリ ネットワークモニタリング およびスクリプト などの 標準の Splunk セットを利 することもできます Splunk App for Windows Splunk App for Windows は Windows サーバーおよびデスクトップの管理 に データの取り込み サーチ レポート アラート およびダッシュボードを提供しています Windows オペレーティングシステムのモニター 管理 トラブルシューティングを 1 カ所から えます この App には CPU ディスク I/O メモリー イベントログ 設定 およびユーザーデータ のスクリプト そして Windows イベントログのインデックスを作成するための Web ベースのセットアップ UI が含まれています この無料 App を利 すれば Windows 版 Splunk を 軽に学習することができます Windows App と Splunk の新しいパフォーマンス測定基準収集機能 現在の所 Splunk App for Windows は 最新版の Splunk で利 できる 新たな Windows パフォーマンスモニター収集機能を活 していません App は正常に動作し サポートされていますが デフォルトでは WMI を使ってローカルのパフォーマンス測定基準を収集しています この新機能を使 したい場合 またはユニバーサルフォワーダーを使ってデフォルトのパフォーマンスモニタリングデータコレクションによるデータを App が動作しているインスタンスに送信している場合は 定義したパフォーマンスモニタリングコレクションを使 するように App 内のサーチを編集する必要があります Windows への Splunk デプロイの初期検討事項 Windows に Splunk をインストール デプロイする場合 以下の事項を検討する必要があります 認証 : ネットワーク内のリモート Windows マシン上で何らかの操作を実 するためには Splunk に Active Directory ドメインまたはフォレストへの適切なアクセス権が必要です つまり 適切な資格情報を持つユーザーとして Splunk を実 する必要があります デプロイ作業を開始する前に そのような資格情報を 意しておくことをお勧めします その他の詳細は リモート Windows データのモニター 法決定のための検討事項 を参照して 11

12 ください ディスクの帯域幅 :Splunk インデクサーは 量のディスク I/O 帯域幅を必要としています ( 特に 量のデータのインデックスを作成する場合 ) Splunk とそれがインストールされているオペレーティングシステム間を中継するプログラムがあるシステムでは 特に注意する必要があります これにはウィルス対策ソフトウェアが含まれています ウィルス対策ソフトウェアがインストールされている場合 ウィルススキャンなどでパフォーマンスが 幅に低下するため Splunk ディレクトリまたはプロセスを監視対象にしないようにウィルス対策ソフトウェアを設定する必要があります 共有サーバー : 他のサービスが動作しているサーバー上に Splunk をインストールする前に インストールマニュアル の Splunk デプロイ環境のハードウェアキャパシティプランニング を参照してください このことは特に ドメインコントローラに Splunk をインストールする場合 または Exchange SQL Server または仮想ホストサーバーなどのメモリーを消費するサービスが動作するコンピュータ上に Splunk をインストールする場合に重要になります Windows サーバーから効率的にデータを収集するには データの収集対象マシン上にユニバーサルフォワーダーをインストールします ユニバーサルフォワーダーは 型軽量で わずかなリソースしか消費しません レジストリのモニタリングなど 部の状況下では リモートにレジストリの変更をポーリングできないためフォワーダーを使 する必要があります Splunk によるデータの取り扱い ( および活 法 ) Splunk は任意の種類のデータを取り込んで それのインデックスを作成し イベントという形のサーチ可能で役に つ情報に変換します 以下のデータパイプラインは インデックス作成時のデータ処理の主な流れを表しています これらのプロセスが イベント処理を構成しています データが処理されてイベントに変換されたら イベントをナレッジオブジェクトと関連付けて有 性をさらに向上することができます データパイプライン 連のデータが Splunk に取り込まれると データをサーチ可能なイベントに変換する データパイプラインを通過します データパイプラインの主要なステップを以下の図に します 12

13 データパイプラインの概要については 分散デプロイ マニュアルの Splunk 内でのデータの移動 を参照してください Splunk はイベント処理時に ほとんどのタイプのデータを 有益でサーチ可能になるイベントに変換するために 適切に認識して処理を います ただし データの種類やデータから抽出したい情報によっては イベント処理の 部のステップを調整しなければならないこともあります イベント処理 イベント処理は パーシングとインデックス作成の 2 つのステージに分かれて われます Splunk に取り込まれるデータはすべて きなデータの塊 ( チャンク ) としてパーシングパイプラインを通過します パーシング中に これらのチャンクはイベントに分割されます 分割されたイベントは インデックス作成パイプラインに渡されて 最終処理が われます パーシングおよびインデックス作成の両 で Splunk はデータを処理し さまざまな 法で変換を います これらのプロセスの 半は設定を変更することができ ニーズに合わせて処理を調整することができます 以降の説明でリンクをクリックすると これらのいずれかのプロセスの説明と 設定 法に関する情報を記載したトピックに移動します パーシング中 Splunk はさまざまなアクションを実 します 以下に例を します host source および sourcetype などの 連のデフォルトフィールドを抽出する 字セットのエンコードを設定する 分割ルールを使って の終端を識別する 半のイベントは短く 1 2 程度ですが 中には いイベントも存在しています の終端の設定は Splunk Web のデータプレビュー機能を使って 対話形式で変更することもできます タイムスタンプを識別する また存在しない場合は作成する タイムスタンプ処理と同時に イベント境界の識別が われます タイムスタンプの設定は Splunk Web のデータプレビュー機能を使って 対話形式で変更することもできます このステージで 重要なイベントデータ ( クレジットカード情報や社会保障番号など ) をマスクするように Splunk を設定することができます また 受信したイベントにカスタムメタデータを適 するように設定することもでき 13

14 ます インデックス作成パイプラインでは 以下のような追加処理が われます すべてのイベントを サーチ可能なセグメントに分割する セグメント分割のレベルを指定することができます セグメント分割レベルは インデックス作成およびサーチ速度 サーチ能 およびディスクの圧縮効率に影響します インデックスデータ構造を作成する raw データとインデックスファイルをディスクに書き込む ディスクでは インデックス作成後の圧縮処理が われます パーシングおよびインデックス作成パイプラインの違いは 主にフォワーダーに影響してきます ヘビーフォワーダーは ローカルにデータの完全パーシングを い パーシングされたデータをインデクサーに転送できます インデクサーは最終的なインデックス作成作業を います ユニバーサルフォワーダーでは 最低限のパーシング処理を った後にデータを転送します 部分のパーシング処理は 受信側のインデクサーで われます イベントおよび処理の詳細は このマニュアルの イベント処理の概要 を参照してください インデックス作成パイプラインの詳細を表した図とインデックス作成の仕組みについては Community Wiki の How Indexing Works を参照してください イベントの強化と調整 データがイベントに変換されたら それをイベントタイプ フィールド抽出 および保存済みサーチなどのナレッジオブジェクトに関連付けて 有 性を強化することができます Splunk ナレッジの管理の詳細は ナレッジ管理 マニュアルの Splunk のナレッジとは? を参照してください ファイルやディレクトリからデータを収集 ファイルとディレクトリのモニター Splunk には 3 つのファイル プロセッサ monitor monitornohandle および upload が存在しています たいていの場合は monitor を使ってファイルやディレクトリからの ほぼすべてのデータソースを追加することができます ただし 履歴データのアーカイブなど 1 回限り取り込むようなデータには upload を使 することもできます Windows システムでは monitornohandle を使って システムがローテーションを 動的に うファイルをモニターすることができます MonitorNoHandle は Windows システム上でのみ機能します モニターまたはアップロードする を 以下の任意の 法を使って追加することができます Splunk Web CLI inputs.conf CLI または inputs.conf を使って monitornohandle に を追加することができます データプレビュー機能を使って Splunk がファイルのデータに対してどのようなインデックスを作成するかを確認することができます 詳細は データプレビューの概要 を参照してください Splunk のモニターの仕組み ファイルやディレクトリへのパスを指定すると Splunk のモニター monitor プロセッサはそのファイルまたはディレクトリに書き込まれる任意の新しいデータを取り込みます そうすることにより J2EE または.NET アプリケーションなどからのライブアプリケーションログや Web アクセスログなどのログ情報をモニターすることができます Splunk は継続的にファイルやディレクトリをモニターし 新たなデータが到着するとインデックスを作成します Splunk がディレクトリからデータを読み込める限り NFS を含めたマウントされたディレクトリや共有ディレクトリを指定することもできます 指定されたディレクトリ内にサブディレクトリがある場合 Splunk はそれらのディレクトリも再帰的に調査して新たなファイルを取り込みます モニター設定に指定されたファイルまたはディレクトリは Splunk の起動および再起動時にチェックされます 起動時にファイルやディレクトリが存在していなかった場合 Splunk は最後の再起動時刻から 24 時間ごとに再チェックを います モニター対象ディレクトリのサブディレクトリも継続的に調査されます Splunk を再起動せずに新しい を追加したい場合は Splunk Web または CLI を使 します Splunk に 動的に新たな 候補を探させる場合は クロール (crawl) を使 します モニターを使 する場合 以下の事項に注意してください 半のファイルシステムでは 書き込み中でもファイルを読み取ることができます ただし Windows ファイルシステムには 書き込み中のファイルの読み取りを防 する機能があり 部の Windows プログラムはこの機能を使 しています ( 部分は使 していませんが ) 書き込み中のファイルを読み取りたい場合は monitornohandle を使 することができます 対象とする または除外するファイルやディレクトリを ホワイトリストとブラックリストを使って指定することができます 14

15 再起動すると Splunk は処理を中断した時点からファイルの処理を再開します アーカイブファイルは そのインデックスを作成する前に解凍されます tar, gz, bz2, tar.gz, tgz, tbz, tbz2, zip および z などの 般的なアーカイブファイルタイプを処理することができます 既存のアーカイブファイルに新しくデータを追加した場合 その新たなデータだけではなく ファイル内のすべてのデータのインデックスが再作成されます そのため イベントの重複が発 する可能性があります Splunk はログファイルのローテーションを検出して すでにインデックスを作成している 名前が変更されたファイルの処理は いません (tar と.gz は例外です 詳細は このマニュアルの ログファイルのローテーション を参照してください ) dir/filename パスの全 は 1024 字以下でなければなりません コマンドラインまたは [ システム ] を使ってファイルベースの を無効化または削除しても その で処理中のファイルのインデックス作成は中断されません ファイルの再チェックは中 されますが 中 時点でのすべてのデータのインデックスが作成されます すべてのデータ処理を中 するには Splunk サーバーを再起動する必要があります モニター がオーバーラップしている場合もあります スタンザ名が異なっている限り Splunk はそれらを別個のスタンザとして取り扱い スタンザにもっとも 致するファイルが そのスタンザの設定に従って処理されます アップロードまたはバッチを使 する理由 静的なファイルのインデックスを 1 回のみ作成するには Splunk Web で [ ローカルファイルのアップロード ] または [Splunk サーバー上のファイルのインデックスを作成 ] を選択します このファイルが継続的にモニターされることはありません 同じ 的で CLI コマンドの add oneshot または spool を使 することもできます 詳細は CLI の使 を参照してください ファイルを 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 を使ってファイルやディレクトリからの を追加するには : A. [ 新規追加 ] ページに移動 ( データの取り込み ) は Splunk Web の [ 新規追加 ] ページから追加します 2 種類の 法でこのページを表 できます Splunk 設定 Splunk ホーム どちらの 法を使 しても構いません 同じ [ 新規追加 ] ページが表 されます Splunk 設定を使 する場合 : 1. Splunk Web の右上にある [ 設定 ] をクリックします 2. [ 設定 ] ポップアップの [ データ ] セクションで [ データ ] をクリックします 3. [ ファイルとディレクトリ ] をクリックします 4. [ 新規 ] ボタンをクリックして を追加します Splunk ホームを使 する場合 : 1. Splunk ホームの [ データの追加 ] リンクをクリックします 2. [ ファイルとディレクトリから ] リンクをクリックして を追加します 15

16 B. データのプレビュー 新しくディレクトリやファイル を追加する場合 インデックスが作成されたデータが どのようになるのかをプレビューできるオプションが表 されます この機能により 実際にデータのインデックスを作成する前に Splunk がデータを適切にフォーマットしているかを確認したり 必要に応じてイベント処理を調整したりすることができます データのプレビューが不要な場合は の追加 ページに進むことができます データプレビュー機能の詳細は データプレビューの概要 を参照してください データプレビューページへのアクセスと使 については イベントデータの表 を参照してください データのプレビューをスキップした場合は [ 新規追加 ] ページが表 されます このページでは 次のセクションで説明するように 新しい を追加することができます C. の指定 1. [ ソース ] ラジオボタンを選択します この Splunk がアクセスできるファイルやディレクトリから継続的にインデックスを作成 : 継続的なデータ取り込み ( ) を設定します 指定したファイルやディレクトリにデータが追加されると それのインデックスが作成されます このオプションの詳細設定については 次のセクションを参照してください ファイルのアップロードによるインデックス作成 : ローカルマシンから Splunk にファイルをアップロードします この Splunk サーバー上のファイルからインデックスを 1 度だけ作成 : サーバーから Splunk に バッチ (batch) ディレクトリ経由でフアイルをコピーします 2. ファイルまたはディレクトリへのフルパスを指定します ([ ローカルファイルのアップロード ] ラジオボタンを選択した場合 このフィールドは [ ファイル ] になります ) 共有ネットワークドライブをモニターするには <myhost>/<mypath> と します ( または Windows の場合 \\<myhost>\<mypath>) Splunk に マウントされたドライブ およびモニター対象ファイルに対する読み取り権限があることを確認してください 3. 他の設定にアクセスするには [ その他の設定 ] を選択します 追加の設定が表 されます 通常は これらの設定はデフォルト値のままで 分です 明 的に設定したい場合は 以下の説明を参照してください a. [ ホスト ] セクションでは ホスト名を設定できます さまざまな選択肢があります ホスト値の設定の詳細は ホストについて を参照してください 注意 : [ ホスト ] は イベントの host フィールドの設定のみを います Splunk にネットワーク上の特定のホストを探すように指 するものではありません b.[ ソースタイプ ] を設定することができます ソースタイプは イベントに追加されるデフォルトのフィールドです ソースタイプは タイムスタンプやイベント境界などの 処理する特徴の決定に いられます Splunk の 動ソースタイプ設定に優先する設定を うには このマニュアルの ソースタイプの 動割り当てに優先する設定 を参照してください ディレクトリの場合は ソースタイプに [ 動 ] を設定してください ディレクトリ内に異なるフォーマットのファイルが含まれている場合は ソースタイプの値を 動設定しないでください そうしてしまうと そのディレクトリ内のすべてのファイルに単 のソースタイプが割り当てられてしまいます c. この のインデックスを設定することができます 異なる種類のイベントを取り扱うために 複数のインデックスを定義している場合を除き この値は default のままにしてください ユーザーデータ のインデックスに加えて Splunk にはさまざまなユーティリティインデックスが存在しています これらのインデックスも このドロップダウンボックスに表 されます 4. [ 保存 ] をクリックします ファイル / ディレクトリのモニタリング 詳細オプション ソースとして [ ファイルまたはディレクトリを監視 ] ラジオボタンを選択した場合 [ その他の設定 ] セクションには [ 詳細オプション ] セクションも表 されます このセクションから いくつかの追加設定を えます ファイル末尾から取込 : 選択した場合 ファイルの末尾でモニタリングが開始されます (tail -f と同様 ) ホワイトリスト : パスを指定した場合 そのパスからのファイルは 指定した正規表現に 致する場合にのみモニターされます ブラックリスト : パスを指定した場合 そのパスからのファイルは 指定した正規表現に 致するとモニターされません ホワイトリストとブラックリストの詳細は このマニュアルの ホワイトリストまたはブラックリスト固有の到着データ を参照してください CLI の使 ファイルやディレクトリを Splunk のコマンドラインインターフェイス (CLI) を使ってモニターします Splunk の CLI を使 するには $SPLUNK_HOME/bin/ ディレクトリに移動して そのディレクトリで splunk コマンドを使 します 何か分からないことがある場合 CLI にはヘルプが 意されています メインの CLI ヘルプにアクセスするには splunk 16

17 help と します 各コマンドには それぞれ独 のヘルプページが 意されています splunk help <command> と してください 設定 の CLI コマンド CLI を使った 設定には 以下のコマンドを利 できます コマンドコマンドの構 対処 add monitor edit monitor remove monitor list monitor add oneshot add monitor <source> [- parameter value]... edit monitor <source> [- parameter value]... remove monitor <source> list monitor add oneshot <source> [- parameter value]... <source> からの をモニターします 前に追加した <source> の を編集します 前に追加した <source> の を削除します 現在設定しているモニター を 覧表 します <source> ディレクトリを Splunk に直接コピーします これによりファイルが 1 回アップロードされますが 継続的なモニターは われません 重要 :oneshot コマンドでは 再帰的フォルダやワイルドカードをソースとして使 することはできません このコマンドを使 する場合は 対象ファイルの正確なソースパスを指定してください spool spool <source> <source> を Splunk に sinkhole ディレクトリ経由でコピーします このコマンドは add oneshot コマンドと似ていますが 即座に追加されるのではなく sinkhole ディレクトリからスプールされるという違いがあります 追加のパラメータを設定して 各データ の設定を変更します パラメータは -parameter value の構 で設定します 注意 : コマンドあたり 1 つの -hostname -hostregex または -hostsegmentnum を設定することができます パラメータ <source> 必須? はい 説明 新しい をモニター / アップロードするための ファイルまたはディレクトリへのパス 注意 : 他のパラメータと違い このパラメータの構 は単純に値で パラメータフラグが先頭に付けられることはありません <source> であり -source <source> ではありません sourcetype index hostname または host いいえ いいえ いいえ ソースからのイベントの sourcetype フィールド値を指定します ソースからのイベントの 宛先インデックスを指定します ソースからのイベントの host フィールド値として設定するホスト名を指定します 注意 : これらは機能的に同等です hostregex または host_regex いいえ ソースキーから host フィールド値を抽出するために使 する 正規表現を指定します 注意 : これらは機能的に同等です hostsegmentnum または host_segment いいえ 整数で パスのどの / で区切られたセグメントを host フィールドの値として設定するのかを決定します たとえば 3 を設定すると パス内の 3 番 のセグメントが使 されます 注意 : これらは機能的に同等です rename-source follow-only いいえ いいえ このファイルからのデータに適 する source フィールドの値を指定します true または false を設定します デフォルトは偽 (False) です 真 (True) を設定した場合 Splunk はソースの末尾から読み込みます (UNIX コマンドの tail - f と同様 ) 17

18 注意 :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 ログのデフォルトの場所をモニターする 法を以下の例に します データ として C:\windows\system32\LogFiles\W3SVC を追加します./splunk add monitor c:\windows\system32\logfiles\w3svc 例 4: ファイルのアップロード Splunk にファイルをアップロードする 法を以下に します 前の例と違い Splunk は 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 を設定してください これにより ファイルの modtime がチェックされ 変更があった場合にインデックスが再作成されます ファイル全体のインデックスが再作成されるため 重複するイベントが発 する可能性があることに注意してください 設定の指定 モニター (monitor) とバッチ (batch) には 個別のスタンザタイプが存在しています モニターとバッチの詳細は ファイルとディレクトリのモニター を参照してください monitor および batch の両 の スタンザで使 できる属性を以下に します 各 タイプ固有の属性については 後述するセクションを参照してください host = <string> ホスト / キーフィールドに このスタンザの静的な値を設定します ホストキーの初期値を設定します このキーは パーシング / インデックス作成時に使 されます ( 特に host フィー 18

19 ルドの設定時 ) サーチ時に使 される host フィールドでもあります <string> の前には host:: が付けられます 明 的に設定しない場合 デフォルトではデータの起源となるホストの IP アドレスまたは完全修飾ドメイン名が使 されます index = <string> この からのイベントを保管するインデックスを設定します <string> の前には index:: が付けられます デフォルトは main またはデフォルトのインデックスとして設定した任意の値になります インデックスフィールドの詳細は インデクサーとクラスタの管理 マニュアルの インデックス作成の仕組み を参照してください sourcetype = <string> この からのイベントの sourcetype キー / フィールドを設定します このデータのソースタイプを 動的に判断する代わりに 明 的に宣 します このことは パーシングおよびインデックス作成中の このタイプのデータに対するサーチ可能性と関連するフォーマットの適 の両 で重要になります ソースタイプキーの初期値を設定します このキーは パーシング / インデックス作成時に使 されます ( 特に host フィールドの設定時 ) サーチ時に使 される source type フィールドでもあります <string> の前には sourcetype:: が付けられます 明 的に設定しない場合は データのさまざまな側 に基づいてソースタイプが選択されます ハードコード化されたデフォルト値はありません ソースタイプの詳細は このマニュアルの ソースタイプが重要な理由 を参照してください queue = parsingqueue indexqueue プロセッサが 読み込んだイベントをデポジットするかどうかを指定します データに props.conf および他のパーシングルールを適 する場合は parsingqueue を設定します データを直接インデックスに送信する場合は indexqueue を設定します デフォルトは parsingqueue です _TCP_ROUTING = <tcpout_group_name>,<tcpout_group_name>,... tcpout グループ名のカンマ区切りリストを指定します この属性を使 して フォワーダーがデータの転送時に使 する tcpout グループを指定することで データを特定のインデクサーに選択的に転送することができます tcpout グループ名は outputs.conf の [tcpout:<tcpout_group_name>] スタンザに定義します この設定のデフォルトは outputs.conf の [tcpout] スタンザにある defaultgroup のグループになります host_regex = <regular expression> 指定した場合 正規表現は各 のファイル名からホストを抽出します 特に 最初の正規表現グループがホストとして使 されます 正規表現に 致しない場合は デフォルトの host = 属性が使 されます host_segment = <integer> 指定した場合 パスのセグメントがホストとして設定されます セグメントの判断には <integer> が使 されます たとえば host_segment = 2 の場合 パスの 2 番 のセグメントがホストとして設定されます パスのセグメントは / 字により分割されます 値が整数でない または 1 未満の場合は デフォルトの host = 属性が使 されます モニターの構 と例 のモニタースタンザは <path> 内のすべてのファイル ( または 単 のファイルを表している場合は <path> のみ ) を監視するように Splunk に指 します タイプを指定した後は パスを指定します root から開始する場合は 3 つのスラッシュを使 するようにパスを指定してください パスにはワイルドカードを使 できます 詳細は ワイルドカードを使った パスの指定 を参照してください [monitor://<path>] <attrbute1> = <val1> <attrbute2> = <val2>... のモニタースタンザの定義時に使 できる その他の属性を以下に します source = <string> この からのイベントの source キー / フィールドを設定します 注意 : source キーに優先する設定は 般的にお勧めできません 通常 レイヤーは データの取得場所を正確に記録し 問題の分析と調査を 援するために より正確な 字列を提供しています この値に優先する設定を う前に ソースタイプ タグ設定 およびワイルドカードを使ったサーチの使 を検討してください <string> の前には source:: が付けられます 19

20 デフォルトは ファイルパスになります crcsalt = <string> CRC ( 周期的冗 検査 ) が 致するファイルを取り込むように Splunk に強制する場合に この設定を使 します (Splunk は CRC チェックを ファイルの最初の数 に対してのみ実 します この動作により 同じファイルのインデックスを 2 回作成することを防 します ( ログファイルのローテーションなどで ファイル名を変更した場合でも ) ただし CRC はファイルの最初の数 のみを使 しているため 同じ CRC を持つ 異なるファイルが存在する可能性もあります ( 特に同じヘッダーを保有している場合 ) ) 設定した場合 string が CRC に追加されます <SOURCE> を設定した場合 CRC にはソースのフルパスが追加されます これにより モニター対象の各ファイルに対して 意の CRC が保証されます ログファイルのローテーションにこの属性を使 する場合は注意が必要です 注意 : この設定では 字と 字が区別されます ignoreolderthan = <time window> modtime が <time window> 閾値を超えた場合に モニターしている の 更新のためのファイルチェックを中 します モニター対象ディレクトリ階層に 量の履歴ファイルをがある場合 これによりファイル追跡操作の速度が改善します ( たとえば アクティブなログファイルが もはや書き込まれない古いファイルと共存している場合 ) 注意 : 初回モニター時に modtime が <time window> 外のファイルのインデックスは作成されません 値は <number><unit> でなければなりません たとえば 7d は 週間を表しています 有効な単位は d ( 数 ) h ( 時間数 ) m ( 分数 ) および s ( 秒 ) です デフォルトは 0 ( 無効 ) です followtail = を設定した場合 ファイルの末尾からモニタリングが開始されます (tail -f と同様 ) これは ファイルを最初に取得する際にのみ適 されます それ以降は Splunk の内部ファイル位置レコードがそのファイルを追跡します デフォルトは 0 です whitelist = <regular expression> 設定した場合 このパスからのファイルは 指定した正規表現に 致する場合にのみモニターされます blacklist = <regular expression> 設定した場合 このパスからのファイルは 指定した正規表現に 致する場合はモニターされません alwaysopenfile = を設定すると Splunk はファイルを開いてインデックスがすでに作成されているかどうかを確認します modtime を更新しないファイルでのみ役 ちます Windows 上のファイルのモニターにのみ使 する必要があります ( たいていは IIS ログ ) 注意 : 負荷が増加しインデックス作成のパフォーマンスが低下するため このフラグは最後の 段としてのみ使 する必要があります time_before_close = <integer> Splunk が EOF でファイルを閉じるためには Modtime デルタが必要です 過去 <integer> 秒内に更新されたファイルを閉じないようにシステムに指 します デフォルトは 3 です recursive = true false false を設定すると モニター対象ディレクトリ内に つかったサブディレクトリを調査しません デフォルトは true です followsymlink false の場合 モニター対象ディレクトリ内に つかったシンボリックリンクは無視されます デフォルトは true です 例 1:/apache/foo/logs または /apache/bar/logs 内のすべてをロードします [monitor:///apache/.../logs] 例 2: /apache/ 内の.log で終了するものをすべてロードします [monitor:///apache/*.log] MonitorNoHandle の構 と例 20

21 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 内の パスの指定には 正規表現準拠の式を使 せずに Splunk が定義したワイルドカードを使 します ワイルドカードの概要 ワイルドカードは テキストのサーチ時または複数のファイルやディレクトリの選択時に 1 つまたは複数の 字列を表す 字です Splunk では ワイルドカードを使って をモニターする パスを指定することができます ワイルドカード 説明 同等の正規表現 例... 省略記号ワイルドカードは ディレクトリおよび任意のレベルのサブディレクトリを対象に 致項 を探します.* /foo/.../bar/* は /foo/bar /foo/1/bar /foo/2/bar /foo/1/2/bar などに 致します 注意 : 単 の省略記号ですべてのディレクトリとサブディレクトリを調査するため /foo/.../bar の 致項 と /foo/.../.../bar の 致項 は同じになります * アスタリスクは そのディレクトリパスセグメントのすべての項 に 致します... と違い * はサブディレクトリを対象にしません [^/]* /foo/*/bar は /foo/bar /foo/1/bar /foo/2/bar などに 致します ただし /foo/1/2/bar には 致しません /foo/m*r/bar は /foo/mr/bar /foo/mir/bar /foo/moor/bar などに 致します /foo/*.log は 拡張 が.log のすべてのファイルに 致し 21

22 ます (/foo/bar.log など ) /foo/bar.txt または /foo/bar/test.log には 致しません 注意 : 単 のドット (.) はワイルドカードではありません 正規表現の \. と同じ意味を持ちます より細かく 致項 を指定するには... と * を組み合わせて使 します たとえば /foo/.../bar/* は指定パス内の /bar ディレクトリ内の任意のファイルに 致します 警告 :Windows では 現在の所 root レベルでワイルドカードを使 することはできません たとえば 以下の指定は機能しません [monitor://e:\...\foo\*.log] Splunk はログにエラーを記録し 的のファイルのインデックスは作成されません これは既知の問題で リリースノートの Known Issues ( 既知の問題 ) に記載されています 既知の問題については それを参照してください ワイルドカードと正規表現メタ 字 モニター対象の 連のファイルやディレクトリを判断する際に Splunk はモニター スタンザのエレメントをセグメント ( ディレクトリ区切り 字 (/ または \) 間の 字列 ) に分割します ワイルドカードと正規表現メタ 字 ((, ), [, ] や など ) の両 のセグメントを含むモニター スタンザを指定した場合 それらの 字はスタンザ内のワイルドカードの位置によって動作が異なります モニター スタンザで 正規表現メタ 字を持つセグメントがワイルドカードを持つセグメントの前にある場合 Splunk はメタ 字を 字通りに解釈します ( ファイルやディレクトリ名にそれらの 字が使われているものをモニターするように ) 例 : [monitor://var/log/log(a b).log] この場合 /var/log/log(a b).log ファイルがモニターされます ワイルドカードが存在しないため Splunk は (a b) を正規表現として取り扱いません [monitor://var/log()/log*.log] この場合 /var/log()/ ディレクトリ内の log で始まり拡張.log を持つすべてのファイルがモニターされます 正規表現がワイルドカードよりも前のセグメントにあるため Splunk は () を正規表現としては取り扱いません 正規表現がワイルドカードを持つセグメント内またはそれよりも後にある場合 Splunk はメタ 字を正規表現として取り扱い それに 致するファイルがモニターされます 例 : [monitor://var/log()/log(a b)*.log] この場合 /var/log()/ ディレクトリ内の loga または logb で始まり 拡張.log を持つすべてのファイルがモニターされます 最初のセットの () は その後のセグメントにワイルドカードがあるため正規表現としては取り扱われません 2 番 の () は 同じセグメント内にワイルドカード * があるため 正規表現として取り扱われます [monitor://var/.../log(a b).log] /var/ の任意のサブディレクトリ内にある 名前が loga.log および logb.log のすべてのファイルをモニターします 前のスタンザセグメントにワイルドカード... があるため (a b) は正規表現として取り扱われます [monitor://var/.../log[a-z0-9]*.log] /var/ の任意のサブディレクトリ内にある 以下の条件を満たすすべてのファイルをモニターします log で始まり 次に単 の 字 (A Z) または数字 (0 9) を含み 次に他の任意の 字を含み 次に.log で終了する 前のスタンザセグメントにワイルドカード... があるため [A-Z0-9]* は正規表現として取り扱われます 共通のディレクトリに対するワイルドカードを持つ複数のスタンザ 複数のスタンザにワイルドカードを使って 同じディレクトリ内の異なるファイルサブセットを指定すると インデックス作成動作が 盾する可能性があります 同じディレクトリ内の異なるファイルサブセットをモニターするには ディレクトリのトップレベルにモニター対象のファイルを含む単 のスタンザを作成し インデックスを作成するファイルを表 22

23 対単す正規表現に whitelist 属性を設定します 必要に応じて このマニュアルの イベント単位のソースタイプの優先設定 の説明に従ってソースタイプに優先する設定を います 例 /apache/foo/logs /apache/bar/logs /apache/bar/1/logs などをモニターするには : [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] ワイルドカードとホワイトリスト 重要 :Splunk でホワイトリストとブラックリストは 標準の PCRE 正規表現を使って定義します 前のセクションで説明したファイル パスの構 とは異なります ファイル パスにワイルドカードを指定する場合 Splunk はそのスタンザに対する暗黙の whitelist を作成します もっとも いワイルドカードがないパスがモニター スタンザになり 前述のテーブルのようにワイルドカードが正規表現に変換されます 注意 :Windows で whitelist と blacklist ルールは 円記号 ( バックスラッシュ ) を含む正規表現をサポートしていません 2 つの円記号 \\ を使って ワイルドカードをエスケープ処理する必要があります また 変換された正規表現は パス全体を照合するように ファイルパスの右端にアンカーされます たとえば 以下のように指定すると [monitor:///foo/bar*.log] Splunk はこれを以下のように変換します [monitor:///foo/] whitelist = bar[^/]*\.log$ ファイル でのホワイトリストの使 については ホワイトリストまたはブラックリスト固有の到着データ を参照してください ホワイトリストまたはブラックリスト固有の到着データ ディレクトリをモニターする場合 ホワイトリストおよびブラックリストルールを使って データを取り込むファイルを明 的に指 することができます また batch にこれらの設定を適 することもできます ホワイトリストを定義する場合 Splunk はそのリストに指定されているファイルのみインデックスを作成します ブラックリストを定義する場合 Splunk はリストに指定されているファイルを無視して 残りすべてのインデックスを作成します ホワイトリストとブラックリストは inputs.conf 内の特定の のスタンザに定義します ホワイトリストとブラックリストの両 を定義する必要はありません それぞれが独 した設定です 両 を指定して そのどちらにも該当するファイルがある場合 そのファイルのインデックスは作成されません blacklist の設定が whitelist の設定に優先されます ホワイトリストとブラックリストルールは正規表現構 を使って 照合するファイル名 / パスを定義します また ルールは [monitor://<path>] のように 設定スタンザ内に含める必要があります スタンザ外に指定されている ( グローバルエントリ ) の場合 それは無視されます データ にホワイトリスト / ブラックリストを指定する代わりに 特定のイベントをフィルタリングして 別のキューやインデックスに送信することができます データのルーティングやフィルタリングに関する記事を参照してください クロール (crawl) 機能を使って ファイルシステムに追加されたファイルのインデックスを作成する または作成しないファイルを事前定義することもできます 23

24 重要 : ホワイトリスト / ブラックリストエントリは 正しい正規表現構 を使って定義します パスへのワイルドカード... の使 はサポートされていません ( ここを参照 ) ホワイトリスト ( 許可 ) ファイル Splunk にインデックスを作成させるファイルを定義するには その が定義されている 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> 重要 : 無視する各ファイルに対して blacklist を作成すると Splunk は最後のフィルタのみを適 します 拡張.txt を持つファイルのみを無視してモニターの対象外にするには : [monitor:///mnt/logs] blacklist = \.(txt)$ 拡張.txt または (OR).gz を持つすべてのファイルを無視してモニターの対象外にするには ( この場合 を使 します ): [monitor:///mnt/logs] blacklist = \.(txt gz)$ モニター 下のディレクトリ全体を無視するには : [monitor:///mnt/logs] blacklist = (archive historical \.bak$) 上記の例は アーカイブまたは履歴ディレクトリ内の /mnt/logs/ 下のすべてのファイル および *.bak で終わるすべてのファイルを無視するように Splunk に指 しています 特定の 字列を含むファイルを無視する場合 : [monitor:///mnt/logs] blacklist = [8 9]file\.txt$ 上記の例は /mnt/logs/ 下の webserver file.txt および webserver file.txt ファイルを無視します Splunk によるログファイルのローテーションの取り扱い 24

25 Splunk はモニターしているファイル (/var/log/messages など ) がローテーション (/var/log/messages1) されると そのことを認識し そのローテーションにより名前が変更されたファイルは読み込みません 圧縮ファイルへのログローテーションへの対処対処 法 Splunk はログのローテーションにより 成された圧縮ファイル (bz2 や gz など ) が 圧縮前のオリジナルファイルと同じであることを認識できません そのため それらのファイルがモニター対象になる場合 データの重複が発 する可能性があります この問題を回避するには 2 種類の 法があります そのようなファイルを Splunk がモニターしていないディレクトリに移動するように ログのローテーションを設定する アーカイブのファイルタイプに対してブラックリストルールを設定して それらのファイルが新たなログファイルとして読み込まれることを防 する 例 : blacklist = \.(gz bz2 z zip)$ Splunk は 次のアーカイブファイルタイプを認識します :tar, gz, bz2, tar.gz, tgz, tbz, tbz2, zip z ブラックリストルールの設定の詳細は このマニュアルの ホワイトリストまたはブラックリスト固有の到着データ を参照してください 関連する問題として.gz ファイルなどの既存の圧縮形式アーカイブファイルに新しくデータを追加した場合 その新たなデータだけではなく ファイル内のすべてのデータのインデックスが再作成されます そのため イベントの重複が発 する可能性があります Splunk がログのローテーションを認識する仕組み モニタリングプロセッサは新しいファイルを選んで ファイルの先頭および最後の 256 バイトを読み取ります このデータが 開始および終了 CRC にハッシュ化されます Splunk はこの CRC を Splunk が以前に処理したすべてのファイルの CRC が含まれているデータベースでチェックします Splunk がファイル内で最後に読み込んだ場所 ( ファイルの seekptr) も保管されます CRC チェックの結果は 3 種類考えられます 1. データベース内に このファイルの開始 / 終了 CRC と 致する項 がない このことは 新しいファイルであることを意味しています Splunk はそのファイルの開始からデータを取り込みます データベースには新しい CRC が保管され またファイルの取り込み状況に応じて seekptr も保管されます 2. 開始 CRC と終了 CRC の両 がデータベースに存在しているが ファイルサイズが保管されている seekptr よりも きい これは 以前に Splunk がファイルを処理したことがあるけれども 最後の読み込み以降にデータが追加されたことを意味しています この場合 ファイルを開いて前回終了地点からデータの読み込みを開始します このようにして 新しいデータのみを取り込んで 以前に取り込んだデータの再読み込みを防 することができます 3. 開始 CRC は存在するけれども 終了 CRC が 致しない この場合 Splunk は以前にファイルを読み込んだことがあるけれども その後読み込んだ内容の 部が変更されたことを意味しています この場合 Splunk は ファイル全体を再読み込みする必要があります 重要 : CRC 開始チェックはファイルの最初の 256 バイトに対してのみ われるため 重複ではないファイルが同じ開始 CRC になる可能性があります ( 特にそれらのファイルのヘッダーが同じである場合など ) このような問題に対処するには : initcrclength 属性を使って CRC の算出に使 する 字数を増やす ( 上記の例では 同じヘッダーの さより きな値に増やす ) inputs.conf にファイルを設定する際に crcsalt 属性を使 する ( inputs.conf の編集 を参照 ) crcsalt 属性により 各ファイルが 意の CRC を持つことが保証されます ローテーションが われるログファイルにこの属性を使 したくないでしょうが この問題は Splunk のログローテーション認識機能だけでは対処できないため 同じデータのインデックスが再作成される可能性があります Get network events TCP および UDP ポートからのデータの取り込み 任意の TCP または UDP ポートからのデータを取り込むように Splunk を設定することができます Splunk はこれらのポートに送信されるデータを取り込むことができます syslog ( デフォルトのポートは UDP 514) にはこの 法を使 するか または netcat を設定してポートにバインドします TCP は Splunk のデータ配布に使 されるプロトコルで リモートマシンから Splunk サーバーにデータを送信する場合の推奨 段でもあります Splunk は syslog-ng や他の TCP 経由でデータを伝送するアプリケーションからの リモートデータのインデックスを作成することができます Splunk は UDP のモニタリングもサポートしていますが 可能な場合は TCP を使 することをお勧めします 般的に 25

26 UDP は 他にもさまざまな理由がありますが 特に配信が保証されないという点で 伝送 段としては望ましくありません UDP を使 する必要がある場合は Splunk コミュニティ Wiki の Working with UDP connections を参照してください Splunk Web を使ったネットワーク の追加 Splunk Web を使ってネットワークポートからの を追加するには : A. [ 新規追加 ] ページに移動 ネットワーク は Splunk Web の [ 新規追加 ] ページから追加します 2 種類の 法でこのページを表 できます Splunk 設定 Splunk ホーム どちらの 法を使 しても構いません 同じ [ 新規追加 ] ページが表 されます Splunk 設定を使 する場合 : 1. Splunk Web の右上にある [ 設定 ] をクリックします 2. [ 設定 ] ポップアップの [ データ ] セクションで [ データ ] をクリックします 3. [TCP] または [UDP] を選択します 4. [ 新規 ] ボタンをクリックして を追加します Splunk ホームを使 する場合 : 1. Splunk ホームの [ データの追加 ] リンクをクリックします [ データレシピ ] ページが表 されます 2. を追加するには [TCP ポートから ] または [UDP ポートから ] をクリックします B. ネットワーク の指定 1. ポート番号を します Splunk を実 するユーザーには ポートへのアクセス権が必要です ストック UNIX システムでは 1024 未満のポートで待ち受ける場合 Splunk を root として実 する必要があります 2. TCP の場合 ポートがすべてのホストからの接続を受け付けるか または 1 台のホストからの接続を受け付けるかを指定することができます 1 台のホストからの接続のみを受け付けるように指定する場合は [ すべてのホストからの接続を受け付けますか?] で [ いいえ 1 つのホストに制限します ] ラジオボタンを選択します 表 される [ ホスト制限 ] フィールドに ホスト名またはホストの IP アドレスを します 3. 必要に応じて [ ソース名 ] に デフォルト値に優先する新たなソース名を します 重要 : この値を変更する前に Splunk サポートにお問い合わせください 4. 他の設定にアクセスするには [ その他の設定 ] を選択します 追加の設定が表 されます 通常は これらの設定はデフォルト値のままで 分です 明 的に設定したい場合は 以下の説明を参照してください a. ラジオボタンを選択して ホストを設定できます IP: プロセッサが リモートサーバーの IP アドレスでホストを再書き込みするように設定します DNS: ホスト名にリモートサーバーの DNS エントリを設定します カスタム : ホストにユーザー定義ラベルを設定します b.[ ソースタイプ ] を設定することができます ソースタイプは イベントに追加されるデフォルトのフィールドです ソースタイプは タイムスタンプやイベント境界などの 処理する特徴の決定に いられます Splunk の 動ソースタイプ設定に優先する設定を うには このマニュアルの ソースタイプの 動割り当てに優先する設定 を参照してください c. インデックスを設定できます 異なる種類のイベントを取り扱うために 複数のインデックスを定義している場合を除き この値は default のままにしてください ユーザーデータ のインデックスに加えて Splunk にはさまざまなユーティリティインデックスが存在しています これらのインデックスも このドロップダウンボックスに表 されます 5. [ 保存 ] をクリックします CLI を使ったネットワーク の追加 Splunk の CLI を使 するには $SPLUNK_HOME/bin/ ディレクトリに移動して./splunk コマンドを使 します 26

27 何か分からないことがある場合 CLI にはヘルプが 意されています メインの CLI ヘルプにアクセスするには splunk help と します 各コマンドには それぞれ独 のヘルプページが 意されています splunk help <command> と してください ネットワーク の設定には 以下の CLI コマンドを使 できます コマンドコマンドの構 対処 add add tcp udp <port> [-parameter value]... <port> からの を追加します edit edit tcp udp <port> [-parameter value]... 前に追加した <port> の を編集します 削除 remove tcp udp <port> 前に追加したデータ を削除します list list tcp udp [<port>] 現在設定しているモニター を 覧表 します <port> は データを待ち受けるポート番号です Splunk を実 するユーザーには このポートへのアクセス権が必要です 以下のような追加パラメータを指定して 各 の設定を変更することができます パラメータ sourcetype index hostname remotehost resolvehost restricttohost 必須? いいえ いいえ いいえ いいえ いいえ いいえ 説明 ソースからのイベントの sourcetype フィールド値を指定します ソースからのイベントの 宛先インデックスを指定します ソースからのイベントの host フィールド値として設定するホスト名を指定します 排他的にデータを受け付ける IP アドレスを指定します True または False (T F) を設定します デフォルトは False です ソースからのイベントに対して DNS を使ってホストフィールドの値を設定する場合 True を設定します この が唯 接続を受け付ける ホスト名または 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>] 27

28 <attrbute1> = <val1> <attrbute2> = <val2>... このタイプの スタンザは <port> ( ポート ) で <remote server> ( リモートサーバー ) を待機するように Splunk に指 します <remote server> に何も指定しない場合 Splunk は指定ポート上ですべての接続を待機します 注意 :Splunk を実 するユーザーには 待機ポートへのアクセス権が必要です UNIX システムでは 1024 未満のポートで待ち受ける場合 root として実 する必要があります host = <string> ホスト / キーフィールドに このスタンザの静的な値を設定します ホストキーの初期値を設定します このキーは パーシング / インデックス作成時に使 されます ( 特に host フィールドの設定時 ) サーチ時に使 される host フィールドでもあります <string> の前には host:: が付けられます 明 的に設定しない場合 デフォルトではデータの起源となるホストの IP アドレスまたは完全修飾ドメイン名が使 されます index = <string> この からのイベントを保管するインデックスを設定します <string> の前には index:: が付けられます デフォルトは main またはデフォルトのインデックスとして設定した任意の値になります インデックスフィールドの詳細は インデクサーとクラスタの管理 マニュアルの インデックス作成の仕組み を参照してください sourcetype = <string> この からのイベントの sourcetype キー / フィールドを設定します このデータのソースタイプを 動的に判断する代わりに 明 的に宣 します このことは パーシングおよびインデックス作成中の このタイプのデータに対するサーチ可能性と関連するフォーマットの適 の両 で重要になります ソースタイプキーの初期値を設定します このキーは パーシング / インデックス作成時に使 されます ( 特に host フィールドの設定時 ) サーチ時に使 される source type フィールドでもあります <string> の前には sourcetype:: が付けられます 明 的に設定しない場合は データのさまざまな側 に基づいてソースタイプが選択されます ハードコード化されたデフォルト値はありません ソースタイプの詳細は このマニュアルの ソースタイプが重要な理由 を参照してください source = <string> この からのイベントの source キー / フィールドを設定します 注意 : source キーに優先する設定は 般的にお勧めできません 通常 レイヤーは データの取得場所を正確に記録し 問題の分析と調査を 援するために より正確な 字列を提供しています この値に優先する設定を う前に ソースタイプ タグ設定 およびワイルドカードを使ったサーチの使 を検討してください <string> の前には source:: が付けられます デフォルトは ファイルパスになります queue = [parsingqueue indexqueue] プロセッサが 読み込んだイベントをデポジットするかどうかを指定します データに props.conf および他のパーシングルールを適 する場合は parsingqueue を設定します データを直接インデックスに送信する場合は indexqueue を設定します デフォルトは parsingqueue です connection_host = [ip dns none] ip は ホストにリモートサーバーの IP アドレスを設定します dns は ホストにリモートサーバーの DNS エントリを設定します none は ホストを指定通りのまま放置します デフォルトは ip です TCP over SSL [tcp-ssl:<port>] 暗号化された未パーシングデータを フォワーダーまたはサードパーティ製のシステムから受信する場合にこのスタンザを使 します <port> には 暗号化された未パーシングデータを送信するフォワーダーまたはサードパーティ製システムのポートを設定します UDP [udp://<remote server>:<port>] 28

29 <attrbute1> = <val1> <attrbute2> = <val2>... このタイプの スタンザは TCP の場合と似ていますが UDP ポートで待機するという違いがあります 注意 : <remote server> を指定した場合 指定したポートはそのサーバーからのデータのみを受け付けます <remote server> が空の場合 ポート [udp://<port>] は任意のサーバーから送信されたデータを受け付けます host = <string> ホスト / キーフィールドに このスタンザの静的な値を設定します ホストキーの初期値を設定します このキーは パーシング / インデックス作成時に使 されます ( 特に host フィールドの設定時 ) サーチ時に使 される host フィールドでもあります <string> の前には host:: が付けられます 明 的に設定しない場合 デフォルトではデータの起源となるホストの IP アドレスまたは完全修飾ドメイン名が使 されます index = <string> この からのイベントを保管するインデックスを設定します <string> の前には index:: が付けられます デフォルトは main またはデフォルトのインデックスとして設定した任意の値になります インデックスフィールドの詳細は インデクサーとクラスタの管理 マニュアルの インデックス作成の仕組み を参照してください sourcetype = <string> この からのイベントの sourcetype キー / フィールドを設定します このデータのソースタイプを 動的に判断する代わりに 明 的に宣 します このことは パーシングおよびインデックス作成中の このタイプのデータに対するサーチ可能性と関連するフォーマットの適 の両 で重要になります ソースタイプキーの初期値を設定します このキーは パーシング / インデックス作成時に使 されます ( 特に host フィールドの設定時 ) サーチ時に使 される source type フィールドでもあります <string> の前には sourcetype:: が付けられます 明 的に設定しない場合は データのさまざまな側 に基づいてソースタイプが選択されます ハードコード化されたデフォルト値はありません ソースタイプの詳細は このマニュアルの ソースタイプが重要な理由 を参照してください source = <string> この からのイベントの source キー / フィールドを設定します 注意 : source キーに優先する設定は 般的にお勧めできません 通常 レイヤーは データの取得場所を正確に記録し 問題の分析と調査を 援するために より正確な 字列を提供しています この値に優先する設定を う前に ソースタイプ タグ設定 およびワイルドカードを使ったサーチの使 を検討してください <string> の前には source:: が付けられます デフォルトは ファイルパスになります queue = [parsingqueue indexqueue] プロセッサが 読み込んだイベントをデポジットするかどうかを指定します データに props.conf および他のパーシングルールを適 する場合は parsingqueue を設定します データを直接インデックスに送信する場合は indexqueue を設定します デフォルトは parsingqueue です _rcvbuf = <integer> UDP ポートの受信バッファ ( バイト ) を指定します 値が 0 または負の場合 それは無視されます デフォルトは 1,572,864 です 注意 : デフォルト値が OS にとって きすぎる場合 Splunk は /2 の値を使 します この値でも失敗する場合は /(2*2) を使って再試 が われます 処理が成功するまで 値を半分に減らして再試 が われます no_priority_stripping = [true false] syslog データ受信 設定 この属性に真 (True) を設定すると 受信したイベントから <priority> syslog フィールドは除去されません この属性に応じて イベントのタイムスタンプには異なる設定が われます 真 (True) を設定した場合 ソースから取得されたタイムスタンプがそのまま使 されます 偽 (False) を設定した場合 イベントにはローカル時刻が割り当てられます デフォルトは偽 (False) です (<priority> が除去される ) no_appending_timestamp = [true false] 29

30 この属性に真 (True) を設定した場合 受信イベントにタイムスタンプとホストは追加されません 注意 : 受信したイベントにタイムスタンプとホストを追加したい場合 この属性を指定しないでください デフォルトは偽 (False) です UDP パケットと の結合 各 UDP パケットが個別のイベントとして インデックスが作成されるとお考えかもしれません しかし そのようにはなりません 明確なタイムスタンプがない場合 Splunk はデータストリームのイベントの結合を実 し 各イベントが結合されます 1 のイベントの場合 props.conf でそのソースタイプを編集して SHOULD_LINEMERGE 属性に false に設定することで この問題を防 することができます そのようにすることで パケットの結合を回避できます Answers 何か質問がありますか?Splunk Answers をご覧ください ここには Splunk コミュニティに寄せられた UDP TCP および他の に関する質問と回答が記載されています Splunk への SNMP イベントの送信 重要 : このトピックに記載されている 順は (*nix と Windows の両 ) 単なる例です Splunk に SNMP を送信する 法は 順は他にも存在しています たとえば Net-SNMP の代わりに Snare や SNMPGate などのツールを使って Splunk でモニターする SNMP トラップをファイルストレージに書き込むことができます SNMP トラップは リモートデバイスが 成するアラートです このトピックは Splunk インデクサーでの SNMP トラップの受信とインデクサーの作成 法について説明しています 注意 :Network Management System コンソールなどの 他のシステムに SNMP アラートを送信するためのモニタリングツールとして Splunk を使 する 法については 管理マニュアル の 他のシステムへの SNMP トラップの送信 を参照してください SNMP トラップのインデックス作成 法 SNMP トラップのインデックスを作成するもっとも効率的な 法は まず SNMP トラップを Splunk サーバー上のファイルに書き込むことです 次に Splunk がそのファイルをモニターするように設定します この作業は 3 つのステップから成り っています 1. リモートデバイスがトラップを Splunk サーバーの IP アドレスに直接送信するように設定します SNMP トラップのデフォルトポートは udp:162 です 2. このトピックで後述するように SNMP トラップを Splunk サーバー上のファイルに書き込みます 3. ファイルとディレクトリのモニター の説明に従って ファイルをモニターするように Splunk を設定します 注意 : このトピックでは リモートデバイスにポーリングを う SNMP ポーリングについては説明していません SNMP トラップの Splunk サーバー上のファイルへの書き込み 重要 : 以下の 順は (*nix と Windows の両 ) 単なる例です Splunk に SNMP を送信する 法は 順は他にも存在しています たとえば Net-SNMP の代わりに Snare や SNMPGate などのツールを使って Splunk でモニターする SNMP トラップをファイルストレージに書き込むことができます SNMP ソフトウェアの詳細は SNMP ポータル ( Web サイトを参照してください *nix の場合 *nix 上では Net-SNMP プロジェクトの snmptrapd を使って ファイルに SNMP トラップを書き込めます システムに snmptrapd をインストールする前に 以下のドキュメントを参照してください ご利 のディストリビューションのツールパッケージ ( 使 している *nix ディストリビューションによって異なります たとえば Red Hat または CentOS Linux の場合 net-snmp RPM パッケージを利 できます 利 できるインストーラパッケージがない場合 ソースファイルからパッケージをビルドしなければならないことがあります ) のローカルドキュメント snmptrapd の man ページ もっとも単純な設定 : 30

31 # 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 コマンドを使って 以下のようにサンプルトラップを 成することができます # 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 Get Windows data リモート Windows データのモニター 法決定の検討事項 Splunk は リモート Windows データのインデックス作成 サーチ およびレポート 成を うための 強 な機能を提供しています ただし 他のソフトウェアと同様に Splunk を有効活 するには 念なプランニングを う必要があります このことは 特にリモート操作を う場合に重要です 最終 標は最低限のリソースを使って データを最 限 31

32 に活 することにあります このトピックは 多数の Windows ホストからのリモートデータのインデックスを作成する場合に 最 限の効率を達成するための Splunk コンポーネントのデプロイ 法を決定するために役 つ情報を説明しています リモート Windows データの概要 Splunk はインデックス作成 のリモート Windows データを 2 種類のいずれかの 法で収集します WMI 経由 Splunk フォワーダーから WMI の使 WMI フレームワークを利 して リモート Windows マシンから実質的に任意の種類のデータを収集することができます この構成では Splunk をインストール時に指定した ( または後で [ サービス ] コントロールパネルで指定した ) ユーザーとして実 します この構成では : 指定したアカウントがリモートアクセス に保有している 最 限のネットワークアクセスが Splunk に与えられます 全社規模でリモート Windows マシンからデータが収集され そのデータが集中リポジトリに保管されます 各ネットワークセグメントに最低 1 台のインデクサーが存在する 中規模ネットワークに適しています ただし この 法では収集に関するいくつかの注意事項があります このトピックの フォワーダーと WMI を参照してください 注意 :Active Directory (AD) モニタリングは WMI を使 しませんが 使 するデータ について同じ認証上の検討事項が存在しています Splunk が Active Directory をモニターする仕組みについては このマニュアルの Active Directory のモニター を参照してください ユニバーサルフォワーダーの使 フォワーダーを使ってリモート Windows データを収集することもできます ライトフォワーダー ヘビーフォワーダー およびユニバーサルフォワーダーの 3 種類のフォワーダーが存在しています ほとんどの場合 ユニバーサルフォワーダーを使 します ユニバーサルフォワーダーの詳細は データの転送 マニュアルの ユニバーサルフォワーダーの紹介 を参照してください 可能な場合はいつでも リモート Windows データの収集にユニバーサルフォワーダーを使 することをお勧めします ユニバーサルフォワーダーを使 する利点を以下に します ユニバーサルフォワーダーは インストールされているマシンのネットワーク / ディスクリソースの消費を最低限に抑えるように設計されています ユニバーサルフォワーダーを Local System ユーザーとしてインストールすると インストールされているマシン上のすべてのデータにアクセスできます また データを取得するために WMI では必要な 認証を受ける必要がありません 規模環境にも柔軟に対応でき デプロイも 較的簡単です System Center Configuration Manager (SCCM) や Systems Management Server (SMS) などの Microsoft のデプロイツール または BigFix/Tivoli のようなサードパーティ製の分散ソリューションを使 して 動でデプロイすることができます ユニバーサルフォワーダーをインストールすると フォワーダーは情報をローカルに収集して それを Splunk インデクサーに送信します 収集するデータはインストール時に または後ほどデプロイサーバー経由で設定の更新情報を配布して フォワーダーに指 します ネットワーク構成やレイアウトによっては ユニバーサルフォワーダーの使 にいくつかの 点が出ることもあります このトレードオフについては このトピックの フォワーダーと WMI を使ったリモート収集の 較 を参照してください WMI 経由でリモートデータを収集しますか? お読みください WMI 経由でリモート Windows データを収集する場合 それに関するいくつかの重要な問題を考慮する必要があります リモート Windows データの認証 Windows では 実 する各リモートアクティビティに対して認証が必要になります Windows 環境で Splunk を使 する場合は特に この重要な概念を正しく理解しておく必要があります ネットワーク経由で Splunk が Windows とどのようなやり取りを うのかを正しく理解しないと 最適なサーチ結果を得られない または何も結果が得られない可能性があります ここでは リモート Windows データを Splunk に取り込む際の さまざまなセキュリティ上の要因について説明していきます Splunk をインストールする際に Local System ユーザーまたは他のユーザーを指定することができます インストール時に うこの選択が及ぼす影響は インストールマニュアル に記載されていますが データの取り込みにおいても考慮事項が存在しています Splunk を実 するユーザーの指定は Splunk がリモートデータから取得できるデータのタイプや量に直接的な影響を与 32

33 えます 的のデータを取得するために 指定するユーザーにはリモートデータにアクセスするために 適切なアクセス許可を割り当てる必要があります もっとも簡単な 法は Splunk を実 するユーザーを Administrators ( または Domain Admins) グループのメンバーにすることです ただし セキュリティを考慮するとこの 法にも問題があり Active Directory の設定によっては この 法を う権限がないこともあります たいていの場合 Splunk ユーザーアカウントには データソースにアクセスするために必要な 最低限のレベルのアクセス許可 / 権限を割り当てる必要があります この必要最低限のアクセス権を与える 法は 以下の作業を伴います ユーザーをさまざまなドメインセキュリティグループに追加するアクセスする必要があるデータソースに応じて 各種 Active Directory オブジェクトのアクセス制御リストを変更する Active Directory ドメインセキュリティポリシーが 定期的なパスワードの変更を強制している場合は 以下の作業も必要になります Splunk アカウントのパスワードが失効しないように設定されていることを確認するか またはポリシーに定義されているように パスワード失効前にパスワードを 動で変更する パスワードを変更したら ネットワーク上のすべてのサーバーで そのアカウントとして動作している Splunk サービスを再起動する 注意 : 最新版の Windows サーバーでは 管理されたサービスアカウント (MSA) を使って パスワード失効に関する問題に対処することができます 詳細は インストールマニュアル の Windows Server 2008 および Windows 7 での管理されたサービスアカウント を参照してください また ユーザーが対話形式でログインすることを防 するために ローカルセキュリティポリシーで Splunk アカウントに ユーザー権利の割り当て [ ローカルでログオンを拒否する ] を設定することもお勧めできます この 法は当初は作業に時間がかかりますが よりきめ細かく管理でき またドメイン管理者としてのアクセス権を与えるよりも安全です このマニュアルの Windows マシンへのリモートアクセスについて取り上げている各トピックには Splunk を実 するユーザーに最低限のアクセス許可 / 権限を設定するための追加情報や推奨事項が記載されています これらのページの セキュリティとリモートアクセスの検討事項 セクションを参照してください ネットワークと I/O 使 に関する検討事項 ネットワーク帯域幅の使 状況は 念にモニターする必要があります ( 特に低速の WAN リンクを利 しているネットワークの場合 ) この理由からだけでも 量のリモート収集操作を う場合は 半の環境でユニバーサルフォワーダーが最善の選択肢になります ディスク帯域幅も重要な考慮事項です ウィルス対策ソフトウェアのドライバ および Splunk とオペレーティングシステム間を中継するドライバは Splunk のインストールタイプに関係なく 常に Splunk ディレクトリとプロセスを無視するように設定する必要があります Splunk フォワーダーと WMI リモート Windows ホストからデータを収集するための推奨 段は ユニバーサルフォワーダーを使 することです これは ユニバーサルフォワーダーは 部分の種類のデータソースに対応しており ネットワークのオーバーヘッドを最 限に抑え 運 上のリスクと複雑さを低減できる ( 特に認証を考慮する必要がある場合 ) ことが理由です また多くの場合 環境の拡張にも WMI よりも柔軟に対応できます ただし リモート収集の が好ましい または必須な状況も存在しています たとえば 企業規則やセキュリティ規則で 実働環境のマシン上で実 できるコードが制限されている場合 または利 しているソフトウェアとの間にパフォーマンスや相互運 性の問題がある場合 ( 例 : ウィルス対策ソフトウェアをアクティブにする必要があるシステム ) などが挙げられます このような状況では ネイティブの WMI インターフェイスを使って イベントログやパフォーマンスデータを収集することができます WMI とフォワーダーの主なトレードオフを以下に します パフォーマンスデプロイ管理 パフォーマンス パフォーマンスの点では 以下の場合にフォワーダーの が適しています ローカルイベントログまたはフラットファイルを収集している これは フォワーダーの が CPU の消費が少なく ネットワークのオーバーヘッドを減らすために データの基本的な事前圧縮を うためです 認証の問題に悩まされることなく マシンからデータを収集したい場合 フォワーダーを Local System ユーザーとしてインストールした場合 そのマシンに対しては管理者権限でアクセスできます そのため そのマシン上で利 可能な任意のデータを収集することができます ドメインコントローラ Active Directory 操作マスター または 貫して負荷が くなる期間が存在するようなマシンなどの 処理負荷が いホストからデータを収集する場合 これには Exchange SQL Server/Oracle 33

34 VMWare/VSphere/VCenter Hyper-V またはし SharePoint などの リソースを消費するアプリケーションを実 しているサーバーも含まれます WMI では これらのサービスが 成するデータ量に追随できない可能性があります 設計上 WMI のポーリングはベストエフォート型で また Splunk も意図しないサービス拒否攻撃を防 するために WMI を抑制します データの収集を うマシン上の CPU およびネットワークの使 量が関 事項の場合 フォワーダーはこれらのリソースの消費を最低限に抑えるように設計されていますが WMI は同じデータ量に対してより CPU を消費します また WMI は データをインデクサーに送信する際にも より多くのネットワークリソースを消費します スケーラビリティが関 事項の場合 ユニバーサルフォワーダーは環境の拡張にも柔軟に対応できます ヘビーフォワーダーはユニバーサルフォワーダーほど柔軟には対応できませんが どちらのフォワーダーも WMI よりは 幅に柔軟に対応することができます WMI の が適している場合を以下に します デプロイ メモリー使 量が いシステム上で メモリー消費量が関 事項の場合 フォワーダーはデータの収集時にローカルマシンに常駐し より多くのポーリングオプションが 意されているため WMI よりも多くのメモリーを消費します デプロイにフォワーダーが適している場合を以下に します システムイメージの作成時など OS のベースビルドを管理している場合 収集するデータソース数が多い場合 ( 特に データの収集時に何らかの変換が必要な場合 ) 注意 : ユニバーサルフォワーダーの場合 インデクサーにデータを転送する前に何らかの 法でデータを処理することはできません インデックス作成前にデータを変更する必要がある場合は ヘビーフォワーダーを使 する必要があります WMI の が適している場合を以下に します ベース OS ビルドを管理していない またはドメイン管理者アクセス権がない またはデータを収集するマシンのローカル Administrotor 権限がない 多数のホストから わずかなセットのデータしか必要ない場合 ( 例 : 使 状況により課 するための CPU データの収集 ) 般的なデプロイのシナリオでは まずリモートポーリングを使ってテストを った後 正常なまたは有益なデータ をフォワーダー設定に追加する ( または 括デプロイ時 ) 管理 どちらの 法でも ログとアラート機能を使って ホストが起動または停 した時 または接続できなくなったことを知らせることができます ただし Splunk では意図しないサービス拒否攻撃を防 するために WMI ポーリングサービスは 定期間ホストと通信できなかった場合 ポーリングの頻度が徐々に減少し 最終的には通信できなくなったホストへのポーリングを中 します そのため ラップトップや動的にプロビジョニングされる仮想マシンなどの 頻繁にオフラインになるマシンに対して WMI によるリモートポーリングを使 しないことをお勧めします データソースの 覧と 各データソースに適したデータ収集タイプを以下の表に します データソースと収集 法 データソースローカルフォワーダー WMI イベントログはいはい * パフォーマンスはいはい レジストリはいいいえ Active Directory はいいいえ ログファイルはいはい ** クロールはいいいえ * リモートイベントログの収集の場合 収集するイベントログの名前を知っている必要があります ローカルフォワーダー上では 名前に関係なくすべてのログを収集するオプションがあります ** Splunk は \\SERVERNAME\SHARE の構 によるリモートログファイルの収集をサポートしています ただし アプリケーション層ファイルアクセスプロトコルとして CIFS (Common Internet File System またはサーバーメッセージブロック ) を使 する必要があり また Splunk には共有とそのファイルシステムの両 に対して 最低でも読み取りアクセス権を保有している必要があります Windows 版以外の Splunk インスタンス上での Windows データのサーチ Windows 版以外の Splunk インスタンス上で Windows データのインデックス作成とサーチを えますが その場合はまず Windows 版の Splunk インスタンスを使って Windows データを収集する必要があります そのためには Windows コンピュータに Splunk フォワーダーをインストールして その Windows データを Windows 版 Splunk インスタンスに転送するように設定します 34

35 作業を うには 主に 2 種類の 法があります データを収集する各 Windows マシン上に ローカルにフォワーダーを設定する これらのフォワーダーは Windows データを Windows Splunk インスタンスに送信することができます フォワーダーを 1 台の Windows マシン上に設定する フォワーダーは WMI を使って 環境内のすべての Windows マシンからデータを収集することができます 次に収集したデータを Windows 版 Splunk インスタンスにまとめて転送します Windows 版 Splunk インスタンスが 明 的に Windows データを処理するように設定する必要があります 詳細は データの転送 マニュアルの 異なるオペレーティングシステムが動作するフォワーダーから受信したデータのサーチ を参照してください フォワーダーの設定については データの転送 マニュアルの 転送と受信の設定 を参照してください Active Directory のモニター Active Directory (AD) は Windows ネットワークの中核を為しています Active Directory データベース (NT ディレクトリサービス (NTDS) データベース ) は Active Directory ドメイン / フォレスト内のユーザー コンピュータ ネットワーク デバイス およびセキュリティオブジェクトの集中リポジトリです ユーザー メンバーサーバー またはドメインコントローラの追加や削除など Active Directory を変更する場合 それらの変更を記録することができます Splunk では これらの変更をモニターし リアルタイムにアラートを 成することができます Active Directory モニタリングを設定して Active Directory フォレストに対する変更を監視し ユーザーとマシンのメタデータを収集することができます この機能と動的リストルックアップを組み合わせて Active Directory で利 できる情報をイベントに追加 変更することができます Active Directory をモニターするように Splunk を設定したら Active Directory データと Active Directory スキーマのベースラインスナップショットが取得されます このスナップショットを取得して モニターの開始点を確 します この処理が完了するまで 少し時間がかかる場合があります Active Directory モニタリング は splunk-admon.exe と呼ばれる別個のプロセスとして実 されます Splunk に定義されている各 Active Directory モニタリング に対して 1 回実 されます Active Directory の監視理由 Active Directory の整合性 セキュリティ およびヘルスの維持管理を担当している場合 々どのような作業が われているのかを把握することが重要になります Splunk では 誰がまたは何が変更をいつ ったのかなど Active Directory の変更内容を確認することができます このデータをレポートに変換して 企業のセキュリティコンプライアンスや法的証拠として利 することができます また 取得したデータから侵 検知アラートを利 して 不正 為に即座に対処することができます さらに インデックス作成したデータからヘルスレポートを作成し 操作マスターロール Active Directory レプリカ およびグローバルカタログの割り当てなどの 将来の Active Directory インフラのプランニングに活 することができます Active Directory のモニターに何が必要か Active Directory スキーマのモニターに必要な 明 的なアクセス許可の 覧を以下の表に します アクティビティ : 必要なアクセス許可 : Active Directory スキーマをモニター * Splunk は Windows 上で実 する必要があります * Splunk はドメインユーザーとして実 する必要があります * Splunk を実 するユーザーには モニター対象のすべての Active Directory オブジェクトに対する読み取りアクセスが必要です Active Directory モニターの検討事項 Splunk を使った Active Directory のモニターで最良の結果を引き出すために 以下の事項に注意してください この機能は Splunk 版の Windows でのみ利 できます *nix 版の Splunk で Active Directory の変更をモニターすることはできません ( ただし Windows 版の Splunk で収集したデータを *nix インデクサーに転送することは可能です ) Active Directory モニタリングプロセスは 完全版 Splunk インスタンスまたは任意の種類のフォワーダーで実 することができます Active Directory への変更をモニターするマシンは モニター対象のドメインまたはフォレストに所属している必要があります Splunk を実 するユーザーも ドメインの 部である必要があります このことは ユーザーが保有しているアクセス許可により Splunk がモニターできる Active Directory の部分が決まるためです Windows データをリモートにモニターする 法を決定する際に役 つその他の情報については このマニュアルの リモート Windows データのモニター 法決定の検討事項 を参照してください インストール時に指定する Splunk を実 するユーザーの決定に関する情報については インストールマニュアル の Splunk を実 するためのユーザーの選択 を参照してください 35

36 Active Directory モニタリングの設定 Splunk Web を使って または設定ファイルを編集して Active Directory モニタリングを設定することができます 設定ファイルを使 する場合は 複数のドメインコントローラのモニター設定などのオプションを利 することができます Splunk Web を使った Active Directory モニタリングの設定 1. Splunk Web の右上にある [ 設定 ] をクリックします 2. [ データ ] で [ データ ] をクリックします 3. [Active Directory モニタリング ] をクリックします 4. [ 新規 ] をクリックして を追加します 5. Active Directory モニター の 意の名前を します 6. Splunk が Active Directory をモニターするためにバインドする ターゲットドメインコントローラの名前を します 注意 :Splunk が最寄りのドメインコントローラを 動検出するように指 する場合は このフィールドを空にしてください 7. Active Directory 内のどこからデータのモニタリングを開始するのかを指 するために 開始ノードの名前を します ディレクトリツリー内の利 可能な最上位の部分から Active Directory オブジェクトをモニターする場合は このフィールドを空にしてください 注意 :Splunk を実 するユーザーが Splunk の表 に与える影響を学習するには リモート Windows データのモニター 法の検討事項 を参照してください 8. [ 参照 ] ボタンをクリックして 参照できる Active Directory オブジェクトのツリーを表 し 的のオブジェクトを選択することもできます 9. [ 参照 ] ボタンをクリックした場合 [Active Directory] ウィンドウが表 されます このウィンドウには Splunk がアクセス可能な Active Directory ツリーの最上位から Active Directory コンテナとオブジェクトが表 されます モニターする Active Directory コンテナまたはオブジェクトを選択した後 [ 選択 ] をクリックしてウィンドウを閉じます 注意 : コンテナはフォルダで オブジェクトはドキュメントアイコンで表されます コンテナまたはオブジェクトを選択した場合 ウィンドウの下部にある [ 修飾名 ] に修飾名が表 されます 10. ステップ 7 9 で指定した開始ノード下の ノードもモニターする場合は [ モニターサブツリー ] を選択します 11. の宛先インデックスを選択します 12. [ 保存 ] をクリックします が追加され 有効になります 設定ファイルを使った Active Directory モニタリングの設定 Active Directory モニタリング設定は inputs.conf で います %SPLUNK_HOME%\etc\system\local ディレクトリ内の このファイルのコピーを編集するようにしてください デフォルトディレクトリにあるファイルを編集すると 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 変更データを収集します それを許容できる場合は それ以上の設定は不要です inputs.conf の設定 inputs.conf には 各 Active Directory モニタリング に対して 1 つのスタンザが含まれており ヘッダーは以下のようになっています [admon://<name of stanza>] 各スタンザで 以下の項 を指定することができます 属性 必須? 36 説明

37 targetdc はい Active Directory モニタリングに使 するドメインコントローラの 意の名前 以下の場合に この属性に 意の名前を指定します 常に きな Active Directory が存在しており 特定の組織単位 (OU) やサブドメインなどの情報のみをモニターしたい場合 セキュリティが 常に 度な環境で モニタリング 的で使 できる特定の ( 読み取り専 ) ドメインコントローラがある場合 推移性の信頼がある複数のドメインまたはフォレストが存在しており Splunk が常駐しているツリー以外のツリーを対象にしたい場合 複数のドメインコントローラを対象にするように 複数の Active Directory モニタリング を設定する場合 たとえば 分散環境で Active Directory レプリケーションをモニターする場合が挙げられます 注意 : 複数のドメインコントローラを対象にする場合 ツリーに他のターゲットの [admon://<uniquename>targetdc] スタンザを追加してください startingnode いいえ Active Directory ツリー内で Splunk がインデックスの作成を開始する場所を す 完全修飾 LDAP 名 ( 例 :"LDAP://OU=Computers,DC=ad,DC=splunk,DC=com")Splunk はそこから開始して monitorsubtree 属性の設定に応じてサブコンテナを列挙します startingnode が指定されていない場合 または空の場合 Splunk はアクセス可能な最上位の root ドメインから Active Directory データのモニタリングを開始します 注意 :Splunk が正常に Active Directory データを収集するために startingnode の値は 対象としているドメインコントローラのスコープ内でなければなりません monitorsubtree baseline index disabled いいえ いいえ いいえ いいえ インデックスを作成するターゲット Active Directory コンテナの量 0 の場合 ターゲットコンテナのみのインデックスが作成され そのコンテナのサブコンテナは対象にはなりません 1 の場合 Splunk がアクセス可能なすべてのサブコンテナとドメインが列挙されます デフォルトは 1 です 初回実 時に が既存の利 可能なすべての Active Directory オブジェクトを列挙するかどうか 0 の場合 ベースラインは設定されません 1 の場合は ベースラインが設定されます デフォルトは 1 です ( ベースラインを設定 ) Active Directory モニタリングデータを送信するインデックス 指定しない場合は default インデックスになります Splunk が を実 するかどうか 0 の場合 が有効なことを 1 の場合 が無効なことを Splunk に指 します デフォルトは 0 ( 有効 ) です Active Directory モニタリング設定の例 admon.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 37

38 [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 変更イベントが存在しています これらのイベントの例は後述しています これらのイベントのコンテンツの 部は 公開のために曖昧化または変更されています 更新イベント Active Directory オブジェクトが何らかの 法で変更されると Splunk はこのタイプのイベントを 成します Splunk はこの変更を タイプ admoneventtype=update として記録します 2/1/10 3:17: PM 02/01/ :17: 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= samaccountname=stuff2 logoncount=4216 accountexpires= objectsid=s 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= usncreated= 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: PM 38

39 02/01/ :11: 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= usncreated= instancetype=4 Additional Details: dscorepropagationdata= z Z Z Z 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: PM 02/01/ :11: dcname=ftw.ad.splunk.com admoneventtype=sync Names: name=ntds Settings distinguishedname=cn=ntds Settings,CN=stuff,CN=Servers,CN=Default-First-Site- Name,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= 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 39

40 SchemaName=LDAP://stuff.splunk.com/schema/nTDSDSA スキーマイベント Active Directory モニタリングを設定した後 Splunk を起動すると スキーマタイプイベント admoneventtype=schema が 成されます このイベントは Active Directory 構造内の各オブジェクトの定義を表しています 各 Active Directory オブジェクトの 利 可能 必須 およびオプションフィールドが記載されています これらのフィールドのすべてを参照できない場合は Active Directory に問題がある可能性を 唆しています 02/01/ :11: 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 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 40

41 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 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 は Windows イベントログのモニタリングもサポートしています イベントログチャネルやローカルマシンに保管されているログファイルをモニターしたり リモートマシンからログを収集したりすることができます Splunk のイベントログモニターは splunkd サービス内の プロセッサとして実 されます Splunk に定義されている各イベントログ に対して 1 回実 されます イベントログをモニターする理由 41

42 Windows イベントログは Windows サーバーの運 に関する中 的な測定基準です Windows システムに何か問題がある場合は おそらくイベントログにそれに関する情報が記載されています Splunk のインデックス作成 サーチ およびレポート機能により ログに 軽にアクセスできます 場合によってはイベントビューアよりも役に ちます イベントログのモニターに何が必要か アクティビティ : 必要なアクセス許可 : ローカルイベントログのモニター リモートイベントログのモニター * Splunk は Windows 上で実 する必要があります * すべてのローカルイベントログを読み取るには Splunk を Local System ユーザーとして実 する必要があります * Splunk は Windows 上で実 する必要があります および * Splunk は イベントログを収集するサーバー上にインストールされている ユニバーサルフォワーダー上で動作する必要があります または * ターゲットサーバー上の WMI への読み取りアクセスを持つドメインまたはリモートユーザーとして Splunk を実 する必要があります * Splunk を実 するユーザーには 的のイベントログへの読み取りアクセスが必要です セキュリティとリモートアクセスの検討事項 Splunk は WMI またはフォワーダーを使って リモートマシンからイベントログデータを収集します リモートマシンからインデクサーへのイベントログデータの送信には ユニバーサルフォワーダーを使 することをお勧めします イベントログデータを収集するための フォワーダーのインストール 設定 使 法については データの転送 マニュアルの ユニバーサルフォワーダーの紹介 を参照してください イベントログデータを収集するために リモートマシン上にフォワーダーをインストールする場合 それらのマシンにはフォワーダーを Local System ユーザーとしてインストールすることができます Local System ユーザーは ローカルマシン上のすべてのデータにアクセスできますが リモートマシンにアクセスすることはできません WMI を使ってリモートマシンからイベントログデータを収集する場合 ネットワークと Splunk インスタンスが適切に設定されていることを確認する必要があります Splunk を Local System ユーザーとしてインストールすることはできません また インストールするユーザーによって Splunk が参照できる 連のパフォーマンス測定基準が決まります Splunk が WMI を使ってリモートデータを適切に収集するために 満たす必要がある要件については このマニュアルの WMI ベースのデータのモニター の セキュリティとリモートアクセスの検討事項 を参照してください デフォルトでは 部の Windows イベントログへのアクセスが制限されています ( ご利 のバージョンの Windows による ) 特に デフォルトでセキュリティイベントログは ローカル Administrators またはグローバル Domain Admins グループのメンバーのみが参照することができます リモート Windows マシンからのイベントログの収集 Splunk を使ってリモートマシンからイベントログを収集する場合 2 種類の選択肢があります WMI を使ってリモートにログを収集する Splunk Web で [ リモートイベントログの収集 ] を選択すると この 法を使 することになります 収集するログがあるマシン上に ユニバーサルフォワーダーをインストールする WMI を使ってイベントログを収集する場合 Splunk を 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 経由でリモートにログを収集した場合にのみ発 します 42

43 Splunk Web を使ったイベントログのモニタリング ローカルイベントログのモニタリングの設定 1. Splunk Web の右上にある [ 設定 ] をクリックします 2. [ データ ] で [ データ ] をクリックします 3. [ ローカルイベントログの収集 ] をクリックします 4. [ 新規追加 ] をクリックして を追加します 5. [ 利 可能なログ ] のリストから 1 つまたは複数のログを選択した後クリックして [ 選択したログ ] のリストに追加します 注意 : 特定の Windows イベントログチャネル ( 直接チャネル ) は モニターのためのユーザーのアクセスまたは購読を許可していません これらのログチャネル経由で送られるイベントは 実際に Windows イベントログフレームワークで処理される訳ではなく そのためリモートに転送または収集することはできません 般的にこれらの直接チャネルは 直接ディスクに書き込まれます これらのログチャネルにモニターを試みると 呼び出し元が直接チャネルを購読しようとしていますが これは許可されていません エラーが 成されます 6. [ 保存 ] をクリックします が追加され 有効になります リモートイベントログのモニタリングの設定 1. Splunk Web の右上にある [ 設定 ] をクリックします 2. [ データ ] で [ データ ] をクリックします 3. [ リモートイベントログの収集 ] をクリックします 4. [ 新規追加 ] をクリックして を追加します 5. このコレクションに対して 意の名前を します 6. 取得するログがあるホストのホスト名または IP アドレスを指定し [ ログの検索...] をクリックして ログのリストを表 します ここから ログを選択します 注意 : Windows Vista には すべてのバージョンの Windows に定義されている標準セットのチャネルに加えて 他にも多数のイベントログチャネルが 意されています Splunk が利 できる CPU によっては すべてまたは多数を選択すると システムが過負荷状態になる可能性があります 7. 必要に応じて データを取得する他のサーバーをカンマ区切りリストで指定します 8. [ 保存 ] をクリックします が追加され 有効になります inputs.conf を使ったイベントログモニタリングの設定 inputs.conf を使ってイベントログのモニタリングを設定することができます inputs.conf を使ったデータ の設定の詳細は このマニュアルの の設定 を参照してください 注意 : 設定ファイルのデフォルトは %SPLUNK_HOME%\etc\system\default 内のファイルまたは 管理マニュアル で確認することができます 設定ファイルの編集 法については 管理マニュアル の 設定ファイルについて を参照してください inputs.conf を編集してイベントログ を有効にするには : 1. inputs.conf を %SPLUNK_HOME%\etc\system\default から etc\system\local にコピーします 2. エクスプローラまたは ATTRIB コマンドを使って ファイルの読み取り専 フラグを削除します 3. ファイルを開いて編集し Windows イベントログ を有効にします 4. Splunk を再起動します 次のセクションでは イベントログのモニタリングのための 特定の設定値について説明していきます イベントログモニターの設定値 Windows イベントログ (*.evt) ファイルはバイナリ形式です 標準のテキストファイルのようにモニターすることはできません splunkd サービスは 適切な API を使ってこれらのバイナリファイルを読み取り ファイル内のデータのイン 43

44 デックスを作成しています Splunk は inputs.conf 内の以下のスタンザを使って デフォルトの Windows イベントログをモニターします # Windows platform specific input processor. [WinEventLog:Application] disabled = 0 [WinEventLog:Security] disabled = 0 [WinEventLog:System] disabled = 0 また デフォルト以外の Windows イベントログをモニターするように Splunk を設定することもできます 作業を う前に ログを 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 を追加します セキュリティイベントログを使ったファイル変更のモニター システム上のファイル変更をモニターするには 連のファイル / ディレクトリのセキュリティ監査を有効にして 次にセキュリティイベントログチャネルの変更イベントをモニターします イベントログモニタリング には 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 = , # exclude these event IDs from being indexed. blacklist = 連のファイル / ディレクトリのセキュリティ監査を有効にするには MS Technet の セキュリティイベントの監査の操作 法 ( を参照してください また 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 = , # exclude these event IDs from being indexed. blacklist =

45 デフォルトで suppress_text は 0 ( 偽 (False)) です イベントログファイル内の 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 属性を使 します evt_dc_name 属性に指定する 字列は ドメインコントローラの NetBIOS 名または完全修飾ドメイン名 (FQDN) を表していなければなりません どちらの種類の名前でも 必要に応じて前に 2 字の円記号 ( バックスラッシュ ) を付けることができます 正しい形式のドメインコントローラ名を使 した例を以下に します 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 はまず属性に指定されているドメインコントローラを使 して SID および GUID の解決を試みます そのドメインコントローラを使って SID を解決できなかった場合 デフォルトのドメインコントローラにバインドして解決を試みます SID を解決するためのドメインコントローラと通信できなかった場合は 次にローカルマシンを使った解決が試みられます これらの 段がどれも利 できなかった場合 Splunk はイベントに捕捉された SID を出 します Splunk は S-1-N-NN-NNNNNNNNNN-NNNNNNNNNN-NNNNNNNNNN-NNNN の形式ではない SID を解決することはできません Splunk が SID を適切に解決 / 変換できていない場合は インデクサーの splunkd.log を参照して問題を調査してください もっとも早いまたは最新のイベントからインデックス作成を開始するかどうかの指定 Splunk がもっとも早いイベントまたは最新のイベントからインデックスの作成を開始するかどうかを指定するには start_from 属性を使 します デフォルトで Splunk はもっとも古いデータからインデックスの作成を開始して 新しいデータへと進んでいきます これを変更するには この属性に newest を設定します この場合 最新のイベントからインデックスの作成が開始され 古いデータへと処理を進めます この設定を変更すると インデックス作成プロセスが 常に 効率的になるため 設定の変更はお勧めできません 特定のログチャネルにある既存のすべてのイベントのインデックスを作成するかどうかを指定するには current_only 属性を使 します 1 を設定すると Splunk が開始された時点から新たに登場したイベントのみ インデックスが作成されます 0 を設定すると すべてのイベントのインデックスが作成されます 例 : 45

46 [WinEventLog:Application] disabled = 0 start_from = oldest current_only = 1 エクスポートされたイベントログ (.evt または.evtx) ファイルのインデックスの作成 エクスポートした Windows イベントログファイルのインデックスを作成するには ファイルとディレクトリのモニターの説明に従って エクスポートしたファイルを保管しているディレクトリをモニターします 制約 Windows XP および Server 2003 システムでは API とログチャネルの処理上の制約により それらのシステムからインポートした.evt ファイルには Message フィールドが含まれていません つまり Message フィールドの内容が Splunk インデックスには含まれません Windows XP および Windows Server 2003/2003 R2 上で動作している Splunk は Windows Vista 7 または Server 2008/2008 R2 が動作しているシステムからエクスポートされた.evtx ファイルのインデックスを作成できません Windows Vista 7 および Server 2008/2008 R2 上で動作する Splunk は.evt および.evtx の両 のファイルのインデックスを作成することができます.evt または.evtx ファイルが標準のイベントログチャネルからのファイルでない場合は そのチャネルが必要とする DLL ファイルが インデックスを作成するコンピュータ上にあることを確認する必要があります.evt または.evtx ファイルのインデックスが作成される 語は ファイルを収集した Splunk コンピュータのプライマリロケール / 語になります 警告 : 現在書き込み中の.evt または.evtx ファイルのモニターは 試みないようにしてください Windows は そのようなファイルに対する読み取りアクセスを禁 しています 代わりにイベントログのモニタリング機能を使 してください 注意 : あるシステム上で.evt または.evtx ファイルを 成し それを別のシステムでモニターする場合 イベントを 成したシステムのように 各イベントの 部のフィールドが展開されない可能性があります この問題は DLL のバージョンの違い DLL の有無 API のバリエーションなどが原因です OS のバージョン 語 Service Pack のレベル およびインストールされているサードパーティ製 DLL などの要因により この問題が発 することもあります Answers 何か質問がありますか? Splunk Answers では Splunk コミュニティに寄せられた Windows イベントログに関する質問と回答をご覧いただけます Windows のファイルシステム変更のモニター Splunk は Windows ファイルシステムの変更を セキュリティイベントログチャネルを介してモニターすることができます ファイルやディレクトリに対する変更のモニタリングを有効にするには まず変更をモニターするファイル / ディレクトリのセキュリティ監査を有効にして 次に Splunk のイベントログモニター機能で セキュリティイベントログチャネルをモニターします このファイルシステム変更のモニター 順は 廃 予定のファイルシステムモニター に代わるものです ファイルシステム変更のモニターに何が必要か アクティビティ : ファイルシステム変更の監視 必要なアクセス許可 : Splunk は Windows 上で実 する必要があります および Splunk は Local System ユーザー またはセキュリティイベントログを読み取るための 特定のセキュリティポリシー権限を持つドメインユーザーとして実 する必要があります および変更をモニターするファイル / ディレクトリのセキュリティ監査を有効にする必要があります セキュリティイベントログを使ったファイル変更のモニター システム上のファイル変更をモニターするには 連のファイル / ディレクトリのセキュリティ監査を有効にして 次にセキュリティイベントログチャネルの変更イベントをモニターします イベントログモニタリング には inputs.conf で使 できる 3 種類の属性が含まれています 属性 説明 デ フォ ルト whitelist 指定した ID コードを含むイベントのインデックスを作成します ハイフンやカンマを使って コードの範囲を指定することができます ハイフンは ID コードの範囲 ( 例 : は 0 46 N/A

47 blacklist suppress_text 2000 の範囲の ID コード を意味する ) を します 複数の範囲はカンマで区切って指定します 指定した ID コードを含むイベントのインデックスを作成しません ハイフンやカンマを使って コードの範囲を指定することができます ハイフンは ID コードの範囲 ( 例 : は の範囲の ID コード を意味する ) を します 複数の範囲はカンマで区切って指定します セキュリティイベントに付属のメッセージテキストを含めるかどうかを指定します 1 はメッセージテキストを抑制します 0 はテキストを保持します N/A 0 注意 : この属性のリストは inputs.conf で利 できる属性の 部に過ぎません 他の属性については このマニュアルの Windows イベントログデータのモニター を参照してください ファイルシステム変更の監視 連のファイル / ディレクトリに対するファイルシステムの変更をモニターするには : 1. MS Technet の セキュリティイベントの監査の操作 法 ( を参考に セキュリティを有効にします 重要 : この作業を うには 管理者権限が必要です 2. セキュリティイベントログチャネルをモニターするように Splunk のイベントログモニター を設定します 注意 : イベントログモニター の設定 法については このマニュアルの Windows イベントログデータのモニター を参照してください 例 ファイルシステム変更をモニターするための inputs.conf スタンザの例を以下に します このスタンザは イベント ID コードが および のセキュリティイベントを収集します [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 = , # exclude these event IDs from being indexed. blacklist = このスタンザは イベント ID コードが および のセキュリティイベントを収集します また イベント 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 = , # exclude these event IDs from being indexed. blacklist = WMI ベースのデータのモニター Splunk では リモートマシン上のパフォーマンスおよびイベントログデータにエージェントレスでアクセスするために WMI を使 することができます このことは 環境内のすべての Windows サーバー / デスクトップに何もインストールすることなく それらのマシンからイベントログを収集できることを意味しています 重要 : 可能な限り WMI ではなくユニバーサルフォワーダーを使 して リモートマシンからデータを収集することをお勧めします 多くの場合 WMI のリソース負荷は ユニバーサルフォワーダーよりも くなります 特に 各ホストから複数のイベントログやパフォーマンスカウンタを収集する場合 またはドメインコントローラのような処理負荷が きなホストに対しては フォワーダーの使 を検討してください 詳細は このマニュアルの リモート Windows データのモニター 法決定の検討事項 を参照してください WMI ベースのデータ では 複数の WMI プロバイダに接続して それらのデータを取得することができます WMI ベースのデータ は splunk-wmi.exe と呼ばれる個別のプロセスとして Splunk サーバー上で実 されます これ 47

48 Splunk 実は %SPLUNK_HOME%\etc\system\default\inputs.conf 内でスクリプト として設定されています このファイルは変更しないでください WMI ベースのデータのモニターに何が必要か WMI ベースのデータをモニターするための 最低の基本要件を以下に します モニターするログやパフォーマンスカウンタによっては 他のアクセス許可が必要になることもあります WMI ベースのデータのモニターに必要な事項については このトピック後半の セキュリティとリモートアクセスの検討事項 を参照してください アクティビティ : 必要なアクセス許可 : WMI 経由のリモートイベントログのモニター WMI 経由のリモートパフォーマンスモニターカウンタのモニター * Splunk は Windows 上で実 する必要があります * Splunk は 最低でも WMI への読み取りアクセスを持つドメインユーザーとして実 する必要があります * Splunk は 的のイベントログへの適切なアクセス権を持つ ドメインユーザーとして実 する必要があります * Splunk は Windows 上で実 する必要があります * Splunk は 最低でも WMI への読み取りアクセスを持つドメインユーザーとして実 する必要があります * Splunk は パフォーマンスデータヘルパーライブラリへの適切なアクセス権を持つ ドメインユーザーとして実 する必要があります セキュリティとリモートアクセスの検討事項 Splunk と Windows ネットワークを WMI データアクセス に正しく設定する必要があります 以下の前提条件を参照の上 すべての要件を満たしていることを確認してから WMI データを収集してください Splunk が WMI ベースのデータを取得する前に : リモートネットワーク接続を実施するアクセス許可を持つユーザーとしてインストールする必要があります Splunk を実 するユーザーは Active Directory ドメイン / フォレストのメンバーで WMI プロバイダーにクエリーするための適切な権限を持っている必要があります また Splunk ユーザーは Splunk を実 するコンピュータのローカル Administrators グループのメンバーでなければなりません Splunk を実 するコンピュータは リモートマシンに接続でき また接続後にはリモートマシンから 的のデータを取得するための アクセス許可を保有している必要があります クエリーを う Splunk サーバーと クエリーを受け取るターゲットサーバーの両 が 同じ Active Directory ドメイン / フォレストに存在している必要があります Splunk ユーザーは Domain Admins グループのメンバーになる必要はありません ( セキュリティ上の理由から そうしないでください ) ただし Splunk ユーザーのアクセスを設定するには ドメイン管理者権限が必要になります ドメイン管理者権限がない場合は 他の適切な権限を持っているユーザーに Splunk ユーザーアクセスの設定 または 分へのドメイン管理者権限の割り当てを依頼してください 注意 :Splunk を Local System ユーザーとしてインストールした場合 WMI 経由のリモート認証は機能しません Local System ユーザーには ネットワーク上の他のマシンに対する資格情報がありません マシンの Local System アカウントに 他のマシンにアクセスするための権限を与えることはできません Splunk ユーザーに WMI プロバイダへのアクセス権を割り当てるには 以下のいずれかの作業を います ユーザーを ポーリングを う各メンバーサーバーの ローカル Administrators グループに追加する ( セキュリティ上の理由からお勧めできません ) Domain Admins グローバルグループに追加する ( セキュリティ上の理由からお勧めできません ) 後述するように 必要最低限の権限のみを割り当てる ( 推奨 ) グループメンバーシップとリソースアクセス制御リスト (ACL) に関する重要な注意事項 セキュリティ整合性を維持するために Splunk ユーザーをドメイングローバルグループに配置して ユーザーに直接アクセス許可を割り当てる代わりに そのグループにサーバーのアクセス許可とリソース ACL を割り当てることを強くお勧めします ユーザーに直接アクセス許可を割り当てるとセキュリティリスクが じてしまい セキュリティ監査時や将来の変更により問題が発 する可能性があります 必要最低限のアクセスを与えるための WMI の設定 Splunk を実 するユーザーがドメイン管理者でない場合 そのユーザーにアクセスを提供するように WMI を設定する必要があります WMI も含めてすべての Windows リソースに対する 必要最低限のアクセス権のみを与えることを強くお勧めします このようなアクセス権を与えるために 以下のチェックリストに従ってください 順については Splunk コミュニティ Wiki の How to enable WMI access for non-administrator domain users を参照してください 最低限の権限を使って WMI 経由でデータを収集するには Splunk を実 するユーザーに異なる複数レベルのアクセス権を与える必要があります 48

49 1. ローカルセキュリティポリシーアクセス許可 Splunk ユーザー向けに WMI ベースのデータをポーリングする各マシン上で 以下のローカルセキュリティポリシーのユーザー権利の割り当てを定義する必要があります ネットワーク経由でコンピュータへアクセスオペレーティングシステムの 部として機能バッチジョブとしてログオンサービスとしてログオンシステムパフォーマンスのプロファイルプロセスレベルトークンの置き換え 注意 : これらのユーザー権利の割り当てをドメイン全体にデプロイするには ドメインセキュリティポリシー (dompol.msc) Microsoft 管理コンソール (MMC) スナップインを使 します デプロイが完了すると それらの権利割り当ては次回の Active Directory レプリケーションサイクル時に ネットワーク上のメンバーサーバーに継承されます ( ただし 変更内容を反映するには それらのサーバー上の Splunk インスタンスを再起動する必要があります ) このアクセスをドメインコントローラにまで拡張するには ドメインコントローラセキュリティポリシー (dcpol.msc) スナップインを使って権限を割り当てます 2. Distributed Component Object Model (DCOM) の設定とアクセス許可 ポーリングを う各マシン上で DCOM を有効にする必要があります また Splunk ユーザーには DCOM にアクセスするためのアクセス許可を割り当てる必要があります そのためにはさまざまな 法がありますが Distributed COM Users ドメイングローバルグループを ポーリングを う各サーバー上の Distributed COM Users ローカルグループに れ して 次に Splunk ユーザーを Distributed COM Users ドメイングローバルグループに追加することをお勧めします また Splunk ユーザーを DCOM に確実にアクセスさせるために 他にもさまざまな 法が存在しています 詳細は MSDN の Securing a Remote WMI Connection ( を参照してください 3. パフォーマンスモニターの設定とアクセス許可 WMI 経由でリモートパフォーマンスオブジェクトにアクセスするには Splunk を実 するユーザーは ポーリングを う各メンバーサーバーの Performance Log Users ローカルグループのメンバーでなければなりません このためには Performance Log Users ドメイングローバルグループを 各メンバーサーバーの Performance Log Users ローカルグループに れ して 次に Splunk ユーザーをグローバルグループに割り当てることをお勧めします 4. WMI 名前空間のセキュリティ Splunk がアクセスする WMI 名前空間 ( 般的には Root\CIMV2) には 適切なアクセス許可セットが必要です グローバル WMI セキュリティは存在しないため 企業内の各サーバーに以下のアクセス許可を設定する必要があります Splunk ユーザーの Root 名前空間で 各ホストに対して WMI ツリー上で以下のアクセス許可を有効にするには WMI セキュリティ MMC スナップイン (wmimgmt.msc) を使 します メソッドの実 アカウントの有効化リモートの有効化セキュリティの読み取り これらの権限は Root 名前空間とその下のすべてのサブ名前空間に割り当てる必要があります 詳細は Microsoft サポートの記事 [HOWTO] Windows Server 2003 で WMI 名前空間のセキュリティを設定する 法 ( を参照してください 注意 : グループポリシーを使って 複数のリモートマシンに WMI セキュリティ設定を 度にデプロイするための 標準機能はありません ただし MSDN ブログの Set WMI namespace security via GPO ( には グループポリシーオブジェクト (GPO) 内に配置できる起動スクリプトの作成 法の説明が記載されています GPO が 的のホストに適 されると このスクリプトが名前空間のセキュリティを設定します 次に GPO をドメイン全体 または 1 つまたは複数の組織単位 (OU) にデプロイすることができます 5. ファイアウォールの設定 ファイアウォールを有効にしている場合 WMI へのアクセスを許可するように設定する必要があります Windows XP Windows Server 2003/2003 R2 Windows Vista Windows 7 および WIndows Server 2008/2008 R2 に含まれている Windows ファイアウォールを使 する場合 例外の 覧には WMI が明 的に含まれています この例外は 発信元とターゲットの両 のマシンに設定する必要があります 詳細は MSDN の Connecting to WMI Remotely Starting with Vista ( を参照してください 6. ユーザーアクセス制御 (UAC) の設定 Windows Vista Windows 7 または Windows Server 2008/2008 R2 を使 している場合 UAC がアクセス許可の割り当て 法に影響してきます UAC と WMI のリモートポーリングの影響については MSDN の User Account Control and WMI ( を参照してください WMI プロバイダへのテストアクセス WMI を設定して Splunk ユーザーのドメインへのアクセスを設定したら 設定をテストしてリモートマシンにアクセスする必要があります 重要 : この 順には 時的に Splunk のデータ保管ディレクトリ (SPLUNK_DB が指している場所 ) を変更する作業が含まれています この作業は WMI にアクセスする前に う必要があります そうしないと WMI イベントが失なわれる可能性があります これは splunk-wmi.exe プロセスが 実 時には毎回 WMI チェックポイントファイルを更新するためです WMI プロバイダにテストアクセスするには : 49

50 1. Splunk ユーザーとして Splunk を実 するマシンにログインします 注意 : ドメインコントローラにログインする場合 ドメインコントローラのセキュリティポリシーを編集して そのユーザーに ローカルログオンを許可する ポリシーを割り当てなければならないことがあります 2. コマンドプロンプトを開きます ([ スタート ] -> [ ファイル名を指定して実 ] をクリックして cmd と する ) 3. Splunk インストールディレクトリ ( 例 :cd c:\program Files\Splunk\bin) 下の bin サブディレクトリに移動します 4. 以下のコマンドを実 して Splunk がデータを格納している場所を確認します > splunk show datastore-dir 注意 : この作業を うには Splunk インスタンスの認証を受ける必要があります 確認した Splunk データ保管ディレクトリは忘れないようにしてください 後ほどの作業で必要になります 5. 以下のコマンドを実 して 時的に Splunk データ保管ディレクトリを変更します > splunk set datastore-dir %TEMP% 注意 : この例では データ保管ディレクトリを 現在 TEMP 環境変数に指定されているディレクトリに変更します 別のディレクトリを指定することもできますが そのディレクトリはすでに存在している必要があります 6. 以下のコマンドを実 して Splunk を再起動します > splunk restart 注意 :Splunk の再起動には 少し時間がかかることもあります これは ステップ 5 で指定した領域に 新しくデータストアが作成されるためです 7. Splunk を再起動したら 以下のコマンドを実 して WMI プロバイダへのアクセスをテストします ここで <server> は リモートサーバー名に置き換えてください > splunk cmd splunk-wmi -wql "select * from win32_service" -namespace \\<server>\root\cimv2 8. データがストリーム配信され エラーメッセージが何も表 されなければ それは Splunk が WMI プロバイダに接続できて クエリーが成功したことを意味しています 9. エラーがあった場合は エラーの理由を すメッセージが表 されます 出 メッセージの error="<msg>" 字列を参考に 問題解決の がかりを探してください WMI アクセスをテストしたら 以下のコマンドを実 して Splunk データベースディレクトリを元の場所に戻してから Splunk を再起動します > splunk set datastore-dir <directory shown from Step 4> WMI ベースの の設定 注意 : バージョン 4.2 以降では WMI ベースの の追加 順が変更されました [ 設定 ] の [ データ ] で [WMI collections] は利 できなくなりました WMI を利 するには [ リモートイベントログの収集 ] または [ リモートパフォーマンス監視 ] データ タイプを使 します Windows 上で Splunk が うすべてのリモートデータ収集作業は WMI プロバイダまたはフォワーダーを介して われます リモートデータ収集の詳細は このマニュアルの リモート Windows データのモニター 法決定の検討事項 を参照してください Splunk Web を使って または設定ファイルを編集して WMI ベースの を設定することができます 設定ファイルを使 する場合は より多くのオプションを利 することができます Splunk Web を使った WMI ベースの の設定 WMI ベースの を追加するには このマニュアルの適切なトピックを参照してください Splunk Web を使ったリモート Windows パフォーマンスモニタリングの設定 リモート Windows イベントログのモニタリングの設定 設定ファイルを使った WMI ベースの の設定 リモートデータ収集の設定は wmi.conf で管理します WMI ベースの のデフォルト値は このファイルを参照してください デフォルト値を変更する場合は %SPLUNK_HOME%\etc\system\local\ 内の wmi.conf のコピーを編集してください 特定のタイプのデータ の 変更が必要な属性にのみ値を設定してください Splunk が設定ファイルをどのように使 するかについては 管理マニュアル の 設定ファイルについて を参照してください wmi.conf には さまざまなスタンザが存在しています [settings] スタンザは グローバル WMI パラメータを指定します 50

51 1 つまたは複数の 固有のスタンザは WMI プロバイダに接続して リモートマシンからデータを収集するための 法を定義しています グローバル設定 [settings] スタンザは グローバル WMI パラメータを指定します スタンザ全体およびその中の各パラメータは すべてオプションで省略することができます このスタンザがない場合 Splunk はデフォルト値を仮定します Splunk が定義されている WMI プロバイダに接続できない場合 splunkd.log にエラーが記録されます 例 : :39: 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 seconds) (error="the RPC server is unavailable." HRESULT=800706BA) 以下の属性はエラー発 時に 指定されている WMI プロバイダに Splunk が再接続する 法を定義します 属性 説明 デフォルト値 initial_backoff max_backoff max_retries_at_max_backoff checkpoint_sync_interval 初めてのエラー発 後に WMI プロバイダへの再接続を試みるまでに待機する時間を秒で指定します 引き続き接続エラーが発 する場合は max_backoff に指定されている値に達するまで 待機時間を 2 倍に増やしながら再試 を試みます max_retries_at_max_backoff を発 するまでに 各接続試 間に待機する最 秒数を指定します 接続試 間の待機時間が max_backoff に達した場合に max_backoff 秒間隔でさらに再試 する回数を指定します これらの接続試 を った後もエラーが発 する場合は 接続を断念します Splunk を再起動しない限り 問題のあるプロバイダへの接続は試みられません ただし 上記の例のように エラーの記録は継続されます 状態データ ( イベントログチェックポイント ) をディスクに書き込むまでに待機する秒数を指定します 固有の設定 固有のスタンザは リモートマシン上の WMI プロバイダに接続してデータを収集する 法を定義しています これは Splunk が収集するデータのタイプを す 2 種類のいずれかの属性で定義します 任意のスタンザ名を使 できますが 通常は WMI: から始まる名前を指定します 例 : [WMI:AppAndSys] Splunk Web で WMI ベースの を設定する場合 Splunk はこの命名規則で 固有のスタンザの 出しを定義します 固有のスタンザには 2 種類の中のいずれかのデータ タイプを指定できます イベントログ :event_log_file 属性は スタンザ内に定義されているソースからイベントログデータを収集することを します Windows Query Language (WQL):wql 属性は WMI プロバイダからデータを収集する予定であることを します この属性を使 する場合は 有効な WQL ステートメントも指定する必要があります パフォーマンスデータを収集する場合は この属性を使 する必要があります 警告 :1 つのスタンザに これらの両 の属性は定義しないでください どちらか 1 つのみを使 してください そうしないと スタンザが定義する は機能しません 両 のタイプの に共通のパラメータを以下に します 属性 説明 デフォルト 値 server interval disabled データを取得するサーバーのカンマ区切りリスト このパラメータを指定しない場合 Splunk はローカルマシンへの接続を仮定します 新しいデータのポーリングを う頻度を秒で指定します この属性が指定されていない場合 スタンザが定義している は機能しません が有効か無効かを します を無効にするには 1 を 有効にするには 0 を設定します ローカルサーバー N/A 0 ( 有効 ) イベントログ固有のパラメータを以下に します 属性 説明 デフォ ルト値 51

52 event_log_file モニターするイベントログチャネルのカンマ区切りリスト N/A current_only disable_hostname_normalization 実 中に発 したイベントのみを収集するかどうかを します Splunk が停 中にイベントが 成された場合 その後 Splunk が再び起動した時にそれらのイベントのインデックス作成は われません 1 を設定すると Splunk は実 中に発 したイベントのみを収集します 0 を設定すると Splunk はすべてのイベントを収集します WMI イベントから取得したホスト名を正規化しないことを します デフォルトでは Splunk はホスト名を正規化します 正規化により ローカルシステムのさまざまな同等ホスト名が識別され ホストの単 の名前が 成されます イベント内のホスト名の正規化を無効にするには このパラメータに 1 を設定します 0 を設定すると イベント内のホスト名が正規化されます 0 ( すべてのイベントを収集 ) 0 (WMI イベントのホスト名を正規化する ) WQL 固有のパラメータ名を以下に します 属性説明デフォルト値 wql 有効な WQL ステートメント N/A namespace current_only ( オプション ) WMI プロバイダへのパスを指定します ローカルマシンは 代理認証を使ってリモートマシンに接続できなければなりません リモートマシンへのパスを指定しない場合 Splunk はデフォルトのローカル名前空間 (\Root\CIMV2) に接続します デフォルトの名前空間は クエリーする可能性がある 半のプロバイダーが常駐している場所です Microsoft は Windows XP 以降の名前空間の 覧を提供しています ( イベント通知クエリーを想定しているかどうかを します 詳細は WQL クエリ : イベント通知と標準 を参照してください イベント通知クエリーを想定している場合は 1 を 標準クエリーを想定している場合は 0 を設定します \\<local server>\root\cimv2 0 ( 標準クエリーを想定 ) WQL クエリータイプ : イベント通知と標準 WQL スタンザ内の current_only 属性は スタンザが WMI ベースのデータの収集に使 する予定のクエリーのタイプを決定します この属性に 1 を設定すると イベント通知データが想定されます イベント通知データは 着信イベントを知らせるデータです イベント通知データを取得するには イベント通知クエリーを使 する必要があります たとえば リモートマシン上でいつプロセスが起動されるのかを知りたい場合は イベント通知クエリーを使ってその情報を する必要があります 標準クエリーには イベント発 時に通知する機能はありません すでに存在している結果情報のみを返します 逆に システム上ですでに実 されているプロセスの中で splunk で始まるものを知りたい場合は 標準クエリーを使 する必要があります イベント通知クエリーは 静的な既存の情報を知らせることはできません イベント通知クエリーの場合 スタンザに定義されている WQL ステートメントが 構造的および構 的に正しくなければなりません 不適切に WQL が定義されていると そのスタンザが定義している は機能しません 詳細と例については wmi.conf 設定ファイルを参照してください 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 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 is running. Gather data from three servers. [WMI:TailApplicationLogs] 52

53 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 が WMI ベース からのデータのインデックスを作成する場合 受信したイベントのソースには wmi が設定されます 着信イベントのソースタイプは 以下の条件に基づいて設定されます イベントログデータの場合 Splunk はソースタイプに WinEventLog:<name of log file> を設定します 例 :WinEventLog:Application WQL データの場合 Splunk はソースタイプに を定義しているスタンザの名前を設定します たとえば スタンザ名が [WMI:LocalSplunkdProcess] の場合 ソースタイプには WMI:LocalSplunkdProcess が設定されます 送信元ホストは受信データから 動的に定義されます WMI およびイベント変換 インデックス時には WMI イベントの変換は利 できません つまり Splunk のインデックス作成時に WMI イベントを変更または抽出することはできません これは WMI イベントは単 のソース ( スクリプト ) として到着し 単 のソースとしてしか照合できないためです ただし サーチ時には WMI イベントの変更や抽出を えます また ソースタイプ [wmi] を指定することで パーシング時に WMI ベースの を処理することもできます Splunk に到着したイベントの変換 法の詳細は このマニュアルの インデックス作成したフィールドの抽出について を参照してください WMI のトラブルシューティング WMI プロバイダー経由のイベント受信に問題が発 した または想定する結果が得られない場合は Troubleshooting Manual の Common Issues with Splunk and WMI を参照してください Windows レジストリデータのモニター Windows レジストリは Windows マシンの集中設定データベースです ほぼすべての Windows プロセスとサードパーティ製プログラムがやり取りを っています 正常なレジストリがないと Windows は動作できません Splunk では Windows レジストリ設定を捕捉して リアルタイムにレジストリへの変更をモニターすることができます プログラムが設定を変更する場合 それらの変更をレジストリに書き込みます たとえば プログラムが開いているウィンドウ内の作業位置を記憶している場合があります 後ほどプログラムを再び実 すると プログラムはレジストリからそれらの設定を探します システム上のプログラムやプロセスが レジストリエントリの追加 更新 および削除を う時期を学習することができます レジストリエントリが変更されると Splunk は変更を ったプロセス名 および変更されたエントリへのパス全体を取得します Windows レジストリ モニターは splunk-regmon.exe と呼ばれるプロセスとして実 されます レジストリのモニター理由 レジストリはおそらくもっとも使 されているけれども ほとんど理解されていない Windows 運 コンポーネントです レジストリは常時使 されており さまざまなプログラムがレジストリを読み書きしています 何かが正常に動作しない場合 Microsoft はしばしば管理者やユーザーに RegEdit ツールを使って直接レジストリを変更することを指 しています これらの編集作業や他の変更をリアルタイムに捕捉することは レジストリの重要性を理解するための最初のステップになります 53

54 レジストリのヘルス状態を理解することも 常に重要です Splunk はレジストリの変更を知らせるだけでなく それらの変更が成功したかどうかも確認することができます プログラムやプロセスがレジストリを読み書きできない場合 Windows システムに障害などの不具合が じる可能性があります Splunk はレジストリ操作に関する問題のアラートを 成できるため バックアップから設定を復元してシステムの正常動作を維持できます レジストリのモニターに何が必要か レジストリのモニターに必要な 明 的なアクセス許可の 覧を以下の表に します モニターするレジストリキーに基づいて 他のアクセス許可が必要な場合もあります アクティビティ : レジストリのモニター 必要なアクセス許可 : * Splunk は Windows 上で実 する必要があります および * Splunk は Local System ユーザーとして実 するかまたは * Splunk をモニターするレジストリハイブまたはキーへの読み取りアクセスを持つドメインユーザーとして実 する必要があります パフォーマンスの検討事項 Windows マシンに Splunk をインストールしてレジストリのモニターを有効にする場合 モニターするレジストリを指定します ユーザーハイブ (RegEdit の HKEY_USERS) またはマシンハイブ (HKEY_LOCAL_MACHINE) を指定します ユーザーハイブには Windows やプログラムが必要とするユーザー固有の設定が含まれています マシンハイブには サービス ドライバ オブジェクトクラス およびセキュリティ記述 の場所などの マシン固有の設定情報が含まれています レジストリは Windows マシン運 の中 的な役割を果たしているため 両 のレジストリパスを有効にすると Splunk は 量のデータをモニターしなければならない可能性があります 最適なパフォーマンスを達成するために inputs.conf を使って Splunk がインデックスを作成するレジストリデータ量を フィルタリングにより制限することをお勧めします 同様に 最初に Splunk を起動する際に 現在の Windows レジストリの状態のスナップショットとなるベースラインを取得し その後も指定時間経過後に再取得していくことができます このスナップショットにより ある時点でのレジストリの内容と 較し 時間の経過に伴うレジストリ変更の追跡を容易にします スナップショットの処理にはある程度 CPU を消費し 処理の完了まで数分ほどかかることもあります ベースラインスナップショットの取得を inputs.conf を編集するまで延期し Splunk でモニターするレジス取れエントリの範囲を制限することができます inputs.conf の詳細およびそれを使った着信レジストリイベントのフィルタリング 法については 後述する 着信レジストリイベントのフィルタリング を参照してください Splunk Web でレジストリのモニターを有効にする Windows レジストリをモニターするように Splunk を設定するには : 1. Splunk Web の右上にある [ 設定 ] をクリックします 2. [ データ ] で [ データ ] をクリックします 3. [ レジストリ監視 ] をクリックします 4. [ 新規 ] をクリックします 5. [ コレクション名 ] フィールドで このコレクションの 意の名前を します 6. [ レジストリハイブ ] フィールドに モニターするレジストリキーへのパスを します 7. パスが分からない場合は [ 参照 ] ボタンをクリックして モニターするレジストリキーのパスを選択します [ レジストリハイブ ] ウィンドウに レジストリがツリービューで表 されます ハイブ キー およびサブキーはフォルダで表され 値はドキュメントアイコンで表されます 注意 : HKEY_USERS, HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE, および HKEY_CURRENT_CONFIG ハイブは トップレベルのオブジェクトとして表 されます HKEY_CLASSES_ROOT ハイブは そのハイブの最初のサブレベルに存在しているサブキー数のため 表 されません HKEY_CLASSES_ROOT の項 にアクセスするには HKEY_LOCAL_MACHINE\Software\Classes を選択します 8. [ レジストリハイブ ] ウィンドウで キー名をクリックして 的のレジストリキーを選択します キーの修飾名は ウィンドウ下部にある [ 修飾名 ] フィールドに表 されます 9. [ 選択 ] をクリックして 選択内容を確認してウィンドウを閉じます 10. ステップ 6 または 7 で指定した開始ハイブ下の ノードもモニターする場合は [ モニターサブノード ] を選択しま 54

55 す 注意 :[ モニターサブノード ] ノードは Splunk Web でレジストリモニター を定義する際に作成された inputs.conf ファイルに 追加される項 を決定します モニターするキーまたはハイブの選択にツリービューを使 し [ モニターサブノード ] を選択した場合 Splunk は正規表現または regex を 定義している のスタンザに追加します 正規表現 (\\\\?.*) は 選択したキーまたはそのサブキーを直接参照しないイベントをフィルタリングします [ モニターサブノード ] を選択しない場合 Splunk は選択したキーを直接参照しないイベントをフィルタリングする スタンザに 正規表現が追加されます ( 選択したキーのサブキーを参照するイベントを含む ) モニターするキーの指定にツリービューを使 しない場合は [ モニターサブノード ] が選択され ステップ 6 で説明している [ レジストリハイブ ] に独 の正規表現を していない場合にのみ 正規表現が追加されます 11. [ イベントタイプ ] で 選択したレジストリハイブに対してモニターするレジストリイベントタイプを選択します イベントタイプ 設定 作成 削除 名前変更 開く 閉じる クエリー Splunk は プログラムがレジストリサブキーに SetValue メソッドを実 した場合に Set イベントを 成し 既存のレジストリの既存の値の設定または上書きを います 説明 Splunk は レジストリハイブ内でプログラムが CreateSubKey メソッドを実 した場合に Create イベントを 成し 既存のレジストリハイブ内に新たなサブキーを作成します Splunk は プログラムが DeleteValue または DeleteSubKey メソッドを実 した場合に Delete イベントを 成します この 法は 特定の既存のキーの値を削除するか または既存のハイブからキーを削除します Splunk は RegEdit でレジストリキーまたはサブキーの名前を変更した場合 Rename イベントを 成します Splunk は プログラムがレジストリサブキー上で OpenSubKey メソッドを実 した場合に Open イベントを 成します ( レジストリに含まれている設定情報をプログラムが必要とする場合の処理など ) Splunk はプログラムがレジストリキーで Close メソッドを実 した場合に Close イベントを 成します これは プログラムがキーのコンテンツの読み取りを完了した場合 または RegEdit でキーの値を変更した後に 値 ウィンドウを終了した場合に発 します Splunk はプログラムがレジストリサブキーで GetValue メソッドを実 した場合に Query イベントを 成します 12. その他のオプションについては [ その他の設定 ] の隣りにあるチェックボックスをクリックします または の変更内容を保存するには [ 保存 ] をクリックします これ以上の変更を わないで を保存するには ステップ 16 に進んでください 13. [ プロセスパス ] フィールドに適切な値を して Splunk がレジストリへのをモニターするプロセスを Splunk に指 します または Splunk にすべてのプロセスをモニターさせる場合は デフォルトの C:\.* を使 します 14. レジストリ変更のモニタリングを開始する前に レジストリ全体のベースラインスナップショットを取得するかどうかを指定します ベースラインを設定するには [ ベースラインインデックス ] で [ はい ] をクリックします 注意 : ベースラインスナップショットは スナップショット取得時のレジストリ全体のインデックスです ベースラインインデックスを設定するためのレジストリのスキャンは CPU を消費するためある程度時間がかることがあります 15. 必要に応じて [ インデックス ] から 的のインデックスを選択して Splunk がレジストリモニタリングイベントを送信するインデックスを選択します 16. [ 保存 ] をクリックします Splunk は を有効にして [ レジストリ監視 ] ページを返します 注意 : 有効にした を無効にするには [ レジストリ監視 ] ページの [ ステータス ] 列にある [ 無効 ] を選択します 警告 : レジストリモニターの実 中は splunk-regmon.exe プロセスを 動で停 または kill しないでください そうすると システムが不安定な状態になる可能性があります レジストリのモニターを停 するには [ サービス ] コントロールパネルまたは CLI から splunkd サーバープロセスを停 します レジストリ変更データの表 Splunk がインデックスを作成したデータのレジストリ変更を表 するには サーチ App でソースが WinRegistry のイベントをサーチします ユーザーがドメインにログインした時に グループポリシーが 成するイベントの例を以下に します 3:03: PM 55

56 06/19/ :03: 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" 各レジストリモニタリングイベントには 以下の項 が含まれます 属性 event_status 説明 レジストリ変更の試 結果 これは常に (0) The operation completed successfully. でなければなりません そうでない場合は バックアップからの復元が必要なレジストリに関する問題になる可能性があります pid レジストリの変更を試みたプロセスのプロセス ID process_image registry_type key_path data_type data レジストリの変更を試みたプロセス名 process_image が実 しようとしたレジストリ操作のタイプ process_image が変更を試みたレジストリキーのパス レジストリの変更を う process_image が取得または設定を試みた レジストリデータのタイプ レジストリの変更を う process_image が読み取りまたは書き込みを試みたデータ Splunk のサーチコマンドやレポート機能を使って 着信データに基づくレポートを作成したり アラート機能を使って何か問題が発 した時にアラートを送信したりすることができます 着信レジストリイベントのフィルタリング Windows レジストリは ほぼ常時利 されるため 量のイベントを 成します そのためライセンス上の問題が発 する可能性があります レジストリのモニタリングでは あたり数百メガバイトものデータが 成される可能性があります Splunk の Windows レジストリモニタリング機能は 設定ファイル inputs.conf を使ってシステムの何を監視するのかを決定します このファイルは $SPLUNK_HOME\etc\system\local\ になければなりません inputs.conf には レジストリハイブのパスを限定 フィルタリングする正規表現を指定して Splunk にモニターさせる項 を指 します inputs.conf 内の各スタンザが 特定のフィルタを表しています 定義には 以下の項 が含まれます proc hive 属性 モニターするプロセスへのパスを含む正規表現 説明 モニターするエントリへのパスを含む正規表現 Splunk は Windows に事前定義されている root キー値のマッピングをサポートしています \\REGISTRY\\USER\\ は HKEY_USERS または HKU にマップします \\REGISTRY\\USER\\_Classes は 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 です type モニターするイベントタイプのサブセット 1 つまたは複数の delete, set, create, rename, open, close または query を使 できます ここの値は sysmon.conf に設定した event_types の値のサブセットでなければなりません baseline baseline_interval disabled その特定のハイブパスのベースラインスナップショットを取得するかどうか はいの場合は 1 いいえの場合は 0 を設定します Splunk がここに指定した時間 ( 秒数 ) を超えて停 していた場合に スナップショットを再取得します デフォルトは 86,400 秒 (1 ) です フィルタを有効にするかどうか フィルタを無効にするには 1 を 有効にするには 0 を設定しま 56

57 disabled す ベースラインスナップショットの取得 レジストリモニタリングを有効にした場合 次回の Splunk 起動時にレジストリハイブのベースラインスナップショットを記録することができます デフォルトで スナップショットは HKEY_CURRENT_USER and HKEY_LOCAL_MACHINE ハイブをカバーしています また デフォルトでスナップショットを再取得する時期も決定しています 前回のチェックポイントから 24 時間を超えて Splunk が停 していた場合 ベースラインスナップショットが再取得されます inputs.conf 内の各フィルタに対して この値をカスタマイズできます (baseline_interval に値を設定 ) この属性は秒数で表されています リアルタイム Windows パフォーマンスモニタリング Splunk は システムで利 できるすべての Windows パフォーマンスカウンタの リアルタイムモニタリングをサポートしています また ローカル / リモートの両 のパフォーマンスデータを収集することができます Splunk のパフォーマンスモニタリングユーティリティによる Web またはコマンドラインインターフェイスでパフォーマンスをモニターすることができます Splunk はパフォーマンスデータヘルパー (PDH) API を使って ローカルマシンのパフォーマンスカウンタをクエリーしています Splunk で利 できるパフォーマンスオブジェクト カウンタ およびインスタンスのタイプは システムにインストールされているパフォーマンスライブラリによって異なります Microsoft とサードパーティベンダーの両 が パフォーマンスカウンタを含むライブラリを提供しています パフォーマンスモニタリングの詳細は MSDN の Performance Counters ( を参照してください 完全版 Splunk インスタンスとユニバーサルフォワーダーの両 が パフォーマンス測定基準のローカル収集をサポートしています リモートパフォーマンスモニタリングは WMI (Windows Management Instrumentation) を介して実 します この場合 適切な Active Directory 資格情報を持つユーザーとして Splunk を実 する必要があります パフォーマンスモニター は splunk-perfmon.exe と呼ばれるプロセスとして実 されます このプロセスは定義されている各 に対して に指定されている間隔で 1 回実 されます パフォーマンスモニタリングの設定には Splunk Web または inputs.conf ( ローカルパフォーマンスデータ ) または wmi.conf ( リモートマシンからのパフォーマンスデータ ) を使 します パフォーマンス測定基準のモニター理由 パフォーマンスのモニタリングは Windows 管理者にとって重要な役割を果たします Windows は システムのヘルス状態に関するさまざまなデータを 成します このデータを適切に分析することが 正常で円滑に動作するシステムと 不具合が発 して頻繁に停 するシステムの違いを み出します パフォーマンスカウンタのモニターに何が必要か Windows でパフォーマンスカウンタのモニターに必要な 明 的なアクセス許可の 覧を以下の表に します モニターするパフォーマンスオブジェクトやカウンタによっては 他のアクセス許可が必要になることもあります パフォーマンス測定基準のモニターに必要な事項については このトピック後半の セキュリティとリモートアクセスの検討事項 を参照してください アクティビティ : 必要なアクセス許可 : ローカルパフォーマンス測定基準のモニター WMI を介した他のコンピュータ上のパフォーマンス測定基準のリモートモニター * Splunk は Windows 上で実 する必要があります * Splunk は Local System ユーザーとして実 する必要があります * Splunk は Windows 上で実 する必要があります * Splunk は 最低でもターゲットコンピュータ上の WMI への読み取りアクセスを持つドメインユーザーとして実 する必要があります * Splunk は ターゲットコンピュータ上のパフォーマンスデータヘルパーライブラリへの適切なアクセス権を持つ ドメインまたはリモートユーザーとして実 する必要があります セキュリティとリモートアクセスの検討事項 Splunk は WMI またはフォワーダーを使って リモートマシンからデータを収集します リモートマシンからインデクサーへのパフォーマンスデータの送信には ユニバーサルフォワーダーを使 することをお勧めします パフォーマンス測定基準を収集するための フォワーダーのインストール 設定 使 法については データの転送 マニュアルの ユニバーサルフォワーダーの紹介 を参照してください パフォーマンスデータを収集するために リモートマシン上にフォワーダーをインストールする場合 それらのマシンにはフォワーダーを Local System ユーザーとしてインストールすることができます Local System ユーザーは ローカルマシン上のすべてのデータにアクセスできますが リモートコンピュータにアクセスすることはできません WMI を使ってリモートマシンからパフォーマンスデータを収集する場合 ネットワークと Splunk インスタンスが適切に設定されていることを確認する必要があります Splunk を Local System ユーザーとしてインストールすることはできません また インストールするユーザーによって Splunk が参照できる 連のパフォーマンス測定基準が決まります 57

58 Splunk が WMI を使ってリモートデータを適切に収集するために 満たす必要がある要件については このマニュアルの WMI データのモニター の セキュリティとリモートアクセスの検討事項 を参照してください 適切なユーザーとして Splunk をインストールしたら ローカルパフォーマンスモニター を有効にする前に そのユーザーを以下のグループに追加します Performance Monitor Users ( ドメイングループ ) Performance Log Users ( ドメイングループ ) ローカル Windows のパフォーマンスモニタリングを有効にする Splunk Web を使って または設定ファイルを編集して ローカルのパフォーマンスモニタリングを設定することができます パフォーマンスモニタリングデータ の追加には Splunk Web の使 をお勧めします 設定ファイルを使 する場合 指定誤りが発 する可能性があります パフォーマンス API に定義されている通りに 正確にパフォーマンスモニターオブジェクトを指定することが重要です 詳細は inputs.conf にパフォーマンスモニターオブジェクトを指定する場合の重要な情報 を参照してください Splunk Web を使ったローカル Windows パフォーマンスモニタリングの設定 1. Splunk Web の右上にある [ 設定 ] をクリックします 2. [ データ ] で [ データ ] をクリックします 3. [ ローカルパフォーマンス監視 ] をクリックします 4. [ 新規 ] をクリックして を追加します 5. この に対して 意の覚えやすい名前を します 6. [ 利 可能オブジェクト ] で カウンタを表 するパフォーマンスオブジェクトを選択します 選択したオブジェクトで利 可能なパフォーマンスカウンタがロードされます 注意 : データ あたり 1 つのパフォーマンスオブジェクトのみを追加できます これは Microsoft によるパフォーマンスモニターオブジェクトの取り扱い 法によるものです 多くのオブジェクトが 選択時に を動的に記述するクラスを列挙します このことは に定義されている どのパフォーマンスカウンタやインスタンスが どのオブジェクトに所属しているのかを判断するための混乱や妨げになる可能性があります 複数のオブジェクトをモニターする必要がある場合は 各オブジェクトに対して追加のデータ を作成してください 7. [ カウンタ ] で [ 利 可能なカウンター ] リストボックスから モニターするカウンタをクリックして選択します 選択したカウンタが [ 利 可能なカウンター ] リストボックスから [ 選択されたカウンター ] リストボックスに移動します 8. [ インスタンス ] で [ 使 可能なインスタンス ] リストからモニターするインスタンスをクリックして選択します 選択したインスタンスが [ 使 可能なインスタンス ] リストボックスから [ 選択されたインスタンス ] リストボックスに移動します 注意 : _Total インスタンスは特殊なインスタンスで 多くのタイプのパフォーマンスカウンタに存在しています このインスタンスは 同じカウンタ下の任意の関連するインスタンスの平均として定義されます このインスタンスで収集されるデータは 同じカウンタ下の個別のインスタンスとは 幅に異なっています たとえば 2 台のディスクを搭載したシステム上の PhysicalDisk オブジェクト下にある Disk Bytes/Sec パフォーマンスカウンタのパフォーマンスデータをモニターする場合 表 される利 可能なカウンタには それぞれの物理ディスクに対して 0 C: と 1 D: そして _Total インスタンスが含まれます この場合 _Total インスタンスが 2 台の物理ディスクインスタンスの平均になります 9. ポーリング間隔 ( 秒 ) を指定します 10. このコレクションの宛先インデックスを選択します 11. [ 保存 ] をクリックします が追加され 有効になります 設定ファイルを使ったローカル Windows パフォーマンスモニタリングの設定 inputs.conf がパフォーマンスモニタリングの設定を管理しています 設定ファイルを使ってパフォーマンスモニタリングを設定する場合 %SPLUNK_HOME%\etc\system\local に inputs.conf を作成して それを編集します Splunk の設定ファイルで初めて作業を う場合は 事前に 設定ファイルについて をお読みください [perfmon://<name>] スタンザは inputs.conf にパフォーマンスモニタリング を定義します モニターする各パフォーマンスオブジェクトに対して それぞれ 1 つのスタンザを定義します 58

59 各スタンザでは 以下の属性を指定することができます 属性 必須? interval はい 新しいデータのポーリングを う頻度を秒で指定します この属性が指定 定義さ れていない場合 デフォルト値は存在しないためその は機能しません object はい 収集するパフォーマンスオブジェクト 字 字の区別も含めて正確に 既存のパフォーマンスモニターオブジェクトの名前を指定するか または複数のオブジェクトを指定するために正規表現を使 します この属性が指定 定義されていない場合 デフォルト値は存在しないためその は機能しません counters はい object に指定されているオブジェクトに関連する 1 つまたは複数の有効なパフォーマンスカウンタ 複数のカウンタを指定する場合は セミコロンで区切ります object で利 できるすべてのカウンタを指定するために アスタリスク (*) を使 することもできます この属性が指定 定義されていない場合 デフォルト値は存在しないためその は機能しません instances index disabled samplinginterval いいえ いいえ いいえ いいえ 説明 counters に指定されているパフォーマンスカウンタに関連する 1 つまたは複数の有効なインスタンス 複数のインスタンスを指定する場合は セミコロンで区切ります すべてのインスタンスを指定するには アスタリスク (*) を使 します スタンザ内にこの属性を定義しない場合 デフォルトではすべてのインスタンスが対象になります ( アスタリスク指定と同じ ) パフォーマンスカウンタデータを送るインデックス 指定しない場合は default インデックスが使 されます この に定義されているパフォーマンスデータを収集するかどうか このスタンザを無効にするには 1 を 有効にするには 0 を設定します 指定しない場合 デフォルトの 0 ( 有効 ) が使 されます 詳細オプション :Splunk がパフォーマンスデータを収集する頻度 ( ミリ秒 ) この属性は 頻度のパフォーマンスサンプリングを有効にします 頻度のパフォーマンスサンプリングを有効にすると Splunk は指定された間隔でパフォーマンスデータを収集し データの平均値および他の統計情報を報告します デフォルトは 100 ミリ秒です また interval 属性に指定した値未満でなければなりません stats いいえ 詳細オプション : 頻度のパフォーマンスサンプリングで Splunk が報告する統計値のセミコロン区切りリスト 利 可能な値 :average, min, max, dev count デフォルトの設定はありません ( 無効 ) mode いいえ 詳細オプション : 頻度のパフォーマンスサンプリングを有効にする場合 この属性で Splunk によるイベントの出 法を制御できます 利 可能な値 :single, multikv, multims および multikvms multims または multikvms を有効にした場合 収集された各パフォーマンス測定基準に対して 2 つのイベントを出 します 最初のイベントは平均値 2 番 は統計イベントになります 統計イベントは 使 する出 モードに応じて特別なソースタイプを保有します (multims の場合は perfmonmsstats multikvms の場合は perfmonmkmsstats) 頻度のパフォーマンスサンプリングを有効にしない場合 multikvms 出 モードと multikv 出 モードは同じです デフォルトは single です システム上のローカルディスクからパフォーマンスデータを収集して それを perfmon インデックスに保管する 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 will reset the interval # to 1. [perfmon://localphysicaldisk] interval = 0 59

60 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 = * inputs.conf にパフォーマンスモニターオブジェクトを指定する場合の重要な情報 perfmon キーワードの指定時にはすべて 字を使 する inputs.conf にパフォーマンスモニター を作成する場合 perfmon キーワードにはすべて 字を使 する必要があります 以下に例を します 正しい 誤り [perfmon://cputime] [Perfmon://CPUTime] [PERFMON://CPUTime] キーワードで 字を使 または 字 字を混在すると Splunk 起動時にその問題の警告が表 され 指定されているパフォーマンスモニター は機能しません 複数のパフォーマンスモニターオブジェクトを取得する場合は有効な正規表現を指定する 単 のパフォーマンスモニタースタンザ内に複数のオブジェクトを指定する必要がある場合 有効な正規表現を使ってそれらのオブジェクトを取得する必要があります たとえば 定の 字数を超える 字列と 致するワイルドカードを指定するには * ではなく.* を使 します オブジェクトにドル記号または類似の特殊 字が含まれている場合は 円記号 (\) またはバックスラッシュを使ってエスケープ処理する必要があります 上記の場合を除いて 値はパフォーマンスモニター API に定義されている通りに正しく指定する必要があります [perfmon://] スタンザに object counters および instances の値を指定する場合 それらの値は 字 字の区別も含めてパフォーマンスモニター API に定義されてい通りに正確に指定する必要があります そうしないと 誤ったデータが返されるか またはまったくデータが返されません 指定したパフォーマンスオブジェクト カウンタ またはインスタンス値に 致する項 が つからない場合 その旨が splunkd.log に記録されます 例 : :04: 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 を実 する必要があります それらの測定基準の収集を試みる前に この作業を実施する必要があります Splunk を実 するマシンと Splunk がリモートにパフォーマンスデータを収集するマシンは 同じ Active Directory ドメイン / フォレスト内に存在している必要があります 注意 : WMI は設計上 サービス拒否攻撃を防 するために 抑制を います Splunk も WMI 呼び出しがエラーを返した場合の追加的な予防 段として 呼び出し数を抑制します ネットワークのサイズ 設定 およびセキュリティプロファイルによっては パフォーマンス測定基準を収集するシステム上に ローカルにフォワーダーをインストールする が適していることもあります 詳細は このマニュアルの リモート Windows データのモニター 法決定の検討事項 を参照してください 60

61 WMI ベースのパフォーマンス測定基準に関する重要な情報 WMI 経由でリモートのパフォーマンス測定基準を収集する場合 部の測定基準が 0 を返す またはパフォーマンスモニターが返す値とは異なる値が返されることがあります これは パフォーマンスモニターカウンタ の WMI の実装の制限によるもので Splunk の問題でも WMI ベースのデータの取得 法の問題でもありません WMI は Win32_PerfFormattedData_* クラスを使って パフォーマンス測定基準を収集します 特定のクラスに関する情報は MSDN の Win32 Classes ( を参照してください WMI は これらのクラス内のデータ構造を ご利 の Windows のバージョンに応じて 32 ビットまたは 64 ビットの符号なし整数として定義します パフォーマンスモニターオブジェクトは 浮動 数点型変数として定義されます これは WMI ベースの測定基準が 丸められることにより変則的に えることがあることを意味しています たとえば Average Disk Queue Length ( ディスクキューの平均の さ ) パフォーマンスモニターカウンタ上のデータと同時に WMI を介して Win32_PerfFormattedData_PerfDisk_PhysicalDisk\AvgDiskQueueLength 測定基準を収集する場合 パフォーマンスモニターの測定基準の値が 0 より きい ( ただし 0.5 未満の ) 場合でも WMI ベースの測定基準は値として 0 を返すことがあります これは WMI は表 する前に値を丸めることが原因です よりきめ細かなパフォーマンス測定基準が必要な場合は パフォーマンスデータを収集する各マシン上にユニバーサルフォワーダーをインストールして パフォーマンスモニタリング を設定することをお勧めします 次に そのデータをインデクサーに転送します この 法を使って取得したデータは WMI ベースの を使ってリモートに収集したデータよりも信頼性が くなります Splunk Web を使ったリモート Windows パフォーマンスモニタリングの設定 1. Splunk Web の右上にある [ システム ] をクリックします 2. [ データ ] で [ データ ] をクリックします 3. [ リモートパフォーマンス監視 ] をクリックします 4. [ 新規 ] をクリックして を追加します 5. このコレクションに対して 意の名前を します 6. [ ターゲットホストの選択 ] で パフォーマンスモニターオブジェクトを収集する Windows ホストの有効な名前を して [ クエリー...] をクリックします Splunk はホストに接続して 利 可能なパフォーマンスオブジェクトを取得します 7. [ 利 可能オブジェクト ] で カウンタを表 するパフォーマンスオブジェクトを選択します 選択したオブジェクトで利 可能なパフォーマンスカウンタがロードされます 注意 : データ あたり 1 つのパフォーマンスオブジェクトのみを追加できます これは Microsoft によるパフォーマンスモニターオブジェクトの取り扱い 法によるものです 多くのオブジェクトが 選択時に を動的に記述するクラスを列挙します このことは に定義されている どのパフォーマンスカウンタやインスタンスが どのオブジェクトに所属しているのかを判断するための混乱や妨げになる可能性があります 複数のオブジェクトをモニターする必要がある場合は 各オブジェクトに対して追加のデータ を作成してください 8. [ カウンタ ] で [ 利 可能なカウンター ] リストボックスから モニターするカウンタをクリックして選択します 選択したカウンタが [ 利 可能なカウンター ] リストボックスから [ 選択されたカウンター ] リストボックスに移動します 9. [ インスタンス ] で [ 使 可能なインスタンス ] リストからモニターするインスタンスをクリックして選択します 選択したインスタンスが [ 利 可能なインスタンス ] リストボックスから [ 選択されたインスタンス ] リストボックスに移動します 注意 : _Total インスタンスは特殊なインスタンスで 多くのタイプのパフォーマンスカウンタに存在しています このインスタンスは 同じカウンタ下の任意の関連するインスタンスの平均として定義されます このインスタンスで収集されるデータは しばしば同じカウンタ下の個別のインスタンスとは 幅に異なっています たとえば 2 台のディスクを搭載したシステム上の PhysicalDisk オブジェクト下にある Disk Bytes/Sec パフォーマンスカウンタのパフォーマンスデータをモニターする場合 表 される利 可能なカウンタには それぞれの物理ディスクに対して 0 C: と 1 D: そして _Total インスタンスが含まれます この場合 _Total インスタンスが 2 台の物理ディスクインスタンスの平均になります 10. 必要に応じて 他のホストから同じ測定基準セットを収集することができます この場合は それらのホストをカンマで区切って指定します 11. ポーリング間隔 ( 秒 ) を指定します 12. 必要に応じて このコレクションの宛先インデックスを選択します デフォルトでは default インデックスが選択されています 61

62 13. [ 保存 ] をクリックします が追加され 有効になります 注意 : Splunk Web で Win32_PerfFormattedData_* クラスは 利 可能なオブジェクトとしては表 されません Win32_PerfFormattedData_* クラスをモニターしたい場合は 直接 wmi.conf に追加する必要があります 設定ファイルを使ったリモート Windows パフォーマンスモニタリングの設定 リモートパフォーマンスモニタリングの設定は wmi.conf で管理します 設定ファイルを使ってリモートパフォーマンスモニタリングを設定する場合 %SPLUNK_HOME%\etc\system\local に wmi.conf を作成して それを編集します Splunk の設定ファイルで初めて作業を う場合は 事前に 設定ファイルについて をお読みください 警告 : リモートパフォーマンスモニター を作成する場合 Splunk Web を使 することを強くお勧めします これは パフォーマンスモニターオブジェクト カウンタ およびインスタンスの名前は 字 字の区別も含めて パフォーマンスモニターに定義されているのと 完全に同じでなければならないためです Splunk Web は WMI を使って適切な形式の名前を取得するため このような問題の発 を防 することができます wmi.conf には モニターする各リモートパフォーマンスモニターのスタンザが含まれています 各スタンザでは 以下の項 を指定することができます グローバル設定 属性 initial_backoff max_backoff max_retries_at_max_backoff checkpoint_sync_interval 必須? いいえ いいえ いいえ いいえ 説明 エラー発 時に WMI プロバイダへの接続を再試 するまでに待機する秒数です プロバイダへの接続に引き続き問題が発 する場合は 接続を試みるまでの待機時間を 2 倍にしながら 接続が成功するか または待機時間が max_backoff に指定される値以上になるまで接続を試みていきます WMI プロバイダへの再接続を試みる最 時間 ( 秒 ) 20 WMI プロバイダとの再接続試 が max_backoff の秒数に達した場合に そのプロバイダとの再接続を試 する回数 状態データをディスクからフラッシュするまでに待機する秒数 2 デフォルト 5 2 固有の設定 属性 必須? interval はい 新しいデータのポーリングを う頻度を秒で指定します この属性が ない場合 デフォルト値は存在しないためその は機能しません server event_log_file いいえ いいえ 説明 パフォーマンスをモニターする 1 つまたは複数の有効なサーバー 複数の項 を指定する場合は カンマで区切ります ポーリングする 1 つまたは複数の Windows イベントログチャネル この属性は 着信データがイベントログ形式であることを Splunk に指 します デフォルト N/A ローカルマシン N/A 注意 : すでに wql 属性があるスタンザには event_log_file 属性を指定しないでください wql いいえ リモートにポーリングするパフォーマンスオブジェクト カウンタ およびインスタンスを す 有効な WQL ステートメント この属性は WMI プロバイダからデータを収集する予定であることを します N/A 注意 : すでに event_log_file 属性があるスタンザには wql 属性を指定しないでください namespace いいえ クエリーする WMI プロバイダが存在する名前空間 この属性の値は 相対値 (Root\CIMV2) または絶対値 (\\SERVER\Root\CIMV2) にできますが server 属性を指定する場合は相対値でなければなりません Root\CIMV2 62

63 注意 :wql 属性があるスタンザでのみ namespace 属性を使 してください index いいえ パフォーマンスカウンタデータを送るインデックス default current_only いいえ WMI ベースのイベント収集の特徴とやり取り N/A wql を定義した場合 この属性は Splunk がイベント通知クエリーを予期すべきかどうかを します イベント通知クエリーを予定している場合は 1 を 標準クエリーを予定している場合は 0 を設定します WQL およびイベント通知クエリーの追加要件は以下を参照してください event_log_file を定義した場合 Splunk が動作中に発 したイベントのみを収集するかどうかを します Splunk 動作中に発 したイベントのみを収集する場合は 1 を 最後のチェックポイントからのイベントを収集する場合は 0 を設定します 0 を指定して チェックポイントが存在していない場合は 利 可能なもっとも古いイベントから収集されます 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 のメモリー使 量が増加することがあります これは正常な動作です 部のパフォーマンスオブジェクトは 収集プロセス時に他のオブジェクトよりも多くのメモリーを消費します Processor Time カウンタが 100 より きい値を返さない 63

64 Microsoft が Processor:%Processor Time および Process:% Processor Time カウンタを使って CPU 使 率を算出する 法により これらのカウンタはシステムの CPU 数やコア数に関係なく 100 を超える値を返すことはありません これは仕様です これらのカウンタは アイドルプロセスが費やした時間量を 100% から減算していきます Windows ホスト情報のモニター Splunk は Windows ホスト情報 ( ローカル Windows マシンの詳細な統計情報 ) のモニターをサポートしています Windows ホストに関する以下の情報を収集することができます 般のコンピュータ : コンピュータのメーカーとモデル そのホスト名と参加している Active Directory ドメイン オペレーティングシステム : コンピュータにインストールされているオペレーティングシステムのバージョンとビルド番号 およびサービスパック コンピュータ名 前回起動時刻 搭載メモリーと空きメモリー量 およびシステムドライブ プロセッサ : システムの CPU のメーカーとモデル 動作速度とバージョン プロセッサ / コア数 およびプロセッサ ID ディスク : システムが利 できるすべてのドライブ 覧 および利 できる場合はファイルシステムタイプと合計 / 利 可能スペース ネットワークアダプタ : 製造業者 製品名 および MAC アドレスを含めた システムに取り付けられているネットワークアダプタに関する情報 サービス : 名前 表 名 説明 パス サービスタイプ 開始モード 状態 およびステータスを含めた システムにインストールされているサービスに関する情報 プロセス : 名前 実 時のコマンドライン ( および引数 ) および実 形式ファイルのパスを含めた システムで動作中のプロセスに関する情報 アプリケーション : 名前とシリアル番号 インストール 時とインストール場所 ベンダー およびバージョン番号を含めた システムにインストールされているアプリケーションに関する情報 完全版 Splunk インスタンスとユニバーサルフォワーダーの両 が ホスト情報のローカル収集をサポートしています ホストモニター は splunk-winhostmon.exe と呼ばれるプロセスとして実 されます このプロセスは定義されている各 に対して に指定されている間隔で 1 回実 されます ホストのモニタリングは Splunk Web または inputs.conf を使って設定できます ホスト情報のモニター理由 Windows ホストのモニタリングにより Windows システムに関する詳細な情報を収集することができます ソフトウェアのインストールと削除 サービスの起動と停 および稼働時間などの システムに対する任意の変更をモニターすることができます システム障害が発 した場合 まず Windows ホストモニタリング情報を がかりに調査を進めていくことができます Splunk のサーチ 語を利 して Windows ネットワーク内のすべてのマシンの統計情報を で把握できる ダッシュボードやビューを作成することができます ホスト情報のモニターに何が必要か アクティビティ : ホスト情報のモニター 必要なアクセス許可 : * Splunk は Windows 上で実 する必要があります * すべてのローカルホスト情報を読み取るには Splunk を Local System ユーザーまたはローカル管理者として実 する必要があります セキュリティとリモートアクセスの検討事項 デフォルトでは Windows ホスト情報を収集するために Splunk を Local System ユーザーとして実 する必要があります リモートマシンからインデクサーへのホスト情報の送信には ユニバーサルフォワーダーを使 することをお勧めします Windows ホストデータを収集するための フォワーダーのインストール 設定 使 法については 分散デプロイ マニュアルの ユニバーサルフォワーダーの紹介 を参照してください Windows ホストデータを収集するために リモートマシン上にフォワーダーをインストールする場合 それらのマシンにはフォワーダーを Local System ユーザーとしてインストールすることができます Local System ユーザーは ローカルマシン上のすべてのデータにアクセスできますが リモートマシンにアクセスすることはできません Splunk を Local System 以外のユーザーとして実 する場合 そのユーザーには収集するホストデータがあるマシンに対する ローカル Administrator 権限が必要です また インストールマニュアル の Splunk を実 する Windows ユーザーの選択 で説明しているように ユーザーには他の明 的なアクセス許可が必要です Splunk Web を使ったホストモニタリングの設定 ローカルホストのモニタリング設定 1. Splunk Web の右上にある [ 設定 ] をクリックします 64

65 2. 表 されるポップアップの [ データ ] から [ データ ] をクリックします 3. [ ローカル Windows ホストモニタリング ] をクリックします [Windows ホストモニター ] ページが表 されます 4. [ 新規 ] をクリックして を追加します [ 新規追加 ] ページが表 されます 5. [ コレクション名 ] フィールドに この の覚えやすい名前を します 6. [ タイプ ] から この で収集する Windows ホスト情報タイプを選択します 7. Splunk 起動後すぐに を実 するには [1 度だけ実 する ] で [ はい ] ラジオボタンをクリックします [ 間隔 ( 秒 )] フィールドで指定した間隔で を実 する場合は [ いいえ ] をクリックします 8. [ 間隔 ( 秒 )] フィールドに 収集を実 する間隔を します 9. [ 保存 ] をクリックします が追加され 有効になります 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 を再起動します 次のセクションでは ホストのモニタリングのための 特定の設定値について説明していきます Windows ホストのモニター設定値 Splunk は Windows ホスト情報をモニターするために inputs.conf 内の以下の属性を使 しています 属性 必須? interval はい 新しいデータのポーリングを う頻度を秒で指定します 負の値を指定した場合 は 1 回のみ を実 します この属性を定義しない場合 デフォルト値は存在 しないためその は機能しません type はい モニターするホスト情報のタイプ Computer, operatingsystem, processor, disk, networkadapter, service, process, driver のいずれか または application を使 で きます この変数が存在しない場合 は実 されません 説明 disabled いいえ をまったく実 しないかどうか この属性に 1 を設定すると は実 されません Windows ホストモニタリング設定の例 inputs.conf での Windows ホストモニタリング設定属性の 使 法の例を以下に します # Queries OS information. # 'interval' set to a negative number tells Splunk to # run the input once only. [WinHostMon://os] type = operatingsystem interval = -1 65

66 # 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 が Windows ホストモニタリング からのデータのインデックスを作成する場合 受信したイベントのソースには windows が設定されます 受信イベントのソースタイプには WinHostMon が設定されます Answers 何か質問がありますか? Splunk Answers では Splunk コミュニティに寄せられた Windows ホスト情報に関する質問と回答をご覧いただけます Windows プリンタ情報のモニター Splunk は Windows 印刷サブシステム情報のモニターをサポートしています ローカルマシン上のプリンタとドライバ 印刷ジョブ およびプリンタポートなど あらゆる統計情報をモニターすることができます 以下の印刷システム情報を収集することができます プリンタ : 接続されているプリンタのステータス およびプリンタの追加 / 削除 時などの 印刷サブシステムに関する情報 ジョブ : 誰が何を印刷したか ジョブの詳細 既存のジョブのステータスなどの 印刷ジョブに関する情報 ドライバ : 既存のプリントドライバ情報 プリントドライバの追加 / 削除 時などの プリントドライバサブシステムの情報 ポート : システムにインストールされているプリンタポートの情報 および追加 / 削除 時 完全版 Splunk インスタンスとユニバーサルフォワーダーの両 が プリンタサブシステム情報のローカル収集をサポートしています プリンタモニター は splunk-winprintmon.exe と呼ばれるプロセスとして実 されます このプロセスは定義されている各 に対して に指定されている間隔で 1 回実 されます プリンタサブシステムのモニタリングは Splunk Web または inputs.conf を使って設定できます プリンタ情報のモニター理由 プリンタのモニタリングにより プリンタサブシステムに関する詳細な情報を収集することができます プリンタ プリントドライバ およびポートのインストールと削除 印刷ジョブの開始と完了 誰が何をいつ印刷したかなどの システムに対する任意の変更をモニターできます プリンタ障害が発 した場合 まずプリンタモニタリング情報を がかりに調査を進めていくことができます Splunk のサーチ 語を利 して Windows ネットワーク内のすべてのプリンタの統計情報を で把握できる ダッシュボードやビューを作成することができます 66

67 プリンタ情報のモニターに何が必要か アクティビティ : 必要なアクセス許可 : ホスト情報のモニター * Splunk は Windows 上で実 する必要があります * すべてのローカルホスト情報を読み取るには Splunk を Local System ユーザーとして実 する必要があります セキュリティとリモートアクセスの検討事項 デフォルトでは Windows 印刷サブシステム情報を収集するために Splunk を Local System ユーザーとして実 する必要があります リモートマシンからインデクサーへのプリンタ情報の送信には ユニバーサルフォワーダーを使 することをお勧めします 印刷サブシステムデータを収集するための フォワーダーのインストール 設定 使 法については 分散デプロイ マニュアルの ユニバーサルフォワーダーの紹介 を参照してください 印刷サブシステムデータを収集するために リモートマシン上にフォワーダーをインストールする場合 それらのマシンにはフォワーダーを Local System ユーザーとしてインストールすることができます Local System ユーザーは ローカルマシン上のすべてのデータにアクセスできますが リモートマシンにアクセスすることはできません Splunk を Local System 以外のユーザーとして実 する場合 そのユーザーには収集する印刷情報があるマシンに対する ローカル Administrator 権限が必要です また インストールマニュアル の Splunk を実 する Windows ユーザーの選択 で説明しているように ユーザーには他の明 的なアクセス許可が必要です Splunk Web を使ったプリンタ情報の設定 ローカル印刷のモニタリング設定 1. Splunk Web の右上にある [ 設定 ] をクリックします 2. 表 されるポップアップの [ データ ] から [ データ ] をクリックします 3. [ ローカル印刷モニター ] をクリックします [Windows 印刷モニター ] ページが表 されます 4. [ 新規 ] をクリックして を追加します [ 新規追加 ] ページが表 されます 5. [ コレクション名 ] フィールドに この の覚えやすい名前を します 6. [ タイプ ] から この で収集する Windows 印刷サブシステム情報タイプを選択します 7. Splunk 起動後すぐに を実 するには [ ベースライン ] で [ はい ] ラジオボタンをクリックします [ 間隔 ( 分 )] フィールドで指定した間隔で を実 する場合は [ いいえ ] をクリックします 8. [ インデックス ] ヘッダー下で プリンタサブシステムデータを保管するインデックスを選択するか またはデフォルトのインデックス (default) に保管する場合は何も選択せずにそのままにします 9. [ 保存 ] をクリックします が追加され 有効になります inputs.conf を使ったホストモニタリングの設定 inputs.conf を使ってホストのモニタリングを設定することができます inputs.conf を使ったデータ の設定の詳細は このマニュアルの の設定 を参照してください 注意 : 設定ファイルのデフォルトは %SPLUNK_HOME%\etc\system\default 内のファイルまたは 管理マニュアル で確認することができます 設定ファイルの編集 法については 管理マニュアル の 設定ファイルについて を参照してください inputs.conf を編集して印刷のモニタリング を有効にするには : 1. inputs.conf を %SPLUNK_HOME%\etc\system\default から etc\system\local にコピーします 2. エクスプローラまたは ATTRIB コマンドを使って ファイルの読み取り専 フラグを削除します 3. ファイルを開いて編集し Windows 印刷モニタリング を有効にします 4. Splunk を再起動します 次のセクションでは ホストのモニタリングのための 特定の設定値について説明していきます 印刷モニタリングの設定値 67

68 Splunk は Windows プリンタサブシステムをモニターするために inputs.conf 内の以下の属性を使 しています 属性 必須? interval はい 新しいデータのポーリングを う頻度を秒で指定します この属性が指定 定義さ れていない場合 デフォルト値は存在しないためその は機能しません type はい モニターするホスト情報のタイプ printer, job, driver のいずれか または port を使 できます この変数が存在しない場合 は実 されません 説明 baseline disabled いいえ いいえ 既存のプリンタ ジョブ ドライバ またはポートの状態のベースラインを 成するかどうかを します この属性に 1, を設定すると ベースラインが 成されます この場合 Splunk の起動までに時間がかかり CPU リソースも消費される可能性があります をまったく実 しないかどうか この属性に 1 を設定すると は実 されません Windows ホストモニタリング設定の例 inputs.conf での Windows ホストモニタリング設定属性の 使 法の例を以下に します # Monitor printers on system. [WinHostMon://printer] type = printer baseline = 0 # Monitor print jobs. [WinHostMon://job] type = job baseline = 1 # Monitor printer driver installation and removal. [WinHostMon://driver] type = driver baseline = 1 # Monitor printer ports. [WinHostMon://port] type = port baseline = 1 Windows 印刷モニタリングデータのフィールド Splunk が Windows 印刷モニタリング からのデータのインデックスを作成する場合 受信したイベントのソースには windows が設定されます 受信イベントのソースタイプには WinPrintMon が設定されます Answers 何か質問がありますか? Splunk Answers では Splunk コミュニティに寄せられた Windows 印刷モニタリングに関する質問と回答をご覧いただけます Windows ネットワーク情報のモニター Splunk は Windows ネットワーク情報のモニタリングをサポートしています Windows マシンとやり取りされるネットワークアクティビティに関する 詳細な統計情報をモニターできます 以下のネットワーク情報を収集することができます ネットワーク活動 :Windows マシンプラットフォームが任意のネットワーク活動を う場合 Splunk を使ってそれをモニターすることができます アドレスファミリー :IPv4 または IPv6 プロトコル経由でネットワークトランザクションが われたかどうか パケットタイプ : トランザクションで送信されたパケットタイプ ( 例 : connect または transport パケット ) プロトコル :TCP または UDP プロトコル経由でネットワークトランザクションが われたかどうか ホスト : ローカル / リモートホスト ホストが通信したポート 利 可能な DNS 情報などの ネットワークトランザクションに関与したホストに関する情報 アプリケーション : ネットワークトランザクションを開始したアプリケーション ユーザー : ネットワークトランザクションを開始したユーザー およびその ID と SID その他 : 伝送ヘッダーサイズやトランザクションが IPSec で保護されていたかどうかなどを含めた ネットワークトランザクションに関するその他の情報 完全版 Splunk インスタンスとユニバーサルフォワーダーの両 が ネットワーク情報のローカル収集をサポートしています 68

69 ネットワークモニター は splunk-netmon.exe と呼ばれるプロセスとして実 されます このプロセスは定義されている各 に対して に指定されている間隔で 1 回実 されます ネットワークのモニタリングは Splunk Web または inputs.conf を使って設定できます ネットワーク情報のモニター理由 Windows ネットワークのモニタリングにより Windows ネットワークアクティビティに関する詳細な情報を収集することができます ユーザーまたはプロセスによるネットワーク接続の開始 トランザクションが IPv4 または IPv6 アドレスを使 しているかどうかなど ネットワーク上のトランザクションをモニターすることができます Splunk のネットワークモニタリングを利 すれば サービス拒否攻撃の受信 / 発信に関与しているマシンを知らせることで 攻撃を検出 防 することができます Splunk のサーチ 語を利 して Windows ネットワーク内のすべてのネットワーク操作の統計情報を で把握できる ダッシュボードやビューを作成することができます ネットワーク情報のモニターに何が必要か アクティビティ : 要件 : ネットワーク情報のモニター Splunk は Windows 上で実 する必要がありますマシンの Windows は以下のいずれかでなければなりません Windows Vista Windows 7 Windows 8 Windows Server 2008 Windows Server 2008 R2 Windows Server 2012 Windows システムには 利 可能なアップデートやサービスパックをすべて適 しておく必要があります すべてのローカルホスト情報を読み取るには Splunk を Local System ユーザーまたはローカル管理者アカウントとして実 する必要があります セキュリティとリモートアクセスの検討事項 デフォルトでは Windows ネットワーク情報を収集するために Splunk を Local System ユーザーとして実 する必要があります リモートマシンからインデクサーへのホスト情報の送信には ユニバーサルフォワーダーを使 することをお勧めします Windows ホストデータを収集するための フォワーダーのインストール 設定 使 法については データの転送 マニュアルの ユニバーサルフォワーダーの紹介 を参照してください Windows ネットワーク情報を収集するために リモートマシン上にフォワーダーをインストールする場合 それらのマシンにはフォワーダーを Local System ユーザーとしてインストールすることができます Local System ユーザーは ローカルマシン上のすべてのデータにアクセスできますが リモートマシンにアクセスすることはできません Splunk を Local System 以外のユーザーとして実 する場合 そのユーザーには収集するホストデータがあるマシンに対する ローカル Administrator 権限が必要です また インストールマニュアル の Splunk を実 する Windows ユーザーの選択 で説明しているように ユーザーには他の明 的なアクセス許可が必要です Splunk Web を使ったホストモニタリングの設定 ローカルホストのモニタリング設定 1. Splunk Web の右上にある [ 設定 ] をクリックします 2. 表 されるポップアップの [ データ ] から [ データ ] をクリックします 3. [ ローカル Windows ネットワークモニタリング ] をクリックします [Windows ネットワークモニタリング ] ページが表 されます 4. [ 新規 ] をクリックして を追加します [ 新規追加 ] ページが表 されます 5. [ ネットワークモニター名 ] フィールドに この の覚えやすい名前を します 6. [ アドレスファミリー ] ヘッダーで モニターする IP アドレスファミリーのタイプ (IPv4 または IPv6) を選択します 7. [ パケットタイプ ] ヘッダーで モニターするパケットタイプ (connect accept transport.) を選択します 8. [ 向 ] ヘッダーで モニターするネットワークの 向を選択します ([ 着信 ] ( モニターしているホストが受信 ) または [ 発信 ] ( モニターしているホストから送信 )) 9. [ プロトコル ] フィールドで モニターするプロトコルの種類を選択します ([tcp] または [udp]) 10. [ リモートアドレス ] フィールドに モニターしているホストとネットワーク通信する モニター対象リモートホスト 69

70 のホスト名または IP アドレスを します 注意 : 複数のホストをモニターする場合は このフィールドに正規表現を指定します 11. [ プロセス ] フィールドに ネットワーク通信をモニターするプロセスの 名前の 部または全部を します 注意 : リモートアドレスと同様に 正規表現を使って複数のプロセスをモニターすることができます 12. [ ユーザー ] フィールドに ネットワーク通信をモニターするユーザーの 名前の 部または全部を します 注意 : リモートアドレスやプロセスの場合と同様に 正規表現を使って複数のプロセスをモニターすることができます 13. [ インデックス ] ドロップダウンから データを保管するインデックスを選択します 14. [ 保存 ] をクリックします が追加され 有効になります inputs.conf を使ったネットワークモニタリングの設定 inputs.conf を使ってネットワークのモニタリングを設定することができます inputs.conf を使ったデータ の設定の詳細は このマニュアルの の設定 を参照してください 注意 : 設定ファイルのデフォルトは %SPLUNK_HOME%\etc\system\default 内のファイルまたは 管理マニュアル で確認することができます 設定ファイルの編集 法については 管理マニュアル の 設定ファイルについて を参照してください inputs.conf を編集してネットワークのモニタリング を有効にするには : 1. inputs.conf を %SPLUNK_HOME%\etc\system\default から etc\system\local にコピーします 2. エクスプローラまたは ATTRIB コマンドを使って ファイルの読み取り専 フラグを削除します 3. ファイルを開いて編集し Windows ネットワークモニタリング を有効にします 4. Splunk を再起動します 次のセクションでは ホストのモニタリングのための 特定の設定値について説明していきます Windows ホストのモニター設定値 Windows ネットワークモニタリング を定義するには inputs.conf で [WinNetMon://<name>] スタンザを定義します Splunk は Windows ネットワークモニター の設定に 以下の属性を使 します 属性 : 説明 : デフォルト : disabled = [0 1] を有効にするかどうかを します を無効にするには 1 を 有効にするには 0 を設定します 0 ( 有効 ) index = < 字列 > データを保管するインデックスを指定します この属性は省略することができます デフォルトのインデックス remoteaddress = < 正規表現 > 設定した場合 ネットワークトランザクションに関与している IP アドレスと照合します IP アドレスを表す正規表現のみを使 できます ( ホスト名は不可 ) 正規表現に 致しないリモートアドレスのイベントはフィルタリングされます 正規表現に 致するリモートアドレスを持つイベントは収集されます 例 :192\.163\..* は x.x の範囲のすべての IP アドレスと 致します ( 空 字列 - すべてに 致 ) process = < 正規表現 > 設定した場合 ネットワークアクセスを実 したプロセスまたはアプリケーション名と照合されます 正規表現に 致しないプロセスが 成したイベントはフィルタリングされます 正規表現に 致するプロセスが 成したイベントは収集されます 70 ( 空 字列 - すべてのプロセスまたはアプリケーションに 致 )

71 収 user = < 正規表現 > addressfamily = [ipv4;ipv6] packettype = [connect;accept;transport] direction = [inbound;outbound] 設定した場合 ネットワークアクセスを実 したユーザー名と照合されます 正規表現に 致しないユーザーが 成したイベントはフィルタリングされます 正規表現に 致するユーザーが 成したイベントは収集されます 設定した場合 ネットワークアクセスに使 されたアドレスファミリーに対して照合が われます ipv4;ipv6 のように セミコロンで区切った値を使 できます 設定した場合 トランザクション内で使 されているパケットタイプに対して照合が われます connect;transport のように セミコロンで区切った値を使 できます 設定した場合 ネットワークトラフィックの 向に対して照合が われます Inbound はモニターを っているマシンに到着するトラフィックを outbound はモニターを っているマシンから出て くトラフィックを表しています inbound;outbound のように セミコロンで区切った値を使 できます ( 空 字列 - すべてのユーザーによるアクセスが含まれます ) ( 空 字列 - すべての IP トラフィックが含まれます ) ( 空 字列 - すべてのパケットタイプが含まれます ) ( 空 字列 - 両 の 向が含まれます ) protocol = [tcp;udp] 設定した場合 指定したネットワークプロトコルに対して照合が われます tcp は トランザクションの設定にハンドシェークと状態を使 する TCP を表しています udp は 状態を持たない UDP を表しています tcp;udp のように セミコロンで区切った値を使 できます ( 空 字列 - 両 のプロトコルタイプが含まれます ) readinterval = < 整数 > ネットワークモニターフィルタドライバを読み込む間隔 ( ミリ秒 ) を指定します 詳細オプション : のパフォーマンスに問題がない限り デフォルト値の使 をお勧めします カーネルドライバの呼び出し頻度を調整することができます 頻度を多くするとネットワークパフォーマンスに影響する可能性があります 頻度を少なくすると イベントが失われる可能性があります 妥当な最 値は 10 最 値は 1000 です 100 driverbuffersize = < 整数 > ネットワークモニターフィルタドライバのバッファに保持するネットワークパケット数を します 詳細オプション : のパフォーマンスに問題がない限り デフォルト値の使 をお勧めします ドライバがキャッシュに格納するパケットの量を制御します 値を さくするとイベントが失われる可能性が きくすると ページメモリーサイズが増加する可能性があります 妥当な最 値は 128 最 値は 8192 です 1024 mode = < 字列 > 各イベントの出 法を します Splunk は各イベントを single または multikv ( キー / 値のペア ) モードで出 することができます 71 single

72 multikvmaxeventcount = < 整数 > mode に multikv を設定した場合に 出 するイベントの最 量を します 詳細オプション : のパフォーマンスに問題がない限り デフォルト値の使 をお勧めします 妥当な最 値は 10 最 値は 500 です 100 multikvmaxtimems = < 整数 > mode に multikv を設定した場合に mulitkv イベントを出 するための最 時間を します 詳細オプション : のパフォーマンスに問題がない限り デフォルト値の使 をお勧めします 妥当な最 値は 100 最 値は 5000 です 1000 Windows ネットワークモニタリングデータのフィールド Splunk が Windows ネットワークモニタリング からのデータのインデックスを作成する場合 受信したイベントのソースには windows が設定されます 受信イベントのソースタイプには WinNetMon が設定されます Answers 何か質問がありますか? Splunk Answers では Splunk コミュニティに寄せられた Windows ネットワークモニタリングに関する質問と回答をご覧いただけます Other ways to get stuff in 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 に スタンザを追加します Splunk の設定ファイルで初めて作業を う場合は 事前に 設定ファイルについて を参照してください FIFO スタンザを追加するための基本的な構 を以下に します [fifo://<path>] <attrbute1> = <val1> <attrbute2> = <val2>... この スタンザは 指定したパスにある FIFO から読み込むことを Splunk に指 するものです FIFO スタンザでは 以下の属性を使 することができます host = <string> ホスト / キーフィールドに このスタンザの静的な値を設定します ホストキーの初期値を設定します このキーは パーシング / インデックス作成時に使 されます ( 特に host フィールドの設定時 ) サーチ時に使 される host フィールドでもあります <string> の前には host:: が付けられます 明 的に設定しない場合 デフォルトではデータの起源となるホストの IP アドレスまたは完全修飾ドメイン名が使 されます index = <string> この からのイベントを保管するインデックスを設定します <string> の前には index:: が付けられます デフォルトは main またはデフォルトのインデックスとして設定した任意の値になります インデックスフィールドの詳細は インデクサーとクラスタの管理 マニュアルの インデックス作成の仕組み を参照してください sourcetype = <string> 72

73 この からのイベントの sourcetype キー / フィールドを設定します このデータのソースタイプを 動的に判断する代わりに 明 的に宣 します このことは パーシングおよびインデックス作成中の このタイプのデータに対するサーチ可能性と関連するフォーマットの適 の両 で重要になります ソースタイプキーの初期値を設定します このキーは パーシング / インデックス作成時に使 されます ( 特に host フィールドの設定時 ) サーチ時に使 される source type フィールドでもあります <string> の前には sourcetype:: が付けられます 明 的に設定しない場合は データのさまざまな側 に基づいてソースタイプが選択されます ハードコード化されたデフォルト値はありません ソースタイプの詳細は このマニュアルの ソースタイプが重要な理由 を参照してください source = <string> この からのイベントの source キー / フィールドを設定します 注意 : source キーに優先する設定は 般的にお勧めできません 通常 レイヤーは データの取得場所を正確に記録し 問題の分析と調査を 援するために より正確な 字列を提供しています この値に優先する設定を う前に ソースタイプ タグ設定 およびワイルドカードを使ったサーチの使 を検討してください <string> の前には source:: が付けられます デフォルトは ファイルパスになります queue = [parsingqueue indexqueue] プロセッサが 読み込んだイベントをデポジットするかどうかを指定します データに props.conf および他のパーシングルールを適 する場合は parsingqueue を設定します データを直接インデックスに送信する場合は indexqueue を設定します デフォルトは parsingqueue です ファイルシステムへの変更のモニター 注意 : この機能は Splunk バージョン 5.0 で 推奨 ( 廃 予定 ) となりました 推奨で廃 予定の機能の 覧は リリースノートの 推奨 ( 廃 予定 ) の機能 を参照してください Splunk のファイルシステム変更モニター機能は ファイルシステム内の変更を追跡する場合に役 ちます ファイルシステム変更モニターは 指定した任意のディレクトリを監視して そのディレクトリに何らかの変更が われた場合に イベントを 成します さまざまな設定を変更することができ システム上の任意のファイル (Splunk 固有のファイルだけでなく ) の編集 削除 追加を検知することができます たとえば /etc/sysconfig/ を監視して システム設定が変更された時にアラートを 成するように設定することができます ファイルシステム変更モニターは inputs.conf に設定します 重要 : この機能と転送機能を使ってリモートインデクサーにイベントを送信する場合は ヘビーフォワーダーを使 するか または ユニバーサルフォワーダーでの使 の説明に従って設定を う必要があります 注意 :Windows でのファイル読み取りの監査については Splunk コミュニティのベストプラクティス Wiki を参照してください ユーザーによっては Windows のネイティブ監査ツールを利 する が簡単なこともあります ファイルシステム変更モニター機能の仕組み ファイルシステム変更モニターは 以下の情報を使って変更を検出します 変更 時グループ ID ユーザー ID ファイルモード ( 読み取り / 書き込み属性など ) ファイルコンテンツの SHA256 ハッシュ ( オプション ) ファイルシステム変更モニターの以下の機能を設定することができます 正規表現を使ったホワイトリスト監視対象ファイルの指定正規表現を使ったブラックリストスキップするファイルの指定ディレクトリ再帰シンボリックリンクトラバーサルを含める複数ディレクトリのスキャン およびそれぞれに対する独 のポーリング頻度の指定暗号化署名ファイルシステム変更の分散監査データの作成追加 / 変更時にファイル全体を 1 つのイベントとしてインデックス作成ファイル全体やハッシュの送信 にサイズ削減すべての変更イベントのインデックス作成と Splunk を使ったサーチ 警告 :root ファイルシステムのモニターに ファイルシステム変更モニターを使 しないでください そうすると ディレクトリ再帰が有効になっている場合に危険で また時間もかかります ファイルシステム変更モニターの設定 73

74 デフォルトでファイルシステム変更モニターは $SPLUNK_HOME/etc/ の内容が変更 削除 または追加された場合に 監査イベントを 成します Splunk を初めて起動する場合 $SPLUNK_HOME/etc/ ディレクトリとそのサブディレクトリ内の各ファイルに対して 監査イベントが 成されます その後は 設定に変更が われると ( 段に関係なく ) 影響するファイルに対して監査イベントが作成されます signedaudit=true の場合 ファイルシステム変更監査イベントは監査インデックス (index=_audit) に保管されます signedaudit が有効になっていない場合は 他のインデックスを指定しない限り デフォルトでイベントは main インデックスに書き込まれます 注意 : ファイルシステム変更モニターは 変更を ったアカウントのユーザー名はモニターしません 変更の発 のみをモニターしています ユーザーレベルのモニタリングの場合は その情報にアクセスするネイティブのオペレーティングシステム監査ツールの使 を検討してください ファイルシステム変更モニターを使ってディレクトリを監視するには $SPLUNK_HOME/etc/system/local/ 内または $SPLUNK_HOME/etc/apps/ の独 の App ディレクトリ内の inputs.conf に [fschange] スタンザを追加 編集します 設定ファイルの 般情報については 設定ファイルについて を参照してください 注意 :[fschange] スタンザを変更した場合は Splunk を再起動する必要があります 構 [fschange] スタンザの構 を以下に します [fschange:<directory or file to monitor>] <attribute1> = <val1> <attribute2> = <val2>... 以下の事項に注意してください 属性 システムは 指定ディレクトリとそのサブディレクトリの すべての追加 / 更新 / 削除操作をモニターします 任意の変更によりイベントが 成され Splunk によりインデックスが作成されます <directory or file to monitor> のデフォルトは $SPLUNK_HOME/etc/ です すべての属性は任意で 省略することができます 利 可能な属性の 覧を以下に します index=<indexname> 成されたすべてのイベントを保管するインデックス デフォルトは main です ( 監査イベント署名を有効にしていない場合 ) recurse=<true false> 真 (True) の場合 <code[fschange]</code> で指定されているディレクトリ内のすべてのディレクトリが再帰されます デフォルトは真 (True) です followlinks=<true false> 真 (True) の場合 ファイルシステム変更モニターはシンボリックリンクを追います デフォルトは偽 (false) です 警告 :followlinks の設定には注意を払う必要があります そうしないと システムループが発 する可能性があります pollperiod=n このディレクトリに対する変更を N 秒ごとにチェックします デフォルトは 3600 です 何らかの変更を った場合 そのシステム監査イベントが 成され それが監査 サーチに利 できるようになるまで 秒ほどかかります hashmaxsize=n N バイト以下の各ファイルの SHA1 ハッシュを算出します このハッシュは ファイル / ディレクトリの変更を検出するための 追加の 段として利 することができます デフォルトは -1 です ( 変更検出にハッシュを使 しない ) signedaudit=<true false> 暗号化署名した追加 / 更新 / 削除イベントを送信します デフォルトは偽 (false) です 真 (True) を設定すると _audit インデックス内にイベントが 成されます index 属性を設定している場合は 偽 (False) を設定する必要があります 74

75 注意 :signedaudit に真 (True) を設定する場合は audit.conf で監査が有効になっていることを確認してください fullevent=<true false> 追加または更新を検出した場合に 完全なイベントを送信します sendeventmaxsize 属性でさらに修飾されます デフォルトは偽 (false) です sendeventmaxsize=n イベントのサイズが N バイト以下の場合にのみ 完全なイベントを送信します これにより インデックス作成されたファイルデータのサイズを制限します デフォルトは -1 ( 無制限 ) です sourcetype = <string> この からのイベントのソースタイプを設定します "sourcetype::" is automatically prepended to <string>. デフォルトは audittrail (signedaudit=true の場合 ) または fs_notification (signedaudit=false の場合 ) になります filesperdelay = <integer> <integer> 件のファイルの処理後 delayinmills に指定されている時間に相当する遅延を挟みます これは CPU を消費しすぎないように ファイルシステムのモニタリングを抑制するために いられます delayinmills = <integer> filesperdelay に指定されているように <integer> 件のファイルの処理ごとに使 する遅延時間 ( ミリ秒 ) これは CPU を消費しすぎないように ファイルシステムのモニタリングを抑制するために いられます filters=<filter1>,<filter2>,...<filtern> これらの各フィルタは モニターのポーリングサイクル中に つかった各ファイルやディレクトリに対して 左から右へと適 されていきます フィルタの定義については 次のセクションを参照してください フィルタの定義 filters 属性で使 するフィルタを定義するには 以下のように [filter...] スタンザを定義します [filter:blacklist:backups] regex1 =.*bak regex2 =.*bk [filter:whitelist:code] regex1 =.*\.c regex2 =.*\.h [fschange:/etc] filters = backups,code Fschange ホワイトリスト / ブラックリストロジックは 般的なファイアウォールと同じように処理されます イベントは 最初に 致するフィルタが つかるまで フィルタのリストと順番に照合されていきます イベントと最初に 致したフィルタがホワイトリストの場合 そのイベントのインデックスが作成されます イベントと最初に 致したフィルタがブラックリストの場合 そのイベントのインデックスは作成されません 致するフィルタが つからなかった場合は イベントのインデックスが作成されます これは 暗黙的に すべて通過 フィルタが存在し すべてに該当しないイベントのインデックスが作成されることを意味しています そのような場合にインデックスを作成させたくない場合は リストの最後に残りのイベントに 致するブラックリストを設定します 例 :... filters = <filter1>, <filter2>,... terminal-blacklist [filter:blacklist:terminal-blacklist] regex1 =.? 重要 : 連のホワイトリストの最後にある最終ブラックリストも含めて あるディレクトリがブラックリストの対象となった場合 そのすべてのサブフォルダとファイルは 動的にブラックリスト化され ホワイトリストに渡されることはありません これに対処するために ブラックリストフィルタの前に 必要なフォルダとサブフォルダすべてを明 的にホワイトリストに指定してください 例 指定ディレクトリ内の拡張 が.config.xml.properties および.log のファイルをモニターし その他すべてを無視 75

76 する設定を以下に します 注意 : この例では ディレクトリがブラックリストに該当する可能性があります その場合 そのすべてのサブフォルダとファイルも 動的にブラックリスト化されます ホワイトリストに指定されたディレクトリ内のファイルのみがモニターされます [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 = delayinmills = 1000 filters = configs,terminal-blacklist ユニバーサルフォワーダーでの使 ユニバーサルフォワーダーからファイルシステム変更モニターイベントを転送するには signedaudit = false と index=_audit を設定する必要があります [fschange:<directory or file to monitor>] signedaudit = false index=_audit この 法では ファイルシステム変更モニターイベントのインデックスは _audit インデックスに作成され sourcetype には fs_notification が source には fschangemonitor が設定されます (sourcetype と source の両 に対して デフォルト値の audittrail の代わりに ) スクリプト を介した API や他のリモートデータインターフェイスからのデータの取得 Splunk は 指定したスクリプトからのイベントを受け取ることができます Splunk は vmstat iostat netstat top などの Windows または *nix コマンドラインツールと連携させると効果を発揮します スクリプト を使って API や他のリモートデータインターフェイス メッセージキューなどからデータを取得できます 次にそのデータに対して vmstat や iostat などのコマンドを使って 測定基準やステータスデータを 成することができます 注意 : このトピックは すでに 連の Splunk に書き込んだスクリプト の追加 法を説明しています スクリプト の開発 法については Developing Views and Apps for Splunk Web マニュアルの Build scripted inputs を参照してください Splunkbase にあるさまざまな App が 特定の 途向けのスクリプト を提供しています 検索するには [Launcher] で [Browse more apps] ( 他の App を参照 ) タブを使 します スクリプト を設定するには [ システム ] を使 するか または inputs.conf を編集します 注意 :Windows プラットフォームでは 中継 Windows バッチ (.bat) または PowerShell (.ps1) ファイルを使って perl や python などのテキストベースのスクリプトを有効にすることができます 警告 : スクリプト を介して起動されたスクリプトは Splunk の環境を継承します そのため スクリプトの動作に影響する可能性がある環境変数は 忘れずに消去しておくようにしてください 問題が発 する可能性が い唯 の環境変数が ライブラリパスの環境変数です ( 般的に Linux Solaris および FreeBSD では LD_LIBRARY_PATH) リリース 4.2 以降 Splunk はスクリプト が作成した任意の stderr メッセージを splunkd.log に記録するようになりました Splunk Web を使ったスクリプト の追加 Splunk Web を使ってスクリプト を追加するには : A. [ 新規追加 ] ページに移動 76

77 スクリプト は Splunk Web の [ 新規追加 ] ページから追加します 2 種類の 法でこのページを表 できます [ システム ] Splunk ホーム どちらの 法を使 しても構いません 同じ [ 新規追加 ] ページが表 されます [ システム ] の場合 : 1. Splunk Web の左上にある [ システム ] をクリックします 2. [ システム ] ポップアップの [ データ ] セクションで [ データ ] をクリックします 3. [ スクリプト ] をクリックします 4. [ 新規 ] ボタンをクリックして を追加します Splunk ホームを使 する場合 : 1. Splunk ホームの [ データの追加 ] リンクをクリックします [ データレシピ ] ページが表 されます 2. を追加するには [ 実 してスクリプトの出 を収集 ] をクリックします B. スクリプト の指定 1. [ コマンド ] ボックスに スクリプトへのパスも含めたスクリプトコマンドを指定します 2. [ 間隔 ] に スクリプト実 の間隔を秒で指定します デフォルトは 60 ( 秒 ) です 3. 必要に応じて [ ソース名 ] に デフォルト値に優先する新たなソース名を します 重要 : この値を変更する前に Splunk サポートにお問い合わせください 4. 他の設定にアクセスするには [ その他の設定 ] を選択します 追加の設定が表 されます 通常は これらの設定はデフォルト値のままで 分です 明 的に設定したい場合は 以下の説明を参照してください a. 必要に応じて [ ホスト ] の値を変更できます b.[ ソースタイプ ] を設定することができます ソースタイプは イベントに追加されるデフォルトのフィールドです ソースタイプは タイムスタンプやイベント境界などの 処理する特徴の決定に いられます Splunk の 動ソースタイプ設定に優先する設定を うには このマニュアルの ソースタイプの 動割り当てに優先する設定 を参照してください c. この のインデックスを設定することができます 異なる種類のイベントを取り扱うために 複数のインデックスを定義している場合を除き この値は default のままにしてください ユーザーデータ のインデックスに加えて Splunk にはさまざまなユーティリティインデックスが存在しています これらのインデックスも このドロップダウンボックスに表 されます 5. [ 保存 ] をクリックします inputs.conf を使ったスクリプト の追加 スクリプト を追加するには inputs.conf に [script] スタンザを追加します 構 [script] スタンザの構 を以下に します [script://$script] <attrbute1> = <val1> <attrbute2> = <val2>... 以下の事項に注意してください 属性 $SCRIPT は スクリプトのある場所への完全パスです ベストプラクティスとして スクリプトを指定した 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/ に保管します すべての属性は任意で 省略することができます 利 可能な属性の 覧を以下に します 77

78 interval = <number> <cron schedule> 指定したコマンドの実 頻度を します 秒を表す整数値または有効な cron スケジュールを指定します デフォルトは 60.0 秒です cron schedule を指定した場合 起動時にスクリプトは実 されません cron スケジュールに定義されている時間に実 されます Splunk はインスタンスあたり 1 つのスクリプト呼び出しを維持します 間隔は スクリプトの完了時期に基づいています そのため 10 分ごとに実 するように設定したスクリプトがあり スクリプトの実 完了に 20 分かかった場合 次回のスクリプト実 は最初の実 から 30 分後に われます 常時データストリームがある場合は 1 ( または スクリプトの間隔よりも さな値 ) を します 単発のデータストリームの場合は -1 を します interval に -1 を設定すると 毎回 Splunk デーモンの再起動時にスクリプトが実 されます index = <string> この からのイベントを保管するインデックスを設定します Splunk は <string> の前に index:: を付けます デフォルトは main またはデフォルトのインデックスとして設定した任意の値になります インデックスフィールドの詳細は インデクサーとクラスタの管理 マニュアルの インデックス作成の仕組み を参照してください sourcetype = <string> この からのイベントの sourcetype キー / フィールドを設定します このデータのソースタイプを 動的に判断する代わりに 明 的に宣 します このことは パーシングおよびインデックス作成中の このタイプのデータに対するサーチ可能性と関連するフォーマットの適 の両 で重要になります ソースタイプキーの初期値を設定します このキーは パーシング / インデックス作成時に使 されます ( 特に host フィールドの設定時 ) サーチ時に使 される source type フィールドでもあります <string> の前には sourcetype:: が付けられます 明 的に設定しない場合は データのさまざまな側 に基づいてソースタイプが選択されます ハードコード化されたデフォルト値はありません ソースタイプの詳細は このマニュアルの ソースタイプが重要な理由 を参照してください source = <string> この からのイベントの source キー / フィールドを設定します 注意 : ソースキーに優先する設定は わないことをお勧めします 通常 レイヤーは データの取得場所を正確に記録し 問題の分析と調査を 援するために より正確な 字列を提供しています この値に優先する設定を う前に ソースタイプ タグ設定 およびワイルドカードを使ったサーチの使 を検討してください Splunk は <string> の前に source:: を付けます デフォルトは ファイルパスになります disabled = <true false> disabled は を無効にしたい場合に真 (True) を設定する論理値です デフォルトは false です スクリプトを継続的に実 する場合は 終了しないようにスクリプトを作成し それに短い間隔を設定します これにより 何か問題があった場合でも Splunk が再起動されます Splunk は派 したスクリプトを追跡し 終了時にはシャットダウンを います ラッパースクリプトの使 般的に スクリプト に 引数を指定したコマンドを使 するラッパースクリプトを作成することが役 ちます 場合によってはコマンドに Splunk Web が されたテキストの検証時にエスケープ処理を う 特殊 字を使 できる場合もあります この場合 以前に設定した の更新すると 保存に失敗してしまいます 注意 :Splunk がテキストの検証時にエスケープ処理を う 字とは 等号 (=) やセミコロン (;) などの パスに使 できない 字のことです たとえば 以下のスクリプト を Splunk Web で編集した場合 Splunk はパラメータ内の等号 (=) をエスケープ処理して 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/ を使 します 78

79 $ 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. シェルを介してスクリプトを実 することで スクリプトが正しく機能することを確認してください $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 sourcetype = top source = script://./bin/top.sh # run every 5 seconds # set sourcetype to top # set source to name of script 注意 : props.conf を変更しなければならない場合もあります デフォルトで Splunk は 単 の top エントリを複数のイベントに分割します この問題に対処するには 出 に存在していない何かの前でのみ分割するように Splunk サーバーに指 します たとえば $SPLUNK_HOME/etc/apps/scripts/default/props.conf に以下の項 を追加すると すべての が単 のイベントに含まれます [top] BREAK_ONLY_BEFORE = <stuff> top 出 にはタイムスタンプがないため 現在の時刻を使 するように指定する必要があります そのためには props.conf に以下の項 を設定します DATETIME_CONFIG = CURRENT cron スケジュールへの interval 属性の設定 上記の例で 以下のような 字列を使 して cron スケジュールに interval 属性を設定することもできます 0 * * * *:1 時間に 1 回 時間の開始時に実 することを します */ * * 1-5: 曜の午前 9 時から午後 5 時までの間 15 分ごとに実 することを します 15,35,55 0-6, */2 *: 各偶数 ( など ) の始めに 午前 0 時 午前 7 時および午後 8 時 午前 0 時の間の各時間の および 55 分に実 することを します cron スケジュールの詳細は Crontab Web サイトの CRONTAB(5) を参照してください crawl を使ったモニター項 の発 ファイルシステムまたはネットワークをサーチして インデックスに追加する新たなデータソースを探すには crawl サーチコマンドを使 します デフォルトの crawl 設定を変更するには crawl.conf を編集します crawl のデフォルトに優先する設定を crawl の実 時に指定することができます crawl は crawl アクティビティのログを 成し $SPLUNK_HOME/var/log/splunk/crawl.log に保管します crawl のデフォルトの変更 79

80 crawl のデフォルトの設定を変更するには $SPLUNK_HOME/etc/system/local/crawl.conf を編集します ファイルとネットワークの crawl は それぞれ独 のスタンザに個別に定義します 構 crawl.conf には 2 つのスタンザが存在しています [files] と [network] は それぞれがファイルとネットワークの crawl のデフォルトを定義しています これらのスタンザに定義できる属性とデフォルト値の詳細は crawl.conf spec ファイルを参照してください 例 ファイルとネットワークの両 に対して 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, big_dir_filecount= 100 index=main max_badfiles_per_dir=100 [network] host = myserver subnet = 24 レシピ フォワーダー 重要 : フォワーダーの の設定は インデクサーでの設定と同じ 法で えます 唯 の違いが フォワーダーには Splunk Web が含まれていないため を CLI または inputs.conf を使って設定する必要があることです を設定する前に このレシピで説明するように フォワーダーをデプロイ 設定する必要があります Splunk のフォワーダーを使って レシーバーと呼ばれるインデクサーにデータを送信することができます 通常はこの 法が リモートデータをインデクサーに取り込むために推奨する 法です フォワーダー 特にユニバーサルフォワーダーを使 してリモートデータを取り込む場合 フォワーダーとレシーバーのトポロジーを構築して データ を設定する必要があります 1. レシーバーとして使 する Splunk インスタンスをインストールします 詳細は インストールマニュアル を参照してください 2. Splunk Web または CLI を使って レシーバーにするインスタンスの受信を有効にします データの転送 マニュアルの レシーバーを有効にする を参照してください 3. フォワーダーをインストール 設定 デプロイします 転送ニーズに応じて さまざまなデプロイのベストプラクティスが存在しています 詳細は データの転送 マニュアルの ユニバーサルフォワーダーのデプロイの概要 を参照してください これらのシナリオの 部では インストール時にフォワーダーを設定することができます 4. インストール時に作業を っていない場合は 各ユニバーサルフォワーダーに対してデータ を指定します この作業は 他の Splunk インスタンスの場合と同じ 法で います 各種データ の設定については このマニュアルの Splunk がインデックス処理できる項 を参照してください 注意 : ユニバーサルフォワーダーには Splunk Web が含まれていないため CLI や inputs.conf を使って 設定する必要があります Splunk Web で設定することはできません 5. インストール時に設定していない場合は フォワーダーの出 を設定します そのためには CLI を使 するか または outputs.conf ファイルを編集します outputs.conf を編集する が柔軟性に優れています 詳細は データの転送 マニュアルの outputs.conf によるフォワーダーの設定 などの項 を参照してください 6. テストを って 転送やードバランシングやフィルタリングなどの他の設定した動作が 期待通りに動作することを確認します 結果データをサーチするには レシーバーに移動します フォワーダーの詳細は データの転送 マニュアルの 転送と受信について を参照してください また このマニュアルの フォワーダーの使 も参照してください 80

81 ファイルとディレクトリ - ローカル Splunk でもっとも多彩な機能の 1 つが ファイルとディレクトリをモニターして イベントを収集する機能です システムがイベントを 成したら Splunk がそれのインデックスを作成して サーチ レポート およびアラートを作成 実 することができます ファイルやディレクトリからデータを取得するには そのファイルやディレクトリを設定します 1. Splunk Web の [ ホーム ] ページで [ データの追加 ] をクリックします 2. [To get started...] バナー下で [ ファイルまたはディレクトリ ] をクリックします 3. [ この Splunk サーバーで任意のファイルを使 する ] の下にある [ 次へ ] をクリックします 4. [ ファイルやディレクトリからデータを収集 ] ページで 3 種類の中からいずれかのデータソースをクリックして指定します 5. [ データへのフルパス ] フィールドで モニターするファイルまたはディレクトリへのパスを します 般的に他のフィールドは [ その他の設定 ] オプション下のフィールドも含めて 空のままでも構いません これらのフィールドの詳細は ここを参照してください 6. [ 保存 ] をクリックします 7. [ 成功 ] ページで [ サーチ ] をクリックしてサーチを開始します データ内の任意の 語を することができます また ソース ソースタイプ またはホストをクリックして syslog ディレクトリ内の異なるディレクトリからのデータ それらのディレクトリ内の異なるタイプのデータ または当初 syslog データを送信した各ホストを参照することができます ファイルやディレクトリからのデータの取り込みの詳細は このマニュアルの ファイルとディレクトリのモニター を参照してください ファイルとディレクトリ - リモート リモートマシンから Splunk にログを取り込むもっとも簡単な 法は ユニバーサルフォワーダーを使 することです フォワーダーはログを 成しているマシン上にインストールして インデクサーにデータを送信するように設定します フォワーダーはログをモニターして イベントをインデクサーに転送します インデクサーはイベントのインデックスを作成し サーチできるように処理します これには 2 つの主要ステップがあります 1. リモートマシン上にフォワーダーを設定し データの転送先となるインデクサーを設定します See this recipe: "Forwarders". 2. ログをモニターするように フォワーダーの を設定します フォワーダーの は インデクサーの場合と同じように設定します ただし フォワーダーには Splunk Web がないため の設定には CLI を使 するか または inputs.conf を直接編集する必要があります UNIX ログをモニターするための の設定については このマニュアルの ファイルとディレクトリのモニター を参照してください フォワーダーの設定に関するその他の情報は このマニュアルの フォワーダーの使 を参照してください Syslog - ローカル ローカルの syslog データを取得する場合は syslog ファイルのディレクトリを指定します 1. Splunk Web の [ ホーム ] ページで [ データの追加 ] をクリックします 2. [To get started...] バナー下で [Syslog] をクリックします 3. [ この Splunk サーバー上にある任意の syslog ファイルまたはディレクトリを使 する ] の下にある [ 次へ ] をクリックします 4. [ ファイルやディレクトリからデータを収集 ] ページで 3 種類の中からいずれかのデータソースをクリックして指定します 5. [ データへのフルパス ] フィールドで syslog ディレクトリへのパスを します *nix システムでは 通常これは /var/log になります Windows の場合 インストールしているサードパーティ製 syslog デーモンによってパスは異なります デフォルトで Windows は syslog 機能を提供していません 代わりに イベントログサービスを使 して ログを記録しています 般的に他のフィールドは [ その他の設定 ] オプション下のフィールドも含めて 空のままでも構いません これらのフィールドの詳細は ここを参照してください 81

82 6. [ 保存 ] をクリックします 7. [ 成功 ] ページで [ サーチ ] をクリックしてサーチを開始します データ内の任意の 語を することができます また ソース ソースタイプ またはホストをクリックして syslog ディレクトリ内の異なるディレクトリからのデータ それらのディレクトリ内の異なるタイプのデータ または当初 syslog データを送信した各ホストを参照することができます ファイルやディレクトリからのデータの取り込みの詳細は このマニュアルの ファイルとディレクトリのモニター を参照してください Syslog - TCP Splunk は TCP ポートで 1 つまたは複数のホストからの syslog サービスから送られてくるデータを待機することができます これらのホストからの syslog の収集に Splunk を使って 軽にサーチ レポート およびアラートを利 することができます TCP 経由で syslog データを取得するには syslog データが到着するネットワークポートで待機するように Splunk を設定します 1. Splunk Web の [syslog] ページに移動します 2. 次に [TCP からの syslog データ ] の下にある [ 次へ ] を選択します 3. 次のページの [TCP ポート ] フィールドに 他の syslog が動作しているシステムからの接続を受け付ける TCP ポートを します 4. 次に [ すべてのホストからの接続を受け付けますか?] に 的に応じて適切な項 を設定します そのためには [ はい ] または [ いいえ 1 つのホストに制限します ] ラジオボタンを選択します [ いいえ 1 つのホストに制限します ] を選択した場合 [ ホスト制限 ] フィールドが表 されます ネットワーク上の有効なホスト名を 1 つ します Splunk はそのコンピュータからの接続のみを受け付けます 5. 必要に応じて [ ソース名上書き ] フィールドに 字列を して スクリプトのデフォルトのソース値に優先する設定を うことができます 6. また [ ソースタイプの設定 ] ドロップダウンの [ リストから ] を選択して 次に [ リストからソースタイプを選択 ] ドロップダウンから 的の項 を選択することで このソースが 成するイベントのソースタイプを設定することも可能です このような場合には おそらくソースタイプに syslog を設定するのもお勧めです 7. 代わりに [ ソースタイプの設定 ] から [ 動 ] を選択して 次に表 される [ ソースタイプ ] フィールドに 字列を することもできます 般的に他のフィールドは [ その他の設定 ] オプション下のフィールドも含めて 変更しないままでも構いません 8. 最後に [ 保存 ] をクリックします 9. [ 成功 ] ページで [ サーチ ] をクリックしてサーチを開始します データ内の任意の 語を することができます また ソース ソースタイプ またはホストをクリックして syslog ディレクトリ内の異なるディレクトリからのデータ それらのディレクトリ内の異なるタイプのデータ または当初 syslog データを送信した各ホストを参照することができます ネットワークからのデータの取得の詳細は このマニュアルの TCP および UDP ポートからのデータの取得 を参照してください Syslog - UDP Splunk は UDP ポートで 1 つまたは複数のホストからの syslog サービスから送られてくるデータを待機することができます これらのホストからの syslog の収集に Splunk を使って 軽にサーチ レポート およびアラートを利 することができます UDP 経由で syslog データを取得するには UDP ポート経由でそのデータを待機するように Splunk を設定します 1. Splunk Web の [syslog] ページに移動します 2. 次に [UDP からの syslog データ ] の下にある [ 次へ ] を選択します 3. 次のページの [UDP ポート ] フィールドに 他の syslog が動作しているシステムからの接続を受け付ける UDP ポートを します デフォルトの syslog UDP ポートは 514 です 4. 必要に応じて [ ソース名上書き ] フィールドに 字列を して スクリプトのデフォルトのソース値に優先する設定を うことができます 5. また [ ソースタイプの設定 ] ドロップダウンの [ リストから ] を選択して 次に [ リストからソースタイプを選択 ] ド 82

83 ロップダウンから 的の項 を選択することで このソースが 成するイベントのソースタイプを設定することも可能です このような場合には おそらくソースタイプに syslog を設定するのもお勧めです 6. 代わりに [ ソースタイプの設定 ] から [ 動 ] を選択して 次に表 される [ ソースタイプ ] フィールドに 字列を することもできます 般的に他のフィールドは [ その他の設定 ] オプション下のフィールドも含めて 変更しないままでも構いません これらのフィールドの詳細は ここを参照してください 7. 最後に [ 保存 ] をクリックします 8. [ 成功 ] ページで [ サーチ ] をクリックしてサーチを開始します データ内の任意の 語を することができます また ソース ソースタイプ またはホストをクリックして syslog ディレクトリ内の異なるディレクトリからのデータ それらのディレクトリ内の異なるタイプのデータ または当初 syslog データを送信した各ホストを参照することができます ネットワークからのデータの取得の詳細は このマニュアルの TCP および UDP ポートからのデータの取得 を参照してください Windows イベントログ - ローカル Splunk では 軽に素早く Windows イベントログを収集することができます セキュリティ上のアラート 成 または Windows システムのヘルス状態を判断するための 各種イベント ID のレポートの 成またはサーチのために Splunk のイベントログ収集機能はスナップショットを取得することができます ローカルイベントログデータを取得するには イベントログサービスを指定します 1. Splunk Web の [ ホーム ] ページで [ データの追加 ] をクリックします 2. [To get started...] バナー下で [Windows イベントログ ] をクリックします 3. [ この Splunk サーバーから Windows イベントログを収集する ] 下の [ 次へ ] をクリックします 4. [ 利 可能なログ ] ウィンドウで モニターするイベントログチャネルをクリックします [ 選択したログ ] ウィンドウにログチャネルが表 されます 5. 必要に応じて [ インデックス ] ドロップダウンボックスからインデックスを選択して このソースの宛先インデックスを設定します 6. [ 保存 ] をクリックします 7. [ 成功 ] ページで [ サーチ ] をクリックしてサーチを開始します テータ内の任意の 語を することができます また ソース ソースタイプ またはホストをクリックして Splunk に取り込まれたイベントのデータを参照することができます ファイルやディレクトリからのデータの取り込みの詳細は データの取り込み マニュアルの Windows イベントログデータのモニター を参照してください Windows イベントログ - リモート Splunk は Windows イベントログをローカルに または WMI 経由でリモートにモニターすることができます セキュリティ上のアラート 成 または Windows システムのヘルス状態を判断するための 各種イベント ID のレポートの 成またはサーチのために Splunk のイベントログ収集機能はスナップショットを取得することができます 重要 :Windows イベントログをリモートに収集するには そのログがあるマシンにアクセスできる権限があるユーザーとして Splunk インスタンスをインストールする必要があります 詳細は このマニュアルの リモート Windows データのモニター 法決定の検討事項 を参照してください リモート Windows イベントログデータを取得するには リモートマシンのイベントログサービスを指定します 1. Splunk Web の [ ホーム ] ページで [ データの追加 ] をクリックします 2. [To get started...] バナー下で [Windows イベントログ ] をクリックします 3. [ 他のコンピュータから Windows イベントログを収集 ] 下の [ 次へ ] をクリックします 4. [ イベントログコレクション名 ] に 収集するイベントログの 意の名前を します 5. [ このホストからログを選択 ] フィールドに Windows ネットワーク上のマシンのホスト名を します 短いホスト名 サーバーの完全修飾ドメイン名 または IP アドレスを指定することができます 6. [ ログのサーチ â ] をクリックして リモートマシン上の利 可能なイベントログチャネルのリストを取得します 7. 表 される [ 利 可能なログ ] ウィンドウで モニターするイベントログチャネルをクリックします 83

84 [ 選択したログ ] ウィンドウにログチャネルが表 されます 8. 必要に応じて 同じセットのイベントログを収集する他のサーバーを指定することができます 各ホスト名をカンマで区切って してください 9. また このソースの宛先インデックスを設定することもできます そうする場合は [ インデックス ] ドロップダウンボックスから インデックスを選択します 10. [ 保存 ] をクリックします 11. [ 成功 ] ページで [ サーチ ] をクリックしてサーチを開始します テータ内の任意の 語を することができます また ソース ソースタイプ またはホストをクリックして Splunk に取り込まれたイベントのデータを参照することができます Windows イベントログからのデータの取り込みの詳細は このマニュアルの Windows イベントログデータのモニター を参照してください Windows イベントログ - 多数のリモート 多数の Windows マシンから Windows イベントログを収集するには さまざまな 法があります たとえば Windows イベントログ - リモート のレシピを使って マシンから Splunk インスタンスにログを取り込みます また より 軽で きな環境にも対応できる 段として Splunk のユニバーサルフォワーダーを使 する 法が挙げられます フォワーダーは 的のイベントログを 成するマシン上に設定します 次に フォワーダーにデータを転送するインデクサーを指 します フォワーダーは各マシン上で 的のイベントログをモニターし そのデータをインデクサーに転送します インデクサーはサーチが可能になるように データのインデックスを作成します 量のリモート Windows マシンからイベントログを収集するもっとも効率的な 法が ユニバーサルフォワーダーを使 することです これには 2 つの主要ステップがあります 1. リモートマシン上にフォワーダーを設定し データの転送先となるインデクサーを設定します フォワーダー のレシピを参照してください 2. 的のイベントログをモニターするように フォワーダーの を設定します フォワーダーの は インデクサーの場合と同じように設定します ただし フォワーダーには Splunk Web がないため の設定には CLI を使 するか または inputs.conf を直接編集する必要があります Windows イベントログからデータを取り込むための の設定については このマニュアルの Windows イベントログデータのモニター を参照してください フォワーダーの設定に関するその他の情報は このマニュアルの フォワーダーの使 を参照してください Windows レジストリ - ローカル Windows マシンのレジストリの変更をモニターすることができます ハイブ全体でも単に 1 つのキーでも それが追加 変更 削除 または単純に読み込みでも Splunk のレジストリモニタリングサービスはそれらのデータを収集し それに対してサーチ レポート アラート機能を利 することができます ローカル Windows のレジストリ変更データを収集するには Splunk でレジストリをモニターします 1. Splunk Web の [ ホーム ] ページで [ データの追加 ] をクリックします 2. [To get started...] バナー下で [Windows レジストリ ] をクリックします 3. [ この Splunk サーバーで Windows レジストリデータを収集する ] 下の [ 次へ ] をクリックします 4. [ 新規 ] をクリックします 5. 次のページで [ コレクション名 ] フィールドに覚えやすい名前を します 6. [ レジストリハイブ ] フィールドの隣りにある [ 参照...] ボタンをクリックして モニターするハイブのパスを選択します 7. ツリービューが表 されたら ツリービュー内のフォルダまたはドキュメントアイコンをクリックして モニターするハイブまたはキーを選択します たとえば HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control レジストリパスをモニターする場合 ツリービューで HKEY_LOCAL_MACHINE を 1 回クリックして展開し 次に展開したリストの SYSTEM をクリックし 次に CurrentControlSet をクリックして 最後に Control をクリックします 選択したレジストリパスは ウィンドウ下部にある [ 修飾名 ] フィールドに表 されます 8. モニターするハイブまたはキーを選択したら [ 選択 ] をクリックします 9. ステップ 7 で選択したハイブまたはノード下のすべてのレジストリキーパスをモニターする場合は [ モニターサブ 84

85 ノード ] チェックボックスを選択します 注意 : 収集したレジストリイベントのフィルタリングについては 後述する情報を忘れずに参照してください 10. 的のイベントの隣りにあるチェックボックスを使って モニターするレジストリのイベントタイプを最 7 つまで選択します 注意 : これらのイベントタイプの詳細は このマニュアルの Splunk Web でレジストリモニタリングを有効にする を参照してください 般的に他のフィールドは [ その他の設定 ] オプション下のフィールドも含めて 変更しないままでも構いません 11. [ 保存 ] をクリックします 12. [ レジストリ監視 ] ページに戻ります ここでは 新しいレジストリモニタリング を追加することができます また 画 左上の [ ホームに戻る ] をクリックして 取り込んだデータのサーチを実 することもできます Windows レジストリモニタリング は 量のデータを 成します そのようなデータのフィルタリング 法 およびレジストリモニター に関するその他の情報については このマニュアルの Windows レジストリデータのモニター を参照してください Windows レジストリ - リモート リモート Windows レジストリの変更データを Splunk に取り込むもっとも簡単で唯 の 法が ユニバーサルフォワーダーを使 することです フォワーダーはレジストリデータを 成しているマシン上にインストールして 的のインデクサーにデータを送信するように設定します フォワーダーはログをモニターして イベントをインデクサーに転送します インデクサーはイベントのインデックスを作成し サーチできるように処理します リモートマシンからレジストリデータを収集する唯 の 法が ユニバーサルフォワーダーを使 することです これには 2 つの主要ステップがあります 1. リモートマシン上にフォワーダーを設定し データの転送先となるインデクサーを設定します フォワーダー のレシピを参照してください 2. レジストリをモニターするように フォワーダーの を設定します フォワーダーの は インデクサーの場合と同じように設定します ただし フォワーダーには Splunk Web がないため の設定には CLI を使 するか または inputs.conf を直接編集する必要があります レジストリをモニターするための の設定については このマニュアルの Windows レジストリデータのモニター を参照してください フォワーダーの設定に関するその他の情報は このマニュアルの フォワーダーの使 を参照してください Windows パフォーマンスモニタリング - ローカル Splunk は 単純で Web ベースの パフォーマンスモニターの代替機能として利 できます ディスク 出 メモリー測定基準 ( 空きページ数やコミットチャージなど ) ネットワーク統計情報などを監視する場合に Splunk のデータ収集 グラフ / レポート 成機能を利 して あらゆる 的に柔軟に対応することができます Splunk を使ったパフォーマンス測定基準の収集 法を以下に します 1. Splunk Web の [Windows パフォーマンスデータ ] ページに移動します 2. [ コレクション名 ] に このコレクションに対する 意で分かりやすい名前を します 3. [ 利 可能オブジェクト ] ドロップダウンメニューで モニターするパフォーマンスオブジェクトを選択します [ 利 可能なカウンター ] ウィンドウが表 されます このウィンドウには 選択したオブジェクト固有のカウンタが含まれています 4. [ 利 可能なカウンター ] リストボックスで パフォーマンスデータを収集する各カウンタを 1 回ずつクリックします 的のパフォーマンスカウンタが [ 選択されたカウンター ] ウィンドウに表 されます 5. 次に [ 利 可能なインスタンス ] リストボックスで 先ほど選択したカウンタの Splunk に追跡させる各インスタンスをそれぞれ 1 回ずつクリックします 選択したインスタンスが [ 選択されたインスタンス ] リストボックスに表 されます 他の設定は通常そのままの設定で 分ですが ポーリング間隔を変更したい場合は [ ポーリング間隔 ] フィールドで値を変更することができます これらの設定の詳細は ここを参照してください 6. [ 保存 ] をクリックします 7. [ 成功 ] ページで [ サーチ ] をクリックしてサーチを開始します テータ内の任意の 語を することができます また ソース ソースタイプ またはホストをクリックして Splunk に取り込まれたイベントのデータを参照することができます 85

86 ファイルやディレクトリからのデータの取り込みの詳細は このマニュアルの リアルタイムの Windows パフォーマンスモニタリング を参照してください Windows パフォーマンスモニタリング - リモート Splunk は 単純で Web ベースの パフォーマンスモニターの代替機能として利 できます ディスク 出 メモリー測定基準 ( 空きページ数やコミットチャージなど ) ネットワーク統計情報などを監視する場合に Splunk のデータ収集 グラフ / レポート 成機能を利 して あらゆる 的に柔軟に対応することができます また パフォーマンスモニターと同様に マシンをリモートからモニターすることができます Splunk を使ったパフォーマンス測定基準の収集 法を以下に します 1. Splunk Web の [Windows パフォーマンスデータ ] ページに移動します 2. [ 他のコンピュータから Windows イベントログ ] を探して [ 次へ ] をクリックします 3. [ コレクション名 ] に このコレクションに対する 意で分かりやすい名前を します 4. [ ターゲットホストの選択 ] フィールドに Windows ネットワーク上のマシンのホスト名を します 短いホスト名 サーバーの完全修飾ドメイン名 または IP アドレスを指定することができます 5. [ クエリー â ] をクリックして リモートマシン上の利 可能なパフォーマンスオブジェクトのリストを取得します 6. [ 利 可能オブジェクト ] ドロップダウンメニューで モニターするパフォーマンスオブジェクトを選択します [ 利 可能なカウンター ] ウィンドウが表 されます このウィンドウには 選択したオブジェクト固有のカウンタが含まれています 7. [ 利 可能なカウンター ] リストボックスで パフォーマンスデータを収集する各カウンタを 1 回ずつクリックします 的のパフォーマンスカウンタが [ 選択されたカウンター ] ウィンドウに表 されます 8. 次に [ 利 可能なインスタンス ] リストボックスで 先ほど選択したカウンタの Splunk に追跡させる各インスタンスをそれぞれ 1 回ずつクリックします 選択したインスタンスが [ 選択されたインスタンス ] リストボックスに表 されます 9. 必要に応じて 同じセットのパフォーマンス測定基準を収集する他のサーバーを指定することができます フィールドに各ホスト名を カンマで区切って してください 他の設定は通常そのままの設定で 分ですが ポーリング間隔を変更したい場合は [ ポーリング間隔 ] フィールドで値を変更することができます これらの設定の詳細は ここを参照してください 10. [ 保存 ] をクリックします 11. [ 成功 ] ページで [ サーチ ] をクリックしてサーチを開始します テータ内の任意の 語を することができます また ソース ソースタイプ またはホストをクリックして Splunk に取り込まれたイベントのデータを参照することができます リモートマシンからのパフォーマンスモニターデータの取り込みの詳細は データの取り込み マニュアルの WMI データのモニター を参照してください Windows パフォーマンスモニタリング - 多数のリモート 多数の Windows マシンから Windows パフォーマンス測定基準を収集するには さまざまな 法があります たとえば Windows パフォーマンス - リモート のレシピを使って マシンから Splunk インスタンスに 1 回に 1 台ずつマシンから測定基準を取り込みます また きな環境にも柔軟に対応できる 段として Splunk のユニバーサルフォワーダーを使 する 法が挙げられます フォワーダーは パフォーマンス測定基準を 成しているマシン上に設定します 次に フォワーダーにデータを転送するインデクサーを指 します フォワーダーは各マシン上で 的のパフォーマンスカウンターをモニターし そのデータをインデクサーに転送します インデクサーはサーチが可能になるように データのインデックスを作成します リモート Windows マシンからパフォーマンス測定基準を収集するもっとも効果的な 法が ユニバーサルフォワーダーを使 することです これには 2 つの主要ステップがあります 1. リモートマシン上にフォワーダーを設定し データの転送先となるインデクサーを設定します フォワーダー のレシピを参照してください 2. 的のパフォーマンス測定基準をモニターするように フォワーダーの を設定します フォワーダーの は インデクサーの場合と同じように設定します ただし フォワーダーには Splunk Web がないため の設定には CLI を使 するか または inputs.conf を直接編集する必要があります 86

87 パフォーマンス測定基準を収集するための の設定については このマニュアルの リアルタイムの Windows パフォーマンスモニタリング を参照してください フォワーダーの設定に関するその他の情報は このマニュアルの フォワーダーの使 を参照してください Windows Active Directory Splunk を使って 任意の Active Directory 変更データを収集することができます パスワードの変更 ユーザーまたはマシンアカウントの追加 またはグループポリシーオブジェクトへの権限の委任などを ったユーザーを確認したいと思いませんか?Splunk の Active Directory モニター機能を利 すれば このような情報をすべて 軽に収集 確認することができます さらに 1 台のノードから Active Directory フォレスト全体まで 変更を監視する Active Directory の部分を 由に選択することができます 注意 :Active Directory の任意の部分をモニターするには 最低でも Active Directory スキーマに対する読み取りアクセス許可を持つユーザーとして Splunk を実 する必要があります Active Directory データを収集するには Splunk に Active Directory を指 します 1. Splunk Web の [ ホーム ] ページで [ データの追加 ] をクリックします 2. [Splunk によるデータの取得 法を選択してください ] バナー下で [Active Directory スキーマをモニター ] をクリックします 3. [AD モニター名 ] フィールドに 意の覚えやすい名前を します 4. [ ターゲットドメインコントローラ ] フィールドに ネットワーク上のドメインコントローラのホスト名を します または このフィールドを空欄のままにします この場合 Splunk は利 可能なもっとも近いドメインコントローラを検索して それにバインドします 5. 必要に応じて [ 開始ノード ] フィールドに Splunk がモニターを開始する Active Directory ノードを します または このフィールドを空欄のままにします この場合 Splunk はアクセス可能な Active Directory ツリー内の最上部からモニターを開始します 6. ステップ 5 で指定したノード ( 指定していない場合は Active Directory ツリーの最上部 ) 下のすべての ノードをモニターする場合は [ モニターサブツリー ] ボックスを選択します 指定した開始ノードのみをモニターする場合は ボックスの選択を解除します 7. 必要に応じて このソースの宛先インデックスを指定することができます 8. 最後に [ 保存 ] をクリックします 9. [ 成功 ] ページで [ サーチ ] をクリックしてサーチを開始します テータ内の任意の 語を することができます また ソース ソースタイプ またはホストをクリックして Splunk に取り込まれた Active Directory イベントのデータを参照することができます ファイルとディレクトリからのデータの取り込みの詳細は このマニュアルの Windows イベントログデータのモニター を参照してください UNIX ログ - ローカル UNIX ログからデータを Splunk に取り込むには UNIX ログファイルまたはログファイルのあるディレクトリを指定します 1. Splunk Web の [ ホーム ] ページで [ データの追加 ] をクリックします 2. [To get started...] バナー下で [UNIX/Linux ログとメトリック ] をクリックします 3. [ この Splunk サーバーで UNIX/Linux ログとメトリックを使 する ] 下の [ 次へ ] をクリックします 4. [ ファイルやディレクトリからデータを収集 ] ページで 3 種類の中からいずれかのデータソースをクリックして指定します 5. [ ソース ] フィールドで モニターするファイルまたはディレクトリへのパスを します 般的に他のフィールドは [ その他の設定 ] オプション下のフィールドも含めて 空のままでも構いません これらのフィールドの詳細は ここを参照してください 6. [ 保存 ] をクリックします 7. [ 成功 ] ページで [ サーチ ] をクリックしてサーチを開始します データ内の任意の 語を することができます また ソース ソースタイプ またはホストをクリックして syslog ディレクトリ内の異なるディレクトリからのデータ それらのディレクトリ内の異なるタイプのデータ または当初 syslog データを送信した各ホストを参照することができます ファイルやディレクトリからのデータの取り込みの詳細は このマニュアルの ファイルとディレクトリのモニター を参照してください 87

88 FSChange - ローカル 注意 : この機能は Splunk バージョン 5.0 で 推奨 ( 廃 予定 ) となりました 推奨で廃 予定の機能の 覧は リリースノートの 推奨 ( 廃 予定 ) の機能 を参照してください ローカルファイルシステムの変更をモニターするように設定することができます そのためには inputs.conf を編集して fschange スクリプト を有効にします 設定が完了すると 指定したファイルシステムに対するすべての変更がモニターされます fschange の有効化と設定の詳細は このマニュアルの ファイルシステムへの変更のモニター を参照してください WebSphere - ローカル WebSphere ログからデータを Splunk に取り込むには WebSphere ログファイルまたはログファイルのあるディレクトリを指定します 1. Splunk Web の [ ホーム ] ページで [ データの追加 ] をクリックします 2. [To get started...] バナー下で [WebSphere ログ メトリック その他データ ] をクリックします 3. [ この Splunk サーバーで WebSphere サーバーログを使 する ] 下の [ 次へ ] をクリックします 4. [ ファイルやディレクトリからデータを収集 ] ページで 3 種類の中からいずれかのデータソースをクリックして指定します 5. [ ソース ] フィールドで モニターするファイルまたはディレクトリへのパスを します 般的に他のフィールドは [ その他の設定 ] オプション下のフィールドも含めて 空のままでも構いません これらのフィールドの詳細は ここを参照してください 6. [ 保存 ] をクリックします 7. [ 成功 ] ページで [ サーチ ] をクリックしてサーチを開始します データ内の任意の 語を することができます また ソース ソースタイプ またはホストをクリックして syslog ディレクトリ内の異なるディレクトリからのデータ それらのディレクトリ内の異なるタイプのデータ または当初 syslog データを送信した各ホストを参照することができます ファイルやディレクトリからのデータの取り込みの詳細は このマニュアルの ファイルとディレクトリのモニター を参照してください IIS ログ - ローカル Internet Information Server (IIS) Web サーバーログからデータを Splunk に取り込むには IIS Web サーバーログファイルまたはログファイルのあるディレクトリを指定します 1. Splunk Web の [ ホーム ] ページで [ データの追加 ] をクリックします 2. [To get started...] バナー下で [IIS ログ ] をクリックします 3. [ この Splunk サーバーで IIS ログとメトリックを使 する ] 下の [ 次へ ] をクリックします 4. [ ファイルやディレクトリからデータを収集 ] ページで 3 種類の中からいずれかのデータソースをクリックして指定します 5. [ ソース ] フィールドで モニターするファイルまたはディレクトリへのパスを します 般的に他のフィールドは [ その他の設定 ] オプション下のフィールドも含めて 空のままでも構いません これらのフィールドの詳細は ここを参照してください 6. [ 保存 ] をクリックします 7. [ 成功 ] ページで [ サーチ ] をクリックしてサーチを開始します データ内の任意の 語を することができます また ソース ソースタイプ またはホストをクリックして syslog ディレクトリ内の異なるディレクトリからのデータ それらのディレクトリ内の異なるタイプのデータ または当初 syslog データを送信した各ホストを参照することができます ファイルやディレクトリからのデータの取り込みの詳細は このマニュアルの ファイルとディレクトリのモニター を参照してください Apache ログ - ローカル Apache Web サーバーログからデータを Splunk に取り込むには Apache ログファイルまたはログファイルのあるディレクトリを指定します 1. Splunk Web の [ ホーム ] ページで [ データの追加 ] をクリックします 88

89 2. [To get started...] バナー下で [Apache ログ ] をクリックします 3. [ この Splunk サーバーで Apache ログを使 する ] の下にある [ 次へ ] をクリックします 4. [ ファイルやディレクトリからデータを収集 ] ページで 3 種類の中からいずれかのデータソースをクリックして指定します 5. [ ソース ] フィールドで モニターするファイルまたはディレクトリへのパスを します 般的に他のフィールドは [ その他の設定 ] オプション下のフィールドも含めて 空のままでも構いません これらのフィールドの詳細は ここを参照してください 6. [ 保存 ] をクリックします 7. [ 成功 ] ページで [ サーチ ] をクリックしてサーチを開始します データ内の任意の 語を することができます また ソース ソースタイプ またはホストをクリックして Apache ログディレクトリ内の異なるディレクトリからのデータ それらのディレクトリ内の異なるタイプのデータ または当初 Apache ログデータを送信した各ホストを参照することができます ファイルやディレクトリからのデータの取り込みの詳細は このマニュアルの ファイルとディレクトリのモニター を参照してください JMS/JMX - 独 のスクリプトの作成 独 の Java Message Service (JMS) または Java Management Extension (JMX) スクリプトを作成し 次に Splunk でそのスクリプトを定期的に実 するように設定して Java MBeans VM または他の J2EE ベースの技術サービスのデータを収集することができます まず JMS または JMX スクリプトを作成し テストします 作業が完了したら Java 環境をモニターする Splunk インスタンスの $SPLUNK_HOME/bin/scripts に保管します 次に Splunk にそのスクリプトを設定します 1. Splunk Web の [ ホーム ] ページで [ データの追加 ] をクリックします 2. [To get started...] バナー下で [WebSphere ログ メトリック その他データ ] をクリックします 3. [JMS からのメッセージを収集 ] 下の [ 次へ ] をクリックします 4. [ 新規追加 ] ページで スクリプト名と必要な引数を指定します 5. [ 間隔 ] フィールドに適切な間隔を指定して Splunk にスクリプトの実 頻度を指 します 6. 必要に応じて [ ソース名上書き ] フィールドに 字列を して スクリプトのデフォルトのソース値に優先する設定を うことができます 7. また [ ソースタイプの設定 ] ドロップダウンの [ リストから ] を選択して 次に [ リストからソースタイプを選択 ] ドロップダウンから 的の項 を選択することで このスクリプトが 成するイベントのソースタイプを設定することも可能です または [ ソースタイプの設定 ] から [ 動 ] を選択して 次に表 される [ ソースタイプ ] フィールドに 字列を します 般的に他のフィールドは [ その他の設定 ] オプション下のフィールドも含めて 変更しないままでも構いません これらのフィールドの詳細は ここを参照してください 8. [ 保存 ] をクリックします 9. [ 成功 ] ページで [ サーチ ] をクリックしてサーチを開始します データ内の任意の 語を することができます また ソース ソースタイプ またはホストをクリックして syslog ディレクトリ内の異なるディレクトリからのデータ それらのディレクトリ内の異なるタイプのデータ または当初 syslog データを送信した各ホストを参照することができます スクリプトから Splunk へのデータの取り込みの詳細は このマニュアルの スクリプト を介した API および他のリモートデータインターフェイスからのデータの取得 を参照してください イベント処理の設定 イベント処理の概要 イベントは ログファイル内のアクティビティレコードで Splunk のインデックスに保管されます これが主に Splunk がインデックスを作成するデータです イベントは ログファイルを 成したシステムに関する情報を提供しています イベントデータ と呼ばれる 語は Splunk インデックスの内容を表しています イベントの例を以下に します [01/Jul/2005:12:05: ] "GET /trade/app?action=logout HTTP/1.1"

90 Splunk がイベントのインデックスを作成する場合 以下のような処理が われます 字セットのエンコードを設定する 複数 イベントの 分割を設定する イベントのタイムスタンプを識別する ( イベントにタイムスタンプが存在しない場合はタイムスタンプを割り当てる ) host source および sourcetype などの 役に つ 連の標準フィールドを抽出する イベントをセグメントに分割する イベントに動的にメタデータを割り当てる ( 指定されている場合 ) データを匿名化する ( 指定されている場合 ) Splunk のインデックス作成処理の概要については インデクサーとクラスタの管理 マニュアルの インデックスの概要 を参照してください 字セットのエンコードの設定 Splunk では データソースの 字セットのエンコードを設定することができます Splunk には Splunk デプロイ環境の国際化をサポートするために 内蔵の 字セット規格が 意されています Splunk は 71 種類の 語をサポートしています (UTF-8 エンコードではない 20 の 語を含む ) 部分の *nix システムでは iconv -l コマンドを使って Splunk の有効な 字エンコード規格の 覧を取得することができます デフォルトでは ソースに対して UTF-8 エンコードの適 が試みられます ソースが UTF-8 エンコードを使 していない場合 または ASCII ファイルの場合 props.conf に CHARSET キーを設定して使 する 字セットを指定しない限り Splunk はソースからのデータの UTF-8 エンコードへの変換を試みます サポートする 字セット Splunk は UTF-8 UTF-16LE Latin-1 BIG5 および SHIFT-JIS などの主要なセットを含めて さまざまな 字セットをサポートしています 完全な 覧については このトピックの最後にある サポートするすべての 字セットの 覧 を参照してください ここでは Splunk がサポートしている主要な 字セットと対応する 語の 覧を記載しています 語アラビア語アラビア語アルメニア語ベラルーシ語ブルガリア語チェコ語グルジア語ギリシャ語ヘブライ語 本語 本語韓国語ロシア語ロシア語ロシア語スロバキア語スロベニア語タイ語ウクライナ語ベトナム語 コード CP1256 ISO ARMSCII-8 CP1251 ISO ISO Georgian-Academy ISO ISO EUC-JP SHIFT-JIS EUC-KR CP1251 ISO KOI8-R CP1250 ISO TIS-620 KOI8-U VISCII 字セットの 動指定 に適 する 字セットを 動で指定するには props.conf に CHARSET を設定します 90

91 [spec] CHARSET=<string> たとえば ギリシャ語のデータを 成しているホスト ( この例では GreekSource ) があり そのホストが ISO エンコードを使 している場合は props.conf 内でそのホストに対して CHARSET=ISO を設定します [host::greeksource] CHARSET=ISO 注意 :Splunk は UTF-8 マッピングのある 字エンコードのみをパーシングします 部の EUC-JP 字セットには UTF-8 エンコードへのマッピングがありません 字セットの 動指定 Splunk は その洗練された 字セットエンコード機構を使って 動的に 語と適切な 字セットを認識することができます 特定の に対して 動的に適切な 語と 字セットを認識するには props.conf 内でその に CHARSET=AUTO を設定します たとえば ホスト my-foreign-docs の 字セットエンコードを 動的黄に認識させる場合は props.conf 内でそのホストに CHARSET=AUTO を設定します [host::my-foreign-docs] CHARSET=AUTO Splunk が 字セットを認識しない場合 Splunk が認識できないエンコードを使 する場合は 以下のディレクトリにサンプルファイルを追加して Splunk に 字セットの認識 法を学習させます $SPLUNK_HOME/etc/ngram-models/_<language>-<encoding>.txt 字セット仕様ファイルを追加したら Splunk を再起動する必要があります 再起動後 Splunk は新しい 字セットを使 するソースを認識できるようになり インデックス時に 動的にそれを UTF-8 に変換します たとえば vulcan-iso 字セットを使 する場合 仕様ファイルを以下のパスにコピーします /SPLUNK_HOME/etc/ngram-models/_vulcan-ISO txt サポートするすべての 字セットの 覧 前述の 般的な 字セットは Splunk の豊富な 字セットの中の氷 の に過ぎません 実際に Splunk がサポートしている 字セットやエイリアスのリストは膨 で *nix の iconv ユーティリティがサポートするリストと同じです ここでは すべての 字セットのリストを記載します また 括弧内はエイリアスを表しています utf-8 (aka CESU-8 ANSI_X ANSI_X 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 UCS-2 UCS-2 CSUNICODE UCS-2BE UNICODE-1-1 UNICODEBIG CSUNICODE11 UTF-16) utf-32le (aka UCS-4LE) utf-32be (aka ISO 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 ISO-IR-100 ISO_8859-1:1987 L1 CSISOLATIN1) latin-2 (aka ISO ISO-IR-101 ISO_8859-2:1987 L2 CSISOLATIN2) latin-3 (aka ISO ISO-IR-109 ISO_8859-3:1988 L3 CSISOLATIN3) latin-4 (aka ISO ISO-IR-110 ISO_8859-4:1988 L4 CSISOLATIN4) latin-5 (aka ISO ISO-IR-148 ISO_8859-9:1989 L5 CSISOLATIN5) latin-6 (aka ISO ISO-IR-157 ISO_ :1992 L6 CSISOLATIN6) latin-7 (aka ISO ISO-IR-179 L7) latin-8 (aka ISO ISO-CELTIC ISO-IR-199 ISO_ :1998 L8) latin-9 (aka ISO ISO-IR-203 ISO_ :1998) latin-10 (aka ISO ISO-IR-226 ISO_ :2001 L10 LATIN10) ISO (aka CYRILLIC ISO-IR-144 ISO_8859-5:198,8 CSISOLATINCYRILLIC) ISO (aka ARABIC ASMO-708 ECMA-114 ISO-IR-127 ISO_8859-6:1987 CSISOLATINARABIC MACARABIC) ISO (aka ECMA-118 ELOT_928 GREEK GREEK8 ISO-IR-126 ISO_8859-7:1987 ISO_8859-7:2003 CSISOLATINGREEK) 91

92 ISO (aka HEBREW ISO ISO-IR-138 ISO ISO_8859-8:1988 CSISOLATINHEBREW) ISO 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 です 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) EUC-TW (aka CSEUCTW) GB18030 GBK GB_ (aka ISO-IR-57 ISO646-CN CSISO57GB1988 CN) HZ (aka HZ-GB-2312) GB_ (aka CHINESE, ISO-IR-58 CSISO58GB231280) SHIFT-JIS (aka MS_KANJI SJIS, CSSHIFTJIS) ISO-IR-87 (aka JIS0208 JIS_C JIS_X0208 JIS_X JIS_X X0208 CSISO87JISX0208 ISO-IR-159 JIS_X0212 JIS_X JIS_X X0212 CSISO159JISX ) ISO-IR-14 (aka ISO646-JP JIS_C RO JP CSISO14JISC6220RO) JISX (aka JIS_X0201 X0201 CSHALFWIDTHKATAKANA) ISO-IR-149 (aka KOREAN KSC_5601 KS_C_ KS_C_ CSKSC ) VISCII (aka VISCII1.1-1 CSVISCII) ISO-IR-166 (aka TIS-620 TIS620-0 TIS TIS TIS ) 注意 : Splunk は CHARSET の照合時に句読点と 字 字の区別を無視します たとえば utf-8 UTF-8 および utf8 はすべて同 とみなされます イベントの 分割の設定 イベントの中には複数の から構成されているものもあります デフォルトで Splunk は 部分の複数 イベントを正確に処理できます 正しく処理されない複数 イベントがある場合は Splunk の 分割動作を変更するように設定する必要があります Splunk がイベント境界を判別する仕組み Splunk は 2 つのステップで イベント境界を判別しています 92

93 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 が 動的にイベント境界を認識することができます イベント境界の認識が正しく われない場合には 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 を使 します これらの属性については後述します 般的な 分割属性 分割に影響する props.conf 属性を以下に します TRUNCATE = <non-negative integer> デフォルトの最 ( バイト ) を変更します この属性の単位はバイトですが 複数バイト 字のために 字の途中で終了する場合 の さが丸められることに注意してください 切り詰めを わない場合は 0 を設定します ( ただし 常に い はしばしば無効なデータの兆候でもあります ) デフォルトは バイトです LINE_BREAKER = <regular expression> の結合処理 ( 後述の SHOULD_LINEMERGE 属性が指定されている場合 ) を う前の raw テキストを初期イベントに分割する 法を決定する正規表現を指定します デフォルトは ([\r\n]+) です この場合 任意の数の復帰改 (\r) または改 (\n) 字で区切られている各 が それぞれ 1 つのイベントに分割されます 正規表現には 捕捉グループ ( 致項 の識別されたサブコンポーネントを定義する括弧のペア ) を含める必要があります 正規表現に 致する場合 Splunk は最初の捕捉グループの開始点を前のイベントの終了点とみなし 最初の捕捉グループの終了点を次のイベントの開始点とみなします 最初の捕捉グループの内容は破棄され どのイベントにも含められることはありません これは Splunk にそのテキストが 間に存在していることを知らせるものです 注意 :LINE_BREAKER を使って複数 イベントを分割した場合 (SHOULD_LINEMERGE を使って個別の を複数 イベントに再構築しない ) 処理速度が 幅に向上することを実感できると思います データの 部分が複数 イベントである場合などに この 法の使 を検討してください LINE_BREAKER と分岐式の使 法の詳細は props.conf 仕様ファイルを参照してください LINE_BREAKER_LOOKBEHIND = <integer> 前の raw データチャンクからの残りデータがある場合 LINE_BREAKER_LOOKBEHIND には Splunk が LINE_BREAKER 正規表現を適 する raw データチャンクの終了 ( 次のチャンクを連結した状態で ) までの 字数を指定します 特に巨 なイベントや葉複数 イベントを処理する場合に この値をデフォルト値よりも増やした が良い場合があります デフォルトは 100 です SHOULD_LINEMERGE = [true false] 93

94 真 (True) を設定すると Splunk は複数の を単 のイベントにまとめ 次のセクションで説明している属性に基づいて設定を います デフォルトは真 (True) です SHOULD_LINEMERGE に真 (True) を設定した場合にのみ利 できる属性 SHOULD_LINEMERGE=true ( デフォルト ) の場合 これらの属性を使って 分割動作を定義します BREAK_ONLY_BEFORE_DATE = [true false] 真 (True) を設定すると 付のある改 に遭遇した場合にのみ新しいイベントが作成されます デフォルトは真 (True) です 注意 :DATETIME_CONFIG に CURRENT または NONE を設定した場合 Splunk はタイムスタンプを識別しないため この属性は意味を持たなくなります BREAK_ONLY_BEFORE = <regular expression> 真 (True) を設定すると 正規表現に 致する改 に遭遇した場合にのみ新しいイベントが作成されます デフォルトは空です MUST_BREAK_AFTER = <regular expression> 設定した場合に 現在の と正規表現が 致すると 次の の新しいイベントが常に作成されます 他のルールと 致した場合 現在の の前で分割することもあります デフォルトは空です MUST_NOT_BREAK_AFTER = <regular expression> 設定した場合に 現在の が正規表現と 致すると 以降の は MUST_BREAK_AFTER 式に 致するまでの間分割されません デフォルトは空です MUST_NOT_BREAK_BEFORE = <regular expression> 設定した場合に 現在の が正規表現に 致すると 現在の の前の最後のイベントは分割されません デフォルトは空です MAX_EVENTS = <integer> 例 任意のイベントに追加する 数の最 値を指定します 指定した数の が読み込まれると 分割が われます デフォルトは 256 です イベント分割の指定 [my_custom_sourcetype] BREAK_ONLY_BEFORE = ^\d+\s*$ 数字のみで構成されている を新しいイベントの開始として イベントを分割する例を以下に します ソースタイプが my_custom_sourcetype の任意のデータに対して処理を います 複数 を単 のイベントに結合 以下のログイベントには 同じリクエストの 部となる複数の が含まれています 各リクエスト間の違いはパス (Path) です この例では これらのすべての を単 のイベントエントリとして表 する必要があることを前提にしています {{" , 02:57:11.58", 122, 11, "Path=/LoginUser Query=CrmId=ClientABC&ContentItemId=TotalAccess&SessionId=3A1785URH117BEA&Ticket=646A1DA4STF896EE&SessionTime=25368&R Method=GET, IP= , Content=", ""}} {{" , 02:57:11.60", 122, 15, "UserData:<User CrmId="clientabc" UserId="p "><EntitlementList></EntitlementList></User>", ""}} {{" , 02:57:11.60", 122, 15, "New Cookie: SessionId=3A1785URH117BEA&Ticket=646A1DA4STF896EE&CrmId=clientabc&UserId=p &AccountId=&AgentHost=man&AgentId=m MANUser: Version=1&Name=&Debit=&Credit=&AccessTime=&BillDay=&Status=&Language=&Country=& =& Notify=&Pin=&PinPayment=&P ""}} この複数 イベントのインデックスを正しく作成するには 設定に Path を使 します $SPLUNK_HOME/etc/system/local/props.conf に以下の項 を追加します 94

95 [source::source-to-break] SHOULD_LINEMERGE = True BREAK_ONLY_BEFORE = Path= このコードは イベントの各 を結合して 語 Path= の前でのみ分割することを表しています 複数 イベントの 分割とセグメント分割 極端に きなイベントには 分割とセグメント分割制限が適 されます 10,000 バイトを超える :Splunk は 10,000 バイトを超える のインデックスを作成する場合 それぞれが 10,000 バイトの複数 に分割します 切り詰められた各セクションの最後には meta::truncated フィールドが追加されます ただし Splunk は引き続きこれらの を単 のイベントにグループ化します 100,000 バイトを超えるイベントのセグメント分割 : サーチ結果には イベントの最初の 100,000 バイトしか表 されません ただし 常に い の最初の 100,000 バイト以降のセグメントを サーチすることは可能です 1,000 セグメントを超えるイベントのセグメント分割 : サーチ結果では イベントの最初の 1,000 件のセグメントが セグメントとして空 字で区切られて表 されます マウスカーソルをセグメントの上に移動すると 強調表 されます イベントの残りの部分は raw テキストとして表 され 対話形式の書式は設定されません Answers 何か質問がありますか? Splunk Answers では Splunk コミュニティに寄せられた 分割に関する質問と回答をご覧いただけます イベントのタイムスタンプの設定 次のサンプルイベントを調査します [01/Jul/2005:12:05: ] "GET /trade/app?action=logout HTTP/1.1" Notice the time information in the event: [01/Jul/2005:12:05: ]. This is what is known as a timestamp.splunk はタイムスタンプを使って 時間別にイベントを相関させ Splunk Web でのヒストグラムの作成やサーチの時間範囲の設定を います 部分のイベントにはタイムスタンプが含まれています イベントにタイムスタンプ情報が含まれていない場合は インデックス時のタイムスタンプ値がイベントに割り当てられます たいていの場合 タイムスタンプの処理は正しく われますが 状況によってはタイムスタンプの処理 法を設定しなければならないこともあります たとえば 部のソースを利 している または分散デプロイ環境を運 している場合 タイムスタンプの認識とフォーマットを再設定しなければならないことがあります タイムスタンプの詳細は このマニュアルの タイムスタンプの設定 を参照してください インデックス作成フィールド抽出の設定 Splunk がインデックス時に抽出できるフィールドは 3 種類あります デフォルトフィールドカスタムフィールドファイルヘッダーフィールド Splunk は各イベントに対して 常に 連のデフォルトフィールドを抽出しています カスタムフィールド またデータによってはファイルヘッダーフィールドを抽出するように設定することも可能です インデックス作成フィールドの抽出の詳細は このマニュアルの インデックス作成フィールドの抽出 を参照してください データの匿名化 ログイベントのインデックス作成時に 個 の機密情報を隠したい場合もあります たとえば クレジットカード番号や社会保障番号などは Splunk インデックスに登場させたくないデータです ここでは 機密情報フィールドの 部を隠すことで プライバシーを保護しながら イベントの追跡が可能な状態にデータを維持する 法について説明していきます Splunk では 2 種類の 法でデータを匿名化することができます 正規表現変換を使 するストリームエディタ処理 (sed) スクリプトを使 する 正規表現変換を使 する transforms.conf で正規表現を利 して データをマスクすることができます この例では アプリケーションサーバーログの SessionId および Ticket number フィールドの 最後の 4 字を除いて残りの 字をマスクします 95

96 的の出 は以下のようになります SessionId=###########7BEA&Ticket=############96EE のサンプルは以下のようになります " , 02:57:11.58", 122, 11, "Path=/LoginUser Query=CrmId=ClientABC& ContentItemId=TotalAccess&SessionId=3A1785URH117BEA&Ticket=646A1DA4STF896EE& SessionTime=25368&ReturnUrl= Method=GET,IP= , Content=", "" " , 02:57:11.60", 122, 15, "UserData:<User CrmId="clientabc" UserId="p "><EntitlementList></EntitlementList></User>", "" " , 02:57:11.60", 122, 15, "New Cookie: SessionId=3A1785URH117BEA& Ticket=646A1DA4STF896EE&CrmId=clientabcUserId=p &AccountId=&AgentHost=man& AgentId=man, MANUser: Version=1&Name=&Debit=&Credit=&AccessTime=&BillDay=&Status= &Language=&Country=& =& Notify=&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> はイベントのホストを表します source::<source> ここで <source> はイベントのソースを表します この例で session-anonymizer および ticket-anonymizer は任意の TRANSFORMS クラス名で そのアクションは対応する transforms.conf ファイル内のスタンザに定義されています transforms.conf 内に作成したクラス名を使 してください transforms.conf の設定 $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) を設定してください FORMAT はマスク値を します $1 は正規表現までのすべてのテキスト $2 は正規表現後のすべてのテキストです DEST_KEY = _raw は FORMAT からの値をログ内の raw 値に書き込んでイベントを変更することを しています ストリームエディタ処理 (sed) スクリプトを使 する sed スクリプトを使ってイベント内の 字列を置換 / 代替することで データを匿名化することもできます UNIX ユーザーの ならば おそらく UNIX ユーティリティ sed をご存じかと思います このユーティリティは ファイルを読み込んで 指定されている 連のコマンドに従って を変更します Splunk では props.conf 内で sed 類似の構 を使って データを匿名化することができます props.conf への sed スクリプトの定義 96

97 $SPLUNK_HOME/etc/system/local 内に props.conf のコピーを作成または編集します sed script を指定するには SEDCMD を使 するスタンザを props.conf に作成します [<spec>] SEDCMD-<class> = <sed script> 以下の事項に注意してください <spec> には 以下のいずれかを使 する必要があります <sourcetype> イベントのソースタイプ host::<host> ここで <host> はイベントのホストを表します source::<source> ここで <source> はイベントのソースを表します sed script は インデックス時に _raw にのみ適 されます 現在 Splunk は 以下の sed コマンドのサブセットをサポートしています 置換 (s) 字代替 (y). 注意 :props.conf を変更したら 変更内容を反映するために Splunk を再起動してください 正規表現照合による 字列の置換 sed 置換の構 を以下に します SEDCMD-<class> = s/<regex>/<replacement>/flags 以下の事項に注意してください 例 regex は PERL 正規表現です replacement は 正規表現に 致した項 と置換する 字列です \n は逆参照を しており n は単 の数字です flags に g を指定すると すべての 致項 が置換されます また 数字を指定すると 指定された 致項 が置換されます 社会保障番号とクレジットカード番号を含むデータのインデックスを作成する場合を考えてみましょう インデックス時に イベント内でこれらの値は最後の 4 桁のみを表 し 残りはマスクします props.conf スタンザは以下のようになります [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 により 各 a が A に b が B に c が C に代替されています タイムスタンプの設定 タイムスタンプ割り当ての仕組み 97

98 Splunk はタイムスタンプに関するさまざまな処理を います Splunk はタイムスタンプを使って 時間別にイベントを相関させ Splunk Web でのタイムラインヒストグラムの作成やサーチの時間範囲の設定を います イベントへのタイムスタンプの割り当ては インデックス時に われます 通常タイムスタンプ値は raw イベントデータ内の情報を使って 動的に割り当てられます イベントに明 的なタイムスタンプがない場合は 他の 段でのタイムスタンプ値の割り当てが試みられます 部のデータでは タイムスタンプの認識 法を設定しなければならないこともあります Splunk はタイムスタンプ値を _time フィールドに保管します (UTC 形式 ) タイムスタンプ処理は イベント処理時の主要ステップの 1 つです イベント処理の詳細は このマニュアルの イベント処理の設定 を参照してください Splunk によるタイムスタンプの割り当て 法 Splunk は 以下の優先ルールを使って イベントにタイムスタンプを割り当てます 1. TIME_FORMAT が明 的に指定されている場合は それを使ってイベントの 時を探します TIME_FORMAT は props.conf に設定します 2. データに TIME_FORMAT が設定されていない場合は Splunk がイベントのタイムスタンプを判別しようと試みます イベントのソースタイプ (TIME_FORMAT 情報が含まれている ) を使ってタイムスタンプを探します 3. イベントに時間または 付がない場合は 同じソースからの直前のイベントを使 します 4. ソース内のイベントに 付がない場合は ソース名またはファイル名から 付を探します ( この場合 イベントには 付がなくとも 時刻が存在している必要があります ) 5. ファイルソースの場合 ファイル名から 付を特定できなかった場合 そのファイルの変更時刻を使 します 6. 最後の 段として 各イベントのインデックス作成時に 現在のシステム時刻をタイムスタンプとして設定します 注意 :Splunk はソースから 付のみを抽出できます 時間は抽出できません ソースから時刻を抽出する必要がある場合は transform を使 します タイムスタンプの設定 部分のイベントでは 特別なタイムスタンプ処理を う必要はありません Splunk が 動的にタイムスタンプを認識して抽出します ただし 部のソースや分散デプロイ環境では タイムスタンプが適切にフォーマットされるように タイムスタンプの抽出 法を設定しなければならないことがあります タイムスタンプ抽出を設定するには 2 種類の 法があります データのプレビュー機能を使って サンプルデータのタイムスタンプを対話形式で調整する 満 できる結果が得られたら 変更内容を新しいソースタイプに保存して そのソースタイプをデータ に適 します データのプレビュー を参照してください props.conf を直接編集する 詳細は タイムスタンプ認識の設定 を参照してください 以下の 的で タイムスタンプ抽出プロセッサを設定することも可能です タイムゾーンオフセットを適 する 複数のタイムスタンプを使ってイベントから正確なタイムスタンプを取得する インデックス作成パフォーマンスを向上する 新しい からデータを追加する場合の注意事項 新しい からのデータのインデックスを作成した後に タイムスタンプの抽出処理を調整する必要があることに気が付いた場合は 設定を変更した後に データのインデックスを再作成する必要があります そのため データのプレビュー で説明しているように データのプレビューを うことをお勧めします または 新しいデータ をテスト Splunk インスタンスで ( または実働環境 Splunk インスタンスの別のインデックスを使 して ) テストしてから 実働環境の Splunk インスタンスにデータを追加します そうすることで 何か調整が必要な場合でも データを 軽に削除してから インデックスを再作成して 的の結果が得られるまで調整を うことができます タイムスタンプ認識の設定 部分のイベントでは 特別なタイムスタンプ処理を う必要はありません Splunk が 動的にタイムスタンプを認識して抽出します ただし 部のソースや分散デプロイ環境では タイムスタンプが適切にフォーマットされるように タイムスタンプの抽出 法を設定しなければならないことがあります タイムスタンプ抽出を設定するには 2 種類の 法があります データのプレビュー機能を使って サンプルデータのタイムスタンプを対話形式で調整する 満 できる結果が得 98

99 られたら 変更内容を新しいソースタイプに保存して そのソースタイプをデータ に適 します データのプレビュー を参照してください props.conf を直接編集する タイムスタンプ抽出のための props.conf の編集 法については このまま読み進めてください Splunk のタイムスタンププロセッサ Splunk のタイムスタンププロセッサは デフォルトでは $SPLUNK_HOME/etc/datetime.xml に存在しています 例外的な独 のタイムスタンプを処理するのではない限り 通常このファイルを編集する必要はありません 何らかの 法でタイムスタンプ認識 法を設定する必要がある場合は 通常は後述のように props.conf のタイムスタンプ属性設定を変更することで問題を解決できます props.conf の設定では対処できない独 のタイムスタンプがある場合は DATETIME_CONFIG 属性を使って 独 のタイムスタンププロセッサで代 することができます ( 次のセクションを参照 ) この属性には Splunk がタイムスタンプ処理に使 するファイルを指定します props.conf でのタイムスタンププロパティの編集 Splunk によるタイムスタンプの認識 法を設定するには props.conf を編集します タイムスタンプ関連の さまざまな属性が存在しています 特に TIME_FORMAT 属性を使ってタイムスタンプの strptime() フォーマットを指定することで Splunk によるタイムスタンプの認識 法を決定することができます また その他のタイムスタンプ関連属性を設定することもできます たとえば イベント内のタイムスタンプの位置 使 するタイムゾーン さまざまな単位のタイムスタンプの処理 法などを指定することができます $SPLUNK_HOME/etc/system/local/ 内 または $SPLUNK_HOME/etc/apps/ の独 のカスタムアプリケーションディレクトリ内にある props.conf ファイルを編集します 設定ファイルの 般情報については 管理マニュアル の 設定ファイルについて を参照してください Splunk のタイムスタンプ認識を設定するには 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> 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 relative to $SPLUNK_HOME> Splunk のタイムスタンププロセッサの設定に使 するファイルを指定します デフォルトでは $SPLUNK_HOME/etc/datetime.xml がタイムスタンププロセッサとして使 されます 標準環境下では 独 のタイムスタンププロセッサファイルを作成したり Splunk デフォルトの datetime.xml ファイルを修正したりする必要はありません 般的には このトピックに記述されている他の props.conf 属性を使って ご 分のニーズを満たすように Splunk のタイムスタンプ認識機能を調整することができます ただし データに独 のタイムスタンプ形式が存在している場合は このファイルに代わる独 のファイルを作成して それで機能を代 しなければならないこともあります タイムスタンププロセッサの実 を防 する場合は DATETIME_CONFIG = NONE を設定します タイムスタンプ処理をオフにすると イベント内のタイムスタンプテキストが調査されることはありません 代わりにイベントの 受信時刻 が使 されます ( からイベントを受信した時刻 ) ファイルベースの の場合 イベントのタイムスタンプは ファイルの変更時刻から取得されます 99

100 DATETIME_CONFIG = CURRENT を設定すると インデックス作成時に現在のシステム時刻が各イベントに割り当てられます 注意 :CURRENT と NONE の両 が 明 的にタイムスタンプの識別を無効にします そのため デフォルトのイベント境界検出 (BREAK_ONLY_BEFORE_DATE = true) は 的通りには機能しません これらの設定を使 する場合は SHOULD_LINEMERGE や BREAK_ONLY_*, MUST_BREAK_* 設定を使ってイベントの結合を管理します TIME_PREFIX = <regular expression> 設定した場合 Splunk はタイムスタンプの抽出を試みる前に この正規表現と 致するイベントテキスト内の項 を探します タイムスタンプアルゴリズムは 最初の正規表現 致項 の最後に続くイベントテキスト内のみで タイムスタンプを探します イベントのタイムスタンプの直前を正確に指 する正規表現を使 する必要があります たとえば フレーズ abc123 に続いてタイムスタンプが登場する場合 TIME_PREFIX には abc123 を設定する必要があります イベントテキスト内に TIME_PREFIX が つからなかった場合 タイムスタンプの抽出は われません デフォルトは空 字列です MAX_TIMESTAMP_LOOKAHEAD = <integer> Splunk がイベント内でタイムスタンプをどこまで探すのかを 字数で指定します これらの制約は TIME_PREFIX が す位置から適 されます たとえば TIME_PREFIX の位置がイベント内の 11 字 で MAX_TIMESTAMP_LOOKAHEAD に 10 が設定されている場合 タイムスタンプ抽出は 字に制限されます 0 または -1 を設定した場合 タイムスタンプ認識の さ制約は事実上無効になります このことは の さ ( またはイベント分割 に LINE_BREAKER が再定義された時のイベントサイズ ) に応じて負の影響が出る可能性があります デフォルトは 150 字です TIME_FORMAT = <strptime-style format> タイムスタンプを抽出するための strptime() フォーマット 字列を指定します 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 は時間コンポーネントを無視します フォーマットは例外として取り扱われ 精度は 付のみとみなされます デフォルトは空です TZ = <time zone identifier> 特定のイベントのタイムゾーンを判断するための Splunk のロジックは以下のようになっています イベントの raw テキストにタイムゾーンがある場合は (UTC や -08:00 など ) それが使 されます そうでない場合は TZ に有効なタイムゾーン 字列が設定されていれば それが使 されます zoneinfo TZ データベースからの値を使って タイムゾーン設定を指定します それ以外の場合は splunkd が動作しているシステムのタイムゾーンを使 します 詳細と例については このマニュアルの タイムスタンプのタイムゾーンの指定 を参照してください デフォルトは空です TZ_ALIAS = <key=value>[,<key=value>]... イベントから抽出されたタイムゾーン 字列の解釈 法に対して 管理者レベルの制御を提供します たとえば EST は 国の東部標準時 (Eastern Standard Time) または豪州の東部標準時 (Eastern Standard Time) と解釈することができます その他にも 複数のタイムゾーンに解釈できる 3 字のタイムゾーン省略形が存在しています これらの値に対する従来の Splunk デフォルトマッピングが期待通りに機能する場合 TZ_ALIAS の使 に関する要件はありません たとえば デフォルトで EST は 国東部標準時にマップされます TZ の値には効果がありません TIME_FORMAT に設定されている またはパターンベースの推測フォールバックからの イベントテキスト内のタイムゾーン 字列にのみ影響します この設定は key=value ペアをカンマで区切ったリストです このキーは イベントのタイムゾーン指定 のテキストに対して照合され 値はタイムスタンプを UTC/GMT にマッピングする際に使 するタイムゾーン指定 になります 値は 必要なオフセットを表す他の TZ 指定 です 例 :TZ_ALIAS = EST=GMT+10:00 ( その他の例については 設定ファイルリファレンス の props.conf サンプルファイルを参照してください ) デフォルトでは設定されていません MAX_DAYS_AGO = <integer> 抽出した 付が有効になる 現在の 付から過去への最 数を指定します たとえば MAX_DAYS_AGO = 10 の場合 現在の 付から 10 を超えて古い 付は無視されます 100

101 デフォルトは 2000 で 最 は になります 注意 :2000 より古いデータがある場合は この値を増やしてください MAX_DAYS_HENCE = <integer> 抽出した 付が有効になる 現在の 付から将来への最 数を指定します たとえば MAX_DAYS_HENCE = 3 の場合 3 を超えて将来の 付は無視されます 重要 : ウィンドウを限定すると 誤判定の可能性が低くなります 変更する際には細 の注意を払ってください サーバーに誤った 付セットがある場合 またはサーバーが 1 先のタイムゾーンに存在している場合は 3 以上の値を設定してください デフォルトは 2 です この場合 1 先までのタイムスタンプ抽出を えます 最 値は です MAX_DIFF_SECS_AGO = <integer> イベントのタイムスタンプが 1 つ前のタイムスタンプよりも <integer> 秒を超えて前の場合 ソースからのタイムスタンプの 半と時間フォーマットが同じ場合にのみそれを受け付けます 重要 : タイムスタンプの順序が乱雑な場合は この値を増やすことを検討してください デフォルトは 3600 (1 時間 ) です 最 値は です MAX_DIFF_SECS_HENCE = <integer> イベントのタイムスタンプが 1 つ前のタイムスタンプよりも <integer> 秒を超えて後の場合 ソースからのタイムスタンプの 半と時間フォーマットが同じ場合にのみそれを受け付けます 重要 : タイムスタンプの順序が乱雑な場合 または週に 1 回未満しか書き込まれないログがある場合は この値を増やすことを検討してください デフォルトは (1 週間 ) です 最 値は です 拡張 strptime() サポート タイムスタンプのパーシングを設定するには props.conf で TIME_FORMAT 属性を使 します この属性は strptime() フォーマット 字列を取ります この 字列は タイムスタンプの抽出に いられます Splunk は拡張版の UNIX strptime() を実装しており マイクロ秒 ミリ秒 任意の時間幅フォーマット および互換性を保つための他の時間フォーマットの利 を可能にする 追加の時間フォーマットがサポートされています 追加のフォーマットを以下の表に します %N %Q,%q %I GNU 付 - 時刻ナノ秒 width: %3N = ミリ秒, %6N = マイクロ秒, %9N = ナノ秒を指定して 1 秒未満の任意のパーシングを指定します ミリ秒 Apache Tomcat の場合はマイクロ秒 width を指定した場合 %Q および %q で 任意の時間分解能をフォーマットできます 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 との同等 ( 注意 : 存在しない場合もあります ) 注意 : リテラルドットと %Q %q %N などの 1 秒未満の指定 で終わる strptime 式は 終点のドットと変換指定 をオプションとして取り扱います テキストに.subseconds 部が存在しない場合でも 抽出は われます strptime() フォーマット式の例 strptime() 式で処理するサンプルの 付形式を以下に します %Y-%m-%d %y-%m-%d 1998 years, 312 days %Y years, %j days Jan 24, 2003 %b %d, %Y January 24, 2003 %B %d, %Y q 25 Feb '03 = q %d %b '%y = %Y-%m-%d 注意 : 現在 Splunk は タイムスタンプ内の英語以外の 名を認識しません ログファイルに英語以外の 名を書き込む App がある場合 可能な場合は数値の を使 するように App を再設定してください 101

102 例データには 以下のような簡単に認識できるタイムスタンプが含まれていることがあります...FOR: 04/24/07 PAGE このようなタイムスタンプを抽出するには props.conf に以下のスタンザを追加します [host::foo] TIME_PREFIX = FOR: TIME_FORMAT = %m/%d/%y データには Splunk がタイムスタンプとしてパーシングしてしまうような情報が含まれていることもあります 以下に例を します /12/31 16:00:00 ed May 23 15:40: Splunk は 付を Dec 31, 1989 (1989 年 ) として抽出しますが この情報は役に ちません この場合 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 のスタンザは できる限りきめ細かく設定してください 複数のタイムスタンプを持つイベントから正しいタイムスタンプを抽出する 法の詳細は 複数のタイムスタンプを持つイベントのタイムスタンプ割り当ての設定 を参照してください 特定のニーズに合わせたタイムスタンプの設定 このトピックで説明している属性を使って 以下のような特定の 的に合わせてタイムスタンプ抽出プロセッサを設定することができます タイムゾーンオフセットを適 する 複数のタイムスタンプを使ってイベントから正確なタイムスタンプを取得する インデックス作成パフォーマンスを向上する サーチ結果へのタイムスタンプの表 法の設定 ブラウザのロケール設定を使って ブラウザによるサーチ結果内のタイムスタンプの フォーマット 法を設定することができます ブラウザのロケールの設定については ユーザーの 語とロケール を参照してください raw データ内のタイムスタンプの表 法の再設定 Splunk はブラウザのロケールを使ってサーチ結果内のタイムスタンプの表 法を設定していますが raw データのフォーマットを引き続き元の形式で保持されています raw データとサーチ結果の両 のデータフォーマットを標準化するために これを変更することができます そのためには props.conf および transforms.conf を使 します 以下に例を します raw イベント内のタイムスタンプデータが 以下のようになっていると仮定してみましょう 06/07/ :26:11 PM このデータを 以下のようにしたいと考えています ( サーチ結果の表 法と合わせるために ) 07/06/ :26:11 PM この例では props.conf および transforms.conf を使った raw イベント内のタイムスタンプの変換 法の概要を表しています transforms.conf に以下のスタンザを追加します [resortdate] REGEX = ^(\d{2})\/(\d{2})\/(\d{4})\s([^/]+) FORMAT = $2/$1/$3 $4 DEST_KEY = _raw props.conf に以下のスタンザを追加します ここで <spec> がデータを修飾します 102

103 [<spec>] TRANSFORMS-sortdate = resortdate Answers 何か質問がありますか? Splunk Answers では Splunk コミュニティに寄せられた タイムスタンプの認識と設定に関する質問と回答をご覧いただけます 複数のタイムスタンプを持つイベントのタイムスタンプ割り当ての設定 イベントに複数のタイムスタンプが含まれている場合 Splunk が使 するタイムスタンプを指定することができます これは 特に syslog のホストチェーンデータが含まれているイベントのインデックスを作成する場合に役 ちます props.conf を編集して 位置的タイムスタンプ抽出を設定します タイムスタンプに関する props.conf の編集の概要は タイムスタンプ認識の設定 を参照してください 位置的タイムスタンプ抽出の設定 イベント内の任意の場所にあるタイムスタンプを認識するように Splunk を設定するには props.conf のスタンザに TIME_PREFIX および MAX_TIMESTAMP_LOOKAHEAD 属性を追加します TIME_PREFIX に正規表現を設定することで タイムスタンプ検索の開始場所を す 字パターンを Splunk に指 することができます MAX_TIMESTAMP_LOOKAHEAD の値を設定して Splunk にどの程度先までイベントのタイムスタンプを探すのか (TIME_PREFIX の ) を指 する値を設定します 先読みを制限することで 正確性とパフォーマンスの両 を改善することができます TIME_PREFIX を設定した場合 タイムスタンプの抽出を試みる前に その正規表現に 致するイベントのテキストが検索されます Splunk のタイムスタンプアルゴリズムは 最初に正規表現に 致した項 に続くテキスト内のタイムスタンプのみに注 します そのため TIME_PREFIX に abc123 を設定すると 最初に登場した abc123 に続くテキストのみが タイムスタンプ抽出に利 されます TIME_PREFIX は MAX_TIMESTAMP_LOOKAHEAD の開始点も設定します 先読みは TIME_PREFIX 正規表現内の 致するテキスト項 の後から開始されます たとえば TIME_PREFIX がイベントの最初の 11 字からのテキストと 致して 抽出するタイムスタンプが常に次の 30 字内に存在する場合 MAX_TIMESTAMP_LOOKAHEAD=30 を設定することができます タイムスタンプ抽出は 12 字 から始まり 41 字 で終了するテキストに限定されます 例 以下のようなイベントがある場合を考えてみましょう 1989/12/31 16:00:00 Wed May 23 15:40: ERROR UserManager - Exception thrown Ignoring unsupported search for eventtype: /doc sourcetype="access_combined" NOT eventtypetag=bot タイムスタンプを時間情報 May 23 15:40: の 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 は以下の順序でこれらのルールを使ってタイムゾーンを適 します 103

104 1. Splunk は raw イベントデータに指定されている任意のタイムゾーンを使 します ( 例 :PST, -0800) 2. イベントがスタンザに指定されているホスト ソース またはソースタイプに 致する場合 props.conf に設定されている TZ 属性の値を使 します 3. イベントのインデックスを作成する Splunk サーバーのタイムゾーンを使 します 注意 :Splunk が動作しているシステムのタイムゾーン設定を変更した場合 変更内容を反映するには Splunk を再起動する必要があります 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 で設定されているのではなく オペレーティングシステムのタイムゾーンが使われていることに注意してください インデクサーのホストシステムで時刻が正しく設定されている限り イベントのタイムゾーンのオフセットは正しく算出されます 例 このインデクサーには New York City ( タイムゾーンは 国東部標準時 (US/Eastern)) および Mountain View, California ( 太平洋標準時 (US/Pacific)) からのイベントが到着します これらの 2 種類のイベントセットのタイムスタンプを正しく処理するには インデクサーの props.conf に 国東部標準時と 国太平洋標準時の両 のタイムゾーンを指定する必要があります 最初の例では 名前が正規表現 nyc.* と 致するホストから到着する 任意のイベントのタイムゾーンを 国東部標準時に設定します [host::nyc*] TZ = US/Eastern 2 番 の例では バス /mnt/ca/... 内のソースから到着する 任意のイベントのタイムゾーンを 国太平洋標準時に設定します [source::/mnt/ca/...] TZ = US/Pacific zoneinfo (TZ) データベース zoneinfo データベースは 公的に管理されているタイムゾーン値のデータベースです UNIX 版の Splunk は ご利 の UNIX ディストリビューションに含まれている TZ データベースを使 しています Most UNIX distributions store the database in the directory: /usr/share/zoneinfo. Solaris versions of Splunk store TZ information in this directory: /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 もマップします ご利 の地域で いられている組み合わせに応じて 適切なマップを ってください ソフトウェアをテストして 成されるタイムゾーン 字列を確認してください 104

105 複数のマッピングを指定することができます TZ_ALIAS の構 を以下に します TZ_ALIAS = <key=value>[,<key=value>]... 詳細と例については 設定ファイルリファレンス の props.conf ファイルの仕様と例を参照してください ユーザーのサーチ結果のタイムゾーン設定 Splunk ビルトイン認証を使ってユーザーを追加 編集する場合 ユーザーのタイムゾーンを設定することができます そのユーザーのサーチ結果は 設定したタイムゾーンで表 されます ただし この設定によりインデックス時に決定された 実際のイベントデータのタイムゾーンが変更されることはありません この値の設定については Splunk のセキュリティ マニュアルの Splunk Web を使ったユーザーの設定 を参照してください インデックス作成パフォーマンス向上のためのタイムスタンプ認識の調整 インデックス作成を 速化するために Splunk のタイムスタンププロセッサがイベントを調査する度合いを調整したり タイムスタンププロセッサをオフにすることができます そのためには props.conf を編集します props.conf のタイムスタンプ編集については タイムスタンプ認識の設定 を参照してください タイムスタンプ先読みの調整 タイムスタンプ先読みは イベントを調査する度合い ( 何 字先まで ) を決定します この設定には MAX_TIMESTAMP_LOOKAHEAD 属性を使 します タイムスタンププロセッサがイベントを調査するデフォルトの 字数は 150 です MAX_TIMESTAMP_LOOKAHEAD の値を さくして インデックス作成を 速化することができます 特にタイムスタンプが常にイベントの最初の部分に登場する場合は この値を調整してください 例 : この例では ソース foo から到着するイベントの最初の 20 字のみ タイムスタンプを探します [source::foo] MAX_TIMESTAMP_LOOKAHEAD = タイムスタンププロセッサを無効にする インデックス作成パフォーマンスを改善するために タイムスタンププロセッサを無効にすることができます 特定のホスト ソース またはソースタイプに 致するイベントのタイムスタンプ処理をオフにするには DATETIME_CONFIG 属性に NONE を設定します DATETIME_CONFIG=NONE の場合 Splunk はイベントのテキストからタイムスタンプを探しません 代わりに イベントの受信時刻 つまり からイベントを受け取った時の時刻が使 されます ファイルベースの ( モニターなど ) の場合 タイムスタンプは ファイルの変更時刻から取得されます また DATETIME_CONFIG に CURRENT を設定して インデックス作成のパフォーマンスを向上することもできます この場合 インデックス時に現在のシステム時刻が 各イベントに割り当てられます 例 : この例は ソース foo からのイベントのタイムスタンプ抽出をオフにします [source::foo] DATETIME_CONFIG = NONE... 注意 :CURRENT と NONE の両 が 明 的にタイムスタンプの識別を無効にします そのため デフォルトのイベント境界検出 (BREAK_ONLY_BEFORE_DATE = true) は 的通りには機能しません これらの設定を使 する場合は SHOULD_LINEMERGE や BREAK_ONLY_*, MUST_BREAK_* 設定を使ってイベントの結合を管理します インデックス作成フィールド抽出の設定 インデックス作成フィールドの抽出について Splunk がデータのインデックスを作成する場合 データストリームをパーシングして 連のイベントを作成します このプロセスの 環として イベントデータにさまざまなフィールドが追加されます これらのフィールドには 動的に追加されるデフォルトフィールドや 分が指定したカスタムフィールドが含まれます イベントへのフィールドの追加プロセスは フィールドの抽出と呼ばれています 2 種類のフィールド抽出が存在してい 105

106 ます インデックス作成フィールドの抽出 : このトピックの始めに簡単に説明しましたが これがこの章で説明する主な項 になります これらのフィールドはインデックス内に保管され イベントデータの 部となります サーチ時フィールドの抽出 : データのサーチ時に処理が われます これらのフィールドはその場で抽出され インデックスには保管されません この種類のフィールド抽出については ナレッジ管理 マニュアルの サーチ時フィールド抽出の作成 を参照してください 2 種類のインデックスされたフィールドが存在しています デフォルトフィールド :Splunk が各イベントに 動的に追加します この章の デフォルトフィールドについて を参照してください カスタムフィールド : 分が指定したフィールドです この章の インデックス時のカスタムフィールドの作成 を参照してください 重要 : インデックス時にカスタムフィールドを作成するのは 般的にはお勧めできません ただし サーチ時にすべてのカスタムフィールドを作成することができます 詳細は インデックス時のカスタムフィールドの作成 を参照してください デフォルトフィールドについて (host source sourcetype など ) データのインデックス作成時には 各イベントにさまざまなフィールドが追加されます これらのフィールドは インデックスのイベントデータの 部となります Splunk が 動的に追加するフィールドは デフォルトフィールドと呼ばれます デフォルトのフィールドは さまざまな 的に利 されます たとえば index はイベントが存在しているインデックスを します デフォルトフィールド linecount はイベントに含まれる 数を timestamp はイベントの発 時刻を します Splunk はデータのインデックス作成時に 部のフィールドの値 特に sourcetype の値を利 して 正しくイベントを作成します データのインデックスが作成されたら サーチにデフォルトフィールドを使 できます すべてのデフォルトフィールドの 覧を以下に します フィールドのタイプ 内部フィールド 基本的なデフォルトフィールド デフォルトの 時フィールド フィールドのリスト _raw, _time, _indextime 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 説明 これらのフィールドには Splunk が内部処理の 的で使 する情報が含まれています これらのフィールドは イベントのソース 含まれているデータの種類 保管されているインデックス 含まれている 数 発 時などのイベントに関する基本情報を表しています これらのフィールドは イベントのタイムスタンプに対するサーチをさらに細かく制御するために いられます 注意 : 各システムで 成されたタイムスタンプ情報を持つイベントのみが date_* フィールドを持っています イベントに date_* フィールドがある場合 それはイベント 体からの直接の時間 / 付値を表しています インデックス時 / 時にタイムゾーン変換や時間 / 付値の変更をを った場合 ( 例 : タイムスタンプがインデックス時または 時になるように設定した ) これらのフィールドはそれを表さないようになります サーチの観点からのデフォルトフィールドについての情報は ナレッジ管理 マニュアルの デフォルトフィールドの使 を参照してください 注意 : インデックスに追加する 独 のカスタムフィールドを指定することもできます この章の インデックス時のカスタムフィールドの作成 を参照してください このトピックは 3 つの主要デフォルトフィールドを取り上げていきます ホストソースソースタイプ host source および sourcetype ソースタイプの定義 host source および sourcetype フィールドは以下のように定義されます host - イベントの host の値は 般的にはイベントの発 元となるホスト名 IP アドレス またはネットワークホストの完全修飾ドメイン名になります host 値を利 すれば 特定のデバイスから収集されたデータを 軽に特 106

107 定することができます ホストの詳細は ホストについて を参照してください 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 割り当てを変更することができます 当初は別のホストで 成されたアーカイブデータを 括ロードしており それらのイベントにそのホスト値を設定したい場合 データが別のホストから転送されている場合 ( 特に指定のない限り フォワーダーがホストになります ) どこで 成されたログでも そのログデータを受信したサーバーがホストになるような 集中ログサーバー環境で作業を っている場合 ホストの詳細は ホスト値の設定 を参照してください ソースタイプ割り当てに優先する設定 以下のような場合に デフォルトの sourcetype 割り当てを変更することができます Splunk がデータを適切に 動フォーマットできず 誤ったタイムスタンプ設定やイベントの 分割が われるなどの問題が発 する場合 離散グループのホストに由来するイベント または特定の IP アドレスやユーザー ID に関連するイベントなど 特定の から受信した特定のイベントにソースタイプを適 したい場合 Splunk が 動的に認識できるソースタイプを拡張することも または単にソースタイプの名前を変更することも可能です ソースタイプの詳細は ソースタイプの設定 を参照してください デフォルトフィールドの動的割り当て Splunk への取り込み時に ファイルにデフォルトフィールド ( メタデータ ) を動的に割り当てることができます この機能を利 して 受信データにソースタイプ ホスト またはソースを動的に指定できます この機能は主に スクリプト やスクリプトが処理した既存のファイルからのデータを処理する場合に役 ちます 重要 : 継続的なファイルモニタリング (tail) に動的メタデータ割り当てを使 することはお勧めできません ファイル の詳細は このマニュアルの ファイルとディレクトリのモニター を参照してください この機能を使 するには ファイルに単 の動的 ヘッダーを追加して 値を割り当てるメタデータフィールドを指定します 利 可能なメタデータフィールドは sourcetype host および source です inputs.conf props.conf および transforms.conf を編集する代わりに この 法を使ってメタデータを割り当てることができます 単 の ファイルの設定 既存の ファイルに対してこの機能を使 するには ファイルを編集して単 の ヘッダーを追加します ( 動またはスクリプトを使って ) 107

108 ***SPLUNK*** <metadata field>=<string> <metadata field>=<string>... <metadata field>=<string> には 有効なメタデータ / 値のペアを設定します 複数のペアを指定することができます 例 :sourcetype=log4j host=swan 単 のヘッダーをファイル内の任意の場所に追加します EOF に達するまで ヘッダーに続く任意のデータが 割り当てた属性と値に追加されます ファイルを $SPLUNK_HOME/var/spool/splunk または Splunk がモニターしている他のディレクトリに追加します スクリプトによる設定 スクリプトを作成して 受信するデータストリームに動的に ヘッダーを追加することができます また ファイルの内容に基づいて 動的にヘッダーを設定することもできます インデックス時のカスタムフィールドの作成 警告 : Splunk がインデックス時に 動的に抽出してインデックスを作成する 連のデフォルトフィールド (timestamp punct host source sourcetype など ) に カスタムフィールドを追加することはお勧めできません このフィールドリストに追加すると インデックス作成された各フィールドがサーチ可能インデックスのサイズを増やすため インデックス作成のパフォーマンスとサーチ時間に悪影響を与える可能性があります インデックス作成フィールドは柔軟性にも けています 連のフィールドを変更すると データセット全体のインデックスを再作成する必要があります 詳細は インデクサーとクラスタの管理 マニュアルの インデックス時とサーチ時 を参照してください これらの注意事項や問題があっても カスタムフィールドを追加しなければならないことがあります たとえば 特定のサーチ時フィールド抽出が サーチのパフォーマンスに きな影響を与えるような環境が挙げられます たとえば 頻繁に きなイベントセットに対して foo!=bar や NOT foo=bar などの式でサーチを実 し foo フィールドがほぼ常に値 bar を取る場合がこれにあたります 反対に サーチ時抽出フィールドの値が ほぼフィールド外に存在している場合に インデックス作成フィールドを追加したいこともあります たとえば foo=1 のみをサーチするような場合に foo=1 を持たない多くのイベント内に 1 が存在している場合 インデックス時に抽出されるフィールドのリストに foo を追加する が効率的なことがあります 般的には サーチ時にカスタムフィールドを抽出するようにしてください 詳細は ナレッジ管理 マニュアルの サーチ時フィールド抽出の作成 を参照してください 追加のインデックス作成フィールドの定義 追加のインデックス作成フィールドを定義するには props.conf transforms.conf および fields.conf を編集します $SPLUNK_HOME/etc/system/local/ 内 または $SPLUNK_HOME/etc/apps/ の独 のカスタムアプリケーションディレクトリ内にある これらのファイルを編集します 設定ファイルの 般情報については 管理マニュアル の 設定ファイルについて を参照してください フィールド名構 の制限事項 Splunk では フィールド名に英数字とアンダースコアのみを使 できます フィールド名に使 できる 字は a-z A-Z 0-9 _ です フィールド名の先頭に 0-9 または _ を使 することはできません 先頭のアンダースコアは Splunk の内部変数 に予約されています 国際 字は使 できません transforms.conf への新規フィールド 正規表現スタンザの追加 transforms.conf にインデックス時フィールド変換を定義する場合は 以下のフォーマットに従ってください ( 注意 :LOOKAHEAD や DEST_KEY など 部の属性は 特定の 途でのみ必要になります ): [<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 のように すべての変換に <unique_stanza_name> が必要になります REGEX は データからフィールドを抽出するための正規表現です REGEX の名前付きグループは 直接フィールドに抽出されます 単純なフィールド抽出の場合は FORMAT を指 108

109 定する必要はありません REGEX でフィールド名と対応する値の両 を抽出する場合 以下の特殊グループを使って FORMAT 属性のマッピング指定をスキップすることができます _KEY_<string>, _VAL_<string> たとえば 以下の事項は同じ意味を持っています FORMAT の使 : REGEX = ([a-z]+)=([a-z]+) FORMAT = $1::$2 FORMAT を不使 : REGEX = (?<_KEY_1>[a-z]+)=(?<_VAL_1>[a-z]+) FORMAT の指定はオプションです これを使って 追加する任意のフィールド名や値も含めて 抽出するフィールド / 値のペアのフォーマットを指定します 名前付きグループを使った単純な REGEX の場合は FORMAT を指定する必要はありません FORMAT は 抽出がサーチ時に われるのか またはインデックス時に われるのかによって動作が異なります インデックス時変換の場合 $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 の場合 : FORMAT = foo$1 would yield foobar FORMAT = foo$bar would yield foo$bar FORMAT = foo$1234 would yield foo$1234 FORMAT = foo$1\$2 would yield foobar\$2 WRITE_META = true は抽出されたフィールド名と値を _meta (Splunk によるインデックス作成フィールドの保管場所 ) に書き込みます この属性は DEST_KEY = _meta の場合を除いて すべてのインデックス時フィールド抽出に設定する必要があります ( 後述する DEST_KEY の説明を参照 ) _meta に関する情報 およびそれがインデックス作成フィールドの作成時に果たす役割については 後述する Splunk によるインデックス作成フィールドの構築 法 を参照してください WRITE_META = false が設定されている または何も設定されていない場合 インデックス時フィールド抽出には DEST_KEY が必要です これは REGEX の結果の保管場所を します インデックス時サーチの場合は DEST_KEY = _meta (Splunk がインデックス作成フィールドを保管する場所 ) です その他の可能な KEY 値については このマニュアルの transforms.conf に関するページを参照してください _meta に関する情報 およびそれがインデックス作成フィールドの作成時に果たす役割については 後述する Splunk によるインデックス作成フィールドの構築 法 を参照してください DEST_KEY = _meta を使 する場合は FORMAT 属性の先頭に $0 を追加する必要があります $0 は Splunk が REGEX を実 する前の DEST_KEY の値です (_meta) 注意 :$0 の値が REGEX から得られることはありません DEFAULT_VALUE の指定はオプションです REGEX が失敗した場合 この属性の値は DEST_KEY に書き込まれます デフォルトは空です SOURCE_KEY の指定はオプションです これを使って REGEX を適 する値の KEY を指定します デフォルトは SOURCE_KEY = _raw で この場合すべてのイベントに丸ごと適 されます 般的には REPEAT_MATCH とともに使 されます その他の可能な KEY 値については このマニュアルの transforms.conf に関するページを参照してください 109

110 REPEAT_MATCH の指定はオプションです SOURCE_KEY に対して REGEX を複数回実 する場合は true を設定します REPEAT_MATCH は 前回照合が停 された場所から開始し 致する項 が つからなくなるまで処理を続 します イベントあたりに予測される フィールド / 値の 致項 数が不明な場合などに役 ちます デフォルトは false です LOOKAHEAD の指定はオプションです イベント内のサーチ 字数を指定します デフォルトは 256 です の さが 256 字を超えるイベントがある場合は LOOKAHEAD の値を増やすことができます 注意 : 正規表現の構 と使 法の概要については Regular-Expressions.info を参照してください 正規表現をテストするには rex サーチコマンドのを使 します 正規表現式を作成 テストするために役 つサードパーティ製ツールのリストも 意されています 注意 : 正規表現内の捕捉グループは フィールド名構 の制限事項に従ったフィールド名を指定する必要があります ASCII 字 (a z A Z 0 9 または _) のみを使 できます 国際 字は使 できません props.conf への新しいフィールドのリンク props.conf に 以下の を追加します [<spec>] TRANSFORMS-<class> = <unique_stanza_name> 以下の事項に注意してください <spec> には 以下の値を使 できます <sourcetype> イベントのソースタイプ host::<host> <host> はイベントのホストです source::<source> <sourct> はイベントのソースです 注意 :<spec> の設定時には 正規表現型構 を使 できます また ソースおよびソースタイプスタンザの照合では 字と 字が区別されますが ホストスタンザでは区別されません 詳細は props.conf 仕様ファイルを参照してください <class> は 抽出するフィールド ( キー ) の名前空間を識別する 意のリテラル 字列です 注意 : <class> の値は フィールド名構 の制限事項 ( 前述 ) に従う必要はありません a-z A-Z および 0-9 以外の 字を使 でき またスペースも利 できます <unique_stanza_name> は transforms.conf のスタンザ名です 注意 : インデックス時フィールド抽出の場合 props.conf は TRANSFORMS-<class> を使 します EXTRACT-<class> は サーチ時フィールド抽出の設定に いられます fields.conf への新規フィールド エントリの追加 fields.conf に新しいインデックス作成フィールド のエントリを追加します [<your_custom_field_name>] INDEXED=true 以下の事項に注意してください <your_custom_field_name> は transforms.conf に追加する 意のスタンザ内に設定する カスタムフィールドの名前です フィールドのインデックスが作成されることを すために INDEXED=true を設定します 注意 : サーチ時に同名のフィールドが抽出される場合は フィールドに対して INDEXED=false を設定する必要があります また そのフィールドの インデックス時には取得されないけれども サーチ時には抽出される値を持つイベントが存在する場合も INDEXED_VALUE=false を設定する必要があります たとえば インデックス時に単純な <field>::1234 抽出を う場合を考えてみましょう これは機能しますが A(\d+)B のような正規表現に基づいてサーチ時フィールド抽出も うような場合は 字列 A1234B がそのフィールドの値 1234 を み出すため 問題が発 してしまいます これによりサーチ時に 1234 のイベントが登場するため Splunk は <field>::1234 抽出を使ってインデックス時を特定することができなくなってしまいます 変更内容を反映するための Splunk の再起動 props.conf や transforms.conf などの設定ファイルの変更は Splunk をシャットダウンして再起動しないと反映されません Splunk によるインデックス作成フィールドの構築 法 Splunk は _meta に書き込むことで インデックス作成フィールドを構築しています その詳細を以下に します _meta は transforms.conf 内の DEST_KEY = _meta または WRITE_META = true を含むすべての 致する変換により変 110

111 更されます 致する各変換は _meta を上書きすることができます _meta に追加する場合は WRITE_META = true を使 します WRITE_META を使 しない場合は $0 で FORMAT を開始します パーシング中に _meta が完全に構築されたら Splunk は以下の 法でテキストを変換します テキストはユニットに分割されます 各ユニットは空 字で区切られます 空 字の有無に関係なく 引 符 (" ") で 字を きなユニットにグループ化します 引 符直前の円記号 (\) またはバックスラッシュは 引 符のグループ化特性を無効にします 円記号の前に円記号があると その円記号が無効になります 2 つの連続するコロン (::) を含むテキストユニットは 抽出フィールドに変換されます 2 つの連続するコロンの左側がフィールド名 右側が値になります 注意 : 般的に正規表現抽出値を持ち引 符を含むインデックス作成フィールドは機能せず 円記号がある場合にも問題があります サーチ時に抽出されるフィールドには これらの制限はありません 引 符と円記号を含んでおり それらが無効になるような 連のインデックス時抽出の例を以下に します 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 を作成します transforms.conf transforms.conf に以下の項 を追加します [netscreen-error] REGEX = device_id=\[\w+\](?<err_code>[^:]+) FORMAT = err_code::"$1" WRITE_META = true このスタンザは device_id= に続けて 括弧に囲まれた単語 およびコロンで終了するテキスト 字列を取ります イベントのソースタイプは testlog です コメント : FORMAT = には 以下の値が含まれています err_code:: は フィールド名です $1 は インデックスに書き込まれる新しいフィールドを表しています REGEX により抽出された値です WRITE_META = true は FORMAT の内容をインデックスに書き込むことを表しています props.conf props.conf に以下の を追加します [testlog] TRANSFORMS-netscreen = netscreen-error fields.conf fields.conf に以下の を追加します [err_code] INDEXED=true 111

112 設定ファイルの変更内容を反映するために Splunk を再起動します 1 つの正規表現で 2 つの新規インデックス作成フィールドを定義 この例では インデックス作成フィールド username および login_result を作成します transforms.conf transforms.conf に以下の項 を追加します [ftpd-login] REGEX = Attempt to login by user: (.*): login (.*)\. FORMAT = username::"$1" login_result::"$2" WRITE_META = true このスタンザは リテラルテキスト Attempt to login by user: を探し 後ろにコロンが付いたユーザー名を抽出し 次に後ろにピリオドが付いた結果を抽出します は以下のようになります :15:21 mightyhost awesomeftpd INFO Attempt to login by user: root: login FAILED. props.conf props.conf に以下の を追加します [ftpd-log] TRANSFORMS-login = ftpd-login fields.conf fields.conf に以下の を追加します [username] INDEXED=true [login_result] INDEXED=true 設定ファイルの変更内容を反映するために Splunk を再起動します インデックス時のイベントセグメントからのフィールド値の連結 この例は インデックス時変換を使った イベントの個別のセグメントの抽出 および FORMAT を使ってそれらを結合して 単 のフィールドを作成する 法を表しています 以下のイベントが存在する場合を考えてみましょう :48: PACKET 078FCFD0 UDP Rcv R Q [0084 A NOERROR] A (4)www(8)google(3)com(0) 的は (4)www(8)google(3)com(0) を dns_requestor フィールドの値として抽出することです ただし それらの無意味な括弧と数字は不要で 単純に のみを抽出たいと考えています そのためにはどうすれば良いのでしょうか? transforms.conf j まず 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 を使 する必要がある場合は 実 するために新しいインデックス作成フィールドを作成する必要があります props.conf 112

113 次に dnsrequest 変換を参照し それを server1 ソースタイプから受け取るイベントに適 するフィールド抽出を props.conf に定義します [server1] TRANSFORMS-dnsExtract = dnsrequest fields.conf 最後に fields.conf に以下のスタンザを設定します [dns_requestor] INDEXED = true 設定ファイルの変更内容を反映するために Splunk を再起動します ヘッダーのあるファイルからのデータの抽出 カンマ区切り形式 (CSV) ファイルなどの構造化データの多くが ファイルヘッダーに情報を保有しています Splunk はその情報を使って インデックス時イベント処理中にフィールドを抽出することができます これらのフィールドを 動抽出するように Splunk を設定することができます たとえば 般的に従来の CSV ファイルは それ以降の の値に対する列 出しを含む から始まります host,status,message,"start date" srv1.splunk.com,error,"no space left on device", t06:35:00 srv2.splunk.com,ok,-, t06:00:00 ヘッダーベースの 動フィールド抽出を有効にする ヘッダーがあるファイル ( カンマ区切り形式ファイル IIS Web サーバーログ および他の構造化データファイルなど ) からデータを抽出するには inputs.conf と props.conf を組み合わせて使 します $SPLUNK_HOME/etc/system/local/ 内 または $SPLUNK_HOME/etc/apps/<app_name>/local の独 のカスタム App ディレクトリ内にある これらのファイルを編集します Inputs.conf には モニターするファイル およびモニターするために使 するソースタイプを指定します props.conf には ソースタイプ 体を定義します 設定ファイルの 般情報については 管理マニュアル の 設定ファイルについて を参照してください 重要 :props.conf に対して った変更は ( ヘッダーベースの 動フィールド抽出など ) Splunk を再起動しない限り反映されません 構造化データ の Props.conf 属性 props.conf には ヘッダーを含むファイルを処理するために以下の属性が含まれています 他の props.conf 属性については props.conf 仕様ファイルを参照してください 属性 説明 デ フォ ルト INDEXED_EXTRACTIONS = {CSV,W3C,TSV,PSV} PREAMBLE_REGEX FIELD_HEADER_REGEX HEADER_FIELD_LINE_NUMBER FIELD_DELIMITER FIELD_QUOTE TIMESTAMP_FIELDS = field1,field2,...,fieldn ファイルのタイプと抽出 またはファイルに対して使 するパーシング 法を Splunk に指 します ファイルによってはプリアンブル が含まれていることもあります この属性には 指定パターンに基づいてそれらのプリアンブル を無視するための 正規表現を指定します プリフィックスが付いたヘッダー のパターンを す正規表現 実際のヘッダーはパターンの後から始まり それはヘッダーフィールドには含まれないことに注意してください この属性には 特殊 字を指定することができます ヘッダーフィールドを含むファイル内の の 番号を します 0 を設定すると Splunk がファイル内のヘッダーフィールドを 動的に検索します 指定ファイルまたはソース内のフィールドを区切る / 分割する 字を しますこの属性には 特殊 字を指定することができます 指定ファイルまたはソース内の 引 に使 する 字を しますこの属性には 特殊 字を指定することができます 部の CSV および構造化ファイルには 区切り 字で区切られた イベント内の複数のフィールドにまたがるタイムスタンプが存在していることもあります この属性は タイムスタンプを構成するそのようなフィールドを カンマ区切り形式で 113 CSV N/A N/A 0 N/A N/A N/A

114 FIELD_NAMES 指定することを Splunk に指 します 部の CSV および構造化ファイルには ヘッダーが存在しないことがあります この属性は ヘッダーフィールドを直接指定することを Splunk に指 します N/A 部の属性では特殊 字を使 できる 部の属性には 円記号 (\) またはバックスラッシュを使 することで スペース 垂直タブ 平タブ フォームフィードなどの特殊 字を指定することができます 特殊 字 Props.conf の表記 フォームフィード \f スペース \s 平タブ \t 垂直タブ \v これらの特殊 字は 以下の属性に指定することができます FIELD_DELIMITER FIELD_HEADER_REGEX FIELD_QUOTE 設定ファイルの編集によるソースタイプの作成と参照 新しい属性を使 するには $SPLUNK_HOME/etc/system/local の props.conf を編集する必要があります Splunk がヘッダーデータを持つファイルから フィールドを抽出するための 法を定義した新しいソースタイプを作成するには props.conf を編集します props.conf を編集したら 次に Splunk がインデックスを作成するファイル内に新たに作成されたソースタイプを参照するように inputs.conf を編集します ヘッダーを持つファイル抽出 の新しいソースタイプを作成 参照するには : 1. テキストエディタで $SPLUNK_HOME/etc/system/local 内の props.conf を開きます 注意 : このファイルが存在しない場合は 作成する必要があります 2. 前述の属性を使って Splunk にファイルヘッダーおよび構造化ファイルデータの抽出 法を指 するスタンザを作成することで 新しいソースタイプを定義します 例 : [HeaderFieldsWithFewEmtpyFieldNamesWithSpaceDelim] FIELD_DELIMITER=, HEADER_FIELD_DELIMITER=\s FIELD_QUOTE=" 注意 : 必要に応じて 任意の数のスタンザ ( ソースタイプ ) を定義することができます 3. props.conf を保存して終了します 4. inputs.conf ファイルが存在していない場合は 同じディレクトリにファイルを作成します 5. 編集するためにファイルを開きます 6. ファイルヘッダーおよび構造化データを抽出するファイルを表すスタンザを追加します 複数追加することもできます 例 : [monitor:///opt/test/data/structureddata/headerfieldswithfewemtpyfieldnameswithspacedelim.csv] sourcetype=headerfieldswithfewemtpyfieldnameswithspacedelim 注意 : ヘッダーと構造化データを抽出するファイルやディレクトリのために 任意の数のスタンザを追加することができます 7. inputs.conf ファイルを保存して閉じます 8. 変更内容を反映するために Splunk を再起動します ヘッダーファイルから抽出したデータの転送 ヘッダーを持つファイルから抽出したフィールドを 他の Splunk インスタンスに転送することもできます 114

115 構造化データファイルから抽出したフィールドを転送するには 以下の 順に従ってください 1. ファイルをモニターする Splunk インスタンス上で このトピック前半の 設定ファイルの編集によるソースタイプの作成と参照 の説明に従って props.conf および inputs.conf を編集します 2. 次に データを他の Splunk インスタンスに転送するようにシステムを設定します 注意 : データを送信または受信するための Splunk インスタンスの設定 法については 分散デプロイ マニュアルの 転送と受信の設定 を参照してください 3. データを受信する Splunk インスタンス上で Splunk をレシーバーとして設定します 4. 受信側 Splunk インスタンスの $SPLUNK_HOME/etc/system/local に props.conf ファイルが存在していない場合は そのディレクトリにファイルを作成します 5. モニターする Splunk インスタンス上の props.conf から適切なスタンザを 受信側 Splunk インスタンス上に作成した props.conf をコピーします 6. 受信側 Splunk インスタンスで Splunk を再起動します 7. モニター側 Splunk インスタンスで Splunk を再起動します 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 がこのファイルを読み込むと header4 列の はすべて空のため このヘッダーフィールドまたはその のインデックスを作成することはありません このことは インデックス内で header4 またはその 内のデータをサーチできないことを意味しています ただし header4 フィールドに空 字列 ( 例 :"") が存在する が含まれている場合 そのフィールドおよびそのすべての のインデックスが作成されます Splunk は中間ファイルのヘッダーフィールド名変更をサポートしていない Internet Information Server などの 部のソフトウェアは ファイル処理中のヘッダーフィールド名の変更をサポートしています Splunk はこのような変更を認識できません ファイル内でヘッダーフィールドの名前が変更されたファイルのインデックス作成を試みても 名前が変更されたヘッダーフィールドのインデックスは作成されません 設定およびデータファイルの例 ファイルヘッダー抽出属性の使 法を表す inputs.conf と props.conf ファイルの例を以下に します データをローカルに抽出するには inputs.conf と props.conf を編集して 構造化データファイルの とソースタイプを定義し 次に前述の属性を使って Splunk にファイルの処理 法を指 します このデータを他の 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] sourcetype=verylargecsvfile [monitor:///opt/test/data/structureddata/uselesslongheadertobeignored.log] sourcetype=uselesslongheadertobeignored 115

116 [monitor:///opt/test/data/structureddata/headerfieldswithfewemptyfieldnameswithspacedelim.csv] sourcetype=headerfieldswithfewemptyfieldnameswithspacedelim 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=" サンプルファイル 設定したファイルがどのようになるのかを理解するために 先ほど取り上げた inputs.conf および props.conf の 部を抜粋した サンプルファイルを以下に します 注意 : 内容をすべて参照するために 右 向に少しスクロールしなければならないかもしれません CSVWithFewHeaderFieldsWithoutAnyValues.csv vqmcallhistoryid,serialnumber,vqmavgjbenvdelay,vqmavgjbenvnegdelta,vqmavgjbenvposdelta,vqmbitrate,vqmburstcount,vqmbu 99152,CFG ,-3,-2,356,64000,1,280,14,14.29,36,3499,201000,BW @ , :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,,,,,6 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,6 0/1,2,0,54,80,80,18500, ,48,1,0, :41:47.303, :41: ,CFG ,-3,-1,251,64000,4,195,9,20.52,28,3494,359000,BW @ , :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,,,,,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, 0/1,2,0,48,60,70,30400, ,54,1,0, :41:47.342, :41: VeryLargeCSVFile.csv IncidntNum,Category,Descript,DayOfWeek,Date,Time,PdDistrict,Resolution,Location,X,Y ,FRAUD,"FORGERY, CREDIT CARD",Tuesday,02/18/2003,16:30,NORTHERN,NONE,2800 Block of VAN NESS AV, , ,WARRANTS,WARRANT ARREST,Thursday,04/17/2003,22:45,NORTHERN,"ARREST, BOOKED",POLK ST / SUTTER ST, , ,LARCENY/THEFT,GRAND THEFT PICKPOCKET,Tuesday,02/18/2003,16:05,NORTHERN,NONE,VAN NESS AV / MCALLISTER ST, , ,DRUG/NARCOTIC,SALE OF BASE/ROCK COCAINE,Tuesday,02/18/2003,17:00,BAYVIEW,"ARREST, BOOKED",1600 Block of KIRKWOOD AV, , ,OTHER OFFENSES,CONSPIRACY,Tuesday,02/18/2003,17:00,BAYVIEW,"ARREST, BOOKED",1600 Block of KIRKWOOD AV, , ,OTHER OFFENSES,PROBATION VIOLATION,Tuesday,02/18/2003,17:00,BAYVIEW,"ARREST, BOOKED",1600 Block of KIRKWOOD AV, , UselessLongHeaderToBeIgnored.log ************ Start Display Current Environment ************ WebSphere Platform 6.1 [ND cf ] running with process name sammys_cell_a\fsgwws189node_a\sammys_a_c01_s189_m06 and process id Detailed IFix information: ID: WS-WASSDK-AixPPC32-FP BuildVrsn: null Desc: Software Developer Kit ID: WS-WAS-AixPPC32-FP BuildVrsn: null Desc: WebSphere Application Server ID: WS-WASSDK-AixPPC32-FP BuildVrsn: null Desc: Software Developer Kit ID: WS-WAS-AixPPC32-FP BuildVrsn: null Desc: WebSphere Application Server

117 ID: sdk.fp61021 BuildVrsn: null Desc: WebSphere Application Server ID: sdk.fp61019 BuildVrsn: null Desc: WebSphere Application Server ID: was.embed.common.fp61021 BuildVrsn: null Desc: WebSphere Application Server ID: was.embed.fp61021 BuildVrsn: null Desc: WebSphere Application Server HeaderFieldsWithFewEmptyFieldNamesWithSpaceDelim.csv "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 Answers 何か質問がありますか? Splunk Answers では Splunk コミュニティに寄せられた フィールドの抽出に関する質問と回答をご覧いただけます ホスト値の設定 ホストについて イベントの host フィールドの値は イベントが 成された物理デバイスの名前です これは Splunk がインデックスを作成した各イベントにホストを割り当てる デフォルトフィールドのため 特定のホストが 成したすべてのイベントを ホスト名を使ってサーチすることができます 般的に host の値は イベントの 成元となるホスト名 IP アドレス またはネットワークホストの完全修飾ドメイン名になります Splunk による host 値の割り当て Splunk は以下の順序で設定を調査し 最初に つかったホスト設定を使って各イベントに host 値を割り当てます 1. transforms.conf に指定されている イベント固有のホスト割り当て 2. イベントの の デフォルトのホスト値 ( ある場合 ) 3. 最初にデータを取り込んだ Splunk サーバー ( インデクサーまたはフォワーダー ) の デフォルトのホスト値 これらの割り当て 法の概要と使 事例は 後述します 以降のトピックでは これらの 法を詳細に説明していきます Splunk サーバーのデフォルトのホスト値 ソースに対して他のホストルールが指定されていない場合 任意の から Splunk インスタンスに取り込まれる すべてのデータに適 されるデフォルト値が host フィールドに割り当てられます デフォルトのホスト値は 最初にデータを取り込んだ Splunk インスタンス ( インデクサーまたはフォワーダー ) のホスト名または IP アドレスになります イベントが発 したサーバー上で Splunk インスタンスが動作している場合は このホスト名は正確で 動による介 は必要ありません 詳細は このマニュアルの Splunk サーバーのデフォルトホストの設定 を参照してください ファイル / ディレクトリ のデフォルトホスト Splunk を集中ログアーカイブマシン上で実 している場合 または環境内の他のホストから転送されたファイルを処理している場合 特定の から取り込まれるイベントの デフォルトのホスト割り当てに優先する設定を わなければならないことがあります 特定の から取り込まれたデータのホスト値を割り当てるには 2 種類の 法があります 特定の から取り込まれるすべてのデータに対して 静的なホスト値を定義する またはパスの 部やソースのファイル名などを ホスト値に動的に割り当てることができます 各ホストのログアーカイブを異なるサブディレクトリに分類するようなディレクトリ構造を採 している場合は 後者の 法が役 ちます 詳細は このマニュアルの ファイル / ディレクトリ のデフォルトホストの設定 を参照してください イベント固有の割り当て 状況によっては イベントデータを調査してホスト値を割り当てなければならないこともあります たとえば イベントを Splunk に送信する集中ログホストがある場合 そのメインのログサーバーには複数のホストサーバーがデータを送信しています 各イベントにその 成元サーバーのホスト値を確実に設定するには そのイベントのデータを使ってホスト値を決定する必要があります 117

118 詳細は このマニュアルの イベントデータに基づくホスト値の設定 を参照してください 誤って割り当てられたホスト値の取り扱い イベントデータに誤ったホスト値が割り当てられた場合でも 配することはありません このような問題を修正するための さまざまな 段が存在しています 詳細は このマニュアルの 誤って割り当てられたホスト値の取り扱い を参照してください ホスト値のタグ設定 正確なサーチを実 する 助けとして ホスト値にタグを設定することができます タグを利 することで さまざまなホストのグループを有 なサーチ可能カテゴリに変換することができます 詳細は ナレッジ管理 マニュアルの タグとエイリアスについて を参照してください Splunk サーバーのデフォルトホストの設定 イベントのホスト値は イベントが 成されたネットワーク上の物理デバイスの IP アドレス ホスト名 または完全修飾ドメイン名です Splunk はインデックス時に インデックスを作成した各イベントに対して host 値を割り当てるため ホスト値でサーチを実 することで 特定のデバイスに由来するデータを 軽に発 することができます デフォルトのホスト割り当て ソースに対して他のホストルールを指定していない場合 ( この章で説明している情報を使って ) イベントのデフォルトのホスト値は 最初にイベントデータを取り込んだ Splunk インスタンス ( フォワーダーまたはインデクサー ) が動作しているサーバーの ホスト名または IP アドレスになります イベントが Splunk インスタンスが動作しているサーバー上で 成された場合 そのホスト名割り当ては正確で 何も設定を変更する必要はありません ただし すべてのデータが他のホストから転送される またはアーカイブデータの 括ロードを う場合 そのデータのデフォルトのホスト値を変更した が良いことがあります host フィールドのデフォルト値を設定するには Splunk Web を使 するか または inputs.conf を編集します Splunk Web を使ったデフォルトホスト値の設定 Splunk Web を使って サーバーのデフォルトホスト値を設定します 1. Splunk Web で 画 の右上にある [ システム ] リンクをクリックします 2. [ システム ] で [ システム設定 ] をクリックします 3. [ システム設定 ] ページで [ 全般設定 ] をクリックします 4. [ 全般設定 ] ページで [ インデックス設定 ] セクションまでスクロールして [ デフォルトのホスト名 ] を変更します 5. 変更内容を保存します この Splunk インスタンスに取り込まれるすべてのイベントの host フィールドのデフォルト値が設定されます この章の後半で説明しているように 個別のソースまたはイベントに対して この値に優先する設定を うことができます inputs.conf を使ったデフォルトホスト値の設定 Splunk のインストール時に デフォルトのホスト割り当ては inputs.conf に設定されます $SPLUNK_HOME/etc/system/local/ 内 または $SPLUNK_HOME/etc/apps/ の独 のカスタム App ディレクトリ内にあるファイルを編集して ホスト値を変更することができます ホスト割り当ては [default] スタンザに設定します inputs.conf 内の デフォルトのホスト割り当ての形式を以下に します [default] host = <string> <string> に適切なデフォルトホスト値を設定してください <string> のデフォルト値は データが 成されたホストの IP アドレスまたはドメイン名になります 警告 :<string> の値を引 符で囲まないでください host="foo" ではなく host=foo のように指定します inputs.conf への変更内容を反映するために Splunk を再起動してください 注意 : デフォルトで host 属性には $decideonstartup 変数が設定されています これは splunkd が動作しているマシンのホスト名が設定されることを意味しています 値は splunkd の起動時に 毎回再取得されます 118

119 特定の から取り込んだデータのデフォルトホスト値に優先する設定 Splunk を集中ログアーカイブマシン上で実 している場合 または環境内の他のホストから転送されたファイルを処理している場合 特定の から取り込まれるイベントの デフォルトのホスト割り当てに優先する設定を わなければならないことがあります 特定の から取り込まれたデータのホスト値を割り当てるには 2 種類の 法があります 特定の から取り込まれるすべてのデータに対して 静的なホスト値を定義する またはパスの 部やソースのファイル名などを ホスト値に動的に割り当てることができます 各ホストのログアーカイブを異なるサブディレクトリに分類するようなディレクトリ構造を採 している場合は 後者の 法が役 ちます 詳細は このマニュアルの ファイル / ディレクトリ のデフォルトホストの設定 を参照してください イベントデータを使ったデフォルトホスト値に優先する設定 状況によっては イベントデータを調査してホスト値を割り当てなければならないこともあります たとえば イベントを Splunk に送信する集中ログホストがある場合 そのメインのログサーバーには複数のホストサーバーがデータを送信しています 各イベントにその 成元サーバーのホスト値を確実に設定するには そのイベントのデータを使ってホスト値を決定する必要があります 詳細は このマニュアルの イベントデータに基づくホスト値の設定 を参照してください ファイル / ディレクトリ のデフォルトホストの設定 特定のファイル / ディレクトリ のすべてのデータに ホスト値を設定することができます ホストは静的にまたは動的に設定することができます ホスト値を静的に設定する場合 指定したファイル / ディレクトリ から Splunk に取り込まれる各イベントには 同じホスト名が割り当てられます ホスト値を動的に設定する場合 正規表現またはソースのディレクトリパスのセグメントを使って ソース の 部がホスト名として抽出されます また ソースまたはソースタイプの値 ( および他の種類の情報 ) に基づいて 特定のファイル / ディレクトリ から取り込まれるイベントにホスト値を割り当てることも可能です 詳細は このマニュアルの イベントデータに基づくホスト値の設定 を参照してください 注意 : 現在 Splunk では TCP UDP またはスクリプト 経由で取り込んだイベントデータの デフォルトのホスト設定は有効にはなっていません デフォルトホスト値の静的設定 この 法では 特定のファイル / ディレクトリ から取り込まれた各イベントに 単 のデフォルトホスト値が適 されます 注意 : 静的なホスト値割り当ては 対応する から新たに取り込まれるデータにのみ適 されます すでにインデックスが作成されたデータに デフォルトのホスト値を割り当てることはできません 代わりに ホスト値にタグを設定することは可能です Splunk Web の使 Splunk Web の [ システム ] にある [ データ ] ページから ファイル / ディレクトリタイプの を新たに追加した場合 そのファイル / ディレクトリ のホストを定義することができます 1. Splunk Web の左上にある [ システム ] をクリックします 2. [ システム ] ポップアップの [ データ ] セクションで [ データ ] をクリックします 3. [ ファイルとディレクトリ ] をクリックします 4. [ ファイルとディレクトリ ] ページで 既存の の名前をクリックするか ( 更新する場合 ) または [ 新規 ] をクリックして 新しいファイル / ディレクトリ を作成します 5. [ ホスト ] セクションで [ ホスト設定 ] ドロップダウンから [ 定数値 ] オプションを選択します 6. [ ホストフィールドの値 ] フィールドに この の静的なホスト値を します 7. [ 保存 ] をクリックします および タイプの詳細は このマニュアルの Splunk がモニターできる項 を参照してください inputs.conf の編集 inputs.conf を直接編集して モニター対象ファイル / ディレクトリ のホスト値を指定することができます 適切なスタンザに host 属性を設定してください 119

120 [monitor://<path>] host = <your_host> $SPLUNK_HOME/etc/system/local/ 内 または $SPLUNK_HOME/etc/apps/ の独 のカスタムアプリケーションディレクトリ内にある inputs.conf を編集してください 設定ファイルの 般情報については 管理マニュアル の 設定ファイルについて を参照してください および タイプの詳細は このマニュアルの Splunk がモニターできる項 を参照してください 静的ホスト値割り当ての例 この例は /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/system/local/ 内 または $SPLUNK_HOME/etc/apps/ の独 のカスタムアプリケーションディレクトリ内にある inputs.conf を編集してください 設定ファイルの 般情報については 管理マニュアル の 設定ファイルについて を参照してください 正規表現を使って抽出した値で host フィールドを上書きするには host_regex を使 します [monitor://<path>] host_regex = <your_regex> 正規表現は各 のファイル名から host 値を抽出します 正規表現の最初の捕捉グループが ホストとして使 されます 注意 : 正規表現に 致する項 がない場合 デフォルトの host 属性がホストとして設定されます データソースのパス内のセグメントから抽出した値で host フィールドを上書きするには host_segment を使 します たとえば ソースへのパスが /var/log/<host server name> で 3 番 のセグメント ( ホストサーバー名 ) をホスト値にする場合は スタンザは以下のようになります 120

121 [monitor://var/log/] host_segment = 3 注意 :host_regex と host_segment を同時に指定することはできません 動的なホスト割り当ての例この例では 正規表現により /var/log/foo.log からのすべてのイベントに ホスト値 foo が割り当てられます [monitor://var/log] host_regex = /var/log/(\w+) この例は パス apache/logs 内の 3 番 のセグメントをホスト値に割り当てます [monitor://apache/logs/] host_segment = 3 イベントデータに基づくホスト値の設定 Splunk では イベント内のデータに基づいて イベントにホスト名を割り当てることができます このトピックでは イベントデータを使った デフォルトのホスト割り当てに優先する設定を う 法を説明していきます 設定 イベント単位の優先設定を うには 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 以下の事項に注意してください <unique_stanza_name> は 関連するホスト値を反映する必要があります この名前は 後ほど props.conf スタンザで使 します <your_regex> は ホスト値を抽出するイベント内の位置を す正規表現です FORMAT = host::$1 は REGEX の値を host:: フィールドに書き込みます 注意 : 正規表現の構 と使 法の概要については Regular-Expressions.info を参照してください 正規表現をテストするには rex サーチコマンドのを使 します 正規表現式を作成 テストするために役 つサードパーティ製ツールのリストも 意されています props.conf 次に props.conf に transforms.conf のスタンザを参照するスタンザを作成します [<spec>] TRANSFORMS-<class> = <unique_stanza_name> 以下の事項に注意してください 例 <spec> には 以下の値を使 できます <sourcetype> イベントのソースタイプ host::<host> <host> はイベントのホストを表します source::<source> <source> はイベントのソース値を表します <class> は 変換に割り当てる任意で 意の識別 です <unique_stanza_name> は transforms.conf で作成したスタンザ名です houseness.log ファイルから 以下のイベントセットを処理する場合を考えてみましょう ホストは 3 番 にあります 121

122 ( fflanda など ) :53 accepted fflanda :29 accepted rhallen :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 が存在しています この指定は イベントを改 ごとに分割することを しています これでサーチ結果には イベントが以下のように表 されるようになります 誤って割り当てられたホスト値の取り扱い 何らかの理由で 部のイベントに誤ったホスト値が割り当てられていることに気が付くこともあるでしょう たとえば Splunk サーバー上のディレクトリにいくつかの Web プロキシのログを収集して保管しており host フィールドの値に優先する設定を忘れたまま そのディレクトリを Splunk に として追加し それらのすべてのイベントのオリジナルのホスト値が Splunk ホストと同じになってしまうことがあります このような事態が発 した場合の対処 法を 複雑さの順番に記載していきます インデックス全体を削除して 再度インデックス作成する サーチを使って誤ったホスト値を持つイベントを削除して その後それらのイベントのインデックスを再作成する 不正なホスト値にタグを設定し サーチにはそのタグを使 する 静的なフィールドルックアップを設定してホストをルックアップし ルックアップファイル内のそれを新しいフィールド名にマップして その新しい名前をサーチに使 する host フィールドから新しいフィールド (temp_host など ) へのエイリアスを設定し 名前 temp_host を使って正しいホスト名をルックアップする静的なフィールドルックアップを設定し 次にルックアップでオリジナルの host を新しいルックアップ値で上書きする ( ルックアップの定義時に OUTPUT オプションを使 ) これらの 法の中で データのインデックスを削除してからインデックスを再作成できないけれども データを削除して再インデックスを作成できれば最 のパフォーマンスを実現できるような場合は 最後の 法が最適です ソースタイプの設定 ソースタイプが重要な理由 ソースタイプは Splunk が取り込んだすべてのデータに割り当てるデフォルトフィールドの 1 つです これは Splunk がインデックス作成時にデータを正しくフォーマットできるように 収集したデータの種類を表しています また これはデータの分類 法でもあり これを使ってデータを 軽にサーチすることができます ソースタイプに関する重要事項 Splunk はソースタイプを使ってデータのフォーマット 法を判断するため データには正しいソースタイプを割り当てることが 常に重要になります これにより インデックスが作成されたデータ ( イベントデータ ) は 適切なタイムスタンプおよびイベント分割を使って 期待通りのデータが作成されます そのため 以降のデータに対するサーチがとても簡単になります 122

123 たいていの場合 データに正しいソースタイプを割り当てるのはとても簡単です Splunk には 多数の事前定義されたソースタイプが 意されています 般的には データの取り込み時に Splunk が正しいソースタイプを 動的に選択します ただし ユーザーによる介 が必要な場合もあります 特殊なデータの場合 別の事前定義ソースタイプを 動で選択しなければならないこともあります またデータが 常に特殊な場合は 独 のイベント処理設定を持つ新たなソースタイプを作成する必要があります データソースに異機種環境データが含まれている場合は イベント単位 ( ソース単位ではない ) にソースタイプを割り当てなければならないこともあります データのインデックスが作成されたら他のフィールドと同様に ソースタイプを使ってイベントデータをサーチすることもできます ソースタイプはデータを分類する主要な 段であるため しばしばサーチで頻繁に利 されます 般的なソースタイプ 般的な任意のデータ フォーマットを ソースタイプにすることができます ソースタイプの 半は ログフォーマットです Splunk が 動的に認識できる 般的なソースタイプの例を以下に します access_combined:ncsa 結合フォーマットの HTTP Web サーバーログ apache_error: 標準の Apache Web サーバーエラーログ cisco_syslog:cisco ネットワークデバイス (PIX ファイアウォール ルーター および ACS を含む ) が 成する標準 syslog 般的には集中ログホストへのリモート syslog 経由 websphere_core:websphere からのコアファイルエクスポート 注意 :Splunk が 動的に認識するソースタイプの 覧については このマニュアルの 事前定義ソースタイプの 覧 を参照してください ソースタイプの設定 ソースタイプに関連する 2 種類の基本的な設定タイプがあります 取り込んだデータに明 的にソースタイプを割り当てる 最初から または既存のソースタイプを変更して 新しいソースタイプを作成する ソースタイプの割り当て たいていの場合 Splunk がデータに最適なソースを判断し 取り込んだイベントに 動的にそれを割り当てます ただし データにソースタイプを明 的に割り当てなければならないこともあります 通常この作業は データ の定義時に います ソースタイプ割り当ての改善 法の詳細は 以下のトピックを参照してください 動ソースタイプ割り当てに優先する設定 イベント単位でのソースタイプに優先する設定 ルールベースのソースタイプ認識の設定 ソースタイプ名の変更 このトピックの後半では Splunk によるソースタイプの割り当て 法が説明されています 新しいソースタイプの作成 ご利 のデータのニーズに既存のソースタイプでは対応できない場合は 新しいソースタイプを作成することができます Splunk のデータプレビュー機能を利 すれば ユーザーインターフェイスを使ってデータに合わせてソースタイプの設定を 軽に調整することができます 本質的にこの機能は ビジュアルなソースタイプエディタと呼ぶことができます 詳細は データのプレビューとソースタイプ を参照してください また props.conf を直接編集して ソースタイプのスタンザを追加することで 新しいソースタイプを作成することもできます 新しいソースタイプの作成 法を学習するには ソースタイプの作成 を参照してください データプレビュー機能を使ったソースタイプのテストと変更 Splunk Web のデータプレビュー機能は に適 したソースタイプの効果を 軽に参照することができます この機能では 実際にインデックスにイベントを書き込まずに 結果となるイベントをプレビューすることができます また データのプレビュー機能を使って タイムスタンプとイベント分割設定を対話形式で編集し 変更内容を新たなソースタイプとして保存することもできます データプレビュー機能をソースタイプエディタとして活 する 法については データプレビューとソースタイプ を参照してください ソースタイプのサーチ sourcetype は ソースタイプサーチフィールド名です sourcetype フィールドを使って 任意のソースタイプからの類似のデータタイプを探すことができます たとえば sourcetype=weblogic_stdout をサーチして WebLogic が複数のドメイン (Splunk の 語では ホスト ) からログを記録している場合でも すべての WebLogic サーバーイベントを探すことができます Splunk によるソースタイプの割り当て 法 123

124 Splunk には インデックス時にイベントデータにソースタイプを割り当てるためのさまざまな 法が 意されています イベントデータの処理時には 定義されている優先順位に従ってこれらの 法が適 されます まず inputs.conf および props.conf 内のハードコード化されたソースタイプ設定から始めて ルールベースのソースタイプ関連付けに移 し 次に 動ソースタイプ認識や 動ソースタイプ学習などの 法を利 します 複数の 法を順次利 することで Splunk が特定の種類のイベントにソースタイプ値を適 する 法を設定する で 他のイベントにはソースタイプ値を 動的に設定することができます Splunk が データ のソースタイプを決定するための処理 法を以下のリストに します Splunk は最初の 法から開始して ソースタイプを判断できるまで 必要に応じてその他の 法を試していきます このリストでは 各レベルでのソースタイプ割り当ての設定 法の概要も説明されています 1. データ に基づく明 的なソースタイプ指定 データ に対する明 的なソースタイプが つかった場合は ここで処理が中 されます これは inputs.conf または Splunk Web で設定します ファイル にソースタイプを割り当てるための inputs.conf 構 を以下に します [monitor://<path>] sourcetype=<sourcetype> Splunk Web で の定義時に ソースタイプを割り当てることもできます このファイル に対する作業については このマニュアルの Splunk Web の使 を参照してください このプロセスは ネットワークや他の のプロセスと似ています 詳細は のソースタイプの指定 を参照してください 2. データソースに基づく明 的なソースタイプ指定 特定のソースに対する明 的なソースタイプが つかった場合は ここで処理が中 されます これは 以下の構 を使って 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 はファイルまたはネットワーク ストリームの最初の数千 から パターン の署名を算出します これらの署名は 繰り返される単語パターン 句読点パターン の さなどを識別します Splunk が署名を算出する際に 既知の事前定義されている 連のソースタイプと 較が われます 致する項 があった場合は そのソースタイプがデータに割り当てられます Splunk が最初から認識できるソースタイプの 覧については このマニュアルの 事前定義ソースタイプの 覧 を参照してください 5. 遅延型ルールベースのソースタイプ関連付け ここまでにソースタイプが特定できなかった場合 遅延型ルールが参照されます これは ルールベースの関連付け ( 前述のステップ 3) と同じように機能します props.conf に delayedrule:: スタンザを作成します これは Splunk が前述の照合で何も分からなかった場合に役 つ 汎 型のルールになります 遅延型ルール関連付けは 前述のステップ 3 で rule:: を使って定義したソースタイプの汎 版として使 します たとえば rule:: を使って sendmail syslog や cisco syslog などの特定の syslog ソースタイプからイベントデータを取得して 次に delayedrule:: で汎 型の syslog ソースタイプを残りの syslog イベントデータに適 します 構 を以下に します 124

125 [delayedrule::$rule_name] sourcetype=$sourcetype MORE_THAN_[0-100] = $REGEX LESS_THAN_[0-100] = $REGEX ソースタイプ認識の遅延型ルールの設定と削除の詳細は ルールベースのソースタイプ認識の設定 を参照してください 6. ソースタイプの 動学習 ここまでの 法でイベントにソースタイプを割り当てることができなかった場合 イベント署名 の新しいソースタイプが作成されます ( 前述のステップ 4 を参照 ) Splunk は 学習パターン情報を sourcetypes.conf に保存します 動ソースタイプ割り当てに優先する設定 Splunk はデータへのソースタイプの 動割り当てを試みます 通常は適切なソースタイプが割り当てられますが 分で明 的に割り当てるソースタイプを指定することもできます データ またはデータソースに基づいて ソースタイプを割り当てるように設定することができます データへのソースタイプ割り当てルールの優先順位については Splunk によるソースタイプの割り当て 法 を参照してください 注意 : 優先設定は それが設定された後に取り込んだデータにのみ適 されます すでにインデックスが作成されたイベントのソースタイプを修正するには 代わりにソースタイプのタグを設定してください ここでは データに関する以下の事項に基づいた ソースタイプの指定 法を説明していきます ソース のソースタイプの指定 /var/log/ などの 特定の から取り込まれたデータのソースタイプを明 的に割り当てることができます この作業は Splunk Web または inputs.conf 設定ファイルを使って います 注意 : によるソースタイプの割り当ては 軽な 法に えますが きめ細かく調整することはできません この 法では ある からのすべてのデータに同じソースタイプが割り当てられてしまいます ( 部のデータが別のソースやホストから取り込まれる場合でも ) より対象を絞り込み ソースタイプの 動割り当てをバイパスするには このトピックの後半で説明しているように データのソースに基づいてソースタイプを割り当てます Splunk Web の使 [ システム ] でデータ を定義する場合 その から取り込まれるすべてのデータに適 する ソースタイプ値を設定することができます [ システム ] では リストからソースタイプを選択したり 独 のソースタイプ値を したりすることができます のソースタイプを選択するには [ システム ] から 的のデータ の設定を探します ファイル の場合の例を以下に します 1. Splunk Web の左上にある [ システム ] をクリックします 2. [ システム ] ポップアップの [ データ ] セクションで [ データ ] をクリックします 3. [ ファイルとディレクトリ ] をクリックします 4. [ 新規 ] ボタンをクリックして を追加します 5. [ その他の設定 ] ボックスを選択します 6. [ ソースタイプ ] には ソースタイプを設定するための 3 種類の選択肢があります 動 : このデフォルト設定では データのソースタイプが 動的に選択されます リストから : 般的な事前定義ソースタイプのリストが表 されます このオプションの詳細は 次のセクションを参照してください マニュアル : ドロップダウンリストに 的のソースタイプがないけれども Splunk の事前定義ソースタイプには含まれている場合は その値を 動で することができます また 独 のソースタイプを 動で することもできます このオプションの詳細は後述しています ドロップダウンリストからのソースタイプの選択 Splunk の 般的な事前定義ソースタイプかのリストから ソースタイプを選択することができます 125

126 1. [ ソースタイプを設定 ] ドロップダウンリストから [ リストから ] を選択します 2. 表 された [ リストからソースタイプを選択 ] ドロップダウンリストから ソースタイプを選択します 3. の設定を保存します その から取り込まれ インデックスが作成されるすべてのイベントに対して 選択したソースタイプが割り当てられるようになります 注意 : ドロップダウンリストには 般的なソースタイプのみが表 されます 利 可能なすべての事前定義されたソースタイプについては 事前定義ソースタイプの 覧 を参照してください ソースタイプの 動 特定の から取り込まれるデータに対するソースタイプを 動で することができます 1. [ ソースタイプを設定 ] ドロップダウンリストから [ マニュアル ] を選択します 2. 表 された [ ソースタイプ ] フィールドに ソースタイプを します Splunk の事前定義ソースタイプまたは独 のソースタイプを指定できます 3. の設定を保存します その から取り込まれ インデックスが作成されるすべてのイベントに対して 指定したソースタイプが割り当てられるようになります inputs.conf 設定ファイルを使 inputs.conf に を設定する場合 その のソースタイプを指定することができます $SPLUNK_HOME/etc/system/local/ 内 または $SPLUNK_HOME/etc/apps/ の独 のカスタムアプリケーションディレクトリ内にある inputs.conf を編集してください 設定ファイルの 般情報については 管理マニュアル の 設定ファイルについて を参照してください ソースタイプを指定するには のスタンザ内に sourcetype 属性を設定します 例 : [tcp://:9995] connection_host=dns sourcetype=log4j source=tcp:9995 この例では ポート 9995 の TCP から取り込まれる 任意のイベントに対してソースタイプ log4j が設定されます 警告 : 属性値は引 符で囲まないでください sourcetype="log4j" ではなく sourcetype=log4j のように指定します ソースのソースタイプの指定 ソースタイプの 動割り当てに優先して 特定のソースから取り込まれるすべてのデータに対して 単 のソースタイプを明 的に割り当てるには props.conf を使 します $SPLUNK_HOME/etc/system/local/ 内 または $SPLUNK_HOME/etc/apps/ の独 のカスタムアプリケーションディレクトリ内にある props.conf を編集してください 設定ファイルの 般情報については 設定ファイルについて を参照してください 重要 : データを転送している場合に ソースのソースタイプを割り当てるには この作業をフォワーダー上の 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 126

127 ファイルとして処理してしまいます 以下のように指定することをお勧めします [source::/home/fflanda/...log(.\d+)?] sourcetype=mytype 注意 : 正規表現の構 と使 法の概要については Regular-Expressions.info を参照してください 正規表現をテストするには rex サーチコマンドのを使 します 正規表現式を作成 テストするために役 つサードパーティ製ツールのリストも 意されています ルールベースのソースタイプ認識の設定 ルールベースのソースタイプ認識を使って Splunk が認識するソースタイプの種類を増やすことができます props.conf に 特定のソースタイプと 連の基準を関連付ける rule:: スタンザを作成します データの取り込み時に ルールの基準を満たすファイル に 指定したソースタイプが割り当てられます props.conf には ルールと遅延型ルールの 2 種類のルールを作成することができます これらのルールの違いは ソースタイプ処理プロセス中に Splunk がそれを確認する時期のみです 取り込まれたデータセットの処理時に Splunk はさまざまな 法でソースタイプを決定します データ またはソースに基づいて明 的なソースタイプ定義を確認後 props.conf に定義されている任意の rule:: スタンザを参照し それらのスタンザに定義されている分類ルールに基づいて データのソースタイプの特定が試みられます rule:: スタンザを参照しても 致するソースタイプがない場合 過去に学習したソースタイプと類似のパターンを識別する ソースタイプの 動認識が試みられます それでも特定できない場合は props.conf 内の delayedrule:: スタンザを参照して それらのスタンザ内に定義されているルールを使って データのソースタイプの判断を試みます データへのソースタイプ割り当てルールの優先順位については Splunk によるソースタイプの割り当て 法 を参照してください rule:: スタンザに特別なソースタイプ の分類ルールを指定し また delayedrule:: スタンザには汎 ソースタイプ向けの分類ルールを指定することができます このように 専 のソースタイプに当てはまらない各種イベントには 汎 のソースタイプが適 されます たとえば 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> MORE_THAN および LESS_THAN 属性には数値を設定します これは 正規表現に指定された 字列を含む の割合 ( パーセント ) を表しています たとえば MORE_THAN_80 は 最低でも の 80% が正規表現に 致する 字列を含む必要があることを表しています LESS_THAN_20 は 正規表現に 致する 字列が の 20% 以下でなければならないことを意味しています 注意 : 属性名は MORE_THAN_ となっていますが 実際にはこの属性は を超える ではなく 以上 の意味を持っています 同様に LESS_THAN_ 属性は 以下 の意味で使 します ルールには 任意の数の MORE_THAN および LESS_THAN 条件を指定することができます データファイルがルール内のすべてのステートメントに合致する場合にのみ そのルールのソースタイプが割り当てられます たとえば の 60% 以上がある正規表現に 致し 別の正規表現に 致する が 20% 以下の場合にのみ ファイル にそのソースタイプを割り当てるルールを定義することができます 注意 : 正規表現の構 と使 法の概要については Regular-Expressions.info を参照してください 正規表現をテストするには rex サーチコマンドのを使 します 正規表現式を作成 テストするために役 つサードパーティ製ツールのリストも 意されています 127

128 例 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 には 多数のソースタイプ定義が最初から 意されています これらのソースタイプは 事前定義ソースタイプと呼ばれています Splunk は取り込んだデータの 半に これらの事前定義ソースタイプを 動的に認識して割り当てることができます また 動的には認識できないけれども Splunk Web または inputs.conf を使って 動で割り当てられる事前定義ソースタイプも 意されています ( 動ソースタイプ割り当てに優先する設定 など この章の各トピックを参照 ) 事前定義ソースタイプが 的のデータに適合する場合は それを使 することをお勧めします Splunk は 事前定義ソースタイプのデータに対して インデックスを適切に作成する 法を理解しています ただし データが事前定義ソースタイプに適していない場合は 独 のソースタイプを作成することができます ( ソースタイプの作成 を参照 ) Splunk は 独 のプロパティがない場合でも 実質的に任意の形式のデータのインデックスを作成することができます ソースタイプの概要については ソースタイプが重要な理由 を参照してください 動認識されるソースタイプ ソースタイプ名起源例 access_combined access_combined_wcookie access_common apache_error asterisk_cdr asterisk_event asterisk_messages NCSA 連結フォーマット http Web サーバーログ (Apache や他の Web サーバーが 成可能 ) NCSA 連結フォーマット http Web サーバーログ (Apache や他の Web サーバーが 成可能 ) 最後に cookie フィールドを追加 NCSA 共通フォーマット httpweb サーバーログ (Apache や他の Web サーバーが 成可能 ) 標準 Apache Web サーバーログ 標準 Asterisk IP PBX コール詳細レコード 標準 Asterisk イベントログ ( 管理イベント ) 標準 Asterisk メッセージログ ( エラーと警告 ) webdev [08/Aug/2005:13:18: ] "GET / HTTP/1.0" "-" "check_http/1.10 (nagios-plugins 1.4)" " " [19/Aug/2005:10:04: ] "GET /themes/splunk_com/images/logo_splunk.png HTTP/1.1" " "Mozilla/5.0 (X11; U; Linux i686; en-us; rv:1.7.8) Gecko/ Fedora/ Firefox/1.0.4" " " [16/May/2005:15:01: ] "GET /themes/combeta/images/bullet.png HTTP/1.1" [Sun Aug 7 12:17: ] [error] [client ] File does not exist: /home/reba/public_html/images/bullet_image.gif ""," ","1234","default","""James Jesse""< >","SIP/5249-1ce3","","Voic ","u1234"," :19:25"," :19:25"," :19:42",17,17,"ANSWERED","DOCUMENTATION" Aug 24 14:08:05 asterisk[14287]: Manager 'randy' logged on from Aug 24 14:48:27 WARNING[14287]: Channel 'Zap/1-1' sent into invalid extension 's' in context 'default', but no invalid handler

129 asterisk_queue 標準 Asterisk キューログ NONE NONE NONE CONFIGRELOAD cisco_syslog db2_diag exim_main exim_reject linux_messages_syslog linux_secure log4j mysqld_error mysqld postfix_syslog sendmail_syslog sugarcrm_log4php weblogic_stdout PIX ファイアウォール ルーター ACS などを含めて すべての Cisco ネットワークデバイスが 成する標準 Cisco syslog 通常はリモート syslog 経由で集中ログホストに送信される 標準 IBM DB2 データベース管理およびエラーログ Exim MTA メインログ Exim 拒否ログ 標準 Linux syslog ( 半のプラットフォームで /var/log/messages) Linux securelog log4j を使 する任意の J2EE サーバーが 成する log4j 標準出 標準 mysql エラーログ 標準 mysql クエリーログ テキスト変換した mysql のバイナリログにも対応 UNIX/Linux syslog 経由で報告される標準 Postfix MTA ログ UNIX/Linux syslog 経由で報告される標準 Sendmail MTA ログ log4php ユーティリティを使って報告される 標準 Sugarcrm アクティビティログ 標準のネイティブ BEA 形式の Weblogic サーバーログ Websphere アクティビティログ 129 Sep 14 10:51:11 stage-test.splunk.com Aug :08:49: %PIX : Inbound TCP connection denied from IP_addr/port to IP_addr/port flags TCP_flags on interface int_name Inbound TCP connection denied from /9876 to /6161 flags SYN on interface outside I27231H328 LEVEL: Event PID : 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 :02:43 1E69KN-0001u6-8E => support-notifications@splunk.com R=send_to_relay T=remote_smtp H=mail.int.splunk.com [ ] :24:57 SMTP protocol violation: synchronization error (input sent without waiting for greeting): rejected connection from H=gate.int.splunk.com [ ] 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: port ssh :44:03, [PoolThread- 0] INFO [STDOUT] got some property :19:29 InnoDB: Started; log sequence number /usr/libexec/mysqld: ready for connections. Version: '4.1.10a-log' socket: '/var/lib/mysql/mysql.sock' port: 3306 Source distribution 53 Query SELECT xar_dd_itemid, xar_dd_propid, xar_dd_value FROM xar_dynamic_data WHERE xar_dd_propid IN (27) AND xar_dd_itemid = 2 Mar 1 00:01:43 avas postfix/smtpd[1822]: 0141A61A83: client=host pool80180.interbusiness.it[ ] Aug 6 04:03:32 nmrjl00 sendmail[5200]: q64f01vr001110: to=root, ctladdr=root (0/0), delay=00:00:01, xdelay=00:00:00, mailer=relay, min=00026, relay=[ ] [ ], dsn=2.0.0, stat=sent (v00f3hmx Message accepted for delivery) Fri Aug 5 12:39: ,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, :27:24 PM MDT> <Warning> <WebLogicServer> <bea03> <asiadminserver> <ListenThread.Default> <<WLS Kernel>> <> <BEA > <HostName: , maps to multiple IP addresses: , > ComponentId: Application Server ProcessId: 2580 ThreadId: c ThreadName: Nondeferrable Alarm : 3 SourceId: com.ibm.ws.channel.framework.impl. WSChannelFrameworkImpl ClassName: MethodName: Manufacturer: IBM Product: WebSphere Version:

130 websphere_activity websphere_core websphere_trlog_syserr websphere_trlog_sysout windows_snare_syslog サービスログと呼ばれることもあります Websphere からの Corefile エクスポート IBM のネイティブ tr 形式の標準 Websphere システムエラーログ IBM のネイティブ trlog 形式の標準 Websphere system out ログ Resin および Jboss の log4j サーバーログと似ていますが ( システムエラーログのサンプル形式 ) 重 度が低いイベントおよび情報通知イベントが含まれています サードパーティ製 Intersect Alliance Snare エージェント経由で UNIX/Linux サーバー上の syslog に報告される 標準 Windows イベントログ Platform 6.0 [BASE o ] ServerName: nd6cell01\was1node01\tradeserver1 TimeStamp: :04: UnitOfWork: Severity: 3 Category: AUDIT PrimaryMessage: CHFW0020I: The Transport Channel Service has stopped the Chain labeled SOAPAcceptorChain2 ExtendedMessage: NULL SECTION TITLE subcomponent dump routine NULL=============================== 1TISIGINFO signal 0 received 1TIDATETIME Date: 2005/08/02 at 10:19:24 1TIFILENAME Javacore filename: /kmbcc/javacore txt NULL SECTION XHPI subcomponent dump routine NULL ============================== 1XHTIME Tue Aug 2 10:19: XHSIGRECV SIGNONE received at 0x0 in <unknown>. Processing terminated. 1XHFULLVERSION J2RE IBM AIX build ca NULL [7/1/05 13:41:00:516 PDT] ae SystemErr R at com.ibm.ws.http.channel. inbound.impl.httpiclreadcallback.complete (HttpICLReadCallback.java(Compiled Code)) (truncated) [7/1/05 13:44:28:172 PDT] d SystemOut O 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: max: avg: The current price update is: Update Stock price for s:393 old price = new price = Sep 14 10:49:46 stagetest.splunk.com Windows_Host MSWinEventLog 0 Security 3030 Day Aug 24 00:16: Security admin4 User Success Audit Test_Host 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 130

131 サーバー データベース メール オペレーティングシステム ネットワーク プリンタ ルーターとファイアウォール VoIP Web サーバー その他 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 asterisk_cdr asterisk_event asterisk_messages asterisk_queue access_combined access_combined_wcookie access_common apache_error iis snort 事前定義ソースタイプの設定の表 Splunk がどのような設定情報を使って特定のソースタイプのインデックスを作成するのかを理解するために btool ユーティリティを使ってプロパティの 覧を参照することができます btool の使 法の詳細は Troubleshooting manual の Use btool to troubleshoot configurations を参照してください tcp ソースタイプの設定の表 例を以下に します $./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 = 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 = maxdist = 100 pulldown_type = true 131

132 イベント単位でのソースタイプに優先する設定 ここでは イベント単位にソースタイプに優先する設定を う 法を説明していきます この処理は Splunk によるソースタイプの割り当て 法 で説明しているように Splunk が初期割り当てを完了した後のパーシング時に います イベント単位の優先設定を うには 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 以下の事項に注意してください <unique_stanza_name> は 関連するソースタイプを反映する必要があります この名前は 後ほど props.conf スタンザで使 します <your_regex> は 独 のソースタイプを適 するイベントを表す正規表現です ( 特定のホスト名や他のフィールド値を持つイベントなど ) <your_custom_sourcetype_value> は 正規表現に 致したイベントに適 するソースタイプです 注意 : 正規表現の構 と使 法の概要については Regular-Expressions.info を参照してください 正規表現をテストするには rex サーチコマンドのを使 します 正規表現式を作成 テストするために役 つサードパーティ製ツールのリストも 意されています props.conf 次に props.conf に transforms.conf のスタンザを参照するスタンザを作成します [<spec>] TRANSFORMS-<class> = <unique_stanza_name> 以下の事項に注意してください <spec> には 以下の値を使 できます <sourcetype> イベントのソースタイプ host::<host> <host> はイベントのホストを表します source::<source> <source> はイベントのソース値を表します <class> は 変換に割り当てる任意で 意の識別 です <unique_stanza_name> は transforms.conf で作成したスタンザ名です 例 : 単 の から取り込まれた異なるホストを持つイベントへのソースタイプの割り当て 共有 UDP UDP514 がある場合を考えてみましょう Splunk インスタンスはこの を使って さまざまなホストからのデータのインデックスを作成します 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 132

133 この正規表現を 的のホスト名 ( この例では 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 設定ファイルを編集する データプレビューの使 データプレビュー機能を利 すれば データにソースタイプを適 した効果を 軽に参照し 必要に応じてソースタイプの設定を調整することができます 変更内容を新たなソースタイプとして保存して それをデータ に割り当てることができます データプレビュー機能には タイムスタンプやイベントの分割を調整するための 般的な種類の調整オプションが 意されています その他の変更を う場合は props.conf ファイルを直接編集します 設定を変更すると 即座にイベントデータの変化を確認することができます データプレビュー機能の詳細は このマニュアルの データのプレビュー を参照してください props.conf の編集 props.conf を編集して新しいスタンザを追加することで 新しいソースタイプを作成できます props.conf の詳細は 管理マニュアル の props.conf に関する記事を参照してください $SPLUNK_HOME/etc/system/local/ 内 または $SPLUNK_HOME/etc/apps/ の独 のカスタムアプリケーションディレクトリ内にある props.conf ファイルを編集します 設定ファイルの 般情報については 管理マニュアル の 設定ファイルについて を参照してください データプレビュー機能の [ 詳細モード ] タブから 新しいソースタイプの props.conf スタンザを直接作成することもできます 詳細は イベント処理の変更 の詳細モードに関するセクションを参照してください ソースタイプを作成する場合 サーチ可能イベントを作成するためのデータの処理 法を設定します 特に 2 つの重要な設定を指定する必要があります イベント改 :props.conf を使ったイベント分割の指定 法については イベントの 分割の設定 を参照してください タイムスタンプ :props.conf を使ったタイムスタンプの指定 法については タイムスタンプ認識の設定 およびこのマニュアルの タイムスタンプの設定 内の 他のトピックを参照してください その他のさまざまな設定を うこともできます 詳細は props.conf の仕様を参照してください ソースタイプ名の変更 状況によっては ソースタイプ名の変更が必要なこともあります たとえば に誤ったソースタイプ名を割り当ててしまった場合に ソースタイプ名の変更が必要になります また 2 つの異なる名前のソースタイプを サーチ時に同時に処理しなければならないこともあります props.conf 内で rename 属性を使って サーチ時に新しいソースタイプをイベントに割り当てることができます オリジナルのソースタイプでサーチする必要がない場合 そのソースタイプは _sourcetype に移動されます 注意 : インデックス作成されたイベントには 引き続きオリジナルのソースタイプが含まれます 名前の変更はサーチ時にのみ われます また ソースタイプ名を変更しても 最初に誤ったソースタイプを割り当てたことにより 成された イベントデータのインデックスフォーマットが修正される訳ではありません 133

134 ソースタイプ名を変更するには ソースタイプスタンザに rename 属性を追加します rename = <string> たとえば アプリケーションサーバーに対して ソースタイプ 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 のようなマイナーセグメント または のようなマイナーセグメントのグループに分割することができます イベントのセグメント分割の度合いを定義することができます インデックス時のセグメント分割は インデックス作成 / サーチ速度 ストレージサイズ および先 機能を使 できるかどうかに影響するため このことが重要になります サーチ時セグメント分割はサーチ速度 および Splunk Web に表 された結果から項 を選択してサーチを作成できるかどうかに影響します インデックス時 と サーチ時 の違いについては インデクサーとクラスタの管理 マニュアルの インデックス時とサーチ時 を参照してください props.conf で 特定のカテゴリのイベントに セグメント分割を割り当てることができます 詳細は イベントデータのセグメント分割の設定 を参照してください イベントのセグメント分割のタイプ インデックス時またはサーチ時に設定できる 主に 3 種類のセグメント分割タイプ ( レベル ) があります インナーセグメント分割は 細分可能なもっとも さなマイナーセグメントにまでイベントを分割します たとえば のような IP アドレスにインナーセグメント分割を うと および 223 に分割されます インデックス時にインナーセグメント分割を設定すると インデックス作成およびサーチ処理が 速化され ディスクの使 量が減少します ただし 先 機能は制限され ユーザーはマイナーセグメントレベルでのみ先 を えます アウターセグメント分割は インナーセグメント分割の反対です アウターでは メジャーセグメントのみインデックスが作成されます たとえば IP アドレス は としてインデックスが作成されます この場合 フレーズ内の個別の部分はサーチできません ただし ワイルドカードを使ってフレーズ内の 部をサーチすることは可能です たとえば 192.0* でサーチすると から始まる IP アドレスを持つ 任意のイベントを取得することができます また アウターセグメント分割では IP アドレスの の部分 ( セグメント ) などの サーチ結果内の個別のセグメントをクリックしてサーチを実 することはできません アウターセグメント分割は フルセグメント分割に べて少し効率性が い傾向がありますが インナーセグメント分割の が 幅に効率が くなります フルセグメント分割は インナーセグメント分割とアウターセグメント分割の組み合わせです フルセグメント分割の場合 IP アドレスはメジャーセグメントと や などの各種マイナーセグメントの両 に対して インデックスが作成されます このオプションは効率的がもっとも低くなりますが 多彩なサーチ機能を利 することができます これらのセグメント分割タイプは デフォルトでは $SPLUNK_HOME/etc/system/default にある segmenters.conf ファイルに定義されています デフォルトで インデックス時セグメント分割は indexing タイプ ( インナーセグメント分割とアウターセグメント分割の組み合わせ ) に設定されています サーチ時セグメント分割には フルセグメント分割が設定され 134

135 ています セグメント分割なし スペース効率がもっとも いセグメント分割設定が セグメント分割を完全に無効にすることです ただし これがサーチに与える影響は きくなります セグメント分割なしでインデックスを作成するように設定すると 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 では サーチ時にイベントをセグメント分割することもできます サーチ時セグメント分割は Splunk Web で設定できます Splunk Web でのサーチ時セグメント分割の設定 を参照してください 特定のホスト ソース またはソースタイプからのイベントの サーチまたは処理 法が分かっている場合 そのタイプのイベントにインデックス時セグメント分割を設定することができます 特定のタイプのイベントに サーチ時セグメント分割を設定することもできます 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> 135

136 [<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 でサーチ時に使 する セグメント分割タイプを します <segment_selection> には full inner outer または raw を使 できます これらの 4 つの値は Splunk Web のサーチ結果の上にある [ オプション ] から表 する [ 結果表 オプション ] パネルの [ イベントのセグメント化 ] ドロップダウンに表 するオプションです これらの値は 単純に Splunk Web のドロップダウンで利 できるオプションです この属性を使って オプションが実 する実際のセグメント分割タイプを指定することができます ( ドロップダウンに表 されるオプションとは違う名前のタイプにすることもできます ) たとえば 通常そうすることはありませんが inner ドロップダウンオプションを定義して outer セグメント分割タイプを実 することもできます ドロップダウンオプションを <seg_rule> にマップすることで 後ほどサーチ結果を参照する際に そのオプションを使ってサーチ時セグメント分割を設定することができます 詳細は Splunk Web でのサーチ時セグメント分割の設定 を参照してください <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 を再起動する必要があります 既存のデータにインデックス時セグメント分割の変更を適 するには データのインデックスを再作成する必要があります Splunk Web でのサーチ時セグメント分割の設定 Splunk Web では サーチ結果のセグメント分割を設定することができます インデックス時のセグメント分割には 何 136

137 の影響もありません Splunk Web のセグメント分割は ブラウザとの対話操作に影響し またサーチ結果を 速化することができます サーチ結果のセグメント分割を設定するには : 1. サーチを実 します 結果を参照します 2. 返されたイベントセットの上にある [ オプション...] をクリックします 3. [ イベントのセグメント化 ] ドロップダウンで 利 可能ないずれかのオプション (full inner outer または raw) を選択します デフォルトは full です これらのドロップダウンの意味を設定することができます 詳細は イベントデータのセグメント分割の設定 を参照してください Preview your data データプレビューの概要 Splunk Web のデータプレビュー機能は イベント処理を改善するための 強 な 段を提供しています この機能を使って データのインデックスが意図通りに作成されることを確認することができます データプレビュー機能では データのインデックスがどのように作成されるのかを確認し 必要に応じて設定を調整して 作成結果を改善することができます この機能はデータのサブセットに対して標準のインデックス作成プロセスを いますが 標準のインデックス作成処理とは違い 結果となるイベントデータがインデックスには保管されません データのプレビュー時には 対話形式でインデックス作成プロセスを調整 改善することができます そのため 後ほど実際にインデックス作成を った時には 的通りの形式のイベントデータが作成されます データプレビュー画 の例を以下に します データのプレビュー時 Splunk によるタイムスタンプ抽出とイベントの分割 法を調整することができます 満 のいく結果が得られたら 変更内容を新しいソースタイプとして保存します 次に それを実際のデータに適 してください 詳細は データプレビューとソースタイプ を参照してください データプレビュー機能は単 のファイルに対して実 できますが いくつかの事項を考慮して対処すれば ネットワークやディレクトリ からのデータをプレビューすることもできます 詳細は データの準備 を参照してください 注意 : データプレビュー機能は Splunk の App として実装されています Splunk に収録されており 起動時に有効になります データプレビューとソースタイプ 基本的にデータプレビューの 的は 取り込んだデータへの正しいソースタイプの適 を 援することです ソースタイプは Splunk が取り込んだすべてのデータに割り当てるデフォルトフィールドの 1 つです ソースタイプは インデックス作成時のデータのフォーマット 法を決定します データに正しいソースタイプを割り当てることで インデックスが作成されたデータ ( イベントデータ ) には 適切なタイムスタンプの設定とイベント分割が われ 期待通りのデータが 137

138 作成されます Splunk には 多数の事前定義されたソースタイプが 意されています たいていの場合は データの取り込み時にデータに正しいソースタイプが 動的に割り当てられ 適切にデータが処理されます 特殊なデータの場合 データに対して別の事前定義ソースタイプを 動で選択しなければならないこともあります また 独 のイベント処理を設定した 新たなソースタイプを作成しなければならないこともあります データプレビュー機能は データに正しいソースタイプを割り当てるために役 ちます 事前定義ソースタイプをデータに適 した結果を確認することができます また ソースタイプの設定を対話形式で変更して 的の結果が得られるまで設定を調整することもできます 作業が完了したら 変更内容を新たなソースタイプとして保存することができます データプレビュー機能を使って 以下のような作業を えます Splunk が 動的に割り当てるデフォルトのソースタイプを使った場合に データがどのようになるのかを確認する 別のソースタイプを適 して さらに良好な結果が得られるかどうかを確認する タイムスタンプ 成またはイベント分割の設定を変更して インデックスデータの品質を向上し 変更内容を新しいソースタイプとして保存する 新たなソースタイプを最初から作成する データプレビュー機能は 新しいソースタイプを props.conf ファイルに保存します 後ほどこのファイルをデプロイ環境内の各インデクサーに配布することで 全体的にそのソースタイプを利 することができます 詳細は データプレビューと分散 Splunk を参照してください ソースタイプの詳細は このマニュアルの ソースタイプが重要な理由 を参照してください また イベント処理の設定 タイムスタンプの設定 および ソースタイプの設定 内の各トピックにも ソースタイプの処理に関する詳細な情報が記述されています データの準備 データプレビューは単 のファイルに対してのみ実 できます 直接ネットワークデータやディレクトリを処理することはできませんが この問題には簡単に対処することができます 注意 : データプレビュー機能は Splunk が動作しているローカルマシンのファイルにしかアクセスできません ネットワークデータのプレビュー サンプルネットワークデータをファイルに書き込んで そのファイルを使ってデータのプレビューを えます この 的で利 できるさまざまな外部ツールがあります たとえば *nix 系では netcat を利 することができます たとえば ポート 514 で UDP データを待機している場合 netcat を使ってネットワークデータの 部をファイルに書き込むことができます nc -lu 514 > sample_network_data データプレビュー機能は ファイルの最初の 2MB のデータのみを読み込みます そこで ファイルサイズが 2MB に達したら netcat を kill するロジックを組み込んで シェルスクリプト内でこのコマンドを実 すると便利です サンプルの sample_network_data ファイルを作成したら それを使っデータのプレビューを えます ファイル内のデータのプレビューを って 必要な変更をイベント処理に反映させたら そのソースタイプを直接ネットワークデータに適 することができます ディレクトリ内の複数ファイルのプレビュー ディレクトリ内のすべてのファイルが同じような内容のデータを保有している場合 どれか 1 つのファイルでデータのプレビューを えば そのディレクトリ内のすべてのファイルに対してほぼ満 がいく結果を得ることができます ただし ディレクトリにさまざまな形式や環境のデータファイルが混在している場合は データが異なる各ファイルを選んで個別にプレビューする必要があります ファイルサイズの制限 データプレビュー機能は ファイル内の最初の 2MB のデータを読み込みます たいていの場合は これで 分なデータ標本を得ることができます より きなサイズのデータ標本が必要な場合は limits.conf を編集して max_preview_bytes 属性の値を変更します または ファイルを編集して 2MB のデータ内に元のファイル内のすべてのタイプのデータが収まるように 類似データが多いデータの量を減らします イベントデータの表 ヘルプのリンクからこのページに移動した へ... このトピックは データプレビューを使 するための初期ステップ ( データプレビュー機能がファイルを処理する時点まで ) を説明しています 結果の調整 法について学習したい場合は イベント処理の変更 を参照してください Splunk Web でファイル の作成を開始した場合 そこでデータプレビュー機能を利 することができます Splunk 138

139 Web の [ ファイルとディレクトリ ] ページから新しい を追加した場合 ここで説明しているように Splunk Web にはファイルをプレビューするためのオプションが表 されます この画 で プレビューするファイルを指定したり またはデータのプレビューをスキップして 直接 [ ファイルとディレクトリ ] ページに移動したりできます プレビューするファイルの指定 [ ファイルとディレクトリ ] では プレビューするファイルを選択するダイアログが表 されます 1. [ インデックス作成前にデータをプレビュー ] ラジオボタンを選択します 2. [ ファイルへのパス ] フィールドにファイル名を します ファイルは Splunk が動作しているマシン上の ローカルファイルでなければなりません 3. [ 続 ] ボタンを選択します ソースタイプ選択ダイアログが表 されます 注意 : If you don't want to preview your data, select the radio button, Skip: don't preview. ソースタイプの選択 ファイル名を指定したら ファイルのソースタイプの選択 法を指定するダイアログが表 されます 以下の項 を選択することができます 動検出されたソースタイプを使 : たいていの場合 Splunk がデータを認識して適切なソースタイプを判断することができます このダイアログには Splunk が 動検出したソースタイプが表 され そのソースタイプを使ってデータをプレビューするかどうかを選択することができます ソースタイプを 動検出できなかった場合はその旨を知らせるメッセージが表 され 残りの 2 つのいずれかのオプションを選択することができます 新しいソースタイプの開始 : 新たなソースタイプを最初から作成することができます 既存のソースタイプの適 : ドロップダウンリストから 事前定義されているソースタイプを選択することができます 適切な項 を選択して [ 続 ] をクリックします [ データのプレビュー ] ページが表 されます このページでは ソースタイプの適 結果を参照し 必要に応じてソースタイプを変更することができます [ データのプレビュー ] ページ ファイルとソースタイプの指定後に表 される [ データのプレビュー ] ページの例を以下に します このページには ファイルからのデータを Splunk がイベントに変換した結果が表 されています この変換 ( フォーマット ) は 先ほど選択したソースタイプに基づいています 緑 で強調表 されている項 は Splunk がタイムスタンプの作成に使 した raw データを表しています 抽出されたタイムスタンプ 体は イベントの左の列に指定されています の先頭に黄 の警告アイコンが表 されている場合 その上にマウスカーソルを移動すると その のイベントのパーシングに関する問題の詳細が表 されます 139

140 イベントリストの右側には データに関するいくつかのサマリー情報が記載されています パスとファイルの合計バイト数などのファイルのプロパティ 抽出されたイベント数などのプレビュープロパティ イベントの時間分布を すグラフ カウントによるイベントの分布 次のステップ このページでレビューを ったら 2 種類の作業を うことができます これらのオプションは ページの上部から利 することができます イベントの処理結果が良好な場合は [ 続 ] を選択します 実際のファイルを指定して データプレビューで選択したソースタイプを適 することができるページが表 されます イベントのフォーマット 法を調整したい場合は [ タイムスタンプおよびイベント改 設定を調整します ] を選択します 各種イベント処理設定を変更して 新しいソースタイプを作成するためのページが表 されます イベント処理の変更 法については 次のトピック イベント処理の変更 を参照してください また 他のファイルをプレビューすることもできます その場合は ページの下部から [ 新規ファイルを選択 ] を選択します イベント処理の変更 Splunk によるデータの処理結果 ( イベントデータの表 を参照 ) に満 できない場合は データプレビュー機能を使ってイベント処理設定を変更し その設定を新しいソースタイプとして保存することができます 主な 順を以下に します 1. イベントデータを表 します 詳細は イベントデータの表 を参照してください 2. イベント処理設定を変更します 3. 変更による影響を確認し 満 のいく結果が得られるまで 調整を繰り返します 4. 設定を新しいソースタイプとして保存します 新しいソースタイプは 任意の に適 することができます イベント処理設定の変更 [ データのプレビュー ] ページで [ タイムスタンプおよびイベント改 設定を調整します ] を選択した場合 以下のようなページが表 されます ページの上部には 3 種類の調整作業を うためのタブとリンクがあります イベント改 :Splunk がデータをイベントに分割する 法を調整します 140

141 タイムスタンプ :Splunk がイベントのタイムスタンプを決定する 法を調整します 詳細モード :props.conf を直接編集します イベント改 [ イベント改 ] を選択した場合 以下の項 を選択することができます 動 ( タイムスタンプで改 ) 各 が 1 つのイベントになります改 の直前にあるパターンまたは正規表現を指定してください - テキストフィールドに正規表現を指定します イベント分割 ( 改 ) の詳細は イベントの 分割の設定 を参照してください 正規表現の構 と使 法の概要については Regular-Expressions.info を参照してください 正規表現をテストするには サーチコマンドの rex を使 します 正規表現式を作成 テストするために役 つサードパーティ製ツールのリストも 意されています タイムスタンプ [ タイムスタンプ ] を選択した場合は 2 種類の選択肢があります [ 場所 ] では 以下のいずれかのオプションを選択することができます タイムスタンプを 動検出タイムスタンプ直前のパターンを指定 - 分でパターンを指定しますタイムスタンプは < 数字 > 字以内のイベント 字列に含まれる [ フォーマット ] では 以下の任意のオプションを選択することができます 何も選択しないことも可能です タイムスタンプのフォーマットを指定 (strptime) タイムゾーンを指定 重要 :[ フォーマット ] でタイムスタンプのフォーマットを指定し タイムスタンプが各イベントの開始点付近に存在していない場合は [ 場所 ] セクションで [ タイムスタンプ直前のパターンを指定 ] フィールドにプリフィックス ( 直前のパターン ) を指定する必要があります そうしないと Splunk はフォーマット処理を えず 各イベントには strptime を使 できない旨の警告が含まれます ( それでも Splunk が問題にどのように対処するのかによっては 有効なタイムスタンプが得られる可能性があります ) タイムスタンプ設定の詳細は タイムスタンプの設定 を参照してください 詳細モード [ 詳細モード ] を選択した場合 props.conf ファイルを直接編集してソースタイプのプロパティを指定できるページが表 されます [ 詳細モード ] には 2 つのテキストボックスがあります その他の設定 : ここでは 属性と値のペアを指定することで ソースタイプのプロパティを追加または変更することができます これらのプロパティの設定 法の詳細は props.conf を参照してください 現在適 されている設定 : このボックスは 編集しているソースタイプの 現在の完全なプロパティセットが表 されています これには 以下の情報が含まれています [ イベント改 ] または [ タイムスタンプ ] タブで われた変更により 成された設定 ([ 適 ] ボタンをクリックした後 ) 最初にデータプレビュー機能にファイルを取り込んだ時に 動検出された または 動で選択したソースタイプの既存の設定 [ その他の設定 ] テキストボックスから適 した任意の設定 ([ 適 ] ボタンをクリックした後 ) ソースタイプのプロパティの設定 法の詳細は Configuration file reference の props.conf に関するトピックを参照してください また タイムスタンプ設定およびイベントの 分割に関するトピックも参照してください 141