概要
自社のメンバーからWebServerに反映できないと連絡を受け対応した。
ベストプラクティスでは無いと思うのであくまでご参考程度に読んでいただけると幸いです。
備忘録として記事に残しておく。
現状を知る
メンバーからディスク容量が一杯というエラーが出ますと言われていたのでとりあえずEC2上のディスク容量を確認してみる。
[サーバー上のアプリディレクトリ内]$ df -h
案の定ディスク容量が枯渇していた。
ファイルシス サイズ 使用 残り 使用% マウント位置
/dev/xvda1 493G 0G 493G 100% /
devtmpfs 490M 56K 490M 1% /dev
tmpfs 498M 0 498M 0% /dev/shm
どのファイルが容量をたくさん食っているかを調べる
とりあえずホームディレクトリは問題なさそう。
[サーバー上のアプリディレクトリ内]$ sudo du -h --max-depth=1
744M ./backup
8.0K ./shell
24K ./.ssh
8.0K ./.pki
8.0K ./.vim
744M .
ルートディレクトリを見てみる。
/varの使用率が凄い。
[サーバー上のアプリディレクトリ内]$ sudo du -h --max-depth=1 /
56K /dev
45M /lib
476G /var
942M /usr
56M /root
7.4M /bin
24K /tmp
0 /sys
~~ 省略 ~~
492G /
更に深ぼっていく。
apacheのlogファイルが凄いことになっている。
[サーバー上のアプリディレクトリ内]$ sudo du -h --max-depth=1 /var/log
1.8M /var/log/letsencrypt
466GG /var/log/httpd
4.0K /var/log/ntpstats
28M /var/log/audit
8.0K /var/log/mail
176G /var/log
更に更に調べていく。
どうやらapacheのアクセスログがストレージをほぼほぼ独占している状態みたい。
[サーバー上のアプリディレクトリ内]$ sudo ls -lh /var/log/httpd/xxx.com/
合計 466G
-rw-r--r-- 1 root root 405G 1月 5 09:19 access_log
-rw-r--r-- 1 root root 61G 1月 5 09:19 error_log
対処方法
使用していないログファイル&割りと緊急事態だったのでとりあえずログファイルの容量を削りました。
ログファイルのサイズがあまりにも大きいため一度で削除するのは危険と判断し、少しずつ消していくことに。
＊稼働しているWebServerを止めてからApacheのログを削除した方が良いです。
とりあえず2GBだけ削減。
sudo truncate -s 403G /var/log/httpd/xxx.com/access_log
この時にはWebServerへの反映は行えるようになっていました。
特にapacheの再起動等は行わなくても大丈夫でした。
問題ないと判断し、100GB分のログは残るようにして、50GBずつ削除していきました。
sudo truncate -s 350G /var/log/httpd/xxx.com/access_log
今後、枯渇しないようにする
apacheのaccess_logは今後も必要ないと判断し、cronで定期的に100GB分のログだけ残して(これでもかなり多いが)削除していくようにしました。
0 0 * * * /usr/bin/sudo truncate -s 100G /var/log/httpd/xxx.com/access_log
このサーバーの時間設定がUTCの為、日本時間の朝9時にこのコマンドが走る。
本来ならばapacheのlogrotateを使用して保存から30日経過したログファイルは削除みたいな感じでやった方が良さそうですが、、。
最後に
今回は緊急事態でしたが焦らずに対応できてよかったです。
ではまたっ！！