分散管理コンソールマニュアル

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
分散管理コンソールのセットアップ
分散管理コンソールについて
DMC の役割とは
DMC の仕組み
複数のインスタンスデプロイ DMC のセットアップ⼿順
単⼀インスタンスデプロイ DMC のセットアップ⼿順
コンソールを利⽤するインスタンス
DMC セットアップの前提条件
クラスタラベルの設定
インスタンスをサーチピアとして DMC に追加
スタンドアロンモードで DMC を設定
分散モードで DMC を設定
DMC にフォワーダーモニタリングを設定
プラットフォームアラート
3
3
3
4
5
5
5
7
8
9
9
9
10
10
DMC ダッシュボードレファレンス
サーチアクティビティ：インスタンス
サーチアクティビティ：デプロイ
サーチ使⽤統計ダッシュボード
スケジューラーアクティビティ
インデックス作成のパフォーマンス：インスタンス
インデックス作成のパフォーマンス：デプロイ
リソース使⽤状況：インスタンス
リソース使⽤状況：マシン
リソース使⽤状況：デプロイ
KV ストア：インスタンス
KV ストア：デプロイ
サーチヘッドクラスタリングダッシュボード
分散サーチダッシュボード
HTTP イベントコレクタダッシュボード
インデクサークラスタリング：ステータス
インデクサークラスタリング：サービスアクティビティ
インデックス作成：インデックスとボリュームのダッシュボード
フォワーダーダッシュボード
ライセンス
12
12
13
13
14
15
16
16
17
17
18
19
20
22
23
23
23
24
24
25
分散管理コンソールのセットアップ
分散管理コンソールについて
分散管理コンソールとは
分散管理コンソール (DMC) は Splunk Enterprise のモニタリングツールです。分散管理コンソール (DMC) によ
り、Splunk Enterprise のデプロイに関する詳細なトポロジーとパフォーマンス情報を参照することができます。
ダッシュボードを使⽤することで、デプロイまたはインスタンスに関する次の項⽬について確認できます。
サーチ性能と分散サーチフレームワーク
インデックス作成のパフォーマンス
オペレーティングシステムリソースの使⽤状況
Splunk App キーバリューストアパフォーマンス
サーチヘッドとインデクサークラスタリング
インデックスと容量の使⽤状況
フォワーダー接続と Splunk TCP パフォーマンス
HTTP イベントコレクタパフォーマンス
ライセンスの使⽤状況
DMC ダッシュボードは Splunk Enterprise の内部ログファイル (metrics.log など)のデータや Splunk
Enterprise プラットフォームの計測から⼊⼿できるデータを使⽤します。
分散管理コンソールへの移動
Splunk Web 内の任意の場所から[ 設定] をクリックし、左側にある分散管理コンソールのアイコンをクリックし
ます。
DMC は Splunk Enterprise の admin 権限を持つユーザーだけが閲覧できます。
DM C の役割とは
DMC の設定状態は⼤きく分けて3つあります。
Splunk Enterprise インスタンスでは、DMC をスタンドアロンモードで未設定のまま利⽤することができ
ます。この場合、デプロイでの各インスタンスで個別に DMC を利⽤して、そのインスタンスのパフォーマ
ンスを確認することができます。
スタンドアロンモードの場合も、設定⼿順を完了することでデフォルトのプラットフォームアラートを利⽤
できます。
分散モードの設定⼿順を完了することで、１つのインスタンスにログインし、デプロイでの各インスタンス
のパフォーマンス情報を参照することができます。
⼀般的な問題を解決する
DMC では、Splunk Enterprise のデプロイに関するトラブルシューティング情報が豊富に利⽤可能です。以下は
このツールを使⽤して調べられる問題の例です。
事象
ダッシュボード
最初に⾒るべき場所：
「ピア何々から応答がありません」、「ピアがサーチに参加
しません」、または「サーチが不完全な可能性があります」
のようなサーチ実⾏時のエラーの報告がユーザーからありま
す。
3
分散サーチ：デプロイの正常チェック、
または問題のあるサーチピアがわかってい
る場合は分散サーチ：インスタンス
リソース使⽤状況：デプロイで、サーチ
ピアを選択して取り込みすぎている情報が
ないか調べます。
す。
[分散サーチ ] および [リソース使⽤状況 ]
ビューで、問題が発⽣しそうな時間帯を⽐
較して、キャパシティプランニングを実施
してください。
ユーザーの UI の動きが遅いです。
問題のあるインスタンスのリソース使⽤状況：
インスタンス
サーチのスピードが遅いです。
リソース使⽤状況：デプロイ、スケジュー
ラーアクティビティ、またはスケサーチアク
ティビティ
インデクサー/サーチヘッドはいま稼働中でしょうか、それ
とも停⽌中でしょうか。
[ 概要] > [ トポロジー]
インデクサーのワークロードはインスタンスに等しく分散さ
れるのでしょうか。
インデックス作成のパフォーマンス：デプロ
イ
KV ストアが初期化をしません。
KV ストア：デプロイ
Splunk Web 上に、ディスクスペースが⼀杯とのエラーが
表⽰されています。
リソース使⽤状況：マシンまたはインデック
スとボリュームダッシュボード
DM C の仕組み
ここでは、分散管理コンソールが Splunk Enterprise ファイルシステムで変更するファイル⼀覧を表⽰します。
これらのファイルは、特に明記されていない限り$SPLUNK_HOME/etc/apps/splunk_management_console/ にあります。
ファイル
そこで⾒つかる DMC の情報
設定される
時期
DMC についての基本情報：分散モードかどう
か、および Splunk Web を使⽤するための簡単
な説明。app.conf.spec を参照してください。
デフォルト
etc/system/local の中の distsearch.conf
DMC が作成した分散サーチグループを参照する
スタンザが含まれます。通常、これらのグループ
名は「dmc_group_*」から始まります。
例：[distributedSearch:dmc_group_cluster_master]。
DMC の
セットアッ
プで分散
モードに切
り替えると
きは、 [変
更の適⽤ ]
をクリック
します。
dmc_alerts.conf
場合によっては、アラートのためのサーチ⽂字列
を直接変更せずに、プラットフォームアラートの
閾値を編集することもできます。そのようなア
ラートに対して、DMC ではサーチ⽂字列、記述
⽂字列、編集可能なパラメータのテンプレートが
利⽤できます。 DMC の [アラート設定 ] ページ
で使⽤されるこのテンプレートデータは、
default/savedsearches.conf の中の保存済み
サーチの名前からつけられたスタンザに保管され
ます。
デフォルト
app.conf
2 つの重要なファイルが含まれています。
Lookups ディレクトリ
assets.csv で⼀覧化されているのは、DMC
が認識するインスタンスとそのピア URI (⼀
意の名前)、サーバー名、ホスト、マシン
(ホストの fqdn)、サーチグループ (サー
バーロール、カスタムグループまたはクラ
スタ) です。この csv ファイルはすべての
DMC ダッシュボードで使⽤されます。
dmc_forwarder_assets.csv はフォワー
ダーモニタリングを有効にした時に⽣成さ
れます。フォワーダーモニタリングを有効
にすると、savedsearches.conf の中の保
存済みサーチ (「DMC フォワーダー - ア
セットテーブルの作成」) が有効になり、こ
の csv ファイルに値が挿⼊されます。この
マニュアルの「DMC にフォワーダーモニ
タリングを設定」を参照してください。
2 種類の重要なマクロが含まれています。
4
デフォルト
(初期起動
時)[変更の
適⽤ ] のク
リック時ま
たは [フォ
ワーダーア
セットの再
構築 ] のク
リック時に
それぞれ更
新されま
す。
サーチマク
ロはデフォ
ルトでここ
に保管され
ます。
macros.conf
すべての DMC ダッシュボードのための
サーチマクロ
[概要 ] ページのカスタマイズは、[分散管
理コンソール ] > [設定 ] > [⼀般設定 ] で可
能です。
macros.conf.spec を参照してください。
ひとつの
サーチマク
ロを編集
し、[保存 ]
をクリック
した時にカ
スタマイズ
が完了しま
す。
props.conf
サーチ時フィールド抽出およびルックアップアプ
リケーションとevalprops.conf.spec を参照して
ください。
デフォルト
savedsearches.conf
プラットフォームアラートのためのスケジュール
およびサーチ⽂字列フォワーダーモニタリングを
有効にすると、「DMC フォワーダー - アセット
テーブルの作成」という保存済みサーチが実⾏さ
れます。
デフォルト
このファイルには以下が含まれます。
splunk_management_console_assets.conf
transforms.conf
DMC で設定したサーチピアとモニターを
無効化したサーチピアの⼀覧。
セットアップ中に⼿動で DMC により上書
きされたサーチピア識別⼦。たとえば、ホ
スト、host_fqdn、インデクサークラスタ
ラベル、サーチヘッドクラスタなど。
サーチピアがメンバーとなっているインデ
クサーとサーチヘッドクラスタを記述する
スタンザ。
[設定 ] >
[⼀般設定 ]
上で [変更
の適⽤] の
クリック
時。
assets.csv および forwarder.csv のためのルッ
クアップ定義
デフォルト
Dmc_alerts.conf および splunk_management_console_assets.conf の詳細について
は、$SPLUNK_HOME/etc/apps/splunk_management_console/README を参照してください。
複数のインスタンスデプロイ DM C のセットアップ⼿順
本トピックでは、Splunk Enterprise デプロイ全体をモニターする分散管理コンソール (DMC) のセットアップ⼿
順の概要について説明していきます。単⼀インスタンスのモニタリングを設定するには、このマニュアルの「単⼀
インスタンス DMC のセットアップ⼿順」を参照してください。
1.
2.
3.
4.
5.
6.
デプロイにDMCをホストするインスタンスを決定します。
内部ログの転送を含め、デプロイが前提条件を満たすようにしてください。
クラスタラベルの設定を⾏います。
インスタンスをサーチピアとして追加します。
分散モードのDMC のセットアップを⾏います。
DMC のフォワーダーダッシュボードを使⽤する場合は、フォワーダーモニタリングのセットアップを⾏い
ます。
7. 事前設定プラットフォームアラートを有効にします。
8. [概要 ] のためのカラーマッピングをカスタマイズします。[分散管理コンソール ] > [設定 ] > [⼀般設定 ] に
進みます。
単⼀インスタンスデプロイ DM C のセットアップ⼿順
本トピックでは、分散管理コンソール（DMC）をセットアップして単⼀の Splunk Enterprise インスタンスと
フォワーダーをモニターし、DMC のプラットフォームアラートを使⽤する⼿順の概要について説明していきま
す。Splunk Enterprise デプロイをモニターする DMC を設定するには、「複数インスタンスデプロイのセット
アップ⼿順」を参照してください。
1. インスタンスが前提条件を満たしているかどうかを確認します。
2. スタンドアロンモードで DMC をセットアップします。
3. DMC のフォワーダーダッシュボードを使⽤する場合は、フォワーダーモニタリングのセットアップを⾏い
ます。
4. 事前設定プラットフォームアラートを有効にします。
5. [概要 ] のためのカラーマッピングをカスタマイズします。[分散管理コンソール ] > [設定 ] > [⼀般設定 ] に
進みます。
コンソールを利⽤するインスタンス
本トピックでは、Splunk Enterprise のデプロイで分散管理コンソール (DMC) をセットアップするプロセスの⼿
順について説明していきます。上記の「分散管理コンソールについて」を参照してください。
DMC を分散モードに設定したら、デプロイの 1 つのインスタンスから、デプロイ全体のコンソール情報を参照す
ることができます。では、どのインスタンスで⾏うのでしょうか。
5
DMC をホストする場所については、さまざまなオプションがあります。選択するインスタンスは、サーチヘッド
として設定する必要があります。『キャパシティプランニング』マニュアルの「リファレンスハードウェア」を参
照してください。セキュリティおよびパフォーマンス上の理由から、このインスタンスには Splunk Enterprise
管理者のみがアクセスできるようにする必要があります。
重要: 単⼀のスタンドアロン型 Splunk Enterprise インスタンスの場合を除き、DMC をホストするインスタンス
は本番サーチヘッドとして使⽤せず、DMC の機能に関係のないサーチを実⾏をしないようにする必要がありま
す。
本表は、デプロイタイプに基づいて推奨される DMC の設定場所を説明するものです。
分散
モー
ド?
インデ
クサー
クラス
タリン
グ?
サーチ
ヘッド
クラス
タリン
グ?
DMC オプション
いい N/A
え
N/A
スタンドアロンインスタンス
はいいいえ
いいえ
ライセンスマスターまたは少数（<50）のクライアントを使⽤可能にするデプロイ
サーバーインスタンスの使⽤は DMC および特定の機能に限定されます。ライセンス
マスターとデプロイサーバーのいずれも利⽤できない場合は、他の⽬的で使⽤されて
いない専⽤サーチヘッドで DMC を実⾏します。
単⼀ク
ラスタ
関係な
し
マスターノード他の⽬的で使⽤されていない専⽤サーチヘッドで DMC を実⾏するこ
ともできます。
複数の
はいクラス
タ
関係な
し
クラスタ全体でサーチヘッドノードとして設定されているサーチヘッド。このサーチ
ヘッドは DMC の使⽤に限定する必要があります。
はいいいえ
はい
サーチヘッドクラスタデプロイヤー：他の⽬的で使⽤されていない専⽤サーチヘッド
で DMC を実⾏することもできます。サーチヘッドクラスタのメンバー上で DMC を
実⾏しないでください。
はい
単⼀のインデクサークラスタを構成するデプロイ：マスターノード
インデクサークラスタでは、(単⼀サイトまたはマルチサイトとも) クラスタマスターで DMC をホストします。
『インデクサーとクラスタの管理』マニュアルの「システム要件」を参照してください。
代案としては、クラスタのサーチヘッドノードで DMC をホストすることもできます。この場合、サーチヘッドを
使⽤して⾮ DMC サーチを実⾏することはできません。
複数のインデクサークラスタを構成するデプロイ：サーチヘッドノード
デプロイに複数のインデクサークラスタがあれば、各クラスタでサーチヘッドノードとして設定されたサーチヘッ
ドで DMC をホストします。このサーチヘッドを使⽤して⾮ DMC サーチを実⾏することはできません。
この操作を完了する主な⼿順は以下の通りです。
1. 各インデクサークラスタで、単⼀のサーチヘッドをノードとして設定します。『インデクサーとクラスタの管
理』マニュアルの「複数のインデクサークラスタでのサーチ」を参照してください。これがお使いの DMC インス
タンスです。
2. 各マスターノードおよびクラスタ内のすべてのサーチヘッドノードを DMC インスタンスのサーチピアとして設
定します。このマニュアルの「インスタンスをサーチピアとして追加」を参照してください。
警告：クラスタピアノード (インデクサー) をサーチピアとして DMC ノードに設定しないでください。これらは
インデクサークラスタのノードとして、DMC ノードなど、クラスタ内のすべてのサーチヘッドノードに認知され
ています。
⾮インデクサークラスタ環境でのオプション 1：ライセンスマスター上
以下の条件を満たしている場合、専⽤のライセンスマスター上にモニター⽤コンソールを設定することができま
す。
ライセンスマスターが、サーチ負荷に対応できるだけの処理能⼒を持っている (サーチヘッドのリファレン
スハードウェアの要件を満たしている、またはそれ以上である場合)。『キャパシティプランニング』マニュ
アルの「リファレンスハードウェア」を参照してください。
ライセンスマスターには、Splunk Enterprise の管理者のみがアクセスできます。
⾮インデクサークラスタ環境でのオプション 2：新しいインスタンス
別の⽅法としては、新しいインスタンスを⽤意し、それを各サーチヘッド⽤のサーチヘッド、および各インデク
サー⽤のサーチヘッドとして設定し、そこに DMC を分散モードで設定することができます。
6
サーチヘッドクラスタ環境
DMC をホストするには、デプロイヤーまたは専⽤のライセンスマスターを使⽤します。サーチヘッドクラスタメ
ンバー上に DMC を導⼊することはできません。App は起動時は、サーチヘッドクラスタメンバー上で無効化さ
れています。『分散サーチ』マニュアルの「サーチヘッドクラスタのシステム要件とデプロイに関する他の検討事
項」を参照してください。
サーチヘッドプーリング環境では、DMC はサポートされていません。
実働環境のサーチヘッド上でコンソールをホストしない理由
実働環境のサーチヘッド (⾃分のサーチや App を実⾏するサーチヘッド) として使⽤されていないインスタンス上
で DMC を設定すべき⼤きな理由は、DMC の分散サーチグループがデフォルトのサーチの挙動を変更する点にあ
ります。この変更により、ターケットとなるサーチピアの⼀覧に対して、DMC のダッシュボードサーチの範囲が
できるだけ絞り込まれます。
DMC を分散モードでセットアップした時、サーバーロール、識別されたクラスタ、またはカスタムグループに対
してサーチグループを 1 つ作成します。そして「splunk_server_group」または「splunk_server」オプション
を使⽤しない場合は、そのインデクサーのグループのメンバーであるピアのみがデフォルトでサーチされるように
なります。
DMC とデプロイサーバー
ほとんどの場合、デプロイサーバーに分散 DMC をホストすることはできません。デプロイサーバーが処理するデ
プロイクライアントの数が 50 以下の場合は例外となります。クライアントの数がこれよりも多いと、DMC とデ
プロイサーバーの機能が⼲渉し合う可能性があります。『Splunk Enterprise インスタンスの更新』マニュアルの
「デプロイサーバーのプロビジョニング」を参照してください。
DM C セットアップの前提条件
本トピックでは、Splunk Enterprise のデプロイ、または単⼀の Splunk Enterprise インスタンスのいずれか
に、分散管理コンソール (DMC) をセットアップするプロセスの⼿順について説明していきます。このマニュアル
の「分散管理コンソールについて」を参照してください。
この時点では既にデプロイでDMC をホストするインスタンスが決定されています。「クラスタラベルの設定」
(デプロイ⽤) 、または「スタンドアロンモードで DMC を設定」 (単⼀の Splunk Enterprise インスタンス⽤) に
進む前に、以下の前提条件が満たされているかどうか確認してください。
Splunk Enterprise のデプロイが正常に機能していること。『分散デプロイ』マニュアルの「分散 Splunk
Enterpriseの概要」を参照してください。
デプロイが正常、つまりすべてのピアが動作しているようにしてください。
デプロイの各インスタンス (サーチヘッドやライセンスマスターなど) に⼀意の server.conf の serverName 値
および inputs.conf の host 値があること。
プラットフォーム環境計測データは、モニターするすべての Splunk Enterprise インスタンス (フォワー
ダーを除く) に対して有効にする必要があります。インスタンスはすべてプラットフォーム環境計測データ
の要件を満たす必要があります。
各ノードが Splunk Enterprise 6.1 以降を実⾏していること。
プラットフォーム環境計測データが Windows、Linux、Solaris をサポートしていること。
他のすべてのインスタンスタイプからインデクサーに内部ログ ($SPLUNK_HOME/var/log/splunk
と$SPLUNK_HOME/var/log/introspection の両⽅) が転送されていること。ベストプラクティスとして『分散サー
チ』マニュアルの「サーチヘッドデータの転送」を参照してください。これを⾏わないと、多くのダッシュ
ボードでデータが不⾜することになります。他のインスタンスタイプには以下が挙げられます。
サーチヘッド
ライセンスマスター
クラスタマスター
デプロイサーバー
分散管理コンソールをセットアップするユーザーには、admin_all_objects 権限が必要です。
ダッシュボードバージョンの依存関係
7
分散管理コンソールのダッシュボードは、Splunk Enterprise の内部ログファイルとエンドポイントから収集した
データに依存します。データの多くは、Splunk Enterprise バージョン 6.1 で導⼊されたプラットフォーム環境計
測データから収集されます。さらにプラットフォーム環境計測データはその後のリリースを経て機能強化されてい
ます。たとえば、Splunk Enterprise 6.4.0 では iostats に対するログ機能が追加されました。次のテーブルは、
各機能とその導⼊バージョンをまとめたものです。
コンソールでモニターするインスタンスは、これらのバージョン要件を満たす必要があります。そうしない場合
は、ダッシュボードパネルがブランク表⽰されます。
ダッシュボード
パネル
システム要件
すべてのダッシュボード
多くのパネル
Splunk Enterprise 6.1
KV ストア：ダッシュボード
すべてのパネル
Splunk Enterprise 6.2.0 (この機能が導⼊さ
れたバージョン)
サーチヘッドクラスタリングダッ
シュボード
すべてのパネル
Splunk Enterprise 6.2.0
分散サーチダッシュボード
バンドルの複製処理⽤
のパネル
Splunk Enterprise 6.3.0
HTTP イベントコレクタダッシュ
ボード
すべてのパネル
Splunk Enterprise 6.3.0 (この機能が導⼊さ
れたバージョン)
スケジューラーダッシュボード
多くのパネル
Splunk Enterprise 6.3.0
リソース使⽤：マシン、リソース使
⽤：デプロイ
I/O パネル
Splunk Enterprise 6.4.0
クラスタラベルの設定
本トピックでは、Splunk Enterprise のデプロイで分散管理コンソールをセットアップするプロセスの⼿順につい
て説明していきます。上記の「分散管理コンソールについて」を参照してください。
関連付けられたインスタンスを DMC が特定できるよう、クラスタ (インデクサークラスタおよびサーチヘッドク
ラスタの両⽅) にラベルを設定します。この特定により、DMC はインデクサークラスタリングとサーチヘッドク
ラスタリングのダッシュボードを追加できるようになります。
クラスタのデプロイ中
クラスタの最初のデプロイ中にラベルを設定することが推奨されます。必要な場合は、ラベルを後で設定したり、
変更したりすることも可能です。
デプロイ中にインデクサークラスタのラベルを設定するには、「インデクサークラスタマスターノードを有効にす
る」を参照してください。
デプロイ中にサーチヘッドクラスタのラベルを設定するには、「サーチヘッドクラスタのデプロイ」を参照してく
ださい。
クラスタのデプロイ後
新しいクラスタをデプロイする場合は、デプロイ中にクラスタのラベルを設定することが推奨されます。ただし、
たとえばクラスタのアップグレードなど、クラスタが既にデプロイされている場合は、この表に従って DMC の
セットアップを開始する時にクラスタのレベルを設定します。
Splunk Ent erprise のバージョン、クラ
スタタイプ
場所
⽅法
6.3.0 以降のインデクサークラスタ
クラスタマスター上
以下を参照してください。
6.3.0 以前のインデクサークラスタ
DMC セットアップ
ページ上
クラスタ内のすべてのインスタンスにラ
ベルを設定
6.3.0 以降のインデクサークラスタのラベルをデプロイ後に設定するには、「ダッシュボードを使ったマスターの
設定」を参照するか、以下のクラスタマスターの CLI コマンドを使⽤します。
splunk edit cluster-config -cluster_label <CLUSTER LABEL>
Splunk Ent erprise のバージョン、クラ
スタタイプ
場所
⽅法
6.3.0 以降のサーチヘッドクラスタメンバー
すべての SHC メン
バー上
以下を参照してください。
6.3.0 以降のサーチヘッドクラスタデプロイ
ヤー
DMC セットアップ
ページ上
デプロイヤーインスタンスにラベルを設
定
6.3.0 以前のサーチヘッドクラスタ
DMC セットアップ
ページ上
クラスタ内のすべてのインスタンスにラ
ベルを設定
8
6.3.0 以降のサーチヘッドクラスタのラベルをデプロイ後に設定するには、「サーチヘッドクラスタの設定」を参
照するか、以下のクラスタマスターの CLI コマンドを使⽤します。
splunk edit shcluster-config -shcluster_label <CLUSTER LABEL>
どちらの⽅法でクラスタのラベルを編集する場合も、 DMC セットアップページで[変更の適⽤ ] をクリックし、
DMC のアセットテーブルを必ず更新してください。
DMC セットアップページの使⽤
Splunk Web で DMC セットアップページは [分散管理コンソール ] > [設定 ] > [⼀般設定 ] にあります。
クラスタのラベルを編集した後、右上の [変更の適⽤ ] をクリックしてください。
インスタンスをサーチピアとして DM C に追加
本トピックでは、Splunk Enterprise のデプロイで分散管理コンソールをセットアップするプロセスの⼿順につい
て説明していきます。上記の「分散管理コンソールについて」を参照してください。
1. 分散管理コンソールを設定するインスタンスにログインします。
2. Splunk Web で[ 設定] > [ 分散サーチ] > [ サーチピア] へと進みます。
3. [新規 ] をクリックします。
4. 必須⼊⼒フィールドに⼊⼒し、[保存 ] をクリックします。
5. 各サーチヘッド、デプロイサーバー、ライセンスマスター、⾮クラスタ構成のインデクサーに対して、⼿順 3
と 4 を繰り返してください。クラスタ構成インデクサーは追加しないでください。ただし、クラスタ構成サーチ
ヘッドは追加する必要があります。インデクサークラスタをモニタリングし、クラスタマスター以外のインスタン
スで DMC をホストしている場合は、クラスタマスターをサーチピアとして追加する必要があります。
DMC をセットアップするための次の⼿順は、「分散モードで DMC を設定」です。
スタンドアロンモードで DM C を設定
本トピックでは、スタンドアロンの Splunk Enterprise インスタンスで分散管理コンソール（DMC）をセット
アップするプロセスの⼿順について説明していきます。「単⼀インスタンス DMC のセットアップ⼿順」を参照し
てください。
設定⽅法：
1. Splunk Web で、[分散管理コンソール ] > [設定 ] > [⼀般設定 ] へと進みます。
2. [サーバーロール ] には、サーチヘッド、ライセンスマスター、インデクサー以外には何も⼀覧化されていない
ことを確認してください。そうでない場合は、[編集 ] をクリックします。
3. [変更の適⽤ ] をクリックして、セットアップを完了します。
DMC 設定の次の⼿順は、「フォワーダーモニタリングの設定」です。
分散モードで DM C を設定
本トピックでは、複数のインスタンスの Splunk Enterprise のデプロイで分散管理コンソール (DMC) をセット
アップするプロセスの⼿順について説明していきます。「複数のインスタンスデプロイ DMC のセットアップ⼿
順」を参照してください。
1. 分散管理コンソールを設定するインスタンスにログインします。デフォルトのインスタンスは未設定のスタンド
アロンモードです。
2. Splunk Web で、[分散管理コンソール ] > [設定 ] > [⼀般設定 ] へと進みます。
3. 左上の [分散モード ] をオンにします。
4. 以下を確認してください。
[インスタンス ] および [マシン ] 列に正しい値が記⼊されている（列ごとに⼀意の値が追加されてい
る）。注意：デプロイで Splunk Enterprise 6.1.x (6.2.0 以降ではなく) が動作しているノードがある場合、
そのインスタンス (ホスト) とマシンの値は追加されません。
マシンの値を探すには、通常、6.1.x のインスタンスにログインし、 *nix または Windows で
hostnameを実⾏します。ここでは、マシンがそのマシンの FQDN を表します。
インスタンス (ho st ) の値を探すには、次のように btool を使⽤します：splunk cmd btool inputs list
default
これらの値が分かっている場合は、[設定 ] ページで [編集 ] > [インスタンスの編集 ] へと進みます。
ポップアップに、記⼊が必要な 2 つのフィールド [インスタンス（ホスト）名 ] と [マシン名 ] が表
⽰されます。
サーバーロールが正しく、プライマリまたはメジャーロールを持っているようにしてください。たとえば、
ライセンスマスターを兼ねたサーチヘッドには、両⽅のロールが設定されている必要があります。設定され
ていない場合は、[編集 ] をクリックして修正してください。
インデクサークラスタリングを使⽤している場合、クラスタマスターが設定されています。設定されていな
9
い場合は、[編集 ] をクリックして修正してください。
警告：インデクサーとして設定されている項⽬が、本当にインデクサーであることを確認してください。
5. (任意) カスタムグループを設定します。カスタムグループは、分散サーチグループに直接マップされるタグで
す。最初に DMC のセットアップを⾏う際に、グループを追加する必要はありません (その後も不要な場合もあり
ます)。たとえばマルチサイトのインデクサークラスタリング (各グループを 1 つの場所にあるインデクサーで構
成します)、またはインデクサークラスタとスタンドアロンのピアがある場合にグループが役⽴ちます。カスタム
グループでは、重複させることが可能です。つまり、1 つのインデクサーは複数のグループに所属させられます。
『分散サーチ』マニュアルの分散サーチグループを参照してください。
6. インターフェイスの右上にある [変更の適⽤ ] をクリックします。
7. (任意) プラットフォームアラートをセットアップします。
デプロイで後から別のノードを追加する場合は、[設定 ] > [⼀般設定 ] に戻って⼿順 4 の各項⽬が正しいことを確
認してください。
DMC 設定の次の⼿順は、「フォワーダーモニタリングの設定」です。
DM C にフォワーダーモニタリングを設定
本トピックでは、複数のインスタンスの Splunk Enterprise のデプロイで分散管理コンソール (DMC) をセット
アップするプロセスの⼿順について説明していきます。「複数のインスタンスデプロイ DMC のセットアップ⼿
順」を参照してください。
前提条件
複数のダッシュボードモニタリングパネルを稼働させるには、フォワーダーに⼀意の永続的 GUID が必要ですこ
れを⾏う1つの⽅法として、開始前にフォワーダーのクローンを作成します。フォワーダーの GUID は
instance.cfg に⾒つかります。
セットアップ
[分散管理コンソール ] >[設定 ] > [フォワーダー設定 ] と進み、Splunk Webのセットアップ⼿順に従います。
時間設定について
フォワーダーのセットアップでは、データコレクションの間隔を設定したり、フォワーダーモニタリングを有効ま
たは無効にすることができます。フォワーダーモニタリングを有効にすると、スケジュール済みサーチが実⾏さ
れ、etc/apps/splunk_management_console/lookups の中の、DMC ノード上に存在するルックアップファイルである
dmc_forwarder_assets.csv に値が設定されます。DMC はこのフォワーダーのアセットテーブルを使って、どのフォ
ワーダーがダッシュボードをモニターするフォワーダーの情報を表⽰するかを理解します。
Splunk Web で、[設定 ] > [サーチとレポート ] > [DMC フォワーダー - アセットテーブルの作成 ] に進む
と、スケジュール済みサーチを確認することができます (ただし、変更はしないでください)。
[分散管理コンソール ] > [設定 ] > [フォワーダーモニタリングのセットアップ ] のページで、[データコレク
ションの間隔 ] に対していくつかの値を選択できます。この間隔は、スケジュール済みサーチの実⾏間隔です。デ
フォルトは 15 分です。
フォワーダーのアセットテーブルを再構築するためにスケジュール済みサーチを実⾏する時は、どのスケジュール
を選択しても 15 分間遡って実⾏されます。この履歴追跡時間は設定変更できず、またデータコレクションの間隔
とは異なるものです。
たとえば、コレクションの間隔を 24 時間に設定します。この場合、スケジュール済みサーチは 24 時間ごとに実
⾏されるものの、チェックされるのは実⾏開始前の 15 分間だけです。
フォワーダーの数が多い場合 (数⼗万など) は、スケジュール済みサーチは⾮効率になる場合があります。デフォ
ルトの 15 分ごとよりも少ない頻度でサーチを実⾏したいこともあるでしょう。
フォワーダーのアセットテーブルの再構築
フォワーダーのアセットテーブルのデータは蓄積されていきます。フォワーダーがインデクサーに接続すると、そ
の記録がテーブルに残ります。そして後ほどデプロイからフォワーダーを削除しても、アセットテーブルからフォ
ワーダーの記録は削除されません。アセットテーブル上で「不明」と表⽰され、DMC のフォワーダーダッシュ
ボードには依然表⽰がされます。
フォワーダー全体を DMC ダッシュボードから削除したい場合は、[分散管理コンソール ] > [設定 ] > [フォワー
ダー設定 ] にある [フォワーダーアセットの再構築 ] をクリックしてください。こうした⼀度限りの設定⽤サー
チの実⾏については、の履歴追跡時間を選択できます。この選択によって、前述のスケジュール済みサーチの履歴
追跡時間 (15 分) やデータコレクションの間隔が変更されることはありません。
プラットフォームアラート
プラットフォームアラートとは
プラットフォームアラートは、分散管理コンソール (DMC) に含まれる保存済みサーチです。プラットフォーム
アラートは、Splunk Enterprise 環境に問題を引き起こす可能性がある状況を、Splunk Enterprise の管理者に
通知します。通知は DMC ユーザーインターフェイス上に表⽰され、メールなどのアラートアクションを追加で開
10
始できます。プラットフォームアラートは REST エンドポイントからデータを取得します。
デフォルトでは、プラットフォームアラートは無効になっています。
プラットフォームアラートを有効にする
前提条件
DMC を設定します。「単⼀インスタンス DMC のセットアップ⼿順」または「複数インスタンス DMC の
セットアップ⼿順」を参照してください。
1. DMC の [概要 ] ページから [アラート ] > [有効または無効にする ]へ進みます。
2. 有効にするアラートの隣にある、[有効 ] のチェックボックスをクリックします。
アラートが⽣成されると、DMC Overview"ʼ ページに通知が表⽰されます。アラートが⽣成されると、[概
要 ] > [アラート ] > [⽣成されたアラートの管理 ] へと進むことでアラートとその結果を確認できます。
メール通知などのアラートアクションを追加で設定できます。
プラットフォームアラートおよびアラートアクションの設定
DMC から、 [ 概要 ] > [ アラート ] > [ 有効または無効にする ] へと進みます。設定するアラートを探し、[編集 ]
をクリックします。
ここではデフォルト設定を確認したり、以下のようなパラメータを変更できます。
アラートスケジュール
抑制時間
アラートアクション (メール送信やカスタムスクリプトの起動など)
メール通知を有効にする場合は、[設定 ] > [サーバー設定 ] > [メールの設定 ] で有効なメールホストを設定するよ
うにしてください。
アラートアクションについての説明は、『アラート』マニュアルの「アラートアクションの設定」を参照してくだ
さい。
また、$SPLUNK_HOME/etc/apps/splunk_management_console/default/savedsearches.conf では、プラットフォームアラート
のデフォルトのパラメータの⼀覧も確認できます。設定ファイルを直接編集する場合は、デフォルトではなく、
ローカルディレクトリに新しい設定を保管してください。
含まれているアラート
プラットフォームアラートを使ってデプロイのモニターリングを開始するには、希望するアラートを個別に有効に
する必要があります。上記の「プラットフォームアラートを有効にする」を参照してください。
アラー
ト名
説明
その他の参考情報
インデ
クサー
プロ
セッ
サーの
異常状
態
1 つ以上のインデクサーが、異常な状態を報告し
た場合に⽣成されます。こうした異常状態は、抑
制または停⽌することができます。
異常状態にあるインデクサーの詳細の確認や原
因調査の開始については、DMC の [インデック
スパフォーマンス：デプロイ ] ダッシュボード
にある [インスタンスごとのインデックス作成
のパフォーマンス ] パネルを確認してくださ
い。ダッシュボードについては [インデックスパ
フォーマンス：デプロイ]、および「インデック
ス作成の仕組み」を参照してください。
システ
ムによ
る物理
メモ
リーの
使⽤が
クリ
ティカ
ルと
なった
場合
1 つ以上のインスタンスのメモリー使⽤率が 90%
を超えた場合に⽣成されます。ほとんどの Linux
ディストリビューションでは、OS がバッファや
ファイルシステムのキャッシュアクティビティに
関与している場合に、このアラートが⽣成されま
す。他のプロセスを必要とする場合、OS はこのメ
モリーを解放するため、こうしたアラートは常に
深刻な問題を⽰している訳ではありません。
インスタンスのメモリー使⽤状況の詳細につい
ては、DMC の[ リソース使⽤状況：デプロイ]
ダッシュボードを確認してください。また、本
マニュアルの「リソース使⽤状況：デプロイ」
を参照してください。
既に期限切れとなっている、または 2 週間以内に
期限切れとなるライセンスがある場合に⽣成され
ライセンスおよびライセンスの使⽤状況に関す
る情報を確認する場合は、DMC の [ライセン
期限切
れ、お
よびま
もなく
期限切
れとな
11
れとな
るライ
センス
につい
て
ます。
ス ] をクリックします。
⾒つか
らない
フォ
ワー
ダー
1 つ以上のフォワーダーが⾒つからない場合に⽣
成されます。
DMC のフォワーダーのダッシュボードを確認し
てください。
ディス
クの使
⽤量が
ニアク
リティ
カルと
なった
場合
ディスク容量の 80% が使⽤された場合に⽣成され
ます。
ディスクの使⽤状況の詳細については、DMC の
3 つの [リソース使⽤状況 ] ダッシュボードを確
認してください。また、本マニュアルの該当す
るトピックを参照してください。
イベン
ト処理
の
キュー
が飽和
した場
合
1 つ以上のインデクサーキューが、直近の 15 分間
の平均で、フィルの割合が 90% 以上であると報告
した場合に⽣成されます。このアラートでは、潜
在的なインデックス作成の遅延について通知でき
ます。
インデクサーキューの詳細は、DMC の 2 つの
[インデックス作成のパフォーマンス ] ダッ
シュボードで確認できます。また、本マニュア
ルの該当するトピックを参照してください。
サーチ
ピアが
応答し
ない場
合
いずれかのサーチピア (インデクサー) と通信でき
ない場合に⽣成されます。
すべてのインスタンスのステータスについて
は、DMC の [インスタンス ] ビューを参照して
ください。
⽇次ラ
イセン
ス
クォー
タが合
計のラ
イセン
ス使⽤
量に接
近した
場合
⽇次ライセンスクォータの使⽤量の合計が 90% に
なった場合に⽣成されます。
ライセンス使⽤状況の詳細は、DMC の [ライセ
ンス ] をクリックします。
過去のサーチ結果について
savedsearches.conf のdispatch.ttl では、プラットフォームアラートからのサーチがサーチ結果を 4 時間保存す
るよう設定されています。
ただし、アラートが⽣成された場合は、過去のサーチ結果が 7 ⽇間保存されます。つまり、⽣成されたアラート
のサーチ結果を調査するためにメールで送信されるリンクは 7 ⽇間 (デフォルト) で期限切れとなります。
DM C ダッシュボードレファレンス
サーチアクティビティ：インスタンス
このトピックでは、分散管理コンソールの [サーチアクティビティ：インスタンス ] ダッシュボードについて参
照することができます。このマニュアルの「分散管理コンソールについて」を参照してください。
このビューに表⽰される内容
サーチアクティビティに関する複数のパネル
このビューでの結果の解釈
[サーチのリソース使⽤状況中央値 ] パネルでは、以下の事項に注意してください。
リソース使⽤状況はすべてのサーチで集計されます。
メモリー使⽤状況は物理メモリーを対象としています。
このグラフの CPU 使⽤状況は、システム全体の CPU 使⽤状況ではなく、1 つのコアのパーセンテージで表
⽰されます。その結果、ここには >100% の値が表⽰されると想定されます。これは、分散管理コンソール
の他の CPU 使⽤状況の例とは異なります。
[サーチランタイム集計 ] パネルでは、以下の事項に注意してください。
グラフ内の各時間ビンに対して、DMC はその時間範囲で実⾏されたすべてのサーチのランタイムを合計し
ます。そのため、たとえば 5 分間で 1,000 秒のサーチになる場合もあります。この場合、その 5 分間に複
数のサーチが実⾏されたことになります。
12
履歴バッチおよび RT インデックス作成のモードで、 Splunk Enterprise 内の特定の機能 (スケジューラー
など) のみが履歴バッチをディスパッチできます。RT インデックス作成は、リアルタイムにインデックスが
作成されたことを意味しています。
[メモリーを消費するサーチ上位 10 位 ] パネルの SID はサーチ ID を意味します。保存済みサーチに関する情報
を探す場合は、audit.log によって保存済みサーチの名前 (savedsearch_name) をそのサーチ ID (search_id)、
ユーザー、および時刻と照合できます。search_id を使って、Splunk サーチログのように (「Splunk がログに記
録する情報」を参照) 他の場所にあるサーチを探すことができます。
このビューで注⽬する事項
システムの制限と⽐較した上で、同時サーチとリソース使⽤状況について検討してください。
詳細については以下を参照してください。
『サーチ』マニュアルの「より良いサーチの作成」
『サーチ』マニュアルの「サーチについて」
『レポート作成』マニュアルの「スケジュール済みレポートの優先度の設定」
『ナレッジマネジャー』マニュアルの「サマリーベースのサーチとピボット⾼速化の概要」
このビューのトラブルシューティング
[サーチアクティビティ ] パネルでは、デフォルトで 10 秒ごとにスナップショットが作成されます。その時点で
サーチが実⾏されていない場合、またはごく短時間のサーチを実⾏する場合、スナップショットのパネルはブラン
クとなり、「⾒つかりません」と表⽰されます。
履歴パネルは、イントロスペクションのログからデータを取得します。パネルがブランク、またはインデクサー以
外からの情報がない場合は、以下を確認してください。
イントロスペクションのログをインデクサーに転送していること
プラットフォーム環境計測データに関するシステム要件
サーチアクティビティ：デプロイ
このトピックでは、分散管理コンソールの [サーチアクティビティ：デプロイ ] ダッシュボードについて参照す
ることができます。このマニュアルの「分散管理コンソールについて」を参照してください。
このビューに表⽰される内容
Splunk Enterprise のデプロイ全般でのサーチアクティビティに関する複数のパネル
このビューでの結果の解釈
ここに表⽰されるメモリーおよび CPU 使⽤状況は、サーチに関するもののみです。すべての Splunk Enterprise
のリソース使⽤状況については、リソース使⽤状況のダッシュボードを確認してください。
[中央値 CPU 使⽤状況別インスタンス ] パネルでは、コアが複数あるために CPU が 100% を超える場合があ
ります。
[中央値メモリー使⽤状況別インスタンス ] パネルのメモリーは物理メモリーです。
履歴バッチおよび RT インデックス作成のモードで、履歴バッチは Splunk Enterprise 内の特定の機能（スケ
ジューラーなど）のみがディスパッチできます。RT インデックス作成は、リアルタイムにインデックスが作成さ
れたことを意味しています。
このビューで注⽬する事項
このビューの中のすべてのパネルを確認する⼀般的なパターンは、マシン上で限界値を超えそうなものを探すこと
です。
詳細は、以下の項⽬を参照してください。
『サーチ』マニュアルの「より良いサーチの作成」
『サーチ』マニュアルの「サーチについて」
『レポート作成』マニュアルの「スケジュール済みレポートの優先度の設定」
『キャパシティプランニング』マニュアルの「多数の同時サーチの実⾏」を参照してください。
このビューのトラブルシューティング
履歴パネルは、イントロスペクションのログからデータを取得します。パネルがブランク、またはインデクサー以
外からの情報がない場合は、以下を確認してください。
イントロスペクションのログをインデクサーに転送していること
プラットフォーム環境計測データに関するシステム要件
サーチ使⽤統計ダッシュボード
このトピックでは、分散管理コンソールの [サーチ使⽤統計：インスタンス ] および [サーチ使⽤統計：デプロ
13
イ環境 ] ダッシュボードについて参照することができます。このマニュアルの「分散管理コンソールについて」を
参照してください。
これらのビューが表⽰する内容
デプロイ環境にあるすべてのサーチヘッドのサーチ使⽤統計と各インスタンスの詳細
これらのビューでの結果の解釈
以下の説明は、各ダッシュボードの⻑時間動作しているサーチのテーブルに適⽤されます。
「最も早い時間」あるいは「最も遅い時間」がブランクの場合は、おそらくリアルタイムサーチでしょう。
「最も早い時間」が「-」の場合は、最も早い時間は特定されておらず、コンピュータエポック時の開始時間
という意味になります。多くの *nix 環境の場合、これは 1970 年 1 ⽉ 1 ⽇になります。
「最も遅い時間」が「-」の場合は、最も遅い時間は特定されておらず、今現在という意味になります。
[サーチ使⽤統計：：インスタンス ] > [⼀般的なサーチコマンド ] では、実⾏時間は数秒です。
これらのビューで注⽬する事項
⻑時間動作しているサーチを確認することが推奨されます。最適化できるサーチが⾒つかる可能性があります。
詳細は、『サーチ』マニュアルの「より良いサーチの作成」を参照してください。
これらのビューのトラブルシューティング
このビューの履歴パネルは、audit.log からデータを取得します。パネルがブランク、またはインデクサー以外か
らの情報がない場合は、イントロスペクションのログをインデクサーに転送しているかどうか確認してください。
[⻑時間実⾏サーチ ] パネルは、REST エンドポイントからの情報も使⽤します。
スケジューラーアクティビティ
このトピックでは、分散管理コンソールの [スケジューラーアクティビティ ] ダッシュボードについて参照する
ことができます。このマニュアルの「分散管理コンソールについて」を参照してください。
これらのビューが表⽰する内容
分散管理コンソールの [スケジューラーアクティビティ：デプロイ ] ビューには、サーチやレポートスケジュー
ラーの概要が表⽰されます。
これらのビューには、スケジューラーのアクティビティと成功率が表⽰されます。実⾏しようとしたすべてのサー
チの中で、成功率はどれくらいだったでしょうか。同時処理やスケジュールの負荷がその障害になります。これら
のビューのパネルはこうした問題に適しています。スキップ割合と実⾏遅延は、スケジューラーのパフォーマンス
を数値化します。
スケジューラーアクティビティビューは、サーチヘッドクラスタリングを使⽤するしないにかかわらず役に⽴ちま
す。SHC が利⽤できる場合は、サーチヘッドクラスタリングセクションに他にも役⽴ちそうなビューがあること
に注意してください。これは「スケジューラーの委任」というもので、キャプテンがスケジューラージョブをどの
ように担当するかを扱うものです。
これらのビューでの結果の解釈
デプロイビューで、[St at ist ics ] パネルにはインスタンスごとの稼働状況が表⽰されますが、そのデプロイ環境
のすべてのインスタンスが含まれます。たとえば、最⼤とはそのデプロイ環境のすべてのインスタンスの中で最⼤
という意味です。
これらのビューで注⽬する事項
使⽤するスケジューラーが最⼤同時サーチ数に達した場合は、追加あるいは⻑時間動作するサーチをスケジュール
する時に問題が起こります。詳細は、「スケジュール済みレポートの優先度の設定」を参照してください。
スナップショット数スキップ割合および平均実⾏遅延はともに低く抑えてください。
以下は、スキップしているスケジューラーのためのスケジューラーアクティビティ：インスタンスパネルの例
です。
14
スケジューラーがレポートをスキップする理由を探すには、(名前および理由を基準とした) スキップされたレ
ポート数のラベルが付いたパネルをスクロールします。
これらのビューのトラブルシューティング
スケジューラーアクティビティダッシュボードでは、モニターされるインスタンスが Splunk Enterprise 6.3.0
以降であることが必要です。
DMC のセットアップ⼿順をすべて完了してください。.
インデックス作成のパフォーマンス：インスタンス
このトピックでは、分散管理コンソールの [インデックス作成のパフォーマンス：インスタンス ] ダッシュボー
ドについて参照することができます。上記の「分散管理コンソールについて」を参照してください。
このビューに表⽰される内容
1 つのインスタンス（デプロイでは複数になる可能性あり）でのインデックス作成のパフォーマンスに関する複数
のパネル
このビューでの結果の解釈
[Splunk Ent erprise データパイプライン ] と呼ばれるスナップショットのパネルには、キューサイズの平均減
少値が表⽰されます。平均値には過去 15 分間のデータが使⽤されます。このパネルと履歴パネル [データ処理
キューの中央値フィルレシオ ] は、インデックス作成遅延の原因を特定のキューに絞り込むのに役⽴ちます。
データはパーシングから開始され、データパイプラインを経由して、最終的にインデックスが作成されます。
[インデクサープロセッサアクティビティごとに費やされた集計 CPU の秒数 ] パネルでは、「インデックス
サービスをサブタスクごとに分割」することが可能です。複数のインデックスサービスが、インデックス作成準備
および作成後のクリーンアップに関連するサブタスクになります。サブタスクのカテゴリの意味についての詳細
は、『トラブルシューティング』マニュアルの metrics.log のトピックを参照してください。
このビューで注⽬する事項
[Splunk Ent erprise データパイプライン ] パネルと履歴パネル [データ処理キューの中央値フィルレシオ ]
は、インデックス作成遅延の原因を特定のキューに絞り込むのに役⽴ちます。データはパーシングから開始され、
データパイプラインを経由して、最終的にインデックスが作成されます。以下は不良状態のキューを持つインスタ
ンスのパネルの例です。
この例では、パーシングおよび集計キューのフィルレシオが⾮常に⾼いものの、問題は⼊⼒キュー内のプロセスに
あると考えられます。最初に遅くなるのが⼊⼒キューです。⼊⼒キューへの格納待ちのデータは、他の 2 つの
キューにバックアップされます。
15
このビューのトラブルシューティング
スナップショットパネルは Splunk REST エンドポイントからイントロスペクション向けのデータを取得します。
スナップショットパネルのデータが不⾜している場合は以下を確認してください。
プラットフォーム環境計測データに関するシステム要件
server.conf の pipelinesets 設定パイプラインセットの使⽤時 (つまり、pipelinesets が 1 よりも⼤きな値に設
定されている場合)、DMC インデックス作成パフォーマンスのダッシュボードのパネルにブランクのものが
あること。
このビューの履歴パネルのデータは、metrics.log から取得されます。
インデックス作成のパフォーマンス：デプロイ
このトピックでは、分散管理コンソールの [インデックス作成のパフォーマンス：デプロイ ] ダッシュボードに
ついて参照することができます。上記の「分散管理コンソールについて」を参照してください。
このビューに表⽰される内容
Splunk Enterprise のデプロイ全般でのインデックス作成のパフォーマンスに関する複数のパネル
このビューでの結果の解釈
[インデックス作成パフォーマンスの概要 ] パネルのインデックス作成レートの合計は、すべてのインデクサー
の合計となります。
デフォルトではそれぞれのタイプの上位 10 位の結果だけを対象とする metrics.log が使⽤されるため、[推定イ
ンデックス作成レート別インスタンス ] パネルのインデックス作成レートは推定値になります。詳細は、『トラ
ブルシューティング』マニュアルの「metrics.log について」を参照してください。
このビューのトラブルシューティング
スナップショットパネルは Splunk REST エンドポイントからイントロスペクション向けのデータを取得します。
スナップショットパネルのデータが不⾜している場合は以下を確認してください。
プラットフォーム環境計測データに関するシステム要件
server.conf の pipelinesets 設定パイプラインセットの使⽤時 (つまり、pipelinesets が 1 よりも⼤きな値に設
定されている場合)、DMC インデックス作成パフォーマンスのダッシュボードのパネルにブランクのものが
あること。
このビューの履歴パネルのデータは、metrics.log から取得されます。
リソース使⽤状況：インスタンス
このトピックでは、分散管理コンソールの [リソース使⽤状況：インスタンス ] ダッシュボードについて参照す
ることができます。上記の「分散管理コンソールについて」を参照してください。
このビューに表⽰される内容
Splunk Enterprise インスタンスによって確認されるリソースの使⽤状況に関する複数のパネル
このビューでの結果の解釈
2 つの [プロセスクラス] パネルのプロセスクラスは、splunkd サーバー、サーチ、Splunk Web、インデックス
サービス、スクリプト⼊⼒、KVStoreなどになります。
プロセスクラスとは、1 つのクラスでのプロセスの集計を意味します。それぞれの詳細については、以下を参照し
てください。
splunkd については、『インストール』マニュアルの「Splunk Enterprise のアーキテクチャとプロセス」
をお読みください。
サーチについては、『サーチ』マニュアルの「サーチについて」と「より良いサーチの作成」を参照してく
ださい。
splunkweb については、『インストール』マニュアルの「Splunk Enterprise のアーキテクチャとプロセ
ス」をお読みください。
スクリプト⼊⼒については、『データの取り込み』マニュアルの「スクリプト⼊⼒による API や他のリモー
トデータインターフェイスからのデータの取得」をお読みください。
KVStore については、DMC の「KV ストア：インスタンス」ビューを確認してください。
インデックスサービスはインデックス作成に関連する維持管理タスクで構成されています。これらはインデックス
作成パイプラインの最後に実⾏されるものの、同期されません。これらのプロセスは splunkd を経由せず、単独
で実⾏されます。
[ディスク使⽤状況 ] および [中央値ディスク使⽤状況 ] パネルには、Splunk Enterprise が使⽤するパーティ
ションのみが表⽰されます。
このビューで注⽬する事項
16
⼤量のリソースを使⽤しているプロセスクラスがサーチと判明した場合は、[サーチアクティビティ：インスタ
ンス ] ダッシュボードを確認します。
⻑時間実⾏されているプロセスについては、時間とともにメモリー使⽤量が継続的に増加していないかどうかを確
認してください。
このビューのトラブルシューティング
履歴パネルは、イントロスペクションのログからデータを取得します。パネルがブランク、またはインデクサー以
外からの情報がない場合は、以下を確認してください。
イントロスペクションのログをインデクサーに転送していること、および
プラットフォーム環境計測データに関するシステム要件
リソース使⽤状況：マシン
このトピックでは、分散管理コンソールの [リソース使⽤状況：マシン ] ダッシュボードについて参照すること
ができます。上記の「分散管理コンソールについて」を参照してください。
このビューに表⽰される内容
Splunk Enterprise のデプロイで個々のマシンがリソースを使⽤している状況に関する複数のパネル
このビューでの結果の解釈
このビューは、運⽤後の検討作業やキャパシティプランニングに役⽴ちます。詳細については『キャパシティプラ
ンニング』マニュアルを参照してください。
このビューの物理メモリー使⽤状況について：Linux の場合、OS は空いている物理メモリーを使って、ファイル
システムのリソースをキャッシュします。ただし、このようなメモリーは緩くロックされているため、優先度の⾼
いプロセスで必要となった場合には、メモリーが解放されてしまいます。DMC レポートでは、このように緩く
ロックされているメモリーの容量が識別されません。
[中央値 CPU 使⽤状況 ] パネルで、システムに搭載されているコア数に関係なく、100% はシステム全体を意味
します。これは、100% が 1 つのコアを意味する [サーチアクティビティ ] ダッシュボードと対照的です。
このビューのディスクスペースは、Splunk のあるパーティションのみを表しています。
このビューで注⽬する事項
⻑時間実⾏されているプロセスについては、時間とともにメモリー使⽤量が継続的に増加していないかどうかを確
認してください。
このビューのトラブルシューティング
履歴パネルは、イントロスペクションのログからデータを取得します。パネルがブランク、またはインデクサー以
外からの情報がない場合は、以下を確認してください。
イントロスペクションのログをインデクサーに転送していること、および
プラットフォーム環境計測データに関するシステム要件
リソース使⽤状況：デプロイ
このトピックでは、分散管理コンソールの [リソース使⽤状況：デプロイ ] ダッシュボードについて参照するこ
とができます。上記の「分散管理コンソールについて」を参照してください。
このビューに表⽰される内容
Splunk Enterprise のデプロイ全般でのリソースの使⽤状況に関する複数のパネル。これらのパネルはキャパシ
ティプランニングに役⽴ちます。
このビューでの結果の解釈
このビューの物理メモリー使⽤状況について：Linux の場合、OS は空いている物理メモリーを使って、ファイル
システムのリソースをキャッシュします。ただし、このようなメモリーは緩くロックされているため、優先度の⾼
いプロセスで必要となった場合には、メモリーが解放されてしまいます。DMC レポートでは、このように緩く
ロックされているメモリーの容量が識別されません。
[ デプロイ全体の中央値ディスク使⽤状況] パネルでは、各 Splunk Enterprise インスタンスが使⽤しているす
べてのパーティションが考慮されます。
このビューで注⽬する事項
このビューの共通のテーマは、インスタンスが値の範囲ごとにグループ化されることです。注⽬すべき事項の 1
つは外れ値です (他のインスタンスとは異なっているインスタンス)。もう 1 つは、時間とともに現れるパターン
です。
このビューのトラブルシューティング
17
履歴パネルは、イントロスペクションのログからデータを取得します。パネルがブランク、またはインデクサー以
外からの情報がない場合は、以下を確認してください。
イントロスペクションのログをインデクサーに転送していること
プラットフォーム環境計測データに関するシステム要件
KV ストア：インスタンス
このトピックでは、分散管理コンソールの [KV ストア：インスタンス ] ダッシュボードについて参照することが
できます。上記の「分散管理コンソールについて」を参照してください。
このビューに表⽰される内容
分散管理コンソール（DMC）のインスタンスレベルの KV ストアビューには、App キーバリューストアを実⾏す
る単⼀の Splunk Enterprise インスタンスのパフォーマンス情報が表⽰されます。分散デプロイでDMC を設定
した場合、表⽰するデプロイのインスタンスを選択することができます。
パフォーマンス測定基準
コレクションの測定基準は、/services/server/introspection/kvstore/collectionstatsREST エンドポイントでのデー
タの履歴レコードである_introspection インデックス内の KVStoreCollectionStats コンポーネントで⽣成され
ます。測定基準は以下の通りです。
アプリケーションコレクションが所属しているアプリケーション
コレクションKV ストア内のコレクション名
オブジェクト数コレクション内に保存されているデータオブジェクト数
⾼速化コレクションに設定されている⾼速化の数注意：これらはパフォーマンスやサーチの⾼速化に使⽤さ
れる従来のデータベース型のインデックスです。
⾼速化サイズコレクションに設定されているインデックスのサイズ (MB)
コレクションのサイズコレクションに保存されているすべてのデータのサイズ (MB)
スナップショットは、REST エンドポイント経由で収集され、関連するイントロスペクションコンポーネントから
の最新情報を提供します。KV ストアインスタンスのスナップショットは、エンドポイント
/services/server/introspection/kvstore/serverstatusを使⽤します。
ロックの割合：システムがグローバル読み取りまたは書き込みロックを保持した KV ストアのアップタイム
の割合。ロックの割合が⾼いと、全体に影響が及びます。この場合、複製の停滞、アプリケーション呼び出
しの遅延、タイムアウト、または失敗が発⽣する可能性があります。
ページフォルトの割合：ページフォルトになった KV ストア操作の割合。割合が 1 に近いほど、システムパ
フォーマンスが低下していることになります。これは、メモリ内のデータストアに効率的にアクセスするの
ではなく、KV ストアがディスク I/O のフォールバックを強制されているために発⽣する継続的な停滞を⽰
す代表的なサインです。
メモリー使⽤状況：KV ストアが使⽤中の常駐/マップ済み/仮想メモリの容量。通常、仮想メモリの使⽤量
は KV ストアにマップされたメモリの 2 倍です。仮想メモリの使⽤量がマップされたメモリーの 3 倍を超え
る場合は、メモリーリークの可能性があります。
ネットワークトラフィック：KV ストアネットワークトラフィックの合計⼊出量 (MB)。
フラッシュの割合：KV ストアがディスクへのすべての書き込みをフラッシュするために必要とする時間の
割合。1 に近いほど、ディスクへの書き込みが困難、または継続的に⼤量の書き込み操作が⾏われているこ
とになります。OS によっては、データのフラッシュに 60 秒かからない場合もあります。この場合、書き
込み上のボトルネックがあっても、この値が⼩さくなる可能性があります。
操作：KV ストアに対して発⾏された操作数。コマンド、更新、クエリ、削除、取得、挿⼊などが挙げられ
ます。イントロスペクションのプロセスでは、KV ストアの統計情報を配信するためにコマンドが発⾏され
るため、通常は他の⼤半の操作よりもコマンド数が多くなります。
現在の接続：KV ストアで開かれている接続数。
キューの合計：ロック待ちでキューされている操作の合計。
合計アサート：KV ストアが⾏ったアサート数の合計。値が負でない場合は、KV ストアのログをチェックす
る必要があります。
履歴
このセクションの統計情報の多くは、[スナップショット ] セクションに表⽰されます。[履歴 ] ビューには⼀定期
間の測定基準の傾向情報が表⽰されます。これらの統計情報は KVSt o reServerSt at s に収集されます。[履歴 ]
パネルには、デフォルトで過去 4 時間の情報が表⽰されます。このセクション内のグラフにギャップがある場
合、通常はその時点で KV ストアまたは Splunk Enterprise と通信できなかったことを⽰しています。
メモリー使⽤状況 - 上記を参照。
複製遅延：プライマリ OpLog に記録されている最後の操作とセカンダリノードに適⽤された最後の操作間
の時間。プライマリ opLog ウィンドウを超えた複製遅延が発⽣すると、複製セットのすべてのノードで
データが正しく複製されない場合があります。複製を⾏わないスタンドアロンのインスタンスでは、このパ
ネルに結果は表⽰されません。注意：複製遅延は _introspection インデックス内の
KVSt o reReplicaSet St at s コンポーネントに収集されます。
操作数（分単位の平均） - 上記を参照。このパネルには、個々の操作タイプ (コマンド、更新、削除など) ま
たはすべての操作に関する情報が表⽰されます。
アサート - 上記を参照。このパネルでは、アサートのタイプ（メッセージ、レギュラー、ロールオーバー、
ユーザー、警告）に基づいてフィルタリングを⾏うことができます。
ロックの割合：システムがグローバル、読み取りまたは書き込みロックを保持している KV ストアのアップ
タイムの割合。このパネルはロックの種類ごとにフィルタリングします。
読み取り：読み取り操作のために⾏われるロック。
書き込み：書き込み操作のために⾏われるロック。KV ストアロックは「書き込み中⼼」のため、コレ
クションでは書き込みロックがロック全体の⼤半を占めることがあります。
グローバル：グローバルシステムによって⾏われるロック。KV ストアではコレクションレベルのロッ
クが実⾏されるため、グローバルロックを積極的に使⽤する必要性が削減されます。
18
合計操作数の割合としてのページフォルト - 上記を参照。
ネットワークトラフィック - 上記を参照。このパネルに追加されているのは、KV ストアに対して⾏われた
リクエストです。
キューの推移：以下の項⽬で分類されたキュー数。
読み取り：読み取りロックの解除待ちの読み取り操作数。
書き込み：書き込みロックの解除待ちの書き込み操作数。
合計：
接続の推移
ディスクのフラッシュに費やされたそれぞれの時間の割合 - 上記を参照。
もっとも遅い操作。選択された時間内で KV ストアに記録されている最も遅い操作の上位 10 件。すべての
コレクションに対してプロファイリングをオフにすると、⾮常に遅い操作を実⾏している場合でも結果が表
⽰されません。collections.conf でコレクションごとにプロファイリングを有効にしてください。
このビューのデータの取得先
KV ストアは、_introspection インデックス内のデータを収集します。
これらの統計情報は、以下のコンポーネントに分類されます。
KVStoreServerStats：KV ストアの全体的なプロセスの実⾏に関する情報。27 秒ごとにポーリングされま
す。
KVStoreCollectionStats：KV ストア内でのコレクションに関する情報。10 分ごとにポーリングされま
す。
KVStoreReplicaSetStats：KV ストアインスタンス全体での複製データに関する情報。60 秒ごとにポーリ
ングされます。
KVProfilingStats：遅い操作に関する情報。5 秒ごとにポーリングされます。プロファイリングが有効に
なっている場合に使⽤できます。注意：プロファイルは開発システム上、またはデフォルトのパネルでは分
からない KV ストアのパフォーマンスに関する問題のトラブルシューティングの⽬的でのみ有効にしてくだ
さい。プロファイリングはシステムのパフォーマンスに悪影響を与える可能性があるため、実際の運⽤環境
では有効にしないでください。
また、KV ストアは Splunk Enterprise が収集するさまざまな内部ログでエントリを⽣成します。
このビューでの結果の解釈
パフォーマンスのインジケータと⾚いフラグに関する情報については、本マニュアルの「KV ストア：デプロイ」
を参照してください。
このビューのトラブルシューティング
履歴パネルは、イントロスペクションのログからデータを取得します。通常、このセクションのグラフに時間の
ギャップがある場合は、その時点で KV ストアまたは Splunk Enterprise と通信できなかったことを⽰していま
す。パネルが完全にブランク、または特定の Splunk Enterprise インスタンスからのデータがない場合は、以下
を確認してください。
イントロスペクションのログをインデクサーに転送していること
プラットフォーム環境計測データに関するシステム要件
KV ストア：デプロイ
このトピックでは、分散管理コンソールの [KV ストア：デプロイ ] ダッシュボードについて参照することができ
ます。上記の「分散管理コンソールについて」を参照してください。
このビューに表⽰される内容
分散管理コンソール（DMC）の [KV ストア：デプロイ ] ビューには、Splunk Enterprise のデプロイ内のすべ
ての KV ストアで集計された情報が表⽰されます。このビューでインスタンスを表⽰するには、[KV ストア ]の
サーバーロールを設定する必要があります。この設定は DMC の [設定 ] ページで⾏います。
このビューと [ KV ストア：インスタンス] ビューは、ほぼ同じ情報を追跡します。ただし、このデプロイビュー
は KV ストアから統計情報を収集し、さまざまな測定基準の値でグループ分けされたインスタンスを表⽰します。
個々のダッシュボードと測定基準の定義とコンテキストについては、本章の「KV ストア：インスタンス」を参照
してください。
パフォーマンス測定基準
デプロイスナップショット
[デプロイスナップショット統計情報 ] は、/services/server/introspection/kvstore/serverstatus REST エンドポイ
ントにアクセスします。デプロイでの各 KV インスタンスについて、[デプロイスナップショット ] は以下の情報
を提供します。
インスタンスSplunk Enterprise インスタンス名
メモリー使⽤状況
キューの合計
現在の接続
操作あたりのページフォルト
ロック (%)
前回のフラッシュ (ミリ秒)
ネットワークトラフィック (MB)
19
アップタイム (時間)：現在のインスタンスが再起動せずに動作している時間
複製ロール：複製セットでのインスタンスのロールインスタンスが複製セットに含まれない場合は、
「N/A」が返されます。
このビューのデータの取得先
KV ストアは、_introspection インデックス内のデータを収集します。
これらの統計情報は、以下のコンポーネントに分類されます。
KVStoreServerStats：KV ストアの全体的なプロセスの実⾏に関する情報。27 秒ごとにポーリングされま
す。
KVStoreCollectionStats：KV ストア内でのコレクションに関する情報。10 分ごとにポーリングされま
す。
KVStoreReplicaSetStats：KV ストアインスタンス全体での複製データに関する情報。60 秒ごとにポーリ
ングされます。
KVProfilingStats：遅い操作に関する情報。5 秒ごとにポーリングされます。プロファイリングが有効に
なっている場合に使⽤できます。注意：プロファイルは開発システム上、またはデフォルトのパネルでは分
からない KV ストアのパフォーマンスに関する問題のトラブルシューティングの⽬的でのみ有効にしてくだ
さい。プロファイリングはシステムのパフォーマンスに悪影響を与える可能性があるため、実際の運⽤環境
では有効にしないでください。
また、KV ストアは Splunk Enterprise が収集するさまざまな内部ログでエントリを⽣成します。
このビューの解釈
パネ
ル
クリティカル
1.3+
操作あ
たりの
ページ
フォル
ト
警告
0.7–1.3
⼤量のディスク
I/O が必要とな
り、より多くの
RAM を消費する
可能性がある読み
取り
定期的に
ディスク
I/O を必
要とする
読み取り
ロック
の割合
ネット
ワーク
トラ
フィッ
ク
標準
説明
0-0.7
ディスク
I/O をほ
とんど必
要としな
い読み取
り
Splunk Enterprise がメモリ内に保有しているデータで
は対応できない読み取りリクエストの頻度の計測で、
Splunk Enterprise によるディスクの読み込みが必要
50%+
30%50%
0-30%
ロックの割合が⾼いと複製が正常に処理できなかった
り、アプリケーション呼び出しの遅延、タイムアウト、
または失敗の原因になる場合があります。通常、ロック
の割合が⾼い場合は、ノード上で⼤量の書き込みアク
ティビティが発⽣しています。
N/A
N/A
N/A
ネットワークトラフィックはシステムの使⽤状況および
アプリケーションの想定と同等でなければなりません。
デフォルトの閾値は適⽤されません。
複製待
ち時間
>30 秒
10-30 秒
0-10 秒
複製のニーズはシステムによって異なります。⼀般的
に、複製セットのメンバーは、KV キャプテンを⼤幅に下
回ってはなりません。複製の待ち時間が 30 秒以上の場
合、複製のマウントに関して問題が発⽣している場合が
あります。
プライ
マリ操
作ログ
ウィン
ドウ
N/A
N/A
N/A
参考⽤：これは時間の観点からのデータ量で、復元⽤に
操作ログに保存されるシステムです。
フラッ
シュ
レート
50%-100%
10%50%
0-10%
⾼いフラッシュレートは、書き込み操作が重いか、シス
テムパフォーマンスが悪いことを⽰しています。
このビューのトラブルシューティング
履歴パネルは _introspection および _internal インデックスからデータを取得します。これらのパネルの時間に
ギャップがある場合は、その時点でKV ストアまたは Splunk Enterprise と通信できなかったことを⽰します。
パネルが完全にブランク、または特定の Splunk Enterprise インスタンスからのデータがない場合は、以下を確
認してください。
ログをインデクサーに転送していること
プラットフォーム環境計測データに関するシステム要件
サーチヘッドクラスタリングダッシュボード
このトピックでは、サーチヘッドクラスタリングに関連するすべての分類管理コンソールダッシュボードを参照す
ることができます。上記の「分散管理コンソールについて」を参照してください。
20
ステータスと設定
[ステータスと設定 ] ダッシュボードには、サーチヘッドクラスタの概要が表⽰されます。これはハイレベルの情
報です。
設定の複製
[設定の複製 ] ダッシュボードには、サーチヘッドクラスタメンバー (新しいイベントタイプなど) でユーザーが
変更する設定や、クラスタ全体に変更が伝搬される⽅法に関する情報が表⽰されます。この伝搬でかなりの遅延が
みられる場合には、このダッシュボードを使⽤してください。
アクションレファレンス：下記は [経過時間内のアクション数 ] パネルと [経過時間内でアクションにかかった
時間 ] パネルで表⽰される低レベルのアクションです。これらのパネルはトラブルシューティングに役⽴ちます。
アクション
説明
accept_push
キャプテンで、メンバーからの複製された変更を承認します。
acquire_mutex
設定システムを「保護」するミューテックス (相互排除) を⼊⼿します。
add_commit
メンバーで、変更を記録します。
base_initialize
設定「root」を初期化します (例： $SPLUNK_HOME/ 等)。
check_range
設定変更の 2 つの範囲を⽐較します。
compute_common
メンバーとキャプテン間の直近の共通の変更を特定します。
pull_from
メンバーで、キャプテンから変更を取り出します。
purge_eligible
メンバーで、レポジトリから⼗分に古い変更をパージします。
push_to
メンバーで、キャプテンに変更をプッシュします。
release_and_reacquire_mutex
設定システムを「保護」するミューテックスをリリースした後で再⼊⼿しま
す。これは acquire_mutex と同様です。
reply_pull
キャプテンで、メンバーの pull_from リクエストに応答します。
repo_initialize
設定レポジトリを (ディスクから) 初期化します。
この情報は Splunk サポートによって活⽤されることを想定しています。設定の複製に問題がある場合、このダッ
シュボードで⼿掛かりを探すことができます。ただし、このダッシュボードは情報の獲得よりも、サポートケース
の記録後に情報を収集するために使⽤してください。
過去のサーチ結果の複製
[過去のサーチ結果の複製] ダッシュボードには、複製する過去のサーチ結果に関するクラスタの「バックログ」を
表⽰する複数のパネルが含まれています。『分散サーチ』マニュアルの「サーチヘッドクラスタリングのアーキテ
クチャ」を参照してください。
[警告とエラーパターン ] パネルはメッセージ内のテキストに基づいて、警告やエラーイベントを分類します。こ
の分類機能ではクラスタコマンドが使⽤されます。
サーチヘッドクラスタが時間通りに過去のサーチ結果を複製している場合、複製待ちの過去のサーチ結果数は 0
または 0 に近い値になります。ごく⼀部の複製待ちの過去のサーチ結果は、警告のサインでない可能性がありま
す。過去のサーチ結果数が常に多く、特にその数が増加している場合は、複製の問題が発⽣している可能性があり
ます。待ち状態の過去のサーチ結果が多い場合は、別のサーチヘッドを使⽤している⼈がローカルキャッシュにた
どり着けない可能性があり、サーチの有⽤性が低下することになります。
[複製する過去のサーチ結果の中央値 ] は (表⽰されている通り) 中央値です。つまり、スパイクを制限している
と、より広範な時間範囲でスパイクを確認できないことになります。
[過去のサーチ結果の複製ジョブアクティビティ ] パネルには複製ジョブの変更率が表⽰されます (具体的には
バックログの変更率)。クラスタがバックログに追い付いている場合、バックログの変更は負の値になる場合もあ
ります。このパネルの⾚いフラグは、絶えず増加しているバックログを⽰します (つまり、バックログの変更は常
に正の値)。この場合、上記の [複製する過去のサーチ結果の中央値 ] パネルに表⽰されるバックログは、継続的
に増加しています。
スケジューラーの委任
『分散サーチ』マニュアルの「サーチヘッドクラスタリングのアーキテクチャ」を参照してください。
[スケジューラーステータス ] パネルでは、max_pending と max_running が 30 秒の間、「ピーク」となるこ
とに留意してください。これらはペンディングまたは実⾏中のジョブの 30 秒間での最⼤数です。このパネルで
複数の機能の中から 1 つを選択できます。「最⼤」機能は、これらの統計値と直接的に機能します。ただし、
「平均値」、「中央値」、「90 パーセンタイル」の意味についても考察してください。たとえば、max_pending
が 30 秒間で 4 の場合にその値を平均するとします。すると、全体の平均ではなく⾼い値の平均が出ます。そのた
め、ペンディング状態のジョブの数が⼤きく変動する場合は、平均の max_pending はペンディング状態のジョブ
数の単純な平均と異なる可能性があります。
A pp デプロイ
App デプロイダッシュボードは、デプロイヤーからサーチヘッドクラスタメンバーにデプロイされる際、app を
モニターします。
21
『Splunk Enterprise インスタンスの更新』マニュアルの「デプロイサーバーとフォワーダーの管理について」を
参照してください。
[App ステータス ] パネルに継続的に相違が表⽰される場合、それはデプロイヤーがメンバーに対して App のデ
プロイを終了していないことを⽰します。
これらのビューのトラブルシューティング
サーチヘッドクラスタリングダッシュボードでは、モニターされるインスタンスが Splunk Enterprise 6.2.0 以降
であることが必要です。
DMC のセットアップ⼿順をすべて完了してください。.
特に、
サーチヘッドとデプロイヤーからインデクサーにログを転送してください。「DMC の前提条件」を参照し
てください。
すべてのサーチヘッドクラスタリングダッシュボードについては、サーチヘッドを DMC のサーチピアとし
て設定する必要があります。
すべてのサーチヘッドクラスタリングダッシュボードには、サーチヘッドクラスタのメンバーが必要です。
「クラスタラベルの設定」を参照してください。App デプロイヤーにもラベルが必要なことに留意してくだ
さい。
App デプロイダッシュボードについては、
デプロイヤーが DMC のサーチピアでなければなりません。または、DMC をデプロイヤーでホストするこ
ともできます。「インスタンスをサーチピアとして追加」を参照してください。
デプロイヤーにはデプロイヤーロールが必要です (⾃動検出される場合があります)。これについては、[ 分散
管理コンソール ] > [ 設定 ] > [ ⼀般設定 ] へと進んで確認してください。
デプロイヤーは SHC のメンバーとして⼿動でラベリングする必要があります(⾃動検出されません)。これに
ついては、[ 分散管理コンソール ] > [ 設定 ] > [ ⼀般設定 ] と進んで設定してください。
上記の通り、デプロイヤーはログを転送する必要があります。「DMC の前提条件」を参照してください。
分散サーチダッシュボード
このトピックでは、分散サーチに関連するすべての分類管理コンソールダッシュボードを参照することができま
す。このマニュアルの「分散管理コンソールについて」を参照してください。
これらのビューが表⽰する内容
分散サーチビューは、分散サーチフレームワークの状態、アクティビティ、パフォーマンスを表⽰します。
これらのビューは、サーチ時のサーチヘッドとそのピア間の通信に焦点を置いています。これに対して、サーチ
ヘッドクラスタリングダッシュボードはサーチヘッド間の通信を表⽰したものです。
これらのビューを使⽤する基本的な⽅法が 2 つあります。
1. ビューの⼀番上の、この製品エリアの正常チェックに移動します。これらの基本チェックが問題ないことを確認
してください。
2. ユーザーから分散サーチに問題ある旨の報告を受けた時には、これらのビューを使ってコンポーネントの稼働の
様⼦を理解してください。たとえば、「サーチピアがサーチに参加しません」あるいは、サーチピアが利⽤できな
いまたは終了しない、といったメッセージをユーザーが⾒たとします。このようなメッセージに対して、これらの
ダッシュボードを使⽤してください。問題のあるインスタンスがわかっている場合は、分散サーチ：インスタン
スビューに直接移動してください。そうでない場合は、分散サーチ：デプロイビューから始めてください。これ
らのインスタンスの動作履歴を⾒てください。これらのビューは、分散サーチフレームワークの理解に役⽴ちま
す。これは問題解決のヒントとなるでしょう。
これらのビューでの結果の解釈
いずれのビュー (インスタンスまたはデプロイ ) でも、ページの⼀番上で [サーチヘッド ] または [インデク
サー ] を選択して、サーチヘッドまたはサーチピアを調べることができます。ダッシュボード上に表⽰される測定
基準は選択したロールにより変わります。
インスタンスビューでサーチヘッドを選択して、サーチヘッドがどのようにピアを通信しているかを、サーチヘッ
ドの稼働という観点から確認してください。
これらのビューで注⽬する事項
各ビューの⼀番上にある [正常チェック ] の中で⾚⾊のフラグを探してください。正常チェックは、分散サーチイ
ンフラ全体にわたる総合的なものではありません。むしろ基本的事項を⾼度にチェックするものです。
[スナップショット ] パネルには、リクエストに対する応答時間およびバンドルの複製時間が表⽰されます。それ
らの時間は⾮常に短い (1 秒未満) ので、⾮常に重要です。これらの時間が数秒あるいはそれ以上である場合は、
通常どこかに異常があります。
[デプロイ ] ビューでは、サーチヘッドラジアルを選択して、列ソートでタイミング測定基準を検査してくださ
い。
ディスパッチディレクトリは、操作ごとに結果が出るため、15 秒以上時間がかかる場合は問題があります。
バンドルディレクトリの実⾏もまた、15 秒よりはるかに短い時間しかかかりません。
22
3 つのハートビート測定基準は、サーチヘッドにきわめて重要です。それらが⾼いとサーチピアは受信しすぎて
しまい、通信リクエストへの素早い応答に問題が⽣じる可能性があります。1 秒を超える応答時間は理想的ではな
く、開発において問題があることを⽰すものとなります。応答時間が 5 秒または 10 秒を超えるとタイムアウトを
迎え始めます。これが発⽣するときはサーチは失敗します。トラブルシューティングを続けるには、これをこのピ
アに対応した [リソース使⽤状況：マシン ] ビューと⼀致させてください。詳細については、『トラブルシュー
ティング』マニュアルの「サーチピア上で頻発する認証タイムアウト」を参照してください。
分散サーチの問題ついてさらに情報が必要な場合は、『分散サーチ』マニュアルの「⼀般的なトラブルシューティ
ングに関する問題」を参照してください。
これらのビューのトラブルシューティング
これらのビューが利⽤する測定基準はすべて Splunk Enterprise 6.3.0 で導⼊されました。デプロイ環境のコン
ポーネントが Splunk Enterprise バージョン 6.3.0 以降の場合は、これらのビューにはコンポーネントからの
データは含まれません。
スナップショットパネルは様々なエンドポイントからのデータを使⽤します。
これらのビューのすべての履歴パネルは、audit.log からデータを取得します。
H T T P イベントコレクタダッシュボード
このトピックでは、分散管理コンソールの [HTTP イベントコレクタ ] ダッシュボードについて参照することが
できます。「分散管理コンソールについて」を参照してください。
これらのビューが表⽰する内容
分散管理コンソールでは、HTTP イベントコレクタのために 2 つのダッシュボードが利⽤可能です。
確認箇所
デプロイ全体のダッシュボードから始めて、周辺のパフォーマンスを確認してください。ドリルダウンを使⽤し
て、インスタンスを範囲としたダッシュボードに関連した問題に関する詳細を探してください。
これらのビューでの結果の解釈
HTTP イベントコレクタ：デプロイダッシュボード：表⽰されるトークンの⼀覧は、現時点で設定されている
トークンを⽰しています。なのでトークンが無効化されている場合は、トークンドロップダウンには表⽰されま
せん。これに対して、インスタンスを範囲としたビューではすべての有効化および無効化トークンが表⽰されま
す。
『データの取り込み』マニュアルの「HTTP イベントコレクタの設定と使⽤」を参照してください。
これらのビューのトラブルシューティング
データの取り込みを⾏うインスタンスは、HTTP イベントコレクタを使⽤するため、Splunk Enterprise 6.3.0 以
降である必要があります。使⽤するインスタンスがユニバーサルフォワーダーの場合は、サーチピアになれないた
め、DMC によりモニターできません。
これらのダッシュボードにデータの不⾜がある場合、分散またはスタンドアロンモードのいずれかで、DMC の
セットアップ⼿順をすべて完了しているかどうかを確認してください。
インデクサークラスタリング：ステータス
このトピックでは、分散管理コンソールの [インデクサークラスタリング：ステータス ] ダッシュボードについ
て参照することができます。上記の「分散管理コンソールについて」を参照してください。
このビューに表⽰される内容
このビューは、インデクサークラスタマスターのマスターダッシュボードに類似しています。『インデクサーとイ
ンデクサーのクラスタの管理』マニュアルの「マスターダッシュボードの表⽰」を参照してください。
このビューのトラブルシューティング
このダッシュボードでは、すべてのインデクサークラスタのデータが表⽰されるはずです。複数のインデクサーク
ラスターがあり、それらのデータが 1 つでも確認できない場合は、Splunk Enterprise デプロイ DMC のセット
アップ⼿順に従っているかを確認してください。具体的には、
すべてのクラスタのメンバであるサーチヘッドで DMC をホストしていること。
インデクサークラスタをラベリングしていること。
各クラスタマスタが DMC にサーチピアとして追加されていること。
インデクサークラスタリング：サービスアクティビティ
このトピックでは、分散管理コンソールの [インデクサークラスタリング：サービスアクティビティ ] ダッシュ
ボードについて参照することができます。上記の「分散管理コンソールについて」を参照してください。
このビューに表⽰される内容
23
インデクサークラスタリングに関する複数のパネル
このビューでの結果の解釈
このダッシュボードのパネルには、データがまったく表⽰されない場合があります。データはバケツ修復アクティ
ビティが発⽣した場合にのみ表⽰されます。
これらのパネルは、Splunk Enterprise が実⾏しなければならない修復タスク（バックログ）がいくつあるかを特
定するのに役⽴ちます。修復タスクは複数のジョブになる場合があります。
最後 2 つのパネルは、クラスタリングエンドポイントにヒットするまでにかかった時間を測定します。
Splunk サポートおよび/またはエンジニアリングはこのデータを確認し、クラスタマスターが⾏っているアク
ティビティのタイプをプロファイルする場合があります。
このビューで注⽬する事項
ピアが下がるなど、クラスタで予期しないイベントが発⽣した場合にこのビューを使⽤します。
タスクをペンディング状態にしないことが理想的です。
サーチ要因がマッチしない場合、サーチ結果は不完全になります。
⽣成がマッチしない場合、クラスタ全体がサーチ不可能になります。6.1 以降のクラスタではこれが発⽣しないと
想定されています。
イベントが発⽣した場合は、このダッシュボードからタスク (およびジョブ) の数が減少しているかどうかを確認
できます。クラスタに問題がない場合、これらのパネルには何も表⽰されません。
このビューのトラブルシューティング
DMC のセットアップ⼿順をすべて完了してください。.
特に、
サーチヘッドとデプロイヤーからインデクサーにログを転送してください。「DMC の前提条件」を参照し
てください。
すべてのインデクサークラスタリングダッシュボードには、インデクサークラスタのメンバーが必要です。
「クラスタラベルの設定」を参照してください。
インデックス作成：インデックスとボリュームのダッシュボード
このトピックでは、分散管理コンソールの [インデックス作成：インデックスとボリューム ] のすべてのダッ
シュボードについて参照することができます。上記の「分散管理コンソールについて」を参照してください。
これらのビューが表⽰する内容
インデックスとボリュームのダッシュボードは、インデックス作成に関する 6 つの個別のダッシュボードで構成
されており、それぞれに複数のパネルがあります。
インデックスとボリュームのダッシュボードの全体では、インデックスでのディスクの使⽤状況を確認できます。
これらのビューでは、リソース使⽤状況ビューのデータの内訳が表⽰されます。
これらのビューでの結果の解釈
システムのストレージに余裕がない場合は、インデックスとボリュームのダッシュボードを確認します。このデー
タは、保存ポリシーの評価と修正に役⽴てることができます。『インデクサーとインデクサーのクラスタの管理』
の「インデクサーによるインデックスの保管⽅法」を参照してください。
これらのビューで注⽬する事項
[インデックスとボリューム：インスタンス ] ダッシュボードで、⻘でハイライトされているインスタンスはフ
ローズンに移⾏するバケツです。『インデクサーとインデクサーのクラスタの管理』の「インデクサーによるイン
デックスの保管⽅法」を参照してください。
[インデックスとボリューム：デプロイ ] ダッシュボードでは、フローズンデータに関する情報は⾚⾊フラグに
なる場合があります。[インデックス ] および [ボリューム ] パネルにこの情報が表⽰されます。
[インデックス詳細：デプロイ ] ダッシュボードで、[インスタンス ] パネルを⾒て、データ期間を持つインデク
サーと、データ期間の期限よりずっと前からフローズン状態にあるフローズン期間を持つインデクサーを確認して
ください。ダッシュボードのドリルダウンを調査に役⽴てることができます。
フォワーダーダッシュボード
このトピックでは、分散管理コンソールの [フォワーダー：デプロイ ]、[フォワーダー：インスタンス ]、そし
て [Splunk TCP ⼊⼒パフォーマンス ] のデプロイおよびインスタンスダッシュボードについて参照することが
できます。このマニュアルの「分散管理コンソールについて」を参照してください。
これらのビューが表⽰する内容
24
DMC は ([フォワーダー ] ダッシュボードで) フォワーダー接続と ([Splunk TCP ⼊⼒ ] ダッシュボードで) 通信
をモニターします。
Splunk TCP ⼊⼒ビューでは、Splunk TCP ⼊⼒、つまりある Splunk インスタンスから他の Splunk インスタ
ンスへのデータがモニターされます。通常、これはインデクサーにデータを送信するフォワーダーです。これらの
ビューは、Apache サーバーがログをフォワーダーに送信するように、⾮ Splunk デバイスからコレクタへの
TCP ⼊⼒のモニターをしません。
これらのビューでの結果の解釈
フォワーダー：デプロイビュー
[ステータス ] パネルには、「アクティブ」または「不明」の値を表⽰することができます。スケジュール済み
サーチは 15 分間遡って実⾏され、このパネルを更新します。直近の 15 分の間にフォワーダーがインデクサーに
接続された場合、ステータスは「アクティブ」になります。そうでない場合は、ステータスは「不明」になりま
す。不明のフォワーダーをダッシュボードから永久に削除したい場合は、フォワーダーのアセットテーブルを再構
築してください。このマニュアルの「フォワーダーモニタリングの設定」を参照してください。
この履歴追跡時間は、スケジュール済みサーチの実⾏頻度を表すデータコレクションの間隔 ([設定 ] > [フォ
ワーダーモニタリングのセットアップ ] の) とは異なります。このマニュアルの「フォワーダーモニタリングの
設定」の時間設定の項⽬を参照してください。
[ステータスと設定パネル ] ではスケジュール済みサーチが最後に完了した時間が表⽰されます。
フォワーダー：インスタンスビュー
「出⼒データレート」と呼ばれる数量は、インデクサーがフォワーダーから受信するデータを測定したものです。
これはインデクサーの metrics.log を測定したものです。『トラブルシューティング』マニュアルの
「metrics.log について」を参照してください。
Splunk Enterprise にインデックス化されたデータが⾒つからない場合は、DMC ダッシュボードを次の順序で確
認してください。
1. フォワーダービュー
2. Splunk TCP ⼊⼒ビュー
3. インデックス作成ビュー
『データの転送』マニュアルの「フォワーダー/レシーバー接続のトラブルシューティング」を参照してくださ
い。
これらのビューで注⽬する事項
[フォワーダー：デプロイ ] ビューから始めて、フォワーダーが設定通りレポートしているか、またはフォワー
ダーのどれかが不明になっていないかを確認してください。
このダッシュボードは事前に設定されたプラットフォームアラートとペアになっており、⼀つ以上のフォワーダー
が⾒つからない場合に通知を受け取ることができます。
これらのビューのトラブルシューティング
フォワーダーと Splunk TCP ⼊⼒ダッシュボード
これらのダッシュボードにデータの不⾜がある場合、分散またはスタンドアロンモードのいずれかで、DMC の
セットアップ⼿順をすべて完了しているかどうかを確認してください。
すべての DMC ダッシュボードと同様、これらのダッシュボードにはインデクサーの metrics.log が必要です。
DMC はデータの取得のためにフォワーダーに直接クエリを発⾏することはなく、データの取得はフォワーダーが
接続しているインデクサーから⾏います。
フォワーダーのダッシュボードに固有の⼿順
[フォワーダー：デプロイ ] または [フォワーダー：インスタンス ] ダッシュボードのパネルを機能させるには、
このマニュアルの「フォワーダーモニタリングの設定」の設定⼿順に従う必要があります。履歴パネルには、個別
の GUID を備えるフォワーダーが必要になるという前提条件に注意してください。
[フォワーダー ] ダッシュボードの平均値は、「データコレクションの間隔」 ([DMC ] > [設定 ] > [フォワーダー
モニタリングのセットアップ ] へと進んで定義される) の少なくとも 1 つが経過するまで計算されません。
ライセンス
分散管理コンソール（DMC）の [ライセンス ] ビューには、ライセンス使⽤状況のレポートビューと同じ情報が
表⽰されます。ライセンスマスターからではなく DMC 経由でこのビューにアクセスする利点は、デプロイに複数
のライセンスマスターがある場合、情報を表⽰するライセンスマスターを DMC ビューで選択できることです。
このビューに表⽰される情報の詳細は、『管理』マニュアルの「Splunk Enterprise ライセンス使⽤状況のレポー
トビューについて」を参照してください。
25

Download Report