6
9

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

Splunk Advent Calendar 2019Advent Calendar 2019

Day 16

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
9
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
9

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?