Splunk Enterprise インスタンスのアップデート

Splunk® Enterprise 6.4.0
Splunk Enterprise インスタンスの
アップデート
作成⽇時：2016/03/29 12:35 pm
Copyright (c) 2016 Splunk Inc. All Rights Reserved
Table of Contents
デプロイサーバーとフォワーダー管理
デプロイサーバーとフォワーダー管理について
デプロイサーバーのアーキテクチャ
更新のデプロイの仕組み
フォワーダー管理の概要
3
3
4
5
6
デプロイシステムの設定
デプロイのプランニング
デプロイクライアントの設定
デプロイ App の作成
サーバークラスの作成
フォワーダー管理を使ったサーバークラスの定義
クライアントフィルタの設定
7
7
9
11
12
14
17
App のデプロイ
クライアントへの App のデプロイ
App 更新からのコンテンツの除外
App デプロイステータスの表⽰
23
23
24
24
デプロイサーバーの管理
デプロイサーバーのパフォーマンスの⾒積もり
フォワーダー管理を使った App の管理
フォワーダー管理を使ったクライアントの管理
25
25
26
27
⾼度な設定
serverclass.conf を使ったサーバークラスの定義
互換性とフォワーダー管理
28
28
30
例
32
32
37
例：複数のフォワーダーへの設定のデプロイ
例：フォワーダーへの⼊⼒の追加
デプロイサーバーとフォワーダー管理
デプロイサーバーとフォワーダー管理について
重要：このマニュアルをお読みになる前に、『分散デプロイ』マニュアルを参照して、Splunk Enterprise 分散デプロイ
環境の基礎を学習してください。
Splunk Enterprise は Splunk Enterprise 分散インスタンスの更新⼿続きを管理するために、デプロイサーバーと
そのフォワーダー管理インターフェイスを提供しています。
デプロイサーバーとは
デプロイサーバーは、⼀連の Splunk Enterprise インスタンスグループの分散設定、App、およびコンテンツを更新
するためのツールです。これを使って、フォワーダー、⾮クラスタ構成インデクサー、サーチヘッドなど、⼤部分のタイ
プの Splunk Enterprise コンポーネントを更新/アップデートすることができます。
デプロイサーバーは、他の⼀連の Splunk Enterprise インスタンスの更新⼿続きを管理するように設定された、単純
な Splunk Enterprise インスタンスです。更新をデプロイするインスタンス数によっては、デプロイサーバーは更新
の管理作業に専念しなければならないこともあります。詳細は、「デプロイのプランニング」を参照してください。
デプロイサーバーは、既存の Splunk Enterprise の設定とコンテンツの更新を担当します。 Splunk
Enterprise やユニバーサルフォワーダーの初期インストールやアップグレードに使⽤することはできません。
Splunk Enterprise のインストールおよびデプロイ⽅法を学習するには、Splunk Enterprise では「インストール
⼿順」を、ユニバーサルフォワーダーでは「ユニバーサルフォワーダーのインストール」を参照してください。デプロイ
環境の新しいバージョンの Splunk Enterprise へのアップグレード⽅法については、『インストールマニュアル』内
の「分散 Splunk Enterprise デプロイ環境のアップグレード」を参照してください。
デプロイ·サーバーは必要？
フォワーダーや他の Splunk Enterprise インスタンスの管理に、デプロイ·サーバーは不要です。お好みに応じて、
Chef、Puppet、Salt、または何らかの Windows 設定ツールをご利⽤いただけます。
フォワーダー管理とは
フォワーダー管理は、デプロイサーバーに構築されているグラフィカルインターフェイスで、デプロイサーバーを⼿軽
に設定し、デプロイ環境の更新状況を監視する⼿段を提供しています。主⽬的は多数のフォワーダーグループを管理する
ことにありますが、フォワーダー管理を使って、⾮クラスタ構成のインデクサーやサーチヘッドへの更新の管理とデプロ
イ作業など、任意の更新⽬的によるデプロイサーバーの設定に使⽤することができます。たいていの場合、フォワーダー
管理とデプロイサーバーの機能は同じです。詳細は、「フォワーダー管理の概要」を参照してください。
重要： 6.0 以前のバージョンのデプロイサーバーからアップグレードする場合、既存の serverclass.conf ファイルがフォ
ワーダー管理インターフェイスと互換性がないことがあります。これは、フォワーダー管理は serverclass.conf を使って
可能な設定の⼀部のみしか処理できないためです。場合によっては、フォワーダー管理を設定ツールとして利⽤するので
はなく、引き続き serverclass.conf を使って直接設定しなければならないこともあります。フォワーダー管理と互換性が
ある設定の詳細およびデプロイサーバーのアップグレード⽅法については、「互換性とフォワーダー管理」を参照してくだ
さい。
デプロイサーバーが提供する機能
デプロイサーバーにより、共通の特徴で Splunk Enterprise コンポーネントをグループ化し、それらのグループに基
づいてコンテンツを配布することができます。
たとえば、組織内のさまざまな異なるニーズに応じてサービスを提供している Splunk Enterprise インスタンスがあ
る場合、使⽤するユーザーや使⽤⽬的によって、それらのインスタンスの設定内容は異なります。たとえば、⼀部のイン
スタンスはヘルプデスクチームにサービスを提供し、Windows デスクトップに関する問題のトラブルシューティングを
素早く実施するために、特定の App を設定します。また、別のグループのインスタンスは運⽤スタッフが使⽤し、ネッ
トワークに関する問題やセキュリティ上の問題の追跡、およびメールのトラフィック管理に使⽤する別の App を設定し
ています。3 番⽬のインスタンスグループは、運⽤チーム内の Web サービス担当者達にサービスを提供しています。
このような多彩な Splunk Enterprise インスタンスを⼀度にまとめて保守管理するのではなく、使⽤⽬的に基づいてグ
ループ化し、各グループが必要とする設定や App を判別して、次に必要に応じてデプロイサーバーを使ってそれらの
App や設定を更新します。
使⽤⽬的で Splunk Enterprise インスタンスをグループ化するだけでなく、他にも有益なグループ化⽅法があります。
たとえば、インスタンスを OS やハードウェアタイプ別、バージョン別、地域別、またはタイムゾーン別にグループ化す
ることができます。
主な使⽤事例としては、フォワーダーグループの設定を管理することが挙げられます。たとえば、さまざまな種類のマシ
3
ンでフォワーダーを動作させている場合、デプロイサーバーを使って、マシンの種類に応じて異なるコンテンツをデプロ
イすることができます。Windows フォワーダーにはある⼀連の設定を配布し、Linux フォワーダーには別の設定を配
布するなどのように作業を⾏います。
サーバーとクラスタのデプロイ
インデクサー·クラスタ·ピア·ノードまたはサーチヘッド·クラスタ·メンバーの更新に、デプロイ·サーバーを使⽤すること
はできません。
インデクサー·クラスタ
インデクサー·クラスタ内のピアノード (インデクサー) に対する設定の管理作業に、デプロイ·サーバーやフォワーダー管
理は絶対に使⽤しないでください。代わりに、設定バンドルを使⽤します。ただし、デプロイ·サーバーを使って更新を
マスター·ノードに配布して、次に設定バンドルを利⽤してマスター·ノードからピア·ノードにそれを配布することは可能
です。詳細は、『インデクサーとクラスタの管理』マニュアルの「共通のピア設定の更新」を参照してください。
サーチヘッド·クラスタ
サーチヘッド·クラスタ·メンバーの更新にデプロイ·サーバーは使⽤しないでください。
設定や App のクラスタ·メンバーへの配布⼿段として、デプロイ·サーバーはサポートされていません。⼀連のメンバーに
設定を配布するには、サーチヘッド·クラスタ·デプロイヤーを使⽤する必要があります。『分散サーチ』マニュアルの「デプ
ロイヤーを使った App と設定更新の配布」を参照してください。
デプロイサーバーのアーキテクチャ
デプロイサーバーは、サーバークラスでグループ化されたデプロイクライアントに、コンテンツや設定 (総称して「デ
プロイ App」) を配布するために⽤いられます。デプロイ App としては、Splunkbase で提供されているような本格的
な App を使⽤することも、単純な⼀連の設定を使⽤することも可能です。
アーキテクチャの主なエレメント
デプロイサーバーは、「デプロイクライアント」と呼ばれる他の任意の数のインスタンスの設定を管理する Splunk
Enterprise インスタンスです。データのインデックスをローカルに作成するインスタンスを含めて、任意の完全版
Splunk Enterprise インスタンスをデプロイサーバーとして使⽤できます。デプロイサーバーが⾃⼰のクライアントに
なることはできません。
デプロイクライアントは、デプロイサーバーによりリモート設定が⾏われる Splunk Enterprise インスタンスです。
ユニバーサルフォワーダー、ヘビーフォワーダー、インデクサー、またはサーチヘッドがデプロイクライアントになりま
す。各デプロイクライアントは、1 つまたは複数のサーバークラスに所属します。
デプロイ App は、デプロイサーバー上で管理される⼀連のコンテンツ (設定ファイルを含む) で、それらがまとめられ
た単位として特定のサーバークラスに対応するクライアントにデプロイされます。デプロイ App は単⼀の設定ファイル
であることも、複数のファイルから構成されていることもあります。時間の経過とともに、新しい内容で App が更新さ
れ、それが特定のクライアントに再度デプロイされます。デプロイ App には、既存の Splunk Enterprise App また
はデプロイ⽬的で特定のグループ向けに開発された App などが含まれることもあります。
注意：デプロイサーバーに関連して⽤いられている「App」は、⼀般的に Splunk Enterprise で使われている App と多
少意味が異なっています。⼀般的な Splunk Enterprise App についての情報は、『管理マニュアル』の「App とアドオン
とは」を参照してください。
サーバークラスは、定義されている 1 つまたは複数の特徴を共有するデプロイクライアントのグループです。たとえ
ば、すべての Windows クライアントをあるサーバークラスに、そしてすべての Linux クライアントを別のサーバーク
ラスにグループ化することができます。サーバークラスを使ってデプロイクライアントのグループを、1 つまたは複数の
デプロイ App と対応付けます。サーバークラスを作成することで、⼀連の App セットの形で設定の更新を受け取る、
⼀連のクライアントをデプロイサーバーに指⽰します。
相互関係
デプロイサーバーとデプロイクライアントおよびサーバークラスの概念的な概要を以下の図に⽰します。
4
この例で、各デプロイクライアントは、2 種類のサーバークラス (OS および地理的な場所) に所属する Splunk
Enterprise フォワーダーです。デプロイサーバーがサーバークラスのリストを管理しており、それらのサーバークラス
を使って各クライアントに配布するコンテンツを決定しています。クライアントへのコンテンツの配布を制御するため
に、このようなタイプの管理⼿段を導⼊する例については、「複数のフォワーダーへの設定のデプロイ」を参照してくださ
い。
デプロイ App の詳細は、「デプロイ App の作成」を参照してください。サーバークラスの詳細は、「サーバークラスにつ
いて」を参照してください。デプロイクライアントの詳細は、「デプロイクライアントの設定」を参照してください。
主な⽤語のまとめ
主要な⽤語の定義を以下に⽰します。
⽤語
意味
集中的に設定の管理を⾏う Splunk Enterprise インスタンス。設定の更新を他のインスタンスにデプロイ
デプロイ
します。また、デプロイサーバー、クライアント、および App で構成される、全体的な設定更新機構のこ
サーバー
とも表しています。
デプロイ
クライアリモート設定が⾏われる Splunk Enterprise インスタンス。デプロイサーバーから更新を受信します。
ント
サーバー⼀連のデプロイクライアントが共有する、デプロイ設定のカテゴリ。デプロイクライアントは複数のサー
クラス
バークラスに所属することができます。
デプロイ
1 つまたは複数のサーバークラスのメンバーにデプロイされる、まとめられたコンテンツの単位。
App
更新のデプロイの仕組み
更新のデプロイは以下のように⾏われています。
1.各デプロイクライアントは定期的にデプロイサーバーにポーリングを⾏います。
2.デプロイサーバーは、クライアントが所属するサーバークラスに基づいて、クライアント⽤のデプロイ App を判断し
ます。
3.デプロイ·サーバーは、クライアントに属している App のリストおよびそれらの App の現在のチェックサムを通知し
ます。
4.クライアントはデプロイサーバーからの App 情報を⾃⼰が保有している App 情報と⽐較し、ダウンロードする必要
5
がある新しい App や更新された App があるかどうかを判断します。
5.新しい App や更新された App がある場合、デプロイクライアントはそれらをダウンロードします。
6.特定の App の設定に応じて、App の変更を反映するためにクライアントは⾃⼰を再起動する場合があります。
フォワーダー管理の概要
フォワーダー管理インターフェイスは、デプロイクライアントとデプロイ App を対応付けるサーバークラスを作成
するための、対話型ビジュアルツールです。フォワーダー管理を使ってデプロイ環境を管理、監視することもできます。
このインターフェイスはサーバークラス設定を、デプロイサーバーの
serverclass.conf ファイルに保存します。
$SPLUNK_HOME/etc/system/local下にある、
インターフェイスの機能
フォワーダー管理の主⽬的は、サーバークラスの作成と編集にあります。その他の⽬的に使⽤することもできます。
システムのステータスを追跡する
デプロイアクティビティを監視する
App、クライアント、およびサーバークラスの関係を参照する
App 動作を設定する
クライアントから App をアンインストールする
フォワーダー管理インターフェイスへのアクセス
フォワーダー管理インターフェイスには、デプロイサーバー上の Splunk Web を介してアクセスします。インターフェ
イスを表⽰するには：
1.Splunk Web の上部にある [設定 ] リンクをクリックします。⼀連のシステムインターフェイスへのリンクが、ポッ
プアップウィンドウに表⽰されます。
2.[分散環境 ] セクションで、[フォワーダー管理] を選択します。インターフェイスのメインページが表⽰されます。
すでにいくつかの App、クライアント、およびサーバークラスを保有している、フォワーダー管理のホームページ例を以
下に⽰します。
このページには、以下のような要素が⽤意されています (上から下へ)。
リポジトリの場所：リポジトリの場所は、デプロイサーバー上でデプロイ App が存在している場所です。
ステータスセクション：デプロイクライアントと最近のダウンロードに関する情報が表⽰されます。
3 つのタブ：
App：このタブには、リポジトリにある⼀連のデプロイ App のリストとそのステータスが表⽰されます。
ここから、⼀部の App プロパティを編集することができます。
サーバークラス：このタブには、⼀連のサーバークラスとそのステータスが表⽰されます。ここでは、新し
いサーバークラスの作成や既存のサーバークラスの編集を⾏えます。また、既存のサーバークラスをドリル
ダウンして、関連する App やクライアントの情報を参照することもできます。新しい未設定のデプロイサー
バーの場合、このリストは空になります。
クライアント：このタブには、デプロイサーバーのすべてのクライアントとそのステータス情報が記載され
ています。このリストをさまざまな⽅法でフィルタリングして、表⽰する項⽬を絞り込むことができます。
このページの詳細は、「フォワーダー管理を使ったサーバークラスの定義」を参照してください。
インターフェイスの制限事項
フォワーダー管理インターフェイスは、さまざまなデプロイサーバーの使⽤事例に対応しています。ただし、複雑な設定
要件がある場合は、直接 serverclass.conf を編集しなければならないこともあります。
重要：フォワーダー管理から、直接 serverclass.conf を編集するように切り替えた場合、それ以降の設定にフォワーダー
管理を使⽤できない可能性があります。これは、フォワーダー管理インターフェイスは、serverclass.conf を使って可能
6
な設定の⼀部のみしか処理できないためです。
設定ファイルの直接編集と⽐較したインターフェイス利⽤の制限事項の例を以下に⽰します。
App のデプロイ動作は、サーバークラスにまたがって同じでなければなりません。たとえば、あるサーバークラス
経由で App をダウンロードした場合 App によるクライアントの再起動を指⽰できませんが、他のサーバークラス
経由でダウンロードした場合は可能なことがあります。
デプロイサーバー上で、デフォルトの repositoryLocation を変更することはできません。
ホワイトリストとブラックリストの動作に影響する filterType は、デフォルト値の whitelist でなければなりませ
ん。
クライアントフィルタは、サーバークラスレベルでのみサポートされています。
フォワーダー管理の制限事項、およびフォワーダー管理と
ダー管理」を参照してください。
serverclass.conf
間の互換性については、「互換性とフォワー
デプロイシステムの設定
デプロイのプランニング
デプロイサーバーを設定するには、デプロイサーバーとデプロイクライアントの両⽅を設定する必要があります。ただ
し、⼤部分の設定はデプロイサーバー側で⾏われます。実⾏する必要がある主な作業を以下に⽰します。
デプロイサーバーに接続するようにデプロイクライアントを設定する。
デプロイサーバー上にデプロイ App を保管するディレクトリを作成し、そこにコンテンツを保管する。
デプロイクライアントと App ディレクトリ間のマッピング (サーバークラス ) を作成する。
これらの作業を⾏う順序は、ある程度まで変更することができますが、推奨する⼿順は「基本⼿順」で取り上げられている
ものです。
クライアント、App ディレクトリ、およびマッピングを設定したら、App ディレクトリにコンテンツを保管することが
できます。任意の時点でデプロイサーバーに、App ディレクトリにある新しいコンテンツや更新されたコンテンツを、
マップ先のクライアントに配布するように指⽰できます。
重要：インデクサークラスタ内のピアノード (インデクサー) に対する更新の配布に、デプロイサーバーやフォワーダー
管理は絶対に使⽤しないでください。同様に、サーチヘッド·クラスタ·メンバーへの App や設定ファイルの配布にも、
デプロイ·サーバーは使⽤しないでください。「サーバーとクラスタのデプロイ」を参照してください。
デプロイサーバーシステム要件
デプロイサーバーマシン要件
App のダウンロード時には CPU 使⽤率およびメモリー消費量が⾼くなるため、デプロイサーバーインスタンスは専⽤の
マシン上で動作させることをお勧めします。
オペレーティング·システムの互換性
UNIX デプロイ·サーバーは、Windows および UNIX クライアントの両⽅を更新できます。ただし、Windows デプロ
イ·サーバーは、Windows クライアントに対してのみ使⽤する必要があります。
UNIX デプロイ·クライアントの更新には、UNIX デプロイ·サーバーを使⽤します。スクリプト⼊⼒、アラート、サーチ·
コマンドなどを利⽤している App は、Windows から UNIX にデプロイするとアクセス許可に関する問題が発⽣する
可能性があります。特に、UNIX クライアントへの配布時に、スクリプトや他のプログラムは実⾏形式に設定されませ
ん。
クライアントバージョンの互換性
6.x のデプロイ·サーバーは、5.0 以上が動作するデプロイ·クライアントと互換性があります。
デプロイサーバーおよびその他の役割
ほとんどのデプロイに関しては、インデクサーまたはサーチヘッドとして機能していない専⽤の Splunk Enterprise
インスタンスで、デプロイサーバーが動作する必要があります。例外は、デプロイサーバーのクライアント数が少なく、
50 台以下の場合です。こうした限られた状況下では、インデクサーまたはサーチヘッドがデプロイサーバーの役割も兼
ねる可能性があります。
同様に、クライアント数が 50 台超のデプロイサーバーでは、基本的にはサーチヘッドである分散管理コンソールをホス
トしないでください。
ただし、通常はサーチヘッドクラスタデプロイヤーをデプロイサーバーと同じインスタンスで実⾏することが可能です。
7
『分散サーチ』マニュアルの「デプロイヤーの要件」を参照してください。
デプロイサーバーの規模の設定については、「デプロイサーバーのパフォーマンスの⾒積もり」を参照してください。
設定対象
デプロイサーバーとデプロイクライアントの両⽅を設定する必要があります。
各デプロイクライアント上で、CLI コマンドを実⾏して、設定ファイルを直接編集して、または (Windows ユ
ニバーサルフォワーダーの場合のみ) インストール時に、そのデプロイサーバーを指定します。
デプロイサーバー上で、デプロイ App を保管するディレクトリを作成します。次にフォワーダー管理を使って、
クライアントと App のマッピングを設定したサーバークラスを定義します。
基本⼿順
デプロイサーバーを設定するには、デプロイクライアントとデプロイサーバーの両⽅でさまざまな作業を実⾏する必要が
あります。これらの作業順序はある程度まで任意ですが、ここでは推奨する⼿順を説明します。
1.リモート設定のニーズを判断します。以下のような事項を検討してください。
リモート設定する Splunk Enterprise コンポーネントのタイプは？例：フォワーダー、インデクサー。
各コンポーネントタイプ内で、設定のニーズを表す特徴は何か？例：マシンタイプ、地域、App。
2.デプロイクライアントを設定ニーズによりグループ化します。クライアントは、アプリケーション、マシンタイプ、ま
たはその他のデプロイ⽅針に則した任意の基準でグループ化できます。クライアントを複数のグループのメンバーにする
こともできます。たとえば、フォワーダー forwarder-x を linux-x86_64 マシンタイプ、地理的場所 northamerican、および security App グループに、フォワーダー forwarder-y を windows-intel マシンタイプ、地理
的場所 asian、および security App グループに所属させることができます。
これらのグループは、サーバークラスの基盤となります。サーバークラスはデプロイクライアントのグループを、それら
にデプロイされる⼀連のコンテンツ (デプロイ App) にマップします。クライアントは複数のサーバークラスに所属する
ことができます。デプロイクライアントをサーバークラスに対応付けるガイダンスについては、「サーバークラスについ
て」を参照してください。
3.デプロイサーバーにするいずれかの Splunk Enterprise インスタンスを選択します。Splunk Enterprise のデプ
ロイサーバー機能が⾃動的に有効になります。このステップでインスタンスの選択以外に必要な作業はありません。この
インスタンスにダウンロード可能なコンテンツを保管し、またサーバークラスを定義します。デプロイサーバーはコンテ
ンツの更新を⼀連のデプロイクライアントに分散します。
ほとんどの場合、デプロイサーバーは専⽤の Splunk Enterprise インスタンスを必要とします。「デプロイサーバーシ
ステム要件」を参照してください。
重要：デプロイサーバーが⾃⼰のクライアントになることはできません。そうした場合、splunkd.log にエラー「This DC
shares a Splunk instance with its DS: unsupported configuration」が記録されます。
4.各デプロイクライアント上で、ステップ 3 で選択したデプロイサーバーを指定します。詳細は、「デプロイクライアン
トの設定」を参照してください。後ほど他のクライアントを追加することもできます。
5.デプロイサーバーのファイルシステム上で、クライアントに配布するコンテンツを保管する、デプロイ App ⽤ディレ
クトリを作成します。それらのディレクトリに App コンテンツを保管します。この作業は今実施しても、後ほど実施し
ても構いません。詳細は、「デプロイ App の作成」を参照してください。後ほど他のデプロイ App を追加することもでき
ます。
6.デプロイサーバー上で、デプロイクライアントをデプロイ App にマップする、サーバークラスを作成します。サー
バークラスの設定の詳細は、「サーバークラスについて」を参照してください。
注意：たいていの場合は、フォワーダー管理インターフェイスを使ってサーバークラスの設定を⾏えます。⼀部の特殊な
状況下では、直接設定ファイルを編集しなければならないこともあります。フォワーダー管理を使⽤する場合でも、直接
設定ファイルを編集する場合でも、基本的な⼿順は同じです。
この設定プロセスを完了したら、コンテンツのクライアントへの配布を開始できます。新しいコンテンツのクライアント
へのデプロイ⽅法については、「App のクライアントへのデプロイ」を参照してください。
SSL 暗号化
デフォルトの証明書を使った SSL 暗号化は最初から有効になっています。デプロイサーバー上の SSL 設定を変更した
場合は、デプロイクライアント上でもそれを変更する必要があります。デプロイサーバーとそのクライアントは、splunkd
管理⽤ポートの SSL 設定に合意しなければなりません。すべてで SSL を有効にするか、またはすべてで SSL を無効に
する必要があります。
Splunk Enterprise インスタンスの SSL 設定を無効にするには、server.conf ファイルの
「false」を設定します。
8
enableSplunkdSSL
属性に
[sslConfig]
enableSplunkdSSL = false
デプロイサーバーでの SSL の使⽤の詳細は、『Splunk のセキュリティ』マニュアルの「デプロイサーバーとクライアント
の保護」を参照してください。
デプロイクライアントの設定
このトピックでは、デプロイサーバーからコンテンツを受け取るための、デプロイクライアントの設定⽅法について説
明していきます。たいていの場合は、クライアントが接続するデプロイサーバーを指定する必要しかありません。
この作業はデプロイサーバーではなくデプロイクライアント上で⾏いますが、デプロイサーバーシステムの総合的な設定
を確⽴するために必要不可⽋な作業です。
重要：デプロイサーバーが⾃⼰のクライアントになることはできません。そうした場合、splunkd.log にエラー「This DC
shares a Splunk instance with its DS: unsupported configuration」が記録されます。これによりデプロイク
ライアントがデプロイサーバーと通信できなくなるおそれがあります。
デプロイサーバーの指定
各クライアント上で、接続先のデプロイサーバーを指定する必要があります。そのためには、クライアントの
deploymentclient.conf ファイルを編修して設定を⾏います。各デプロイクライアントniは、⼀意のネットワークホ
スト名が必要です。
このファイルを設定するには、3 種類の⽅法があります。
CLI を使⽤する。このトピックの後半にある、「CLI の使⽤」を参照してください。
ファイルを直接編集する。このトピックの後半にある、「deploymentclient.conf の編集」を参照してください。
Windows ユニバーサルフォワーダーの場合のみ：インストールプロセスの⼀環として、Windows フォワー
ダーをデプロイクライアントとして設定できます。次のユニバーサルフォワーダーマニュアルのトピックを参照し
て下さい。
Windows ユニバーサルフォワーダーをインストーラを使ってインストールします。
コマンドラインを使った Windows ユニバーサルフォワーダーのインストール
重要：デプロイサーバーを使⽤して deploymentclient.conf でデプロイクライアントを更新しないで下さい。デプロイク
ライアントがデプロイサーバーと通信できなくなるおそれがあります。
CLI の使⽤
デプロイクライアント上で、以下の CLI コマンドを実⾏します。
splunk set deploy-poll <IP_address/hostname>:<management_port>
splunk restart
クライアントの接続先デプロイサーバーの、IP_address/hostname と
management_port
を使⽤します。
例：
splunk set deploy-poll deploymentserver.splunk.mycompany.com:8089
splunk restart
deploymentclient.conf の編集
$SPLUNK_HOME/etc/system/local
に
deploymentclient.conf
ファイルを作成し、直接編集することもできます。
構⽂
deploymentclient.conf
ファイルには、2 つのスタンザが必要になります。
スタンザ
[deployment-client]
[targetbroker:deploymentServer]
その⽬的
新しいコンテンツや更新されたコンテンツの検索場所を含む、さまざまな属性を設定しま
す。⼀般的には、このスタンザのデフォルト値を変更する必要はありません。
このクライアントのデプロイサーバーの場所を指定します。deploymentServer は、デプロイ
サーバーのデフォルト名です。このスタンザ内にデプロイサーバーを指定する必要がありま
す。
9
このファイルには多数のオプション属性が存在していますが、⼤半のデプロイ環境では [target-broker:deploymentServer]
スタンザの targetUri しか設定する必要はありません。この属性には、クライアントのデプロイサーバーを指定します。
属性の構⽂を以下に⽰します。
targetUri
デフォル
ト
その⽬的
属性
N/A
デプロイサーバー接続情報を指定します。
<deployment_server_URI>:<management_port>
を設定します。⼀般的に管理⽤ポートは 8089 で
す。
deploymentclient.conf
の属性の⼀覧については、『管理マニュアル』の deploymentclient.conf に関する説明を参照し
てください。
重要：変更内容を有効にするには、デプロイクライアントを再起動する必要があります。
例
⼀般的なクライアント設定を以下に⽰します。
[deployment-client]
[target-broker:deploymentServer]
targetUri= deploymentserver.splunk.mycompany.com:8089
通常のように、この例ではほぼすべての属性でデフォルト値をそのまま使⽤しています。設定する必要があるデプロイ
サーバーの場所に関する属性には、設定値に deploymentserver.splunk.mycompany.com:8089 を指定しています。
クライアント名の設定
各デプロイクライアントに、クライアント名を割り当てることができます。デプロイサーバーは、クライアント名により
フィルタリングすることができます。「クライアントフィルタの設定」を参照してください。
デフォルトで、クライアント名にはデプロイクライアントの GUID が設定されます。クライアント名によるフィルタリン
グを使⽤する場合は、妥当で分かりやすい名前を明⽰的に設定することをお勧めします。
重要：クライアント名は⼀意でなければなりません。
クライアント名を設定する場合は、deploymentclient.conf の
clientName
属性に適切な名前を指定します。例：
[deployment-client]
...
clientName = Fflanda-LINUX1
設定の変更を反映するには、デプロイクライアントを再起動してください。
デプロイクライアント情報の⼊⼿
デプロイクライアントに関する情報は、2 つの場所から確認することができます。
そのデプロイクライアント上
デプロイサーバー上
デプロイクライアントでのステータスの表⽰
デプロイクライアントのステータスを表⽰するには、Splunk Web を使⽤します。
1.Splunk Web の上部にある [設定 ] リンクをクリックします。⼀連のシステムインターフェイスへのリンクが、ポッ
プアップウィンドウに表⽰されます。
2.[システム ] セクションの [サーバー設定 ] を選択します。
3.[デプロイクライアント設定 ] を選択します。クライアントに関する情報が、読み取り専⽤画⾯に表⽰されます。
そのデプロイサーバー
そのサーバークラスと App
ステータス
デプロイサーバーからのクライアントの表⽰
10
クライアントの設定を完了し、クライアントを再起動したら、指定したデプロイサーバーとのハンドシェイクプロセスが
開始されます。デプロイサーバーは、フォワーダー管理インターフェイスの [クライアント ] タブにあるクライアントリ
ストに、そのクライアントを追加します。例：
デプロイクライアントを無効にする
デプロイクライアントを無効にするには、デプロイクライアント上で以下の CLI コマンドを実⾏します。
splunk disable deploy-client
デプロイクライアントのアップグレード
クライアントのアップグレードは、クライアントがユニバーサルフォワーダーか、または完全版の Splunk Enterprise
インスタンスかに応じて、通常の⽅法で⾏います。インスタンスがデプロイクライアントであっても、アップグレード⽅
法に違いはありません。
ただし、クライアントのアップグレード後、デプロイサーバーが管理するクライアントのリストにそのクライアントは 2
回表⽰され、フォワーダー管理インターフェイス経由で公開されます。この重複表⽰を避けるには、クライアントのアッ
プグレード後に、デプロイサーバーを再起動する必要があります。
デプロイ App の作成
デプロイ App は、⼀連のデプロイクライアントにダウンロードさせる任意のコンテンツから構成されています。コン
テンツには、以下のものを含めることができます。
Splunk Enterprise App (Splunkbase で提供されている App など)
⼀連の Splunk Enterprise 設定
スクリプト、画像、サポートファイルなどの、その他のコンテンツ
デプロイ App を追加するには、それ⽤のディレクトリをデプロイサーバー上に作成します。ディレクトリを作成した
ら、フォワーダー管理インターフェイスを使って、App をデプロイクライアントにマップすることができます。
App へのコンテンツの追加やコンテンツの変更は、ディレクトリの作成時、または後ほどデプロイクライアントへの
App のデプロイまたは再デプロイ準備完了時など、任意の時点で⾏えます。
App ディレクトリの作成
各デプロイ App ⽤に個別のディレクトリを、デプロイサーバー上の特別な場所に作成します。デフォルトの場所は
$SPLUNK_HOME/etc/deployment-apps ですが、serverclass.conf の repositoryLocationで設定を変更することもできます。
この場所の下位には、各 App 独⾃のサブディレクトリを配置する必要があります。サブディレクトリ名が、フォワー
ダー管理インターフェイスにおける App 名となります。
注意： App がダウンロードされると、それはデプロイクライアント上の
$SPLUNK_HOME/etc/apps下に保管されます。
App は任意の時点で追加できます。新しい App ディレクトリを作成したら、CLI コマンド
して、デプロイサーバーにそれを認識させる必要があります。
reload deploy-server
を実⾏
splunk reload deploy-server
App ディレクトリを作成することで、そのディレクトリにコンテンツが何もない場合でも、デプロイ App ⾃体を作成し
たことになります。この App はフォワーダー管理インターフェイスに表⽰され、またこれを使ってサーバークラスを定
義することができます (「サーバークラスについて」を参照)。
重要：デプロイ App 名を指定する場合 (App ディレクトリを作成する場合)、設定ファイルの優先度について理解してお
く必要があります。『管理マニュアル』の「設定ファイルの優先度」を参照してください。特に、App ディレクトリの優先度
は、ASCII ソート順で決定されることに注意してください。たとえば、App ディレクトリ「A」内の設定ファイル x.conf
に、属性/値のペア whatever=1 を設定した場合、そのデプロイ App A の設定はデプロイ App B (B ディレクトリ) 内の
11
x.conf
にある
whatever=0
の設定よりも優先されます。それ以降も同様です。
App の保管
デプロイ App をクライアントにデプロイする前の任意の時点に、コンテンツを App ディレクトリに保管することができ
ます。その後デプロイ App を更新して再デプロイすることもできます。デプロイ App を更新するには、単純に当該
ディレクトリにファイルを追加するか、またはファイルを上書きします。デプロイ App の更新とクライアントへのデプ
ロイについては、「デプロイ App のクライアントへのデプロイ」を参照してください。
フォワーダー管理を使ったデプロイ App の表⽰
デプロイ App ⽤のディレクトリを作成したら、デプロイサーバーは、フォワーダー管理インターフェイスの [App] タ
ブにある App リストに、その App を追加します。例：
App 管理上の問題
デプロイサーバーを使って App を管理するかどうかを決定する前に、検討する必要があるいくつかの問題があります。
デプロイサーバーでの App の管理を決定したらそれを取り消せない
重要：デプロイサーバーを使ったデプロイ App の管理を開始したら、以後 App の管理にデプロイサーバーの使⽤を中
⽌することはできません。これが意味することを正しく理解しておくことが重要です。
デプロイサーバーの (serverclass.conf) に定義) から App を削除すると、デプロイクライアントはそれが保有する App
のコピーを削除します。デプロイクライアントに対して、各⾃の App を独⾃に管理するように指⽰する⽅法はありませ
ん。
たとえば、デプロイサーバーを使って「appA」の更新を管理する場合を考えてみましょう。このためには、デプロイサー
バー上にディレクトリ「appA」を作成し、そこに App のコンテンツを保管します。それ以降は、デプロイクライアントが
更新があるかどうかを確認するために、サーバーにポーリングを⾏い、⾃⼰の appA のチェックサムとサーバーの appA
のチェックサムを⽐較します。チェックサムが違っている場合、クライアントはサーバーから最新版の App をダウン
ロードします。ただし、サーバーの App リポジトリから appA が削除されていた場合は、クライアントは各⾃が保有し
ているその App を削除します。
そのため、デプロイサーバーで App を削除しても、クライアントにデプロイサーバーを使った App の管理を中⽌して、
各⾃が独⾃に App を管理するように指⽰したことにはなりません。実際には、App の削除を指⽰したことになりま
す。デプロイサーバーによる App の管理を開始したら、常にデプロイサーバーがその App を管理することになります。
警告：このような動作が⾏われるため、デプロイサーバーを使った Splunk Enterprise サーチ App の管理を決定する
にあたり、特に注意する必要があります。デプロイサーバーを使ってサーチ App を管理することで、ユーザーによる
サーチヘッド上への独⾃のサーチの保存を防⽌することになります。デプロイサーバーに App の管理を中⽌するように
指⽰する⼿段が存在しないため、その決定が後で問題になってしまう可能性もあります。
ルックアップテーブルを持つ App
インデクサーやサーチヘッドが、ルックアップテーブルに情報を保存する App を実⾏している場合もあります。そのよ
うな App の管理にデプロイサーバーを使⽤する場合は注意が必要です。デプロイサーバーが更新された App 設定を配布
する場合、既存の App が上書きされます。その時点で、そのルックアップテーブルが失われてしまいます。
サーバークラスの作成
サーバークラスは、デプロイクライアントのグループを、1 つまたは複数のデプロイ App と対応付けます。サー
バークラスを作成することで、⼀連の App セットの形で更新を受け取る、⼀連のクライアントをデプロイサーバーに指
⽰します。
12
クライアントのグループ化⽅法
クライアントのグループ化は、マシンタイプ、OS、地域、またはアプリケーションタイプなど、さまざまな基準に基づ
いて⾏えます。
クライアントは複数のサーバークラスに所属することができます。たとえば、ケローナ (カナダ) にあり Web 運⽤チー
ムに情報を提供している Windows フォワーダーを、サーバークラス「canada」、「windows」、および「web_host」に
所属させます。複数のサーバークラスにクライアントが所属できる仕組みを以下の図に⽰します。
この例で、各デプロイクライアントは、2 種類のサーバークラス (OS および地理的な場所) に所属する Splunk
Enterprise フォワーダーです。デプロイサーバーがサーバークラスのリストを管理しており、それらのサーバークラス
を使って各クライアントに配布するコンテンツを決定しています。クライアントへのコンテンツの配布を制御するため
に、このようなタイプの管理⼿段を導⼊する例については、「複数のフォワーダーへの設定のデプロイ」を参照してくださ
い。
また、デフォルトですべてのデプロイクライアントに適⽤するサーバークラスを 1 つ定義して、クライアントをグループ
化する⽅法もあります。その後、デフォルトのサーバークラスに優先する、各種観点から定義したより特有のサーバーク
ラスを作成し、それをクライアントのサブグループに割り当てます。たとえば、同じインデクサーにデータを送信する
Windows ユニバーサルフォワーダーと Linux ユニバーサルフォワーダーが存在している場合に、すべてのフォワー
ダーが共通の outputs.conf ファイルを受け取るけれども、Windows フォワーダーはそれ専⽤の inputs.conf ファイルを
受信し、Linux フォワーダーは別のファイルを受信するように設定することができます。こうするためには、すべての
フォワーダーを対象に共通の outputs.confファイルを含むデプロイ App を配布するサーバークラス「all forwarder」を
定義し、それとは別に独⾃の inputs.conf ファイルを含む個別のデプロイ App を適切なフォワーダーに配布する
Windows および Linux ⽤のサーバークラスをそれぞれ定義します。
サーバークラス設定の概要
サーバークラスは、デプロイクライアントとデプロイ App 間のマッピングです。これは、デプロイサーバーにどの App
をどのクライアントに送信するのかを指⽰するものです。そのため、サーバークラスの定義時には、1 つまたは複数の
App を、デプロイクライアントのグループと関連付けます。
サーバークラスを定義するには、デプロイサーバー上で以下の⼿順に従って作業を⾏います。
1.サーバークラスを作成します。
2.サーバークラスに 1 つまたは複数のデプロイ App を指定します。
3.サーバークラスに所属させるクライアントを指定します。
このセクションは、これらの⼿順の概要について説明しています。設定作業の詳細は、サーバークラスの作成にフォワー
ダー管理を使⽤するのか、または serverclass.conf を直接編集するのかによって異なります。「サーバークラスの定義
13
⽅法」を参照してください。
1.サーバークラスの作成
フォワーダー管理を使って、または直接
serverclass.conf
を編集して、サーバークラスを作成し、名前を指定します。
重要：サーバークラス名は⼀意でなければなりません。
2.サーバークラスの App の指定
サーバークラスを作成したら、それにデプロイ App を関連付けます。これらの App は、事前にデプロイサーバーの
ファイルシステム上に作成したデプロイ App です。「デプロイ App の作成」を参照してください。サーバークラスと
App の関係は、1 対 1 でなくても構いません。単⼀のサーバークラスに複数の App を関連付けることも可能です。同
様に、1 つの App が複数のサーバークラスに所属することも可能です。
3.サーバークラスのクライアントの指定
次に、クライアントをサーバークラスに関連付ける必要があります。⼀般的には、クライアントを個別に指定することは
ありません。代わりにフィルタを設定して、サーバークラスに所属させる共通の特徴を持つクライアントを動的に決定し
ます。
サーバークラスの定義⽅法
サーバークラスはデプロイサーバー上で定義します。サーバークラス定義は、デプロイサーバーの
イルに保存されます。サーバークラスを定義するには 2 種類の⽅法があります。
serverclass.conf
ファ
フォワーダー管理インターフェイスを使⽤する。詳細は、「フォワーダー管理を使ったサーバークラスの定義」を参
照してください。これが、サーバークラスを定義する簡単な⽅法です。素早く対話的にクライアントをフィルタリ
ングして、それを App と対応付けることができます。
デプロイサーバーの serverclass.conf ファイルを直接編集する。詳細は、「serverclass.conf を使ったサーバー
クラスの定義」を参照してください。⼀部の⾼度な設定を⾏うには、serverclass.conf を直接編集する必要がありま
す。
重要：いったん serverclass.conf を直接編集したら、以後の設定にはフォワーダー管理を使⽤できなくなる可能性があり
ます。これは、フォワーダー管理が⼀部の設定のみにしか対応していないためです。フォワーダー管理と互換性がある
serverclass.conf の設定の詳細については、「互換性とフォワーダー管理」を参照してください。
serverclass.conf ファイル
ファイルは、主要なデプロイサーバー設定ファイルです。すべてのサーバークラス定義がこのファイル
に書き込まれます。また、デプロイサーバーの動作に関連するさまざまな設定も保有しています。このファイルの詳細
と、設定属性の⼀覧については、serverclass.conf ファイルを参照してください。
serverclass.conf
Splunk Enterprise 設定ファイルの背景情報については、『管理マニュアル』の「設定ファイルについて」を参照してくだ
さい。
フォワーダー管理インターフェイスでサーバークラスを設定する場合、その定義内容は
込まれます。serverclass.conf を直接編集し、より複雑な設定を⾏うことも可能です。
serverclass.conf
のコピーに書き
デプロイサーバーは、複数バージョンの serverclass.conf を保有することができます。設定ファイルに複数のバージョン
がある場合、Splunk Enterprise はその優先順位に基づいてすべてのバージョンの属性を結合していきます。Splunk
Enterprise が処理する優先度については、『管理マニュアル』の「優先度の設定」を参照してください。
フォワーダー管理を使って新しいサーバークラスを作成する場合、サーバークラス定義は $SPLUNK_HOME/etc/system/local
下の、serverclass.conf のコピーに保存されます。フォワーダー管理を使⽤せずに直接 serverclass.confを編集する場合
は、同じ $SPLUNK_HOME/etc/system/local ディレクトリに serverclass.conf ファイルを作成することをお勧めします。
ファイルにサーバークラス定義が存在している場合 (⼀般的には
下の App ディレクトリなど)、システム内の他のディレクトリに存在している
ファイルのサーバークラス定義とともに、このファイルのサーバークラスもフォワーダー管理インターフェイスに表⽰さ
れます。フォワーダー管理を使って既存のサーバークラスを編集する場合、変更内容は同じバージョンの
serverclass.conf に保存されます。つまり、$SPLUNK_HOME/etc/apps/SomeApp/local/serverclass.conf に定義されているサー
バークラスを編集した場合、フォワーダー管理は更新された定義内容を、この同じディレクトリにあるファイルに保存し
ます。ただし、その後フォワーダー管理を使って新しいサーバークラスを作成した場合、その新しいサーバークラスは
$SPLUNK_HOME/etc/system/local/serverclass.conf に保存されます。
他のディレクトリ下の
serverclass.conf
$SPLUNK_HOME/etc/apps/<app_name>/local
重要：サーバークラス名は、すべての
serverclass.conf
ファイル間で⼀意でなければなりません。
フォワーダー管理を使ったサーバークラスの定義
フォワーダー管理インターフェイスは、デプロイクライアントとデプロイ App を対応付けるサーバークラスを作
14
成、編集するための、対話型ビジュアルツールです。これは、デプロイサーバー上で実⾏します。インターフェイスの
概要とアクセス⽅法については、「フォワーダー管理の概要」を参照してください。
このインターフェイスは、サーバークラス設定を serverclass.conf ファイルに保存します。最初にサーバークラスを
保存する場合、フォワーダー管理はデプロイサーバーの $SPLUNK_HOME/etc/system/local 下に serverclass.conf を作成しま
す。serverclass.conf の詳細は、「serverclass.conf ファイル」を参照してください。
注意：⼀部の⾼度なサーバークラス設定を⾏うには、serverclass.conf を直接編集する場合もあります。フォワーダー管
理の制限事項については、「互換性とフォワーダー管理」を参照してください。serverclass.conf を直接編集する⽅法につ
いては、「serverclass.conf を使ったサーバークラスの定義」を参照してください。
サーバークラスの定義
サーバークラスは、デプロイクライアントをデプロイ App に対応付けます。そのため、サーバークラスを定義する前
に、クライアントを設定し、対応付ける App を作成する必要があります。詳細は、「デプロイクライアントの設定」およ
び「デプロイ App の作成」を参照してください。
クライアントと App を設定すると、それは⾃動的にフォワーダー管理インターフェイスに表⽰されます。
サーバークラスの定義は 3 つのステップから成り⽴っています。
1.サーバークラスを作成します。
2.サーバークラスにデプロイ App を追加します。
3.サーバークラスのクライアントを指定します。
ステップ 2 とステップ 3 は任意の順序で実⾏できます。また、任意の時点で⼀連のクライアントや App を変更するこ
ともできます。
重要：フォワーダー管理インターフェイスを使ってサーバークラス設定を編集、保存した場合、デプロイサーバーは最新
の App コンテンツを再ロードして、まだそれを受け取っていないクライアントにデプロイします。たとえば、サーバー
クラスに App を追加した場合、そのサーバークラスに該当するすべてのクライアントにその App が配布されます。
サーバークラスに新しいクライアントを追加したけれども App は変更していない場合は、その新しいクライアントに対
してのみ配布が⾏われます。デプロイサーバーによる App のデプロイまたは再デプロイの契機となる操作については、
「クライアントへの App のデプロイ」を参照してください。
1.サーバークラスの作成
サーバークラスを作成するには、フォワーダー管理インターフェイスに移動して (「フォワーダー管理インターフェイスへ
のアクセス」を参照)、以下の作業を⾏います。
1.[サーバークラス ] タブを選択します。
2.[新しいサーバークラス ] ボタンを選択します。
3.ポップアップウィンドウの [タイトル ] フィールドにサーバークラス名を⼊⼒し、[保存 ] をクリックします。
画⾯に App とクライアントの追加を指⽰するメッセージが表⽰されます。
重要：サーバークラス名は⼀意でなければなりません。また、スペースを含めることはできません。
2.App の追加
サーバークラスを保存する際に、App とクライアントの追加⽤画⾯が表⽰されます。サーバークラスに App を追加する
には：
1.[App の追加 ] ボタンをクリックします。[App の編集 ] ページに移動します。(後ほど⼀連の App を編集すること
もできます。この場合は、[サーバークラス ] タブに移動して、⽬的のサーバークラスに対応する [編集 ] ボタンをク
リックします。)
[App の編集 ] ページには、[選択解除された App] と [選択された App] の 2 つの列があり、それぞれに対応する
App が⼀覧表⽰されています。新しいサーバークラスの場合、当初はすべての App が［選択解除された App］列に
表⽰されます。ここに表⽰される App は、デプロイサーバー上のリポジトリ (デフォルトは
$SPLUNK_HOME/etc/deployment-apps) 内のサブディレクトリに存在している App です (「デプロイ App の作成」を参照)。
2.サーバークラスに App を追加するには、⽬的の App をクリックします。この操作により、App が［選択解除され
た App］列から［選択された App］列に移動します。
3.サーバークラスに⽬的の App をすべて追加したら、[保存 ] をクリックします。まだクライアントを追加していない場
合は、クライアントの追加を指⽰するメッセージが表⽰されます。
このサーバークラスにクライアントをすでに指定している場合は、App 設定を保存する際に、デプロイサーバーが App
を再読み込みして、それを⼀連のクライアントにデプロイします。まだクライアントを指定していない場合は、クライア
15
ントの指定後に App がデプロイされます。
3.クライアントの指定
サーバークラスを保存する際に、App とクライアントの追加⽤画⾯が表⽰されます。サーバークラスにクライアントを追
加するには：
1.[クライアントの追加 ] ボタンをクリックします。(後ほど⼀連のクライアントを編集することもできます。この場合
は、[サーバークラス ] タブに移動して、⽬的のサーバークラスに対応する [編集 ] ボタンをクリックします。)[クライ
アントの編集 ] ページが表⽰されます。
[クライアントの編集 ] ページには、[すべて ]、[⼀致 ]、[不⼀致 ] の 3 種類のボタンと、クライアントのリストがあり
ます。[すべて ] ボタンを選択して表⽰されるクライアントは、「デプロイクライアントの設定」で説明しているように、前
にこのデプロイサーバーに対して設定したクライアントです。[⼀致 ] および [不⼀致 ] ボタンは、ページ上部で作成した
フィルタに⼀致するかどうかによって、クライアントを表⽰します。新しいサーバークラスの場合、当初は [⼀致 ] タブ
下にクライアントは表⽰されません。
2.サーバークラスにクライアントを追加する場合、個別にクライアントを指定するのではありません。代わりにフィルタ
を作成し、動的にクライアントを含めるか、または除外します。フィルタは、ページ上部のフィールド [含める ]、 [除
外 ]、および [マシンタイプでフィルタ ] を使って指定します。クライアントフィルタを作成するためには、さまざまな
事柄を学習する必要があります。詳細は、「クライアントフィルタの設定」を参照してください。
1 つまたは複数のフィルタを指定したら、[プレビュー ] ボタンをクリックすると、条件に⼀致する⼀連のクライアント
を確認することができます。
クライアントのリストが⾧すぎて、その⼀部のみを参照したい場合は、[すべて ]/[⼀致 ]/[不⼀致 ] ボタンの隣にある
[フィルタ ] フィールドを使⽤します。このフィルタは、画⾯に表⽰するクライアントのみを制限するものです。サー
バークラスに含めるクライアントを制限するものではありません。たとえば、クライアントのリストをホスト名や IP ア
ドレスでフィルタリングすることができます。
3.サーバークラスに⽬的のクライアントをすべて追加したら、[保存 ] をクリックします。まだ App を追加していない場
合は、App の追加を指⽰するメッセージが表⽰されます。
クライアント設定を保存したら、デプロイサーバーがこのサーバークラスの⼀連の App を再読み込みして、それを受け
取っていないクライアントにデプロイします。この処理は、サーバークラスに App をすでに指定している場合にのみ⾏
われます。
サーバークラスの表⽰
サーバークラスの内容を表⽰するには：
1.フォワーダー管理ホームページの [サーバークラス ] タブに移動します。デプロイサーバー上のすべてのサーバークラ
スが⼀覧表⽰されます。
2.⽬的のサーバークラスをクリックします。そのサーバークラスの詳細ページが表⽰されます。このページには、3 つの
セクションがあります。
ステータス：ページ上部には、そのサーバークラスの App 数とクライアント数が表⽰されます。また、デプロイ
の成功率に関する情報も表⽰されます。
App：中央のセクションには、サーバークラスに対応する App とそのデプロイステータスが表⽰されます。ここ
では、以下のような作業を⾏えます。
サーバークラスの⼀連のApp を編集するには、リスト上部の [編集 ] リンクをクリックします。
App の詳細を表⽰するには、App 名をクリックします。
16
App の属性を編集するには、App に対応する [編集 ] アクションをクリックします。
クライアント：下部のセクションには、サーバークラスに対応するクライアント、およびそれに関連するステータ
スなどの情報が表⽰されます。ここでは、以下のような作業を⾏えます。
サーバークラスの⼀連のクライアントを編集するには、リスト上部の [編集 ] リンクをクリックします。
クライアントの連絡時期、デプロイステータス、またはクライアントテーブル内の他のフィールドでリスト
をフィルタリングできます。
クライアントの詳細を表⽰するには、各⾏の⼀番左側の列にある⽮印をクリックします。
App の管理の詳細は、「フォワーダー管理を使った App の管理」を参照してください。クライアントの管理の詳細は、
「フォワーダー管理を使ったクライアントの管理」を参照してください。
サーバークラスの編集
任意の時点でサーバークラスを編集することができます。フォワーダー管理ホームページの [サーバークラス ] タブに移
動します。⽬的のサーバークラスを探して、その⾏の [編集 ] ボタンをクリックします。以下の作業を⾏えます。
クライアントの編集：サーバークラスの⼀連のクライアントを編集します。「フォワーダー管理を使ったクライア
ントの管理」を参照してください。
App の編集：サーバークラスの⼀連の App を編集します。「フォワーダー管理を使った App の管理」を参照して
ください。
名前変更：サーバークラス名を変更します。
削除：サーバークラスを削除します。
⼀連のクライアントや App の編集後に [保存 ] をクリックすると、デプロイサーバーは最新の App コンテンツを再読み
込みして、まだそれを受け取っていないクライアントにデプロイします。
注意：個別のサーバークラスページの右上にある [編集 ] ボタンを使っても、同じ編集操作を⾏えます。
クライアントフィルタの設定
サーバークラス定義時の主要な作業が、そのサーバークラスに所属する⼀連のクライアントを指定することです。指定に
は、クライアントフィルタを使⽤します。
フィルタの種類
3 種類のクライアントフィルタがあります。
ホワイトリスト： IP アドレス、ホスト名、DNS 名、またはクライアント名に基づいて、含めるクライアントを指
定します。
ブラックリスト： IP アドレス、ホスト名、DNS 名、またはクライアント名に基づいて、除外するクライアントを
指定します。
マシンタイプ： linux-i686, linux-x86_64 などのマシンタイプに基づいて、含めるクライアントを指定します。
注意：クライアント名は、deploymentclient.conf 内の clientName 属性を使って、デプロイクライアントに割り当てるこ
とができる論理名です。詳細は、「クライアント名の設定」を参照してください。
これらのフィルタを 1 つまたは複数使⽤して、サーバークラスに所属する⼀連のクライアントを定義します。たとえば、
北⽶ (North American) 地域のすべてのクライアントをホワイトリストに登録し、それをすべての Windows クライ
アントを含むマシンタイプフィルタと組み合わせることができます。こうすることにより、北⽶地域の Windows クラ
イアントがサーバークラスに追加され、北⽶地域の Linux クライアントや他の地域にあるクライアントとは個別に処理
できるようになります。
フォワーダー管理を使ったフィルタの定義
フォワーダー管理では、常にサーバークラス全体のフィルタを定義することになります。フィルタをグローバルレベルま
たは App レベルで定義する必要がある場合は、serverclass.conf を直接編集する必要があります。
サーバークラスのクライアントを指定する際に、フィルタを定義します。クライアントの指定⼿順については、「フォワー
ダー管理を使ったサーバークラスの定義」を参照してください。このトピックに記載されている⼿順により、[クライアン
トの編集 ] ダッシュボードが表⽰されます。このダッシュボードの上部には、含める (ホワイトリスト)、除外 (ブラック
リスト)、およびマシンタイプに対応する個別のフィールドがあります。
17
注意：
これらのフィールドには、必要に応じて任意の数の値を⼊⼒することができます。また、各フィールドに複数の
フィルタを指定することもできます。
複数のホワイトリスト/ブラックリストフィルタを使⽤する場合は、各フィルタをカンマで区切ります。
IP アドレスまたはホスト名を指定する場合は、10.1.1.* や
きます。
fwdr-*
のように、ワイルドカードを使⽤することがで
マシンタイプフィルタの場合は、ドロップダウンリストを使⽤します。このリストには、デプロイサーバーの⼀連
のクライアントに対応する、すべてのマシンタイプが表⽰されます。たとえば linux-x86_64、linux-i686、windowsx64 がドロップダウンリストに表⽰される場合があります。クライアントをどのようにグループ化するのかに応じ
て、各マシンタイプに対する個別のサーバークラスを⽤意しなければならないことも、複数のマシンタイプ (たと
えば、すべての Linux マシンタイプ) を 1 つのサーバークラスにまとめられることもあります。
フォワーダー管理のマシンタイプフィルタは、serverclass.conf 内の
す。machineTypes 属性ではありません。
machineTypesFilter
属性に対応していま
フィルタの組み合わせ⽅法
各種フィルタを組み合わせると以下のように処理されます。
デフォルトでサーバークラスにクライアントは含まれません。
ホワイトリストの任意の項⽬に⼀致し、ブラックリストの任意の項⽬に⼀致しないクライアントがサーバークラス
に含まれます。
ブラックリストの任意の項⽬に⼀致するクライアントは、ホワイトリストに関係なくサーバークラスから除外され
ます。
マシンタイプフィルタは、ホワイトリスト/ブラックリストの適⽤後の結果に対して適⽤されます。マシンタイプ
フィルタを単独で適⽤したい場合は、マシンタイプを指定するだけではなく、ホワイトリストにアスタリスクを指
定する必要があります。
さまざまな結果を得るために、フィルタフィールドに⼊⼒する内容の例を以下に⽰します。これらは単なる例であり、ク
ライアントのホスト名や DNS 名の表記/命名規則によって指定内容は異なります。
例 1
すべての Windows 64 ビットクライアントを含める例です。
ホワイトリスト：*
ブラックリスト：
マシンタイプ：windows-x64
重要：ホワイトリストフィルタのアスタリスクは必須項⽬です。そうしないと、マシンタイプフィルタを適⽤するクライ
アントは何も出⼒されません。
例 2
すべての Windows 64 ビットフォワーダーを含めます。
ホワイトリスト：fwdr-*
ブラックリスト：
マシンタイプ：windows-x64
18
例 3
北⽶ (North America) 地域外の、会社の Ops エリアにある Linux クライアントを含めます。
ホワイトリスト：*.ops.yourcompany.com
ブラックリスト：northamerican-*
マシンタイプ：linux-i686, linux-x86_64
serverclass.conf
を扱うこのトピックのセクションには、フォワーダー管理フィルタ設定に関連するフィルタの詳細が含
まれます。
フィルタ動作の詳細
その他の例
serverclass.conf によるフィルタの定義
フォワーダー管理インターフェイスでは対応できないフィルタリングが必要な場合は、serverclass.conf を直接編集する
ことができます (たとえば、複数のレベルにまたがってフィルタを階層化する必要がある場合、またはサーバークラス内
の異なる App に応じて異なるフィルタを定義する必要がある場合など)。
serverclass.conf
では、3 種類のレベルでフィルタを定義することができます。
グローバル：これらのフィルタは、すべてのサーバークラスに適⽤されます。
サーバークラス：これらのフィルタは、1 つのサーバークラス全体に適⽤されます。
App：これらのフィルタは、サーバークラス内の単⼀の App にのみ適⽤されます。
異なるレベルで複数のフィルタを定義することができます。より限定的なフィルタが常に優先されます。たとえば、グ
ローバルレベルでホワイトリストフィルタを定義した後に、各サーバークラスレベルで異なるブラックリストフィルタを
使⽤して、各サーバークラスから⼀部のクライアントを除外することができます。
を編集したら、変更内容を反映するためにデプロイサーバーを再ロードする必要があります。デプロイ
サーバーを再ロードするには、CLI コマンドの reload deploy-server を実⾏します。
serverclass.conf
splunk reload deploy-server
詳細は、「デプロイサーバーの再ロード」を参照してください。
重要： serverclass.conf を直接編集した場合、その後の設定作業にフォワーダー管理インターフェイスを使⽤できなくな
る強い可能性があります。詳細は、「互換性とフォワーダー管理」を参照してください。
デプロイクライアントのホスト名の決定
このフィルタはデプロイクライアントのホスト名に対して動作します。フィルタリングを⾏うホスト名の正しい組み合わ
せ決めるために、デプロイサーバーの CLI コマンドを実⾏できます。
splunk list deploy-clients
フィルタリング属性のリスト
フィルタの動作を決定する
serverclass.conf
内の属性を以下に⽰します。
フィルタ属性
filterType
その⽬的
「whitelist」または「blacklist」を設定します。
デ
フォ
ルト
ホワ
イト
フィルタの実⾏/適⽤順序を決定します。filterType に whitelist を設定する
リス
と、まずすべてのホワイトリストフィルタが適⽤され、次にブラックリストフィト
ルタが適⽤されます。filterType に blacklist を設定すると、まずすべてのブ
ラックリストフィルタが適⽤され、次にホワイトリストフィルタが適⽤されま
す。
whitelist
設定は、サブセットを抽出するフィルタリング⽅針を意味していま
す。
デフォルトで、項⽬はスタンザに⼀致しないとみなされます。
ホワイトリストの任意のエントリに⼀致し、ブラックリストの任意のエン
トリに⼀致しない項⽬が、スタンザに⼀致するとみなされます。
ブラックリストの任意のエントリに⼀致する項⽬は、ホワイトリストに関
係なくスタンザに⼀致しないとみなされます。
19
blacklist
設定は、サブセットを除外するフィルタリング⽅針を意味していま
す。
デフォルトで、項⽬はスタンザに⼀致するとみなされます。
ブラックリストの任意のエントリに⼀致し、ホワイトリストの任意のエン
トリに⼀致しない項⽬が、スタンザに⼀致しないとみなされます。
任意のホワイトリストエントリに⼀致する項⽬が、スタンザに⼀致すると
みなされます。
要約：
whitelist：デフォルトで不⼀致
-> ホワイトリスト包含 -> ブラックリス
ト除外
blacklist：デフォルトで⼀致
-> ブラックリスト除外 -> ホワイトリスト
包含
および serverClass:app レベルで、この値に優先する設定を⾏えま
す。グローバルレベルで whitelist を指定した後、個別のサーバークラスレベル
で blacklist を指定した場合、そのサーバークラスに対する設定は blacklist に
なり、そのサーバークラス定義でグローバルレベルに優先させるフィルタを指定
する必要があります。
serverClass
重要：フォワーダー管理インターフェイスを利⽤する場合、filterType はデ
フォルト値の whitelist でなければなりません。
whitelist. <n>
blacklist. <n>
は符号なし整数です。値の並びはどんな値から始まってもよく、また不連続 N/A
でも構いません。
<n>
属性に
ipAddress, hostname, DNSname,
または
clientName
を設定します。
は、デプロイクライアントの IP アドレスです。次のようなワイ
ルドカードを使⽤することができます：10.1.1.*
hostname は、デプロイクライアントのホスト名です。次のようなワイルド
カードを使⽤することができます：*.splunk.com
DNSname は、デプロイクライアントの DNS 名です。次のようなワイルド
カードを使⽤することができます：*.ops.yourcompany.com
clientName は、deploymentclient.conf 内のデプロイクライアントに割り当
てることができる、論理名またはタグ名です。これは、クライアントを
フィルタと照合する際に、ipAddress、hostname、または DNSname に優先し
ます。
ipAddress
これは、filterType が whitelist の場合の例の⼀部です。
whitelist.0=*.fflanda.com
blacklist.0=printer.fflanda.com
blacklist.1=scanner.fflanda.com
これにより、「printer」と「scanner」を除く fflanda.com 内のすべてのデプロ
イクライアントが、このサーバークラスに⼀致します。
filterType
が blacklist の場合：
blacklist.0=*
whitelist.0=*.web.fflanda.com
whitelist.1=*.linux.fflanda.com
これにより、「web」と「linux」クライアントのみがサーバークラスと⼀致しま
す。その他のクライアントは⼀致とみなされません。
デプロイサーバーは、<n> 値の並びが最初に途切れた時点でフィルタの評価を中
断します。
serverClass
および
serverClass:app
レベルで、このフィルタに優先する設定を
⾏えます。
重要：ある種類のフィルタ (ホワイトリスト/ブラックリスト) に優先する設定を
⾏うと、もう⼀⽅のタイプにも優先することになります。たとえば、ホワイトリ
ストに優先する設定を⾏うと、ブラックリストも親から継承されないため、スタ
ンザ内でブラックリストも設定する必要があります。
whitelist.from_pathname この属性を <pathname> に設定して、フィルタリングする値を含んだプレーンテ
キストファイルかカンマ区切りのファイル (CSVファイル) を作って下さい。
blacklist.from_pathname
20
N/A
この属性により、デプロイサーバーは指定したファイルから、<clientName>、<IP
address> または <hostname> のリストをインポートします。
CSV ファイルから値をインポートする場合は、この属性
をwhitelist|blacklist.select_field、whitelist|blacklist.where_field または
whitelist|blacklist.where_equals 属性とともに使⽤する必要があります。この
属性により⽬的の値を含むCSVファイルにフィールドが指定されます。
これらすべての属性の使⽤の詳細は、外部ファイルからフィルタリング値をイン
ポートする⽅法の例とともに、serverclass.conf ファイルを参照して下さ
い。
machineTypesFilter
カンマ区切りリスト内の任意のマシンタイプを照合します。
この設定では、デプロイクライアントのハードウェアタイプをフィルタとして使
⽤できます。このフィルタは、ホワイトリスト/ブラックリストフィルタに⼀致
するクライアントがある場合にのみ適⽤されます。
の値はマシンタイプのカンマ区切りリストです。たとえ
ば、linux-i686, linux-x86_64 のようになります。各マシンタイプは、ハード
ウェアプラットフォーム⾃体が指定する特定の⽂字列です。
machineTypesFilter
注意： linux-* の値には、windows-*、aix-* 、machineTypesFilter のようにワイ
ルドカードを使⽤することができます。
クライアント上でこの⽂字列を検索する⼿段はプラットフォームによって異なり
ますが、デプロイクライアントがすでにデプロイサーバーに接続している場合、
デプロイサーバー上で以下の CLI コマンドを実⾏して、⽂字列の値を確認する
ことができます。
splunk list deploy-clients
これにより、utsname の値が返されます。それを使って、machineTypesFilter を
指定することができます。
この設定は、カンマ区切りリスト内の任意のマシンタイプを照合します。⼀般
的に利⽤されるマシンタイプとしては、次のものが挙げられます：linuxx86_64, windows-x64, linux-i686, freebsd-i386, darwin-i386, sunos-sun4u,
linux-x86_64, sunos-i86pc, freebsd-amd64.
これらの属性の詳細は、『管理マニュアル』の serverclass.conf ファイルに関する説明を参照してください。
例
クライアントフィルタリングのいくつかの例を以下に⽰します。serverclass.confいろいろな理由からこれらの例を、フォ
ワーダー管理で厳密に再現することはできません。たとえば最初の例は、1 つのホワイトリストをグローバルレベルで定
義しています。フォワーダー管理では、すべてのフィルタがサーバークラスレベルで定義されます。2 番⽬の例では、1
つのサーバークラスで filterType 属性に blacklist を設定しています。フォワーダー管理で、filterType は常に
whitelist が設定されます。
# Example 1
# Match all clients and includes all apps in the server class
[global]
whitelist.0=*
# whitelist matches all clients.
[serverClass:AllApps]
[serverClass:AllApps:app:*]
# a server class that encapsulates all apps in the repositoryLocation
# Example 2
# Assign server classes based on hostnames.
[global]
[serverClass:AppsForOps]
whitelist.0=*.ops.yourcompany.com
[serverClass:AppsForOps:app:unix]
[serverClass:AppsForOps:app:SplunkLightForwarder]
21
[serverClass:AppsForDesktops]
filterType=blacklist
# blacklist everybody except the Windows desktop machines.
blacklist.0=*
whitelist.0=*.desktops.yourcompany.com
[serverClass:AppsForDesktops:app:SplunkDesktop]
# Example 3
# Deploy server class based on machine types
[global]
# whitelist.0=* at the global level ensures that the machineTypesFilter attribute
# invoked later will apply.
whitelist.0=*
[serverClass:WindowsMachineTypes]
machineTypesFilter=windows-*
[serverClass:WindowsMachineTypes:app:WindowsApp]
[serverClass:LinuxMachineTypes]
machineTypesFilter=linux-i686, linux-x86_64
[serverClass:LinuxMachineTypes:app:LinuxApp]
# Example 4
# Blacklist a range of IP addresses, using a regular expression
[global]
[serverClass:ExcludeSomeIPAddresses]
filterType=whitelist
whitelist.0=*
blacklist.0=192.168.1.1[34][0-9]
# Example 5a
# Use (whitelist|blacklist) text file import.
[serverClass:MyApps]
whitelist.from_pathname = etc/system/local/clients.txt
# Example 5b
# Use (whitelist|blacklist) CSV file import to read all values from the Client
# field (ignoring all other fields).
[serverClass:MyApps]
whitelist.select_field = Client
whitelist.from_pathname = etc/system/local/clients.csv
# Example 5c
# Use (whitelist|blacklist) CSV file import to read some values from the Client
# field (ignoring all other fields) where ServerType is one of T1, T2, or
# starts with dc.
[serverClass:MyApps]
whitelist.select_field = Client
whitelist.from_pathname = etc/system/local/server_list.csv
whitelist.where_field = ServerType
whitelist.where_equals = T1, T2, dc*
# Example 5d
# Use (whitelist|blacklist) CSV file import to read some values from field 2
# (ignoring all other fields) where field 1 is one of T1, T2, or starts with
# dc.
[serverClass:MyApps]
whitelist.select_field = 2
whitelist.from_pathname = etc/system/local/server_list.csv
whitelist.where_field = 1
whitelist.where_equals = T1, T2, dc*
22
App のデプロイ
クライアントへの App のデプロイ
デプロイサーバーは、クライアントにデプロイ App を配布します。
App は以下の場合にデプロイされます。
サーバークラスを作成し、⼀連のクライアントを 1 つまたは複数の App にマップした場合。
サーバークラスを変更した場合 (たとえば、サーバークラスの⼀連の App やクライアントを変更した)。
App のコンテンツを変更した場合。
サーバークラスに新しいクライアントが追加された場合。
また、App が⾃動的にデプロイされることもあります。その他の場合は、⼿動でデプロイを開始する必要があります。ま
たこのことは、フォワーダー管理を使⽤しているか、または直接 serverclass.confを編集しているかによっても異なりま
す。
App のデプロイにかかる時間の⾒積もりについては、「デプロイサーバーのパフォーマンスの⾒積もり」を参照してくださ
い。
新しいまたは更新されたサーバークラス内のクライアントへの App のデプロイ
サーバークラスを作成または変更したら、次にフィルタで指定されたクライアントに App をデプロイします。フォワー
ダー管理でサーバークラスを設定した場合は、⾃動的に処理が⾏われます。serverclass.conf を直接編集してサーバーク
ラスを設定した場合は、デプロイを⼿動で実施する必要があります。
フォワーダー管理を使⽤する場合
最初にサーバークラスを作成する場合、⼀連のクライアントを⼀連の App にマップします。クライアントフィルタと
App の両⽅を指定したら、デプロイサーバーが App を⾃動的に、適切なクライアントにデプロイします。この⼿順は、
「フォワーダー管理を使ったサーバークラスの定義」で説明しています。
後ほどサーバークラスを編集し、⼀連の App またはクライアントフィルタを変更すると、デプロイサーバーはすべての
サーバークラスを再デプロイします。つまり、任意のサーバークラス (編集したサーバークラスだけでなく) の App のコ
ンテンツが前回デプロイ時から変更されている場合、デプロイサーバーは最新版の App を対応するクライアントにデプ
ロイします。
重要：フォワーダー管理を使って設定を変更した場合は、⾃動的にデプロイサーバーが再ロードされます。これにより、
デプロイサーバーはすべてのサーバークラスにまたがって、変更された App を再デプロイします。
serverclass.conf を直接編集する場合
を直接編集してサーバークラスを作成することができます。フォワーダー管理を利⽤した場合と違
い、serverclass.conf を直接編集しても、それに応じてデプロイサーバーが⾃動的に App をデプロイすることはありま
せん。デプロイを開始するには、デプロイサーバーを⼿動で再ロードする必要があります。
serverclass.conf
再ロードするには、CLI コマンド
reload deploy-server
を実⾏します。
splunk reload deploy-server
reload deploy-serverを実⾏すると、デプロイサーバーはすべてのサーバークラスをデプロイします。つまり、サーバーク
ラス内の App が新しく追加された、または前回のデプロイ時から変更された場合は、そのサーバークラスに対応するク
ライアントに最新版の App がデプロイされます。同様に、前回のデプロイサーバー再ロード時からクライアントフィル
タを変更した場合は、各サーバークラスに対応するクライアントに、最新版の App がデプロイされます。
を直接編集するサーバークラスの作成については、「serverclass.conf を使ったサーバークラスの定
義」を参照してください。
serverclass.conf
コンテンツ変更後の App の再デプロイ
App のコンテンツを更新したら、App を再デプロイするために、デプロイサーバーを再ロードする必要があります。
注意：フォワーダー管理を使⽤した場合に、App を即座に再デプロイしたい場合は、デプロイサーバーを⼿動で再ロー
ドする必要があります。デプロイサーバーを⼿動で再ロードしない場合でも、フォワーダー管理で何らかの設定を変更し
た場合、App は再デプロイされます。
コンテンツが更新された App を再デプロイするには：
23
1.デプロイサーバー上の関連するデプロイ App ディレクトリのコンテンツを更新します。
2.デプロイサーバーが変更されたコンテンツを認識できるように、デプロイサーバーを再ロードします。
デプロイサーバーが、対応するすべてのクライアントに App を再デプロイします。
1.コンテンツの更新
デプロイサーバー上に App ディレクトリを作成する⽅法は、「デプロイ App の作成」で説明しています。これらのディレ
クトリの内容はいつでも追加または上書きすることができます。
2.デプロイサーバーの再ロード
App のコンテンツを編集したら、デプロイサーバーを再ロードして、に変更した App を認識させる必要があります。そ
うすると App が対応する⼀連のクライアントに再デプロイされます。
デプロイサーバーを再ロードするには、CLI コマンドの
reload deploy-server
を使⽤します。
splunk reload deploy-server
このコマンドはすべての App の変更をチェックして、関連するクライアントに通知します。
新しいクライアントへの App のデプロイ
デプロイクライアントが初めてデプロイサーバーに接続する場合、デプロイサーバーは⾃動的にクライアントに適⽤され
るサーバークラスの App をデプロイします。この場合、デプロイサーバーを再ロードする必要はありません。
この例としては、新しいデプロイクライアントを設定し、そのクライアントが既存のサーバークラスの適⽤対象となるマ
シンタイプである場合が挙げられます。
App 更新からのコンテンツの除外
指定したファイルやディレクトリを、App の更新から除外することができます。この機能を有効にすると、デプロイ·ク
ライアントは初めてダウンロードしたコンテンツをコピーしますが、それ以降のその App の更新時にはそれを無視しま
す。この機能は、更新時に /local ディレクトリの内容が消去されることを防⽌するために役⽴ちます。
この機能には、デプロイサーバーとデプロイクライアントのバージョンがともに 6.2 かそれ以降であることが必要になり
ます。
この機能を使⽤するには、デプロイサーバーの
serverclass.conf
に
excludeFromUpdate
属性を設定します。
たとえば、App の更新時に、my-app の /local ディレクトリの上書きを防⽌する場合を考えてみましょう。App は、次の
ような⼀般的なディレクトリ構造を持っています。
my-app/
default/
local/
some-conf.conf
...
ディレクトリのコンテンツを更新から除外するには、serverclass.conf の
属性を指定します。
/local
my-app
スタンザ内に、excludeFromUpdate
[serverClass:my-class:app:my-app]
excludeFromUpdate = $app_root$/local
デプロイクライアントが初めて App をダウンロードする時には、/local ディレクトリとそのコンテンツがコピーされま
す。それ以降のダウンロードでは、このディレクトリは完全に無視されます。クライアント上にすでに存在してい
る、/local ディレクトリ内のコンテンツはそのまま保持されます。同様に、ダウンロードしたデータの /local ディレク
トリ内にある新しいコンテンツは無視されます。
以下の事項に注意してください。
App のルートディレクトリの指定には、$app_root$ を使⽤する必要があります。
個々のファイルまたはディレクトリ全体を除外することができます。
excludeFromUpdate は、グローバル、サーバー·クラス、または App の任意のスタンザ·レベルで指定することができ
ます。たとえば、グローバル·レベルに指定した場合、指定されたコンテンツがすべての App から除外されます。
App デプロイステータスの表⽰
24
フォワーダー管理インターフェイスを使って、App の配布ステータスを参照することができます。
[App] タブに移動します。各 App に対して、App がデプロイされたクライアント数に関する情報が表⽰されます。
App をクリックすると、その App の詳細ページが表⽰されます。
重要：ダッシュボードの上部にある [App データサイズ ] フィールドは、App バンドルのサイズを⽰しています。バ
ンドルは、App を含む圧縮形式ファイルです。デプロイサーバーはこの形式で App をパッケージ化して、クライアント
に配布します。クライアントがバンドルを受け取ったら、それを解凍して適切な場所にインストールします。
CLI を使ってデプロイステータスに関する情報を⼊⼿することもできます。すべてのクライアントにデプロイされたこと
を確認するには、デプロイサーバー上で以下のコマンドを実⾏します。
splunk list deploy-clients
これにより、最後にデプロイサーバーが再起動されてから、デプロイサーバーと通信を⾏ったデプロイクライアントがす
べて表⽰されます。
デプロイサーバーの管理
デプロイサーバーのパフォーマンスの⾒積もり
ここでは、⼀連のクライアントに App をダウンロードするまでにかかる時間の⾒積もりに役⽴つ情報を説明していきま
す。以下の事項が主な決定要素になります。
デプロイサーバーの仕様
クライアントがデプロイサーバーに更新を問い合わせる間隔 (頻度)
クライアント数
App の合計サイズ
デプロイサーバーのプロビジョニング
デプロイサーバーをプロビジョニングする際には、以下の事項に注意してください。
50 台を超えるクライアントをデプロイする場合は、デプロイサーバーを専⽤の Splunk Enterprise インスタン
ス上で実⾏しなければなりません。このインスタンスはインデクサーまたはサーチヘッドの役割を兼ねることはで
きません。
クライアント数が 50 台超のデプロイサーバーでは、基本的にはサーチヘッドである分散管理コンソールをホスト
しないでください。
また、クライアント数が 50 台超のデプロイサーバーでは、サーチヘッドクラスタデプロイヤーをホストしないで
ください。
クライアント数が 50 台未満の場合は、分散管理コンソールを含むインデクサーまたはサーチヘッドとデプロイ
サーバーを共存させることができます。
App のダウンロード処理時には CPU 使⽤率およびメモリー消費量が⾼くなるため、インスタンスは専⽤のホスト
マシン上で動作させることをお勧めします。
Linux でのデプロイ時間
このガイダンスは、以下の設定を使って⾏われたテストに基づいています。
デプロイサーバーは専⽤のベアメタル 64 ビット Linuxシステム (12GB の RAM と 12 コア) 上で動作。
⾼速 LAN ネットワーク経由のデプロイ。待機時間が⼤きなネットワークでは、デプロイ時間が⾧くなります。
クライアントの問い合わせ間隔は 60 秒。
⼀連の App の合計サイズは 50MB。これは、デプロイするには⽐較的⼤きなサイズとみなされます。たいていの
場合、⼀連の App をデプロイするのは 1 回限りで、それ以降は更新された増分のみがデプロイされます。
25
すべてのクライアントに 50MB をデプロイするためにかかる合計時間の⾒積もりには (前述のデプロイサーバーハード
ウェアが前提)、以下の式を利⽤できます。
T = 0.0075 * C + 2
ここで T はデプロイの最⼤時間 (分)、C はデプロイクライアント数です。
たとえば、1000 台のクライアントに 50MB の App をデプロイするためには、最⼤ 9.5 分かかります。
Windows でのデプロイ時間
このガイダンスは、以下の設定を使って⾏われたテストに基づいています。
デプロイサーバーは専⽤の 64 ビット Windows Server 2008 仮想マシン (12GB の RAM と 8 コア) 上で動
作
⾼速 LAN ネットワーク経由のデプロイ。待機時間が⼤きなネットワークでは、デプロイ時間が⾧くなります。
クライアントの問い合わせ間隔は 60 秒。
⼀連の App の合計サイズは 50MB。これは、デプロイするには⽐較的⼤きなサイズとみなされます。たいていの
場合、⼀連の App をデプロイするのは 1 回限りで、それ以降は更新された増分のみがデプロイされます。
すべてのクライアントに 50MB をデプロイするためにかかる合計時間の⾒積もりには (前述のデプロイサーバーハード
ウェアが前提)、以下の式を利⽤できます。
T = 0.04 * C + 8
ここで T はデプロイの最⼤時間 (分)、C はデプロイクライアント数です。この式は、最⾼ 3000 台のクライアントのデ
プロイまで有効です。
2000 台を超えるクライアントをデプロイする場合、クライアントからの問い合わせ間隔を 5 分 (300 秒) に増やすこと
で⼤幅にパフォーマンスが改善する場合があります。
フォワーダー管理を使った App の管理
フォワーダー管理の主な機能は、デプロイ App をデプロイクライアントにマップする、サーバークラスを作成するこ
とにあります。この⼿順は、「フォワーダー管理を使ったサーバークラスの定義」で説明しています。
このインターフェイスには、デプロイ App を管理するためのツールも⽤意されています。以下の作業を⾏えます。
App の編集
App のアンインストール
App デプロイステータスの表⽰
App の編集
App を編集するには：
1.[App] タブに移動します。ここには、すべての App が⼀覧表⽰されます。
2.編集する App を探して、それに対応する [編集 ] アクションをクリックします。
3.[編集 ] オプションを選択します。[App の編集 ] 画⾯が表⽰されます。
ここでは、いくつかの作業を⾏えます。
App を新しいサーバークラスに追加する、または既存のサーバークラスから App を削除する。画⾯上部に
は、[サーバークラス ] と呼ばれるセクションがあります。新しいサーバークラスに App を追加するには、[+] ボ
タンをクリックします。サーバークラスの右にある [x] をクリックすると、そのサーバークラスから App が削除
されます。
デプロイクライアントが App をダウンロードした直後に実施する動作を指定する。2 種類のオプションを利⽤で
きます。
App を有効にする：クライアント上で App を有効にします。
Splunkd の再起動：クライアント上で splunkd を再起動します。
変更が完了したら、[保存 ] ボタンをクリックします。これにより、デプロイサーバーは変更内容を保存して、App の再
デプロイを⾏います (更新された他の App も含む)。App デプロイ処理の詳細は、「クライアントへの App のデプロイ」
を参照してください。
重要：フォワーダー管理インターフェイスから、App の実際のコンテンツを編集することはできません。コンテンツを
変更するには、デプロイサーバーのファイルシステム上で App を更新する必要があります。「デプロイ App の作成」を参
照してください。
26
App のアンインストール
App はすべてのサーバークラスから、または 1 つのサーバークラスのみからアンインストールすることができます。
すべてのサーバークラスからのアンインストール
すべてのサーバークラスから App をアンインストールするには：
1.[App] タブに移動します。ここには、すべての App が⼀覧表⽰されます。
2.編集する App を探して、それに対応する [編集 ] アクションをクリックします。
3.[アンインストール ] オプションを選択します。
これにより、すべてのサーバークラスから App が削除され、すべてのクライアントから App がアンインストールされま
す。デプロイサーバー上のファイルシステムから、実際の App が削除されることはありません。
1 つのサーバークラスからのアンインストール
1 つのサーバークラスからのみ App をアンインストールするには：
1.[サーバークラス ] タブに移動します。ここには、すべてのサーバークラスが⼀覧表⽰されます。
2.App を削除するサーバークラスを探して、それに対応する [編集 ] アクションをクリックします。
3.[App の編集 ] オプションを選択します。[App の編集 ] ページに移動します。[App の編集 ] ページには、[選択解
除された App] と [選択された App] の 2 つの列があり、それぞれに対応する App が⼀覧表⽰されています。
4.［選択された App］列で、アンインストールする App を探します。
5.App 名をクリックすると、［選択された App］列から［選択解除された App］列に App が移動します。
6.[保存 ] をクリックします。
デプロイサーバーは、そのサーバークラスに対応するすべてのクライアントから App を削除します。
App デプロイステータスの表⽰
App のデプロイステータスを表⽰するには：
1.[App] タブに移動します。ここには、すべての App が⼀覧表⽰されます。
2.［クライアント］列を探します。この列は、App を受け取ったクライアント数を表しています。
詳細を表⽰するには、App 名をクリックします。これにより、App に関するサマリー情報、および App のクライアン
トとそのデプロイステータスが表⽰されます。各クライアント列の左にある⽮印をクリックして、クライアントが関連付
けられている App とサーバークラスを参照することができます。
フォワーダー管理を使ったクライアントの管理
フォワーダー管理を使って、クライアントマッピングの編集やクライアントステータスの表⽰を⾏えます。
クライアントマッピングの編集
サーバークラスのクライアントマッピングを変更するには：
1.[サーバークラス ] タブに移動します。ここには、すべてのサーバークラスが⼀覧表⽰されます。
2.クライアントマッピングを変更するサーバークラスを探して、それに対応する [編集 ] アクションをクリックします。
3.[クライアントの編集 ] オプションを選択します。[クライアントの編集 ] ページが表⽰されます。ページの上部に
は、フィルタ⽤フィールドの [含める ]、[除外 ]、および [マシンタイプでフィルタ ] があります。
4.⼀連のフィルタを編集します。フィルタの詳細は、「クライアントフィルタの設定」を参照してください。
5.[保存 ] をクリックします。
フィルタを変更してサーバークラスとの関連付けが解除されたクライアントには、以前にダウンロードされたデプロイ
App は残りますが、それ以降デプロイサーバーからの更新を受け取ることはありません。
クライアントステータスの表⽰
特定のクライアントのステータスを表⽰するには、[クライアント ] タブに移動します。ここには、すべてのクライアン
27
トが⼀覧表⽰されます。リストの上部には、リストをフィルタリングするためのさまざまなオプションが⽤意されていま
す。
このリストは、ホスト名、クライアント名、IP アドレス、それにデプロイされた App 数、前回のデプロイサーバーとの
通信時刻などの、各クライアントに関する情報を提供しています。⾏の左側にある⽮印をクリックすると、クライアント
のその他の情報を参照することができます。
このリストには、[レコードの削除 ] アクションも⽤意されています。このアクションは、⼀時的にクライアントのレ
コードをデプロイサーバーから削除します。次回クライアントがデプロイサーバーと通信した時点で、レコードは再度⽣
成されます。このアクションがクライアント⾃体に影響することはありません。
⾼度な設定
serverclass.conf を使ったサーバークラスの定義
必要に応じて、フォワーダー管理インターフェイスを使⽤する代わりに serverclass.conf 設定ファイルを直接編集して、
サーバークラスを定義することができます。フォワーダー管理は可能な設定の⼀部にのみ対応しているため、⾼度な設定
を⾏う場合は serverclass.conf の編集が必要なこともあります。フォワーダー管理を使って設定作業を開始した後、より
⾼度な設定を利⽤するために設定ファイルの直接編集に切り替えることもできます。
重要： serverclass.conf を直接編集する場合、その後はフォワーダー管理インターフェイスを使って設定作業を⾏えなく
なる可能性が⾼くなります。これは、フォワーダー管理インターフェイスは、serverclass.conf を使って可能な設定の⼀
部のみしか処理できないためです。フォワーダー管理と互換性がある設定については、「互換性とフォワーダー管理」を参
照してください。
serverclass.conf の場所
serverclass.conf ファイルは、デプロイサーバー上の $SPLUNK_HOME/etc/system/local に作成します。以前にフォワー
ダー管理インターフェイスを使って 1 つ以上のサーバークラスを定義している場合、このファイルはすでに存在している
ため、単純にファイルの編集または追加作業を⾏います。serverclass.conf の詳細は、「serverclass.conf ファイル」を
参照してください。
サーバークラスに対して設定できる項⽬
重要な設定の⼤半は、各サーバークラスに対する⼀連のデプロイクライアントおよび⼀連の App を定義するものです。
⼤部分の属性は、3 種類の任意のスタンザレベルに設定することができます。
スタンザレベル
設定はグローバルレベル、個別のサーバークラスレベル、またはサーバークラス内の App レベルで設定を指定すること
ができます。そのために、3 種類のレベルのスタンザが存在しています。
スタンザ
[global]
[serverClass:<serverClassName>]
意味
グローバルレベル。
ここに定義された属性は、すべてのサーバー
クラスに関連しています。
個別のサーバークラ
ス。
ここに定義された属性は、サーバークラス
<serverClassName> に関連しています。
各サーバークラスにそ
れぞれ 1 つずつ、複数
の serverClass スタン
ザを設定することがで
きます。
注意： <serverClassName> にスペースを含め
ることはできません。ま
た、<serverClassName> はすべての
serverclass.conf ファイルにまたがって
⼀意でなければなりません。
指定サーバークラス内
の App。これを使っ
て、サーバークラスが
適⽤する App を指定
することができます。
[serverClass:<serverClassName>:app:<appName>]
対象
サーバークラス内の各
App に対して 1 つず
つ、このタイプのスタ
ンザを複数指定するこ
とができます。
には単⼀の App 名 (通常
は、repositoryLocation 内のその App の
ディレクトリ名)、または repositoryLocation
内のすべての App を指定する場合はワイル
ドカード⽂字「*」を指定できます。
<appname>
ここに定義された属性は、<serverClassName>
内の指定したデプロイ App <appName> にのみ
関連しています。
serverclass.conf 仕様ファイルに特に明記されていない限り、属性は各スタンザレベルで定義することができます。
28
より詳細なレベルのスタンザが、それより範囲の広いスタンザより優先されます。そのた
め、[serverClass:<serverClassName>] スタンザに定義されている属性は、[global] スタンザに定義されている同じ属性よ
りも優先されます。
クライアントフィルタリング属性
もっとも⼀般的な属性は、クライアントフィルタリングを設定するものです。これらの属性の詳細は、「クライアント
フィルタの設定」を参照してください。
⾮フィルタリング属性
⾮フィルタリング属性の⼤半が、デフォルト値から変更されることはほとんどありません。特に注⽬できるような属性を
以下に⽰します。
その⽬的
属性
デフォルト
repositoryLocation デプロイサーバー上の、このサーバークラスでデプロイするコンテンツの保
管場所。
$SPLUNK_HOME/etc
/deployment-apps
stateOnClient
「enabled」、「disabled」、または「noop」を設定します。この設定は、
enabled
App を受信するデプロイクライアントが、App をインストール後それを有
効にするか (enable)、または無効にするか (disable) を指定します。
「noop」は、有効化の必要がない App に対して指定します。たとえば、イ
ベントやソースタイプのみを含む App がこれに該当します。
restartSplunkWeb
「true」または「false」を設定します。更新の受信後に、クライアントの
Splunk Web を再起動するかどうかを⽰します。
false
restartSplunkd
「true」または「false」を設定します。更新の受信後に、クライアントの
splunkd を再起動するかどうかを⽰します。
false
issueReload
「true」または「false」を設定します。更新の受信後に、クライアントの
splunkd を再読み込みするかどうかを⽰します。
false
注意：特定の設定ファイルで利⽤できる設定の完全な⼀覧は、設定ファイルの .spec ファイルに記載されていま
す。serverclass.conf のための .spec および .example ファイルの最新版については、『管理マニュアル』の「設定ファイル
リファレンス」の serverclass.conf、または $SPLUNK_HOME/etc/system/README を参照してください。
restartSplunkd と issueReload の相互作⽤
クライアントの動作は restartSplunkd と issueReload の設定によって異なります。オプションを以下に⽰します。
issueReload restartSplunkd
動作
true
false
再読み込みのみ。再起動なし。ダウンロードしたAppを完全にアクティブにす
るには、⼿動で再起動を実⾏しなければならない場合があります。
true
true
クライアントの再読み込み。⼀部の App コンポーネントをアクティブにする
ために再起動が必要な場合、クライアントが再起動します。
false
false
ダウンロードした App はアクティブになっていません。
false
true
App が更新されると、クライアントは必ず再起動します。
これらの設定はサーバークラス単位でカスタマイズ可能です。
例
設定の簡単な例については、「クライアントフィルタの設定」を参照してください。また、このマニュア
ルの後半では、より⾧く複雑な例も記載されています。
serverclass.conf
デプロイサーバーの再ロード
変更内容を有効にするには、サーバークラスの追加または変更後、デプロイサーバーを再ロードする必要があります。た
とえば、サーバークラスに App を追加した場合、デプロイサーバーを再ロードした後にのみ、新しい App がサーバーク
ラスに対応するクライアントにデプロイされます。同様に、サーバークラスのクライアントフィルタを変更した場合、そ
のクライアントセットの変更 (およびそれ以降の App のデプロイ) は、再ロード後にのみ有効になります。
デプロイサーバーを再ロードするには、CLI コマンドの
reload deploy-server
を実⾏します。
splunk reload deploy-server
デプロイサーバーの再ロードの詳細は、「クライアントへの App のデプロイ」を参照してください。
29
互換性とフォワーダー管理
フォワーダー管理は、デプロイサーバーの設定ニーズの⼤半に対応することができます。ただし、複雑な設定要件がある
場合は、serverclass.conf を編集する必要があります。
すべての設定作業どちらかの⽅法 (フォワーダー管理または serverclass.conf の直接編集) のみを使って⾏う場合は、こ
のトピックはスキップしても構いません。フォワーダー管理と設定ファイルの編集間で設定⽅法を切り替える、または両
⽅の⼿段を利⽤する場合は、互換性に関する問題が発⽣する可能性があります。
serverclass.conf
を直接設定する⽅法については、「serverclass.conf を使ったサーバークラスの定義」を参照してくだ
さい。
互換性は⽚⽅向
フォワーダー管理インターフェイスでは、serverclass.conf で利⽤できる設定の主要な項⽬のみを利⽤できます。⼤部分
の設定ニーズでは、フォワーダー管理で⼗分に対処できます。
複雑な設定要件がある場合は、まずフォワーダー管理で設定を開始した後、serverclass.conf を編集して⾼度な設定を⾏
えます。ただし、設定ファイルを直接編集すると、その後フォワーダー管理インターフェイスを使って編集作業を⾏えな
い可能性が⾼くなります。これは、フォワーダー管理インターフェイスは、設定ファイルを使って利⽤できる機能の⼀部
のみをサポートしているためです。
の編集後にフォワーダー管理を利⽤した場合、フォワーダー管理は互換性がないことを検出して、イン
ターフェイス内の適切な場所にエラーメッセージを表⽰します。互換性がない項⽬がある限り、フォワーダー管理イン
ターフェイスを使って設定を⾏うことはできません。
serverclass.conf
このインターフェイスを使って設定を⾏うことができない場合でも、デプロイ状況の監視に利⽤することは可能です。
App、クライアント、およびサーバークラス間の関係を正常に表⽰することができます。また、デプロイの測定基準も正
しく報告されます。
6.0 より前のデプロイサーバーからのアップグレード
6.0 より前 (フォワーダー管理インターフェイス導⼊前) の Splunk Enterprise で serverclass.conf を設定した場合、
6.0 にアップグレードした後にフォワーダー管理インターフェイスが正常に動作しない互換性上の問題が発⽣する可能性
があります。フォワーダー管理インターフェイスを最初に表⽰した場合、互換性のない項⽬が存在しているかどうかが
チェックされ、必要に応じてエラーメッセージが表⽰されます。互換性がない項⽬がある限り、フォワーダー管理を使っ
て設定を⾏うことはできません。
互換性がない項⽬が検出されたけれどもフォワーダー管理インターフェイスを使⽤したい場合は、以下のいずれかの作業
を⾏う必要があります。
既存の serverclass.conf ファイルを削除してから、フォワーダー管理インターフェイスを開始して、サーバー·クラ
スや他の設定を作成し直す。
既存の serverclass.conf ファイルを直接編集して、フォワーダー管理インターフェイスの機能に厳密に対応できる
ように修正する。たいていの場合は、この⽅法は可能です。この⽅法を利⽤する場合は、以降のセクションを参考
に、主な互換性のない項⽬のリストを確認してください。
重要：設定にフォワーダー管理を利⽤できるかどうかは、そのニーズによって異なります。
互換性のない項⽬⼀覧
⼀部の serverclass.conf の属性は、フォワーダー管理インターフェイスと互換性がありません。また、⼀部の属性は設定
ファイル内では複数のレベル (グローバル、サーバークラス、および App) に設定することができますが、フォワーダー
管理の場合は単⼀のレベルにしか設定できません。
ファイルに互換性のない設定が存在する場合、フォワーダー管理はロックダウンモードに移⾏します。
互換性の問題を解決しない限り、設定に利⽤することはできません。
serverclass.conf
serverclass.conf
の属性と、それがフォワーダー管理でサポートされているかどうかを以下の表に⽰します。
デフォルト
属性
repositoryLocation
$SPLUNK_HOME/etc/deployment-apps
targetRepositoryLocation $SPLUNK_HOME/etc/apps
30
グ
ロー
バル
サー
バー
クラ
ス
App
サ
ポー
ト
⾮サ
ポー
ト
N/A
⾮サ
ポー
ト
N/A
N/A
tmpFolder
$SPLUNK_HOME/var/run/tmp
⾮サ
ポー
ト
N/A
N/A
continueMatching
True
⾮サ
ポー
ト
⾮サ
ポー
ト
N/A
endpoint
$deploymentServerUri$/services/streams/deployment?
name=$serverClassName$:$appName$
⾮サ
ポー
ト
⾮サ
ポー
ト
N/A
filterType
whitelist (フォワーダー管理は暗黙的にこのデフォルト値を使
⽤)
⾮サ
ポー
ト
⾮サ
ポー
ト
⾮サ
ポー
ト
ホワイトリスト
なし
⾮サ
ポー
ト
サ
ポー
ト
⾮サ
ポー
ト
ブラックリスト
なし
⾮サ
ポー
ト
サ
ポー
ト
⾮サ
ポー
ト
whitelist.from_pathname
なし
⾮サ
ポー
ト
サ
ポー
ト
⾮サ
ポー
ト
blacklist.from_pathname
なし
⾮サ
ポー
ト
サ
ポー
ト
⾮サ
ポー
ト
machineTypesFilter
なし
⾮サ
ポー
ト
サ
ポー
ト
⾮サ
ポー
ト
有効
⾮サ
ポー
ト
すべての
サーバーク
ラスにまた
がって、単
⼀の App
単位設定
stateOnClient
restartSplunkd
False
⾮サ
ポー
ト
すべての
サーバーク
ラスにまた
がって、単
⼀の App
単位設定
issueReload
False
⾮サ
ポー
ト
⾮サ
ポー
ト
⾮サ
ポー
ト
restartSplunkWeb
False
⾮サ
ポー
ト
⾮サ
ポー
ト
⾮サ
ポー
ト
appFile
なし
N/A
N/A
⾮サ
ポー
ト
表中の項⽬に関する注意点：
n/a：これは、serverclass.conf内で属性をそのレベルには設定できないことを意味しています。
全サーバークラス内のシングルアプリ単位設定：stateOnClient 属性と restartSplunkd 属性は、App レベルのス
タンザで設定されます。App レベルのスタンザには、appName と serverClassName コンポーネントが含まれま
す。[serverClass::app:]のようになります「serverclass.conf を使ったサーバークラスの定義」を参照してくださ
い。
フォワーダー管理を使⽤していない場合、同じ App であっても、サーバークラスによってこれらの属性の設定を
変えることができます。例えば、[serverClass:X:app:A] では stateOnClient=enabled と指定しなが
31
ら、[serverClass:Y:app:A] (同じ App、異なるサーバークラス) では、stateOnClient=disabled と指定することでき
ます。そのため、同じ App がサーバークラス次第で、クライアントにダウンロードされた時に有効にも無効にも
なります。
しかしフォワーダー管理では、管理されるすべてのサーバークラスにおいて、各 App に⼀種類の定義しか定められ
ません。そのため、[serverClass:X:app:A] と [serverClass:Y:app:A] はいずれも stateOnClient に同じ設定を⾏う必
要があります。同様の条件は restartSplunkd にもあてはまります。
例
例：複数のフォワーダーへの設定のデプロイ
ここの⽬的
デプロイサーバーの⼀般的な利⽤法は、フォワーダーの設定ファイルを管理することです。分散環境によっては、フォ
ワーダー数が数千台に上ることもあり、そのような場合にデプロイサーバーを利⽤することで、設定および更新作業を簡
素化することができます。この例では、デプロイサーバーを使って⼀連の異なるユニバーサルフォワーダーのセットの、
初期設定を実施する⽅法を表しています。その後のフォローアップ例となる「例：フォワーダーへの⼊⼒の追加」では、デ
プロイサーバーを使って新しい⼊⼒を持つフォワーダー設定で更新する⽅法を取り上げています。
この例では、2 台のインデクサーにデータを送信する 3 台のユニバーサルフォワーダーにデプロイサーバーが設定をデ
プロイする、以下の分散環境を想定しています。
デプロイサーバー Fflanda-SPLUNK3 (10.1.2.4) が、以下のユニバーサルフォワーダーのデプロイを管理して
います。
Fflanda-WIN1
Fflanda-LINUX1
Fflanda-LINUX2
Fflanda-WIN1 は、Windows イベントログをインデクサー Fflanda-SPLUNK1 (10.1.2.2) に転送します。
Fflanda-LINUX1 および Fflanda-LINUX2 は、Linux メッセージをインデクサー Fflanda-SPLUNK2
(10.1.2.3) に転送します。
フォワーダーはデプロイクライアントで、デプロイサーバーから設定ファイルを受信します。
基本的な設定を以下に⽰します。
ユニバーサルフォワーダーも含めたフォワーダーの詳細は、『データの転送』マニュアルの「転送と受信について」を参照し
てください。
Windows イベントログデータの監視については、『データの取り込み』マニュアルの「Windows イベントログデータの
32
監視」を参照してください。
メッセージログなどのファイルの監視については、『データの取り込み』マニュアルの「ファイルとディレクトリの監視」を
参照してください。
設定の概要
設定処理の概要を以下に⽰します (詳細なステップは次のセクションで説明します)。
フォワーダーからデータを受信する各インデクサー上で：
1.CLI を使って、受信を有効にします。
2.インデクサーを再起動します。
各デプロイクライアント (フォワーダー ) 上で：
1.デプロイサーバーを指す
deploymentclient.conf
ファイルを作成します。
2.フォワーダーを再起動します。
デプロイサーバー上で：
1.デプロイ App のディレクトリを作成します。
2.フォワーダー管理を使って、デプロイクライアント (フォワーダー) ⽤の⼀連のサーバークラスを作成します。2 種類
の OS (Windows、Linux) を表す、 2 つのサーバークラスを作成します。各サーバークラスは、⼀連のクライアント
を 2 つの個別の App にマップします (合計で 4 つの App)。後のステップで定義するこれらの App には、以下のもの
が含まれています。
⼊⼒のタイプ - ユニバーサルフォワーダーが監視するデータ (Windows イベントログまたは Linux メッセー
ジ)。
出⼒のタイプ - フォワーダーがデータを送信するインデクサー (SPLUNK1 または SPLUNK2)。
この設定により、サーバークラスに所属する各ユニバーサルフォワーダーが、その⼊⼒と出⼒から 1 つずつ、合計 2 つ
の App を受信します。
注意：「serverclass.conf でのサーバークラスの設定」で説明しているように、直接
バークラスを作成することもできます。
3.App ディレクトリに、App のコンテンツを保管します。各 App は、設定ファイル
から成り⽴っています。
serverclass.conf
outputs.conf
を編集してサー
または
inputs.conf
4.デプロイサーバーを再ロードして、App をデプロイします。
短時間経過後に (フォワーダーがデプロイコンテンツを受信し、処理する間)、Fflanda-WIN1 から FflandaSPLUNK1 に Windows イベントログの送信が開始され、また /var/log/messages が Fflanda-LINUX1 および
Fflanda-LINUX2 から Fflanda-SPLUNK2 への送信も開始されます。
詳細な設定⼿順
受信する各インデクサーに対して (Fflanda-SPLUNK1 および Fflanda-SPLUNK2)：
1.インデクサーを配備するマシン上に Splunk Enterprise をインストールします。
2.以下の CLI コマンドを実⾏します。
splunk enable listen 9997 -auth <username>:<password>
これは、インデクサーがレシーバーとして動作し、ポート 9997 でデータを待機することを⽰しています。適切な権限が
ある任意のフォワーダーが、IP アドレスとポート番号を指定して、レシーバーにデータを送信できます。フォワーダー
がレシーバーにデータを送信するように設定する前に、インデクサーをレシーバーとして有効にする必要があります。
レシーバーを有効にする⽅法については、『データの転送』マニュアルの「レシーバーを有効にする」を参照してください。
3.インデクサーを再起動します。
各ユニバーサルフォワーダーに対して (Fflanda-WIN1、 Fflanda-LINUX1、および Fflanda-LINUX2)：
1.⽬的のマシンにフォワーダーをインストールします (まだそうしていない場合)。
2.フォワーダーが通信するデプロイサーバーを指定します。この作業はフォワーダーのインストールプロセスの⼀環とし
て、またはインストール後に⾏うことができます。$SPLUNK_HOME/etc/system/local/deploymentclient.conf を以下のように
編集してください。
33
[deployment-client]
[target-broker:deploymentServer]
# Specify the deployment server; for example, "10.1.2.4:8089".
targetUri= <URI:port>
このファイルの設定⽅法の詳細は、「デプロイクライアントの設定」を参照してください。インストール時のデプロイサー
バーの指定⽅法については、『データの転送』マニュアルの「ユニバーサルフォワーダーのデプロイの概要」およびそれ以降
のトピックを参照してください。
3.フォワーダーを再起動します。
デプロイサーバー上で (Fflanda-SPLUNK3)：
A. デプロイサーバーの準備
1.まだインストールしていない場合は、Splunk Enterprise をインストールします。
2.以下のデプロイ App ディレクトリを作成します。
$SPLUNK_HOME/etc/deployment-apps/fwd_to_splunk1
$SPLUNK_HOME/etc/deployment-apps/fwd_to_splunk2
$SPLUNK_HOME/etc/deployment-apps/winevt
$SPLUNK_HOME/etc/deployment-apps/linmess
「fwd_to_splunk1」、「fwd_to_splunk2」などのように、ディレクトリ名が App 名になります。
B. Windo ws フォワーダー⽤のサーバークラスの設定
注意：この⼿順とその次の⼿順では、両⽅ともフォワーダー管理を使ってサーバークラスを設定します。これらのサー
バークラスを、serverclass.conf を直接編集して設定する例については、後述する「serverclass.conf でのサーバーク
ラスの設定」を参照してください。
Windows フォワーダー⽤に
います。
Fflanda-WIN
サーバークラスを設定するには、フォワーダー管理に移動して以下の作業を⾏
1.[サーバークラス ] タブを選択します。
2.[新しいサーバークラス ] ボタンを選択します。
3.ポップアップウィンドウの [タイトル ] フィールドに Fflanda-WIN と⼊⼒し、[保存 ] をクリックします。画⾯に App
とクライアントの追加を指⽰するメッセージが表⽰されます。
4.[App の追加 ] ボタンをクリックします。[App の編集 ] ページに移動します。このページには、[選択解除された
App] と [選択された App] の 2 つの列があり、それぞれに対応する App が⼀覧表⽰されています。新しいサーバー
クラスの場合、当初はすべての App が［選択解除された App］列に表⽰されます。
5.［選択解除された App］列で、App winevt および
て、［選択された App］列に移動します。
fwd_to_splunk1
を探します。これらの App をクリックし
6.[保存 ] をクリックして、サーバークラスに App を保存します。サーバークラスにクライアントを追加するように指⽰
するメッセージが表⽰されます。[クライアントの追加 ] ボタンをクリックします。[クライアントの編集 ] ページに移
動します。
7.すべての Windows クライアントを含めるフィルタを設定するために、[含める ] フィールドに
し、[保存 ] をクリックします。
Fflanda-WIN*
と⼊⼒
8.App のデプロイ後の動作を設定します。各 App に対して、[App] タブに移動してその App に対応する⾏を探
し、[編集 ] アクションをクリックします。ページの上部にある [インストール後 ] セクションで、[App を有効にする ]
および [Splunkd の再起動 ] を選択します。
C. Linux フォワーダー⽤のサーバークラスの設定
Linux フォワーダー⽤に
以下の作業を⾏います。
Fflanda-LINUX
サーバークラスを設定するには、フォワーダー管理インターフェイスに移動して
1.[サーバークラス ] タブを選択します。
2.[新しいサーバークラス ] ボタンを選択します。
3.ポップアップウィンドウの [タイトル ] フィールドに Fflanda-LINUX と⼊⼒し、[保存 ] をクリックします。画⾯に
App とクライアントの追加を指⽰するメッセージが表⽰されます。
34
4.[App の追加 ] ボタンをクリックします。
5.［選択解除された App］列で、App linmess および
て、［選択された App］列に移動します。
fwd_to_splunk2
を探します。これらの App をクリックし
6.[保存 ] をクリックして、サーバークラスに App を保存します。サーバークラスにクライアントを追加するように指⽰
するメッセージが表⽰されます。[クライアントの追加 ] ボタンをクリックします。[クライアントの編集 ] ページに移
動します。
7.すべての Linux クライアントを含めるフィルタを設定するために、[含める ] フィールドに
し、[保存 ] をクリックします。
Fflanda-LINUX*
と⼊⼒
8.App のデプロイ後の動作を設定します。各 App に対して、[App] タブに移動してその App に対応する⾏を探
し、[編集 ] アクションをクリックします。ページの上部にある [インストール後 ] セクションで、[App を有効にする ]
および [Splunkd の再起動 ] を選択します。
フォワーダー管理インターフェイスの詳細は、「フォワーダー管理を使ったサーバークラスの定義」を参照してください。
D. App の保管
1.以下の設定で
$SPLUNK_HOME/etc/deployment-apps/fwd_to_splunk1/default/outputs.conf
を作成します。
[tcpout]
defaultGroup=splunk1
[tcpout:splunk1]
# Specifies the server that receives data from the forwarder.
server=10.1.2.2:9997
outputs.conf
の詳細は、『データの転送』マニュアルの「outputs.conf によるフォワーダーの設定」を参照してください。
2.以下の設定で
$SPLUNK_HOME/etc/deployment-apps/fwd_to_splunk2/default/outputs.conf
を作成します。
[tcpout]
defaultGroup=splunk2
[tcpout:splunk2]
server=10.1.2.3:9997
3.以下の設定で
$SPLUNK_HOME/etc/deployment-apps/winevt/default/inputs.conf
を作成します。
[WinEventLog:Application]
disabled=0
[WinEventLog:Security]
disabled=0
[WinEventLog:System]
disabled=0
Windows イベントログデータの監視については、『データの取り込み』マニュアルの「Windows イベントログデータの
監視」を参照してください。
4.以下の設定で
$SPLUNK_HOME/etc/deployment-apps/linmess/default/inputs.conf
を作成します。
[monitor:///var/log/messages]
disabled=false
sourcetype=syslog
メッセージログなどのファイルの監視については、『データの取り込み』マニュアルの「ファイルとディレクトリの監視」を
参照してください。
E. App のデプロイ
App をデプロイするには、デプロイサーバーを再ロードします。
splunk reload deploy-server
各フォワーダーがデプロイサーバーにポーリングし、設定ファイルをダウンロードして、再起動します。その後、インデ
35
クサーに対してデータの転送が開始されます。
注意： App のコンテンツを変更した場合は常に、reload コマンドを実⾏して、クライアントに新しいコンテンツの存在
を知らせる必要があります。
デプロイサーバーを使ったフォワーダー設定の更新⽅法の例は、「例：フォワーダーへの⼊⼒の追加」を参照してくださ
い。
serverclass.conf によるサーバークラスの設定
フォワーダー管理を使ってサーバークラスを設定する代わりに、直接 serverclass.conf を編集することができます。ただ
し、たいていの場合は、フォワーダー管理を使⽤する⽅が⼿軽で簡単です。
ここで取り上げている例の場合、必要なサーバークラスすべてをフォワーダー管理を使って定義できるた
め、serverclass.conf を編集する必要はありません。ただし、直接設定ファイルを編集したい⽅のために、ここでは
serverclass.conf を編集して⼀連のサーバークラスを作成する⽅法を説明していきます。この例では、serverclass.conf
を直接編集することでのみ可能になる、いくつかの最適化⽅法も利⽤しています。
以下の設定で
$SPLUNK_HOME/etc/system/local/serverclass.conf
を作成します。
# Global server class
[global]
# Filter (whitelist) all clients
whitelist.0=*
# Server class for Windows
[serverClass:Fflanda-WIN]
# Filter (whitelist) all Windows clients
whitelist.0=Fflanda-WIN*
# App for inputting Windows event logs
# This app is only for clients in the server class Fflanda-WIN
[serverClass:Fflanda-WIN:app:winevt]
#Enable the app and restart Splunk, after the client receives the app
stateOnClient=enabled
restartSplunkd=true
# App for forwarding to SPLUNK1
# This app is only for clients in the server class Fflanda-WIN
[serverClass:Fflanda-WIN:app:fwd_to_splunk1]
stateOnClient=enabled
restartSplunkd=true
# Server class for Linux
[serverClass:Fflanda-LINUX]
# Filter (whitelist) all Linux clients
whitelist.0=Fflanda-LINUX*
# App for inputting Linux messages
# This app is only for clients in the server class Fflanda-LINUX
[serverClass:Fflanda-LINUX:app:linmess]
stateOnClient=enabled
restartSplunkd=true
# App for forwarding to SPLUNK2
# This app is only for clients in the server class Fflanda-LINUX
[serverClass:Fflanda-LINUX:app:fwd_to_splunk2]
stateOnClient=enabled
restartSplunkd=true
このファイルの設定⽅法の詳細は、「serverclass.conf を使ったサーバークラスの定義」を参照してください。
デプロイサーバーとクライアントの通信
前述の例を使った Fflanda-WIN1 から Fflanda-SPLUNK3 へのポート 8089 での通信は、以下のように⾏われま
す。
Fflanda-WIN1：こんにちは、こちらは Fflanda-WIN1 です。
Fflanda-SPLUNK3：こんにちは、Fflanda-WIN1。連絡をお待ちしておりました。あなたは Fflanda-WIN サー
バークラスのメンバーとなっています。fwd_to_splunk1 (チェックサム=12345) と winevt (チェックサム
=12378) をお持ちですね。
36
Fflanda-WIN1：うーん、それらの設定は持っていません。この接続を使って設定を⼿に⼊れたいのですが？
Fflanda-SPLUNK3：いいですよ！今すぐ⽤意します。
Fflanda-WIN1：ありがとうございます！他のクライアントも問い合わせたいでしょうから、ランダムに 1∼60 秒間
待機してから、再び連絡します。よし、ではファイルを送信してください。
Fflanda-SPLUNK3：完了しました！これで fwd_to_splunk1-timestamp.bundle と winevttimestamp.bundle をお持ちですね。
Fflanda-WIN1：すごい、ありがとうございます！$SPLUNK_HOME/etc/apps ディレクトリに⼤切に保管しま
す。さて、私は再起動を⾏います。処理が完了したら、いただいた tar 形式の .bundle ファイルから設定を読み込みま
す。
数分後...
Fflanda-WIN1：こんにちは、こちらは Fflanda-WIN1 です。
Fflanda-SPLUNK3：こんにちは、Fflanda-WIN1。連絡をお待ちしておりました。あなたは Fflanda-WIN サー
バークラスのメンバーとなっています。fwd_to_splunk1 (チェックサム=12345) と winevt (チェックサム
=12378) App をお持ちですね。
Fflanda-WIN1：どれどれ...はい、きちんと持っています。確認ありがとうございます。
その後管理者が Fflanda-SPLUNK3 上の winevt/inputs.conf ファイルを編集して、システムイベントログの収集を無効
にし、次に CLI コマンド splunk reload deploy-server を実⾏して、デプロイサーバーに serverclass.conf と App
ディレクトリを再確認させました。次回に Fflanda-WIN1 が Fflanda-SPLUNK3 に連絡する際には、以下のようなや
り取りが⾏われます。
Fflanda-WIN1：こんにちは、こちらは Fflanda-WIN1 です。
Fflanda-SPLUNK3：こんにちは、Fflanda-WIN1。連絡をお待ちしておりました。あなたは Fflanda-WIN サー
バークラスのメンバーとなっています。fwd_to_splunk1 (チェックサム=12345) と winevt (チェックサム
=13299) App をお持ちですね。
Fflanda-WIN1：うーん、これらの設定は持っていますが、私の持っている winevt のチェックサムはあなたの
winevt と違っているようです。この接続を使って更新された winevt 設定を⼿に⼊れたいのですが？
Fflanda-SPLUNK3：いいですよ！今すぐ⽤意します。
Fflanda-WIN1：ありがとうございます！他のクライアントも問い合わせたいでしょうから、ランダムに 1∼60 秒間
待機してから、再び連絡します。よし、では更新された設定を送信してください。
Fflanda-SPLUNK3：完了しました！これで winevt-newer_timestamp.bundle をお持ちですね。
Fflanda-WIN1：すごい、ありがとうございます！これを $SPLUNK_HOME/etc/apps ディレクトリに保管して、
現在保有している古い winevt.bundle はどこか邪魔にならない所に移動しておきます。これから⾃分を再起動して、最
新の設定を読み込みます。
例：フォワーダーへの⼊⼒の追加
前のトピック「例：複数のフォワーダーへの設定のデプロイ」では、⼀連のユニバーサルフォワーダーを管理するためのデ
プロイ環境の設定について説明しました。そこでは、コンテンツを⼀連の新たなデプロイクライアントにデプロイするた
めの、新しいデプロイサーバーの設定⽅法を説明しました。今回の例では、前回の作業の直後から始めて、そこで作成さ
れた設定を使⽤します。フォワーダー設定ファイルを更新する⽅法、および更新したファイルをサーバークラスで定義し
た、フォワーダーのサブセットにデプロイする⽅法について説明していきます。
更新プロセスの概要
この例は、「例：複数のフォワーダーへの設定のデプロイ」で作成した、⼀連の設定と Splunk Enterprise インスタンス
を使⽤します。その後 Linux ユニバーサルフォワーダーは、2 番⽬のソースからのデータも監視する必要がでてきまし
た。そのためには、デプロイサーバー上で以下の作業を⾏います。
1. inputs.conf ファイルの Linux サーバークラスを編集して新しいソースを追加し、それを App ディレクトリ内の古い
バージョンに上書きします。
2.デプロイサーバーが変更を認識し、適切なクライアント (フォワーダー) にデプロイできるように、デプロイサーバー
を再ロードします。
変更はデプロイサーバー上でのみ⾏います。Linux サーバークラスに所属するデプロイクライアントが、次回にサーバー
にポーリングした時に、inputs.conf ファイルが変更されたことが通知されます。クライアントはファイルをダウンロー
ドして有効化し、splunkd を再起動することで、2 番⽬のデータソースの監視を開始します。
37
詳細な設定⼿順
デプロイサーバー上で：
1. $SPLUNK_HOME/etc/deployment-apps/linmess/default/inputs.conf を編集して、新たな⼊⼒を追加します。
[monitor:///var/log/messages]
disabled=false
sourcetype=syslog
[monitor:///var/log/httpd]
disabled=false
sourcetype = access_common
2.デプロイサーバーを再ロードします。
splunk reload deploy-server
このコマンドを実⾏したら、デプロイサーバーは Fflanda-LINUX サーバークラスのメンバーであるクライアントに、
ファイルの変更を知らせます。クライアントはファイルをダウンロードして有効化し、splunkd を再起動することで、2
番⽬のデータソースの監視を開始します。
38

Download Report