コンテナ再起動させると、Filebeatのログ収集が止まる

Elastic In Your Native Tongue 日本語による質問・議論はこちら
1

Kubernetes上のTomcatのコンテナのログを、Filebeatのコンテナで収集しています。
Tomcatのコンテナ再起動後、収集対象のログは更新されているのに、ログ収集のインスタンスが、
ログ更新を検知していないようで、Filebeatのログ収集が開始されません。。
ほかのアプリのログ収集も、同様に、コンテナの再起動をかけるとログ収集が止まります。

暫定対処として、アプリのコンテナ再起動後、Filebeatのコンテナ再起動をかけてログ収集の再開をさせています。

Filebeatのログを確認したところ、エラーも出ていないので、
原因がわからず、根本対処に困っています。

〇環境
Kubernetes上のコンテナ
Tomcat(ログ出力はAzure上の永続化ボリューム)
Filebeat

〇filebeat.yml

filebeat.inputs:

type: log
enabled: true
type: log
close_inactive: 5m
ignore_older: 15m
paths:

/var/lib/kubelet/plugins/kubernetes.io/azure-disk/mounts/m*/api.log
tags:
Tomcat_api.log

設定が悪いのでしょうか？
何か、よい解決策はないでしょうか？

2

k8sでのFilebeatsのデプロイメントは、一般的にはDaemon Setでのデプロイがリコメンドとなります。

https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html

イメージとしては、Filebeatは、以下のLogging Agentになります。

ご質問頂いた環境のBeatsのデプロイ方法はどんな形でしょうか？
FilebeatsをSidecarとしてデプロイしていますか？

3

レスありがとうございます。
ご質問頂いた環境のBeatsのデプロイ方法はどんな形でしょうか？

Daemon Setで、デプロイしています。

FilebeatsをSidecarとしてデプロイしていますか？

Azure Kubernetes Service ( AKS)のクラスターノードの、
Sidecarとしてデプロイしています。

AKS上のコンテナのログを永続化ボリュームに出力しているので、
そのログをSidecarのfilebeetで、収集させています。

4

Daemon SetとSide Carは排他なので、FilebeatはDaemon Setではなく、TomcatコンテナのSide Carとして同じPodでデプロイされているイメージですかね？

Sider Carでということになると、おそらく、TomcatコンテナとFilebeatコンテナで、それぞれPersistent VolumeをVolumeマウントして互いに見ているのだと思いますが、その辺りのPod設定の問題か、もしくはTomcatコンテナ側でログローテーションした時に、Filebeat側がうまく認識できていない可能性がありますね。

一般的なリコメンドとしては、コンテナログはstdout/stderrに吐いて、Daemon SetとしてデプロイしているFilebeatでそれをキャプチャするやり方です。特段の理由がなければ、Hint BaseのAutodiscoverを使うほうが簡単かと思います。

5

bruce_shimizuさん
レスと、ご確認、ありがとうございます。

Filebeatは、Daemon Setで、デプロイしています。
ご教示ありました情報をもとに、確認してみます。

6

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.