こんにちは。Takitaです。

Webサービスのデプロイがこけると連絡を受けて対応しました。
ぼくはインフラエンジニアでもなくインフラの知見があまりないので調べながら対応した内容をまとめておきます。

エラーログを確認する

デプロイでこけたという話だったのでデプロイのログを確認しました。

mkdir stdout: mkdir: cannot create directory ‘/var/www/app_name/releases/20170613042031’: No space left on device

No space left on device は

通常ファイルの書き込み時またはディレクトリエントリの作成時に、デバイスに空き領域が残っていません。ディスク、テープ、またはフロッピーディスクがデータでいっぱいです。この状態のときに書き込まれたすべてのデータが失われる可能性があります。
https://docs.oracle.com/cd/E19455-01/806-2720/msgs-601/index.html

ということです。

ディスク容量を調査する

サーバーに入ってディスク容量を確認しました。
まず、ディスク・ドライブの使用量を表示して確認します。

$ df
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/xvda1       8115168 7679888         4 100% /
none                   4       0         4   0% /sys/fs/cgroup
udev             4082848       8   4082840   1% /dev
tmpfs             817564     348    817216   1% /run
none                5120       0      5120   0% /run/lock
none             4087808       0   4087808   0% /run/shm
none              102400       0    102400   0% /run/user

/ が100%になっています。

暫定対応

/ 以下の不要なファイルを削除して容量を確保します。
削除対象のファイルを洗い出すために容量を食っていそうなディレクトリを一覧にします。

$ sudo du -x -h / | sort -r -h | head -40

どれも必要そうなフォルダっぽいので容量の大きいフォルダの一覧の中から、
不要なファイルが格納されていそうなログ関連のフォルダを見つけます。

$ sudo du -x -h / | sort -r -h | head -40 | grep log
1.3G    /var/log/nginx
1.3G    /var/log

これらのフォルダに入って ll でいらなそうなファイルかつ容量が大きいものから順に rm していきました。

恒久対応

今回は暫定対応だけ行いました。

今回はそもそもローテートされていないログファイルがあったりしたことが原因のひとつだったので、
ちゃんとログファイルはローテートするなどの対応が必要だと思います。
ログファイルのローテートを行っていても容量が逼迫する場合は、ディスク容量を増やすなどの対策が必要です。

参考

https://docs.oracle.com/cd/E19455-01/806-2720/msgs-601/index.html
https://serverfault.com/questions/330532/xvda1-is-100-full-what-is-it-how-to-fix