LoginSignup
6
8

More than 3 years have passed since last update.

Splunk Admin編 〜 _internal ログ - metrics.log の種類とその利活用 〜

Posted at

はじめに

今回はSplunkのAdmin編です。
普段あまり注目されることのないSplunkの内部ログである _internal を利用して、Splunk Adminとして、Splunkを少しだけプロっぽく運用できたらいいなと思い、とりあえず metrics.log を調べてまとめてみました。
Adminではないユーザーにとってはそもそも内部ログの存在自体を知らないかもしれませんが、もし興味があれば読んでいただければと思います。

確認に利用した環境

Splunkバージョンは現時点の最新である v8.0.1 を利用しています。
metrics.log は特定のコンポーネントを利用して初めて出力されるものがあるので、可能な限り多くのコンポーネントを利用して構成しました。今回利用したコンポーネントは下記です。
- Monitoring Console
- Deployment Server
- License Master
- Index Cluster (Cluster Master, Indexer x 2)
- Search Head Cluster (Deployer, Search Head x 3)
(構築だけで所々でハマったりして3時間近くかかってしまいました^¥^)

そのため、基本的な metrics.log はカバーできているかと思いますが、もしこの記事に載っていないログ(group。後述)があればお知らせください。確認して更新したいと思います。

まず、Splunk内部ログとは?

SplunkにはSplunk自体の内部ログを、 $SPLUNK_HOME/var/log/splunk/ にロギングしており、 Splunkの _internal という index に自動的に保管しています。
内部ログは非常に多くあるのですが、有名どころだと下記があります。
- splunkd.log
- metrics.log
- scheduler.log
- audit.log (audit.log だけは例外的に _audit index に保管)

簡単な例としては、下記などでサーチしたことがあるかもしれません。

index=_internal source=*splunkd.log log_level!=INFO

Splunkの環境において、WARNやERRORなど比較的問題となっている場合に出力されるログが確認できます。

内部ログの主な用途は、監査であったりトラブルシューティング、Splunkの稼働状況確認などによく使われます。
なお、 splunkd.log や metrics.log などはSplunkの監視において基本中の基本であり重要な Monitoring Console で多く利用されています。

詳しくは公式ドキュメントをご参照ください:
https://docs.splunk.com/Documentation/Splunk/latest/Troubleshooting/WhatSplunklogsaboutitself

では、 metrics.log とは?

metrics.log の基本的な性質としては下記になります。
- Splunk稼働状況を確認するためのSplunk内部情報をメトリクスとしてロギング
- エラーメッセージなどはなく、ログレベルはINFOの一種類のみ
- ロギングの頻度は30秒に1回(例外あり)
- 同じメトリクスはTop 10のみしかロギングしない( limits.conf [metrics] スタンザの maxseries で変更可能)

ログの基本的な構造は下記のようになっています。

metrics.log
└- group
    └- name
        └- ...
            └- key=value (Metrics)

group がメトリクスの種類、 name がその中でのサブカテゴリという理解で良さそうです。さらに詳細に分岐する場合もあります。
例えば、 pipeline という group の場合、 parsing, merging, typing, indexerpipe などの name があり、その下に、 utf8 や linebreaker などという processor ごとに、メトリクスが記録されます。
このメトリクスと queue group のメトリクスを見ると、データの取り込み時の処理において、パース、マージ、インデキシング、などどのフェーズの、どの処理がボトルネックになっているか、というところまで確認ができるので、トラブルシューティングに役立ちそうです。
(ちなみに上記のメトリクスはざっくりといい感じに Monitoring Console の indexing > Performance からも確認することができます)

上記のデータ取り込み時の処理(Data Pipleine)については、こちらもご参照ください:
https://docs.splunk.com/Documentation/Splunk/8.0.1/Deploy/Datapipeline

ちなみに今回なぜ metrics.log を記事にしたか、という理由ですが、すみません特に無くなんとなくです。
重要度(トラブルシューティングなどでよく使われる頻度)で言うと splunkd.log や audit.log のほうがよかったかもしれませんが、そちらはまた今度ということで。

metrics.log の種類

