More than 3 years have passed since last update.

Splunk モニターコンソールでSplunkの状態を知る

Last updated at 2020-10-19Posted at 2020-10-19

はじめに

Splunkでどのくらいのデータを毎日取り込んでいるのか、どの Indexにデータがどのくらいのペースで取り込まれているのか、ライセンスはどのくらい余裕があるのか。などSplunkの環境自体について知りたい事ってありませんか？

そんなときに利用できるのがモニターコンソールという機能になります。管理者権限があればみる事ができるこの機能について少し調べてみました。

モニターコンソールとは

設定画面から、左のデータの追加の下にあるボタンを押すと、画面に移動できます。

以下のような画面が現れます。

ちなみに、モニターコンソール設定はシングルインスタンス以外で利用する場合は最初に設定が必要になります。今回はシングルインスタンスでの利用を想定して記載しますが、分散モードで設定されるかたはこちらのマニュアルをご覧ください。
https://docs.splunk.com/Documentation/Splunk/8.0.6/DMC/Deploymentsetupsteps

どんなメニュー画面があるか

概要
サマリー
健全性チェック
インデックス化
- パフォーマンス
  - インデックス・パフォーマンス：インスタンス
  - インデックス・パフォーマンス：詳細
- インデックスボリューム
  - インデックスとボリューム：インスタンス
  - インデックス詳細：インスタンス
  - ボリュームの詳細：インスタンス
- 入力
  - HTTPイベントコレクター：インスタンス
  - Splunk TCP入力パフォーマンス：インスタンス
  - データ品質
- ライセンス使用状況
  - ライセンス使用状況 -今日
  - ライセンス使用状況 -過去30日
- SmartStore
  - SmartStoreアクティビティ：インスタンス
  - SmartSotreキャッシュパフォーマンス：インスタンス
サーチ
- サーチアクティビティ：インスタンス
- サーチ使用統計情報：インスタンス
- KVストア：インスタンス
- スケジューラーアクティビティ：インスタンス
リソース使用状況
- リソース使用状況：インスタンス
- リソース使用状況：マシン
- CPU Usage:インスタンス
- ワークロード管理
  - ワークロード管理の概要
  - ワークロード管理アクティビティ：インスタンス
  - ワークロード管理アクティビティ：デプロイ
フォワーダー
- フォワーダー：インスタンス
- フォワーダー：デプロイ
設定
- 通常セットアップ
- フォワーダーモニタリング設定
- アラート設定
- 概要設定
- 健全性チェック項目
サーチ実行

ご覧のとおり、たくさんのダッシュボードが用意されております。今回はこの中からユーザーによく聞かれるポイントについてチェックしたいと思います。

どんな事が確認できるか、よくある質問に答えてみる

1: どのようなスペックでSplunkを利用してますか？

これは簡単です。最初の概要ページにいきなり出てきます。（おっと、最小CPU構成を満たしてないのがバレちゃいます)

もっと細かいリソースの使用状況については、「リソース使用状況」のダッシュボードで確認できるので後ほど

2: ライセンスが気になるので、1日の取り込みサイズを過去に遡って知りたい

「インデックス化」ー「ライセンス使用状況」ー「ライセンス使用状況 - 過去 30 日」　で確認できます。

分割基準の項目で指定すると、それぞれの項目毎の取り込み量がチェックできます。

3: どのくらいのデータが溜まっているのか確認したい

よく、ストレージ容量の観点からどの程度のデータが保存されているかチェックしたい。またどのデータが多いのか知りたい。ということがあります。その場合は
「インデックス化」ー「インデックス・ボリューム」ー「インデックスとボリューム：インスタンス」をみるといいです。

このように、インデックス毎にデータAge / Usage (GB) を設定の最大値と実際の値をチェックできます。
例えば上記の _internal インデックスをみると、設定のMax Data Ageが 30日となっており、今保存されているデータで古いのが31日前のものがあります。これはパージされるタイミングの問題で、しばらくすると30日を超えたデータはFrozen 領域に移動もしくは削除されます。
また、aws インデックスをみると、20GB がMax値に設定されてますが、実際のデータは19.32GB でもうすぐ超えそうとわかります。超えた場合は同じようにFrozen領域に移動されるか、もしくは削除されます。これは設定次第ですが、デフォルトだと削除になります。

また下の方にいくと総容量の内訳も日毎にチェックできます。

これを見ながらストレージの設計やインデックス設定をするのがいいかと思います。

4: 同じインデックスにいろんなデータを入れているので、さらにその中でどのソースやソースタイプのものが多いか知りたい

よくあるのが、同じインデックスにまとめて入れていて、逼迫している対象を確認したい。という場合です。
その場合は先ほどの画面からインデックスをクリックすると以下のページに飛びます。直接アクセスしても大丈夫です。

「インデックス化」ー「インデックス・ボリューム」ー「インデックス詳細：インスタンス」

ここではインデックスの詳細を確認できます。

以下の画面からソース別もしくはソースタイプ別にイベント数をチェックできますので、多い対象を調べる事ができます。

下の画面ではインデックス設定情報がチェックできます。

下の画面では、データエイジの推移や、hot/warm 領域の割合などもチェックできます。

5: サーバーのリソース利用状況を知りたい

次によくあるのが、リソース使用状況です。OS側でも全体のリソース状況はチェックできますが、こちらではSplunk内の利用状況をもう少し詳しくチェックできます。

「リソース使用状況」ー「リソース使用状況：インスタンス」

CPU/Memory/Disk の日々の使用状況をグラフでチェックできます。

また、マシン情報の欄でマシンをクリックするとさらに詳細が確認できます。以下は確認できる一例の画面です。I/O周りはとくに詳しくでてます。

CPUの使用をもっと詳しくチェックしたい場合は以下のみるといいでしょう。

「リソース使用状況」ー「CPU Usage:インスタンス」

どのプロセス（機能）がCPUを多く消費しているか、もしくはユーザー別に利用者を特定するなどもできます。

6: インデックス時の性能は問題ないか？

データが反映されるのが遅いとか、index time にdelayが生じているケースなどはここをチェックするといいでしょう。

インデックス処理の各パイプライン毎のパフォーマンスが確認できます。それぞれキューがあるのですが、処理が追いつかなくなるとキューが溢れ出します。そのためこちらの画面でキューがあふれていないかをまずはチェックしてみるのがいいでしょう。

インデックス側に問題がなければ、フォワーダー側を疑って確認することも忘れずに

7: サーチの多いユーザーや時間のかかっているサーチを見つけたい

よく使っているユーザーや負荷の高いサーチを見つけるには、ここをチェック！

「サーチ」ー「サーチ使用統計情報：インスタンス」

ユーザー別のサーチ回数や、頻繁に実行されるサーチなどがチェックできます。頻繁に実行されるサーチなどは最適化すると全体のパフォーマンスがよくなるかも。

また実際に時間がかかっているサーチなどもチェックできます。

8: スケジュールサーチはスキップされずに実行されているの？

サーチをスケジュール実行しているものでも、次の実行時間までに前の処理が終わらなかったり、何かしらの問題で実行されずにスキップされてしまうケースがあります。
このようなケースがどのくらい発生していたかをこちらのダッシュボードで確認できます。

「サーチ」ー「スケジューラーアクティビティ：インスタンス」

大量のパネルがありますが、今回のようにコア数が少ない環境にスケジュールサーチをたくさん走らせるとスキップされるケースが増えてしまいます。この場合スケジュール時間を少しずらすか、コア数を増やすかなどの対策が必要です。今回の場合はちょうど 00分のタイミングでスケジュールサーチがかぶっているので５分ずらすことで解決。