Zabbixから警告が
仮想マシンのdockerホストのZabbix監視から警告が届きました。
OSはFedora Core OSなので、基本的にはデータを置くことを想定されていないので、docker composeのファイルとかはNASをNFSマウントして使ってます。
あとは永続ストレージのデータをホスト内に置いているものの、設計上全体容量を80%超えるほどのデータは格納していないはず。。。
となると何がデータ容量を食っているのか。
容量確認
おそらく犯人はdockerのイメージのごみとかだろうと思いつつ、状況確認。
$ df -h
Filesystem Size Used Avail Use% Mounted on
composefs 5.0M 5.0M 0 100% /
/dev/sda4 128G 109G 19G 86% /etc
devtmpfs 4.8G 0 4.8G 0% /dev
tmpfs 4.9G 0 4.9G 0% /dev/shm
efivarfs 256K 209K 43K 84% /sys/firmware/efi/efivars
tmpfs 2.0G 4.5M 2.0G 1% /run
tmpfs 4.9G 16K 4.9G 1% /tmp
tmpfs 1.0M 0 1.0M 0% /run/credentials/systemd-journald.service
/dev/sda3 350M 287M 40M 88% /boot
tmpfs 1.0M 0 1.0M 0% /run/credentials/systemd-resolved.service
tmpfs 1.0M 0 1.0M 0% /run/credentials/getty@tty1.service
*****NAS*****
*****NAS*****
tmpfs 892M 4.0K 892M 1% /run/user/1001まぁこれだけではわからないので、docker関係の容量を確認します。
docker system dfで確認できます。
$ docker system df
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 78 30 76.73GB 27.87GB (36%)
Containers 32 32 4.521GB 0B (0%)
Local Volumes 38 2 928.8MB 928.8MB (99%)
Build Cache 115 0 5.866GB 3.669GBdocker関係の不要ファイル削除
不要イメージなど
まずはdockerのコマンドで使用していないファイルを削除します。
docker system pruneを実行します。
$ docker system prune
WARNING! This will remove:
- all stopped containers
- all networks not used by at least one container
- all dangling images
- unused build cache
Are you sure you want to continue? [y/N] y
Deleted Networks:
**********
Deleted Images:
**********
Deleted build cache objects:
**********
Total reclaimed space: 13.66GB13.66GBもいらぬファイルが。。。
これでだいぶ状況が改善しました。
$ df -h
Filesystem Size Used Avail Use% Mounted on
composefs 5.0M 5.0M 0 100% /
/dev/sda4 128G 62G 67G 49% /etc
devtmpfs 4.8G 0 4.8G 0% /dev
tmpfs 4.9G 0 4.9G 0% /dev/shm
efivarfs 256K 209K 43K 84% /sys/firmware/efi/efivars
tmpfs 2.0G 4.5M 2.0G 1% /run
tmpfs 4.9G 16K 4.9G 1% /tmp
tmpfs 1.0M 0 1.0M 0% /run/credentials/systemd-journald.service
/dev/sda3 350M 287M 40M 88% /boot
tmpfs 1.0M 0 1.0M 0% /run/credentials/systemd-resolved.service
tmpfs 1.0M 0 1.0M 0% /run/credentials/getty@tty1.service
*****NAS*****
*****NAS*****
tmpfs 892M 4.0K 892M 1% /run/user/1001SPONSORED
ビルドキャッシュ
あとはビルドキャッシュも削除できます。
docker builder pruneを実行します。
$ docker builder prune
DEPRECATED: The legacy builder is deprecated and will be removed in a future release.
Install the buildx component to build images with BuildKit:
https://docs.docker.com/go/buildx/
WARNING! This will remove all dangling build cache. Are you sure you want to continue? [y/N] y
Total reclaimed space: 0B今回は特に削除対象はありませんでした。
ログファイル
あとはdockerのログファイルっていうのも容量を食う原因です。
sudo find /var/lib/docker/containers/ -name "*.log" -exec du -h {} + | sort -hを実行します。
$ sudo find /var/lib/docker/containers/ -name "*.log" -exec du -h {} + | sort -h
4.0K /var/lib/docker/containers/339773ce5f7374f31e39b0c038135b91**********d**********8**********/container-cached.log
...ただ、結果はコンテナ名と紐づける必要があります。
そういう場合はコンテナのIDを表示します。
docker ps -q | xargs docker inspect --format '{{.Id}}: {{.Name}}'を実行します。
$ docker ps -q | xargs docker inspect --format '{{.Id}}: {{.Name}}'
339773ce5f7374f31e39b0c038135b91**********d**********8**********: /maintenance
...結果はこのログファイルは「maintenance」という名のコンテナのものです。
サイズ制限等をかけているとよいので、ログが肥大化した場合はサイズ制限を検討するとよいです。
CoreOS関係の不要ファイル削除
CoreOSは自動で最新にアップデートされますが、その時に過去のバージョン情報を保持します。
これはアップデート後に不具合が発生したときに戻すのに有用ですが、しばらく安定稼働しているのであれば削除しても大丈夫です。
ちなみにこれは/bootの容量に効いてきます。
sudo rpm-ostree cleanup -pを実行します。
$ sudo rpm-ostree cleanup -p
Deployments unchanged.今回は特に削除対象がありませんでした。（勝手に消えてる？）
今回はdocker system pruneでばっちり容量を確保できたのでこのくらいにしておきますが、また肥大化したら対策しようと思います。
気づくためにも監視は大事です。