ステータス
解決
事象
2023年１月2日正午頃、https://bmf-tech.com/ にアクセスするとレスポンスが遅い、500エラーが常に返却されることに気づき、発覚。
grafanaにログインして調査をしようとしたが、ログインができなかった。
一部コンテナが何らかの原因でダウンした可能性を考慮して、デプロイを実施したが、no space left on device のエラーログを確認したため、別の原因であることを推察。
影響
bmf-techの全サービスが利用できない状況となった。
Nginxのリクエスト状況を確認するに、2023年1月2日午前5時48分頃からサービスダウンしていた。
復旧は同日12時40分頃。
2023年1月2日午前5時48分頃~12時40分頃までの間に58件の500エラーが発生。 ※ある程度のユーザー数を計測したかったが、ログやGA4などから集計できるように調整していないため調査しづらい。
原因
ファイルシステムに空きがないのが原因であった。
対応
ファイルシステム容量を圧迫しているデータを削除し、空き容量を確保。
アクション
- サーバーにsshし、dfコマンドでディスクの空き容量を確認。空き容量がなかった。
- duコマンドでディスクを一番使っていそうな箇所を調査。
/var/lib/docker/配下であると特定。
- 使用されていないdockerオブジェクトを削除して、空き容量を確保。
- ついでに2番目くらいに容量を食っていたjournalのログも200M残して削除。
追記
上記の対応だけでは不十分だった。
/var/lib/docker/containers 配下に溜まっているログファイルが容量を大きく取っていたので、コンテナのログローテーションを調整することで対応した。
この対応により容量に大きく余裕を持つことができた。一番のボトルネックがここであったということ。。。
再発防止
ファイルシステムの利用率をアラートに追加。事前に逼迫を検知して対処できるようにした。
その他
削除できるデータやローテーションすべきデータを洗い出して節約できるようにしたい。
所感
bmf-techをリプレースして以来、初めての障害であった。