Splunk Enterprise 6.2.0 データの転送

Splunk Enterprise 6.2.0
データの転送
作成：2014 年 11 ⽉ 21 ⽇ 午後 4 時 11 分
Copyright (c) 2015 Splunk Inc. All Rights Reserved
Table of Contents
概要
転送と受信について
フォワーダーのタイプ
フォワーダーのデプロイトポロジー
4
4
4
6
転送の設定
転送と受信の設定
フォワーダーとインデクサー間の互換性
レシーバーを有効にする
複数のマシンからのデータの統合
ロードバランシングの設定
10
10
11
12
14
15
ユニバーサルフォワーダー
ユニバーサルフォワーダーの紹介
デプロイの概要
サポートしている CLI コマンド
ユニバーサル・フォワーダーのインストール⽅法
17
18
18
21
22
Wi ndows ユニバーサルフォワーダーのデプロイ
22
インストーラ GUI を使った Windows ユニバーサルフォワーダーの 22
デプロイ
コマンドラインを使った Windows ユニバーサルフォワーダーのデ 29
プロイ
静的設定を使った Windows ユニバーサルフォワーダーのリモート 34
デプロイ
ユニバーサルフォワーダーをシステムイメージの⼀部にする
35
Windows ライトフォワーダーの移⾏
36
ni x ユニバーサルフォワーダーのデプロイ
37
*nix ユニバーサルフォワーダーの⼿動デプロイ
37
静的設定を使った *nix ユニバーサルフォワーダーのリモートデプロ 40
イ
ユニバーサルフォワーダーをシステムイメージの⼀部にする
44
*nix ライトフォワーダーの移⾏
45
フォワーダーのアップグレード
Windows ユニバーサルフォワーダーのアップグレード
*nix システムのユニバーサルフォワーダーのアップグレード
45
46
47
詳細設定
outputs.conf によるフォワーダーの設定
転送データ損失の保護
データのルーティングとフィルタリング
サードパーティ製システムへのデータの転送
49
49
53
56
64
ヘビーフォワーダーとライトフォワーダー
ヘビーフォワーダーのデプロイ
ライトフォワーダーのデプロイ
ヘビーフォワーダーとライトフォワーダーの機能
67
67
68
70
転送のトラブルシューティング
フォワーダー/レシーバー接続のトラブルシューティング
71
71
概要
転送と受信について
重要： このマニュアルをお読みになる前に、『分散デプロイ』マニュアルを参照して、Splunk Enterprise 分散
デプロイ環境の基礎を学習してください。
ある Splunk Enterprise インスタンスから別の Splunk Enterprise インスタンスや Splunk 以外のシステムに、
データを転送することができます。⼀般的に、転送 を担当する Splunk Enterprise インスタンスは、フォワー
ダー と呼ばれる⼩型軽量版の Splunk Enterprise です。
1 つまたは複数のフォワーダーからデータを受信 する Splunk Enterprise インスタンスは、レシーバー と呼ばれ
ています。通常レシーバーは、Splunk Enterprise インデクサー ですが、こちらで説明しているように他のフォ
ワーダーであることも可能です。
以下の図は、3 台のフォワーダーが単⼀のレシーバー (インデクサー) にデータを送信し、受け取ったデータを
サーチに利⽤できるように、インデクサーがインデックスを作成する概要を表しています。
フォワーダーは以下の機能により、ネットワークから raw データを供給するよりも、⼤幅に堅牢なソリューショ
ンを実現しています。
メタデータのタグ設定 (ソース、ソースタイプ、ホスト)
設定可能なバッファ
データ圧縮
SSL セキュリティ
利⽤可能な任意のネットワークポートの使⽤
転送/受信機能により、データの統合 、ロードバランシング 、およびデータのルーティング などの⽬的に対処す
るための、さまざまな種類の Splunk Enterprise トポロジーを利⽤することができます。フォワーダーを使って
作成できるデプロイトポロジーの種類については、「フォワーダーのデプロイトポロジー」を参照してください。
フォワーダーには、いくつかの異なるタイプが存在しています。「フォワーダーのタイプ」を参照してください。
フォワーダーのタイプ
3 種類のフォワーダーが⽤意されています。
ユニバーサルフォワーダー は、スリム化された専⽤版の Splunk Enterprise で、レシーバーにデータを転
送するために必要な基本コンポーネントのみが含まれています。
ヘビーフォワーダー は完全版の Splunk Enterprise インスタンスで、軽量化するために⼀部の機能が無効
になっています。
ライトフォワーダー は完全版の Splunk Enterprise インスタンスで、⼤幅な軽量化を実現するために、ほ
ぼすべての機能が無効になっています。ユニバーサルフォワーダーは⼩型軽量ながらライトフォワー
ダーと同様の機能を提供しているため、ほぼすべての⽬的においてユニバーサルフォワーダーの⽅が
4
利⽤に適しています。
注意： ライトフォワーダーは Splunk Enterprise 6.0 で廃⽌予定で、⾮推奨となりました。⾮推奨で廃⽌予定の
機能の⼀覧は、リリースノートの「⾮推奨 (廃⽌予定) の機能」を参照してください。
ほぼすべての観点から、インデクサーへのデータ転送にはユニバーサルフォワーダーが適していると⾔うことがで
きます。これの主な制限事項としては、後述するようにユニバーサルフォワーダーは、パーシングされていない
データのみを転送することが挙げられます。そのため、イベントのコンテンツに基づいてデータをルーティングす
ることはできません。それが⽬的の場合は、ヘビーフォワーダーを使⽤する必要があります。また、ユニバーサル
フォワーダーでローカルにデータのインデックスを作成することはできません。インデックスを作成してから転送
できるのは、ヘビーフォワーダーのみです。
ユニバーサルフォワーダー
ユニバーサルフォワーダーは、Splunk の軽量版フォワーダーです。これを使ってさまざまな⼊⼒からデータを収
集し、それをインデックス作成とサーチのために Splunk Enterprise サーバーに転送します。また、インデク
サーに直接データを送信する代わりに、中継地点として他のフォワーダーにデータを転送することもできます。
ユニバーサルフォワーダーの唯⼀の⽬的は、データを転送することにあります。完全版の Splunk Enterprise イ
ンスタンスと違い、ユニバーサル・フォワーダーを使ってインデックスの作成やサーチの実⾏はできません。⾼い
パフォーマンスと⼩型軽量化を実現するために、ユニバーサルフォワーダーにはいくつかの制限があります。
ユニバーサルフォワーダーには、サーチ、インデックス作成、またはアラート機能はありません。
ユニバーサルフォワーダーは、データのパーシング を⾏いません。
完全版の Splunk Enterprise と違い、ユニバーサルフォワーダーには Python のバンドル版は含まれていま
せん。
ユニバーサルフォワーダーの機能の詳細は、「ユニバーサルフォワーダーの紹介」を参照してください。
注意： ユニバーサルフォワーダーは、個別にダウンロードできるソフトウェアです。ヘビーフォワーダーやライ
トフォワーダーと違い、完全版の Splunk Enterprise インスタンスから有効にすることはできません。ユニバー
サルフォワーダーのダウンロード、インストール、およびデプロイ⽅法については、「ユニバーサルフォワーダー
のデプロイの概要」を参照してください。
ヘビーフォワーダーとライトフォワーダー
⼀般的には、データの転送にユニバーサルフォワーダーを利⽤することをお勧めしますが、必要に応じて (古いシ
ステムを利⽤しているなど) ヘビーフォワーダーやライトフォワーダーを使⽤することもできます。個別の効率化
された実⾏形式ファイルであるユニバーサルフォワーダーとは違い、ヘビー/ライトフォワーダーは完全版の
Splunk Enterprise インスタンスから、特定の機能を無効にしたものです。ヘビーフォワーダーとライトフォワー
ダーは、その機能と占有サイズが異なります。
ヘビーフォワーダー (「通常のフォワーダー」と呼ばれることもあります) は、Splunk Enterprise インデクサー
と⽐べて占有サイズは⼩さいですが、分散サーチ機能を利⽤できないことを除き、ほぼすべての機能を保持してい
ます。占有サイズを減らすために、Splunk Web などのデフォルト機能の⼤半を、必要に応じて無効にすること
ができます。ヘビーフォワーダーは、データの転送前にパーシングを⾏うため、イベントのソースやタイプなどの
基準に基づいて、データをルーティングすることができます。
ヘビーフォワーダーの主な利点として、データのインデックスをローカルに作成しながら、他の Splunk
Enterprise インスタンスにデータを転送できる点が挙げられます。この機能はデフォルトでは無効になっている
ため、利⽤する場合は機能を有効にする必要があります 。詳細は、このマニュアルの「outputs.conf による
フォワーダーの設定」を参照してください。
ライトフォワーダー は、占有サイズがより⼩さく、利⽤できる機能も⼤幅に限定されています。これは、パーシ
ングされていないデータのみを転送します。4.2 からは、同様の機能をより⼩さな占有サイズで利⽤できる、ユニ
バーサルフォワーダーが提供されており、そちらを利⽤することをお勧めしています。ライトフォワーダーは、主
に古いシステムのニーズを満たすことを⽬的に提供されています。パーシングされていないデータの転送には、ユ
ニバーサルフォワーダーを使⽤することをお勧めします。ユニバーサルフォワーダーをインストールする場合、イ
ンストーラにはマシンに常駐している任意のライトフォワーダー (バージョン 4.0 以降) から、チェックポイント
設定を移⾏するオプションが⽤意されています。ユニバーサルフォワーダーとライトフォワーダーの詳細な⽐較に
ついては、「ユニバーサルフォワーダーの紹介」を参照してください。
ヘビー/ライトフォワーダーの機能の詳細は、「ヘビー/ライトフォワーダーの機能」を参照してください。
ヘビー/ライトフォワーダーの有効化とデプロイについては、「ヘビー/ライトフォワーダーのデプロイ」を参照し
てください。
フォワーダーの⽐較
3 種類のフォワーダーの類似性と差異の概要を以下の表に⽰します。
機能と特徴
ユニバーサルフォワー
ダー
ライトフォワーダー
ヘビーフォワーダー
Splunk Enterprise インス 専⽤の実⾏形式ファイル
タンスのタイプ
完全版の Splunk
Enterprise で⼤半の機能
が無効化
完全版の Splunk
Enterprise で⼀部の機能
が無効化
占有サイズ (メモリー、
CPU 負荷)
最⼩
⼩
中〜⼤ (有効化した機能に
よる)
Python がバンドルされて
いるか？
いいえ
はい
はい
5
データ⼊⼒の取り扱いは？ すべてのタイプ (ただし、
スクリプト⼊⼒の場合は
Python のインストールが
必要)
すべてのタイプ
すべてのタイプ
Splunk Enterprise に転
送？
はい
はい
はい
サードパーティ製システム はい
に転送？
はい
はい
中継フォワーダーとして利 はい
⽤可能？
はい
はい
インデクサー応答確認 (配
信が保証されている)？
オプション (バージョン
4.2 以降)
オプション (バージョン
4.2 以降)
ロードバランシング可能？ はい
はい
はい
データの複製？
オプション
はい
はい
イベント単位のフィルタリ いいえ
ング？
はい
いいえ
はい
イベントのルーティング？ いいえ
いいえ
はい
イベントのパーシング？
いいえ
いいえ
はい
ローカルにインデックスを いいえ
作成？
いいえ
オプション、次のところ
にある indexAndForward 属
性で設定： outputs.conf
サーチ/アラート機能？
いいえ
いいえ
オプション
Splunk Web？
いいえ
いいえ
オプション
特定の機能の詳細は、このトピックの残りの部分やこのマニュアルの他のトピックを参照してください。
フォワーダーデータのタイプ
フォワーダーは 3 種類のデータを転送することができます。
raw
未パーシング
バーシング済み
フォワーダーが送信できるデータのタイプは、フォワーダーのタイプおよびその設定によって異なります。ユニ
バーサルフォワーダーとライトフォワーダーは、raw データまたは未パーシングデータを送信できます。ヘビー
フォワーダーは、raw データまたはパーシング済みデータを送信できます。
raw データ ：データストリームが raw TCP として転送されます。Splunk 通信形式には変換されません。フォ
ワーダーは単にデータを収集し、それを転送します。これは、⾮ Splunk システムにデータを送信する場合に特に
役⽴ちます。
⾮パーシングデータ ：ユニバーサルフォワーダーは最低限の処理のみ⾏います。データストリームを調査するこ
とはありませんが、ソース、ソースタイプ、およびホストを識別するために、ストリーム全体にメタデータでタグ
を設定します。また、データストリームを 64K のブロックに分割し、イベントに認識可能なタイムスタンプがな
い場合に、データを受信したインデクサーが使⽤する、基本的なタイムスタンプ設定を⾏います。ユニバーサル
フォワーダーが、個別のイベントの識別、調査、またはタグ設定を⾏うことはありません。
パーシング済みデータ ：ヘビーフォワーダーはデータを個別のイベントに分割し、タグを設定して Splunk
Enterprise インデクサーに転送します。イベントの調査を⾏うことも可能です。データはパーシングされている
ため、フォワーダーはフィールド値などのイベントデータに基づいて、条件による振り分け (ルーティング) を⾏
うことができます。
パーシング済みおよび⾮パーシング形式のデータは、処理済み データと呼ばれ、raw データと区別されます。デ
フォルトで、フォワーダーは処理済みデータを送信します (ユニバーサルフォワーダーの場合⾮パーシングデー
タ、ヘビーフォワーダーの場合パーシング済みデータ)。代わりに raw データを送信する場合は、outputs.conf に
sendCookedData=false 属性/値のペアを設定します。
フォワーダーとインデックス
フォワーダーは、インデックス単位でデータを転送、ルーティングします。デフォルトでは、すべての外部データ
および _audit 内部インデックスのデータを転送します。また、_internal 内部インデックスのデータを転送するこ
ともあります。必要に応じてこの動作を変更することができます。詳細は、「ターゲットインデックスによるデー
タのフィルタリング」を参照してください。
フォワーダーのデプロイトポロジー
フォワーダーのデプロイには、さまざまなシナリオを利⽤することができます。ここでは、フォワーダーで作成で
きる、有⽤なトポロジーについて説明していきます。各種デプロイトポロジーの設定⽅法の詳細は、「フォワー
ダーを使ったデプロイトポロジーの作成」を参照してください。
データの統合
6
データの統合は、複数のフォワーダーが単⼀の Splunk Enterprise インスタンスにデータを送信する、もっとも
⼀般的なトポロジーの 1 つです。⼀般的にこのシナリオでは、ユニバーサルフォワーダーがワークステーション
や実働環境の⾮ Splunk サーバーから⾮パーシングデータを、統合とインデックス作成の⽬的で集中処理を⾏う
Splunk Enterprise インスタンスに転送します。⼩型軽量のユニバーサルフォワーダーは、常駐しているシステム
のパフォーマンスに与える影響が最低限に抑えられています。ヘビーフォワーダーを利⽤して、Splunk
Enterprise インデクサーにパーシング済みデータを送信することもできます。
ここでは、3 台のユニバーサルフォワーダーが単⼀のインデクサーにデータを送信しています。
データの統合の詳細は、「複数マシンからのデータの統合」を参照してください。
ロードバランシング
ロードバランシング により、⼤量のデータ処理、サーチパフォーマンスの向上のための⽔平スケーリング、障害
対策などの問題に対処するための、複数のインデクサーにまたがったデータの分散処理を簡素化できます。ロード
バランシングでは、フォワーダーがそれぞれのインデクサーに、指定された間隔で順番にデータをルーティングし
ます。
フォワーダーは、設定された間隔でレシーバーを切り替える、⾃動ロードバランシングを実⾏します。パーシング
が有効になっている場合 (ヘビーフォワーダーの場合)、切り替えはイベント境界で⾏われます。
この図では、3 台のユニバーサルフォワーダーが、それぞれ 2 台のインデクサー間のロードバランシングを⾏っ
ています。
7
ロードバランシングの詳細は、「ロードバランシングの設定」を参照してください。
ルーティングとフィルタリング
データのルーティング で、フォワーダーはソースやソースタイプなどの基準またはイベントのパターンに基づい
て、イベントを特定の Splunk Enterprise またはサードパーティ製サーバーにルーティングします。イベントレ
ベルでルーティングを⾏うには、ヘビーフォワーダーが必要です。
またフォワーダーは、イベントをフィルタリングして特定のキューにルーティングしたり、NULL キューにルー
ティングすることでイベントを破棄したりすることができます。
ここでヘビーフォワーダーはイベントのパターンに基づいて、データを 3 台のインデクサーにルーティングして
います。
8
ルーティングとフィルタリングの詳細は、「データのルーティングとフィルタリング」を参照してください。
フォワーダーとインデクサー・クラスタ
フォワーダーを使って、インデクサー・クラスタ内のピアノードにデータを送信することができます。この⽬的に
は、ロードバランシングを⾏うフォワーダーを使⽤することをお勧めします。
2 台のロードバランシングを⾏うフォワーダーが、クラスタにデータを送信している図を以下に⽰します。
フォワーダーとインデクサー・クラスタの詳細は、『インデクサーとインデクサー・クラスタの管理』マニュアル
の「フォワーダーを使ったデータの取り込み」を参照してください。インデクサー・クラスタの全般的な情報につ
いては、「インデクサー・クラスタとインデックス・レプリケーションについて」を参照してください。
9
いては、「インデクサー・クラスタとインデックス・レプリケーションについて」を参照してください。
⾮ Splunk システムへの転送
raw データを syslog 収集システムなどの、サードパーティ製システムに送信することができます。この機能と
データのルーティングを組み合わせて、あるデータを⾮ Splunk システムに、他のデータを 1 つまたは複数の
Splunk Enterprise サーバーに送信することができます。
3 台のフォワーダーが、2 台の Splunk Enterprise サーバーと 1 台の⾮ Splunk システムにデータを転送する例
を以下に⽰します。
⾮ Splunk システムへの転送の詳細は、「サードパーティ製システムへのデータの転送」を参照してください。
転送の中継
⼀部の⾼度な使⽤事例に対応するために、⼀連のフォワーダーグループとインデクサーの間に中継フォワーダーを
設置することもあります。このシナリオでは、データの最初の送信元となるフォワーダー群が、中継フォワーダー
にデータを送信し、中継フォワーダーが (⼀般的にはローカルにインデックスを作成した後) データをインデク
サーに送信します。
たとえばデータを「保管して転送する」必要がある、またはローカル版のサーチを有効にする⽬的で、中間イン
デックスを作成する必要があるような状況で使⽤されます。(この場合、ヘビーフォワーダーを使⽤する必要があ
ります。)また、セキュリティ上の理由などで、インデクサーへのアクセスを制限する必要がある場合にも、中継
フォワーダーを使⽤できます。
転送の中継を有効にするには、中継フォワーダーをフォワーダーとレシーバーの両⽅として設定する必要がありま
す。レシーバーの設定⽅法の詳細は、「レシーバーを有効にする」を参照してください。
転送の設定
転送と受信の設定
フォワーダーのデプロイトポロジーと、そのために必要なフォワーダーのタイプを決定したら、転送と受信の設定
は単純です。ここには、主要ステップの概要と、詳細なトピックへのリンクを記載しています。
転送と受信の設定を⾏うには、以下の順番で 2 つの基本的な作業を実施する必要があります。
1. 1 つまたは複数の Splunk Enterprise インデクサーを、レシーバーとして設定する。これらがフォワーダーか
らデータを受信します。
2. 1 つまたは複数のフォワーダーを設定する。これらがレシーバーにデータを転送します。
このトピックの残りの部分には、これに関連する主要ステップと、詳細なトピックへのリンクを記載します。ユニ
バーサルフォワーダーを使⽤するのか、またはヘビー/ライトフォワーダーを使⽤するのかに応じて、ある程度⼿
順は異なります。⼀般的にユニバーサルフォワーダーは、単⼀のステップでインストール、設定することができま
す。ヘビー/ライトフォワーダーはまず完全版の Splunk Enterprise インスタンスとしてインストールし、その後
10
フォワーダーとしての設定を⾏います。
注意： このトピックは、レシーバーがインデクサーであることを前提にしています。ただし、記載されている⼀
部のシナリオでは、フォワーダーがレシーバーとしても機能することがあります。どのような種類のレシーバーで
も、基本的な設定はほぼ同じです。
注意： フォワーダーとレシーバー間の通信に HTTP プロトコルは使われていないため、プロキシ経由でデータを
転送することはできません。
フォワーダーとインデクサー・クラスタ
フォワーダーを使ってインデクサー・クラスタ内のピアノードにデータを送信する場合は、このトピックの説明と
は少し異なる⽅法で、転送と受信の設定を⾏います。フォワーダーとクラスタの詳細は、『インデクサーとインデ
クサー・クラスタの管理』マニュアルの「フォワーダーを使ったデータの取り込み」を参照してください。
転送と受信の設定：ユニバーサルフォワーダー
1. レシーバーとして使⽤する完全版の Splunk Enterprise インスタンスをインストールします。詳細は、『イン
ストールマニュアル』を参照してください。
2. Splunk Web または CLI を使って、レシーバーにするインスタンスの受信を有効にします。このマニュアルの
「レシーバーを有効にする」を参照してください。
3. ユニバーサルフォワーダーをインストール、設定、デプロイします。転送ニーズに応じて、さまざまなデプロイ
のベストプラクティスが存在しています。詳細は、「ユニバーサルフォワーダーのデプロイの概要」を参照してく
ださい。これらのシナリオの⼀部では、インストール時にフォワーダーを設定することができます。
4. インストール時に作業を⾏っていない場合は、各ユニバーサルフォワーダーに対してデータ⼊⼒を指定する必要
があります。『データの取り込み』マニュアルの「Splunk Enterprise がインデックス処理できる項⽬」を参照し
てください。場合によっては、受信側インデクサーの [データの追加] ページで、直接フォワーダー⼊⼒を設定す
ることができます。『データの取り込み』マニュアルの「データの転送」を参照してください。
注意： ユニバーサルフォワーダーには Splunk Web が含まれていないため、CLI や
定する必要があります。Splunk Web で設定することはできません。
inputs.conf
を使って⼊⼒設
5. インストール時に作業を⾏っていない場合は、各ユニバーサルフォワーダーに対して出⼒設定を⾏う必要があり
ます。そのためには、CLI を使⽤するか、または outputs.conf ファイルを編集します。outputs.conf を編集する⽅
が柔軟性に優れています。詳細は、このセクションの「outputs.conf によるフォワーダーの設定」などの他のト
ピックを参照してください。
6. テストを⾏って、転送やロード・バランシング、フィルタリングなどの、他の設定した動作が、⽬的通りに動作
することを確認します。
転送と受信の設定：ヘビー/ライトフォワーダー
注意： ライトフォワーダーは Splunk Enterprise 6.0 で廃⽌予定で、⾮推奨となりました。⾮推奨で廃⽌予定の
機能の⼀覧は、リリースノートの「⾮推奨 (廃⽌予定) の機能」を参照してください。
1. フォワーダーおよびレシーバーとして使⽤する完全版の Splunk Enterprise インスタンスをインストールしま
す。詳細は、『インストールマニュアル』を参照してください。
2. Splunk Web または CLI を使って、レシーバーにするインスタンスの受信を有効にします。このマニュアルの
「レシーバーを有効にする」を参照してください。
3. Splunk Web または CLI を使って、フォワーダーにするインスタンスの転送を有効にします。このマニュアル
の「ヘビー/ライトフォワーダーのデプロイ」を参照してください。
4. 通常のように、フォワーダーのデータ⼊⼒を指定します。『データの取り込み』マニュアルの「Splunk
Enterprise がインデックス処理できる項⽬」を参照してください。
5. フォワーダーの出⼒設定を指定します。そのためには、Splunk Web、CLI を使⽤するか、または outputs.conf
ファイルを編集します。outputs.conf を編集する⽅が柔軟性に優れています。詳細は、「ヘビー/ライトフォワー
ダーのデプロイ」、および「outputs.conf によるフォワーダーの設定」などのこのセクションにある他のトピッ
クを参照してください。
6. テストを⾏って、転送やロード・バランシング、ルーティングなどの、他の設定した動作が、⽬的通りに動作す
ることを確認します。
フォワーダーの管理
複数のフォワーダーが存在する環境では、デプロイサーバー を使ってフォワーダーの更新や管理を⾏う⽅が便利
なことがあります。詳細は、『Splunk Enterprise インスタンスの更新』マニュアルの「デプロイサーバーについ
て」を参照してください。
フォワーダーのステータスを参照するために、デプロイモニター を使⽤することができます。
フォワーダーとインデクサー間の互換性
フォワーダーとそのデータを受信するインデクサー間の、特定のバージョンに関する互換性の制限を以下に⽰しま
す。
11
6.xフォワーダー (ユニバーサル/ライト/ヘビー) は、5.0.x 以上のインデクサーと下位互換性があります。
6.x インデクサーは、4.3.x フォワーダーと下位互換性があります。
以下の 6.0 の機能は、インデクサーとフォワーダーの両⽅のバージョンが 6.0 以上の場合にのみ利⽤できます。
ダイナミックファイルヘッダー
フォワーダーによるタイムゾーン伝送。6.0 以降のプロトコルのタイムゾーン伝送機能は、中間でライト/ユ
ニバーサルフォワーダーが中継しているような、複数レベルの転送リンクを持つ転送環境では維持されませ
ん。
App 固有の互換性の制限については、Splunk Apps にある App のドキュメントを参照してください。
ベストプラクティスとして、フォワーダーからデータを受信するインデクサーのバージョンは、フォワーダーの
バージョンと同じかそれ以上にすることをお勧めします。
レシーバーを有効にする
転送と受信を有効にするには、レシーバー とフォワーダー の両⽅を設定します。レシーバーは、データを受信す
る Splunk Enterprise インスタンスです。フォワーダーがレシーバーにデータを送信します。
ニーズに応じて、各フォワーダーに対して複数のレシーバーを⽤意することもあります (たとえば、ロードバラン
シング⽬的で)。逆に、単⼀のレシーバーが複数のフォワーダーからデータを受信することもあります。
レシーバーは、フォワーダーからデータを受信するように設定された、Splunk Enterprise インデクサー (⼀般的
な事例) または他のフォワーダー (中継フォワーダー ) です。
まずレシーバーを設定する必要があります。次に、レシーバーにデータを送信するフォワーダーを設定します。
受信の設定
Splunk Enterprise インスタンス (インデクサーまたはフォワーダー) をレシーバーとして有効にする前に、まず
インスタンスをインストールする必要があります。次に Splunk Web、CLI、または inputs.conf 設定ファイルを
使って、インスタンスでの受信を有効にします。
Splunk Web を使った受信の設定
Splunk Web を使ってレシーバーを設定します。
1. フォワーダーからデータを受信するサーバー上で、Splunk Web に管理者 (admin) としてログインします。
2. ページの上部にある [設定] リンクをクリックします。
3. [データ] の [転送と受信] を選択します。
4. [データの受信] の [新規追加] をクリックします。
5. レシーバーが待機する TCP ポート (待機ポート 、または受信ポート ) を指定します。たとえば、「9997」と
⼊⼒すると、レシーバーはポート 9997 でデータを受信します。慣例的には、レシーバーはポート 9997 で待機
しますが、任意の未使⽤ポートを指定することができます。netstat などのツールを使えば、システムで利⽤でき
るポートを確認することができます。splunkweb や splunkd が選択したポートを使⽤していないことを確認して
ください。
6. [保存] をクリックします。処理を完了するには、インスタンスを再起動する必要があります。
Splunk CLI を使った受信の設定
受信を有効にするには、以下の CLI コマンドを実⾏します。
splunk enable listen <port> -auth <username>:<password>
には、レシーバーを待機させるポート (受信ポート) を指定します。たとえば、「9997」と⼊⼒すると、レ
シーバーはポート 9997 でデータを受信します。慣例的には、レシーバーはポート 9997 で待機しますが、任意
の未使⽤ポートを指定することができます。netstat などのツールを使えば、システムで利⽤できるポートを確認
することができます。splunkweb や splunkd が選択したポートを使⽤していないことを確認してください。
<port>
コマンドは、inputs.conf 内に、[splunktcp] スタンザを作成します。たとえば、ポート 9997
を指定した場合、スタンザ [splunktcp://9997] が作成されます。
splunk enable listen
設定ファイルを使った受信ポートの設定
内の inputs.conf を編集して、Splunk Enterprise インスタンスの受信を有効にする
ことができます。ユニバーサルフォワーダーを中継フォワーダー (レシーバーとしても動作するフォワーダー) を
設定するには、この⽅法を使⽤します。
$SPLUNK_HOME/etc/system/local
受信を有効にするには、受信ポートを指定する
9997 を使⽤しています。
[splunktcp]
[splunktcp://9997]
12
スタンザを追加します。以下の例で受信ポートは
disabled = 0
詳細は、inputs.conf spec ファイルを参照してください。
注意： [splunktcp://9997] と
⽤してください。
[splunktcp://:9997]
(1 つまたは 2 つのコロン) は、意味的に同⼀です。どちらかを使
異なるオペレーティングシステムが動作するフォワーダーから受信したデータのサーチ
たいていの場合、異なる OS で動作しているフォワーダーからデータを受信した Splunk インスタンスには、その
OS ⽤の App をインストールする必要があります。ただし、ここで説明していくように、このことに影響するさ
まざまな検討事項があります。
転送とインデックス作成は OS に依存しない動作です。認定されている OS 上で動作している限り、任意の組み
合わせでフォワーダーとレシーバーを使⽤することができます。たとえば、Linux レシーバーは、Windows ユニ
バーサルフォワーダーから送られてきたデータのインデックスを作成することができます。
データが転送されてインデックスが作成されると、その後はサーチや他のナレッジベースの操作がデータに対して
⾏われます。この時点で、操作を実施するインスタンスは、調査対象データの OS に関する情報が必要なことがあ
ります。⼀般的にはこれに対処するために、その OS 固有の App をインストールします。たとえば、Linux のイ
ンスタンスで、Windows から転送された OS 固有のデータをサーチする場合、Linux インスタンス上に
Windows App をインストールします。
調査対象データが Web ログなどの、OS 固有のものでない場合は、OS ⽤ App をインストールする必要はありま
せん。
また、レシーバーがデータのインデックス作成のみを担当し、実際のサーチは外部のサーチヘッドが実⾏する場
合、レシーバーに OS ⽤の App をインストールする必要はありません。ただし、サーチヘッド上にインストール
する必要があります。代わりに、同じ OS が動作するサーチヘッドを使⽤することもできます。たとえば、
Windows から Linux レシーバーに転送されたデータをサーチするには、その Linux インデクサーをサーチピア
として設定している Windows サーチヘッドを使⽤することができます。サーチヘッドの詳細は、「分散サーチに
ついて」を参照してください。
重要： 関連する OS App をダウンロードしたら、インデクサーにデフォルトの⼊⼒が追加されないように、App
を有効にする前にその inputs.conf ファイルを削除してください。Windows App の場所：
%SPLUNK_HOME%\etc\apps\windows\default\inputs.conf.
まとめると、レシーバー (またはサーチヘッド) がデータの転送元 OS のデータをサーチする場合にのみ、その
フォワーダーの OS に対応する App をインストールする必要があります。
フォワーダーからレシーバーへの接続のトラブルシューティング
レシーバーのレシーバーおよび管理⽤ポートの混乱
フォワーダー設定の⼀環として、レシーバーの hostname/IP_address および port を指定します。フォワーダーはこ
れらの設定を使って、レシーバーにデータを送信します。レシーバーの設定時に受信ポートとして指定されたポー
トを指定する必要があります。レシーバーの管理⽤ポートを間違って指定すると、レシーバーでは以下のようなエ
ラーが発⽣します。
splunkd.log:03-01-2010 13:35:28.653 ERROR TcpInputFd - SSL Error = error:140760FC:SSL
routines:SSL23_GET_CLIENT_HELLO:unknown protocol
splunkd.log:03-01-2010 13:35:28.653 ERROR TcpInputFd - ACCEPT_RESULT=-1 VERIFY_RESULT=0
splunkd.log:03-01-2010 13:35:28.653 ERROR TcpInputFd - SSL Error for fd from HOST:localhost.localdomain,
IP:127.0.0.1, PORT:53075
splunkd.log:03-01-2010 13:35:28.653 ERROR TcpInputFd - SSL Error = error:140760FC:SSL
routines:SSL23_GET_CLIENT_HELLO:unknown protocol
splunkd.log:03-01-2010 13:35:28.653 ERROR TcpInputFd - ACCEPT_RESULT=-1 VERIFY_RESULT=0
splunkd.log:03-01-2010 13:35:28.653 ERROR TcpInputFd - SSL Error for fd from HOST:localhost.localdomain,
IP:127.0.0.1, PORT:53076
splunkd.log:03-01-2010 13:35:28.653 ERROR TcpInputFd - SSL Error = error:140760FC:SSL
routines:SSL23_GET_CLIENT_HELLO:unknown protocol
splunkd.log:03-01-2010 13:35:28.654 ERROR TcpInputFd - ACCEPT_RESULT=-1 VERIFY_RESULT=0
splunkd.log:03-01-2010 13:35:28.654 ERROR TcpInputFd - SSL Error for fd from HOST:localhost.localdomain,
IP:127.0.0.1, PORT:53077
splunkd.log:03-01-2010 13:35:28.654 ERROR TcpInputFd - SSL Error = error:140760FC:SSL
routines:SSL23_GET_CLIENT_HELLO:unknown protocol
splunkd.log:03-01-2010 13:35:28.654 ERROR TcpInputFd - ACCEPT_RESULT=-1 VERIFY_RESULT=0
レシーバーのソケットが閉じている
インデクサーのキューが満杯になると、これ以上のフォワーダーが接続しないように、レシーバーのソケットが閉
じられます。ロードバランシングを有効にしたフォワーダーがそのレシーバーにデータを転送できなくなると、リ
ストに記載されている他のインデクサーにそのデータが送信されます。フォワーダーでロードバランシングを使⽤
していない場合は、問題が解決するまでの間、フォワーダーにデータが保持されます。
キューの混雑が解決すると、レシーバーのソケットは⾃動的に開かれます。
⼀般的にレシーバーは、ディスク満杯でデータを書き込めない、またはデータを受け付けない他の Splunk インス
13
タンスにデータを転送しようとしている、などの理由でデータフローから除外されます。
ソケットがブロックされている場合は、splunkd.log に以下の警告メッセージが表⽰されます。
Stopping all listening ports. Queues blocked for more than N seconds.
ソケットが再び開かれると、以下のメッセージが表⽰されます。
Started listening on tcp ports. Queues unblocked.
受信を無効にする
CLI で受信を無効にするには、splunk
disable listen
コマンドを実⾏します。
splunk disable listen -port <port> -auth <username>:<password>
inputs.conf
から
[splunktcp]
スタンザを削除して、受信を無効にすることもできます。
Answers
何か質問がありますか？「Splunk Answers」では、Splunk コミュニティに寄せられた、転送の設定に関する質
問と回答をご覧いただけます。
複数のマシンからのデータの統合
もっとも⼀般的な使⽤事例の 1 つが、複数のマシンからのデータを統合することです。マシンに常駐している
フォワーダーが、データを集中管理する Splunk Enterprise インデクサーにデータを転送します。通常、⼩型軽
量のユニバーサルフォワーダーは、マシンのパフォーマンスに与える影響を最低限に抑えます。多彩なオペレー
ティングシステムが動作する各マシン上に常駐しているユニバーサルフォワーダーが、単⼀の Splunk Enterprise
インスタンスにデータを送信する例を以下の図に⽰します。この Splunk Enterprise インスタンスがインデック
スを作成し、すべてのデータに対するサーチを可能にしています。
この図は⼩規模なデプロイ環境を表しています。実際には、データの統合に使⽤されるユニバーサルフォワーダー
数が数千台に上ることもあります。
このタイプの使⽤事例は、設定が簡単です。
1. どのマシンにあるどのようなデータが必要かを判断します。
2. Splunk Enterprise インスタンスをインストールします (⼀般的には独⾃のマシン上に)。このインスタンス
が、レシーバー として動作します。ここで、すべてのインデックスの作成およびサーチの実⾏が⾏われます。
14
3. Splunk Web または CLI を使って、インスタンスをレシーバーとして設定します。CLI を使⽤する場合
は、$SPLUNK_HOME/bin/ から以下のコマンドを実⾏します。
./splunk enable listen <port> -auth <username>:<password>
<port>,
には、レシーバーを待機させるポートを指定します。これは、「レシーバーポート」としても知られてい
ます。
4. レシーバーとは異なるオペレーティングシステム上で動作しているユニバーサルフォワーダーがある場合は、レ
シーバーにそのフォワーダーの OS に対応する App をインストールします。たとえば、上記の図に記載されてい
るレシーバーが Linux 上で動作している場合を考えてみましょう。この場合は、レシーバー上に Windows App
をインストールする必要があります。*nix App のインストールも必要な場合があります。ただし、レシーバーは
Linux 上で動作しているため、通常はすでにこの App がインストールされています。このことに関する詳細や条
件については、ここを参照してください。
関連する App をダウンロードしたら、インデクサーにデフォルトの⼊⼒が追加されないように、App を有効にす
る前にその inputs.conf ファイルを削除してください。Windows App の場所：
$SPLUNK_HOME/etc/apps/windows/default/inputs.conf.
5. データを転送する各マシン上に、ユニバーサルフォワーダーをインストールします。これらがレシーバーにデー
タを転送します。
6. 各フォワーダーの⼊⼒を設定します。「Splunk がインデックス処理できる項⽬」を参照してください。
7. レシーバーにデータを転送するように、各フォワーダーを設定します。Windows フォワーダーの場合は、こ
こで説明しているように、インストール時にこの作業を⾏うことができます。*nix フォワーダーの場合は、CLI を
使⽤する必要があります。
./splunk add forward-server <host>:<port> -auth <username>:<password>
<host>:<port>,
には、レシーバーのホストとレシーバーポートを指定します。例：
splunk_indexer.acme.com:9995.
多数のフォワーダーが存在している場合は、outputs.conf ファイルを使ってレシーバーを指定することができま
す。例：
[tcpout:my_indexers]
server= splunk_indexer.acme.com:9995
このファイルを 1 つ作成して、そのコピーを各フォワーダーに配布します。
ロードバランシングの設定
ロードバランシング を利⽤する場合、フォワーダーは複数の Splunk レシーバーにデータを分散します。各レ
シーバーは、データ全体の⼀部を受け取り、各レシーバーのデータをまとめたものが全データになります。転送さ
れたデータ全体にアクセスするには、すべてのレシーバーにまたがる分散サーチを設定する必要があります。分散
サーチの詳細は、『分散サーチ』マニュアルの「分散サーチについて」を参照してください。
ロードバランシングにより、パフォーマンスを向上するための⽔平⽅向スケーリングが可能になります。また、そ
の⾃動切り替え機能により、マシンが停⽌した場合の耐性も向上します。あるマシンが停⽌すると、フォワーダー
は利⽤可能な他のレシーバーにデータの転送を開始します。
ロードバランシングは、ルーターなどのネットワーク機器からデータを受信する場合にも役⽴ちます。syslog お
よびポート 514 で⽣成された他のデータを処理するために、1 台のヘビーフォワーダーでポート 514 を監視し
て、その受信データを複数のインデクサーに分散することができます。
注意： フォワーダーとレシーバー間にロードバランシングを採⽤する場合、フォワーダー固有のロードバランシ
ング機能を使⽤する必要があります。外部のロードバランサーは使⽤しないでください。フォワーダーとレシー
バー間に外部のロードバランサーを使⽤すると、正常に機能しません。
ロードバランシングの仕組み
フォワーダーは⾃動ロードバランシングを実⾏します。フォワーダーは、指定された時間間隔に基づいて異なるイ
ンデクサーにデータをルーティングします。たとえば、3 台のインデクサーから成り⽴っているロードバランシン
ググループを考えてみましょう。それぞれのノードを A、B、および C とします。フォワーダーは指定された 30
秒などの⼀定の間隔で、データストリームを、グループ内の他のインデクサーに切り替えます。インデクサーは無
作為に選択されます。たとえばフォワーダーは、インデクサー B からインデクサー A に切り替え、次にインデク
サー C に切り替えます。あるインデクサーが停⽌すると、即座に別のインデクサーに切り替えられます。
フォワーダーがモニターするように設定されている、各⼊⼒に対するデータストリームがある場合を考えてみま
しょう。フォワーダーは、データストリームを他のインデクサーに切り替えても安全かどうかを判断します。次
に、指定されている間隔で、新たに選択したインデクサーにデータストリームを切り替えます。新しいインデク
サーにデータストリームを安全に切り替えることができない場合は、安全に送信できるようになるまでの間、前の
インデクサーとの接続を維持してデータストリームの送信を継続します。
重要： ユニバーサルフォワーダーが TCP ネットワークのデータストリーム (syslog を含む) をモニターしている
場合、EOF に達するかインデクサーが停⽌しない限り、インデクサーを切り替えることはできません。EOF に達
するかインデクサーが停⽌した時点で、フォワーダーがリスト内の次のインデクサーに切り替えます。ユニバーサ
ルフォワーダーは、インデクサーにデータを送信する前に (ヘビーフォワーダーと違い)、データのパーシングを
15
⾏ってイベント境界を識別しないため、EOF を受信しない限り、次のインデクサーに切り替えても安全かどうか
を判断する⼿段がありません。
注意： 以前は⾃動ロードバランシングの代わりに利⽤できた、ラウンドロビン⽅式ロードバランシング機能は、
Splunk Enterprise バージョン 4.2 で廃⽌されました。
3 台のフォワーダーが 2 台のインデクサーにデータをロードバランシングしている、⼀般的なシナリオを以下の
図に⽰します。
ロードバランシングのターゲット
⼀連のターゲットレシーバーを設定する場合、DNS または静的リストを使⽤することができます。
DNS リストは柔軟性に優れており、⼤規模なデプロイ環境などでは特に環境の拡張が容易になります。DNS を
利⽤すれば、フォワーダーの outputs.conf ファイルをいちいち編集することなく、⼀連のレシーバーを変更するこ
とができます。
静的リストの主な利点は、各レシーバーに異なるポートを指定できることにあります。このことは、単⼀のホスト
上で動作する複数のレシーバー間でロードバランシングを⾏う必要がある場合に役⽴ちます。各レシーバーが、個
別のポートで待機することができます。
静的リストのターゲット
ターゲットの静的リストを使⽤するには、フォワーダーの outputs.conf ファイル内の、対象グループの [tcpout] ス
タンザに、各レシーバーを指定します。この例では、対象グループが 3 台のレシーバーから構成されており、そ
れぞれの IP アドレスとレシーバーポートが設定されています。
[tcpout: my_LB_indexers]
server=10.10.10.1:9997,10.10.10.2:9996,10.10.10.3:9995
ユニバーサルフォワーダーは、記載されている 3 台のレシーバー間でロードバランシングを⾏います。いずれか
のレシーバーが停⽌した場合、フォワーダーは⾃動的にリスト内の他のレシーバーに切り替えます。
DNS リストターゲット
DNS リストを使⽤する場合、フォワーダーの
ザに、単⼀のホストを指定します。例：
outputs.conf
ファイルを編集して、対象グループの
[tcpout]
スタン
[tcpout:my_LB_indexers]
server=splunkreceiver.mycompany.com:9997
DNS サーバーでは、outputs.conf. に指定したサーバー名を参照する、各ホストの IP アドレスに対して DNS A
レコードを作成します。例：
16
splunkreceiver.mycompany.com
A
10.10.10.1
splunkreceiver.mycompany.com
A
10.10.10.2
splunkreceiver.mycompany.com
A
10.10.10.3
フォワーダーは DNS リストを使ってロードバランシングを⾏い、指定された間隔に応じて、指定されたレシー
バー間を切り替えながらデータを送信します。あるレシーバーが利⽤できない場合、フォワーダーはそれをスキッ
プしてリストに記載されている他のレシーバーにデータを送信します。
多数のフォワーダーが存在するトポロジーを採⽤している場合、DNS リストを使⽤すれば、フォワーダーの
outputs.conf ファイルを編集することなく、⼀連のレシーバーを更新することができます。
⽔平スケーリング⽤のロードバランシングの設定
ロードバランシングを設定するには、まずご⾃分のニーズを決定します (特に⽔平⽅向のスケーリングとフェイル
オーバーの要件)。次に、それらのニーズに基づいてトポロジーを設計していきます。たとえば、複数のフォワー
ダーとレシーバー、そして各レシーバーにまたがってサーチを実施するための、サーチヘッドを設置します。
3 台のユニバーサルフォワーダーおよび 3 台のレシーバーがあるトポロジーで、DNS ベースのロードバランシン
グを設定するには、以下の⼿順に従います。
1. 3 台の Splunk Enterprise インスタンスをインストールして、レシーバーとして設定します。この例では、
DNS リストを使ってレシーバーを指定するため、レシーバーはすべて同じポートで待機する必要があります。た
とえば、ポートが 9997 の場合、各レシーバーの $SPLUNK_HOME/bin/ に移動して、以下の CLI コマンドを実⾏しま
す。
./splunk enable listen 9997 -auth <username>:<password>
2. ここで説明しているように、⼀連のユニバーサルフォワーダーをインストールします。
3. DNS リストに各レシーバーの IP アドレスの A レコードを設定します。
splunkreceiver.mycompany.com
A
10.10.10.1
splunkreceiver.mycompany.com
A
10.10.10.2
splunkreceiver.mycompany.com
A
10.10.10.3
4. すべてのフォワーダーが使⽤する、単⼀の outputs.conf を作成します。これは、DNS リストで使⽤する DNS
サーバー名と、レシーバーが待機するポートを⽰します。
[tcpout]
defaultGroup=my_LB_indexers
[tcpout:my_LB_indexers]
disabled=false
autoLBFrequency=40
server=splunkreceiver.mycompany.com:9997
この outputs.conf ファイルは、autoLBFrequency 属性を使って、ロードバランシングの頻度を 40 秒間隔に設定しま
す。フォワーダーは 40 秒ごとに、別のレシーバーに切り替えます。デフォルトは 30 秒で、この値を変更する必
要はほとんどありません。
5. outputs.conf ファイルをすべてのフォワーダーに配布します。デプロイサーバー を使って配布することもできま
す。
⼿順は、DNS の代わりに静的リストを使う場合と同様です。
CLI からのロードバランシングの指定
CLI を使ってロードバランシングを指定することもできます。⼀連のレシーバーへの転送活動を開始する際に、以
下の構⽂を使⽤します。
./splunk add forward-server <host>:<port> -method autobalance
ここで、<host>:<port> には、レシーバーのホストとレシーバーポートを指定します。
この例は、4 台のレシーバーのロードバランシンググループを作成します。
./splunk add forward-server indexer1:9997 -method autobalance
./splunk add forward-server indexer2:9997 -method autobalance
./splunk add forward-server indexer3:9997 -method autobalance
./splunk add forward-server indexer4:9997 -method autobalance
ユニバーサルフォワーダー
17
ユニバーサルフォワーダーの紹介
ユニバーサルフォワーダー は、Splunk の軽量版フォワーダー です。ユニバーサルフォワーダーを使ってさまざ
まな⼊⼒からデータを収集し、それを Splunk サーバーに転送して インデックス作成とサーチを⾏います。
このセクションでは、さまざまなシステムおよびニーズに応じた、ユニバーサルフォワーダーのデプロイ⽅法につ
いて説明していきます。各種フォワーダーの詳細およびトポロジーや使⽤事例に応じた設定⽅法については、この
マニュアルの「データの転送」を参照してください。
ユニバーサルフォワーダーはライトフォワーダーに代わるものです。
注意： ユニバーサルフォワーダーは、完全版の Splunk Enterprise とは別個の実⾏形式ファイルです。Splunk
Enterprise インスタンスとユニバーサルフォワーダーは、同じシステム上で共存できます。
ユニバーサルフォワーダーのデプロイ⽅法の詳細は、「ユニバーサルフォワーダーのデプロイの概要」を参照して
ください。
ユニバーサルフォワーダーと完全版 Splunk Enterprise の違い
ユニバーサルフォワーダーの唯⼀の⽬的は、データを転送することにあります。完全版の Splunk Enterprise イ
ンスタンスと違い、ユニバーサル・フォワーダーを使ってインデックスの作成やサーチの実⾏はできません。⾼い
パフォーマンスと⼩型軽量化を実現するために、ユニバーサルフォワーダーにはいくつかの制限があります。
ユニバーサルフォワーダーには、サーチ、インデックス作成、またはアラート機能はありません。
ユニバーサルフォワーダーは、データのパーシング を⾏いません。
ユニバーサルフォワーダーは、syslog 経由でデータを出⼒しません。
完全版の Splunk Enterprise と違い、ユニバーサルフォワーダーには Python のバンドル版は含まれていま
せん。
スクリプト⼊⼒と Python
完全版の Splunk Enterprise には、Python がバンドルされています。ユニバーサルフォワーダーにはありませ
ん。そのため、現在 Python によるスクリプト⼊⼒を使⽤しており、それをユニバーサルフォワーダーでそれらの
スクリプトを使⽤したい場合は、まず独⾃に Python をインストールする必要があります。Splunk の Python 固
有のライブラリを呼び出している場合は、ユニバーサルフォワーダーで使⽤することはできません。それらのライ
ブラリは、完全版の Splunk Enterprise にのみ存在しています。ターゲットホスト上でサポートされている場合
は、他のスクリプト⾔語をユニバーサルフォワーダーのスクリプト⼊⼒に使⽤することができます (例：Windows
Server 2008 で Powershell)。
ユニバーサルフォワーダーとライトフォワーダーの⽐較
ユニバーサルフォワーダーは、スリム化された独⽴型のフォワーダーで、他の Splunk Enterprise インスタンス
にデータを転送するために必要な基本コンポーネントのみが含まれています。対照的にライトフォワーダー は完
全版の Splunk Enterprise インスタンスで、軽量化するために⼀部の機能が無効になっています。すべての観点
から、インデクサーへのデータ転送にはユニバーサルフォワーダーが適していると⾔うことができます。ユニバー
サルフォワーダーをインストールする場合、既存のライトフォワーダーのバージョン 4.0 以降から移⾏すること
ができます。詳細は、「ライトフォワーダーからの移⾏」を参照してください。
ライトフォワーダーと⽐べて、ユニバーサルフォワーダーはパフォーマンスが⾼く、データの転送を⾏うためのよ
り合理化されたソリューションとなっています。ユニバーサルフォワーダーとライトフォワーダーの主な技術的差
異を以下に⽰します。
ユニバーサルフォワーダーの⽅が CPU に与える負荷が低く、メモリーおよびディスク使⽤量も少なくなっ
ています。
ユニバーサルフォワーダーのデフォルトのデータ転送レートは 256Kbps です。
ユニバーサルフォワーダーには、Python がバンドルされていません。
ユニバーサルフォワーダーはフォワーダー専⽤です。完全版の Splunk Enterprise インスタンスに変換する
ことはできません。
注意： ライトフォワーダーは Splunk Enterprise 6.0 で廃⽌予定で、⾮推奨となりました。⾮推奨で廃⽌予定の
機能の⼀覧は、リリースノートの「⾮推奨 (廃⽌予定) の機能」を参照してください。
お読みください
ユニバーサルフォワーダーのデプロイについては、このトピックの次のトピックを参照してください。
ユニバーサル・フォワーダーを使ったデータの転送、およびさまざまな分散トポロジーへの参加⽅法については、
このマニュアルの「概要」を参照してください。これらのトピックでは、ライト/ヘビーフォワーダーについても
説明しています。
Windows 版の Splunk Enterprise に同梱されているサードパーティ製の Windows バイナリについては、『イン
ストールマニュアル』の「Splunk Enterprise と⼀緒に配布される Windows 版サードパーティ製バイナリについ
て」を参照してください。
Windows セーフモードでのユニバーサルフォワーダーの実⾏については、『インストールマニュアル』の
「Splunk Enterprise のアーキテクチャとプロセス」を参照してください。
デプロイの概要
この章のトピックは、ユニバーサルフォワーダー のインストール、デプロイ⽅法について説明しています。これ
18
には、さまざまな状況に応じた、フォワーダーのインストールと設定に関する使⽤事例も含まれています。
重要： ユニバーサルフォワーダーをデプロイする前に、転送の仕組みや各種設定上の問題について正しく理解し
ておく必要があります。以下の事項を参照してください。
フォワーダーと転送の概要については、「データの転送」の各トピックを参照してください。
フォワーダーの設定⽅法については、「転送の設定」の各トピックを参照してください。
転送と受信の設定の概要は、「転送と受信の設定：ユニバーサルフォワーダー」を参照してください。
デプロイのタイプ
ユニバーサルフォワーダーのデプロイの主なシナリオを以下に⽰します。
インストーラ GUI またはコマンドラインを使って、Windows ユニバーサルフォワーダーを⼿動デプロイす
る。
nix ユニバーサルフォワーダーを⼿動でデプロイし、CLI を使って設定する。
ユニバーサルフォワーダーをリモートからデプロイする (Windows または nix)。
ユニバーサルフォワーダーをシステムイメージの⼀部にする。
各シナリオが、独⾃のトピックで説明されています。⼤部分のシナリオは、Windows と *nix を別々のトピックで
取り上げています。
注意： ユニバーサルフォワーダーは、完全版の Splunk Enterprise とは別個の、ダウンロード可能な実⾏形式
ファイルです。ヘビーフォワーダーやライトフォワーダーと違い、完全版の Splunk Enterprise インスタンスか
ら有効にすることはできません。ユニバーサルフォワーダーをダウンロードするに
は、http://www.splunk.com/download/universalforwarder を参照してください。
作業を開始する前に
フォワーダーとインデクサー・クラスタ
フォワーダーを使ってインデクサー・クラスタ内のピアノードにデータを送信する場合は、このトピックの説明と
は少し異なる⽅法で、デプロイと設定を⾏います。フォワーダーとクラスタの詳細は、『インデクサーとインデク
サー・クラスタの管理』マニュアルの「フォワーダーを使ったデータの取り込み」を参照してください。
インデクサーとユニバーサルフォワーダーの互換性
詳細は、「フォワーダーとインデクサー間の互換性」を参照してください。
システム要件
特定のハードウェア要件とサポートしているオペレーティングシステムについては、『インストールマニュアル』
を参照してください。
ライセンス要件
ユニバーサルフォワーダーには、事前インストールされるライセンスが同梱されています。詳細は、『管理マニュ
アル』の「Splunk Enterprise ライセンスの種類」を参照してください。
その他の要件
ユニバーサルフォワーダーをインストールするマシンに対して、管理者または同等の権限が必要です。
デプロイ⼿順
実際の⼿順は、デプロイのタイプによって異なりますが、⼀般的な⼿順は以下のようになります。
1. デプロイのプランニングを⾏います。
2. http://www.splunk.com/download/universalforwarder からフォワーダーをダウンロードします。
3. テスト⽤マシンにユニバーサルフォワーダーをインストールします。
4. インストール後の設定作業を⾏います。
5. デプロイ環境のテストと調整を⾏います。
6. ユニバーサルフォワーダーを環境内の各マシンにデプロイします (複数台のマシンをデプロイする場合)。
これらのステップの詳細は後述しています。
重要： フォワーダーのデプロイは、転送と受信の設定プロセス全体の中の、ほんの 1 つのステップに過ぎません
設定プロセスの概要は、「転送と受信の設定：ユニバーサルフォワーダー」を参照してください。
デプロイのプランニング
デプロイのプランニングを⾏う際の、検討事項の例を以下に⽰します。
デプロイするマシン数 (およびマシンのタイプ) は？
複数の OS にまたがってデプロイするのか？
19
既存のフォワーダーからの移⾏が必要か？
デプロイツールを使⽤する場合、何を使⽤するのか？
システムイメージまたは仮想マシンを使ってデプロイするのか？
デプロイ時にユニバーサルフォワーダーの設定を完全に⾏うのか、またはユニバーサルフォワーダーのシス
テムのデプロイ後に設定を⾏うのか？
ユニバーサルフォワーダーとインデクサー間の通信に必要なセキュリティのレベルは？
インストール、テスト、設定、デプロイ
次に⾏う作業としては、この章内でご⾃分のデプロイ要件にもっとも近いトピックを参照してください。各トピッ
クには、インストールから設定、デプロイまで、特定のデプロイシナリオに対応する、1 つまたは複数の使⽤事例
が記載されています。
インストーラ GUI を使った Windows ユニバーサルフォワーダーのデプロイ
コマンドラインを使った Windows ユニバーサルフォワーダーのデプロイ
静的設定を使った Windows ユニバーサルフォワーダーのリモートデプロイ
nix ユニバーサルフォワーダーの⼿動デプロイ
静的設定を使った nix ユニバーサルフォワーダーのリモートデプロイ
ユニバーサルフォワーダーをシステムイメージの⼀部にする
ただし、まず次のセクションをお読みになって、ユニバーサルフォワーダー設定の詳細を学習してください。
注意： ユニバーサルフォワーダーの実⾏形式ファイル名は splunkd で、完全版 Splunk Enterprise の実⾏形式
ファイル名と同じになっています。サービス名は SplunkUniversalForwarder です。
⼀般的な設定に関する問題
ユニバーサルフォワーダーには Splunk Web GUI が⽤意されていないため、すべての設定はインストール時に⾏
うか (Windows のみ)、または後ほど別個の作業として設定を⾏う必要があります。インストール後に設定を⾏う
場合は、CLI を使⽤、設定ファイルを直接編集、またはデプロイサーバーを使⽤します。
設定箇所
主要な設定ファイルとしては、inputs.conf (データ⼊⼒⽤) および outputs.conf (データ出⼒⽤) が挙げられま
す。他にも server.conf や deploymentclient.conf などが挙げられます。
CLI を使って設定を変更する場合、ユニバーサルフォワーダーは設定ファイルへの変更をサーチ App 内に書き込
みます (outputs.conf への変更を除く、この場合は $SPLUNK_HOME/etc/system/local/ 内のファイルに書き込まれま
す)。実際にユニバーサルフォワーダーを使ってサーチを実⾏できなくても、サーチ App がユニバーサルフォワー
ダーのデフォルト App になります。奇妙に思うかもしれませんがそのようになっています。
重要： Windows インストールプロセスは、設定の変更を「MSICreated」と⾔う名前の App に書き込みます。
サーチ App ではありません。
注意： ユニバーサルフォワーダーには、「SplunkUniversalForwarder」 App も同梱されています。この App
は有効にする必要があります。(この処理は⾃動的に⾏われます。)この App には、ユニバーサルフォワーダーを
効率化モードで実⾏するための、事前設定が含まれています。ここに設定の変更は書き込まれません。この App
の設定を変更したり、追加したりはしない ことをお勧めします。
他の設定に関する詳細情報
重要な情報については、以下の記事を参照してください。
設定ファイルが機能する仕組みについては、『管理マニュアル』の「設定ファイルについて」および「設定
ファイルの優先度」を参照してください。
outputs.conf に関する詳細は、「outputs.conf によるフォワーダーの設定」を参照してください。
CLI を使った出⼒の設定については、「フォワーダーを使ったデプロイトポロジーの作成」を参照してくだ
さい。
inputs.conf または CLI を使ったデータ⼊⼒の設定については、『データの取り込み』マニュアルの「⼊⼒の
設定」を参照してください。
設定更新のデプロイ
⼀連のユニバーサルフォワーダーに設定の更新をデプロイする主な⽅法を以下に⽰します。
各ユニバーサルフォワーダーに対して、⼿動で設定ファイルを編集またはコピーする (⼩規模なデプロイ環
境の場合)。
Splunk デプロイサーバー を使って、設定した App を⼀連のユニバーサルフォワーダーに配布する。
独⾃のデプロイツールを使って、設定の変更を配布する。
ユニバーサルフォワーダーの再起動
⼀部の設定を変更した場合は、フォワーダーの再起動が必要なことがあります。(変更後に再起動が必要な設定に
ついては、その設定の変更⽅法を説明しているトピックでその旨が説明されています。)
ユニバーサルフォワーダーを再起動するには、完全版 Splunk Enterprise インスタンスを再起動する場合と同様
20
に、CLI コマンドの
restart
を使⽤します。
Windows の場合： %SPLUNK_HOME%\bin に移動して、以下のコマンドを実⾏します。
> splunk restart
*nix システムの場合： ホスト上のシェルプロンプトから、以下のコマンドを実⾏します。
# splunk restart
ライトフォワーダーからの移⾏
ユニバーサルフォワーダーは、従来のライトフォワーダー のすべての機能を提供していますが、より⼩型軽量で
パフォーマンスに優れています。既存のライトフォワーダーからユニバーサルフォワーダーに移⾏することができ
ます。Splunk には、移⾏プロセスを容易にし、新しいユニバーサルフォワーダーがインデクサーに、古いライト
フォワーダーがすでに送信したデータを送らないようにするためのツールが⽤意されています。
注意： バージョン 4.0 以降のライトフォワーダーのみを移⾏することができます。
移⾏は、ユニバーサルフォワーダーのインストールの過程で、オプションとてして⽤意されています。詳細は、
「Windows フォワーダーの移⾏」または「nix フォワーダーの移⾏」を参照してください。ユニバーサルフォ
ワーダーをインストールして稼働させたら (そして移⾏処理が正常に⾏われたことを確認したら)、古いライトフォ
ワーダーインスタンスをアンインストールすることができます。
移⾏で⾏われる処理
移⾏時には、fishbucket ディレクトリのデータも含めたチェックポイントデータが、古いフォワーダーから新し
いユニバーサルフォワーダーにコピーされます。これにより、従来のフォワーダーからすでにインデクサーに送信
したデータを、ユニバーサルフォワーダーが再送信することを防⽌します。また、この処理により不要な再イン
デックス作成も防⽌でき、統計情報を維持しながら、ライセンス使⽤量も適切に管理することができます。移⾏処
理では、特に以下のデータがコピーされます。
fishbucket ディレクトリ (tailed ファイルのシークポインタを含む)。
移⾏で⾏われない処理
移⾏処理で inputs.conf や outputs.conf などの設定ファイルがコピーされることはありません。これは、古いフォ
ワーダー上に存在しているすべての既存バージョンの設定ファイルを確認することは、結果的に不可能なためで
す。そのため、インストール時またはその後に、データの⼊⼒と出⼒を設定する必要があります。後で設定するこ
とを選択した場合、必要な設定ファイルを⼿動でコピーする、またはデプロイサーバーを使ってすべてのユニバー
サルフォワーダーに設定ファイルを配布することができます。設定ファイルの詳細は、後述するセクションを参照
してください。
ユニバーサルフォワーダーのデータ⼊⼒が古いフォワーダーとは異なる場合でも、移⾏を⾏うことができます。ユ
ニバーサルフォワーダーに対して設定されていない⼊⼒に関する、移⾏されたチェックポイントデータは、単純に
無視されます。後ほどこれらの⼊⼒を追加した場合、ユニバーサルフォワーダーは移⾏されたチェックポイントを
使って、データの転送を開始する、データストリーム内の場所を判断します。
移⾏処理では、ライトフォワーダーから App がコピーされることもありません。ユニバーサルフォワーダーに移
⾏したい App がある場合は、⼿動で移⾏する必要があります。
サポートしている CLI コマンド
ユニバーサルフォワーダーは、CLI コマンドで使⽤するオブジェクトの⼀部をサポートしています。index (add
index) などの完全版 Splunk Enterprise で有効な⼀部のオブジェクトは、ユニバーサルフォワーダーでは何の意
味も持ちません。
コマンドはオブジェクトに応じて処理を⾏います。無効なコマンド/オブジェクトの組み合わせを指定すると、ユ
ニバーサルフォワーダーからはエラー メッセージが返されます。
有効な CLI オブジェクト
ユニバーサルフォワーダーは、これらのオブジェクトに対して、すべての CLI コマンドをサポートしています。
add
app
config
datastore-dir
default-hostname
deploy-client
deploy-poll
eventlog
exec
forward-server
monitor
oneshot
perfmon
21
registry
servername
splunkd-port
tcp
udp
user
wmi
注意： start や stop などの、いくつかのコマンドは、オブジェクトを指定せずに実⾏することができます。ユニ
バーサルフォワーダーでも、オブジェクトを指定しないコマンドは有効です。
CLI 構⽂の概要
CLI コマンドの⼀般的な構⽂を以下に⽰します。
./splunk <command> [<object>] [[-<parameter>] <value>]...
前述のように、ユニバーサルフォワーダーであるコマンドが有効かどうかを決定するのが、オブジェクトです。た
とえば、上記のリストには monitor オブジェクトが含まれています。そのため、add monitor および edit monitor の
コマンド/オブジェクトの組み合わせは両⽅とも有効になります。monitor オブジェクトの詳細は、『データの取り
込み』マニュアルの「CLI を使ったファイルとディレクトリの監視」を参照してください。
CLI の使⽤に関する全般的な情報は、『管理マニュアル』の「コマンドラインインターフェイス (CLI) を使った
Splunk の管理」を参照してください。特に、トピック「CLI 管理コマンド」には、完全版 Splunk Enterprise が
サポートするすべてのコマンド⼀覧や対象となるオブジェクトを含めた、CLI 構⽂の詳細が記載されています。
ユニバーサル・フォワーダーのインストール⽅法
ユニバーサル・フォワーダーをインストールする前に、ご利⽤のオペレーティング・システムに合った適切なバー
ジョンを⼊⼿する必要があります。ユニバーサル・フォワーダーには、Windows 版の他に、各種 *nix に対応した
バージョンも⽤意されています。
Splunk がサポートしているオペレーティング・システムについては、『インストール・マニュアル』のシステム
要件に関するページを参照してください。次にユニバーサル・フォワーダーのダウンロード・ページでご利⽤の環
境に適したフォワーダーを選択します。
フォワーダーのインストーラをダウンロードしたら、デプロイ要件にもっとも適したインストールに関するトピッ
クを参照してください。インストール中またはインストール直後には、設定作業も⾏います。各インストール・ト
ピックには、インストールから設定、デプロイまで、特定のデプロイシナリオに対応する、1 つまたは複数の使⽤
事例が記載されています。
ユニバーサル・フォワーダーの詳細は、このマニュアルの「デプロイの概要」を参照してください。
Windows へのユニバーサル・フォワーダーのインストール
インストーラ GUI を使った Windows ユニバーサルフォワーダーのデプロイ
コマンドラインを使った Windows ユニバーサルフォワーダーのデプロイ
*nix へのユニバーサル・フォワーダーのインストール
nix ユニバーサルフォワーダーの⼿動デプロイ
静的設定を使った nix ユニバーサルフォワーダーのリモートデプロイ
Windows ユニバーサルフォワーダーのデプロイ
インストーラ GUI を使った Windows ユニバーサルフォワーダーの
デプロイ
重要
Splunk バージョン 6.2 のユニバーサル・フォワーダーでは、インストール⼿順が⼤幅に変更されました。新
しいインストール⼿順については、「インストール・オプション」を参照してください。
ここでは、Windows 環境でのインストーラ GUI を使ったユニバーサルフォワーダーの⼿動インストール、設
定、およびデプロイ⽅法について説明していきます。ここでは、デプロイツールを使⽤するのではなく、直接
Windows マシンにインストールすることを前提にしています。このインストール⽅法は、以下の状況やニーズに
適しています。
⼩規模なデプロイ
実証テスト⽤デプロイ
システムイメージまたは仮想マシンを利⽤した複製
22
別のデプロイ⽅法を利⽤する場合、または異なるオペレーティングシステム上にインストールする場合は、ご⾃分
のニーズに適した他のトピックを参照してください。
を使って、コマンドラインからユニバーサルフォワーダーをインストールすることもできます。コマンド
ラインによるデプロイでは、データ⼊⼒やその他の設定などに向けた、その他の設定オプションが⽤意されていま
す。詳細は、「コマンドラインを使った Windows ユニバーサルフォワーダーのデプロイ」を参照してください。
msiexec
重要： インストール後すぐにユニバーサルフォワーダーを開始したくない場合は、コマンドラインを使ってイン
ストールする必要があります 。
このトピックの⼿順を実⾏する前に、「デプロイの概要」を参照して、分散 Splunk デプロイ環境の仕組みを正し
く理解してください。
デプロイ⼿順
ユニバーサルフォワーダーをダウンロードして、「デプロイの概要」の説明に基づいてデプロイのプランニングを
完了したら、以下の作業を⾏います。
1. ユニバーサルフォワーダーをインストールします (必要に応じて移⾏や設定を⾏います)。
2. デプロイ環境のテストと調整を⾏います。
3. インストール後の設定作業を⾏います。
4. 環境へのユニバーサルフォワーダーのデプロイ
インストールの前に
ユニバーサル・フォワーダーが使⽤するアカウントの選択
ユニバーサルフォワーダーをインストールする際に、フォワーダーによるデータの取り込み元を選択することがで
きます。2 種類の⽅法があります。
ローカルシステム
ドメインアカウント
ローカルシステム ユーザーとしてインストールするように指定した場合、ユニバーサルフォワーダーはローカル
マシン上で利⽤できる任意の種類のデータを取り込めます。ただし、他のマシンからのデータを収集することはで
きません。
以下の作業を⾏う場合は、フォワーダーをドメインユーザー としてインストールする必要があります。
イベントログをリモートに読み込む
パフォーマンスカウンタをリモートに収集する
ネットワーク共有のログファイルを読み込む
Active Directory 監視を使って Active Directory スキーマを列挙する
ドメインユーザーとしてインストールした場合、モニターするデータにアクセスするユーザーを指定する必要があ
ります。リモート Windows データを収集するために必要なユーザーの要件などの概念と⼿順については、『イン
ストールマニュアル』の「Splunk を実⾏するための Windows ユーザーの選択」を参照してください。
ドメインユーザーとしてインストールする場合、ローカルマシンに対してユーザーに管理者権限を持たせるかどう
かを選択することができます。ユーザーに管理者権限を与えない場合、ユニバーサルフォワーダーでは「低権限」
モードが有効になります。低権限モードを有効にする⽅法については、このトピックの後半をご覧ください。
重要： リモート Windows データを収集するユニバーサルフォワーダーをインストールする前に、Splunk を実⾏
する (Splunk が動作する) ユーザーを選択、設定する必要があります。
リモートデータ収集のための Windows 環境の設定
リモート Windows データを収集するためのユニバーサルフォワーダーをインストールする必要がない場合は、後
述のインストール⼿順に従って作業を続⾏してください。
モニター⽬的で、リモート Windows データを収集するユニバーサルフォワーダーをインストールする必要がある
場合、Windows 環境に適切にフォワーダーをインストール、設定する必要があります。
1. ユニバーサルフォワーダーを動作させるユーザーを持つ、セキュリティグループを作成、設定します。
2. 必要に応じて、ユニバーサルフォワーダーのアカウントを管理対象アカウントとして設定します。
3. セキュリティポリシーとユーザー権限割り当て⽤の、グループポリシーオブジェクトを作成、設定します。
4. グループポリシーオブジェクトに適切なユーザー権限を割り当てます。
5. 更新された設定を持つグループポリシーオブジェクトを、適切なオブジェクトにデプロイします。
注意： これらのステップでは、⼤まかな⼿順のみを記載しています。詳細な⼿順については、『インストールマ
ニュアル』の「ネットワークまたはドメインユーザーとしての、Splunk Enterprise インストール⽤ Windows
ネットワークの準備」を参照してください。フォワーダーを低権限モードでインストールするかどうかに応じて、
いくつかの⼿順が不要になることがあります。
ユニバーサルフォワーダーのインストール
23
Windows インストーラは、ユニバーサルフォワーダーのインストールと設定プロセスを案内します。また、既存
のフォワーダーからの、チェックポイント設定を移⾏するオプションも⽤意されています。
ユニバーサルフォワーダーをインストールするには、適切な MSI ファイルをダブルクリックします。
splunkuniversalforwarder-<...>-x86-release.msi
splunkuniversalforwarder-<...>-x64-release.msi
<...>
(32 ビット版プラットフォーム⽤)
(64 ビット版プラットフォーム⽤)
の値はリリースによって異なります (例：splunkuniversalforwarder-4.2-86454-x64-release.msi)。
警告： 32 ビット版の Windows ⽤ Splunk ユニバーサル・フォワーダーを、64 ビット Windows システムにイ
ンストール、実⾏することはできなくなりました。また、サポートされていない OS が動作しているマシン (例：
Windows Server 2003 が動作するマシン) にユニバーサル・フォワーダーをインストールすることもできませ
ん。「システム要件」を参照してください。
そのような環境でインストーラを実⾏すると、警告が表⽰されインストールは⾏えません。
インストール⽅法を案内する⼀連のダイアログが表⽰されます。各ダイアログで作業を⾏った後は、[Next] (次
へ) をクリックすると次の画⾯が表⽰されます。各ダイアログを、表⽰順に以下に⽰します。
1.ユニバーサル・フォワーダーの設定⽤ダイアログ
インストールを続⾏するには、[Check this box to accept the License Agreement] (使⽤許諾契約に同意するに
はこのボックスを選択) チェック・ボックスを選択します。[Customize Installation] および [Install] ボタンが有
効になります。
注意： 使⽤許諾契約を表⽰する場合は、[View License Agreement] ボタンをクリックします。
インストール・オプション
ユニバーサル・フォワーダーのバージョン 6.2 では、デフォルト設定でのインストールと、インストール前にす
べての設定を⾏う⽅法の 2 種類のインストール⽅法が選択できるようになりました。
インストーラはデフォルトで、以下の処理を⾏います。
システム・ドライブ (Windows システムをブートするドライブ) の \Program Files\SplunkUniversalForwarder
にユニバーサル・フォワーダーをインストールします。
デフォルトの管理⽤ポートでユニバーサル・フォワーダーをインストールします。
Local System ユーザーとして実⾏する⽤にユニバーサル・フォワーダーを設定します。詳細は、このマ
ニュアルの「Splunk Enterprise を実⾏するためのユーザーの選択」を参照してください。
アプリケーション、システム、およびセキュリティ Windows イベント・ログ⼊⼒を有効にします。
2a. これらのデフォルトのインストール設定を変更する場合、[Customize Options] ボタンをクリックして、この
トピックの「オプションのカスタマイズ」の⼿順を参照してください。
2b. そうでない場合は、[インストール] ボタンをクリックします。この場合、ソフトウェアがデフォルトの設定で
インストールされます。次に、ステップ 8 に進みます。
オプションのカスタマイズ
注意： 各パネルで、続⾏する場合は [次へ] を、前のステップに戻る場合は [戻る] をクリックします。インス
トールをキャンセルしてインストーラを終了する場合は、[キャンセル] をクリックします。
3.宛先フォルダ⽤ダイアログ
24
デフォルトでユニバーサルフォワーダーは、C:\Program
ルされます。
Files\SplunkUniversalForwarder
ディレクトリにインストー
別のインストールディレクトリを指定する場合は、[Change...] (変更) をクリックします。
警告： 完全版のSplunk Enterprise がすでにインストールされているディレクトリには、ユニバーサルフォワー
ダーをインストールしないでください。完全版 Splunk Enterprise のデフォルトのインストールディレクトリは
C:\Program Files\Splunk です。デフォルト値を使⽤する限り、このような問題は発⽣しません。
4.証明書情報⽤ダイアログ
このマシンの ID を検証するための、SSL 証明書を選択します。このステップは省略することができます。
証明書の要件に応じて、証明書の ID を検証するために、パスワードやルート認証局 (CA) 証明書を指定しなけれ
ばならない場合もあります。そうでない場合、それらのフィールドは空欄でも構いません。
5.ユーザー選択⽤ダイアログ
このステップでは、選択したユーザータイプに応じて、1 つまたは 2 つのダイアログが表⽰されます。
最初のダイアログでは、ユーザーコンテキストを指定します。このコンテキストは、ユニバーサルフォワーダー
を、Local System ユーザーとして実⾏するか、またはドメインユーザーとして実⾏するかを⽰します。インス
トーラはこの情報を使って、ユニバーサルフォワーダーに必要なアクセス許可を判断します。
注意： [Local System] (ローカルシステム) を選択した場合、ユニバーサルフォワーダーは Local System ユー
ザーとしてインストールされます。セキュリティを強化するためには、この⽅法をお勧めします。ただし、ユニ
バーサルフォワーダーがリモートマシンから、イベントログや測定基準を収集する場合は、この⽅法を利⽤できま
せん。
ここでの選択内容を判断する⽬安については、前述の「インストールの前に」を参照してください。
選択が完了したら、[Next] (次へ) をクリックします。
[Local System] (ローカルシステム) を指定した場合、2 番⽬の画⾯は表⽰されず、次の [Enable Windows
Inputs] (Windows ⼊⼒を有効にする) ダイアログに移動します。
[Domain account] (ドメインアカウント) を指定した場合は、2 番⽬のダイアログでこのユニバーサルフォワー
25
ダーのドメインとユーザー情報を⼊⼒する必要があります。ユニバーサルフォワーダーは、このダイアログで指定
されたユーザーとして動作します。
重要： ユーザー名は domain\username の形式で指定する必要があります。ユーザーの指定時にドメインを含めない
と、インストールが失敗します。
2 番⽬のページの下部には、[Add user as local administrator] (ユーザーをローカル管理者として追加) チェック
ボックスがあります。このチェックボックスを選択すると (デフォルト)、指定したドメインユーザーがローカルの
Administrators グループに追加されます。このチェックボックスを選択しないと、ユニバーサルフォワーダーは
「低権限」モードでインストールされます。このモードは、サーバー上でプログラムを管理者として実⾏できな
い、または実⾏したくないお客様のために⽤意されています。詳細と注意事項については、このトピックの後半に
ある「ユニバーサルフォワーダーの低権限モードでの実⾏」を参照してください。
ローカルの管理者権限を持つユーザーとしてインストール、実⾏する場合は、このボックスを選択します。
重要： たいていの場合、指定するユーザーには、事前に適切な権限を割り当てておく必要があります。そうしな
いと、インストールが失敗する可能性があります。詳細と⼿順へのリンクについては、このトピック前半の「イン
ストールの前に」を参照してください。
注意： このダイアログは、前に受信インデクサーを指定した (前のステップで) 場合にのみ表⽰されます。
6a.Windows ⼊⼒の有効化⽤ダイアログ
リストから、1 つまたは複数の Windows ⼊⼒を選択します。
このステップは省略することができます。後ほどユニバーサルフォワーダーのディレクトリにある
編集して、⼊⼒を有効にすることもできます。
inputs.conf
を
注意： このダイアログで⼊⼒を有効にするとどうなるのかについては、このトピック後半の「インストーラで
データ⼊⼒を有効にする際の検討事項」を参照してください。
6b.Splunk Add-on for Windows ⽤ダイアログ
インストーラ・ダイアログに表⽰されたいずれかの Windows ⼊⼒を選択すると、Splunk Add-on for Windows
選択⽤ダイアログが表⽰されます。
このダイアログでは：
26
ローカル・マシン上に Splunk Add-on for Windows のコピーがインストールされていない場合は、[Install
the SPlunk Add-on for Microsoft Windows included with this installer] を選択します。または、
マシンにアドオンのローカル・コピーがインストールされている、または Splunk Apps から最新バージョ
ンをダウンロードした場合は、[Install an existing local copy of the Splunk Add-on for Microsoft
Windows] を選択します。
[Install an existing local copy of the Splunk Add-on for Microsoft Windows] を選択した場合は、[Browse] ボ
タンをクリックして、システムにインストールしたローカル・コピーを選択します。
選択が完了したら、[Next] をクリックします。
注意： このダイアログは、前に⼊⼒の選択ページで⼊⼒を選択した場合にのみ表⽰されます。
7.デプロイサーバーの指定⽤ダイアログ
デプロイサーバーのホスト名または IP アドレスと管理⽤ポートを⼊⼒します。デフォルトの管理⽤ポートは、
8089 です。
デプロイサーバー を使って、設定情報の更新をユニバーサルフォワーダーに配布できます。詳細は、『Splunk
Enterprise インスタンスの更新』マニュアルの「デプロイサーバーについて」を参照してください。
注意： このステップは省略できますが、省略した場合はステップ 6 で受信するインデクサーを指定する必要があ
ります。そうしないと、どのインデクサーにデータを転送するかを判断できないため、ユニバーサルフォワーダー
は何も作業を⾏いません。フォワーダーの設定は、後ほど設定ファイルを使って⾏えます。
8.受信インデクサーの指定⽤ダイアログ
受信するインデクサー (レシーバー) の、ホスト名または IP アドレスと受信ポート を⼊⼒します。レシーバーの
設定⽅法の詳細は、「レシーバーを有効にする」を参照してください。
注意： このステップは省略できますが、省略した場合はステップ 5 でデプロイサーバーを指定する必要がありま
す。そうしないと、どのインデクサーにデータを転送するかを判断できないため、ユニバーサルフォワーダーは何
も作業を⾏いません。このことを知らせるポップアップメッセージが表⽰されます。フォワーダーの設定は、後ほ
ど設定ファイルを使って⾏えます。
9.プログラムのインストール準備完了ダイアログ
続⾏するには、[Install] (インストール) をクリックします。
27
インストーラが実⾏され、完了するとインストール完了 ダイアログが表⽰されます。
インストールが完了したら、ユニバーサルフォワーダーが⾃動的に開始されます。SplunkForwarderは、ユニバーサ
ルフォワーダーのサービス名です。これが動作していることを確認してください。
インストーラでデータ⼊⼒を有効にする際の検討事項
ユニバーサル・フォワーダーのインストール時にデータ⼊⼒を有効にした場合、それらの⼊⼒を有効にする設定情
報はインストーラに同梱されている Splunk Add-on for Windows に保存されます。
この設定にはインデックス定義が含まれています。つまり、このフォワーダーがデータを送信するインデクサーに
は、すでにそれらのインデックスが定義されている必要があります。インデックス：
perfmon
は、パフォーマンス・モニター⼊⼒⽤です
これらのインデックスを定義してない場合、ユニバーサル・フォワーダーのインストールを実⾏する前に、イン
デックスを定義してください。
ユニバーサルフォワーダーの低権限モードでのインストール
ドメインユーザーを指定して、ユーザーにローカル管理者権限を与えない場合、フォワーダーは低権限モードでイ
ンストール、実⾏されます。
この場合、いくつかの注意事項があります。
ユニバーサルフォワーダーを低権限モードで実⾏する場合、サーバーまたはドメイン上の任意のリソースに
対して管理者アクセスはできません。
リモートリソースにアクセスするために、ドメインユーザーを他のドメイングループに追加しなければなら
ないことがあります。また、権限を持つユーザーのみが利⽤できるローカルリソースにアクセスするため
に、ユーザーをローカルグループに追加しなければならないことがあります。
⾮管理者ユーザーとして、WMI (Windows Management Instrumentation) は収集できません。
デプロイのテスト
ユニバーサルフォワーダーを環境内にデプロイする前に、単⼀のマシンにユニバーサルフォワーダーを設定、テス
トして、正常に動作することを確認してください。ユニバーサルフォワーダーが⽬的のデータを収集し、それを適
切なインデクサーに出⼒していることを確認します。デプロイモニター を使ってユニバーサルフォワーダーを検
証することもできます。
既存のフォワーダーから移⾏する場合、ユニバーサルフォワーダーが、古いフォワーダーがデータの転送を終了し
た時点からのデータを転送していることを確認してください。そうでない場合は、データ⼊⼒を変更または追加し
て、古いフォワーダーの動作と合致するように修正する必要があります。
重要： 移⾏処理で、設定ファイルが⾃動的にコピーされることはありません。ご⾃分で設定する必要がありま
す。⼀般的にはこのために、古いフォワーダーからユニバーサルフォワーダーに、inputs.conf を含めたファイル
をコピーします。ユニバーサルフォワーダーと古いフォワーダー上の inputs.conf ファイルを⽐較して、ユニバー
サルフォワーダーに⽬的の⼊⼒がすべて設定されていることを確認してください。
既存のフォワーダーから移⾏した場合、ユニバーサルフォワーダーを厳密にテストして、結果が⽬的通りであるこ
とを確認したら、古いインスタンスを削除することができます。
追加設定
インストール後にユニバーサルフォワーダーの設定を更新するには、inputs.conf や outputs.conf などの設定ファイ
ルを直接編集します。また、CLI を使って設定を更新することもできます。詳細は、「デプロイの概要」を参照
してください。
注意： CLI を使⽤する場合、コマンドの処理を完了するために、フォワーダーの認証を受けなければならないこ
とがあります。ユニバーサルフォワーダーのデフォルトの資格情報を以下に⽰します。
ユーザー名： admin
パスワード： changeme
複数のユニバーサルフォワーダーへの変更した設定の配布⽅法については、『Splunk Enterprise インスタンスの
更新』マニュアルの「デプロイサーバーについて」を参照してください。
28
環境へのユニバーサルフォワーダーのデプロイ
数台のユニバーサルフォワーダーしか必要ない場合は、⼿動インストール作業を繰り返した⽅が簡単なこともあり
ます。多数のユニバーサルフォワーダーをインストールする必要がある場合は、デプロイツールを使⽤したリモー
トデプロイまたはシステムイメージまたは仮想マシンの⼀部としてデプロイする⽅が簡単です。
ユニバーサルフォワーダーのアンインストール
ユニバーサルフォワーダーをアンインストールするには、以下の⼿順に従ってください。
1. サービス MMC スナップイン ([スタート] > [管理ツール] > [サービス] ) を使って、SplunkForwarder サービス
を停⽌します。
注意： コマンドラインから以下のコマンドを実⾏して、サービスを停⽌することもできます。
NET STOP SplunkForwarder
2. 次に、コントロールパネルの [プログラムの追加と削除] で、フォワーダーをインストールします。Windows
7、8、Server 2008、および Server 2012 の場合、このオプションは [プログラムと機能] 下にあります。
注意： 状況によっては、アンインストール時に再起動を指⽰するメッセージが表⽰される場合があります。この
リクエストを無視して再起動しなくても構いません。
コマンドラインを使った Windows ユニバーサルフォワーダーのデプ
ロイ
ここでは、Windows 環境でのコマンドラインを使ったユニバーサルフォワーダーのインストール、設定、および
デプロイ⽅法について説明していきます。GUI インストーラを使⽤する場合は、「インストーラ GUI を使った
Windows ユニバーサルフォワーダーのデプロイ」を参照してください。
コマンドラインからインストールする場合
コマンドプロンプトまたは PowerShell ウィンドウから、個別のマシンに⼿動でユニバーサルフォワーダーをイン
ストールすることができます。コマンドラインからのインストールが役に⽴つシナリオの例を以下に⽰します。
フォワーダーをインストールしたいけれども、すぐには開始したくない場合。
スクリプトを使って、フォワーダーのインストールを⾃動化したい場合。
後ほど複製するシステム上にフォワーダーをインストールしたい場合。
グループポリシーや、System Center Configuration Manager などのデプロイツールを使⽤する場合。
Windows Server Core を実⾏する場合。
ユニバーサルフォワーダーのインストールに関するその他の情報については、以下のトピックを参照してくださ
い。
ユニバーサルフォワーダーの概要については、「デプロイの概要」を参照してください。
デプロイツールとコマンドラインの使⽤については、「静的設定を使った Windows ユニバーサルフォワー
ダーのリモートデプロイ」を参照してください。
デプロイ⼿順
ユニバーサルフォワーダーをダウンロードして、「デプロイの概要」の説明に基づいてデプロイのプランニングを
完了したら、以下の作業を⾏います。
1. ユニバーサルフォワーダーをインストールします (必要に応じて設定を⾏います)。
2. デプロイ環境のテストと調整を⾏います。
3. インストール後の設定作業を⾏います。
4. 環境へのユニバーサルフォワーダーのデプロイ
インストールの前に
ユニバーサルフォワーダーを実⾏する Windows ユーザーの選択
ユニバーサルフォワーダーをインストールする場合、それを実⾏するユーザーを選択することができます。デフォ
ルトで、このユーザーは Local System です。ドメインアカウントを指定する場合は、後述する LOGON_USERNAME お
よび LOGON_PASSWORD フラグを使⽤します。
フォワーダーを、ローカルマシンの管理者ではないユーザーとしてインストールすることもできます。フォワー
ダーを「低権限」モードでインストールする場合は、SET_ADMIN_USER フラグを使⽤します。
フォワーダーを Local System ユーザーとしてインストールする場合、そのフォワーダーはローカルマシン上で利
⽤できる任意の種類のデータを収集することができます。ただし、他のマシンからのデータを収集することはでき
ません。これは仕様です。
以下の事項を⾏う場合は、ユニバーサルフォワーダーにユーザーアカウントを割り当てる必要があります。
イベントログをリモートに読み込む
29
パフォーマンスカウンタをリモートに収集する
ネットワーク共有のログファイルを読み込む
Active Directory 監視を使って Active Directory スキーマを列挙する
リモート Windows データを収集するために必要なユーザーの要件などの概念と⼿順については、『インストール
マニュアル』の「Splunk を実⾏するための Windows ユーザーの選択」を参照してください。
重要： リモート Windows データを収集するユニバーサルフォワーダーをインストールする前に、Splunk を実⾏
する (Splunk が動作する) ユーザーを選択、設定する必要があります。そうしないと、インストールが失敗する可
能性があります。
インストール前の Windows 環境の設定
フォワーダーを正しくインストールするために、Windows 環境を設定するには、以下の⼿順に従ってください。
1. ユニバーサルフォワーダーを動作させるユーザーを持つ、セキュリティグループを作成、設定します。
2. 必要に応じて、ユニバーサルフォワーダーのアカウントを管理対象アカウントとして設定します。
3. ユーザー権限割り当て⽤の、グループポリシーまたはローカルセキュリティポリシーオブジェクトを作成、設定
します。
4. 適切なセキュリティ設定を割り当てます。
5. Active Directory を使⽤する場合、更新された設定を持つグループポリシーオブジェクトを、適切なオブジェ
クトにデプロイします。
注意： これらのステップでは、⼤まかな⼿順のみを記載しています。詳細な⼿順については、『インストールマ
ニュアル』の「ネットワークまたはドメインユーザーとしての、Splunk Enterprise インストール⽤ Windows
ネットワークの準備」を参照してください。
ユニバーサルフォワーダーのインストール
コマンドラインから Microsoft のインストーラプログラム
インストールすることができます。
msiexec.exe
を実⾏して、ユニバーサルフォワーダーを
32 ビット版プラットフォームの場合は、splunkuniversalforwarder-<...>-x86-release.msi を使⽤します。
msiexec.exe /i splunkuniversalforwarder-<...>-x86-release.msi [<flag>]... [/quiet]
64 ビット版プラットフォームの場合は、splunkuniversalforwarder-<...>-x64-release.msi を使⽤します。
msiexec.exe /i splunkuniversalforwarder-<...>-x64-release.msi [<flag>]... [/quiet]
<...>
の値はリリースによって異なります (例：splunkuniversalforwarder-4.2-86454-x64-release.msi)。
重要： 64 ビットプラットフォーム上では、32 ビット版のユニバーサルフォワーダーを使⽤しないことをお勧め
します。
コマンドラインのフラグにより、インストール時にフォワーダーを設定することができます。コマンドラインフラ
グを使⽤して、さまざまな事項を指定できます。以下に例を⽰します。
ユニバーサルフォワーダーを実⾏するユーザー。(指定するユーザーには、転送するデータにアクセスするた
めの適切な権限が必要です。)
フォワーダーを「低権限モード」で (ローカル管理者権限のないユーザーとして) 実⾏するかどうか。
ユニバーサルフォワーダーがデータを転送する、受信側 Splunk Enterprise インスタンス。
設定を更新するデプロイサーバー。
インデックスを作成する Windows イベントログ。
インストール完了時にユニバーサルフォワーダーを⾃動的に開始するかどうか。
利⽤できるフラグの⼀覧および各種設定例は、以下のセクションに記載されています。
サポートしているフラグ⼀覧
重要： 完全版の Splunk Enterprise インストーラは、別個の実⾏形式ファイルで、独⾃のインストールフラグが
⽤意されています。『インストールマニュアル』の「Windows へのインストール」を参照してください。
フラグ
その⽬的
デフォルト
AGREETOLICENSE=Yes|No
EULA に同意する場合にこのフラ
グを使⽤します。サイレントイン
ストールを⾏うには、このフラグ
に Yes を設定する必要がありま
す。
No
INSTALLDIR="<directory_path>"
インストールディレクトリを指定
します。
c:\Program
重要： 完全版のSplunk
Enterprise がすでにインストール
30
Files\SplunkUniversalForwarder
されている場合、そのディレクト
リにはユニバーサルフォワーダー
をインストールしないで くださ
い。
LOGON_USERNAME="<domain\username>"
LOGON_PASSWORD="<pass>"
RECEIVING_INDEXER="<host:port>"
SplunkForwarder
サービスを実⾏す
るユーザーの、ドメイン\ユー
ザー名およびパスワードを指定す
る場合に、これらのフラグを使⽤
します。ドメインとユーザー名は
次の形式で指定する必要がありま
す：domain\username。これらのフ
ラグを指定しない場合、ユニバー
サルフォワーダーは Local
System ユーザーとしてインス
トールされます。「Splunk を実
⾏するためのユーザーの選択」を
参照してください。
N/A
ユニバーサルフォワーダーがデー
タを転送する、受信側インデク
サーを指定する場合に使⽤しま
す。レシーバーの、ホスト名また
は IP アドレスと受信ポート を⼊
⼒します。このフラグには、単⼀
のレシーバーのみを指定できま
す。複数のレシーバーを指定する
には (ロードバランシングを利⽤
するために)、CLI または
outputs.conf を使って設定する必
要があります。
N/A
レシーバーの設定⽅法の詳細は、
「レシーバーを有効にする」を参
照してください。注意： このフラ
グは省略することができます。た
だし、指定しない場合
に、DEPLOYMENT_SERVER も指定しな
いと、転送先インデクサーを判断
できないため、ユニバーサルフォ
ワーダーは機能しません。
DEPLOYMENT_SERVER="<host:port>"
設定ファイルの更新をユニバーサ N/A
ルフォワーダーに配布する、デプ
ロイサーバー を指定する場合に使
⽤します。デプロイサーバー名
(ホスト名または IP アドレス) と
ポートを⼊⼒してください。
注意： このフラグは省略すること
ができます。ただし、指定しない
場合に、RECEIVING_INDEXER も指定
しないと、転送先インデクサーを
判断できないため、ユニバーサル
フォワーダーは機能しません。
LAUNCHSPLUNK=1|0
インストール完了時に、ユニバー
サルフォワーダーを⾃動的に起動
するかどうかを指定する場合に使
⽤します。
1 (はい)
SERVICESTARTTYPE=auto|manual
システム再起動時に、ユニバーサ
ルフォワーダーを⾃動的に開始す
るかどうかを指定する場合に使⽤
します。
auto
注意： LAUNCHSPLUNK に 0
を、SERVICESTARTTYPE に auto を設
定すると、次回のシステムブート
時まで、ユニバーサルフォワー
ダーはデータの転送を⾏いませ
ん。この設定は、システムイメー
ジを複製する場合に役⽴ちます。
MONITOR_PATH="<directory_path>"
モニター対象ファイルまたはディ
レクトリを指定する場合に使⽤し
ます。
N/A
それぞれ以下の Windows イベン
トログを有効にする場合に、これ
らのフラグを使⽤します。
0 (いいえ)
31
WINEVENTLOG_APP_ENABLE=1|0
application
WINEVENTLOG_SEC_ENABLE=1|0
security
WINEVENTLOG_SYS_ENABLE=1|0
WINEVENTLOG_FWD_ENABLE=1|0
system
forwarders
setup
WINEVENTLOG_SET_ENABLE=1|0
注意： 複数のフラグを指定するこ
とができます。
PERFMON=<input_type>,<input_type>,...
perfmon ⼊⼒を有効にする場合に N/A
使⽤します。<input_type>には、次
のいずれかの値を使⽤できます：
cpu memory network diskspace
ENABLEADMON=1|0
CERTFILE=<c:\path\to\certfile.pem>
ROOTCACERTFILE=<c:\path\to\rootcacertfile.pem>
CERTPASSWORD=<password>
リモートデプロイ⽤に Active
Directory のモニターを有効にす
る場合に使⽤します。
0 (無効)
SSL 証明書を指定する場合に、こ
れらのフラグを使⽤します。
N/A
公開鍵/秘密鍵のペアを含む証明
書ファイルへのパス。
CERTFILE が正規のものかどうか
を検証するための、ルート認証局
証明書を含むファイルへのパス
(省略可)。
CERTFILE の秘密鍵のパスワード
(省略可)。
注意： これらのフラグを使⽤する
場合は、RECEIVING_INDEXER を設定
する必要があります。
CLONEPREP=1|0
マシンの複製を作成する準備とし
て、インスタンス固有のデータを
削除します。これにより、CLI か
ら splunk clone-prep コマンドが実
⾏されます。
0 (インスタンスの複製準備
処理を⾏わない)
SET_ADMIN_USER=1|0
指定したユーザーが管理者かどう
かを⽰します。このフラグに 0 を
設定すると、ユニバーサルフォ
ワーダーは「低権限」モードで動
作します (ローカルマシンの管理
者権限を持たないユーザーとして
実⾏される)。このモードは、サー
バー上でプログラムを管理者とし
て実⾏できないお客様のために⽤
意されています。詳細と注意事項
については、このトピックの後半
にある「ユニバーサルフォワー
ダーの低権限モードでの実⾏」を
参照してください。
1 (ユニバーサルフォワー
ダーを管理者権限を持つユー
ザーとしてインストールしま
す。ユニバーサルフォワー
ダーは「低権限」モードでは
なく、標準モードで実⾏され
ます。)
重要： このフラグを使⽤する場
合、LOGON_USERNAME および
LOGON_PASSWORD の両⽅のフラグを設
定する必要があります。フォワー
ダーを Local System ユーザーと
してインストールする場合 (これ
らのフラグを指定しない場合のデ
フォルト)、このフラグは無視され
ます。
ユニバーサルフォワーダーの低権限モードでのインストール
および LOGON_PASSWORD フラグを設定し、SET_ADMIN_USER=0 を指定した場合、フォワーダーは「低権
限」モードでインストール、実⾏されます。この場合、フォワーダーが動作するサーバー上の、管理者権限を持た
ないユーザーを指定することができます。
LOGON_USERNAME
また、いくつかの注意事項があります。
32
ユニバーサルフォワーダーを低権限モードで実⾏する場合、サーバーまたはドメイン上の任意のリソースに
対して管理者アクセスはできません。
リモートリソースにアクセスするために、ドメインユーザーを他のドメイングループに追加しなければなら
ないことがあります。また、権限を持つユーザーのみが利⽤できるローカルリソースにアクセスするため
に、ユーザーをローカルグループに追加しなければならないことがあります。
⾮管理者ユーザーとして、WMI (Windows Management Instrumentation) は収集できません。
ユニバーサルフォワーダーのサイレントインストール
サイレントインストールを実⾏する場合、インストールコマンド⽂字列の最後に
す。AGREETOLICENSE=Yes フラグも設定する必要があります。
/quiet
を指定しま
システムで UAC が有効になっている場合 (⼀部のシステムではデフォルト)、Administrator (管理者) としてイン
ストールを実⾏する必要があります。そのためには、コマンドプロンプトを表⽰する際に、右クリックして [管理
者として実⾏] を選択します。次にコマンドプロンプトから、サイレントインストール⽤のコマンドを実⾏しま
す。
インストール中の詳細ログの記録を有効にする
ユニバーサルフォワーダーのインストール時に詳細なログを記録するには、msiexec の
す。詳細は以下の例を参照してください。
/l
オプションを使⽤しま
例
さまざまなフラグの使⽤例を以下に⽰します。
Local System ユーザーとして動作し、deploymentserver1 から設定を取得するようにユニバーサルフォ
ワーダーをインストールする
フォワーダーを新たにデプロイする場合などに、この作業を⾏います。
msiexec.exe /i splunkuniversalforwarder_x86.msi DEPLOYMENT_SERVER="deploymentserver1:8089" AGREETOLICENSE=Yes /quiet
ドメインユーザーとして動作するが、即座には起動しないようにユニバーサルフォワーダーをインストール
する
複製⽤のサンプルホストを準備する場合などに使⽤します。
msiexec.exe /i splunkuniversalforwarder_x86.msi LOGON_USERNAME="AD\splunk" LOGON_PASSWORD="splunk123"
DEPLOYMENT_SERVER="deploymentserver1:8089" LAUNCHSPLUNK=0 AGREETOLICENSE=Yes /quiet
インストーラをサイレントモードで実⾏し、ユニバーサルフォワーダーをインストールして Windows セ
キュリティログとシステムイベントログのインデックス作成を有効にする
サイレントインストールを利⽤して、セキュリティログおよびシステムイベントログを収集するように設定しま
す。
msiexec.exe /i splunkuniversalforwarder_x86.msi RECEIVING_INDEXER="indexer1:9997" WINEVENTLOG_SEC_ENABLE=1
WINEVENTLOG_SYS_ENABLE=1 AGREETOLICENSE=Yes /quiet
ユニバーサルフォワーダーを低権限モードでインストールして、ログファイルへの詳細ログの記録を有効に
する
ローカルサーバー上の管理者権限を持たないユーザーとしてフォワーダーを実⾏する場合に、このような作業を⾏
います。
msiexec.exe /i splunkuniversalforwarder_x64.msi /l*v install_splunkforwarder-6.1-201357-x64-release.msi.log
LOGON_USERNAME=adtest1\lowpriv-testuser LOGON_PASSWORD=win1@splunk
AGREETOLICENSE=Yes SET_ADMIN_USER=0 /quiet
デプロイのテスト
ユニバーサルフォワーダーを環境内にデプロイする前に、単⼀のマシンにユニバーサルフォワーダーを設定、テス
トして、正常に動作することを確認してください。ユニバーサルフォワーダーが⽬的のデータを収集し、それを適
切なインデクサーに出⼒していることを確認します。デプロイモニター を使ってユニバーサルフォワーダーを検
証することもできます。
既存のフォワーダーから移⾏する場合、ユニバーサルフォワーダーが、古いフォワーダーがデータの転送を終了し
た時点からのデータを転送していることを確認してください。そうでない場合は、データ⼊⼒を変更または追加し
て、古いフォワーダーの動作と合致するように修正する必要があります。
重要： 移⾏処理で設定ファイルが⾃動的にコピーされることはありません。⼿動で設定する必要があります。⼀
般的にはこのために、古いフォワーダーからユニバーサルフォワーダーに、inputs.conf を含めたファイルをコ
ピーします。ユニバーサルフォワーダーと古いフォワーダー上の inputs.conf ファイルを⽐較して、ユニバーサル
33
フォワーダーに⽬的の⼊⼒がすべて設定されていることを確認してください。
既存のフォワーダーから移⾏した場合、ユニバーサルフォワーダーを厳密にテストして、結果が⽬的通りであるこ
とを確認したら、古いインスタンスを削除することができます。
追加設定
インストール後にユニバーサルフォワーダーの設定を更新するには、inputs.conf や outputs.conf などの設定ファイ
ルを直接編集します。また、CLI を使って設定を更新することもできます。詳細は、「デプロイの概要」を参照
してください。
注意： CLI を使⽤する場合、コマンドの処理を完了するために、フォワーダーの認証を受けなければならないこ
とがあります。ユニバーサルフォワーダーのデフォルトの資格情報を以下に⽰します。
ユーザー名： admin
パスワード： changeme
複数のユニバーサルフォワーダーへの変更した設定の配布⽅法については、『Splunk Enterprise インスタンスの
更新』マニュアルの「デプロイサーバーについて」を参照してください。
環境へのユニバーサルフォワーダーのデプロイ
数台のユニバーサルフォワーダーしか必要ない場合は、コマンドラインによる⼿動インストール作業を繰り返した
⽅が簡単なこともあります。多数のユニバーサルフォワーダーをインストールする必要がある場合は、デプロイ
ツールを使⽤したリモートデプロイまたはシステムイメージまたは仮想マシンの⼀部としてデプロイする⽅が簡単
です。
ユニバーサルフォワーダーのアンインストール
ユニバーサルフォワーダーをアンインストールするには、以下の⼿順に従ってください。
1. コマンドラインから以下のコマンドを実⾏して、サービスを停⽌します。
NET STOP SplunkForwarder
注意： サービス MMC スナップイン ([スタート] > [管理ツール] > [サービス] ) を使って、SplunkForwarder サー
ビスを停⽌することもできます。
2. 次に、Microsoft インストーラを実⾏してアンインストールを実⾏します：
msiexec /u splunkuniversalforwarder-<...>-x86-release.msi
インストーラによるアンインストール時には、1 つのフラグを使⽤することができます。
フラグ
REMOVE_FROM_GROUPS=1|0
その⽬的
デフォルト
このフラグは、ユニバーサルフォワーダーのアンイ
ンストール時にのみ使⽤できます。 フォワーダーと
してインストールしたユーザーから、権限と管理グ
ループメンバーシップを削除するかどうかを指定しま
す。
1 (アンインストール
時に昇格された権限
とグループメンバー
シップを削除する)
このフラグに 1 を設定すると、フォワーダーとしてイ
ンストールされたユーザーから、グループメンバー
シップと昇格された権限が削除されます。
このフラグに 0 を設定すると、ユーザーからグループ
メンバーシップと昇格された権限は削除されません。
注意： 状況によっては、アンインストール時に再起動を指⽰するメッセージが表⽰される場合があります。この
リクエストを無視して再起動しなくても構いません。
静的設定を使った Windows ユニバーサルフォワーダーのリモートデ
プロイ
⼀般的には以下のような理由で、静的設定を使ってユニバーサルフォワーダーをデプロイします。
後ほど設定を変更する必要がない。
System Center Configuration Manager、Altris、または BigFix/Tivoli などの⾮ Splunk デプロイツール
を使って、インストール後の変更を実施する。
このような種類のデプロイでは、Windows のコマンドラインを使ってインストールを⾏います。インストール時
には、すべての設定オプションを指定して、サイレントモード (/quiet) で実⾏する必要があります。コマンドライ
ンインターフェイスおよびサポートされているフラグ (低権限モードを有効にするものも含む) については、「コ
マンドラインを使った Windows ユニバーサルフォワーダーのデプロイ」を参照してください。
デプロイ⼿順
ユニバーサルフォワーダーをダウンロードして、「デプロイの概要」の説明に基づいてデプロイのプランニングを
34
完了したら、以下の作業を⾏います。
1. コマンドラインで適切なフラグを指定して、テストマシン上にユニバーサルフォワーダーをインストール、設定
します。
2. デプロイ環境のテストと調整を⾏います。
3. テストしたフラグを指定して、ユニバーサルフォワーダー MSI をデプロイツールに読み込みます。
4. デプロイツールでデプロイを実⾏します。
5. デプロイモニター を使って、ユニバーサルフォワーダーが動作していることを確認します。
必要なインストールフラグ
/quiet
モードを指定するだけでなく、最低でも以下のフラグを指定する必要があります。
AGREETOLICENSE=Yes
RECEIVING_INDEXER="<server:port>"
WINEVENTLOG_APP_ENABLE=1
など、最低 1 つのデータ⼊⼒フラグ。必要に応じて任意の数のデータ⼊⼒フラグを
追加できます。
利⽤可能なコマンドラインフラグの⼀覧については、「コマンドラインを使った Windows ユニバーサルフォワー
ダーのデプロイ」を参照してください。
インストールの例
この例では、Windows セキュリティおよびシステムイベントログを収集し、それを indexer1 に転送する、⾃動起
動して Local System ユーザーとして動作するユニバーサルフォワーダーを設定します。
msiexec.exe /i splunkuniversalforwarder_x86.msi RECEIVING_INDEXER="indexer1:9997" WINEVENTLOG_SEC_ENABLE=1
WINEVENTLOG_SYS_ENABLE=1 AGREETOLICENSE=Yes /quiet
設定の安全なデプロイ
安全に設定をデプロイするために、SSL 証明書を指定することができます。以下のインストールフラグを使⽤し
ます。
CERTFILE=<c:\path\to\certfile.pem>
ROOTCACERTFILE=<c:\path\to\rootcacertfile.pem>
CERTPASSWORD=<password>
詳細は、「サポートしているコマンドラインフラグ」を参照してください。
デプロイのテスト
ユニバーサルフォワーダーを環境内にデプロイする前に、単⼀のマシンにユニバーサルフォワーダーを設定、テス
トして、正常に動作することを確認してください。ユニバーサルフォワーダーが⽬的のデータを収集し、それを適
切なインデクサーに出⼒していることを確認します。デプロイモニター を使ってユニバーサルフォワーダーを検
証することもできます。
ユニバーサルフォワーダーをシステムイメージの⼀部にする
ここでは、システムイメージまたは仮想マシンの⼀部としてユニバーサルフォワーダーをデプロイする⽅法につい
て説明していきます。この⽅法は、多数のユニバーサルフォワーダーをデプロイする必要がある場合に特に役⽴ち
ます。数台のユニバーサルフォワーダーのみをインストールする場合は、Windows および nix マシンで説明する
ように、⼿動でインストールする⽅が簡単なこともあります。
このトピックの⼿順を実施する前に、「デプロイの概要」を参照してください。
デプロイ⼿順
ユニバーサルフォワーダーをダウンロードして、「デプロイの概要」の説明に基づいてデプロイのプランニングを
完了したら、以下の作業を⾏います。
1. テスト⽤マシンにユニバーサルフォワーダーをインストールします。以下を参照してください。
2. インストール後の設定作業を⾏います。ここを参照してください。
3. デプロイのテストと調整を⾏います。ここを参照してください。
4. テストした設定で、ユニバーサルフォワーダーをソースマシンにインストールします。
5. ユニバーサルフォワーダーを停⽌します。
6. フォワーダー上で以下の CLI コマンドを実⾏してください。
35
./splunk clone-prep-clear-config
これにより、サーバー名や GUID などの、インスタンス固有の情報が消去されます。この情報は、複製された各
フォワーダーの初期起動時に設定されます。
7. イメージまたは仮想マシンを、複製⽤に準備します。
8. *nix システムで、cron または任意のスケジューリングシステムを使って、ブート時に splunkd デーモンを開始
するように設定します。Windows の場合は、サービスに Automatic を設定します。ただし、サービスを開始しな
いでください。
9. システムイメージまたは仮想マシンの複製を、環境内の各マシンに配布して、起動します。
10. デプロイモニター を使って、複製されたユニバーサルフォワーダーが動作していることを確認します。
参考⼿順
上記のデプロイ⼿順は、これらのサブトピックを参考にしています。
ユニバーサルフォワーダーのインストール
オペレーティングシステム固有の⼿順を使って、ユニバーサルフォワーダーをインストールします。
*nix マシンにインストールする場合 は、「nix ユニバーサルフォワーダーの⼿動デプロイ」を参照してく
ださい。
Windows マシンの場合 は、インストーラ GUI またはコマンドラインインターフェイスを使⽤することが
できます。GUI を使ってインストールする場合は、「インストーラ GUI を使った Windows ユニバーサル
フォワーダーのデプロイ」を参照してください。コマンドラインインターフェイスについては、「コマンド
ラインを使った Windows ユニバーサルフォワーダーのデプロイ」を参照してください。
重要： Windows マシン上で、インストール後すぐにユニバーサルフォワーダーを開始したくない場合は、コマン
ドラインを使ってインストールする必要があります 。適切なフラグを使⽤して、インストール時にはユニバーサ
ルフォワーダーを起動せずに、複製がアクティブ化された時に⾃動的に開始するように設定することができます。
インストール時にユニバーサルフォワーダーを設定することもできます。「デプロイの概要」の「⼀般的な設定に
関する問題」を参照してください。
追加設定
インストール後にユニバーサルフォワーダーの設定を更新するには、inputs.conf や
ルを直接編集します。詳細は、「デプロイの概要」を参照してください。
outputs.conf
などの設定ファイ
複数のユニバーサルフォワーダーへの変更した設定の配布⽅法については、『Splunk Enterprise インスタンスの
更新』マニュアルの「デプロイサーバーについて」を参照してください。
デプロイのテスト
ユニバーサルフォワーダーを環境内にデプロイする前に、単⼀のマシンにユニバーサルフォワーダーを設定、テス
トして、正常に動作することを確認してください。ユニバーサルフォワーダーが⽬的のデータを収集し、それを適
切なインデクサーに出⼒していることを確認します。デプロイモニター を使ってユニバーサルフォワーダーを検
証することもできます。
Windows ライトフォワーダーの移⾏
既存のライトフォワーダーをユニバーサルフォワーダーに置換するには、チェックポイントデータを新しいフォ
ワーダーに移⾏する必要があります。チェックポイントデータは、フォワーダーがインデクサーに転送したデータ
を追跡するために使⽤する内部データです。チェックポイント・データを移⾏することで、新しいユニバーサル・
フォワーダーが、古いライト・フォワーダーがすでに転送したデータを送信することを防⽌できます。これによ
り、同じデータのインデックスが 2 回作成されることはありません。
既存の Windows ライトフォワーダー (バージョン 4.0 以上) からユニバーサルフォワーダーに、チェックポイン
トデータを移⾏することができます。移⾏の概要については、「ライトフォワーダーからの移⾏」を参照してくだ
さい。
移⾏する場合は、インストールプロセス中に実施する必要があります。インストール後に移⾏することはでき
ません。
Windows インストールは、インストーラ GUI またはコマンドラインを使って実⾏します。
インストーラ GUI を使⽤する場合 、移⾏するかどうかを問い合わせる画⾯が表⽰されます。GUI を使っ
たインストール⼿順の概要は、「インストーラ GUI を使った Windows ユニバーサルフォワーダーのデプ
ロイ」を参照してください。
コマンドラインを使ってインストールする場合 、移⾏するために MIGRATESPLUNK=1 フラグを指定します。サ
ポートしているフラグの⼀覧と、それを使ったインストールの設定⽅法については、「コマンドラインを
使った Windows ユニバーサルフォワーダーのデプロイ」を参照してください。
重要： ユニバーサル・フォワーダーは、既存のライト・フォワーダーとは別のディレクトリにインストールする
必要があります。ユニバーサルフォワーダーのデフォルトのインストールディレクトリは C:\Program
Files\SplunkUniversalForwarder、完全版 Splunk Enterprise (ライトフォワーダーを含む) のデフォルトのインス
36
トールディレクトリは
C:\Program Files\Splunk
なので、デフォルト値を使⽤する限りは何の問題もありません。
インストーラが⾏う処理
どちらのインストール⽅法を使⽤する場合でも、Windows インストーラは以下の処理を⾏います。
1. マシン上の既存のヘビー/ライト・フォワーダーを探します。
2. フォワーダーが移⾏対象 (バージョン 4.0 以降) であるかどうかを判断します。
3. 移⾏対象にできるフォワーダーが⾒つかった場合は、移⾏するかどうかを問い合わせる画⾯を表⽰します。(コ
マンド・ラインを使⽤している場合は、MIGRATESPLUNK=1 フラグが指定されているかどうかを確認します。)
4. ユーザーが移⾏することを選択した場合 (または、MIGRATESPLUNK=1 フラグが指定されている場合)、インストーラ
は既存のフォワーダーの動作中のサービス (splunkd や splunkweb を含む) をすべてシャットダウンします。ま
た、起動タイプを⼿動に設定します。そのため、再起動時に⾃動的には開始されません。
5. チェックポイント・ファイルをユニバーサル・フォワーダーに移⾏します。
6. ユニバーサル・フォワーダーのインストールと設定を完了します。
⾏う必要がある作業
このプロセスの最後に、ユニバーサルフォワーダーで追加の設定作業を⾏うことができます。移⾏プロセスは
チェックポイントファイルのみをコピーします。古いフォワーダーの inputs.conf 設定ファイルを⼿動でコピーす
る (または、このファイルを参照して、モニター対象のデータ⼊⼒を確認する) ことができます。
ユニバーサルフォワーダーを稼働したら (そして正常に動作していることを確認したら)、古いフォワーダーをアン
インストールすることができます。
nix ユニバーサルフォワーダーのデプロイ
*nix ユニバーサルフォワーダーの⼿動デプロイ
このトピックでは、Linux や Solaris などの *nix 環境に、ユニバーサルフォワーダーを⼿動で設定、デプロイす
る⽅法を説明していきます。ここでは、デプロイツールを使⽤するのではなく、直接 *nix マシンにインストール
することを前提にしています。この種類のデプロイは、以下のニーズに適しています。
⼩規模なデプロイ
実証テスト⽤デプロイ
システムイメージまたは仮想マシンを利⽤した複製
別のデプロイ⽅法を利⽤する場合は、ご⾃分のニーズに適した他のトピックを参照してください。
このトピックの⼿順を実施する前に、「デプロイの概要」を参照してください。
デプロイ⼿順
ユニバーサルフォワーダーをダウンロードして、「デプロイの概要」の説明に基づいてデプロイのプランニングを
完了したら、以下の作業を⾏います。
1. ユニバーサルフォワーダーをインストールします。
2. ユニバーサルフォワーダーを設定します (必要に応じて移⾏を⾏います)。
3. デプロイ環境のテストと調整を⾏います。
4. インストール後の後処理作業を⾏います。
ユニバーサルフォワーダーのインストール
パッケージまたは tar ファイルを使って、*nix マシンにユニバーサルフォワーダーをインストールすることができ
ます。サポートしている *nix 環境にユニバーサルフォワーダーをインストールするには、『インストールマニュ
アル』の *nix インストールに関連する以下のトピックを参照してください。
Linux へのインストール
Solaris へのインストール
Mac OS X へのインストール
FreeBSD へのインストール
AIX へのインストール
HP-UX へのインストール
ユニバーサルフォワーダーは、完全版の Splunk Enterprise インスタンスと同じ⽅法でインストールします。
『インストールマニュアル』のこれらのトピックを参照してください。ただし、2 つの違いが存在しています。
パッケージ名。
デフォルトのインストールディレクトリ。
パッケージ名
37
パッケージをインストールする場合、『インストールマニュアル』のコマンドで使⽤されている完全版 Splunk
Enterprise パッケージ名の代わりに、ユニバーサルフォワーダーのパッケージ名を使⽤します。
たとえば、Red Hat Linux にユニバーサルフォワーダーをインストールする場合、以下のコマンドを使⽤しま
す。
rpm -i splunkforwarder_<package_name>.rpm
これを、以下の完全版 Splunk Enterprise インスタンスのコマンドの代わりに使⽤します。
rpm -i splunk_<package_name>.rpm
違いは、パッケージ名のプリフィックスのみです。「splunk」の代わりに「splunkforwarder」を使⽤します。
デフォルトのインストールディレクトリ
ユニバーサルフォワーダーはデフォルトで、/opt/splunkforwarder にインストールされます。(完全版 Splunk のデ
フォルトのインストールディレクトリは /opt/splunk です。)
重要： 完全版のSplunk Enterprise がすでにインストールされている場合、そのディレクトリにはユニバーサル
フォワーダーをインストールしないで ください。このことは、特にライトフォワーダーから移⾏する場合 (「nix
ライトフォワーダーの移⾏」を参照) に重要になります。
ユニバーサルフォワーダーの設定
ユニバーサルフォワーダーは、ローカルシステム上のユーザーとして動作することができます。ユニバーサルフォ
ワーダーを⾮ root ユーザーとして実⾏する場合は、指定した⼊⼒からデータを読み込むために⼗分な権限を持っ
ていることを確認してください。詳細は、Splunk を⾮ root ユーザーとして動作させる⽅法の説明を参照してく
ださい。
設定の⼀環として、既存のフォワーダーからユニバーサルフォワーダーにチェックポイント設定を移⾏することが
できます。「デプロイの概要」を参照してください。
ユニバーサルフォワーダーの開始と設定には、CLI を使⽤します。
ユニバーサルフォワーダーの開始
重要： 既存のフォワーダーから移⾏したい場合は、初めてユニバーサルフォワーダーを起動する前に、⼀連のア
クションを実⾏する必要があります。詳細は、「nix フォワーダーの移⾏」を参照してください。
ユニバーサルフォワーダーを開始するには、$SPLUNK_HOME/bin ディレクトリから以下のコマンドを実⾏します
($SPLUNK_HOME は、ユニバーサルフォワーダーのインストールディレクトリです)。
splunk start
使⽤許諾契約の⾃動承認
新たにインストールした後初めてユニバーサルフォワーダーを起動する場合、使⽤許諾契約に同意する必要があり
ます。1 ステップでユニバーサルフォワーダーを開始して使⽤許諾契約に同意するには：
splunk start --accept-license
注意： accept-license オプションの前には 2 つのダッシュがあります。
設定⼿順
ユニバーサルフォワーダーを開始して、使⽤許諾契約に同意したら、以下の⼿順に従って設定を⾏います。
1. ユニバーサルフォワーダーが⾃動起動するように設定します。
splunk enable boot-start
2. ユニバーサルフォワーダーがデプロイクライアント として動作するように設定します (オプション)。このため
には、単純にデプロイサーバーを指定します。
splunk set deploy-poll <host>:<port>
ここで：
<host>
はデプロイサーバーのホスト名または IP アドレス、<port> は待機するポートです。
このステップでは、デプロイクライアントの機能も⾃動的に有効になります。
38
3. ユニバーサルフォワーダーが指定したインデクサー (レシーバー) にデータを転送するように設定します (オプ
ション)。
splunk add forward-server <host>:<port> -auth <username>:<password>
ここで：
は受信側インデクサーのホスト名または IP アドレス、<port> はそれが待機するポートです。通常は、
レシーバーはポート 9997 でフォワーダーからのデータを待機しますが、任意のポートで待機するように設
定することができます。そのため、レシーバーの管理者に、ポート番号を確認する必要があります。レシー
バーの設定⽅法の詳細は、「レシーバーを有効にする」を参照してください。
<host>
は、フォワーダーにログインするためのユーザー名とパスワードです。デフォルトは、
「admin:changeme」です (デフォルト値とは異なるパスワードを設定する場合は、コマンド「splunk edit
user admin -password <new password> -role admin -auth admin:changeme」を実⾏します)。
<username>:<password>
このステップでは、Splunk 間の通信⽤に証明書を設定することもできます。⼀連の SSL ⽤フラグを使⽤して、
証明書、ルート認証局、およびパスワードを指定します。例：
splunk add forward-server <host>:<port> -ssl-cert-path /path/ssl.crt -ssl-root-ca-path /path/ca.crt -ssl-password
<password>
注意： インデクサーを指定しない場合は、後ほど受信側のインデクサーを設定できるように、ユニバーサルフォ
ワーダーがデプロイクライアントとして動作するように設定する必要があります (ステップ 2 を参照)。
4. ユニバーサルフォワーダーの⼊⼒を設定するには、CLI コマンドの add を使⽤するか、または inputs.conf を編
集します。CLI の使⽤⽅法の詳細は、「CLI について」およびそれ以降のトピックを参照してください。
ユニバーサルフォワーダーがサポートする CLI コマンドの⼀覧は、「サポートしている CLI コマンド」を参照し
てください。
デプロイのテスト
ユニバーサルフォワーダーを環境内にデプロイする前に、単⼀のマシンにユニバーサルフォワーダーを設定、テス
トして、正常に動作することを確認してください。ユニバーサルフォワーダーが⽬的のデータを収集し、それを適
切なインデクサーに出⼒していることを確認します。デプロイモニター を使ってユニバーサルフォワーダーを検
証することもできます。
既存のフォワーダーから移⾏する場合、ユニバーサルフォワーダーが、古いフォワーダーがデータの転送を終了し
た時点からのデータを転送していることを確認してください。そうでない場合は、データ⼊⼒を変更または追加し
て、古いフォワーダーの動作と合致するように修正する必要があります。2 つの inputs.conf ファイルを調査し
て、新しいユニバーサルフォワーダーが必要なすべての⼊⼒を保持しているかどうかを確認してください。
既存のフォワーダーから移⾏した場合、ユニバーサルフォワーダーを厳密にテストして、結果が⽬的通りであるこ
とを確認したら、古いインスタンスを削除することができます。
トラブルシューティングのヒントについては、「デプロイのトラブルシューティング」を参照してください。
追加設定
CLI を使⽤するだけでなく、inputs.conf や outputs.conf などの設定ファイルを直接編集することで、ユニバーサル
フォワーダーの設定を更新することができます。詳細は、「デプロイの概要」を参照してください。
複数のユニバーサルフォワーダーへの変更した設定の配布⽅法については、『Splunk Enterprise インスタンスの
更新』マニュアルの「デプロイサーバーについて」を参照してください。
環境へのユニバーサルフォワーダーのデプロイ
数台のユニバーサルフォワーダーしか必要ない場合は、⼿動インストール作業を繰り返した⽅が簡単なこともあり
ます。ただし、多数のユニバーサルフォワーダーをインストールする必要がある場合は、スクリプトまたはデプロ
イツールを使⽤したリモートデプロイまたはシステムイメージまたは仮想マシンの⼀部としてデプロイする⽅が簡
単です。
デプロイのトラブルシューティング
ユニバーサルフォワーダーは、⼀部の内部ログをユニバーサルフォワーダーに転送します。ファイルを以下に⽰し
ます。
$SPLUNK_HOME/var/log/splunk/splunkd.log
$SPLUNK_HOME/var/log/splunk/metrics.log
$SPLUNK_HOME/var/log/splunk/license_audit.log
ログは、インデクサーのエラーによりサーチすることができます (index=_internal
host=<ua-machine>)。
ユニバーサルフォワーダーが誤動作してログを転送できない場合は、ユニバーサルフォワーダーのマシン上でテキ
ストエディタまたは grep を使⽤してください。
39
静的設定を使った *nix ユニバーサルフォワーダーのリモートデプロイ
複数のユニバーサルフォワーダーをリモートデプロイする⽅法の 1 つとして、スクリプトを使⽤する⽅法が挙げ
られます。yum や Puppet などのデプロイ管理ツールを使⽤することもできます。このトピックでは、スクリプ
トを使ったデプロイを取り上げていきます。
単⼀のユニバーサルフォワーダーのインストール、設定⽅法については、「nix ユニバーサルフォワーダーの⼿動
デプロイ」を参照してください。このトピックは CLI を使った、パッケージや tar ファイルから各種 *nix プラッ
トフォームにインストールおよび設定 (必要に応じて移⾏処理) する⽅法を説明しています。
デプロイ⼿順
ユニバーサルフォワーダーをダウンロードして、「デプロイの概要」の説明に基づいてデプロイのプランニングを
完了したら、以下の作業を⾏います。
1. 「nix ユニバーサルフォワーダーの⼿動デプロイ」で説明しているように、テスト⽤マシンにユニバーサルフォ
ワーダーをインストール、設定します。
2. 設定のテストと調整を⾏います。
3. インストールおよび設定コマンド⽤のスクリプトラッパーを作成します。
4. 代表的なターゲットマシン上でスクリプトを実⾏し、必要なすべてのシェルでスクリプトが正常に動作すること
を確認します。
5. ⼀連のホストに対してスクリプトを実⾏します。
6. デプロイモニター を使って、ユニバーサルフォワーダーが正常に動作していることを確認します。
スクリプトの作成と実⾏
完全に設定したユニバーサルフォワーダーの、インストールと設定プロセスを検証したら、そのプロセスをスクリ
プトに組み込むことができます。
スクリプトの要件
インストールパッケージまたは tar ファイルは、ターゲットマシンがアクセスできるネットワーク上の場所に配置
する必要があります。スクリプトがファイルを各ターゲットホストに配布できる場所、または NFS マウントなど
の⼀般的にアクセス可能な場所に配置することができます。
スクリプトは、エラーの報告にも対応する必要があります。Splunk に直接またはフラットファイルを介してログ
を記録することをお勧めします。
サンプルスクリプト
参考資料として利⽤できる、サンプルのスクリプトを以下に⽰します。これは、デプロイ⽤に作成できるスクリプ
トの単なる例に過ぎないことに注意してください。スクリプト内に記載されているコメントは、ご⾃分のニーズに
合わせてカスタマイズするための参考として利⽤できます。ただし、記載されているコメント以外にも、さまざま
な変更が必要な場合もあります。
特にこのスクリプトは、以下の処理を⾏います。
フォワーダーの tar ファイルを、HOST_FILE 変数が指すファイルに指定されているホストのリストにデプロイ
します。このファイルは、スクリプトのコメントに指定された形式で提供する必要があります。
tar ファイルが解凍される、各宛先ホスト上の場所を指定します。
デプロイサーバー として動作する Splunk Enterprise インスタンスを指定します。これが、フォワーダー
の管理と更新を⾏います。これは、オプションの設定ステップです。
各ホスト上でフォワーダーを開始します。
このスクリプトには有益なさまざまなコメントが記載されています。ご⾃分の環境に合わせて変更する前に、⼊念
にこれらのコメントを確認してください。
デプロイスクリプトの例を以下に⽰します。
#!/bin/sh
# This script provides an example of how to deploy the universal forwarder
# to many remote hosts via ssh and common Unix commands.
#
# Note that this script will only work unattended if you have SSH host keys
# setup & unlocked.
# To learn more about this subject, do a web search for "openssh key management".
# ----------- Adjust the variables below -----------
40
# Populate this file with a list of hosts that this script should install to,
# with one host per line.
# applicable.
You may use hostnames or IP addresses, as
You can also specify a user to login as, for example, "foo@host".
#
# Example file contents:
# server1
# server2.foo.lan
# you@server3
# 10.2.3.4
HOSTS_FILE="/path/to/splunk.install.list"
# This is the path to the tar file that you wish to push out.
You may
# wish to make this a symlink to a versioned tar file, so as to minimize
# updates to this script in the future.
SPLUNK_FILE="/path/to/splunk-latest.tar.gz"
# This is where the tar file will be stored on the remote host during
# installation.
The file will be removed after installation.
You normally will
# not need to set this variable, as $NEW_PARENT will be used by default.
#
# SCRATCH_DIR="/home/your_dir/temp"
# The location in which to unpack the new tar file on the destination
# host.
This can be the same parent dir as for your existing
# installation (if any).
This directory will be created at runtime, if it does
# not exist.
NEW_PARENT="/opt"
# After installation, the forwarder will become a deployment client of this
# host.
Specify the host and management (not web) port of the deployment server
# that will be managing these forwarder instances.
If you do not wish to use
# a deployment server, you may leave this unset.
#
# DEPLOY_SERV="splunkDeployMaster:8089"
# A directory on the current host in which the output of each installation
# attempt will be logged.
This directory need not exist, but the user running
# the script must be able to create it.
# $LOG_DIR/<[user@]destination host>.
The output will be stored as
If installation on a host fails, a
# corresponding file will also be created, as
# $LOG_DIR/<[user@]destination host>.failed.
LOG_DIR="/tmp/splunkua.install"
# For conversion from normal Splunk Enterprise installs to the universal forwarder:
# After installation, records of progress in indexing files (monitor)
# and filesystem change events (fschange) can be imported from an existing
# Splunk Enterprise (non-forwarder) installation.
Specify the path to that installation here.
# If there is no prior Splunk Enterprise instance, you may leave this variable empty ("").
#
# NOTE: THIS SCRIPT WILL STOP THE SPLUNK ENTERPRISE INSTANCE SPECIFIED HERE.
#
# OLD_SPLUNK="/opt/splunk"
# If you use a non-standard SSH port on the remote hosts, you must set this.
# SSH_PORT=1234
# You must remove this line, or the script will refuse to run.
# ensure that all of the above has been read and set. :)
UNCONFIGURED=1
# ----------- End of user adjustable settings -----------
# helpers.
faillog() {
echo "$1" >&2
41
This is to
}
fail() {
faillog "ERROR: $@"
exit 1
}
# error checks.
test "$UNCONFIGURED" -eq 1 && \
fail "This script has not been configured.
Please see the notes in the script."
test -z "$HOSTS_FILE" && \
fail "No hosts configured!
Please populate HOSTS_FILE."
test -z "$NEW_PARENT" && \
fail "No installation destination provided!
Please set NEW_PARENT."
test -z "$SPLUNK_FILE" && \
fail "No splunk package path provided!
Please populate SPLUNK_FILE."
if [ ! -d "$LOG_DIR" ]; then
mkdir -p "$LOG_DIR" || fail "Cannot create log dir at \"$LOG_DIR\"!"
fi
# some setup.
if [ -z "$SCRATCH_DIR" ]; then
SCRATCH_DIR="$NEW_PARENT"
fi
if [ -n "$SSH_PORT" ]; then
SSH_PORT_ARG="-p${SSH_PORT}"
SCP_PORT_ARG="-P${SSH_PORT}"
fi
NEW_INSTANCE="$NEW_PARENT/splunkforwarder" # this would need to be edited for non-UA...
DEST_FILE="${SCRATCH_DIR}/splunk.tar.gz"
#
#
# create script to run remotely.
#
#
REMOTE_SCRIPT="
fail() {
echo ERROR: \"\$@\" >&2
test -f \"$DEST_FILE\" && rm -f \"$DEST_FILE\"
exit 1
}
"
###
try untarring tar file.
REMOTE_SCRIPT="$REMOTE_SCRIPT
(cd \"$NEW_PARENT\" && tar -zxf \"$DEST_FILE\") || fail \"could not untar /$DEST_FILE to $NEW_PARENT.\"
"
###
setup seed file to migrate input records from old instance, and stop old instance.
if [ -n "$OLD_SPLUNK" ]; then
REMOTE_SCRIPT="$REMOTE_SCRIPT
echo \"$OLD_SPLUNK\" > \"$NEW_INSTANCE/old_splunk.seed\" || fail \"could not create seed file.\"
\"$OLD_SPLUNK/bin/splunk\" stop || fail \"could not stop existing splunk.\"
"
fi
###
setup deployment client if requested.
if [ -n "$DEPLOY_SERV" ]; then
REMOTE_SCRIPT="$REMOTE_SCRIPT
\"$NEW_INSTANCE/bin/splunk\" set deploy-poll \"$DEPLOY_SERV\" --accept-license --answer-yes \
--auto-ports --no-prompt || fail \"could not setup deployment client\"
"
fi
###
start new instance.
REMOTE_SCRIPT="$REMOTE_SCRIPT
\"$NEW_INSTANCE/bin/splunk\" start --accept-license --answer-yes --auto-ports --no-prompt || \
42
fail \"could not start new splunk instance!\"
"
###
remove downloaded file.
REMOTE_SCRIPT="$REMOTE_SCRIPT
rm -f "$DEST_FILE" || fail \"could not delete downloaded file $DEST_FILE!\"
"
#
#
# end of remote script.
#
#
exec 5>&1 # save stdout.
exec 6>&2 # save stderr.
echo "In 5 seconds, will copy install file and run the following script on each"
echo "remote host:"
echo
echo "===================="
echo "$REMOTE_SCRIPT"
echo "===================="
echo
echo "Press Ctrl-C to cancel..."
test -z "$MORE_FASTER" && sleep 5
echo "Starting."
# main loop.
install on each host.
for DST in `cat "$HOSTS_FILE"`; do
if [ -z "$DST" ]; then
continue;
fi
LOG="$LOG_DIR/$DST"
FAILLOG="${LOG}.failed"
echo "Installing on host $DST, logging to $LOG."
# redirect stdout/stderr to logfile.
exec 1> "$LOG"
exec 2> "$LOG"
if ! ssh $SSH_PORT_ARG "$DST" \
"if [ ! -d \"$NEW_PARENT\" ]; then mkdir -p \"$NEW_PARENT\"; fi"; then
touch "$FAILLOG"
# restore stdout/stderr.
exec 1>&5
exec 2>&6
continue
fi
# copy tar file to remote host.
if ! scp $SCP_PORT_ARG "$SPLUNK_FILE" "${DST}:${DEST_FILE}"; then
touch "$FAILLOG"
# restore stdout/stderr.
exec 1>&5
exec 2>&6
continue
fi
# run script on remote host and log appropriately.
if ! ssh $SSH_PORT_ARG "$DST" "$REMOTE_SCRIPT"; then
touch "$FAILLOG" # remote script failed.
else
test -e "$FAILLOG" && rm -f "$FAILLOG" # cleanup any past attempt log.
fi
# restore stdout/stderr.
exec 1>&5
exec 2>&6
43
if [ -e "$FAILLOG" ]; then
echo "
-->
FAILED
<--"
else
echo "
SUCCEEDED"
fi
done
FAIL_COUNT=`ls "${LOG_DIR}" | grep -c '\.failed$'`
if [ "$FAIL_COUNT" -gt 0 ]; then
echo "There were $FAIL_COUNT remote installation failures."
echo "
( see ${LOG_DIR}/*.failed )"
else
echo
echo "Done."
fi
# Voila.
スクリプトの実⾏
スクリプトを実⾏したら、そのスクリプトが⽣成したログファイルを参照してエラーが発⽣していないかどうかを
確認します。たとえば、サンプルスクリプトは /tmp/splunkua.install/<destination hostname> に保存します。
ユニバーサルフォワーダーをシステムイメージの⼀部にする
ここでは、システムイメージまたは仮想マシンの⼀部としてユニバーサルフォワーダーをデプロイする⽅法につい
て説明していきます。この⽅法は、多数のユニバーサルフォワーダーをデプロイする必要がある場合に特に役⽴ち
ます。数台のユニバーサルフォワーダーのみをインストールする場合は、Windows および nix マシンで説明する
ように、⼿動でインストールする⽅が簡単なこともあります。
このトピックの⼿順を実施する前に、「デプロイの概要」を参照してください。
デプロイ⼿順
ユニバーサルフォワーダーをダウンロードして、「デプロイの概要」の説明に基づいてデプロイのプランニングを
完了したら、以下の作業を⾏います。
1. テスト⽤マシンにユニバーサルフォワーダーをインストールします。以下を参照してください。
2. インストール後の設定作業を⾏います。ここを参照してください。
3. デプロイのテストと調整を⾏います。ここを参照してください。
4. テストした設定で、ユニバーサルフォワーダーをソースマシンにインストールします。
5. ユニバーサルフォワーダーを停⽌します。
6. フォワーダー上で以下の CLI コマンドを実⾏してください。
./splunk clone-prep-clear-config
これにより、サーバー名や GUID などの、インスタンス固有の情報が消去されます。この情報は、複製された各
フォワーダーの初期起動時に設定されます。
7. イメージまたは仮想マシンを、複製⽤に準備します。
8. *nix システムで、cron または任意のスケジューリングシステムを使って、ブート時に splunkd デーモンを開始
するように設定します。Windows の場合は、サービスに Automatic を設定します。ただし、サービスを開始しな
いでください。
9. システムイメージまたは仮想マシンの複製を、環境内の各マシンに配布して、起動します。
10. デプロイモニター を使って、複製されたユニバーサルフォワーダーが動作していることを確認します。
参考⼿順
上記のデプロイ⼿順は、これらのサブトピックを参考にしています。
ユニバーサルフォワーダーのインストール
オペレーティングシステム固有の⼿順を使って、ユニバーサルフォワーダーをインストールします。
*nix マシンにインストールする場合 は、「nix ユニバーサルフォワーダーの⼿動デプロイ」を参照してく
ださい。
Windows マシンの場合 は、インストーラ GUI またはコマンドラインインターフェイスを使⽤することが
44
できます。GUI を使ってインストールする場合は、「インストーラ GUI を使った Windows ユニバーサル
フォワーダーのデプロイ」を参照してください。コマンドラインインターフェイスについては、「コマンド
ラインを使った Windows ユニバーサルフォワーダーのデプロイ」を参照してください。
重要： Windows マシン上で、インストール後すぐにユニバーサルフォワーダーを開始したくない場合は、コマン
ドラインを使ってインストールする必要があります 。適切なフラグを使⽤して、インストール時にはユニバーサ
ルフォワーダーを起動せずに、複製がアクティブ化された時に⾃動的に開始するように設定することができます。
インストール時にユニバーサルフォワーダーを設定することもできます。「デプロイの概要」の「⼀般的な設定に
関する問題」を参照してください。
追加設定
インストール後にユニバーサルフォワーダーの設定を更新するには、inputs.conf や
ルを直接編集します。詳細は、「デプロイの概要」を参照してください。
outputs.conf
などの設定ファイ
複数のユニバーサルフォワーダーへの変更した設定の配布⽅法については、『Splunk Enterprise インスタンスの
更新』マニュアルの「デプロイサーバーについて」を参照してください。
デプロイのテスト
ユニバーサルフォワーダーを環境内にデプロイする前に、単⼀のマシンにユニバーサルフォワーダーを設定、テス
トして、正常に動作することを確認してください。ユニバーサルフォワーダーが⽬的のデータを収集し、それを適
切なインデクサーに出⼒していることを確認します。デプロイモニター を使ってユニバーサルフォワーダーを検
証することもできます。
*nix ライトフォワーダーの移⾏
既存のライトフォワーダーをユニバーサルフォワーダーに置換するには、チェックポイントデータを新しいフォ
ワーダーに移⾏する必要があります。チェックポイントデータは、フォワーダーがインデクサーに転送したデータ
を追跡するために使⽤する内部データです。チェックポイント・データを移⾏することで、新しいユニバーサル・
フォワーダーが、古いライト・フォワーダーがすでに転送したデータを送信することを防⽌できます。これによ
り、同じデータのインデックスが 2 回作成されることはありません。
既存の *nix ライトフォワーダー (バージョン 4.0 以上) からユニバーサルフォワーダーに、チェックポイントデー
タを移⾏することができます。移⾏の概要については、「ライトフォワーダーからの移⾏」を参照してください。
重要： 移⾏処理は、インストール後に初めてユニバーサルフォワーダーを開始した時にのみ⾏われます。それ以
降に移⾏することはできません。
以降するには、以下の⼿順に従ってください。
1. 既存のフォワーダーの任意のサービス (splunkd や splunkweb など) を停⽌します。
$SPLUNK_HOME/bin/splunk stop
2. 「nix ユニバーサルフォワーダーの⼿動デプロイ」の説明に従って、ユニバーサルフォワーダーの基本インス
トールを完了します。まだユニバーサルフォワーダーを開始しないでください。
重要： ユニバーサルフォワーダーは、既存のライトフォワーダーとは別のディレクトリにインストールする必要
があります。ユニバーサルフォワーダーのデフォルトのインストールディレクトリは /opt/splunkforwarder、完全版
Splunk Enterprise (ライトフォワーダーを含む) のデフォルトのインストールディレクトリは /opt/splunk なの
で、デフォルト値を使⽤する限りは何の問題もありません。
3. ユニバーサルフォワーダーのインストールディレクトリ (新しい $SPLUNK_HOME) に、old_splunk.seed という名前の
ファイルを作成します：$SPLUNK_HOME/old_splunk.seed。このファイルには、古い フォワーダーの $SPLUNK_HOME ディ
レクトリのパスを記述した単⼀の⾏を指定する必要があります。例：/opt/splunk。
4. ユニバーサルフォワーダーを開始します。
$SPLUNK_HOME/bin/splunk start
ユニバーサルフォワーダーは、$SPLUNK_HOME/old_splunk.seed ファイルに指定されたフォワーダーからチェックポイ
ントファイルを移⾏します。移⾏処理は、start コマンドを最初に実⾏した時にのみ⾏われます。old_splunk.seed
はそのまま放置しても構いません。これは、インストール後最初にフォワーダーを開始した時にのみ参照されま
す。
5. 「nix ユニバーサルフォワーダーの⼿動デプロイ」の説明に従って、ユニバーサルフォワーダーの設定を完了し
ます。移⾏プロセスはチェックポイントファイルのみをコピーします。古いフォワーダーの inputs.conf 設定ファ
イルを⼿動でコピーする (または、このファイルを参照して、モニター対象のデータ⼊⼒を確認する) ことができ
ます。
ユニバーサルフォワーダーを稼働したら (そして正常に動作していることを確認したら)、古いフォワーダーをアン
インストールすることができます。
フォワーダーのアップグレード
45
Windows ユニバーサルフォワーダーのアップグレード
ここでは、バージョン 5.0.x、6.0.x、または 6.1.x の Windows ユニバーサル・フォワーダーの、バージョン 6.2
へのアップグレード⼿順について説明していきます。
アップグレード作業は、当初のインストール作業よりも⼤幅に単純です。MSI が設定を変更せずにそのままアッ
プグレード処理を⾏います。フォワーダーの設定を変更する必要がある場合は、アップグレード後にその作業を⾏
います (デプロイサーバーの使⽤をお勧めします)。
重要： アップグレード作業を⾏う前に、本当にアップグレードが必要かどうかを確認してください。たいていの
場合、フォワーダーをアップグレードする差し迫った理由はありません。フォワーダーは常に最新版のインデク
サーと互換性があります。そのため、データの送信先インデクサーをアップグレードしたからといって、フォワー
ダーをアップグレードする必要はありません。
このトピックでは、3 種類のアップグレードシナリオを取り上げていきます。
GUI インストーラを使った単⼀フォワーダーのアップグレード
コマンドラインインストーラを使った単⼀フォワーダーのアップグレード
⼀連のフォワーダーグループのリモートアップグレード
デプロイ環境の場合はどのような規模でも、最後のシナリオを採⽤することが多いでしょう。
アップグレードする前に
アップグレードを実施する前に、このセクションを参照し、正しく理解するようにしてください。また、『インス
トール・マニュアル』の「Splunk Enterprise のアップグレード⽅法」を参照して、最新情報やアップグレード時
に発⽣する可能性がある潜在的な問題について確認してください。
プラットフォーム・アーキテクチャの変更はありません
ユニバーサル・フォワーダーのインストーラの仕組みにより、32 ビット版のユニバーサル・フォワーダーを、64
ビット版のユニバーサル・フォワーダー・インストーラを使ってアップグレードすることはできません。そのよう
な状況下にある場合は、以下の指⽰に従ってください。
1. App やアドオンも含めて、設定情報をバックアップします (%SPLUNK_HOME%\etc\apps 内)。また、
%SPLUNK_HOME%\var\lib\modinputs\ にあるチェックポイント・ファイルもバックアップします。
2. 既存の 32 ビット版フォワーダーをアンインストールします。
3. 64 ビット版フォワーダーをインストールします。
4. App、設定、およびチェックポイントを復元するために、適切なディレクトリにコピーします。
(設定ファイル⽤)。
(App とアドオン⽤)
%SPLUNK_HOME%\var\lib\modinputs (チェックポイント・ファイル⽤)。
%SPLUNK_HOME%\etc\system\local
%SPLUNK_HOME%\etc\apps
ファイルのバックアップ
アップグレードを実⾏する前に、設定ファイルをバックアップすることを強くお勧めします。設定のバックアップ
の詳細は、『管理マニュアル』の「設定情報のバックアップ」を参照してください。
Splunk Enterprise には、古いバージョンにダウングレードする⼿段は⽤意されていません。古いバージョンの
フォワーダーに戻す必要がある場合は、現在のバージョンをアンインストールしてから、古いリリースを再インス
トールしてください。
GUI インストーラを使ったアップグレード
GUI インストーラを使って、単⼀のフォワーダーをアップグレードすることができます。
1. ユニバーサルフォワーダーのダウンロードページから、新しい MSI ファイルをダウンロードします。
2. MSI ファイルをダブルクリックします。[Accept license agreement] (使⽤許諾契約に同意してください) パネ
ル が表⽰されます。
3. 使⽤許諾契約に同意して、[Install] をクリックします。既存の設定が保持された状態で、フォワーダーがアップ
グレードされます。
注意： アップグレード前にフォワーダーを停⽌する必要はありません。アップグレード処理の⼀環として、MSI
が⾃動的にフォワーダーを停⽌します。
4. インストールが完了すると、フォワーダーが⾃動的に開始されます。
アップグレードの変更内容は、%TEMP% 内のログに記録されます。また、何らかのエラーが発⽣した場合は、アプリ
ケーションイベントログに記録されます。
コマンドラインを使ったアップグレード
コマンドラインインストーラを実⾏して、単⼀のフォワーダーをアップグレードすることができます。⼀連のフォ
ワーダー・グループをアップグレードする場合は、後述のようにデプロイ・ツールにコマンド・ライン・インス
トーラを指定します。
46
ここでは、コマンドラインインストーラを使って、単⼀のフォワーダーをアップグレードする⼿順を説明していき
ます。
1. Splunk ユニバーサルフォワーダーのダウンロードページから、新しい MSI ファイルをダウンロードします。
2. msiexec.exe を実⾏して、コマンドラインからユニバーサルフォワーダーをインストールします。
32 ビット版プラットフォームの場合は、splunkuniversalforwarder-<...>-x86-release.msi を使⽤します。
msiexec.exe /i splunkuniversalforwarder-<...>-x86-release.msi [AGREETOLICENSE=Yes /quiet]
64 ビット版プラットフォームの場合は、splunkuniversalforwarder-<...>-x64-release.msi を使⽤します。
msiexec.exe /i splunkuniversalforwarder-<...>-x64-release.msi [AGREETOLICENSE=Yes /quiet]
<...>
の値はリリースによって異なります (例：splunkuniversalforwarder-5.0-142438-x64-release.msi)。
重要： アップグレード中に設定の変更を⾏うことはできません。「AGREETOLICENSE」以外のコマンドライン
フラグを指定しても、それは無視されます。
注意： アップグレード前にフォワーダーを停⽌する必要はありません。アップグレード処理の⼀環として、MSI
が⾃動的にフォワーダーを停⽌します。
3. インストールが完了すると、フォワーダーが⾃動的に開始されます。
アップグレードの変更内容は、%TEMP% 内のログに記録されます。また、何らかのエラーが発⽣した場合は、アプリ
ケーションイベントログに記録されます。
リモートアップグレードの実⾏
環境内の⼀連のフォワーダーグループをアップグレードするには：
1. ユニバーサルフォワーダー MSI をデプロイツールに読み込みます。たいていの場合は、以下のようなコマンド
を実⾏します。
msiexec.exe /i splunkuniversalforwarder-<...>.msi AGREETOLICENSE=Yes /quiet
MSI コマンドの詳細は、前のセクションの「コマンド・ラインを使ったアップグレード」を参照してください。
2. デプロイツールでデプロイを実⾏します。
3. デプロイモニター を使って、ユニバーサルフォワーダーが正常に動作していることを確認します。
すべてのフォワーダーに対するリモートアップグレードを実⾏する前に、1 台のマシンを使ってローカルにアップ
グレードをテストすることもできます。
*nix システムのユニバーサルフォワーダーのアップグレード
ここでは、バージョン 4.3.x または 5.0.x のユニバーサルフォワーダーの、バージョン 6.0 へのアップグレード⼿
順について説明していきます。
重要： アップグレード作業を⾏う前に、本当にアップグレードが必要かどうかを確認してください。たいていの
場合、フォワーダーをアップグレードする差し迫った理由はありません。フォワーダーは常に最新版のインデク
サーと互換性があります。そのため、データの送信先インデクサーをアップグレードしたからといって、フォワー
ダーをアップグレードする必要はありません。
このトピックでは、2 種類のアップグレードシナリオを取り上げていきます。
単⼀のフォワーダーの⼿動アップグレード
⼀連のフォワーダーグループのリモートアップグレード
デプロイ環境の場合はどのような規模でも、2 番⽬のシナリオを採⽤することが多いでしょう。
アップグレードする前に
アップグレードを実施する前に、このセクションを参照し、正しく理解するようにしてください。また、『インス
トール・マニュアル』の「Splunk Enterprise のアップグレード⽅法」を参照して、最新情報やアップグレード時
に発⽣する可能性がある潜在的な問題について確認してください。
ファイルのバックアップ
アップグレードを実⾏する前に、設定ファイルをバックアップすることを強くお勧めします。設定のバックアップ
の詳細は、『管理マニュアル』の「設定情報のバックアップ」を参照してください。
Splunk Enterprise には、古いバージョンにダウングレードする⼿段は⽤意されていません。古いバージョンの
フォワーダーに戻す必要がある場合は、古いリリースを再インストールしてください。
47
アップグレードの仕組み
新しいバージョンをインストールした後、ユニバーサルフォワーダーを開始するまでの間は、実際の設定の変更は
⾏われません。その時点で移⾏プレビューユーティリティを実⾏して、ファイルの更新前に何が変更されるのかを
確認することができます。続⾏する前に変更内容を確認することを選択した場合は、アップグレードスクリプトが
提案する変更内容を含むファイルが次のところに書き込まれます：
$SPLUNK_HOME/var/log/splunk/migration.log.<timestamp>
単⼀のフォワーダーのアップグレード
1. stop コマンドを実⾏します。
$SPLUNK_HOME/bin/splunk stop
重要： 他のプロセスがフォワーダーを⾃動的に開始することがないように注意してください (Solaris SMF な
ど)。
2. 既存のデプロイ環境に、ユニバーサルフォワーダーパッケージをインストールします。
.tar ファイルを使⽤する場合、既存のユニバーサルフォワーダーインスタンスと同じディレクトリに、同じ
所有権で解凍します。これにより、⼀致するファイルは上書き、置換されますが、独⾃のファイルが削除さ
れることはありません。
RPM などのパッケージマネージャを使⽤する場合は、次のように⼊⼒します： rpm -U
<splunk_package_name>.rpm
.dmg ファイル (MacOS で) を使⽤する場合は、ファイルをダブルクリックした後、指⽰に従って作業を⾏
います。既存のインストールと同じインストールディレクトリを指定してください。
init スクリプトを使⽤する場合は、EULA に同意するために以下の⾏を追加してください。
./splunk start --accept-license
3. start コマンドを実⾏します。
$SPLUNK_HOME/bin/splunk start
以下のメッセージが表⽰されます。
This appears to be an upgrade of Splunk.
-------------------------------------------------------------------------------Splunk has detected an older version of Splunk installed on this machine. To
finish upgrading to the new version, Splunk's installer will automatically
update and alter your current configuration files. Deprecated configuration
files will be renamed with a .deprecated extension.
You can choose to preview the changes that will be made to your configuration
files before proceeding with the migration and upgrade:
If you want to migrate and upgrade without previewing the changes that will be
made to your existing configuration files, choose 'y'.
If you want to see what changes will be made before you proceed with the
upgrade, choose 'n'.
Perform migration and upgrade without previewing configuration changes? [y/n]
4. 移⾏プレビュースクリプトを実⾏して既存の設定ファイルに対して⾏われる変更内容を確認するか、または移⾏
処理を続⾏してすぐにアップグレードを⾏うかを選択します。
5. 変更内容を確認することを選択した場合は、そのリストが表⽰されます。
6. 変更内容を確認し、移⾏とアップグレードを続⾏する準備ができた場合は、
実⾏します。
$SPLUNK_HOME/bin/splunk start
注意： ステップ 3〜5 は 1 ⾏で完了することができます。
ライセンスに同意して、アップグレードを続⾏する前に変更内容を表⽰ (回答は「n」) する場合：
$SPLUNK_HOME/bin/splunk start --accept-license --answer-no
ライセンスに同意して、変更内容を確認せずにアップグレードを開始 (回答は「y」) する場合：
$SPLUNK_HOME/bin/splunk start --accept-license --answer-yes
リモートアップグレードの実⾏
環境内の⼀連のフォワーダーグループをアップグレードするには：
48
を再
1. 前述の説明に従って、テストマシン上のユニバーサル・フォワーダーをアップグレードします。
2. アップグレード・コマンド⽤のスクリプト・ラッパーを作成します。詳細は、『データの転送』マニュアルの
「静的設定を使った nix ユニバーサル・フォワーダーのリモート・デプロイ」を参照してください。ご⾃分のアッ
プグレードニーズを満たすために、サンプルスクリプトを変更する必要があります。
3. 代表的なターゲットマシン上でスクリプトを実⾏し、必要なすべてのシェルでスクリプトが正常に動作すること
を確認します。
4. ⼀連のホストに対してスクリプトを実⾏します。
5. デプロイモニター を使って、ユニバーサルフォワーダーが正常に動作していることを確認します。
詳細設定
outputs.conf によるフォワーダーの設定
outputs.conf ファイルは、フォワーダーのレシーバーへのデータの転送⽅法を定義しています。⼀部の出⼒設定
はインストール時に (Windows ユニバーサルフォワーダーのみ)、または Splunk Web (ヘビー/ライトフォワー
ダーのみ) や CLI を使って⾏えます。ただし、⾼度な設定の⼤半は、outputs.conf を直接編集する必要がありま
す。このトピックは、ロードバランシングやデータのルーティングなどのさまざまなトポロジーについて説明し、
それらのトポロジーを実現するための outputs.conf の設定に関する詳細な例を取り上げています。
重要： outputs.conf はフォワーダーの設定について重要なファイルで、特にフォワーダーからの出⼒に関する項⽬
が多く⽤意されています。フォワーダーの⼊⼒を指定するには、他の Splunk Enterprise インスタンスと同様に
個別に⼊⼒を設定する必要があります。⼊⼒の設定⽅法の詳細は、『データの取り込み』マニュアルの「データの
追加と⼊⼒の設定」を参照してください。
outputs.conf ファイルの種類
単⼀のフォワーダーに複数の outputs.conf ファイルを保有することができます (たとえば、App ディレクトリに 1
つ、そして /system/local ディレクトリに別のファイルを保管する)。フォワーダーに存在する outputs.conf 数や保
管場所に関係なく、すべてのファイルの設定が組み合わされて使⽤されます。詳細は、「設定ファイルの優先度」
を参照してください。インストールには、デフォルトの outputs.conf ファイルとカスタムファイルの両⽅が含まれ
ます。
デフォルト版
Splunk には、以下のデフォルト版の
outputs.conf
が⽤意されています。
ユニバーサルフォワーダー ：ユニバーサルフォワーダーには、$SPLUNK_HOME/etc/system/default と
$SPLUNK_HOME/etc/apps/SplunkUniversalForwarder/default 内に 1 つずつ、合計 2 つのデフォルト outputs.conf
ファイルが存在しています。SplunkUniversalForwarder App にあるデフォルト版のファイルが、/etc/system 内
のファイルよりも優先されます。
ヘビーフォワーダーとライトフォワーダー ：これらの場合は、$SPLUNK_HOME/etc/system/default に、単⼀の
デフォルト outputs.conf ファイルが存在しています。
重要： 「設定ファイルについて」で説明している理由から、デフォルト版の設定ファイルは編集しないでくださ
い。
カスタム版
転送動作を設定する場合、変更内容はカスタム版の
ざまな⽅法を利⽤できます。
outputs.conf
に保存されます。転送動作を設定するには、さま
フォワーダーのインストール時 (Windows ユニバーサルフォワーダーのみ)
CLI コマンドを実⾏
Splunk Web を使⽤ (ヘビー/ライトフォワーダーのみ)
outputs.conf ファイルを直接編集
最初の 3 つの⽅法の場合、⾃動的にカスタム版の outputs.conf が作成または編集されます。これらのバージョン
の保管場所は、フォワーダーの種類やその他の要因によって異なります。
ユニバーサルフォワーダー ：CLI を使ってユニバーサルフォワーダーの出⼒動作を変更する場合
は、$SPLUNK_HOME/etc/system/local 内に outputs.conf のコピーが作成または編集されます。ただし、Windows
のインストールプロセスでは、設定の変更が MSICreated App 内の outputs.conf ファイルに書き込まれます。
ユニバーサルフォワーダーの設定の詳細は、ここを参照してください。
ヘビーフォワーダーとライトフォワーダー ：Splunk Web または CLI を使ってヘビー/ライトフォワー
ダーを有効にする場合、現在動作している App のディレクトリ内に outputs.conf ファイルが作成されます。
たとえば、サーチ App で作業を⾏っている場合は、ファイルが $SPLUNK_HOME/etc/apps/search/local/ に作成
されます。そこからファイルを編集することができます。
ファイルを間接的に (たとえば、CLI を使⽤して) 作成または編集するだけでなく、outputs.conf ファ
イルを直接作成または編集することもできます。ファイルの単⼀のコピーを $SPLUNK_HOME/etc/system/local/ に保管
して、作業を⾏うことをお勧めします。(CLI を使った設定の変更などの理由により、このディレクトリにすでに
ファイルのコピーが存在している場合は、そのコピーを編集します。)配布と管理を簡素化するために、すべての
outputs.conf
49
⾮デフォルト版ファイルからの設定を組み合わせて、単⼀のカスタム
ます。
outputs.conf
ファイルにまとめることができ
outputs.conf
を変更したら、変更内容を反映するためにフォワーダーを再起動する必要があります。
outputs.conf
の詳細と例は、ここを参照してください。
設定レベル
2 種類の出⼒プロセッサ tcpout と syslog が存在しています。これらは、3 種類のレベルのスタンザに設定でき
ます。
グローバル： グローバルレベルでは、全体的に適⽤する属性を指定します。また、システム全体のレベルに
しか設定できない⼀部の属性もここに指定します。このスタンザは省略することができます。
対象グループ： 対象グループは、1 つまたは複数の受信インデクサーを定義します。出⼒プロセッサあたり
複数の対象グループを指定することができます。⼤部分の設定は、対象グループレベルに指定できます。
単⼀サーバー： 対象グループ内の単⼀のサーバー (レシーバー) に対して設定値を指定することができま
す。このタイプのスタンザは省略することができます。
より狭義のレベルの設定が優先されます。たとえば、対象グループに対して compressed=true を指定した場合、グ
ローバルレベルで compressed に「false」が設定されている場合でも、フォワーダーは対象グループ内のサーバー
に圧縮データを送信します。
注意： この説明は、[tcpout] ヘッダーを使⽤する tcpout プロセッサを前提にしています。syslog 出⼒プロセッサ
については、「サードパーティ製システムへのデータの転送」を参照してください。
グローバルスタンザ
ここには、全体的に適⽤する属性を設定します。このスタンザは必須ではありません。ただし、defaultGroup や
indexAndForward など、グローバルレベルでのみ設定できる属性もあります。
tcpout プロセッサ⽤のグローバルスタンザは、[tcpout] ヘッダーで指定します。
グローバル tcpout スタンザの例を以下に⽰します。
[tcpout]
defaultGroup=indexer1
indexAndForward=true
このグローバルスタンザには、2 つの属性/値のペアが含まれています。
defaultGroup=indexer1 ：フォワーダーに、すべてのデータを対象グループ「indexer1」に送信するこ
とを指⽰しています。詳細は、「デフォルトの対象グループ」を参照してください。
indexAndForward=true ：フォワーダーに、データのインデックスをローカルに作成し、対象グループ内
の受信インデクサーにデータを転送することを指⽰しています。「false」 (デフォルト) を設定すると、
フォワーダーは単純にデータを転送し、インデックスを作成することはありません。この属性はヘビーフォ
ワーダーでのみ利⽤できます。ユニバーサルフォワーダーとライトフォワーダーは、データのインデックス
を作成することはできません。
デフォルトの対象グループ
⾃動転送⽤のデフォルトグループを設定するには、[tcpout] スタンザにグローバルレベルで
定します。
defaultGroup
属性を設
[tcpout]
defaultGroup= <target_group1>, <target_group2>, ...
defaultGroup には、後ほど tcpout:<target_group> スタンザに定義する、1 つまたは複数の対象グループを指定し
ます。フォワーダーは、指定されたグループにすべてのイベントを送信します。
データを⾃動的に転送したくない 場合は、defaultGroup 属性を設定しないでください。(4.2 より前のバージョンで
は、defaultGroup に何らかの値を指定する必要がありました。現在では不要となっています。)
defaultGroup
属性の使⽤例については、「データのルーティングとフィルタリング」を参照してください。
対象グループスタンザ
対象グループは、⼀連のレシーバーを⽰しています。また、フォワーダーがそれらのレシーバーにどのようにデー
タを送信するのかも⽰しています。対象グループは複数定義することができます。
対象グループスタンザの基本的なパターンを以下に⽰します。
[tcpout:<target_group>]
server=<receiving_server1>, <receiving_server2>, ...
<attribute1> = <val1>
50
<attribute2> = <val2>
...
対象グループ内に受信サーバーを指定するには、<ipaddress_or_servername>:<port> の形式を使⽤します。ここ
で、<port> は受信サーバーの受信ポート を表しています。例：myhost.Splunk.com:9997。複数のレシーバーを指定す
ることができます。この場合、フォワーダーはそれらに対してロードバランシングを⾏います。
対象グループスタンザを使った、さまざまなデプロイトポロジーの定義⽅法については、このトピックの後半にあ
る「⼀般的なデプロイトポロジーの定義」を参照してください。
単⼀サーバースタンザ
個別の受信インデクサーに固有の設定を定義することができます。ただし、レシーバーは対象グループのメンバー
でなければなりません。
単⼀サーバーレベルで属性を定義する場合、その設定は対象グループやグローバルレベルの設定よりも優先されま
す。
単⼀サーバーレベルのスタンザを定義するための構⽂を以下に⽰します。
[tcpout-server://<ipaddress_or_servername>:<port>]
<attribute1> = <val1>
<attribute2> = <val2>
...
例
以下の outputs.conf の例には、tcpout を Splunk Enterprise レシーバーに送信するための 3 種類のスタンザが含
まれています。
グローバル設定：この例では、defaultGroup を指定する 1 つの設定があります。
2 台のレシーバーで構成される、単⼀の対象グループ設定。これは、2 台のレシーバーで構成される、ロー
ドバランシングを利⽤した対象グループを指定することになります。
対象グループ内の 1 台のレシーバー⽤の設定。このスタンザには、mysplunk_indexer1 レシーバーに固有の設
定を定義します。
[tcpout]
defaultGroup=my_indexers
[tcpout:my_indexers]
server=mysplunk_indexer1:9997, mysplunk_indexer2:9996
[tcpout-server://mysplunk_indexer1:9997]
⼀般的なデプロイトポロジーの定義
このセクションでは、⼀般的な各種デプロイトポロジーを利⽤するための、フォワーダーの設定⽅法について説明
していきます。他のトポロジー⽤のフォワーダーの設定については、このマニュアルの「データの転送」にある各
トピックを参照してください。
ロードバランシング
ロードバランシング を利⽤するには、1 つの対象グループに複数のレシーバーを指定します。この例では、対象
グループが 3 つのレシーバーから構成されています。
[tcpout:my_LB_indexers]
server=10.10.10.1:9997,10.10.10.2:9996,10.10.10.3:9995
フォワーダーは、記載されている 3 台のレシーバー間でロードバランシングを⾏います。いずれかのレシーバー
が停⽌した場合、フォワーダーは⾃動的に利⽤可能な他のレシーバーに切り替えます。
データの複製
データの複製 を実施するには、複数の対象グループをそれぞれ独⾃のスタンザに指定します。データの複製で
は、フォワーダーがすべてのイベントのコピーを、複数の対象グループ内にあるレシーバーに送信します。通常
データの複製により、各受信インデクサーに類似のデータコピーが存在することになりますが、完全に⼀致する必
要はありません。データの複製の設定例を以下に⽰します。
[tcpout]
defaultGroup=indexer1,indexer2
[tcpout:indexer1]
server=10.1.1.197:9997
51
[tcpout:indexer2]
server=10.1.1.200:9997
フォワーダーは、対象グループ
す。
indexer1
と
indexer2
の両⽅のサーバーに、重複したデータストリームを送信しま
データの複製とロードバランシングの利⽤
ロードバランシングとデータの複製を組み合わせることができます。例：
[tcpout]
defaultGroup=cloned_group1,cloned_group2
[tcpout:cloned_group1]
server=10.10.10.1:9997, 10.10.10.2:9997, 10.10.10.3:9997
[tcpout:cloned_group2]
server=10.1.1.197:9997, 10.1.1.198:9997, 10.1.1.199:9997, 10.1.1.200:9997
フォワーダーはすべてのデータストリームを、cloned_group1 と cloned_group2. の両⽅に送信します。データは各グ
ループ内でロードバランシングされ、30 秒 (デフォルト値) ごとにレシーバーが交代します。
注意： syslog および他の出⼒タイプの場合、「データのルーティングとフィルタリング」で説明しているよう
に、明⽰的にルーティングを指定する必要があります。
⼀般的に使⽤される属性
ファイルには、転送をきめ細かく柔軟に調整するために、さまざまな設定オプションが⽤意されてい
ます。利⽤可能な属性の中から、主な属性を以下に⽰します。
outputs.conf
属性
defaultGroup
デ
フォ
ルト
設定場所
グローバ
N/A ルスタン
ザ
値
1 つまたは複数の対象グループの、カンマ区切りリスト。フォワー
ダーは、指定されているすべての対象グループにすべてのイベント
を送信します。対象グループにイベントを⾃動送信しない場合は、
この属性を設定しないでください。
「true」を設定すると、フォワーダーはデータをインデクサーに転
送するだけでなく、データのインデックスをローカルに作成しま
す。
indexAndForward
グローバ
false ルスタン
ザ
server
対象グ
N/A ループス
タンザ
必須。フォワーダーのレシーバーとして動作するサーバーを指定し
ます。<ipaddress_or_servername>:<port> の形式で指定する必要があり
ます (<port> はサーバーの受信ポート)。
disabled
任意のス
false タンザレ
ベル
スタンザが無効かどうかを⽰します。「true」を設定した場合、ス
タンザが存在しないのと同じ意味になります。
グローバ
ルまたは
対象グ
ループス
タンザ
重要： この属性は、ヘビーフォワーダーでのみ利⽤できます。ユニ
バーサルフォワーダーは、ローカルにインデックスを作成できませ
ん。
sendCookedData
true
compressed
グローバ
ルまたは
false 対象グ
ループス
タンザ
フォワーダーが圧縮データを送信するかどうかを⽰します。
ssl....
任意のス
N/A タンザレ
ベル
SSL 設定⽤の属性セット。これらの属性の使⽤⽅法は、『Splunk
Enterprise のセキュリティ』マニュアルの「フォワーダーからの
データの保護について」を参照してください。
useACK
グローバ
ルまたは
false 対象グ
ループス
タンザ
フォワーダーが、データがファイルシステムに書き込まれたことを
確認するための、インデクサー応答確認を待機するかどうかを⽰し
ます。「転送データ損失の保護」を参照してください。
dnsResolutionInterval 300
グローバ
ルまたは
対象グ
データを転送する前に処理するかどうかを⽰します。
インデクサー DNS 名を IP アドレスに解決するベース間隔 (秒) を
52
dnsResolutionInterval 300
対象グ
ループス
タンザ
指定します。「DNS 解決の間隔」を参照してください。
ここの outputs.conf.spec ファイルの説明やさまざまな例で、これらのオプションや他の設定オプションの詳細が記
述されています。また、これらの設定の⼤部分は、特定の転送に関する事例を記述しているトピックでも取り上げ
られています。
注意： 4.2 では、persistent queue 機能が⼤幅に改善されました。これはデータ⼊⼒ (取り込み) の機能となり、
inputs.conf で設定を⾏います。従来の outputs.conf で設定する、廃⽌予定の persistent queue 機能とは何の関
連もなくなりました。詳細は、「persistent queue を使ったデータ損失の防⽌」を参照してください。
DNS 解決の間隔
属性は、レシーバー DNS 名を IP アドレスに解決するベース間隔 (秒) を⽰します。この値
は、以下のように実⾏時の間隔を算出するために⽤いられます。
dnsResolutionInterval
run-time interval = dnsResolutionInterval + (number of receivers in server attribute - 1) * 30
実⾏時間隔は、server 属性にレシーバーが追加された数に応じて (フォワーダーがロードバランシングを⾏う追加
の各レシーバーに対して)、それぞれ 30 秒ずつ延⻑されます。dnsResolutionInterval 属性のデフォルトは 300 秒
です。
たとえば、この属性をデフォルトの 300 秒に設定し、フォワーダーが 20 台のインデクサーにまたがってロード
バランシングを⾏う場合、DNS 解決は 14 分ごとに⾏われます。
(300 + ((20 - 1) * 30)) = 870 seconds = 14 minutes
を 600 秒に変更して、20 台のインデクサーに対してロードバランシングを⾏う場合は、
19.5 分ごとに DNS 解決が⾏われます。
dnsResolutionInterval
(600 + ((20 - 1) * 30)) = 1170 seconds = 19.5 minutes
転送データ損失の保護
インデクサー へのデータ転送 時のデータ損失を保護するために、のインデクサー応答確認 機能を使⽤すること
ができます。インデクサー応答確認を利⽤した場合、フォワーダー はインデクサーが「受信した」ことを確認で
きなかったデータを再送信します。
インデクサー応答確認を有効にするにはフォワーダー上で
に影響するため、デフォルトでは無効になっています。
outputs.conf
を設定します。この機能はパフォーマンス
注意： インデクサー応答確認を利⽤するには、フォワーダーとインデクサーの両⽅がバージョン 4.2 以降でなけ
ればなりません。そうでない場合は、応答確認することなくデータの伝送が⾏われます。
インデクサー応答確認とインデクサー・クラスタ
フォワーダーを使ってインデクサー・クラスタ内のピア・ノードにデータを送信する場合、通常はインデクサー応
答確認を有効にする必要があります。フォワーダーとクラスタの詳細は、『インデクサーとインデクサー・クラス
タの管理』マニュアルの「フォワーダーを使ったデータの取り込み」を参照してください。
正常動作時のインデクサー応答確認の動作
フォワーダーはインデクサーに継続的にデータを送信します (約 64 KB のブロックで)。フォワーダーは、インデ
クサーから応答確認を受信するまでの間、各ブロックのコピーをメモリー内の待機キューに保持します。待機中で
も、その他のブロックは引き続き送信されます。
すべてが順調な場合、インデクサーは：
1. データブロックを受信します。
2. データをパーシングします。
3. データをファイルシステムにイベントとして書き込みます (raw データとインデックスデータ)。
4. フォワーダーに応答確認を送信します。
応答確認は、インデクサーがデータを受信して、ファイルシステムに正常に書き込んだことをフォワーダーに知ら
せます。応答確認を受信すると、フォワーダーは当該ブロックをメモリーから解放します。
待機キューのサイズが⼗分にある場合は、応答確認を受信するまでにキューが⼀杯になることはありません。待機
キューのサイズを増やす⽅法を含めた、潜在的な問題と対処⽅法については、このセクションを参照してくださ
い。
問題がある場合のインデクサー応答確認の動作
⼀連の処理中に何らかの障害が発⽣した場合、フォワーダーは応答確認を受信しません。この場合、データブロッ
53
クの再送信を試みます。
応答確認がない理由
フォワーダーが応答確認を受け取らない理由の例を以下に⽰します。
データの受信後に、マシン障害などの理由でインデクサーが停⽌した。
ディスク満杯などの理由で、インデクサーがファイルシステムにデータを書き込むことができない。
応答確認のフォワーダーへの送信時に、ネットワークが停⽌した。
フォワーダーの障害への対処
データブロックの送信後、フォワーダーは応答確認を受信するまでの間、データのコピーを待機キューに保管しま
す。その後、他のブロックも通常通りに送信し続けます。あるブロックに対する応答確認を 300 秒 (デフォルト)
以内に受信しなかった場合、フォワーダーは接続を終了します。この待機時間を変更するには、outputs.conf 内の
readTimeout 属性を編集します。
フォワーダーに⾃動ロードバランシング が設定されている場合、グループ内の別のインデクサーに接続が⾏われ
(利⽤できる場合)、それにデータが送信されます。フォワーダーに⾃動ロードバランシングが設定されていない場
合は、同じインデクサーにデータを再送信するために、接続が試みられます。
フォワーダーは、応答確認を受信するまでの間、待機キュー内にデータブロックを保持します。待機キューが⼀杯
になると、そのいずれかのブロックの応答確認を受信して、キュー内にスペースを確保できるようになるまでの
間、他のブロックの送信は停⽌されます。
フォワーダーが接続を終了するその他の理由
フォワーダーがネットワーク接続を終了する可能性がある条件は 3 種類あります。
読み取りタイムアウト。フォワーダーが 300 秒 (デフォルト) 以内に応答確認を受信しなかった。これが上
記の状態です。
書き込みタイムアウト。フォワーダーがネットワーク書き込みを 300 秒 (デフォルト) 以内に完了できな
かった。この値は、outputs.conf 内の writeTimeout に設定することができます。
読み取り/書き込み障害。インデクサーマシンのクラッシュ、またはネットワーク停⽌などの原因が考えられ
ます。
これらのすべての状況で、フォワーダーはロードバランシンググループ内の次のインデクサーへの接続を試みる
か、またはロードバランシングを利⽤していない場合は、同じインデクサーへの再接続を試みます。
重複の可能性
インデクサーが同じデータブロックのインデックスを 2 回作成する場合もあります。このような状況は、ネット
ワーク上の問題により、フォワーダーに応答確認が届かなかった場合に発⽣する可能性があります。たとえば、イ
ンデクサーがあるデータブロックを受信して、それをパーシングした後に、ファイルシステムに書き込む場合を考
えてみましょう。次に応答確認を⽣成します。しかし、フォワーダーへの送信中にネットワークが停⽌したため、
フォワーダーにその応答確認が届きませんでした。その後ネットワークが復旧すると、フォワーダーはデータ・ブ
ロックを再送信するため、インデクサーはそれを新しいデータと同じようにパーシングして、ファイル・システム
に書き込みます。
このような問題に対処するために、フォワーダーがデータブロックを再送信する際には、重複の可能性があること
知らせる⽬的で、splunkd.log にイベントを書き込みます。管理者はこのログ情報を使って、インデクサー上の重
複データを追跡する必要があります。
重複の警告例を以下に⽰します。
10-18-2010 17:32:36.941 WARN
TcpOutputProc - Possible duplication of events with
channel=source::/home/jkerai/splunk/current-install/etc/apps/sample_app
/logs/maillog.1|host::MrT|sendmail|, streamId=5941229245963076846, offset=131072
subOffset=219 on host=10.1.42.2:9992
インデクサー応答確認を有効にする
インデクサー応答確認はフォワーダー上で設定します。outputs.conf の
useACK
属性に
true
を設定します：
[tcpout:<target_group>]
server=<server1>, <server2>, ...
useACK=true
デフォルトで、useACK には
false
が設定されています。
注意： useACK はグローバルまたは対象グループ単位に設定できます。[tcpout] または [tcpout:<target_group>] スタ
ンザレベルで設定します。[tcpout-server: ...] スタンザで、個別のインデクサー単位に設定することはできませ
ん。
詳細は、outputs.conf spec ファイルを参照してください。
インデクサー応答確認と転送されたデータのスループット
54
フォワーダーは、待機キューを使ってインデクサー応答確認のプロセスを管理しています。このキューのデフォル
ト最⼤サイズは 21MB です。⼀般的にはこの値で⼗分に対処できます。ただし希にですが、この待機キューのサ
イズを⼿動で調整しなければならないこともあります。
待機キューの詳細については、このセクションを参照してください。待機キューサイズの設定⽅法について説明し
ています。また、待機キューの仕組みについても説明しています。
待機キューサイズの設定⽅法
待機キューのサイズは直接的には設定しません。代わりに、メモリー内出⼒キューのサイズを設定します。そうす
ると、待機キューのサイズが⾃動的に、出⼒キューサイズの 3 倍に設定されます。出⼒キューサイズを設定する
には、outputs.conf の maxQueueSize 属性を使⽤します。
属性のデフォルトは auto です。この設定をそのまま使⽤することをお勧めします。この設定では、イ
ンデクサー応答確認が有効かどうかに基づいて、キューのサイズを最適化します。
maxQueueSize
useACK=true
の場合、出⼒キューサイズは 7MB で、待機キューサイズは 21MB になります。
の場合、出⼒キューサイズは 500KB になります。
useACK=false
必要に応じて、maxQueueSize に特定の値を設定することができます。maxQueueSize の詳細は、outputs.conf spec
ファイルを参照してください。
推奨する
maxQueueSize=auto
の設定については、以下の事項に注意してください。
インデクサー応答確認を有効にした場合、キューサイズの増加はフォワーダーの再起動後にのみ反映されま
す。
auto 設定は、バージョン 5.0.4 以降のフォワーダーでのみ利⽤できます。これより前のバージョンでインデ
クサー応答確認を使⽤している場合は、maxQueueSize 属性に 7MB を明⽰的に指定する必要があります。
待機キューを考慮する理由
インデクサー応答確認を有効にする場合、フォワーダーは待機キューを使って応答確認のプロセスを管理します。
フォワーダーはデータブロックを継続的に送信し、応答確認を待たずに次のブロックを送信するため、⼀般的に待
機キューには応答確認待ちの多数のブロックが存在しています。フォワーダーは、待機キューが⼀杯になるまでブ
ロックを送信し続けます。⼀杯になった時点で、転送を停⽌します。その後フォワーダーは応答確認を受信して、
キューからブロックを解放できる状態になるまで待機し、解放できたら転送を再開します。
ネットワークやインデクサーに何か問題が発⽣した時に待機キューが⼀杯になる可能性がありますが、インデク
サーが正常に動作している場合でもキューが⼀杯になることがあります。これは、インデクサーはファイルシステ
ムにデータを書き込んだ後にのみ、応答確認を送信するためです。ファイルシステムへの書き込みが遅延すると、
応答確認も遅れるため、待機キューが⼀杯になる可能性が⾼くなります。
正常に動作しているインデクサーで、ファイルシステムへのデータ書き込みが遅延する (そして応答確認の送信も
遅延する) 理由は、いくつか考えられます。
インデクサーがビジー状態である。たとえば、データの受信時にインデクサーが複数のサーチリクエストを
処理している、または多数のフォワーダーからデータを受信している場合などが挙げられます。
インデクサーが受信しているデータ量が少なすぎる。効率性のため、インデクサーは書き込みキューが⼀杯
になった、または⼀定期間 (数秒間) 経過した場合にのみ、ファイルシステムにデータを書き込みます。書き
込みキューが⼀杯になるまで時間がかかっている場合、⼀定期間が経過するまでの間、インデクサーは書き
込みを待機します。データが数台のフォワーダーからしか転送されない場合、それらのフォワーダーが普段
通りのデータ量を転送しても、⼀定期間が経過するまでの間、データは書き込まれない可能性があります。
書き込みキューはホットバケツ単位で存在しているため、⼀部の特定のバケツのデータ受信量が少ない場合
にも、このような状況が発⽣します。通常このことは、特定のインデックスのデータ受信量が少ないことを
意味しています。
フォワーダーがインデクサーの応答確認待ちでスループットが低下することがないように、通常はデフォルト設定
の maxQueueSize=auto をそのまま使⽤してください。希にですが、応答確認の到着待ちの間、フォワーダーのメモ
リー内にすべてのブロックを保持するための⼗分なスペースを確保するために、待機キューのサイズを増やさなけ
ればならないこともあります。また、単⼀のインデクサーに多数のフォワーダーがデータを送信しており、フォ
ワーダーあたりのデータソース数が普通程度の場合は、より⼩さなサイズを指定して数メガバイトのメモリーを節
約できることもあります。
レシーバーがインデクサーではなくフォワーダーの場合
中継フォワーダー経由でデータ伝送をする場合に (オリジナルのフォワーダーが中継フォワーダーにデータを送信
し、それがインデクサーにデータを転送する)、インデクサー応答確認を使⽤することもできます。このシナリオ
では、インデクサー応答確認を使⽤する場合、データ伝送経路のすべてのセグメントで有効にすることをお勧めし
ます。そうすることで、オリジナルのフォワーダーからインデクサーまで、パス全体でのデータ配信が保証されま
す。
オリジナルのフォワーダーが中継フォワーダーにデータを送信し、次にそれがインデクサーにデータを送信する場
合を考えてみましょう。この伝送ライン全体でインデクサー応答確認を有効にするには、2 回有効にする必要があ
ります。まず、データ転送元のフォワーダーと中継フォワーダー間の応答確認を有効にして、次に中継フォワー
ダーとインデクサー間の応答確認を有効にします。
両⽅の伝送経路で有効にすると、中継フォワーダーはインデクサーから応答確認を受信するまで待機し、次にオリ
ジナルのフォワーダーに応答確認を送信します。
ただし、どちらかのセグメントでのみ応答確認を有効にすると、その伝送経路でのみインデクサー応答確認が⾏わ
れます。たとえば、オリジナルのフォワーダーから中継フォワーダーへの経路でのみインデクサー応答確認が有効
55
になっており、中継フォワーダーからインデクサーへの経路では有効になっていない場合を考えてみましょう。こ
の場合、中継フォワーダーはインデクサーにデータを送信すると、即座にオリジナルのフォワーダーに応答確認を
送信します。インデクサーへの安全なデータ送信は、TCP に依存します。この 2 番⽬の経路ではインデクサー応
答確認が有効になっていないため、中継フォワーダーはインデクサーへのデータ配信を検証することはできませ
ん。このような事例はその価値が限定されているため、お勧めすることはできません。
データのルーティングとフィルタリング
フォワーダーは、ソース、ソースタイプ、またはイベント内のパターンに基づいて、特定のレシーバーにデータを
フィルタリング/ルーティングすることができます。たとえば、フォワーダーはあるホストグループからのすべて
のデータを 1 台のインデクサーに送信し、2 番⽬のホストグループからのすべてのデータを別のインデクサーに
送信することができます。ヘビーフォワーダーはイベント内を調査して、フィルタリングやルーティングを⾏うこ
とも可能です。たとえば、ヘビーフォワーダーを使って、フィルタリングする WMI イベントコードを調査した
り、Windows イベントをルーティングしたりできます。このトピックは、⼀般的ないくつかのルーティングシナ
リオを説明しています。
またフォワーダーは、レシーバーにルーティングするだけでなく、データをフィルタリングして特定のキューに
ルーティングしたり、NULL キューにルーティングすることでデータを破棄したりすることができます。
重要： イベントレベルでデータのルーティング/フィルタリングを⾏えるのはヘビーフォワーダーのみです。ユニ
バーサルフォワーダーとライトフォワーダーには、ファイルヘッダーを抽出する場合を除いて、個別のイベントを
調査する機能はありません。ただし、データストリームのホスト、ソース、またはソースタイプに基づいてデータ
を転送することは可能です。また、データの⼊⼒スタンザに基づいてルーティングを⾏うことも可能です。後述の
「データ⼊⼒に基づいた特定のインデクサーへのデータのルーティング」を参照してください。
あるフォワーダーが 3 台のインデクサーにデータをルーティングする例を以下に⽰します。
このトピックは、Splunk Enterprise インスタンスへのイベントデータのフィルタリング/ルーティング⽅法につ
いて説明しています。⾮ Splunk システムへのルーティングについては、このマニュアルの「サードパーティ製シ
ステムへのデータの転送」を参照してください。
このトピックには、⼀部のデータのインデックスをヘビーフォワーダー上でローカルに作成し、インデックスを作
成しないデータを 1 つまたは複数の個別のインデクサーに送信するような、選択的なインデックス作成と転送⽅
法も説明されています。詳細は、このトピックの後半にある「選択的インデックス作成と転送の実⾏」を参照して
ください。
ルーティングの設定
⼤部分のルーティングシナリオを定義できる、基本パターンを以下に⽰します。
1. ルーティングに使⽤する基準を選択します。イベントのカテゴリをどのように識別し、それらをどこにルーティ
ングしますか？
2. props.conf を編集して、イベントのメタデータに基づいてルーティングを判断する、TRANSFORMS-routing
属性を追加します。
56
[<spec>]
TRANSFORMS-routing=<transforms_stanza_name>
以下の事項に注意してください。
<spec>
には、以下の値を使⽤できます。
<sourcetype>、イベントのソースタイプ
host::<host>、<host>
はイベントのホストです
はイベントのソースです
複数の TRANSFORMS 属性がある場合、それぞれに⼀意の名前を使⽤します。例：「TRANSFORMSrouting1」、「TRANSFORMS-routing2」など。
<transforms_stanza_name> は⼀意でなければなりません。
source::<source>、<source>
transforms.conf
(後述) 内にエントリを作成する場合は、ここに指定した
<transforms_stanza_name>
を使⽤します。
このトピックの後半にある例は、この構⽂の使⽤⽅法を表しています。
3. transforms.conf を編集して、イベントパターンに基づくルーティングの対象グループを指定、および追加の基
準を設定します。
[<transforms_stanza_name>]
REGEX=<routing_criteria>
DEST_KEY=_TCP_ROUTING
FORMAT=<target_group>,<target_group>,....
注意：
は、props.conf に定義されている名前と⼀致する必要があります。
には、ルーティングするイベントを決定する正規表現ルールを⼊⼒します。この⾏は必須
に指定したメタデータ以外のフィルタリングが不要な場合は、「REGEX = .」を使⽤してく
<transforms_stanza_name>
<routing_criteria>
です。props.conf
ださい。
DEST_KEY は、TCP 経由でイベントを送信する場合、_TCP_ROUTING を設定する必要があります。また、他の出
⼒プロセッサ⽤に、_SYSLOG_ROUTING または _HTTPOUT_ROUTING を設定することもできます。
FORMAT には、outputs.conf で定義した対象グループ名に⼀致する <target_group> を設定します。カンマ区切り
リストは、複数の対象グループにイベントを複製します。
このトピックの後半にある例は、この構⽂の使⽤⽅法を表しています。
4. outputs.conf を編集して、ルーティングするデータの対象グループを定義します。
[tcpout:<target_group>]
server=<ip>:<port>
注意：
に指定した名前と⼀致するように、<target_group> を設定します。
IP アドレスとポートを受信サーバーのと⼀致するように設定します。
transforms.conf
このトピックに記載されている使⽤事例は、⼀般的に以下のパターンに従っています。
対象グループへのイベントデータのフィルタリングとルーティング
この例で、ヘビーフォワーダーは 3 種類のイベントをフィルタリングして、それを異なる対象グループにルー
ティングします。フォワーダーは、以下の基準に従って、フィルタリングとルーティングを⾏います。
ソースタイプが「syslog」のイベントを、ロードバランシングされた対象グループに
単語「error」を含むイベントを 2 番⽬の対象グループに
その他のイベントをデフォルトの対象グループに
このための作業を以下に⽰します。
1. $SPLUNK_HOME/etc/system/local 内の props.conf を編集して、syslog データ⽤とその他のすべてのデータ⽤の 2 つ
の TRANSFORMS-routing 属性を設定します。
[default]
TRANSFORMS-routing=errorRouting
[syslog]
TRANSFORMS-routing=syslogRouting
2. transforms.conf を編集して、各属性のルーティングルールを設定します。
[errorRouting]
REGEX=error
57
DEST_KEY=_TCP_ROUTING
FORMAT=errorGroup
[syslogRouting]
REGEX=.
DEST_KEY=_TCP_ROUTING
FORMAT=syslogGroup
注意： この例で、syslog イベントに単語「error」が含まれている場合、それは errorGroup ではなく、syslogGroup
グループにルーティングされます。これは、前に props.conf に設定した項⽬によるものです。これらの設定は、す
べての syslog イベントが syslogRouting 変換でフィルタリングされ、すべての⾮ syslog (デフォルト) イベントが
errorRouting 変換でフィルタリングされることを表しています。そのため、⾮ syslog イベントのエラー (error) の
みが調査対象となります。
3. outputs.conf を編集して、対象グループを定義します。
[tcpout]
defaultGroup=everythingElseGroup
[tcpout:syslogGroup]
server=10.1.1.197:9996, 10.1.1.198:9997
[tcpout:errorGroup]
server=10.1.1.200:9999
[tcpout:everythingElseGroup]
server=10.1.1.250:6666
syslogGroup および errorGroup は、transforms.conf に指定されているルールに従って、イベントを受け取りま
す。その他のすべてのイベントは、デフォルトのグループ everythingElseGroup にルーティングされます。
データのサブセットのサードパーティ製システムへの複製
この例では、データのフィルタリングを⾏って、2 つのデータストリームにルーティングします。転送内容：
すべてのデータを処理済みの形式で Splunk Enterprise インデクサー (10.1.12.1:9997) に
複製されたデータのサブセットを raw 形式でサードパーティ製サーバー (10.1.12.2:1234) に
この例は、両⽅のストリームを TCP で送信します。2 番⽬のストリームを syslog データとして送信するには、
まずデータをインデクサー経由でルーティングします。
1. props.conf を編集します。
[syslog]
TRANSFORMS-routing = routeAll, routeSubset
2. transforms.conf を編集します。
[routeAll]
REGEX=(.)
DEST_KEY=_TCP_ROUTING
FORMAT=Everything
[routeSubset]
REGEX=(SYSTEM|CONFIG|THREAT)
DEST_KEY=_TCP_ROUTING
FORMAT=Subsidiary,Everything
3. outputs.conf を編集します。
[tcpout]
defaultGroup=nothing
[tcpout:Everything]
disabled=false
server=10.1.12.1:9997
[tcpout:Subsidiary]
disabled=false
sendCookedData=false
server=10.1.12.2:1234
58
詳細は、このマニュアルの「サードパーティ製システムへのデータの転送」を参照してください。
イベントデータのフィルタリングとキューへの送信
フォワーダーベースのルーティングと似ていますが、インデクサーやヘビーフォワーダーで、キューによるルー
ティングを⾏うことができます。outputs.conf ファイルは使⽤しません。props.conf と transforms.conf のみを使⽤
します。
不要なデータは nullQueue にルーティングすることで、排除することができます。これは、Splunk の /dev/null と
同等です。 この⽅法でデータを除外すると、そのデータは転送されることも、インデックスに追加されることも
ありません。また、インデックス作成量にもカウントされません。
特定のイベントを破棄して残りを保持する
この例は、/var/log/messages 内のすべての
sshd
イベントを、nullQueue に送信して破棄します。
1. props.conf で、TRANSFORMS-null 属性を設定します。
[source::/var/log/messages]
TRANSFORMS-null= setnull
2. transforms.conf で、対応するスタンザを作成します。DEST_KEY に「queue」を、FORMAT に「nullQueue」を設定
します。
[setnull]
REGEX = \[sshd\]
DEST_KEY = queue
FORMAT = nullQueue
これで完了です。
特定のイベントを保持して残りを破棄する
ここでは先ほどとは逆のシナリオを取り上げます。この例では、sshd イベントのみを保持するために、2 つの属性
を使⽤します。⽚⽅の属性は sshd イベントを indexQueue にルーティングし、もう⼀⽅はその他のすべてのイベン
トを次の場所にルーティングします： nullQueue.
注意： この例では、props.conf 内の変換の順番が重要になります。NULL キューへのルーティングを最初に指定す
る必要があります。後に指定すると、前の属性が無効になりすべてのイベントが NULL キューにルーティングさ
れます。
1. props.conf で：
[source::/var/log/messages]
TRANSFORMS-set= setnull,setparsing
2. transforms.conf で：
[setnull]
REGEX = .
DEST_KEY = queue
FORMAT = nullQueue
[setparsing]
REGEX = \[sshd\]
DEST_KEY = queue
FORMAT = indexQueue
WMI イベントのフィルタリング
WinEventLog はフォワーダー・レベルで直接フィルタリングできます。
WMI イベントをフィルタリングするには、props.conf 内で [WMI:WinEventLog:Security] ソースタイプのスタン
ザを使⽤します。以下の例は正規表現を使って、2 種類の Windows イベントコード 592 および 593 をフィルタ
リングしています。
props.conf
で：
[WinEventLog:Security]
TRANSFORMS-wmi=wminull
59
注意： 4.2.x より前のバージョンの Splunk Enterprise では、イベントを nullQueue に送信するために、ソース
タイプとして [wmi] または [WMI::WinEventLog:Security] を使⽤する必要があります。
transforms.conf
で：
[wminull]
REGEX=(?m)^EventCode=(592|593)
DEST_KEY=queue
FORMAT=nullQueue
ターゲットインデックスによるデータのフィルタリング
フォワーダーは、データのターゲットインデックスに基づいてデータを転送するかどうかを指定す
る、forwardedindex フィルタを保有しています。たとえば、あるデータ⼊⼒に「index1」を宛先とするデータ
と「index2」を宛先とするデータが存在する場合、このフィルタを使って index1 宛のデータのみを転送して、
index2宛のデータを無視することができます。forwardedindex フィルタは、ホワイトリスト (whitelists ) とブ
ラックリスト (blacklists ) を使ってフィルタリングを指定します。複数のインデックスの設定については、「複
数のインデックスの設定」を参照してください。
注意： forwardedindex フィルタは、グローバルの
スタンザに指定しても、それは適⽤されません。
[tcpout]
スタンザにのみ適⽤できます。outputs.conf 内の他の
インデックス単位で転送するデータを指定するには、outputs.conf で forwardedindex.<n>.whitelist|blacklist を使⽤
します。属性にターゲットインデックスをフィルタリングする正規表現を指定します。
デフォルトの動作
デフォルトでフォワーダーは、デフォルトのインデックスやユーザーが作成したインデックスも含めて、すべての
外部インデックス宛のデータを転送します。内部インデックス⽤のデータについては、転送の担当に応じてデフォ
ルトの動作が異なります。
ユニバーサルフォワーダー は、_audit 内部インデックス⽤のデータのみを転送します。他の内部インデッ
クス⽤データは転送しません。この動作は、$SPLUNK_HOME/etc/apps/SplunkUniversalForwarder/default 内にある
デフォルトの outputs.conf ファイルに、以下の属性を使って指定されています。
[tcpout]
forwardedindex.0.whitelist = .*
forwardedindex.1.blacklist = _.*
forwardedindex.2.whitelist = _audit
ヘビーフォワーダーおよび転送が有効になっている完全版 Splunk インスタンス (たとえば、転送が有
効になっているサーチヘッドなど) は、_audit および _internal 内部インデックス⽤のデータを転送します。
この動作は、$SPLUNK_HOME/etc/system/default 内にあるデフォルトの outputs.conf ファイルに、以下の属性を
使って指定されています。
[tcpout]
forwardedindex.0.whitelist = .*
forwardedindex.1.blacklist = _.*
forwardedindex.2.whitelist = (_audit|_internal)
注意： ヘビーフォワーダーと完全版 Splunk Enterprise インスタンスのデフォルトの動作は、Splunk Enterprise
5.0.2 で変更されました。前のバージョンでは、_internal インデックスはデフォルトでは転送されません。それら
のフォワーダータイプは、ユニバーサルフォワーダーと同じ動作となり、_audit 内部インデックスのデータのみが
転送されます。
⼤部分のデプロイ環境では、デフォルト設定を変更する必要はありません。インデックスのホワイトリストとブ
ラックリストの設定については、outputs.conf を参照してください。デフォルトおよびカスタムの outputs.conf
ファイルとその場所については、「outputs.conf ファイルの種類」を参照してください。
すべての外部および内部インデックスデータの転送
すべての外部データだけでなく、すべての内部インデックスデータも転送する場合は、以下のようにデフォルトの
forwardedindex フィルタ属性に優先する設定を⾏います。
#Forward everything
[tcpout]
forwardedindex.0.whitelist = .*
# disable these
forwardedindex.1.blacklist =
forwardedindex.2.whitelist =
60
単⼀インデックス⽤データのみを転送する
単⼀のインデックス (たとえば、inputs.conf に指定) ⽤のデータのみを転送し、そのインデックス宛以外のすべて
のデータを破棄するには、以下のように指定します。
[tcpout]
#Disable the current filters from the defaults outputs.conf
forwardedindex.0.whitelist =
forwardedindex.1.blacklist =
forwardedindex.2.whitelist =
#Forward data for the "myindex" index
forwardedindex.0.whitelist = myindex
これは、まずデフォルトの outputs.conf ファイルから、すべてのフィルタを無効にします。次に独⾃のインデック
ス⽤のフィルタを設定します。次のように、フィルタの番号は 0 から始まることに注意してくださ
い：forwardedindex.0。
注意： システムにある他の
あります。
outputs.conf
のコピーに別のフィルタを設定している場合、それらも無効にする必要が
CLI コマンド btools を使⽤して、システム内の他の
ことができます。
outputs.conf
ファイルにフィルタがないかどうかを確認する
splunk cmd btool outputs list tcpout
このコマンドは、すべての設定ファイルを結合した後の、tcpout スタンザのコンテンツを返します。
forwardedindex 属性の使⽤とローカルのインデックス作成
ヘビーフォワーダーでは、ローカルにインデックスを作成することができます。そのためには、indexAndForward 属
性に「true」を設定する必要があります。そうしないと、データは単純に転送され、フォワーダー上に保管される
ことはありません。⼀⽅ forwardedindex 属性は、転送するデータをフィルタリングするだけで、ローカルインデッ
クスに保存されるデータをフィルタリングすることはありません。
簡単に⾔うと、ローカルインデックスの作成とフォワーダーのフィルタリングは個別の操作で、相互に連携するこ
とはありません。これにより、ブラックリストのフィルタリングを実⾏する際に、予期しない結果が⽣じることが
あります。
に「true」を設定し、その後 forwardedindex ブラックリスト属性を使って⼀部のデータをフィ
ルタリングした場合、ブラックリストに⼀致するデータは転送されませんが、ローカルにインデックスが作
成されます。
indexAndForward に「false」を設定して (ローカルインデックスを作成しない)、⼀部のデータをフィルタリン
グした場合、フィルタリングされたデータは転送もフォワーダー上に保存 (インデックス作成) もされないた
め、完全に破棄されます。
indexAndForward
データの⼊⼒に基づいた特定のインデクサーへのルーティング
ヘビーフォワーダーを必要としないルーティングが 1 種類あります。このシナリオでは、inputs.conf および
outputs.conf を使って、データの⼊⼒に基づいて特定のインデクサーにデータをルーティングします。
⽅法を以下に⽰します。
1. outputs.conf に、各受信インデクサーのスタンザを作成します。
[tcpout:systemGroup]
server=server1:9997
[tcpout:applicationGroup]
server=server2:9997
2. inputs.conf で、_TCP_ROUTING を使って、各⼊⼒がルーティングに使⽤する
す。
outputs.conf
内のスタンザを指定しま
[monitor://.../file1.log]
_TCP_ROUTING = systemGroup
[monitor://.../file2.log]
_TCP_ROUTING = applicationGroup
フォワーダーは
file1.log
からのデータを
server1
に、file2.log からのデータを
61
server2
にルーティングします。
選択的インデックス作成と転送の実⾏
ヘビーフォワーダーのみが 、データのインデックスをローカルに作成、保管しながら、それをインデクサーに転
送することができます。このためには、2 種類の⽅法があります。
転送する前にすべてのデータのインデックスを作成する。 このためには、outputs.conf の
属性を有効にします。
indexAndForward
⼀部のデータのインデックスを作成してから転送する、またはインデックスを作成しなかったデータ
を転送する。 これは、選択的インデックス作成 と呼ばれています。選択的インデックス作成では、⼀部の
データのみインデックスを作成し、それをインデクサーに転送することができます。または、ローカルにイ
ンデックスを作成しなかったデータのみを転送することもできます。
重要： 選択的インデックス作成を有効にする場合は、[tcpout] スタンザ内の
でください。
indexAndForward
属性を有効にしない
選択的インデックス作成の設定
選択的インデックス作成を使⽤するには、inputs.conf と
outputs.conf
ファイルの両⽅を変更する必要があります。
1. outputs.conf で：
a.
[indexAndForward]
スタンザを追加します。
[indexAndForward]
index=true
selectiveIndexing=true
および selectiveIndexing 属性を含めたこのスタンザの存在により、フォワーダーの選択的インデックス作成
が有効になります。これは、任意の⼊⼒ (inputs.conf に指定) の、_INDEX_AND_FORWARD_ROUTING 属性を持つデータの
ローカルインデックス作成を有効にします。[indexAndForward] スタンザ全体を、ここに記載されている通りに使⽤
してください。
index
注意： これはグローバルスタンザで、outputs.conf に 1 回のみ指定します。
b. 各受信インデクサーのセットに対して、通常の対象グループスタンザを含めます。
[tcpout:<target_group>]
server = <ip address>:<port>, <ip address>:<port>, ...
...
inputs.conf
内で名前付き
<target_group>
を使⽤して、以下のように⼊⼒をルーティングします。
2. inputs.conf で：
a. ローカルにインデックスを作成する各⼊⼒のスタンザに、_INDEX_AND_FORWARD_ROUTING 属性を追加します。
[input_stanza]
_INDEX_AND_FORWARD_ROUTING=<any_string>
...
属性を指定することで、ヘビーフォワーダーにその⼊⼒のインデックスをローカルに作
成することを指⽰します。この属性には、任意の⽂字列値を設定できます。フォワーダーは単純に属性を参照しま
す。⽂字列値が動作に影響することはありません。
_INDEX_AND_FORWARD_ROUTING
b. 転送する各⼊⼒のスタンザに、_TCP_ROUTING 属性を追加します。
[input_stanza]
_TCP_ROUTING=<target_group>
...
<target_group>
は、outputs.conf で受信インデクサーの対象グループを指定するために使⽤されている名前です。
次のいくつかのセクションでは、さまざまな場⾯での選択的インデックス作成の使⽤⽅法を説明しています。
1 つの⼊⼒のインデックスをローカルに作成し、残りの⼊⼒を転送する
この例では、フォワーダーは 1 つの⼊⼒からのデータのインデックスをローカルに作成しますが、転送は⾏いま
せん。また、他の 2 つの⼊⼒からのデータを転送しますが、それについてはローカルにインデックスを作成しま
せん。
1. outputs.conf で以下のスタンザを作成します。
62
[tcpout]
defaultGroup=noforward
disabled=false
[indexAndForward]
index=true
selectiveIndexing=true
[tcpout:indexerB_9997]
server = indexerB:9997
[tcpout:indexerC_9997]
server = indexerC:9997
には存在しないグループ「noforward」 (defaultGroup が存在しないという意味) が設定されているた
め、フォワーダーは inputs.conf 内に明⽰的に対象グループへのルーティングが設定されているデータのみを転送
します。その他のデータはすべて破棄されます。
defaultGroup
2. inputs.conf で以下のスタンザを作成します。
[monitor:///mydata/source1.log]
_INDEX_AND_FORWARD_ROUTING=local
[monitor:///mydata/source2.log]
_TCP_ROUTING=indexerB_9997
[monitor:///mydata/source3.log]
_TCP_ROUTING=indexerC_9997
結果となるフォワーダーは：
データのインデックスをローカルに作成しますが、転送は⾏いません (⼊⼒スタンザに明⽰的な
ルーティングが指定されておらず、outputs.conf 内にデフォルトのグループも設定されていないため)。
source2.log データを indexerB に転送しますが、ローカルにインデックスは作成されません。
source3.log データを indexerC に転送しますが、ローカルにインデックスは作成されません。
source1.log
1 つの⼊⼒のインデックスをローカルに作成し、すべての⼊⼒を転送する
この例は前の例とほとんど同じです。違いは、1 つの⼊⼒のインデックスをローカルに作成しますが、ローカルに
インデックスを作成したデータも含め、すべての⼊⼒のデータを転送することです。
1. outputs.conf で以下のスタンザを作成します。
[tcpout]
defaultGroup=noforward
disabled=false
[indexAndForward]
index=true
selectiveIndexing=true
[tcpout:indexerB_9997]
server = indexerB:9997
[tcpout:indexerC_9997]
server = indexerC:9997
この
outputs.conf
は前の例と同じです。
2. inputs.conf で以下のスタンザを作成します。
[monitor:///mydata/source1.log]
_INDEX_AND_FORWARD_ROUTING=local
_TCP_ROUTING=indexerB_9997
[monitor:///mydata/source2.log]
_TCP_ROUTING=indexerB_9997
[monitor:///mydata/source3.log]
_TCP_ROUTING=indexerC_9997
63
前の例との唯⼀の違いは、ここでローカルにインデックスを作成する⼊⼒の _TCP_ROUTING 属性を指定していること
です。フォワーダーは source1.log と source2.log の両⽅を対象グループ indexerB_9997 に転送しますが、source1.log
からのデータのみ、ローカルにインデックスを作成します。
1 つの⼊⼒のインデックスをローカルに作成し、すべての⼊⼒を転送する別の⽅法
defaultGroup
に実際の対象グループを設定することで、前の例と同じ結果を実現することができます。
1. outputs.conf で以下のスタンザを作成します。
[tcpout]
defaultGroup=indexerB_9997
disabled=false
[indexAndForward]
index=true
selectiveIndexing=true
[tcpout:indexerB_9997]
server = indexerB:9997
[tcpout:indexerC_9997]
server = indexerC:9997
この
outputs.conf
は、defaultGroup に
indexerB_9997
を設定します。
2. inputs.conf で以下のスタンザを作成します。
[monitor:///mydata/source1.log]
_INDEX_AND_FORWARD_ROUTING=local
[monitor:///mydata/source2.log]
_TCP_ROUTING=indexerB_9997
[monitor:///mydata/source3.log]
_TCP_ROUTING=indexerC_9997
のルーティングを明⽰的に設定しない場合でも、outputs.conf にそのグループが
定されているため、indexerB_9997 対象グループにデータが転送されます。
source1.log
defaultGroup
として設
選択的インデックス作成と内部ログ
で選択的インデックス作成を有効にしたら、フォワーダーは _INDEX_AND_FORWARD_ROUTING 属性を持つ⼊
⼒のみ、ローカルにインデックスを作成します。これは、/var/log/splunk ディレクトリ内の内部ログに適⽤されま
す (デフォルトの etc/system/default/inputs.conf に指定)。デフォルトでは、これらのインデックスは作成されませ
ん。これらのインデックスを作成する場合は、ローカルの inputs.conf ファイル (デフォルトファイルに優先する)
にそれらの⼊⼒スタンザを追加し、_INDEX_AND_FORWARD_ROUTING 属性を含める必要があります。
outputs.conf
[monitor://$SPLUNK_HOME/var/log/splunk]
index = _internal
_INDEX_AND_FORWARD_ROUTING=local
サードパーティ製システムへのデータの転送
Splunk Enterprise フォワーダーは、⾮ Splunk システムに raw データを転送することができます。データは
TCP ソケットまたは標準の syslog にパッケージ化して送信できます。⾮ Splunk システムに転送するため、raw
データのみを送信できます。
outputs.conf、props.conf、および transforms.conf,
を編集することで、ヘビーフォワーダーが他の Splunk インス
タンスに条件的にデータをルーティングするのと同様に、条件に応じてデータをサードパーティ製システムにルー
ティングするように設定することができます。データはホスト、ソース、またはソースタイプでフィルタリングで
きます。また、正規表現でデータを指定することもできます。
TCP データ
TCP データをサードパーティ製システムに転送するには、フォワーダーの outputs.conf ファイルを編集して、受
信サーバーとポートを指定します。また、受信サーバーがそのポートで到着するデータストリームを待機するよう
に設定する必要もあります。ユニバーサルフォワーダーなど任意のタイプのフォワーダーを使って、この種類の転
送を実施することができます。
データをルーティングするには、データをパーシングできるヘビーフォワーダーを使⽤する必要があります。フォ
ワーダーの props.conf および transforms.conf ファイル、そして outputs.conf を編集します。
64
設定ファイルの編集
単純にデータを転送するには、outputs.conf を編集します。
受信サーバーの対象グループを指定します。
各受信サーバーの IP アドレスと TCP ポートを指定します。
フォワーダーが raw データを送信するように、sendCookedData に
false
を設定します。
データをルーティング、フィルタリングするには (ヘビーフォワーダーのみ)、props.conf と
します。
transforms.conf
も編集
に、データストリームのホスト、ソース、またはソースタイプを指定します。⼊⼒に実⾏する
transform を指定します。
transforms.conf で、transform を定義して _TCP_ROUTING を指定します。また、正規表現を使ってさらにデー
タをフィルタリングすることもできます。
props.conf
すべてのデータを転送する
この例では、ユニバーサルフォワーダーからサードパーティ製システムに、すべてのデータを送信する⽅法を説明
していきます。すべてのデータを送信するため、outputs.conf しか編集する必要はありません。
[tcpout]
[tcpout:fastlane]
server = 10.1.1.35:6996
sendCookedData = false
データのサブセットの転送
この例は、ヘビーフォワーダーを使ったデータのサブセットのフィルタリングと、サブセットのサードパーティ製
システムへの送信⽅法を説明しています。
1. props.conf および
props.conf
transforms.conf
を編集して、フィルタリング基準を指定します。
で、nyc から始まるすべてのホスト名に
bigmoney
を適⽤します。
[host::nyc*]
TRANSFORMS-nyc = bigmoney
で、bigmoney 変換を設定して、TCP_ROUTING を
として指定します。
transforms.conf
FORMAT
DEST_KEY
として、対象グループ
bigmoneyreader
を
[bigmoney]
REGEX = .
DEST_KEY=_TCP_ROUTING
FORMAT=bigmoneyreader
2. outputs.conf で、⾮ Splunk サーバーの対象グループ
の対象グループを定義します。
bigmoneyreader
と、その他のデータを受信するデフォルト
[tcpout]
defaultGroup = default-clone-group-192_168_1_104_9997
[tcpout:default-clone-group-192_168_1_104_9997]
server = 192.168.1.104:9997
[tcpout:bigmoneyreader]
server=10.1.1.197:7999
sendCookedData=false
フォワーダーは、nyc から始まるホスト名からのすべてのデータを、対象グループ bigmoneyreader に指定されてい
る⾮ Splunk サーバーに送信します。その他のホストからのすべてのデータは、対象グループ default-clone-group192_168_1_104_9997 に指定されているサーバーに送信します。
注意： props.conf および
を設定します。
transforms.conf
に指定されているデータのみを転送したい場合は、defaultGroup=nothing
syslog データ
ヘビーフォワーダーを使って、標準の syslog 形式でデータを送信することができます。フォワーダーは、個別の
出⼒プロセッサ経由でデータを送信します。props.conf および transforms.conf を使ってデータをフィルタリングす
65
ることもできます。DEST_KEY として _SYSLOG_ROUTING を指定する必要があります。
注意： ユニバーサルフォワーダーまたはライトフォワーダーでは、syslog 出⼒プロセッサは使⽤できません。
syslog 出⼒プロセッサは RFC 3164 に準拠したイベントを TCP/UDP ベースのサーバーおよびポートに送信
し、⾮準拠データのペイロードを RFC 3164 準拠にしています。これが Windows イベントログを意味していま
す。
syslog データを転送するには、サードパーティ製の受信サーバーを、フォワーダーの
対象グループ syslog に指定します。
outputs.conf
ファイル内の
注意： syslog データに対して複数のイベントタイプを定義した場合、すべてのイベントタイプ名が⽂字列
「syslog」を含む必要があります。
syslog データの転送
outputs.conf
に、対象グループ
syslog
を指定します。
[syslog:<target_group>]
<attribute1> = <val1>
<attribute2> = <val2>
...
対象グループのスタンザには、以下の属性が必要です。
必要な属性
server
デフォル
ト
N/A
値
この形式は <ipaddress_or_servername>:<port> でなければなりません。これは、
syslog サーバーの IP アドレスまたはサーバー名と、syslog サーバーが待機する
ポートの組み合わせです。デフォルトで syslog サーバーは、ポート 514 を使⽤し
ます。
以下の属性は、必要に応じて指定します (省略可)。
オプション属性
デフォルト
type
UDP
priority
<13> - これ
は、facility
1
(「user」)
および
severity 5
(「notice」)
を意味して
います。
syslogSourceType N/A
timestampformat
""
値
伝送プロトコル。「tcp」または「udp」を設定します。
syslog の優先度。1〜3 桁の整数を、⼭括弧で囲む必要があります (例：
<34>)。この値は syslog ヘッダーに表⽰されます。
syslog インターフェイス呼び出し経由で渡される数字と似ています。詳細は
outputs.conf を参照してください。
優先度値を (<facility> * 8) + <severity> として計算します。facility が 4
(セキュリティ/認証メッセージ) で severity が 2 (重⼤な状態) の場合、優先
度の値は (4 * 8) + 2 = 34 となり、conf ファイルに <34> と指定する必要
があります。
sourcetype::syslog
の形式で、syslog メッセージのソースタイプを指定しま
す。
ヘッダーにタイムスタンプを追加する場合に使⽤するフォーマットです。こ
れは、次の形式でなければなりません：<%b %e %H:%M:%S>。詳細は、
『データの取り込み』マニュアルの「タイムスタンプの設定」を参照してく
ださい。
データのサブセットを syslog サーバーに送信する
この例は、ホスト名が「nyc」から始まるホストからのデータを、syslog サーバー「loghost.example.com」に
ポート 514 経由で送信するように、ヘビーフォワーダーを設定する⽅法を表しています。
1. props.conf および
props.conf
transforms.conf
を編集して、フィルタリング基準を指定します。
で、nyc から始まるすべてのホスト名に
send_to_syslog
を適⽤します。
[host::nyc*]
TRANSFORMS-nyc = send_to_syslog
transforms.conf
my_syslog_group
で、send_to_syslog 変換を設定して、_SYSLOG_ROUTING を
を FORMAT として指定します。
66
DEST_KEY
として、対象グループ
[send_to_syslog]
REGEX = .
DEST_KEY = _SYSLOG_ROUTING
FORMAT = my_syslog_group
2. outputs.conf に、⾮ Splunk サーバー⽤の対象グループ
my_syslog_group
を定義します。
[syslog:my_syslog_group]
server = loghost.example.com:514
ヘビーフォワーダーとライトフォワーダー
ヘビーフォワーダーのデプロイ
転送と受信を有効にするには、レシーバー とフォワーダー の両⽅を設定します。レシーバーは、データを受信す
る Splunk Enterprise インスタンスです。フォワーダーがレシーバーにデータを送信します。
まず「レシーバーを有効にする」の説明に従って、レシーバーを設定する必要があります。次に、レシーバーに
データを送信するフォワーダーを設定します。
ヘビー フォワーダーの設定プロセスは、2 つのステップから成り⽴っています。
1. 完全版 Splunk インスタンスをインストールします。
2. インスタンスの転送機能を有効にします。
これらのステップの詳細は後のセクションで説明されています。
重要： このトピックは、ヘビーフォワーダー固有のデプロイ/設定上の問題について説明しています。ユニバーサ
ルフォワーダー のデプロイ⽅法については、「ユニバーサルフォワーダーのデプロイの概要」を参照してくださ
い。
完全版 Splunk インスタンスのインストール
ヘビーフォワーダーをデプロイするには、まず完全版の Splunk Enterprise インスタンスをインストールする必
要があります。システム要件やライセンス情報も含めた Splunk Enterprise のインストールの詳細は、『インス
トールマニュアル』を参照してください。
Splunk インスタンスをインストールしたら、そのフォワーダー機能を有効にすることができます。
転送の設定
Splunk Web または CLI を使って、Splunk Enterprise インスタンスの転送を有効にすることができます。
また、Splunk Enterprise インスタンス上の outputs.conf ファイルを作成して、転送の有効化や設定を⾏うことも
可能です。outputs.conf によるフォワーダーの設定にはさまざまな事項を理解する必要がありますが、単⼀の場所
からすべてのフォワーダーを設定することには、明⽩な利点があります。⾼度な設定オプションの⼤半
は、outputs.conf でのみ利⽤することができます。また、複数のフォワーダーを有効化、設定する場合、単⼀の
outputs.conf ファイルを編集して、そのコピーを各フォワーダーに配布することで⼿軽に作業を⾏えます。詳細
は、「outputs.conf によるフォワーダーの設定」を参照してください。
Splunk Web によるヘビーフォワーダーの設定
Splunk Web を使って、ヘビーフォワーダーを設定することができます。
1. データを転送するサーバー上で、Splunk Web に管理者 (admin) としてログインします。
2. ページの上部にある [設定] リンクをクリックします。
3. [データ] の [転送と受信] を選択します。
4. [データの転送] の [新規追加] をクリックします。
5. 受信 Splunk Enterprise インスタンスのホスト名または IP アドレス、およびレシーバー設定時に指定した受信
ポート を⼊⼒します。たとえば、次のように⼊⼒します：receivingserver.com:9997.ロードバランシングを導⼊す
るために、複数のホストをカンマ区切りリストで指定することができます。
6. [保存] をクリックします。処理を完了するには、インスタンスを再起動する必要があります。
他の設定に Splunk Web を使⽤することができます。インデックスデータをフォワーダーにローカルに保管する
には：
1. [転送と受信] で、[転送のデフォルト] を選択します。
2. フォワーダー上にインデックスデータのローカルコピーを保持するには、[はい] を選択します。
重要： ヘビーフォワーダーは、ライトフォワーダーやユニバーサルフォワーダーと⽐べて、データのインデック
スをローカルに作成できます。また、他のインデックスにもデータを転送できます。ただし、デフォルトではロー
67
カルのインデックス作成はオフになっています。フォワーダー上でデータを保管する場合、上記の説明に従って、
または outputs.conf を編集して、この機能を有効にする必要があります。
その他のすべての設定は、次のファイルで⾏う必要があります：
outputs.conf.
CLI によるヘビーフォワーダーの設定
CLI によるフォワーダーの設定は、2 つのステップから成り⽴っています。まず、Splunk Enterprise インスタン
スの転送機能を有効にします。次に、特定のレシーバーへの転送を開始します。
CLI にアクセスするには、まず
$SPLUNK_HOME/bin/
に移動します。
フォワーダーモードを有効にするには 、以下のように⼊⼒します。
splunk enable app SplunkForwarder -auth <username>:<password>
フォワーダーモードを無効にするには 、以下のように⼊⼒します。
splunk disable app SplunkForwarder -auth <username>:<password>
このコマンドで転送を無効にすることで、フォワーダーは完全版の Splunk Enterprise インスタンスに戻りま
す。
重要： コマンドを実⾏した後は、フォワーダーを再起動してください。
CLI からの転送の開始
CLI にアクセスするには、まず
$SPLUNK_HOME/bin/
転送活動を開始するには 、splunk
に移動します。
add forward-server
コマンドでレシーバーを指定します。
splunk add forward-server <host>:<port> -auth <username>:<password>
転送活動を終了するには 、以下のコマンドを⼊⼒します。
splunk remove forward-server <host>:<port> -auth <username>:<password>
注意： このコマンドは転送活動を終了しますが、インスタンスは引き続きフォワーダーとして設定されていま
す。フォワーダーを完全版の Splunk Enterprise インスタンスに戻すには、前述のように disable コマンドを使⽤
します。
重要： コマンドを実⾏した後は、フォワーダーを再起動してください。
フォワーダーのアップグレード
フォワーダーを新しいバージョンにアップグレードするには、通常のようにインスタンスをアップグレードしま
す。詳細は、『インストールマニュアル』のアップグレードに関するセクションを参照してください。
重要： アップグレード作業を⾏う前に、本当にアップグレードが必要かどうかを確認してください。多くの場
合、フォワーダーをアップグレードする差し迫った理由はありません。フォワーダーは常に最新版のインデクサー
と互換性があります。そのため、データの送信先インデクサーをアップグレードしたからといって、フォワーダー
をアップグレードする必要はありません。
まずファイルをバックアップ
アップグレードを実⾏する前に、すべてのファイルをバックアップすることを強くお勧めします。特に、Splunk
Enterprise 設定ファイルは必ずバックアップしてください。設定のバックアップの詳細は、『管理マニュアル』
の「設定情報のバックアップ」を参照してください。
データのインデックスをローカルに作成するヘビーフォワーダーをアップグレードする場合、インデックスデータ
もバックアップする必要があります。データのバックアップについては、『インデクサーとインデクサー・クラス
タの管理』マニュアルの「インデックス作成されたデータのバックアップ」を参照してください。
前のバージョンにダウングレードすることはできません。古いリリースのフォワーダーに戻す必要がある場合は、
インスタンスを再インストールしてください。
ライトフォワーダーのデプロイ
注意： ライトフォワーダーは Splunk Enterprise 6.0 で廃⽌予定で、⾮推奨となりました。⾮推奨で廃⽌予定の
機能の⼀覧は、リリースノートの「⾮推奨 (廃⽌予定) の機能」を参照してください。
転送と受信を有効にするには、レシーバー とフォワーダー の両⽅を設定します。レシーバーは、データを受信す
る Splunk Enterprise インスタンスです。フォワーダーがレシーバーにデータを送信します。
まずレシーバーを設定する必要があります。次に、レシーバーにデータを送信するフォワーダーを設定します。
68
ライト フォワーダーの設定プロセスは、2 つのステップから成り⽴っています。
1. 完全版 Splunk インスタンスをインストールします。
2. インスタンスの転送機能を有効にします。
これらのステップの詳細は後のセクションで説明されています。
重要： このトピックは、ライトフォワーダー固有のデプロイ/設定上の問題について説明しています。ユニバーサ
ルフォワーダー のデプロイ⽅法については、「ユニバーサルフォワーダーのデプロイの概要」を参照してくださ
い。
完全版 Splunk インスタンスのインストール
ライトフォワーダーをデプロイするには、まず完全版の Splunk Enterprise インスタンスをインストールする必
要があります。システム要件やライセンス情報も含めた Splunk Enterprise のインストールの詳細は、『インス
トールマニュアル』を参照してください。
インスタンスをインストールしたら、そのライトフォワーダー機能を有効にすることができます。
注意： ライトフォワーダーとして使⽤する Splunk Enterprise インスタンスをインストールする場合、フォワー
ダーライセンスを選択します。詳細は、「Splunk ライセンスのタイプ」を参照してください。
転送の設定
CLI を使って、転送を有効にすることができます。
また、Splunk Enterprise インスタンス上の outputs.conf ファイルを作成して、転送の有効化や設定を⾏うことも
可能です。outputs.conf によるフォワーダーの設定にはさまざまな事項を理解する必要がありますが、単⼀の場所
からすべてのフォワーダーを設定することには、明⽩な利点があります。⾼度な設定オプションの⼤半
は、outputs.conf でのみ利⽤することができます。また、複数のフォワーダーを有効化、設定する場合、単⼀の
outputs.conf ファイルを編集して、そのコピーを各フォワーダーに配布することで⼿軽に作業を⾏えます。詳細
は、「outputs.conf によるフォワーダーの設定」を参照してください。
CLI によるライトフォワーダーの設定
CLI によるフォワーダーの設定は、2 つのステップから成り⽴っています。まず、インスタンスの転送機能を有効
にします。次に、特定のレシーバーへの転送を開始します。
CLI にアクセスするには、まず
$SPLUNK_HOME/bin/
に移動します。
ライトフォワーダーモードを有効にするには 、以下のように⼊⼒します。
splunk enable app SplunkLightForwarder -auth <username>:<password>
ライトフォワーダーモードを無効にするには 、以下のように⼊⼒します。
splunk disable app SplunkLightForwarder -auth <username>:<password>
このコマンドで転送を無効にすることで、フォワーダーは完全版の Splunk Enterprise インスタンスに戻りま
す。
重要： コマンドを実⾏した後は、フォワーダーを再起動してください。
CLI からの転送の開始
CLI にアクセスするには、まず
$SPLUNK_HOME/bin/
転送活動を開始するには 、splunk
に移動します。
add forward-server
コマンドでレシーバーを指定します。
splunk add forward-server <host>:<port> -auth <username>:<password>
転送活動を終了するには 、以下のコマンドを⼊⼒します。
splunk remove forward-server <host>:<port> -auth <username>:<password>
注意： このコマンドは転送活動を終了しますが、インスタンスは引き続きフォワーダーとして設定されていま
す。インスタンスを完全版の Splunk Enterprise インスタンスに戻すには、前述のように disable コマンドを使⽤
します。
重要： コマンドを実⾏した後は、フォワーダーを再起動してください。
フォワーダーのアップグレード
フォワーダーを新しいバージョンにアップグレードするには、通常のようにインスタンスをアップグレードしま
69
す。詳細は、『インストールマニュアル』のアップグレードに関するセクションを参照してください。
重要： アップグレード作業を⾏う前に、本当にアップグレードが必要かどうかを確認してください。多くの場
合、フォワーダーをアップグレードする差し迫った理由はありません。フォワーダーは常に最新版のインデクサー
と互換性があります。そのため、データの送信先インデクサーをアップグレードしたからといって、フォワーダー
をアップグレードする必要はありません。
まずファイルをバックアップ
アップグレードを実⾏する前に、すべてのファイルをバックアップすることを強くお勧めします。特に、設定ファ
イルは必ずバックアップしてください。設定のバックアップの詳細は、『管理マニュアル』の「設定情報のバック
アップ」を参照してください。
ヘビーフォワーダーとライトフォワーダーの機能
ヘビー/ライトフォワーダーでは、特定の機能が無効になっています。このセクションは、フォワーダーの機能の
詳細を説明しています。
注意： ライトフォワーダーは Splunk Enterprise 6.0 で廃⽌予定で、⾮推奨となりました。⾮推奨で廃⽌予定の
機能の⼀覧は、リリースノートの「⾮推奨 (廃⽌予定) の機能」を参照してください。
ヘビーフォワーダーの詳細
ヘビーフォワーダーはデフォルトで、すべての Splunk Enterprise 機能とモジュールが有効になっています。た
だし、分散サーチモジュールだけは無効になっています。$SPLUNK_HOME/etc/apps/SplunkForwarder/default/defaultmode.conf ファイルには、以下のスタンザが存在しています。
[pipeline:distributedSearch]
disabled = true
設定の詳細は、$SPLUNK_HOME/etc/apps/SplunkForwarder/default にある SplunkForwarder アプリケーションの設定
ファイルを参照してください。
ライトフォワーダーの詳細
ライトフォワーダーでは、⼤半の Splunk Enterprise 機能が無効になっています。特にライトフォワーダーで
は：
イベント署名とディスクが⼀杯かどうかの確認 ($SPLUNK_HOME/etc/apps/SplunkLightForwarder/default/defaultmode.conf) が無効になっています。
内部データ⼊⼒を splunkd および測定基準ログのみに制限します
($SPLUNK_HOME/etc/apps/SplunkLightForwarder/default/inputs.conf)。
すべてのインデックス作成機能が無効になっています
($SPLUNK_HOME/etc/apps/SplunkLightForwarder/default/indexes.conf)。
transforms.conf を使⽤せず、受信データを完全にはパーシングしませんが、props.conf からの CHARSET,
CHECK_FOR_HEADER, NO_BINARY_CHECK, PREFIX_SOURCETYPE, および sourcetype プロパティは使⽤します。
Splunk Web インターフェイスが無効になっています
($SPLUNK_HOME/etc/apps/SplunkLightForwarder/default/web.conf)。
スループットが 256Kbps ($SPLUNK_HOME/etc/apps/SplunkLightForwarder/default/limits.conf) に制限されていま
す。
$SPLUNK_HOME/etc/apps/SplunkLightForwarder/default/default-mode.conf 内の以下のモジュールが無効になってい
ます。
[pipeline:indexerPipe]
disabled_processors= indexandforward, diskusage, signing,tcp-output-generic-processor, syslog-output-genericprocessor, http-output-generic-processor, stream-output-processor
[pipeline:distributedDeployment]
disabled = true
[pipeline:distributedSearch]
disabled = true
[pipeline:fifo]
disabled = true
[pipeline:merging]
disabled = true
[pipeline:typing]
disabled = true
[pipeline:udp]
disabled = true
70
[pipeline:tcp]
disabled = true
[pipeline:syslogfifo]
disabled = true
[pipeline:syslogudp]
disabled = true
[pipeline:parsing]
disabled_processors=utf8, linebreaker, header, sendOut
[pipeline:scheduler]
disabled_processors = LiveSplunks
これらのモジュールには、デプロイサーバー (デプロイクライアントではない)、分散サーチ、名前付きパイ
プ/FIFO、ネットワークポートからの直接⼊⼒、およびスケジューラーが含まれています。
ライトフォワーダーのデフォルト値をニーズに合わせて調整するに
は、$SPLUNK_HOME/etc/apps/SplunkLightForwarder/default/default-mode.conf の設定に優先する設定を⾏います。
古いインデックスの消去
インデクサーをライトフォワーダーに変換する場合、インデックス作成機能を無効にします。また、そのインスタ
ンスで以前にインデックスが作成されたデータにはアクセスできなくなります。ただし、データは引き続き存在し
ています。
そのようなデータをシステムから消去する場合は、いったん SplunkLightForwarder App を無効にしてから、
CLI コマンドの clean を実⾏します。そして App を再度有効にする必要があります。clean コマンドの詳細は、
『インデクサーとインデクサー・クラスタの管理』マニュアルの「Splunk からのインデックスとデータの削除」
を参照してください。
転送のトラブルシューティング
フォワーダー/レシーバー接続のトラブルシューティング
レシーバーが受信ポートで新しい接続を受け付けない
受信インデクサーの内部キューがブロックされた場合、指定された期間データをキューに挿⼊できない状態が続い
た後、受信/待機ポート (splunktcp) がシャットダウンされます。キューにデータを挿⼊できる状態に回復したら、
ポートが再度開かれます。
ただし、キューのブロック解除後にポートを再度開けないこともあります (Windows マシンのみ)。この場合は、
インデクサーを再起動する必要があります。
この問題が発⽣した場合、レシーバーの inputs.conf にある stopAcceptorAfterQBlock 属性の値を増やして、ポート
の閉鎖条件を緩和することができます。この属性は、インデクサーがポートを閉じるまでに待機する時間を⽰して
います。デフォルトは 300 秒 (5 分) です。
ロードバランシングを利⽤したフォワーダーを使⽤している場合、outputs.conf の writeTimeout 属性に設定されて
いるタイムアウト間隔に基づいて、ロードバランシンググループ内の他のインデクサーに、データの転送が切り替
えられます。そのため、受信インデクサーのキューがブロックされた場合は、⾃動的にフェイルオーバーが⾏われ
ます。
71