データの転送 - Splunk Docs

S plu nk ® E nt er pr is e 6 . 4 . 0
データの転送
作成⽇時：2016/03/22 7:12 pm
Copyright (c) 2016 Splunk Inc. All Rights Reserved
T abl e o f C o nt e nt s
転送の紹介
転送と受信について
フォワーダーのタイプ
3
3
3
デプロイのプランニング
フォワーダーのデプロイトポロジー
フォワーダーとインデクサー間の互換性
5
6
9
ヘビーフォワーダーとライトフォワーダーのデプロイ
Splunk Enterprise インスタンスでの転送機能の有効化
ヘビーフォワーダーとライトフォワーダーの機能
レシーバーを有効にする
ヘビーフォワーダーのデプロイ
ライトフォワーダーのデプロイ
10
10
10
11
12
14
フォワーダーの設定
inputs.conf を使ったフォワーダーのデータ収集の設定
outputs.conf によるフォワーダーの設定
15
15
15
フォワーダーのアップグレード
ヘビーフォワーダーとライトフォワーダーのアップグレード
19
19
詳細設定
ロードバランシングの設定
SOCKS プロキシを使うためのフォワーダー設定
中継フォワーダーの設定
転送データ損失の保護
データのルーティングとフィルタリング
サードパーティ製システムへのデータの転送
19
19
22
24
25
27
36
転送のトラブルシューティング
フォワーダー/レシーバー接続のトラブルシューティング
39
39
転送の紹介
転送と受信について
ある Splunk Enterprise インスタンスから別の Splunk Enterprise インスタンスや Splunk 以外のシステムに、
データを転送することができます。転送を実⾏する Splunk Enterprise インスタンスは、フォワーダーと呼ばれ
ています。
数種類のフォワーダーが⽤意されています。それぞれについて知るにはフォワーダーのタイプを参照してくださ
い。
1 つまたは複数のフォワーダーからデータを受信する Splunk Enterprise インスタンスは、レシーバーと呼ばれ
ています。しばしば、レシーバーは、Splunk Enterprise インデクサーですが、他のフォワーダーもレシーバー
になることができます。
転送レイアウトのサンプル
以下の図は、3 台のフォワーダーが単⼀のレシーバー (インデクサー) にデータを送信し、受け取ったデータを
サーチに利⽤できるように、インデクサーがインデックスを作成する概要を表しています。
フォワーダーは以下の機能により、ネットワークから raw データを供給するよりも、⼤幅に堅牢なソリューショ
ンを実現しています。
メタデータのタグ設定 (ソース、ソースタイプ、ホスト)
設定可能なバッファー
データ圧縮
SSL セキュリティ
利⽤可能な任意のネットワークポートの使⽤
転送および受信権限によりあらゆる種類の Splunk Enterprise トポロジーが可能になります。データ統合、ロー
ドバランシング、およびデータのルーティングなどの機能を取り扱う環境を構築できます。
転送と受信についての参照先
Splunk Enterprise 分散デプロイの基本については、『分散デプロイ』マニュアルを参照してください。
フォワーダーを使って作成できるデプロイトポロジーの種類については、このマニュアルの「フォワーダー
のデプロイトポロジー」を参照してください。
中継転送についての詳細は、このマニュアルの「中継転送」を参照してください。
利⽤可能なフォワーダーの種類については、「フォワーダーのタイプ」を参照してください。
ユニバーサルフォワーダーについての詳細は、『ユニバーサルフォワーダー』マニュアルを参照してくださ
い。
フォワーダーのタイプ
3
3 種類のフォワーダーが⽤意されています。
ユニバーサルフォワーダーは、スリム化された専⽤版の Splunk Enterprise で、データの転送に必要な基
本コンポーネントのみが含まれています。ユニバーサルフォワーダーについての詳細は、『ユニバーサル
フォワーダー』マニュアルを参照してください。
ヘビーフォワーダーは完全版の Splunk Enterprise インスタンスで、データをインデックス、サーチ、変
更、転送できます。ヘビーフォワーダーには、システムリソース利⽤を低減するために、無効になっている
機能があります。
ライトフォワーダーも完全版の Splunk Enterprise インスタンスですが、⼤幅な軽量化を実現するため
に、より多くの機能が無効になっています。ライトフォワーダーは Splunk Enterprise 6.0 をもって廃⽌と
されました。ユニバーサルフォワーダーはほぼすべての⽬的に対してライトフォワーダーに代わるもので、
データをインデクサーに送信するにあたっては最良のツールです。
ユニバーサルフォワーダー
ユニバーサルフォワーダーはデータを転送するためだけに使⽤されます。完全版の Splunk Enterprise インスタ
ンスと違い、ユニバーサルフォワーダーを使ってインデックスの作成やサーチの実⾏を⾏うことはできません。⾼
いパフォーマンスと⼩型軽量化を実現するために、ユニバーサルフォワーダーにはいくつかの制限があります。
ユニバーサルフォワーダーはサーチ、インデックス、さらにデータでのアラート⽣成をできません。
ユニバーサルフォワーダーは、データのパーシングを⾏いません。そのコンテンツに基づいてデータを別の
Splunk Enterprise インデクサーにルーティングすることはできません。
完全版の Splunk Enterprise と違い、ユニバーサルフォワーダーには Python のバンドル版は含まれていま
せん。
ユニバーサルフォワーダーはさまざまな⼊⼒からデータを取得し、それを Splunk Enterprise サーバーに転送し
てインデックス作成とサーチを⾏うことができます。また、インデクサーに直接データを送信する代わりに、中継
地点として他のフォワーダーにデータを転送することもできます。
ユニバーサルフォワーダーは、個別にダウンロードできるソフトウェアです。ヘビーフォワーダーやライトフォ
ワーダーと違い、完全版の Splunk Enterprise インスタンスから有効にすることはできません。ユニバーサル
フォワーダーについての詳細は、『ユニバーサルフォワーダー』マニュアルを参照してください。
ユニバーサルフォワーダーのダウンロード、インストール、およびデプロイ⽅法については、『ユニバーサルフォ
ワーダー』マニュアルの「ユニバーサルフォワーダーソフトウェアのインストール」を参照してください。
ヘビーフォワーダーとライトフォワーダー
データの転送にはユニバーサルフォワーダーを利⽤することをお勧めしますが、データを転送する前に分析または
変更する必要がある場合、あるいは内容に基づいてデータの転送先を管理する必要がある場合は、ヘビーフォワー
ダーやライトフォワーダーを使⽤します。ユニバーサルフォワーダーとは違い、ヘビー/ライトフォワーダーは完
全版の Splunk Enterprise インスタンスから、特定の機能を無効にしたものです。ヘビーフォワーダーとライト
フォワーダーは、機能とリソースの占有サイズが異なります。
ヘビーフォワーダー (「通常のフォワーダー」と呼ばれることもあります) は、インデクサーと⽐べて占有サイズ
は⼩さいですが、分散サーチ機能を利⽤できないことを除き、ほぼすべての機能を保持しています。占有サイズを
減らすために、Splunk Web などのデフォルト機能のいくつかを、必要に応じて無効にすることができます。ヘ
ビーフォワーダーは、データの転送前にパーシングを⾏うため、イベントのソースやタイプなどの基準に基づい
て、データをルーティングすることができます。
ヘビーフォワーダーの主な利点として、データのインデックスをローカルに作成しながら、他の Splunk
Enterprise インスタンスにデータを転送できる点が挙げられます。この機能をアクティブにする必要がありま
す。詳細は、このマニュアルの「outputs.conf によるフォワーダーの設定」を参照してください。
ライトフォワーダーは、占有サイズがより⼩さく、利⽤できる機能も⼤幅に限定されています。これは、パーシ
ングされていないデータのみを転送します。⾮常に類似した機能を提供するユニバーサルフォワーダーが代替しま
す。ライトフォワーダーは廃⽌されましたが、主に古いシステムのニーズを満たすことを⽬的に提供されていま
す。
ユニバーサルフォワーダーをインストールする場合、同じホストに常駐している任意のライトフォワーダー (バー
ジョン 4.0 以降) から、チェックポイント設定を移⾏することができます。ユニバーサルフォワーダーとライト
フォワーダーの詳細な⽐較については、『ユニバーサルフォワーダー』マニュアルの「ユニバーサルフォワーダー
について」を参照してください。
ヘビーフォワーダーとライトフォワーダーの権限の詳細は、本マニュアルの「ヘビーフォワーダーとライトフォ
ワーダーの権限」を参照してください。
フォワーダーの⽐較
3 種類のフォワーダーの類似性と差異の概要を以下の表に⽰します。
機能と特徴
ユニバーサルフォワー
ダー
ライトフォワーダー
ヘビーフォワーダー
Splunk Enterprise イン
スタンスのタイプ
専⽤の実⾏形式ファイル
完全版の Splunk
Enterprise で⼤半の機能
が無効化
完全版の Splunk
Enterprise で⼀部の機能
が無効化
占有サイズ (メモリー、
CPU 負荷)
最⼩
⼩
中〜⼤ (有効化した機能に
よる)
Python がバンドルされて
いるか？
いいえ
はい
はい
4
データ⼊⼒の取り扱いは？すべてのタイプ (ただし、
スクリプト⼊⼒の場合は
Python のインストールが
必要)
すべてのタイプ
すべてのタイプ
Splunk Enterprise に転
送する
はい
はい
はい
サードパーティ製システムはい
に転送する
はい
はい
中継フォワーダーとして利はい
⽤する
はい
はい
インデクサー応答確認 (配
信が保証されている)が必
要
オプション (バージョン
4.2 以降)
オプション (バージョン
4.2 以降)
ロードバランシングを⾏うはい
はい
はい
データを複製する
はい
はい
イベント単位のフィルタリいいえ
ングを⾏う
いいえ
はい
イベントのルーティングをいいえ
⾏う
いいえ
はい
イベントのパーシングを⾏時々
う
いいえ
はい
ローカルにインデックスをいいえ
作成する
いいえ
オプショ
ン、indexAndForward で
outputs.conf 属性を設定
サーチ/アラート機能を使
⽤する
いいえ
いいえ
オプション
Splunk Web を利⽤する
いいえ
いいえ
オプション
オプション
はい
特定の機能の詳細は、このトピックの残りの部分やこのマニュアルの他のトピックを参照してください。
フォワーダーデータのタイプ
フォワーダーは 3 種類のデータを転送することができます。
raw データ
未パーシングデータ
パーシング済みデータ
フォワーダーが送信できるデータのタイプは、フォワーダーのタイプおよびその設定によって異なります。ユニ
バーサルフォワーダーとライトフォワーダーは、raw データまたは未パーシングデータを送信できます。ヘビー
フォワーダーは、raw データまたはパーシング済みデータを送信できます。
raw データの場合、フォワーダーは⼿を加えていないデータを TCP ストリームとして送信します。データは
Splunk 通信形式には変換されません。フォワーダーはデータを収集し、それを送信します。これは、⾮ Splunk
システムにデータを送信する場合に特に役⽴ちます。
⾮パーシングデータ：ユニバーサルフォワーダーは最低限の処理を⾏います。データストリームを調査すること
はありませんが、ソース、ソースタイプ、およびホストを識別するために、ストリームにメタデータでタグを設定
します。また、データストリームを 64 キロバイトのブロックに分割し、イベントに認識可能なタイムスタンプが
ない場合に、データを受信したインデクサーが使⽤できる、基本的なタイムスタンプ設定を⾏います。ユニバーサ
ルフォワーダーは、構造データ (カンマ区切り値ファイルなど) でファイルのパーシングを⾏うように設定してい
る場合を除いて、個別のイベントの識別、調査、またはタグ設定を⾏うことはありません。
パーシング済みデータ：ヘビーフォワーダーはデータを個別のイベントに分割し、タグを設定して Splunk
Enterprise インデクサーに転送します。イベントの調査を⾏うことも可能です。データはパーシングされている
ため、フォワーダーはフィールド値などのイベントデータに基づいて、条件による振り分け (ルーティング) を⾏
うことができます。
パーシング済みおよび⾮パーシング形式のデータは、処理済みデータと呼ばれ、raw データと区別されます。デ
フォルトで、フォワーダーは処理済みデータを送信します (ユニバーサルフォワーダーは⾮パーシングデータ、ヘ
ビーフォワーダーはパーシング済みデータを送信します)。代わりに raw データを送信する場合は、outputs.conf
に sendCookedData=false 属性/値のペアを設定します。
フォワーダーとインデックス
フォワーダーは、インデックス単位でデータを転送、ルーティングします。デフォルトでは、すべての外部データ
および _audit 内部インデックスのデータを転送します。また、_internal 内部インデックスのデータを転送するこ
ともあります。必要に応じてこの動作を変更することができます。詳細は、「ターゲットインデックスによるデー
タのフィルタリング」を参照してください。
デプロイのプランニング
5
フォワーダーのデプロイトポロジー
フォワーダーのデプロイには、さまざまなシナリオを利⽤することができます。ここでは、フォワーダーで作成で
きる、有⽤なトポロジーについて説明していきます。各種デプロイトポロジーの設定⽅法の詳細は、「フォワー
ダーを使ったデプロイトポロジーの作成」を参照してください。
データの統合
データの統合は、複数のフォワーダーが単⼀の Splunk Enterprise インスタンスにデータを送信する、もっとも
⼀般的なトポロジーの 1 つです。⼀般的にこのシナリオでは、ユニバーサルフォワーダーがワークステーション
や実働環境のサーバーから⾮パーシングデータを、統合とインデックス作成の⽬的で集中処理を⾏う Splunk
Enterprise インスタンスに転送します。ヘビーフォワーダーを利⽤して、Splunk Enterprise インデクサーに
パーシング済みデータを送信することもできます。
ここでは、3 台のユニバーサルフォワーダーが単⼀のインデクサーにデータを送信しています。
データの統合の詳細は、「複数のマシンからのデータの統合」を参照してください。
ロードバランシング
ロードバランシングにより、⼤量のデータ処理、サーチパフォーマンスの向上のための⽔平スケーリング、障害
対策などの問題に対処するための、複数のインデクサーにまたがったデータの分散処理を簡素化できます。ロード
バランシングでは、フォワーダーがそれぞれのインデクサーに、指定された間隔で順番にデータをルーティングし
ます。
フォワーダーは、設定された間隔でレシーバーを切り替える、⾃動ロードバランシングを実⾏します。パーシング
が有効になっている場合 (ヘビーフォワーダーの場合)、切り替えはイベント境界で⾏われます。
この図では、3 台のユニバーサルフォワーダーが、2 台のインデクサー間のロードバランシングを⾏っています。
6
ロードバランシングの詳細は、「ロードバランシングの設定」を参照してください。
ルーティングとフィルタリング
データのルーティングで、フォワーダーはソースやソースタイプなどの基準またはイベントのパターンに基づい
て、イベントを特定の Splunk Enterprise またはサードパーティ製ホストにルーティングします。イベントレベ
ルでルーティングを⾏うには、ヘビーフォワーダーが必要です。
またフォワーダーは、イベントをフィルタリングして特定のキューにルーティングしたり、NULL キューにルー
ティングすることでイベントを破棄したりすることができます。
ここでヘビーフォワーダーはイベントのパターンに基づいて、データを 3 台のインデクサーにルーティングして
います。
7
ルーティングとフィルタリングの詳細は、このマニュアルの「データのルーティングとフィルタリング」を参照し
てください。
フォワーダーとインデクサークラスタ
フォワーダーを使って、インデクサークラスタ内のピアノードにデータを送信することができます。Splunk のベ
ストプラクティスでは、この⽬的にはロードバランシングを⾏うフォワーダーを使⽤することをお勧めします。
2 台のロードバランシングを⾏うフォワーダーが、クラスタにデータを送信している図を以下に⽰します。
フォワーダーとインデクサークラスタの詳細は、『インデクサーとインデクサーのクラスタの管理』マニュアル
の「フォワーダーを使ったデータの取り込み」を参照してください。インデクサークラスタの全般的な情報につい
8
の「フォワーダーを使ったデータの取り込み」を参照してください。インデクサークラスタの全般的な情報につい
ては、「インデクサークラスタとインデックスレプリケーションについて」を参照してください。
⾮ Splunk システムへの転送
ヘビーフォワーダーでは、raw データを syslog 収集システムなどの、サードパーティ製システムに送信すること
ができます。この機能とデータのルーティングを組み合わせて、あるデータを⾮ Splunk システムに、他のデータ
を 1 つまたは複数の Splunk Enterprise インスタンスに送信することができます。
3 台のフォワーダーが、2 台の Splunk Enterprise インスタンスと 1 台の⾮ Splunk システムにデータを転送す
る例を図に⽰します。
⾮ Splunk システムへの転送の詳細は、「サードパーティ製システムへのデータの転送」を参照してください。
転送の中継
⼀部の⾼度な使⽤事例に対応するために、⼀連のフォワーダーグループとインデクサーの間に中継フォワーダーを
設置することもあります。このシナリオでは、データの最初の送信元となるフォワーダー群が、中継フォワーダー
にデータを送信し、中継フォワーダーがデータをインデクサーに送信します。中継フォワーダーがデータのイン
デックス作成をする場合もあります。
たとえばデータを「保管して転送する」必要がある、またはローカル版のサーチを有効にする⽬的で、中間イン
デックスを作成する必要があるような状況で使⽤されます。(この場合、ヘビーフォワーダーを使⽤する必要があ
ります)また、セキュリティ上の理由などで、インデクサーへのアクセスを制限する必要がある場合にも、中継
フォワーダーを使⽤できます。
中継転送を有効にするには、「中継フォワーダーの設定」を参照してください。
フォワーダーとインデクサー間の互換性
フォワーダーとそのデータを受信するインデクサー間の、特定のバージョンに関する互換性の制限を以下に⽰しま
す。Splunk ベストプラクティスとして、インデクサーの Splunk Enterprise のバージョンは、データをそのイン
デクサーに送信するフォワーダーの Splunk Enterprise のバージョン以上にしておくことをお勧めします。
フォワーダーとインデクサーの互換性
バージョン 6.0 以降のフォワーダーは Splunk Enterprise のバージョン 5.0 以降のインデクサーにデータを
送信できます。
Splunk Enterprise のバージョンが 6.0 以降のインデクサーは、バージョン 4.3 以降のフォワーダーから
データを受信できます。
以下の 6.x の機能は、インデクサーとフォワーダーの両⽅のバージョンが 6.x 以上の場合にのみ利⽤できます。
ダイナミックファイルヘッダー
構造化データの転送
フォワーダーによるタイムゾーン伝送。さらにフォワーダーは、層がライトフォワーダーまたはユニバーサ
ルフォワーダーによってのみ構成されている場合、タイムゾーン転送機能を中継転送層にわたって維持しま
9
せん。
ヘビーフォワーダーとライトフォワーダーのデプ
ロイ
S pl u nk E nt er pr ise インスタンスでの転送機能の有効化
ヘビーフォワーダーとライトフォワーダーを完全版の Splunk Enterprise インスタンスで設定できます。
ユニバーサルフォワーダーを設定するには、『ユニバーサルフォワーダー』マニュアルの以下のいずれかのトピッ
クを参照してください。
Splunk Light へのデータ転送⽅法
Splunk Cloud へのデータ転送⽅法
Splunk Enterprise へのデータ転送⽅法
転送と受信の設定：ヘビー/ライトフォワーダー
1. フォワーダーおよびレシーバーとして動作するホストを割り当てます。
2. Splunk Enterprise を上記ホストすべてにインストールします。
3. 各レシーバーで、Splunk Web または CLI を使⽤して受信を有効にします。
4. 各フォワーダーで、Splunk Web または CLI を使⽤して転送を有効にします。「ヘビーフォワーダーのデプロ
イ」または「ライトフォワーダーのデプロイ」を参照してください。
5. 各フォワーダーで、Splunk Web または CLI を使⽤、または
inputs.conf
を編集してデータ⼊⼒を指定します。
6. 各フォワーダーで、Splunk Web または CLI を使⽤、または
信先を指定します。
outputs.conf
を編集してフォワーダーのデータ送
7. レシーバーで、データをサーチし転送が期待どおりに実⾏されたことを確認します。
8. レシーバーにデータがない場合は、トラブルシューティングを実⾏します。そうでない場合は、⼿順は完了で
す。
ヘビーフォワーダーとライトフォワーダーの機能
このトピックでは、ヘビーフォワーダーとライトフォワーダーに付随する機能、さらにデフォルトで無効になって
いる機能について説明します。
ヘビーフォワーダーの詳細
ヘビーフォワーダーはデフォルトで、すべての 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 を使⽤せず、受信データを完全にはパーシングしませんが、CHARSET, CHECK_FOR_HEADER,
NO_BINARY_CHECK, PREFIX_SOURCETYPE, からの sourcetype および props.conf プロパティは使⽤します。
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 内の以下のモジュールが無効になってい
ます。
10
[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
[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 の設定に優先する設定を⾏います。
古いインデックスの消去
インデクサーをライトフォワーダーに変換する場合、インデックス作成機能を無効にします。さらに、そのインス
タンスで以前にインデックスが作成されたデータへのアクセスを失います。ただし、データは引き続き存在してい
ます。
そのようなデータをシステムから消去する場合は、いったん Splunk ライトフォワーダー App を無効にしてか
ら、CLI コマンドの clean を実⾏します。そして App を再度有効にする必要があります。clean コマンドの詳細は
『インデクサーとインデクサークラスタの管理』マニュアルの「Splunk からのインデックスとデータの削除」を
参照してください。
構造化データの転送に関する検討事項
構造化データ (INDEXED_EXTRACTIONS 機能を使⽤するソースタイプを有するデータ) を転送する場合、インデクサーで
はなくフォワーダーに対してパーシング、抽出、変更のフィルタリングを⾏う必要があります。『データの取り込
み』マニュアルの「ヘッダーファイルから抽出したデータの転送」を参照してください。
レシーバーを有効にする
転送と受信を有効にするには、レシーバーとフォワーダーの両⽅を設定します。レシーバーは、データを受信す
る Splunk Enterprise インスタンスです。フォワーダーがレシーバーにデータを送信します。
転送ニーズに応じて、各フォワーダーに対して複数のレシーバーを⽤意することもあります。逆に、単⼀のレシー
バーが複数のフォワーダーからデータを受信することもあります。
レシーバーは、Splunk Enterprise インデクサー (⼀般的な事例) または他のフォワーダー (中継フォワーダー) で
す。
Splunk ベストプラクティスはまずレシーバーを設定して、次にデータをレシーバーに送信するためにフォワー
ダーを設定します。
受信の設定
11
Splunk Enterprise インスタンス (インデクサーまたはフォワーダー) をレシーバーとして有効にする前に、まず
インスタンスをインストールする必要があります。次に Splunk Web、CLI、または inputs.conf 設定ファイルを
使って、インスタンスでの受信を有効にします。
Splunk W eb を使った受信の設定
Splunk Web を使ってレシーバーを設定します。
1. レシーバーとして割り当てた Splunk Enterprise ホストで、Splunk Web に管理者 (admin) としてログインし
ます。
2. [ 設定] > [ 転送と受信] をクリックします。
3. [ 新規追加] をクリックします。
4. レシーバーを待機させる TCP ポート (待機ポートまたは受信ポート ) を指定します。
たとえば、「9997」と⼊⼒すると、レシーバーはポート 9997 のフォワーダーからの接続を待機します。使⽤し
ないポートを指定できます。netstat などのツールを使えば、システムで利⽤できるポートを確認することができ
ます。splunkweb や splunkd が選択したポートを使⽤していないことを確認してください。
5. [ 保存] をクリックします。Splunk Enterprise は指定したポートで到着データを待機しはじめます。
Splunk CLI を使った受信の設定
1. シェルまたはコマンドプロンプトから、
$SPLUNK_HOME/bin
ディレクトリに変更します。
cd $SPLUNK_HOME/bin
2. CLI コマンドを実⾏して受信を有効化します。
splunk enable listen <port> -auth <username>:<password>
には、レシーバーを待機させるポート (受信ポート) を指定します。たとえば、「9997」と⼊⼒すると、レ
シーバーはポート 9997 でデータを受信します。使⽤しないポートを指定できます。netstat などのツールを使え
ば、システムで利⽤できるポートを確認することができます。splunkweb や splunkd が選択したポートを使⽤し
ていないことを確認してください。
<port>
コマンドは、[splunktcp] 内に、inputs.conf スタンザを作成します。たとえば、ポート 9997
を指定した場合、スタンザ [splunktcp://9997] が作成されます。
splunk enable listen
設定ファイルを使った受信ポートの設定
$SPLUNK_HOME/etc/system/local
内の
inputs.conf
を編集して、Splunk Enterprise インスタンスの受信を有効にする
ことができます。
1. テキストエディタで
$SPLUNK_HOME/etc/system/local
の
inputs.conf
を開きます。
注意：ファイルが存在しない場合は、作成する必要があります。
2. 受信ポートを指定する
[splunktcp]
スタンザを追加します。以下の例で受信ポートは 9997 を使⽤しています。
[splunktcp://9997]
disabled = 0
注意： [splunktcp://9997] と
⽤してください。
[splunktcp://:9997]
(1 つまたは 2 つのコロン) は、意味的に同⼀です。どちらかを使
ヘビーフォワーダーのデプロイ
ヘビーフォワーダーを完全版の Splunk Enterprise インスタンスで有効にできます。
転送と受信を有効にするには、レシーバーとフォワーダーの両⽅を設定する必要があります。レシーバーは、
データを受信する Splunk Enterprise インスタンスです。フォワーダーはレシーバーにデータを送信します。
Splunk ベストプラクティスは「レシーバーを有効にする」の説明に従って、まずレシーバーを設定することで
す。次に、レシーバーにデータを送信するフォワーダーを設定します。
ヘビーフォワーダーの設定プロセスは、2 つのステップから成り⽴っています。
1. 完全版 Splunk インスタンスをインストールします。
2. インスタンスの転送機能を有効にします。
12
転送の設定
Splunk Web または CLI を使って、Splunk Enterprise インスタンスの転送を有効にすることができます。
また、Splunk Enterprise インスタンス上の outputs.conf ファイルを作成して、転送の有効化や設定を⾏うことも
可能です。outputs.conf によるフォワーダーの設定にはさまざまな事項を理解する必要がありますが、単⼀の場所
からすべてのフォワーダーを設定することには、利点があります。⾼度な設定オプションの⼤半は、outputs.conf
でのみ利⽤することができます。また、複数のフォワーダーを有効化し設定する場合、単⼀の outputs.conf ファイ
ルを編集して、そのコピーを各フォワーダーに配布することで⼿軽に作業を⾏えます。詳細は、「outputs.conf
によるフォワーダーの設定」を参照してください。
Splunk W eb によるヘビーフォワーダーの設定
1. データを転送するインスタンス上で、Splunk Web に管理者 (admin) としてログインします。
2. [ 設定] > [ 転送と受信] をクリックします。
3. [ 新規追加] をクリックします。
4. 受信 Splunk Enterprise インスタンスのホスト名または IP アドレス、およびレシーバー設定時に指定した受信
ポートを⼊⼒します。例えば、receivingserver.com:9997.を⼊⼒して、ロードバランシングを導⼊するために、複
数のホストをカンマ区切りリストで指定することができます。
5. [ 保存] をクリックします。
ヘビーフォワーダーを設定してインデックスとデータの転送を⾏います。
ヘビーフォワーダーは、ライトフォワーダーやユニバーサルフォワーダーと⽐べて、データのインデックスをロー
カルに作成できます。また、他のインデックスにもデータを転送できます。ただし、デフォルトではローカルのイ
ンデックス作成はオフになっています。フォワーダー上でデータを保管する場合、上記の説明に従って、または
outputs.conf を編集して、この機能を有効にする必要があります。
1. データを転送するインスタンス上で、Splunk Web に管理者 (admin) としてログインします。
2. [ 設定] > [ 転送と受信] をクリックします。
3. [ 転送のデフォルト] を選択します。
4. フォワーダー上にインデックスデータのローカルコピーを保持するには、[ はい] を選択します。
その他のすべての設定は、outputs.conf. で⾏う必要があります。
CLI によるヘビーフォワーダーの設定
CLI による転送の設定は、2 つのステップから成り⽴っています。
Splunk Enterprise インスタンスの転送機能を有効にします。
次に、特定のレシーバーへの転送を設定します。
1. コマンドまたはシェルプロンプトで、$SPLUNK_HOME/bin/ に移動します。
2. 以下を⼊⼒して転送を有効にします。
splunk enable app SplunkForwarder -auth <username>:<password>
3. Splunk Enterprise を再起動します。
CLI からの転送の開始
以下の⼿順によりデータを指定した受信インデクサーに送信します。データをレシーバーに送信する前に、
1. シェルまたはコマンドプロンプトから、$SPLUNK_HOME/bin ディレクトリに移動します。
2. 転送活動を開始するには、splunk
add forward-server
コマンドでレシーバーを指定します。
splunk add forward-server <host>:<port> -auth <username>:<password>
3. いずれかのコマンドを実⾏した後は、フォワーダーを再起動してください。
CLI からの転送活動の停⽌
転送活動を終了するには、以下のコマンドを⼊⼒します。
splunk remove forward-server <host>:<port> -auth <username>:<password>
CLI からの転送の無効化
13
転送活動を終了しても、インスタンスは引き続きフォワーダーとして設定されています。フォワーダーを完全版の
Splunk Enterprise インスタンスに戻すには、前述のように disable コマンドを使⽤します。
1. コマンドまたはシェルプロンプトから、$SPLUNK_HOME/bin ディレクトリに移動します。
2. 以下を⼊⼒して転送を無効にします。
splunk disable app SplunkForwarder -auth <username>:<password>
このコマンドで転送を無効にすることで、フォワーダーは完全版の Splunk Enterprise インスタンスに戻りま
す。
ライトフォワーダーのデプロイ
重要：ライトフォワーダーは Splunk Enterprise 6.0 をもって廃⽌とし、⾮推奨となっています。⾮推奨で廃⽌
の機能の⼀覧は、リリースノートの「⾮推奨 (廃⽌予定) の機能」を参照してください。
ライトフォワーダーを完全版の Splunk Enterprise インスタンスにインストールできます。ライトフォワーダー
の推奨代替であるユニバーサルフォワーダーのインストール⽅法については、『ユニバーサルフォワーダー』マ
ニュアルの「ユニバーサルフォワーダーソフトウェアのインストール」を参照してください。
転送と受信を有効にするには、レシーバーとフォワーダーの両⽅を設定します。レシーバーはデータを受信し、
フォワーダーはデータをレシーバーに転送します。
Splunk ベストプラクティスはまずレシーバーを設定することです。次に、レシーバーにデータを送信するフォ
ワーダーを設定します。
ライトフォワーダーの設定プロセスは、2 つのステップから成り⽴っています。
1. 完全版 Splunk インスタンスをインストールします。
2. インスタンスの転送機能を有効にします。
注意：ライトフォワーダーとして使⽤する Splunk Enterprise インスタンスをインストールする場合、フォワー
ダーライセンスを選択します。詳細は、「Splunk ライセンスの種類」を参照してください。
転送の設定
CLI を使って、転送を有効にすることができます。
また、Splunk Enterprise インスタンス上の outputs.conf ファイルを作成して、転送の有効化や設定を⾏うことも
可能です。outputs.conf によるフォワーダーの設定にはさまざまな事項を理解する必要がありますが、単⼀の場所
からすべてのフォワーダーを設定することには、明⽩な利点があります。⾼度な設定オプションの⼤半
は、outputs.conf でのみ利⽤することができます。また、複数のフォワーダーを有効化、設定する場合、単⼀の
outputs.conf ファイルを編集して、そのコピーを各フォワーダーに配布することで⼿軽に作業を⾏えます。詳細
は、「outputs.conf によるフォワーダーの設定」を参照してください。
CLI によるライトフォワーダーの設定
CLI によるフォワーダーの設定は、2 つのステップから成り⽴っています。まず、インスタンスの転送機能を有効
にします。次に、特定のレシーバーへの転送を開始します。
1. シェルまたはコマンドプロンプトから、$SPLUNK_HOME/bin/ ディレクトリに移動します。
2. ライトフォワーダーモードを有効にするには、以下のように⼊⼒します。
splunk enable app SplunkLightForwarder -auth <username>:<password>
ライトフォワーダーモードを無効にするには、以下のように⼊⼒します。
splunk disable app SplunkLightForwarder -auth <username>:<password>
このコマンドで転送を無効にすることで、フォワーダーは完全版の Splunk Enterprise インスタンスに戻りま
す。
3. いずれかのコマンドを実⾏した後は、フォワーダーを再起動してください。
CLI からの転送の開始
1. シェルまたはコマンドプロンプトから、$SPLUNK_HOME/bin/ ディレクトリに移動します。
2. 転送活動を開始するには、splunk
add forward-server
コマンドでレシーバーを指定します。
splunk add forward-server <host>:<port> -auth <username>:<password>
14
転送活動を終了するには、以下のコマンドを⼊⼒します。
splunk remove forward-server <host>:<port> -auth <username>:<password>
注意：このコマンドは転送活動を終了しますが、インスタンスは引き続きフォワーダーとして設定されていま
す。インスタンスを完全版の Splunk Enterprise インスタンスに戻すには、前述のように disable コマンドを使⽤
します。
3. いずれかのコマンドを実⾏した後は、フォワーダーを再起動してください。
フォワーダーの設定
inpu t s.conf を使ったフォワーダーのデータ収集の設定
inputs.conf
設定ファイルを編集することでフォワーダーへのデータ⼊⼒を設定できます。
ほとんどの場合、inputs.conf を編集します。ファイルは $SPLUNK_HOME/etc/system/local ディレクトリにあります。
App をインストール済みで、⼊⼒設定を変更したい場合について
は、$SPLUNK_HOME/etc/apps/<appname>/local/inputs.conf を編集してください。例えば、Splunk Add-on for Unix
and Linux をインストール済みであれば、$SPLUNK_HOME/etc/apps/Splunk_TA_nix/local/inputs.conf 内で編集を⾏えま
す。
内の inputs.conf に変更は加えないでください。アップグレード時には、インス
トールによってファイルが上書きされ、⾏った変更はすべて削除されてしまいます。
$SPLUNK_HOME/etc/system/default
フォワーダーが収集できるデータについての情報は「Splunk Enterprise がインデックス処理できる項⽬」を参照
してください。
設定ファイルを変更したら、変更内容を反映するためにフォワーダーを必ず再起動する必要があります。
i nputs .c o nf の編集
1. ご利⽤のオペレーティングシステムのファイル管理ツール、シェル、またはコマンドプロンプトを使⽤し
て、$SPLUNK_HOME/etc/system/local に移動します。
2. inputs.conf を開き編集します。ファイルが存在しない場合は、作成する必要があります。
3. データ⼊⼒を追加します。
4. ⼊⼒を追加し終えたら、ファイルを保存して閉じます。
5. フォワーダーを再起動します。
6. 受信インデクサーでログインし、サーチとレポート App を読み込みます。
7. サーチを実⾏し、データ⼊⼒を設定したフォワーダーからの結果が表⽰されることを確認します。
host=<forwarder host name or ip address> source=<data source> earliest=1h
結果が確認できない場合、トラブルシューティングぺージで解決⽅法を確認してください。
ou t pu t s.conf によるフォワーダーの設定
outputs.conf ファイルは、フォワーダーのレシーバーへのデータの転送⽅法を定義しています。
⼀部の出⼒設定は Splunk Web (ヘビー/ライトフォワーダーのみ) や CLI を使って⾏えます。ただし、⾼度な設
定の⼤半は、outputs.conf を編集する必要があります。このトピックでは、ロードバランシングやデータのルー
ティングなどのさまざまなトポロジーについて説明し、それらのトポロジーを実現するための outputs.conf の設定
に関する詳細な例を取り上げています。
はフォワーダー設定時に重要なファイルですが、フォワーダーのデータ送信先のみに対処します。
フォワーダーが収集するデータを指定するには、別途⼊⼒を設定する必要があります。⼊⼒の設定⽅法の詳細は、
『データの取り込み』マニュアルの「データの追加と⼊⼒の設定」を参照してください。
outputs.conf
o utputs .c o nf ファイルの種類
単⼀のフォワーダーに複数の outputs.conf ファイルを保有することができます (たとえば、App ディレクトリに 1
つ、そして /system/local ディレクトリに別のファイルを保管する)。フォワーダーに存在する outputs.conf ファイ
ル数や保管場所に関係なく、すべてのファイルの設定が組み合わされて使⽤されます。詳細は、『管理マニュア
ル』の「設定ファイルの優先度」を参照してください。
デフォルト版
Splunk Enterprise には単⼀のデフォルト outputs.conf ファイルが同梱されてお
り、$SPLUNK_HOME/etc/system/default にあります。
15
ユニバーサルフォルダには 2 種類のデフォルト outputs.conf ファイルがあります。『ユニバーサルフォワー
ダー』マニュアルの「outputs.conf によるフォワーダーの設定」を参照してください。
「設定ファイルについて」で説明している理由から、デフォルト版の設定ファイルは編集しないでください。
カスタム版
転送を設定する場合、変更内容はカスタム版の
な⽅法を利⽤できます。
outputs.conf
に保存されます。転送動作を設定するには、さまざま
フォワーダーのインストール時 (Windows ユニバーサルフォワーダーのみ)
CLI コマンドを実⾏
Splunk Web を使⽤ (ヘビー/ライトフォワーダーのみ)
outputs.conf ファイルを直接編集
最初の 3 つの⽅法の場合、⾃動的にカスタム版の outputs.conf が作成または編集されます。これらのバージョンの
保管場所は、フォワーダーの種類やその他の要因によって異なります。
Splunk Web または CLI を使ってヘビー/ライトフォワーダーを有効にする場合、インスタンスで動作している
App のディレクトリ内に outputs.conf ファイルが作成されます。たとえば、サーチ App で作業を⾏っている場合
は、Splunk Enterprise は $SPLUNK_HOME/etc/apps/search/local/ にファイルを作成します。そこからファイルを編集
することができます。
ファイルを間接的に (たとえば、CLI を使⽤して) 作成または編集するだけでなく、outputs.conf ファ
イルを直接作成または編集することもできます。Splunk ベストプラクティスとしてはファイルの単⼀のコピーを
$SPLUNK_HOME/etc/system/local/ に保管して、作業を⾏うことをお勧めします。(CLI を使った設定の変更などの理由
により、このディレクトリにすでにファイルのコピーが存在している場合は、そのコピーを編集します)。配布と
管理を簡素化するために、すべての⾮デフォルト版ファイルからの設定を組み合わせて、単⼀のカスタム
outputs.conf ファイルにまとめることができます。
outputs.conf
outputs.conf
を変更したら、変更内容を反映するためにフォワーダーを再起動する必要があります。
outputs.conf
の詳細は、outputs.conf spec ファイルを参照してください。
設定レベル
2 種類の出⼒プロセッサ
す。
tcpout
と
syslog
が存在しています。これらは、3 種類のレベルのスタンザに設定できま
グローバル： (オプション) グローバルレベルでは、全体的に適⽤する属性を指定します。また、システム全
体のレベルにしか設定できない⼀部の属性もここに指定します。
対象グループ：対象グループは、1 つまたは複数の受信インデクサーを定義します。出⼒プロセッサごとに
複数の対象グループを指定することができます。⼤部分の設定は、対象グループレベルに指定できます。
単⼀サーバー： (オプション) 対象グループ内の単⼀のホスト (レシーバー) に対して設定値を指定すること
ができます。。
より狭義のレベルの設定が優先されます。たとえば、対象グループに対して compressed=true を指定した場合、グ
ローバルレベルで compressed に「false」が設定されている場合でも、フォワーダーは対象グループ内のホストに
圧縮データを送信します。
注意：この説明は、[tcpout] ヘッダーを使⽤する tcpout プロセッサに焦点を合わせています。syslog 出⼒プロ
セッサについては、「サードパーティ製システムへのデータの転送」を参照してください。
グローバルスタンザ
ここには、全体的に適⽤する属性を設定します。このスタンザは省略することができます。ただし、defaultGroup
や indexAndForward など、グローバルレベルでのみ設定できる属性もあります。
tcpout
プロセッサ⽤のグローバルスタンザは、[tcpout] ヘッダーで指定します。
グローバル tcpout スタンザの例を以下に⽰します。
[tcpout]
defaultGroup=indexer1
indexAndForward=true
このグローバルスタンザには、2 つの属性/値のペアが含まれています。
default Gro up=indexer1：フォワーダーに、すべてのデータを対象グループ「indexer1」に送信するこ
とを指⽰しています。詳細は、「デフォルトの対象グループ」を参照してください。
indexAndF o rward=t rue ：フォワーダーに、データのインデックスをローカルに作成し、対象グループ
内の受信インデクサーにデータを転送することを指⽰しています。「false」 (デフォルト) を設定すると、
フォワーダーはデータを転送し、インデックスを作成することはありません。この属性はヘビーフォワー
ダーでのみ利⽤できます。ユニバーサルフォワーダーとライトフォワーダーは、データのインデックスを作
成することはできません。
デフォルトの対象グループ
16
⾃動転送⽤のデフォルトグループを設定するには、[tcpout] スタンザにグローバルレベルで
定します。
defaultGroup
属性を設
[tcpout]
defaultGroup= <target_group1>, <target_group2>, ...
defaultGroup には、後ほど tcpout:<target_group> スタンザに定義する、1 つまたは複数の対象グループを指定し
ます。フォワーダーは、指定されたグループにすべてのイベントを送信します。
データを⾃動的に転送したくない場合は、defaultGroup 属性を設定しないでください。
defaultGroup
属性の使⽤例については、「データのルーティングとフィルタリング」を参照してください。
対象グループスタンザ
対象グループは、⼀連のレシーバーを⽰しています。また、フォワーダーがそれらのレシーバーにどのようにデー
タを送信するのかも⽰しています。対象グループは複数定義することができます。
対象グループスタンザの基本的なパターンを以下に⽰します。
[tcpout:<target_group>]
server=<receiving_server1>, <receiving_server2>, ...
<attribute1> = <val1>
<attribute2> = <val2>
...
対象グループ内に受信ホストを指定するには、<hostname_or_ip_address>:<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]
⼀般的なデプロイトポロジーの定義
このセクションでは、⼀般的な各種デプロイトポロジーを利⽤するための、フォワーダーの設定⽅法について説明
していきます。
ロードバランシング
17
ロードバランシングを利⽤するには、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
[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 ループス
タンザ
必須。フォワーダーのレシーバーとして動作するサーバーを指定し
ます。<hostname_or_ip_address>:<port> の形式で指定する必要があり
ます (<port> は受信ポート)。
disabled
任意のス
false タンザレ
スタンザが無効かどうかを⽰します。「true」を設定した場合、ス
注意：この属性は、ヘビーフォワーダーでのみ利⽤できます。ユニ
バーサルフォワーダーは、ローカルにインデックスを作成できませ
ん。
18
disabled
false タンザレ
ベル
グローバ
ルまたは
対象グ
ループス
タンザ
タンザが存在しないのと同じ意味になります。
sendCookedData
true
compressed
グローバ
ルまたは
false 対象グ
ループス
タンザ
フォワーダーが圧縮データを送信するかどうかを⽰します。
ssl....
任意のス
N/A タンザレ
ベル
SSL 設定⽤の属性セット。これらの属性の使⽤⽅法は、Splunk
Enterprise のセキュリティの「フォワーダーからのデータの保護に
ついて」を参照してください。
useACK
グローバ
ルまたは
false 対象グ
ループス
タンザ
フォワーダーが、データがファイルシステムに書き込まれたことを
確認するための、インデクサー応答確認を待機するかどうかを⽰し
ます。「転送データ損失の保護」を参照してください。
dnsResolutionInterval 300
グローバ
ルまたは
対象グ
ループス
タンザ
フォワーダーが転送前にデータを処理するかどうかを指定します。
インデクサー DNS 名を IP アドレスに解決するベース間隔 (秒) を
指定します。このマニュアルの「DNS 解決の間隔」を参照してく
ださい。
ここの outputs.conf.spec ファイルの説明やさまざまな例で、これらのオプションや他の設定オプションの詳細が記
述されています。また、これらの設定の⼤部分は、特定の転送に関する事例を記述しているトピックでも取り上げ
られています。
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
フォワーダーのアップグレード
ヘビーフォワーダーとライトフォワーダーのアップグレード
ヘビーフォワーダーまたはライトフォワーダーをアップグレードするには、これらのフォワーダーをサポートする
Splunk Enterprise インスタンスをアップグレードします。アップグレード後に転送がきちんと動作し続けること
を確認する以外に、ヘビーフォワーダーまたはライトフォワーダーでアップグレードを⾏う際の所定または追加の
⼿順はありません。
インストールの⼿順とヒントは、『インストールマニュアル』の「Splunk Enterprise のアップグレード⽅法」を
参照してください。
詳細設定
ロードバランシングの設定
ロードバランシングを利⽤する場合、フォワーダーは複数の Splunk レシーバーにデータを分散します。各レ
シーバーは、データ全体の⼀部を受け取り、各レシーバーのデータをまとめたものが全データになります。転送さ
れたデータ全体にアクセスするには、すべてのレシーバーにまたがる分散サーチを設定します。分散サーチの詳細
は、『分散サーチ』マニュアルの「分散サーチについて」を参照してください。
19
ロードバランシングは、フォワーダーがデータを⼀度に複数のレシーバーに送信可能にすることにより、パフォー
マンスを改善します。また、その⾃動切り替え機能により、マシンが停⽌した場合の耐性も向上します。あるレ
シーバーが停⽌すると、フォワーダーは利⽤可能な他のレシーバーにデータの転送を開始します。
ロードバランシングは、ルーターなどのネットワーク機器からデータを受信する場合にも役⽴ちます。syslog お
よびポート 514 で⽣成された他のデータを処理するために、1 台のヘビーフォワーダーでポート 514 を監視し
て、その受信データを複数のインデクサーに分散することができます。
フォワーダーとレシーバーの間にロードバランシングを実装する際は、フォワーダーに搭載されている機能を使⽤
する必要があります。フォワーダーとレシーバー間にロードバランサーを使⽤すると正常に機能しなくなるため、
外部ロードバランサーを使⽤しないでください。
ロードバランシングの仕組み
フォワーダーは、設定可能な時間間隔に基づいて異なるインデクサーにデータを⾃動的にルーティングします。例
えば、インデクサー A、B、および C で構成されるロードバランシンググループがあるとします。フォワーダー
は指定された 30 秒などの⼀定の間隔で、データストリームを、グループ内の他のインデクサーに切り替えます。
インデクサーは無作為に選択されます。たとえばフォワーダーは、インデクサー B からインデクサー A に切り替
え、次にインデクサー C に切り替えます。あるインデクサーが停⽌すると、即座に別のインデクサーに切り替え
られます。
フォワーダーがモニターするように設定されている、各⼊⼒に対するデータストリームがある場合を考えてみま
しょう。フォワーダーは、データストリームを他のインデクサーに切り替えても安全かどうかを判断します。次
に、指定されている間隔で、新たに選択したインデクサーにデータストリームを切り替えます。新しいインデク
サーにデータストリームを安全に切り替えることができない場合は、安全に送信できるようになるまでの間、前の
インデクサーとの接続を維持してデータストリームの送信を継続します。
ユニバーサルフォワーダーには、ストリーム中のファイルの終わり (EOF) マーカーに⾏き会う、またはインデク
サーが故障しないかぎり、データの TCP ネットワークストリームのモニター時にインデクサーを切り替えできな
いという短所があります。この場合、ユニバーサルフォワーダーはリスト内の次のインデクサーに切り替えます。
ユニバーサルフォワーダーは、転送する前に (ヘビーフォワーダーと違い)、データのパーシングを⾏ってイベント
境界を識別しないため、EOF を受信しない限り、次のインデクサーに切り替えても安全かどうかを判断する⼿段
がありません。
3 台のフォワーダーが 2 台のインデクサーにデータをロードバランシングしている、⼀般的なシナリオを以下の図
に⽰します。
ロードバランシングのターゲット
⼀連のターゲットレシーバーを設定する場合、DNS または静的リストを使⽤することができます。
DNS リストは柔軟性に優れており、⼤規模なデプロイ環境などでは特に環境の拡張が容易になります。DNS を利
⽤すれば、各フォワーダーの outputs.conf をいちいち再編集することなく、⼀連のレシーバーを変更することがで
きます。
静的リストの主な利点は、各レシーバーに異なるポートを指定できることにあります。このことは、単⼀のホスト
上で動作する複数のレシーバー間でロードバランシングを⾏う必要がある場合に役⽴ちます。各レシーバーが、個
20
別のポートで待機することができます。
静的リストのターゲット
ターゲットの静的リストを使⽤するには、フォワーダーの 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 レ
コードを作成します。例：
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 秒で、この値を変更する必
21
要はほとんどありません。
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
S OCKS プロキシを使うためのフォワーダー設定
このトピックでは、プロキシサーバーを経由してインデクサーにデータを転送するために、Socket Secure バー
ジョン 5 (SOCKS5) をターゲットとしてフォワーダーを設定する⽅法を説明していきます。
デフォルトでは、Splunk Enterprise フォワーダーは任意の受信インデクサーと直接ネットワーク接続する必要が
あります。ファイアウォールがフォワーダーとインデクサー間の接続をブロックする場合、フォワーダーはインデ
クサーにデータを送信できません。
Splunk Enterprise のバージョン 6.3 からは、フォワーダーを設定することで、 SOCKS5 のプロキシホストを
使ってインデクサーにデータを送信することが可能です。フォワーダーの outputs.conf 設定ファイル内のスタンザ
に属性を指定することで、この設定を⾏えます。設定を完了して再起動したら、フォワーダーが SOCKS5 プロキ
シホストに接続されます。認証情報を⼊⼒すれば、必要に応じてサーバーに対して任意で認証を⾏うことができま
す。プロキシホストはインデクサーに接続を確⽴し、フォワーダーはプロキシ接続を介してデータを送信し始めま
す。
どんなタイプのSplunk Enterprise フォワーダーでも SOCKS5 プロキシホストを介してデータを送信可能です。
この SOCKS5 クライアントの実⾏は、Internet Engineering Task Force (IETF) の Request for Comments
(RFC) Memo #1928 に則って⾏われます。詳細については、IETF ウェブサイトの「Network Working Group:
Request for Comments: 1928」 (http://www.ietf.org/rfc/rfc1928.txt) を参照してください。
SOCKS5 プロキシ接続を設定するには、outputs.conf 内のスタンザを編集し、特定の属性を指定してプロキシを有
効化します。有効なプロキシ属性のリストは、「プロキシ設定値」を参照してください。Splunk Web ではプロ
キシサーバーは設定できません。
設定ファイルを⽤いた SO C K S5 プロキシ接続設定
1. $SPLUNK_HOME/etc/system/default/outputs.conf のコピーを作成し、$SPLUNK_HOME/etc/system/local/<code>
に格納します。
2. $SPLUNK_HOME/etc/system/local/outputs.conf を開き編集します。
3. 転送サーバーまたは outputs.conf 内の出⼒グループを定義します。定義するには、[tcpout] スタンザまたは
[tcpout-server] スタンザを作成します。「outputs.conf によるフォワーダーの設定」を参照してください。
4. SOCKS5プロキシを使う必要のある接続のスタンザに、プロキシ設定に合う SOCKS の属性を追加します。少
なくとも socksServer 属性を指定して、プロキシサポートを有効にする必要があります。
5. ファイルを保存して終了します。
6. フォワーダーを再起動します。
7. 受信インデクサー上で、サーチとレポート App を使⽤してインデクサーがデータを受信したことを確認しま
す。
プロキシ設定値
次の属性を使⽤して、フォワーダーに SOCKS5 を設定します。
属性
説明
22
デ
フォ
ルト
socksServer
データを転送するためにフォワーダーが接続するホスト名または IP アドレスのいずれか
と、SOCKS5 のプロキシポートをフォワーダーに伝えます。
N/A
または IP address:port のいずれかを指定することができます。ホスト名または
IP アドレスのいずれかと、ポートの両⽅を指定する必要があります。この属性を指定し
て、SOCKS5 のサポートを有効にする必要があります。
host:port
socksUsername
(任意) 接続フェーズでフォワーダーが認証を要求してきた場合は、このユーザー名を使⽤ N/A
して SOCKS5 プロキシホストへ認証を⾏うよう伝えます。
socksPassword
(任意) 接続フェーズで認証を要求する SOCKS5 プロキシホストに認証を⾏う際、このパ
スワードを使⽤するようフォワーダーに伝えます。
N/A
フォワーダーはスタンザに関連付けられている設定を読み込む時、このパスワードを暗
号化します。しかし、セキュリティに関してはいくつかの検討事項があります。「セ
キュリティの検討事項」を参照してください。
socksResolveDNS
(任意) SOCKS5 プロキシホストにインデクサーの名前を伝える前に、DNS を使⽤して出
⼒グループ内のインデクサーのホスト名を解決するかどうかをフォワーダーに伝えま
す。
false
この属性を true に設定すると、フォワーダーはインデクサーの名前を SOCKS5 プロキ
シホストにそのまま伝えます。そうすると、SOCKS5 プロキシホストは DNS を介して
インデクサーのホスト名を解決する必要があります。例えば、フォワーダーとプロキシ
サーバーが異なるネットワークで異なる DNS サーバーを使⽤している場合は true に設
定します。
に設定すると、フォワーダーは DNS を介してインデクサーホスト名を解決しよう
と試み、成功すると、インデクサーの解決された IP アドレスを SOCKS5 プロキシホス
トに送信します。
false
この属性は、[tcpout] または [tcpout-server] スタンザ内のインデクサーにホスト名を指
定した場合にのみ適⽤されます。IP アドレスを指定すると、DNS による解決は起こりま
せん。
SO C K S5 サポートの例
ここに、SOCKS5 プロキシサポートの有効な
outputs.conf
スタンザの例をいくつか挙げます。
この例は、ホスト側にあるインデクサーにデータを転送する SOCKS5 プロキシホストに接続を確⽴します。
[tcpout]
defaultGroup = proxy_indexers
[tcpout:proxy_indexers]
server = indexer1.slapstick.com:9997, indexer2.slapstick.com:9997
socksServer = prx.slapstick.com:1080
この例では、データを送ろうと試みる前に、認証情報を使ってプロキシホストに認証をかけて、データ送信時に接
続するインデクサーを決めるため、プロキシホストに DNS を解決するよう伝えています。
[tcpout]
defaultGroup = socksCredentials
[tcpout:socksCredentials]
server = indexer3.slapstick.com:9997
socksServer = prx.slapstick.com:1081
socksUsername = proxysrv
socksPassword = letmein
socksResolveDNS = true
セキュリティの検討事項
この機能を使⽤する時は、次の点に注意してください。
SOCKS5 プロキシは、フォワーダーとインデクサー内の間でのみ使⽤できます。その他の Splunk
Enterprise の機能や App、アドオンと SOCKS の連携はサポートされていません。
SOCKS5 プロトコルは平⽂で認証資格情報を送信します。この実⾏により、認証情報は中間者攻撃を受けや
すくなります。これは、攻撃者が SOCKS クライアントおよび SOCKS プロキシホスト間の通信に割り込
み、変更する可能性があるということを意味します。この注意事項は、Splunk Enterprise の機能ではな
く、SOCKS プロトコルに起因します。
安全性を最⼤限に⾼めるには、SOCKS 属性を、SOCKS プロキシホストによって保護されているネット
ワーク内のフォワーダーにのみ使⽤してください。フォワーダの SOCKS プロキシの使⽤を有効にしていて
も、保護されていない環境でフォワーダーをデプロイすると、サードパーティーによって SOCKS 認証情報
が傍受されてしまうことになります。
23
中継フォワーダーの設定
このトピックでは、中継フォワーダー層の設定⽅法について説明していきます。
中継転送を⾏うフォワーダーは、他の 1 つ以上のフォワーダーからデータを受け取り、他のインデクサーにデー
タを送信します。例えば、様々な地域に多くのホストがあり、インデクサーにデータを転送する前にこれらのフォ
ワーダーから地域の主要ホストにデータを送信したい場合、こうした設定は⾮常に有効です。あらゆる種類のフォ
ワーダーを中継フォワーダーとして使⽤できます。
ユニバーサルフォワーダーでの中継転送の設定⽅法については、『ユニバーサルフォワーダー』マニュアルにある
「中継フォワーダーの設定」を参照してください。
Splunk W eb による中継転送の設定
1. 中継転送に組み込むインスタンスの Splunk Enterprise にログインします。
2. システムバーで、[ 設定] > [ 転送と受信] を選択します。
3. [データ受信] で、[ 新規追加] をクリックします。[データ受信] > [新規追加] ページが読み込まれます。
4. [このポートで待機 ] フィールドに、インスタンスが⼊ってくるフォワーダー接続を待つポートの番号を⼊⼒し
ます。
5. [ 保存] をクリックします。Splunk Enterprise は指定されたポートで待機を開始し、[データ受信] ページを読
み込みます。
6. [データ受信] で、[ 転送と受信] をクリックします。Splunk Enterprise は再度 [転送と受信] ページを読み込み
ます。
7. [データ転送] の、[転送の設定] ラインで、[ 新規追加] をクリックします。[データ転送] > [新規追加] ページが
読み込まれます。
8. [ホスト] フィールドに、ホスト名または IP アドレス、さらに転送データを受信するインデクサーのポートを⼊
⼒します。
注意：同じポート番号をレシーバーで設定していない限り、このインスタンスで以前指定したポートを使⽤しな
いでください。
9. [ 保存] をクリックします。Splunk Enterprise は設定を保存し、指定されたホストやポートへの接続を試みま
す。
10. フォワーダーを再起動します。システムバーで、[ 設定] > [ サーバーコントロール] をクリックします。
11. [ Splunk の再起動] をクリックします。
追加ホストの⼿順を繰り返して中継フォワーダーの層を設定します。
設定ファイルによる中継転送の設定
1. 中継フォワーダーとして動作させたいホストでコマンドまたはシェルプロンプトを開きます。
2. 「inputs.conf によるフォワーダーのデータ収集の設定」の説明のとおりに、inputs.conf を編集してデータを受
信するフォワーダーを設定します。
3. 「outputs.conf によるフォワーダーの設定」の説明のとおりに、受信インデクサーにデータを送信するフォ
ワーダーを設定します。
4. (オプション) 中継フォワーダーの
inputs.conf
を編集してローカルデータ⼊⼒を設定します。
5. フォワーダーを再起動します。
これらの⼿順を繰り返し、層に更にフォワーダーを追加できます。
フォワーダーを設定し中継転送層を使⽤
中継転送層にデータを送信する追加のフォワーダーを設定するには
1. ユニバーサルフォワーダーをインストールしていなければ、インストールを⾏います。
2. 中継フォワーダーにデータを送信するフォワーダーを設定します。
3. (任意) フォワーダーのローカルデータ⼊⼒を設定します。
4. フォワーダーを再起動します。
設定をテストする
中継層が適切に作動していることを確認するために
1. 受信インデクサーで、Splunk Enterprise にサインインします。
24
2. サーチとレポート App を開きます。
3. 中継フォワーダーにデータを送信するよう設定したホストのひとつを参照するサーチを実⾏します。例：
host=<name or ip address of forwarder> index=_internal
イベントを確認できなければ、ホストが適切に設定されていません。考えられるソリューションについては、フォ
ワーダー/レシーバー接続のトラブルシューティングを参照してください。
転送データ損失の保護
インデクサーへのデータ転送時にデータ損失を防ぐために、インデクサー応答確認機能を使⽤することができ
ます。インデクサー応答確認を利⽤した場合、フォワーダーはインデクサーが「受信した」ことを確認できな
かったデータを再送信します。
インデクサー応答確認を有効にするにはフォワーダー上で
無効になっています。
outputs.conf
を設定します。この機能はデフォルトでは
注意：インデクサー応答確認を利⽤するには、フォワーダーとインデクサーの両⽅がバージョン 4.2 以降でなけ
ればなりません。そうでない場合は、応答確認することなくデータの伝送が⾏われます。
インデクサー応答確認とインデクサークラスタ
フォワーダーを使ってインデクサークラスタ内のピアノードにデータを送信する場合、通常はインデクサー応答確
認を有効にする必要があります。フォワーダーとクラスタの詳細は、『インデクサーとインデクサークラスタの管
理』マニュアルの「フォワーダーを使ったデータの取り込み」を参照してください。
正常動作時のインデクサー応答確認の動作
フォワーダーはインデクサーに継続的にデータを送信します (約 64 KB のブロックで)。フォワーダーは、インデ
クサーから応答確認を受信するまでの間、各ブロックのコピーをメモリー内の待機キューに保持します。待機中で
も、その他のブロックは引き続き送信されます。
すべてが順調な場合、インデクサーは：
1. データブロックを受信します。
2. データをパーシングします。
3. データをファイルシステムにイベントとして書き込みます (raw データとインデックスデータ)。
4. フォワーダーに応答確認を送信します。
応答確認は、インデクサーがデータを受信して、ファイルシステムに正常に書き込んだことをフォワーダーに知ら
せます。応答確認を受信すると、フォワーダーは当該ブロックをメモリーから解放します。
待機キューのサイズが⼗分にある場合は、応答確認を受信するまでにキューが⼀杯になることはありません。待機
キューのサイズを増やす⽅法を含めた、潜在的な問題と対処⽅法については、このセクションを参照してくださ
い。
問題がある場合のインデクサー応答確認の動作
⼀連の処理中に何らかの障害が発⽣した場合、フォワーダーは応答確認を受信しません。この場合、データブロッ
クの再送信を試みます。
応答確認がない理由
フォワーダーが応答確認を受け取らない理由の例を以下に⽰します。
データの受信後に、マシン障害などの理由でインデクサーが停⽌した。
ディスク満杯などの理由で、インデクサーがファイルシステムにデータを書き込むことができない。
応答確認のフォワーダーへの送信時に、ネットワークが停⽌した。
フォワーダーの障害への対処
データブロックの送信後、フォワーダーは応答確認を受信するまでの間、データのコピーを待機キューに保管しま
す。その後、他のブロックも通常通りに送信し続けます。あるブロックに対する応答確認を 300 秒 (デフォルト)
以内に受信しなかった場合、フォワーダーは接続を終了します。この待機時間を変更するには、readTimeout 内の
outputs.conf 属性を編集します。
フォワーダーに⾃動ロードバランシングが設定されている場合、グループ内の別のインデクサーに接続が⾏われ
(利⽤できる場合)、それにデータが送信されます。フォワーダーに⾃動ロードバランシングが設定されていない場
合は、同じインデクサーにデータを再送信するために、接続が試みられます。
フォワーダーは、応答確認を受信するまでの間、待機キュー内にデータブロックを保持します。待機キューが⼀杯
になると、そのいずれかのブロックの応答確認を受信して、キュー内にスペースを確保できるようになるまでの
間、他のブロックの送信は停⽌されます。
フォワーダーが接続を終了するその他の理由
25
フォワーダーがネットワーク接続を終了する可能性がある条件は 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
インデクサー応答確認を有効にする
インデクサー応答確認はフォワーダー上で設定します。useACK の
true
属性に
outputs.conf
を設定してください。
[tcpout:<target_group>]
server=<server1>, <server2>, ...
useACK=true
デフォルトで、useACK には
false
が設定されています。
注意： useACKはグローバルまたは対象グループ単位に設定できます。[tcpout] または [tcpout:<target_group>] スタ
ンザレベルで設定します。[tcpout-server: ...] スタンザで、個別のインデクサー単位に設定することはできませ
ん。
詳細は、outputs.conf spec ファイルを参照してください。
インデクサー応答確認と転送されたデータのスループット
フォワーダーは、待機キューを使ってインデクサー応答確認のプロセスを管理しています。このキューのデフォル
ト最⼤サイズは 21MB です。⼀般的にはこの値で⼗分に対処できます。ただしまれにですが、この待機キューの
サイズを⼿動で調整しなければならないこともあります。
待機キューの詳細については、このセクションを参照してください。待機キューサイズの設定⽅法について説明し
ています。また、待機キューの仕組みについても説明しています。
待機キューサイズの設定⽅法
待機キューのサイズは直接的には設定しません。代わりに、メモリー内出⼒キューのサイズを設定します。そうす
ると、待機キューのサイズが⾃動的に、出⼒キューサイズの 3 倍に設定されます。出⼒キューサイズを設定する
には、outputs.conf の maxQueueSize 属性を使⽤します。
属性のデフォルトは auto です。この設定をそのまま使⽤することをお勧めします。この設定では、イ
ンデクサー応答確認が有効かどうかに基づいて、キューのサイズを最適化します。
maxQueueSize
useACK=true
の場合、出⼒キューサイズは 7MB で、待機キューサイズは 21MB になります。
の場合、出⼒キューサイズは 500KB になります。
useACK=false
必要に応じて、maxQueueSize に特定の値を設定することができます。maxQueueSize の詳細は、outputs.conf を参照
してください。
推奨する
maxQueueSize=auto
の設定については、以下の事項に注意してください。
インデクサー応答確認を有効にした場合、キューサイズの増加はフォワーダーの再起動後にのみ反映されま
す。
26
設定は、バージョン 5.0.4 以降のフォワーダーでのみ利⽤できます。これより前のバージョンでインデ
クサー応答確認を使⽤している場合は、maxQueueSize 属性に 7MB を明⽰的に指定する必要があります。
auto
待機キューを考慮する理由
インデクサー応答確認を有効にする場合、フォワーダーは待機キューを使って応答確認のプロセスを管理します。
フォワーダーはデータブロックを継続的に送信し、応答確認を待たずに次のブロックを送信するため、⼀般的に待
機キューには応答確認待ちの多数のブロックが存在しています。フォワーダーは、待機キューが⼀杯になるまでブ
ロックを送信し続けます。⼀杯になった時点で、転送を停⽌します。その後フォワーダーは応答確認を受信して、
キューからブロックを解放できる状態になるまで待機し、解放できたら転送を再開します。
ネットワークやインデクサーに何か問題が発⽣した時に待機キューが⼀杯になる可能性がありますが、インデク
サーが正常に動作している場合でもキューが⼀杯になることがあります。これは、インデクサーはファイルシステ
ムにデータを書き込んだ後にのみ、応答確認を送信するためです。ファイルシステムへの書き込みが遅延すると、
応答確認も遅れるため、待機キューが⼀杯になる可能性が⾼くなります。
正常に動作しているインデクサーで、ファイルシステムへのデータ書き込みが遅延する (そして応答確認の送信も
遅延する) 理由は、いくつか考えられます。
インデクサーがビジー状態である。たとえば、データの受信時にインデクサーが複数のサーチリクエストを
処理している、または多数のフォワーダーからデータを受信している場合などが挙げられます。
インデクサーが受信しているデータ量が少なすぎる。効率性のため、インデクサーは書き込みキューが⼀杯
になった、または⼀定期間 (数秒間) 経過した場合にのみ、ファイルシステムにデータを書き込みます。書き
込みキューが⼀杯になるまで時間がかかっている場合、⼀定期間が経過するまでの間、インデクサーは書き
込みを待機します。データが数台のフォワーダーからしか転送されない場合、それらのフォワーダーが普段
通りのデータ量を転送しても、⼀定期間が経過するまでの間、データは書き込まれない可能性があります。
書き込みキューはホットバケツ単位で存在しているため、⼀部の特定のバケツのデータ受信量が少ない場合
にも、このような状況が発⽣します。通常このことは、特定のインデックスのデータ受信量が少ないことを
意味しています。
フォワーダーがインデクサーの応答確認待ちでスループットが低下することがないように、通常はデフォルト設定
の maxQueueSize=auto をそのまま使⽤してください。まれにですが、応答確認の到着待ちの間、フォワーダーのメモ
リー内にすべてのブロックを保持するための⼗分なスペースを確保するために、待機キューのサイズを増やさなけ
ればならないこともあります。また、単⼀のインデクサーに多数のフォワーダーがデータを送信しており、フォ
ワーダーあたりのデータソース数が普通程度の場合は、より⼩さなサイズを指定して数メガバイトのメモリーを節
約できることもあります。
レシーバーがインデクサーではなくフォワーダーの場合
中継フォワーダー経由でデータ伝送をする場合に (オリジナルのフォワーダーが中継フォワーダーにデータを送信
し、それがインデクサーにデータを転送する)、インデクサー応答確認を使⽤することもできます。このシナリオ
では、インデクサー応答確認を使⽤する場合、データ伝送経路のすべてのセグメントで有効にすることをお勧めし
ます。そうすることで、オリジナルのフォワーダーからインデクサーまで、パス全体でのデータ配信が保証されま
す。
オリジナルのフォワーダーが中継フォワーダーにデータを送信し、次にそれがインデクサーにデータを送信する場
合を考えてみましょう。この伝送ライン全体でインデクサー応答確認を有効にするには、2 回有効にする必要があ
ります。まず、データ転送元のフォワーダーと中継フォワーダー間の応答確認を有効にして、次に中継フォワー
ダーとインデクサー間の応答確認を有効にします。
両⽅の伝送経路で有効にすると、中継フォワーダーはインデクサーから応答確認を受信するまで待機し、次にオリ
ジナルのフォワーダーに応答確認を送信します。
ただし、どちらかのセグメントでのみ応答確認を有効にすると、その伝送経路でのみインデクサー応答確認が⾏わ
れます。たとえば、オリジナルのフォワーダーから中継フォワーダーへの経路でのみインデクサー応答確認が有効
になっており、中継フォワーダーからインデクサーへの経路では有効になっていない場合を考えてみましょう。こ
の場合、中継フォワーダーはインデクサーにデータを送信すると、即座にオリジナルのフォワーダーに応答確認を
送信します。インデクサーへの安全なデータ送信は、TCP に依存します。この 2 番⽬の経路ではインデクサー応
答確認が有効になっていないため、中継フォワーダーはインデクサーへのデータ配信を検証することはできませ
ん。このような事例はその価値が限定されているため、お勧めすることはできません。
データのルーティングとフィルタリング
このトピックは、Splunk Enterprise インスタンスへのイベントデータのフィルタリング/ルーティング⽅法につ
いて説明しています。⾮ Splunk システムへのルーティングについては、このマニュアルの「サードパーティ製シ
ステムへのデータの転送」を参照してください。
このトピックでは、⼀部のデータのインデックスをヘビーフォワーダー上でローカルに作成し、インデックスを作
成しないデータを 1 つまたは複数の個別のインデクサーに送信するような、選択的なインデックス作成と転送⽅
法も説明されています。詳細は、このトピックの後半にある「選択的インデックス作成と転送の実⾏」を参照して
ください。
フォワーダーのルーティングおよびフィルタリング権限
ヘビーフォワーダーは、ソース、ソースタイプ、またはイベント内のパターンに基づいて、特定のレシーバーに
データをフィルタリング/ルーティングすることができます。たとえば、フォワーダーはあるホストグループから
のすべてのデータを 1 台のインデクサーに送信し、2 番⽬のホストグループからのすべてのデータを別のインデク
サーに送信することができます。ヘビーフォワーダーはイベント内を調査して、フィルタリングやルーティングを
⾏うことも可能です。たとえば、ヘビーフォワーダーを使って、フィルタリングする WMI イベントコードを調査
したり、Windows イベントをルーティングしたりできます。このトピックは、⼀般的ないくつかのルーティング
シナリオを説明しています。
27
またフォワーダーは、レシーバーにルーティングするだけでなく、データをフィルタリングして特定のキューに
ルーティングしたり、NULL キューにルーティングすることでデータを破棄したりすることができます。
イベントレベルでデータのルーティング/フィルタリングを⾏えるのはヘビーフォワーダーのみです。ユニバーサ
ルフォワーダーとライトフォワーダーには、フィールドを構造化データファイルから抽出する場合を除いて、個別
のイベントを調査する機能はありません。ただし、ホスト、ソース、またはソースタイプに基づいてデータを転送
することは可能です。また、データの⼊⼒スタンザに基づいてルーティングを⾏うことも可能です。後述の「デー
タ⼊⼒に基づいた特定のインデクサーへのデータのルーティング」を参照してください。データの取得中に特定の
タイプのデータをフィルタリングする機能のある⼊⼒タイプもあります。
あるフォワーダーが 3 台のインデクサーにデータをルーティングする例を以下に⽰します。
ルーティングの設定
この⼿順はヘビーフォワーダーでしか実施できません。
1. 以下の質問に解答してルーティングに使⽤する基準を決定します。
イベントのカテゴリをどのように特定しますか？
イベントをどこにルーティングしますか？
2. ルーティングを⾏うインスタンスで、シェルまたはコマンドプロンプトを開きます。
3. props.conf を編集して、イベントのメタデータに基づいてルーティングを判断する、TRANSFORMS-routing
属性を追加します。
[<spec>]
TRANSFORMS-routing=<transforms_stanza_name>
この
props.con
<spec>
スタンザでは、
以下の値を使⽤できます
<sourcetype>、イベントのソースタイプ
host::<host>、<host>
はイベントのホストです
はイベントのソースです
複数の TRANSFORMS 属性がある場合、それぞれに⼀意の名前を使⽤します。例えば、"TRANSFORMSrouting1"、 "TRANSFORMS-routing2" 等です。
<transforms_stanza_name> は⼀意でなければなりません。
source::<source>、<source>
transforms.conf
(後述) 内にエントリを作成する場合は、ここに指定した
<transforms_stanza_name>
を使⽤します。
このトピックの後半にある例は、この構⽂の使⽤⽅法を表しています。
3. transforms.conf を編集して、イベントパターンに基づくルーティングの対象グループを指定、および追加の基
準を設定します。
28
[<transforms_stanza_name>]
REGEX=<routing_criteria>
DEST_KEY=_TCP_ROUTING
FORMAT=<target_group>,<target_group>,....
この
transforms.con
スタンザでは、
は、props.conf に定義されている名前と⼀致する必要があります。
には、ルーティングするイベントを決定する正規表現ルールを⼊⼒します。この⾏は必須
に指定したメタデータ以外のフィルタリングが不要な場合は、「REGEX = .」を使⽤してく
<transforms_stanza_name>
<routing_criteria>
です。props.conf
ださい。
DEST_KEYは、TCP 経由でイベントを送信する場合、_TCP_ROUTING を設定する必要があります。また、他の出⼒
プロセッサ⽤に、_SYSLOG_ROUTING または _HTTPOUT_ROUTING を設定することもできます。
FORMAT には、outputs.conf で定義した対象グループ名に⼀致する <target_group> を設定します。1 つ以上の対
象グループを指定する場合は、カンマを使⽤して区切ります。カンマ区切りリストは、複数の対象グループ
にイベントを複製します。
このトピックの後半にある例は、この構⽂の使⽤⽅法を表しています。
4. outputs.conf を編集して、ルーティングするデータの対象グループを定義します。
[tcpout:<target_group>]
server=<ip>:<port>
この
outputs.conf
スタンザでは、
に指定した名前と⼀致するように、<target_group> を設定します。
IP アドレスとポートを受信サーバーと⼀致するように設定します。
transforms.conf
このトピックに記載されている使⽤事例は、⼀般的に以下のパターンに従っています。
対象グループへのイベントデータのフィルタリングとルーティング
この例で、ヘビーフォワーダーは 3 種類のイベントをフィルタリングして、それを異なる対象グループにルー
ティングします。フォワーダーは、以下の基準に従って、フィルタリングとルーティングを⾏います。
ソースタイプが「syslog」のイベントを、ロードバランシングされた対象グループに
単語「error」を含むイベントを 2 番⽬の対象グループに
その他のイベントをデフォルトの対象グループに
1. ルーティングを⾏うインスタンスで、シェルまたはコマンドプロンプトを開きます。
2. $SPLUNK_HOME/etc/system/local 内の props.conf を編集して、syslog データ⽤とその他のすべてのデータ⽤の 2 つ
の TRANSFORMS-routing 属性を設定します。
[default]
TRANSFORMS-routing=errorRouting
[syslog]
TRANSFORMS-routing=syslogRouting
3. transforms.conf を編集して、各属性のルーティングルールを設定します。
[errorRouting]
REGEX=error
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) の
みが調査対象となります。
4. outputs.conf を編集して、対象グループを定義します。
[tcpout]
29
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
および errorGroup は、transforms.conf に指定されているルールに従って、イベントを受け取ります。そ
の他のすべてのイベントは、デフォルトのグループ everythingElseGroup にルーティングされます。
syslogGroup
データのサブセットのサードパーティ製システムへの複製
この例では、データのフィルタリングを⾏って、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
イベントデータのフィルタリングとキューへの送信
フォワーダーベースのルーティングと似ていますが、インデクサーやヘビーフォワーダーで、キューによるルー
ティングを⾏うことができます。outputs.conf ファイルは使⽤しません。props.conf と transforms.conf のみを使⽤
します。
不要なデータは、Splunk Enterprise における /dev/null デバイスと同等の、nullQueue にルーティングすることで
排除することができます。この⽅法でデータをフィルタリングして除外すると、Splunk Enterprise はそのデータ
をフィルターも転送もせず、インデックス容量にもカウントされません。
このトピック後半の「構造化データのルーティングとフィルタリングに関する注意事項」を参照してください。
特定のイベントを破棄して残りを保持する
この例は、sshd 内のすべての
/var/log/messages
イベントを、nullQueue に送信することで破棄します。
1. props.conf で、TRANSFORMS-null 属性を設定します。
30
[source::/var/log/messages]
TRANSFORMS-null= setnull
2. transforms.conf で、対応するスタンザを作成します。DEST_KEY に「queue」を、FORMAT に「nullQueue」を設定
します。
[setnull]
REGEX = \[sshd\]
DEST_KEY = queue
FORMAT = nullQueue
3. Splunk Enterprise を再起動します。
特定のイベントを保持して残りを破棄する
これは前のシナリオと反対です。この例では、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
3. Splunk Enterprise を再起動します。
W MI のフィルタリングとイベントログイベント
WinEventLog はフォワーダーレベルで直接フィルタリングできます。
WMI イベントをフィルタリングするには、props.conf 内で [WMI:WinEventLog:Security] ソースタイプのスタン
ザを使⽤します。以下の例は正規表現を使って、2 種類の Windows イベントコード 592 および 593 をフィルタ
リングしています。
1. props.conf を編集します。
[WinEventLog:Security]
TRANSFORMS-wmi=wminull
2. transforms.conf を編集します。
[wminull]
REGEX=(?m)^EventCode=(592|593)
DEST_KEY=queue
FORMAT=nullQueue
3. Splunk Enterprise を再起動します。
ターゲットインデックスによるデータのフィルタリング
フォワーダーは、データのターゲットインデックスに基づいてデータを転送するかどうかを指定す
る、fo rwardedindex フィルタを保有しています。たとえば、あるデータ⼊⼒に「index1」を宛先とするデータ
と「index2」を宛先とするデータが存在する場合、このフィルタを使って index1 宛のデータのみを転送して、
31
index2宛のデータを無視することができます。forwardedindex フィルタは、ホワイトリスト (whit elist s ) とブ
ラックリスト (blacklist s ) を使ってフィルタリングを指定します。複数インデックスの作成の詳細は、『インデ
クサーとインデクサーのクラスタの管理』マニュアルの「複数のインデックスの設定」を参照してください。
注意： 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)
⼤部分のデプロイ環境では、デフォルト設定を変更する必要はありません。インデックスのホワイトリストとブ
ラックリストの設定については、outputs.conf を参照してください。デフォルトおよびカスタムの outputs.conf
ファイルとその場所については、「outputs.conf ファイルの種類」を参照してください。
すべての外部および内部インデックスデータの転送
すべての外部データだけでなく、すべての内部インデックスデータも転送する場合は、デフォルトの
forwardedindex フィルタ属性に優先する設定を⾏います。
#Forward everything
[tcpout]
forwardedindex.0.whitelist = .*
# disable these
forwardedindex.1.blacklist =
forwardedindex.2.whitelist =
単⼀インデックス⽤データのみを転送する
単⼀のインデックス (たとえば、inputs.conf に指定) ⽤のデータのみを転送し、そのインデックス宛以外のすべて
のデータを破棄するには、以下のように outputs.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 ファイルから、すべてのフィルタを無効にします。次に独⾃のインデック
ス⽤のフィルタを設定します。forwardedindex.0 のように、フィルタの番号は 0 から始まることに注意してくださ
い。
注意：システムにある他の
あります。
outputs.conf
のコピーに別のフィルタを設定している場合、それらも無効にする必要が
32
CLI コマンド btools を使⽤して、システム内の他の
ことができます。
outputs.conf
ファイルにフィルタがないかどうかを確認する
splunk cmd btool outputs list tcpout
このコマンドは、すべての設定ファイルを結合した後の、tcpout スタンザのコンテンツを返します。
forwardedindex 属性の使⽤とローカルのインデックス作成
ヘビーフォワーダーでは、ローカルにインデックスを作成することができます。そのためには、indexAndForward 属
性を「true」に設定する必要があります。そうしないと、データは単純に転送され、フォワーダー上に保管される
ことはありません。⼀⽅ forwardedindex 属性は、転送するデータをフィルタリングするだけで、ローカルインデッ
クスに保存されるデータをフィルタリングすることはありません。
簡単に⾔うと、ローカルインデックスの作成とフォワーダーのフィルタリングは個別の操作で、相互に連携するこ
とはありません。これにより、ブラックリストのフィルタリングを実⾏する際に、予期しない結果が⽣じることが
あります。
を「true」に設定し、その後 forwardedindex ブラックリスト属性を使って⼀部のデータを
フィルタリングした場合、フォワーダーはブラックリストに⼀致するデータは転送しませんが、データのイ
ンデックスは作成します。
indexAndForward を「false」 (ローカルインデックスを作成しない) に設定し、⼀部のデータをフィルタリング
した場合、フォワーダーはフィルタリングされたデータ全体を破棄します (フィルタリングされたデータを
転送もインデックス作成もしないため)。
indexAndForward
データの⼊⼒に基づいた特定のインデクサーへのルーティング
このシナリオでは、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 からのデータを
server2
にルーティングします。
選択的インデックス作成と転送の実⾏
データのインデックスをローカルに作成、保管しながら、それを受信インデクサーに転送することができます。こ
のためには、2 種類の⽅法があります。
転送する前にすべてのデータのインデックスを作成する。このためには、indexAndForward の属性を
outputs.conf で有効にします。
⼀部のデータのインデックスを作成してから転送する、またはインデックスを作成しなかったデータ
を転送する。これは、選択的インデックス作成と呼ばれています。選択的インデックス作成では、⼀部の
データのみインデックスを作成し、それを受信インデクサーに転送することができます。または、ローカル
にインデックスを作成しなかったデータのみを転送することもできます。
選択的インデックスの有効化も予定している場合は、[tcpout] スタンザ内の
ください。
indexAndForward
属性を有効にしないで
選択的インデックス作成の設定
選択的インデックス作成を使⽤するには、inputs.conf と
outputs.conf
1. outputs.conf で：
a.
[indexAndForward]
スタンザを追加します。
33
ファイルの両⽅を変更します。
[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 で以下のスタンザを作成します。
[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 で以下のスタンザを作成します。
34
[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
前の例との唯⼀の違いは、ここでローカルにインデックスを作成する⼊⼒の _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
35
[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 Ent erprise はインデクサーに転送された構造化データをパーシングしません
構造化データをインデクサーに転送する時、インデクサーで props.conf を INDEXED_EXTRACTIONS および関連する属性
と設定している場合でも、Splunk Enterprise はこのデータがインデクサーに届いてもパーシングを⾏いません。
転送されたデータは、インデクサーにおける転送データの解析を妨げる、インデクサーの後続キューをスキップし
ます。
parsing
aggregation
typing
転送されたデータは、パーシング済みのインデクサーに届く必要があります。そのためには、データを送信する
フォワーダーの props.conf も設定する必要があります。これには INDEXED_EXTRACTIONSの設定や、パーシング、フィ
ルタリング、匿名化、ルーティングに関するあらゆるルールの設定が含まれます。ユニバーサルフォワーダーは構
造化データに対し、単独でこれらのタスクを実⾏することができます。「ヘッダーファイルから抽出したデータの
転送」を参照してください。
サードパーティ製システムへのデータの転送
Splunk Enterprise フォワーダーは、⾮ Splunk システムに raw データを転送することができます。データは
TCP ソケットまたは標準の syslog にパッケージ化して送信できます。⾮ Splunk システムに転送するため、raw
データのみを送信できます。
outputs.conf、props.conf、および transforms.conf,
を編集することで、ヘビーフォワーダーが他の Splunk インス
タンスに条件的にデータをルーティングするのと同様に、条件に応じてデータをサードパーティ製システムにルー
ティングするように設定することができます。データはホスト、ソース、またはソースタイプでフィルタリングで
きます。また、正規表現でデータを指定することもできます。
サードパーティーのシステムへのデータの転送は Splunk Enterprise が提供するサーチ結果エクスポート⽅法の
1 つです。利⽤可能な他のエクスポート⽅法については、『サーチ』マニュアルの「サーチ結果のエクスポート」
を参照してください。
TCP データ
ユニバーサルフォワーダーなど任意のタイプのフォワーダーを使って、TCP データをサードパーティシステムに
転送できます。
1. サードパーティ受信ホストが TCP ポートで到着データを待機するように設定します。
2. outputs.conf を編集して受信ホストおよびポートを指定します。
36
データをルーティングするには、データをパーシングできるヘビーフォワーダーを使⽤する必要があります。
3. props.conf を編集してルートするデータを決定します。
4. transforms.conf を編集して
props.conf
での設定に基づいてデータのルート先を決定します。
設定ファイルの編集
データを転送するには、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
transforms.confで、bigmoney
を設定して、TCP_ROUTING を
DEST_KEY
として、対象グループ
bigmoneyreader
を
FORMAT
と
して指定します。
[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
37
を設定します。
s y s lo g データ
ヘビーフォワーダーを使って、標準の syslog 形式でデータを送信することができます。フォワーダーは、個別の
出⼒プロセッサ経由でデータを送信します。ユニバーサルフォワーダーまたはライトフォワーダーでは、syslog
出⼒プロセッサは使⽤できません。
syslog 出⼒プロセッサは RFC 3164 に準拠したイベントを TCP/UDP ベースのサーバーおよびポートに送信し、
⾮準拠データのペイロードを RFC 3164 準拠にしています。これは Windows イベントログを含みます。
および transforms.conf を使ってデータをフィルタリングすることもできます。こうするには、
DEST_KEY として _SYSLOG_ROUTING を指定する必要があります。
props.conf
注意： Splunk Enterprise はイベントのコンテンツを、その⽂字コードがサードパーティサーバーに準拠するよ
うに変更しません。SEDCMD 設定を props.conf で指定して、サードパーティサーバーが処理できない⽂字を含むデー
タに対処します。データの取り込みの「sed スクリプトを使ったデータの匿名化」を参照してください。
syslog データをサードパーティサーバーに転送するには：
1. サードパーティの受信サーバーを特定します。
2. フォワーダーの
outputs.conf
ファイルにある
syslog
対象グループで受信サーバーを指定します。
[syslog]
defaultGroup=syslogGroup
[syslog:syslogGroup]
server = 10.1.1.197:514
syslog データに対して複数のイベントタイプを定義した場合、すべてのイベントタイプ名が⽂字列「syslog」を
含む必要があります。
syslog データの転送
outputs.conf
に、対象グループ
syslog
を指定します。
[syslog:<target_group>]
<attribute1> = <val1>
<attribute2> = <val2>
...
対象グループのスタンザには、以下の属性が必要です。
必要な属性
server
デフォル
ト
値
この形式は <hostname_or_ ipaddress>:<port> でなければなりません。これは、syslog
サーバーの IP アドレスまたはサーバー名と、syslog サーバーが待機するポートの
組み合わせです。デフォルトで syslog サーバーは、ポート 514 を使⽤します。
N/A
以下の属性は、必要に応じて指定します (省略可)。
オプション属性
デフォルト
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> でなければなりません。詳細は、『データ
の取り込み』マニュアルの「タイムスタンプの設定」を参照してください。
38
データのサブセットを 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で、send_to_syslog
を
FORMAT
を設定して、_SYSLOG_ROUTING を
DEST_KEY
として、対象グループ
my_syslog_group
として指定します。
[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
転送のトラブルシューティング
フォワーダー/ レシーバー接続のトラブルシューティング
転送が動作しない場合、または正常に動作しない場合は、以下のトラブルシューティングステップに従って理由を
判断します。
レシーバーが受信ポートで新しい接続を受け付けない
受信インデクサーの内部キューがブロックされた場合、指定された期間データをキューに挿⼊できない状態が続い
た後、受信/待機ポート (splunktcp) がシャットダウンされます。キューにデータを挿⼊できる状態に回復したら、
ポートが再度開かれます。
ただし、キューのブロック解除後にポートを再度開けないこともあります (Windows マシンのみ)。この場合は、
インデクサーを再起動する必要があります。
この問題が発⽣した場合、レシーバーの inputs.conf にある stopAcceptorAfterQBlock 属性の値を増やして、ポート
の閉鎖条件を緩和することができます。この属性は、インデクサーがポートを閉じるまでに待機する時間を⽰して
います。デフォルトは 300 秒 (5 分) です。
ロードバランシングを利⽤したフォワーダーを使⽤している場合、outputs.conf の writeTimeout 属性に設定され
ているタイムアウト間隔に基づいて、ロードバランシンググループ内の他のインデクサーに、データの転送が切り
替えられます。そのため、受信インデクサーのキューがブロックされた場合は、⾃動的にフェイルオーバーが⾏わ
れます。
受信ポートおよび管理ポートの混乱
フォワーダー設定の⼀環として、レシーバーの 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,
39
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 インス
タンスにデータを転送しようとしている、などの理由でデータフローから除外されます。
ソケットがブロックされている場合は、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>
[splunktcp]
から
inputs.conf
スタンザを削除して、受信を無効にすることもできます。
A ns w er s
何か質問がありますか？「Splunk Answers」では、Splunk コミュニティに寄せられた、転送の設定に関する質
問と回答をご覧いただけます。
40

Download Report