はじめに
FluentdとはOSSのログ収集ツールで、サーバだけではなくログ収集コンテナとしてKubernetesやOpenshiftの上で動くPodのログをサーバに転送するという使われ方もよくしています。
一方で気になるのはFluentd自体が停止してしまった場合のログの欠落。
結論としては転送前のログが消えてしまうことはないのですが、なぜコンテナが消えてもログが消えないのかについて簡単に解説しました。
尚、今回は以下のKubernetes環境で利用されるFluentdを例に説明します。
ログが欠落しない理由
結論から言うと、Fluentdにはposファイルと呼ばれる「対象のファイルをどこまで読み込んだか記録」しているテキストファイルが存在するからです。このposファイルが存在する限り、Fluentdのプロセスであったりコンテナが停止してしまってもそのファイルを利用してログ転送が再開されます。
ただし、コンテナは明示的にファイルを外出ししておかない限りは停止すると消失してしまうので
Posファイルをコンテナ外のファイルシステムに保管する必要はあります。
例えばIKSのFluentdは以下のように外にマウントしているディレクトリが存在し
Mounts: ... /mnt/ibm-kube-fluentd-persist from persist (rw) ... persist: Type: HostPath (bare host directory volume) Path: /mnt/ibm-kube-fluentd-persist HostPathType:
実際にコンテナの中で該当のパスを確認すると確かにposファイルが存在しました。
sh-4.4# ls /mnt/ibm-kube-fluentd-persist fluentd-docker.pos
同ファイルの中には以下のように値が格納されていて
# cat /mnt/ibm-kube-fluentd-persist/fluentd-docker.pos ... /var/log/containers/test-xx-6ptrq_myns_test-xx.log 00000000014f5766 00000000004c1e98
それぞれファイル名、読み込んだバイト位置、監視対象ファイルのinodeを意味します。
上記のようにファイルの実体はWorkerNodeにあるためFluentd自体が停止しても「読み込んだバイト位置」が残っているので再開されます。
終わりに
Fluentdを停止してしまうと転送前のログが欠落してしまうように思えますが、このPosファイルがコンテナ内にのみ保管されているケースを除いてログはWorkerNodeに残り続けるので欠落しません。
Fluentdに負荷がかかってログ転送が停止してしまうケースなどでも、Fluentd自体を再起動させればまた途中から動きだすのでこの動きは覚えておきたいです。