「いつの間にかハードディスク一杯になってた・・・」
運用側が10:0で言い訳出来ない障害の一つなんじゃないでしょうか。
怖い先輩(上役)に体育館裏(会議室)に連れていかれる恐怖を思い出します。
運管ミドルを入れて監視していても監視データを長く保存過ぎたのが原因で一杯になったりすると「ブルータス、お前もか」と思ってしまいます。
こんなことが起こらないように本番環境に移行する前にリスクは取り除いておきたいところです。
メジャーなHDD枯渇原因として挙げならこんなケースがあります。
- 運用中システムのファイルアップロード機能
- 立ち上げっぱなし運用ミドルのログ(loglotateしていない)
- HDDパーテーション見積もりミス
- Zabbix等の運管ミドルでデータ保持期間見積もりミス
- 長期間運用による塵積もり
不幸にも一杯になった時はどこのディレクトリがディスクを喰っているのかコマンドを実行して調べます。
ディスクを喰っているルートディレクトリの特定
「du -sh /*」コマンドで大まかなあたりをつけます。
# du -sh /*
0 /bin
191M /boot
0 /dev
43M /etc
73M /home
0 /lib
0 /lib64
0 /media
0 /mnt
332M /opt
0 /proc
270M /root
178M /run
0 /sbin
0 /srv
0 /sys
68K /tmp
3.9G /usr
450.0G /var <-- 怪しい
ディレクトリを一つずつ掘り下げていく
サイズの大きいディレクトリにcdしながら「du -h –max-depth=1」して容量を喰っている箇所をを突き留めます。
(*)macの場合、コマンドは「du -h -d 1」。
# du -h --max-depth=1
4.0K ./tmp
223M ./lib
449.0G ./log <-- 怪しい
0 ./adm
1.8G ./cache
8.0K ./db
0 ./empty
0 ./games
0 ./gopher
0 ./local
0 ./nis
4.0K ./opt
0 ./preserve
124K ./spool
0 ./yp
0 ./kerberos
0 ./crash
原因を見つけたら
原因となる大きなファイルを見つけたら削除可否を鑑みて削除するか他PCにバックアップ。DBファイルなら保存量の設定をチューニングするかHDD追加します。
ログとDBファイルが大抵犯人
本番運用環境ではディスク容量監視していてもdevelopmentやstagingの開発環境は監視していないケースは結構あったりします。
tomcatを内包したミドルはlogrotate設定されていなくて/var/logが肥大しがちで、ZabbixのDBデータなども保存期間を設定しないと肥大しがちです。
ステージング環境でシステムに負荷をかけてドッグフーディングしたらディスク容量を確認、本番環境での保存量を見積もるのが肝要ですね。
開発環境で傾向が分かっていれば本番の閾値を設定するのも楽になります。
あとzabbixやnagiosみたいな無料運管ミドルを入れていれて警告メールを出すようにしていても、あまり危機感の無い開発環境の場合は形骸化してしまうので、本当にまずい閾値を超えたケースはチャットに投げるようにするなどの工夫をしておいた方が良いですね。
ちょっと面倒でも体育館裏に行くことは避けられます。