なぜ「満杯になってから」では遅いのか
ディスクの空きがなくなると、サービスは思いがけない形で壊れます。ログが書き込めずにアプリケーションが止まる、データベースが更新を受け付けなくなる、メールが届かなくなる、そもそもSSHでログインした直後にシェルの設定ファイルすら書けない、といった具合です。しかも原因が「ディスク容量」だと気づくまでに、アプリケーション側のバグを疑って時間を失うことも少なくありません。
容量不足は、突然起きるように見えて、実際にはじわじわと進行していることがほとんどです。つまり、日ごろから変化に目を向けていれば、止まる前に手を打てる種類のトラブルです。この記事では、特別なツールを入れなくても始められる「気づくための習慣」を整理します。
まずは現状を知る：2つのコマンド
最初に覚えておきたいのは、使用量を見る df と、どこが大きいかを探す du の2つです。
df -h：ファイルシステムごとの容量、使用量、使用率を人間に読みやすい単位で表示します。du -sh /var/log/*：指定したディレクトリ配下の項目ごとの合計サイズを表示します。「どこが太っているか」を順にたどって絞り込めます。df -i：inode の使用状況を表示します。
見落としやすいのが最後の inode です。小さなファイルが大量にできると、容量には余裕があるのに新しいファイルが作れなくなることがあります。セッション情報やキャッシュ、メールキューなどを大量に生成するシステムでは、容量とあわせて確認しておくと安心です。
習慣その1：使用率ではなく「増え方」を見る
使用率70%という数字だけでは、安全かどうか判断できません。1年かけて70%になったのか、先週まで30%だったのかで、意味がまったく違うからです。そこで、使用量を定期的に記録して、増加のペースを見る習慣をつけます。
難しく考える必要はありません。cronで1日1回、日付と df の結果をファイルに追記するだけでも十分です。数週間たまると、「このペースなら何日後に埋まりそうか」がおおまかに見えてきます。グラフ化できる監視ツールがあればなお良いですが、まずは素朴なテキストの記録でも、何も見ていない状態とは大きな差があります。
習慣その2：しきい値を2段階にして通知する
通知は「警告」と「危険」の2段階に分けておくと運用しやすくなります。たとえば次のような考え方です。
- 警告：使用率が一定の水準を超えたら、翌営業日までに確認すればよい通知として届ける。
- 危険：さらに高い水準に達したら、すぐ対応が必要な通知として届ける。
具体的な数値は、ディスクの大きさや増加ペースによって適切な値が変わります。数百GBのディスクで残り10%といえば数十GBの余裕がありますが、小さなディスクでは同じ10%でも数日で消えてしまうかもしれません。使用率だけでなく、残り容量の絶対値や「あと何日もつか」で考えるのが現実的です。
また、通知が多すぎるとやがて誰も見なくなります。最初はゆるめのしきい値で始め、実際に空振りが続くようなら調整するくらいの気持ちで十分です。
習慣その3：増えやすい場所をあらかじめ知っておく
容量を食う場所は、システムによってある程度パターンが決まっています。自分の環境で次の場所を一度見ておくと、いざというときに慌てません。
- ログ：
/var/log配下。ローテーションの設定が効いているか、古いログが残り続けていないかを確認します。 - パッケージのキャッシュ：パッケージ管理ツールが保持しているダウンロード済みファイル。
- コンテナ関連：Docker を使っている場合、未使用のイメージや停止したコンテナ、ボリュームが蓄積します。
- バックアップや一時ファイル：消し忘れた古いバックアップ、
/tmpに残ったままの作業ファイル。 - データベースのデータやバイナリログ：サービスの成長とともに確実に増えていきます。
とくにログは、ローテーションと保持期間を決めておくだけで、多くの問題を未然に防げます。「何日分残すか」を意識的に決めていないログは、いつか必ず大きくなります。
習慣その4：削除したのに空かない問題を知っておく
大きなファイルを消したのに、df の使用量が減らないことがあります。これは、削除したファイルをまだ動作中のプロセスが開いたままにしている場合に起こりえます。ファイル名は消えていても、プロセスが掴んでいる間は領域が解放されません。
このような状況では、lsof などで削除済みのファイルを開いているプロセスを調べられます。ログファイルを手動で消すより、ローテーションの仕組みを使ったり、内容を空にしたりするほうが安全な場合もあります。ただし、本番環境での操作は影響を確認してから行ってください。
習慣その5：消す前に、中身を見る
容量が逼迫すると、焦って大きなものから消したくなります。しかし、何のファイルか確認しないまま削除するのは危険です。データベースのファイルやアプリケーションが参照中のデータを消せば、容量の問題が別の障害に変わります。
消してよいものと、そうでないものの一覧を、平時に簡単なメモとして残しておくと役立ちます。「このディレクトリのキャッシュは消してよい」「ここは触らない」といった一言のメモが、緊急時の判断を支えてくれます。
週5分の点検ルーティンにする
ここまでの内容を、続けやすい形にまとめると次のようになります。
- 週に1回、
df -hとdf -iを確認する。 - 前回からの増え方を見て、気になる場合は
duで原因の場所を絞る。 - ログのローテーションが動いているかを時々確認する。
- 通知のしきい値が現状に合っているかを、月に一度見直す。
この程度なら、5分もかかりません。大切なのは、完璧な監視体制を一度に作ろうとせず、小さく始めて続けることです。
まとめ
ディスクの空き不足は、前兆のある数少ない障害のひとつです。使用率だけでなく増え方を見ること、通知を段階に分けること、増えやすい場所を把握しておくこと。この3点を押さえるだけで、「気づいたときには止まっていた」という事態はぐっと減らせます。まずは今日、手元のサーバーで df -h を実行してみるところから始めてみてください。
コメントを残す