Redashにつながらなくなった時の調査メモ

Redashが落ちてたのでその時の調査と対応の記録。

前提

• EC2で運用
• 冗長化はしていない
• 公式のAMIを使用（つまりdocker-composeで動かすスタイル）

事象

ブラウザでRedashの固定IPアドレスを叩くと画面が真っ白。

原因のあたりをつける

真っ白な画面は返ってくるので、サーバーが落ちてるわけではなさそう🤔

事実、curlで確認するとステータスは200。

サーバーは生きてるがコンテンツがないレスポンスを返している？

この辺りの事情はこれ以上あたりがつけられないが、なんとなくどうせNo space left on deviceだろうなと思った。

というのも、起動時間が。

sshして調査

公式イメージはUbuntuベースなので、ec2-user@x.x.x.xではなく、ubuntu@x.x.x.xになる。

ディスクの容量を確認。

ubuntu@ip-192-168-170-114:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p1  7.7G  7.7G     0 100% /

やっぱりというお気持ち。
ちなみに8GBのEBSがアタッチされている。

何が占めているのか調査。
抜粋すると

$ sudo du -h -d 1 /
4.8G   /var
2.4G   /usr
8.4G   /

/var/logあたりだろうなと思っていたのでまあvarはよしとして（実際は/var/lib/docker/だったが）、/usr/srcが結構占めていた。

$ ls /usr/src
linux-aws-5.3-headers-5.3.0-1017
linux-aws-headers-4.15.0-1021
linux-aws-headers-4.15.0-1047
linux-aws-headers-4.15.0-1048
linux-aws-headers-4.15.0-1050
linux-aws-headers-4.15.0-1051
linux-aws-headers-4.15.0-1052
linux-aws-headers-4.15.0-1054
linux-aws-headers-4.15.0-1056
linux-aws-headers-4.15.0-1057
linux-aws-headers-4.15.0-1058
linux-aws-headers-4.15.0-1060
linux-aws-headers-4.15.0-1063
linux-aws-headers-4.15.0-1065
linux-headers-4.15.0-1021-aws
linux-headers-4.15.0-1065-aws
linux-headers-5.3.0-1017-aws
linux-headers-5.3.0-1019-aws

カーネルの自動アップデートによるゴミが残ってしまっているので削除する。

sudo apt-get -y autoremove
sudo apt-get -y autoclean

が、空き容量が全くないために以上のコマンドはtmpファイルすら作れずに失敗する。

仕方がないので一時的にEBSを拡張する。
マネジメントコンソールから10GBに拡張を行う。

しばらく待って、適用が完了したらファイルシステムの拡張を行う。

$ lsblk
NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
loop0         7:0    0   18M  1 loop /snap/amazon
loop1         7:1    0 93.9M  1 loop /snap/core/9
loop2         7:2    0 93.8M  1 loop /snap/core/8
loop3         7:3    0   18M  1 loop /snap/amazon
nvme0n1     259:0    0   10G  0 disk
└─nvme0n1p1 259:1    0    8G  0 part /

今回はパーティション(nvme0n1p1)があるので、先にパーティションの拡張が必要。

$ sudo growpart /dev/nvme0n1 1
mkdir: cannot create directory ‘/tmp/growpart.2200’: No space left on device
FAILED: failed to make temp dir

そうかあああああこれも空き容量必要なのかあああああ。

仕方ないので先に空き領域を適当に確保する。
ジャーナルログをローテートしてしまおう。

$ journalctl --vacuum-time=7d

これで300MBくらい空きができた。
（EBS拡張する必要なかったね）

戻すのも面倒なのでEBSはそのままで10GBで使います。

$ sudo growpart /dev/nvme0n1 1
CHANGED: partition=1 start=2048 old: size=16775135 end=16777183 new: size=20969439,end=20971487

$ lsblk
NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
loop0         7:0    0   18M  1 loop /snap/amazon
loop1         7:1    0 93.9M  1 loop /snap/core/9
loop2         7:2    0 93.8M  1 loop /snap/core/8
loop3         7:3    0   18M  1 loop /snap/amazon
nvme0n1     259:0    0   10G  0 disk
└─nvme0n1p1 259:1    0   10G  0 part /

パーティションが拡張できたのでファイルシステムをリサイズ。

$ sudo resize2fs /dev/nvme0n1p1
resize2fs 1.44.1 (24-Mar-2018)
Filesystem at /dev/nvme0n1p1 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 2
The filesystem on /dev/nvme0n1p1 is now 2621179 (4k) blocks long.

$ sudo df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p1  9.7G  7.4G  2.3G  77% /

あとは/var/の方を整理します。

/var/lib/docker/overlay2が肥大化していたので、docker system prune -a してdocker再起動して終了。

4.4GBまで減りました。