主なコンポーネント group 概要
Cluster Master cmmaster_servicejobs Index Cluster に関するメトリクス
Indexer clusterin_connection Index Cluster TCP/IN connection に関するメトリクス
Indexer clusterout_connections Index Cluster TCP/OUT connection に関するメトリクス
Indexer clustered_primaries_searches Cluster環境のサーチに関するメトリクス
Indexer cachemgr_bucket Smart Storeに関するメトリクス
Indexer spacemgr Smart Storeに関するメトリクス
Search Head shclustering Search Head Cluster に関するメトリクス
Search Head captainstability Search Head Cluster captain に関するメトリクス
Search Head searchscheduler サーチスケジューラー関連のメトリクス
Search Head search_pool サーチ関連のメトリクス
Search Head search_health_metrics サーチQuotaなどに関するメトリクス
Search Head search_concurrency サーチ同時実行数などのメトリクス
Search Head realtime_search_data Real timeサーチに関するメトリクス
Search Head knowledgebundle_replication Knowledge bundle replication に関するメトリクス
Deployment Server deploy-client Deployment client に関するメトリクス
Deployment Server deploy-connections Deployment Server connection に関するメトリクス
Deployment Server deploy-server Deployment Server に関するメトリクス
Global tailingprocessor データ転送に関するメトリクス
Global thruput Indexing Pipeline関連のメトリクス
Global dutycycle -
Global per_host_thruput host毎のスループット (kbpsはKB/s)
Global per_index_thruput index毎のスループット (kbpsはKB/s)
Global per_source_thruput source毎のスループット (kbpsはKB/s)
Global per_sourcetype_thruput sourcetype毎のスループット (kbpsはKB/s)
Global tcpin_connections TCP/IN connection に関するメトリクス
Global tcpout_connections TCP/OUT connection に関するメトリクス
Global pipeline Indexing Pipeline関連のメトリクス
Global pipelineset Indexing Pipeline時のキュー関連のメトリクス
Global queue Indexing Pipeline時のキュー関連のメトリクス
Global bundle_replication bundle(index, search head関連)に関するメトリクス
Global bundle_uploads bundle(index, search head関連)に関するメトリクス
Global bundle_donwloads bundle(index, search head関連)に関するメトリクス
Global kvstore KV Store に関するメトリクス
Global bucket_metrics Bucket に関するメトリクス
Global instance 稼働 Instance に関するメトリクス
Global kvstore KV Store に関するメトリクス
Global conf Internal 処理に関するメトリクス
Global executor Internal 処理に関するメトリクス
Global jobs Internal 処理に関するメトリクス
Global subtask_counts Internal 処理に関するメトリクス
Global subtask_seconds Internal 処理に関するメトリクス
Global map Internal の cache 関連のメトリクス
Global tpool Internal 処理に関するメトリクス
Global mpool Internal 処理に関するメトリクス

metrics.log の利活用

基本的なメトリクスは、Monitoring Consoleがいい感じで利用して簡単に確認できるようになっています(と思います)。
ですが詳細な確認をしたい際は、対象コンポーネント、機能に関連する group を指定し、直接サーチすることも出てくるかもしれません。
下記、簡単なサーチの事例を書いてみました。

単位時間あたりのIndex量
- per_host_thruput (host毎)
- per_index_thruput (index毎)
- per_source_thruput (source毎)
- per_sourcetype_thruput (sourcetype毎)

index=_internal metrics group=per_index_thruput NOT debug NOT sourcetype=splunk_web_access 
| timechart fixedrange=t span=1h sum(kb) 
| rename sum(kb) as totalKB

Forwarderの稼働状況

index=_internal source=*metrics.log host=<FORWARDER HOSTNAME> group=tcp*

Data Pipelineの調査

  • Parsing Phase
index=_internal source=*metrics.log group=queue name=parsingqueue
index=_internal source=*metrics.log group=pipeline name=parsing processor=*
  • Merging Phase
index=_internal source=*metrics.log group=queue name=aggqueue
index=_internal source=*metrics.log group=pipeline name=merging processor=*
  • Typing Phase
index=_internal source=*metrics.log group=queue name=typingqueue
index=_internal source=*metrics.log group=pipeline name=typing processor=*
  • Indexing Phase
index=_internal source=*metrics.log group=queue name=indexqueue
index=_internal source=*metrics.log group=pipeline name=indexerpipe processor=*
  • どの Phase に時間がかかっているか
index=_internal source=*metrics.log group=pipeline 
| timechart sum(cpu_seconds) as cpu_seconds by name
  • どの処理に時間がかかっているか
index=_internal source=*metrics.log group=pipeline 
| timechart sum(cpu_seconds) as cpu_seconds by processor

その他、今後更新・・

おわりに

metorics.log を色々調べてみて、ざっくりと概念やどんな時にどのメトリクスを見ればよいのか、は把握できましたが、一度調べ始めると思った以上に奥が深く、肝心のサーチ文まで落とし込む時間があまり取れませんでした。

文中でも触れましたが、 metrics.log の基本的なメトリクスは、 Monitoring Console がいい感じに利用してくれています。
まずは Monitoring Console を見て、足りない部分を metrics.log で詳細調査をする、という流れが良いのかと思いました。

今回 metrics.log を調べてみて、もっと他の内部ログも知りたいと思ったので、また調べて書きたいと思います。
またその日まで。

6
8
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
6
8