サーバのストレージをDockerのログで食いつぶされていた調査

#インフラ #障害対応 #作業記録

2020/1/29 webshのサーバのストレージが食いつぶされていたことが分かった

やったことの記録

調査

サーバに接続してコマンドを実行しようとしたらコマンド入力の補間で変なログがでるようになった

これは以前Dockerイメージの残骸でストレージを食いつぶされていた時と同じ現象

docker imagesを見る

Dockerイメージの残骸はない

ストレージを消費している箇所を特定する

code:bash

sudo su -

cd /

du -h -d 1 2>/dev/null

# -> /var が99GB食ってる

cd var

du -h -d 1 2>/dev/null

# -> lib が99GB食ってる

cd lib

du -h -d 1 2>/dev/null

# -> docker が99GB食ってる

cd docker

du -h -d 1 2>/dev/null

cd containers

du -h -d 1 2>/dev/null

cd コンテナID

ls -lah

# -> ログが80GB以上になっていた

これでログファイルがストレージを逼迫していたことがわかった

ログの掃除

ログファイルのフルパスを確認

code:bash

docker ps

docker inspect 664d39b63773 | grep log

ログファイルの中身を空にする

code:bash

truncate -s 0 /var/lib/docker/containers/664d39b63773513686e4d1439c72884c39fda66eceb811d218902b8574ef9595/664d39b63773513686e4d1439c72884c39fda66eceb811d218902b8574ef9595-json.log

結果の確認

code:bash

df -h

Availが78GBになっていたので回復した

原因

Dockerのログが肥大化してストレージを食いつぶしていた

あるコンテナがyesを実行しており、その標準出力がDockerのログに吐かれ続けていた

なぜかDockerのプロセスが死なずに残っており、数時間以上前から生きていた模様

タイムアウト時間とか設定してるんだけどなぁ

反省

ストレージ監視を入れていない

面倒だったので外形監視しかいれてない

恒久対応

Dockerログのローテーションを導入する

対応した

docker run --log-driver=json-file --log-opt max-size=100m --log-opt max-file=10って感じ

しかしなんでDockerプロセスが死なずに残ってたんだろう

サーバの監視系を導入する

やるならやはりDatadogかMackerelなのかなぁ

prometheusでやった

参考

Dockerのログのクリア方法とローテーション設定について | Fun life