ステータス

解決

事象

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などから集計できるように調整していないため調査しづらい。

原因

ファイルシステムに空きがないのが原因であった。

対応

ファイルシステム容量を圧迫しているデータを削除し、空き容量を確保。

アクション

1. サーバーにsshし、dfコマンドでディスクの空き容量を確認。空き容量がなかった。

   df -h
   

2. duコマンドでディスクを一番使っていそうな箇所を調査。/var/lib/docker/配下であると特定。

   du -sh /var/lib/docker*
   

3. 使用されていないdockerオブジェクトを削除して、空き容量を確保。

   docker system prune -a
   

4. ついでに2番目くらいに容量を食っていたjournalのログも200M残して削除。

   journalctl --vacuum-size=200M
   

追記

上記の対応だけでは不十分だった。

/var/lib/docker/containers 配下に溜まっているログファイルが容量を大きく取っていたので、コンテナのログローテーションを調整することで対応した。

ex. 
  app:
    container_name: "app"
    logging:
      driver: "json-file"
      options:
        tag: "{{.ImageName}}|{{.Name}}|{{.ImageFullID}}|{{.FullID}}"
        max-size: "10m" // ロールオーバーするファイルサイズ
        max-file: "3" // ログが何回ロールオーバされたら破棄するか

この対応により容量に大きく余裕を持つことができた。一番のボトルネックがここであったということ。。。

再発防止

ファイルシステムの利用率をアラートに追加。事前に逼迫を検知して対処できるようにした。

その他

削除できるデータやローテーションすべきデータを洗い出して節約できるようにしたい。

所感

bmf-techをリプレースして以来、初めての障害であった。