これは私がSE時代に経験した実話です。ログを見れば数日前から異常の兆候が出ていたのに、「動いている」という表面上の事実だけを信じてしまった。
この記事では、20年近くLinuxサーバーを運用してきた経験から、「動いている」を鵜呑みにする危険性と、トラブルを未然に防ぐ監視と確認の習慣を解説します。
この記事のポイント
・「動いている」と「正常に動いている」は全く違う
・ログの異常兆候を見逃すと障害が突然やってくる
・確認の習慣を持つエンジニアは現場で圧倒的に信頼される
・今日から始められる3つの監視・確認の習慣
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
「動いている」は「正常」の証拠にならない
Linuxサーバーには「グレーな状態」が存在します。完全に止まっているわけではないが、確実に正常でもない。そういう状態です。たとえば、Webサーバーがリクエストには応答しているが、レスポンスが通常の3倍遅い。メールサーバーが稼働しているが、キューにメールが数千通溜まっている。cronジョブが実行されているが、途中でエラーを吐いて処理が中断している。
こういった「動いてはいるが正常ではない」状態を放置すると、ある日突然サービスが止まります。突然に見えるだけで、実際には何日も前から予兆が出ていた。私が現場でよく見かけるのが、このパターンです。
1. ディスク使用率が静かに100%に近づく
受講生からよく聞かれる質問の一つに「ある日突然サーバーが動かなくなった」というものがあります。原因を調べると、ディスク使用率が100%になっていたというケースが非常に多い。ログファイルは毎日少しずつ増えていきます。1日に数MBでも、1年放置すれば数GBになる。logrotateが正しく設定されていなければ、ある日ディスクが埋まってサービスが停止します。
# ディスク使用率の確認（dfコマンド） $ df -h Filesystem Size Used Avail Use% Mounted on /dev/sda1 50G 47G 3.0G 94% / /dev/sda2 200G 180G 20G 90% /var
2. エラーログが毎日同じ警告を出し続けている
もう一つ多いのが、ログに警告が出続けているのに誰も気づいていないケースです。# /var/log/messagesに毎日出ていた警告の例 Apr 10 03:15:01 sv01 systemd: Started Session 15432 of user root. Apr 10 03:15:02 sv01 backup.sh[28451]: WARNING: /backup is 89% full Apr 10 03:15:03 sv01 backup.sh[28451]: backup completed with warnings
3. プロセスが「ゾンビ」になっている
psコマンドで確認すると、STATがZ（Zombie）になっているプロセスが数十個溜まっている。これはゾンビプロセスと呼ばれる状態で、親プロセスが子プロセスの終了を正しく処理できていないことを意味します。# ゾンビプロセスの確認 $ ps aux | grep defunct root 12345 0.0 0.0 0 0 ? Z Apr08 0:00 [old_script]
root 12346 0.0 0.0 0 0 ? Z Apr08 0:00 [old_script] root 12347 0.0 0.0 0 0 ? Z Apr09 0:00 [old_script]
SE時代に「動いている」を信じて失敗した話
2003年頃、私は客先常駐のSEとしてあるメールサーバーの運用を担当していました。Postfixで構築されたサーバーで、毎日数千通のメールを処理していた環境です。ある金曜の夕方、上司から「メールサーバーは正常か」と聞かれ、「はい、問題ありません」と答えました。実際、その時点でPostfixのプロセスは動いていたし、テストメールも送受信できていました。
しかし月曜の朝、出社すると大騒ぎになっていました。取引先へのメールが金曜の夜から一通も届いていない。調べてみると、メールキューに数千通のメールが溜まっていた。
# 当時確認したメールキューの状態（再現イメージ） $ mailq | tail -1 -- 3842 Kbytes in 2847 Requests.
このとき学んだのは、「プロセスが動いている」と「サービスが正常に機能している」は全く別の問題だということです。金曜の夕方にmailqコマンドを一度叩いていれば、キューの異常に気づけたかもしれない。あの失敗は20年以上経った今でも忘れられません。
「確認の習慣」を持つエンジニアは何が違うのか
セミナーで3,100名以上を指導してきた中で、現場で信頼されるエンジニアとそうでないエンジニアの間に、ある明確な違いがあることに気づきました。それは「確認する習慣」を持っているかどうかです。
信頼されるエンジニアは、言われなくても毎朝サーバーの状態を確認します。ディスク使用率、メールキュー、エラーログ、プロセスの状態。5分もかからない確認作業ですが、これを毎日やっている人と全くやらない人では、トラブルへの対応速度が全く違います。
トラブルが起きてから慌てて調べる人は、まずサーバーの「正常な状態」を知りません。だから何が異常なのかの判断に時間がかかる。一方、毎日確認している人は「いつもと違う」ことに瞬時に気づける。この差は技術力の差ではなく、習慣の差です。
今日から始められる3つの確認習慣
1. 毎朝5分の「サーバー巡回」を習慣にする
出社したら、担当サーバーで以下の4つを確認する習慣をつけてください。# 毎朝の確認コマンド（5分で終わる） # 1. ディスク使用率 $ df -h # 2. メモリ・スワップ使用率 $ free -h # 3. 直近のエラーログ（最新20行） $ tail -20 /var/log/messages # 4. 異常プロセスの有無 $ ps aux | head -5 $ uptime
Linuxのポート状況を確認する方法やfreeコマンドでメモリ使用状況を確認する方法も併せて読んでおくと、確認作業の精度が上がります。
2. cronジョブの「結果」を確認する仕組みを作る
cronで定期実行しているジョブは、「登録した」だけで安心してはいけません。ジョブが正常に完了しているかを確認する仕組みが必要です。最もシンプルな方法は、ジョブの最後にログを書き出すことです。
# cronジョブの出力をログに記録する例 0 3 * * * /opt/scripts/backup.sh >> /var/log/backup.log 2>&1 # ログの確認（翌朝に実施） $ tail -5 /var/log/backup.log 2026-04-11 03:00:01 [INFO] backup started 2026-04-11 03:12:45 [INFO] backup completed successfully (12m44s)
cronのログを確認する方法で、cronの実行履歴の確認方法も詳しく解説しています。
3. 「異常の基準」を数値で決めておく
「なんとなくおかしい」ではなく、「この数値を超えたら対処する」という基準を事前に決めておくことが大切です。・ディスク使用率：80%で要注意、90%で即対応
・メモリ使用率：スワップが継続的に発生したら調査
・ロードアベレージ：CPUコア数の2倍を超えたら原因を確認
・メールキュー：100通以上が30分以上滞留したら調査
基準は環境によって異なりますが、重要なのは「数値で判断できる状態」を作ることです。感覚ではなくデータで判断する。これがプロのサーバー管理者の考え方です。
ロードアベレージの読み方については、Linuxのロードアベレージを確認・理解する方法で詳しく解説しています。
まとめ
| 確認すべきポイント | 具体的なアクション | 防げるトラブル |
|---|---|---|
| ディスク使用率 | df -h を毎朝実行 |
ディスク枯渇によるサービス停止 |
| エラーログ | tail -20 /var/log/messages で警告を確認 |
警告の放置が招く障害の見逃し |
| cronジョブ | ログ出力を設定し、翌朝に結果を確認 | ジョブ失敗の長期放置 |
| 異常の基準 | ディスク80%・スワップ継続などの閾値を事前設定 | 感覚頼みの判断ミス |
毎朝5分の確認を続けてください。ディスク、ログ、プロセス、cronの結果。たったこれだけの習慣が、あなたと「再起動で直そうとする人」の間に決定的な差を生みます。
「とりあえず再起動」が危険な理由でも解説しましたが、トラブル対応の第一歩は「現状を正確に把握すること」です。確認の習慣は、その基盤になります。
Linuxサーバーの「正しい見方」を身につけたい方へ
「サーバーの状態確認って、何を見ればいいのか分からない」「障害が起きてから慌てて調べている」。そのような悩みは、正しい手順で体系的に学べば解決できます。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として15年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 次のページへ：Linuxエンジニアとして「一人前」になるまでに必ず越える3つのステージ｜3,100名を指導した現役講師が語るキャリアの節目
- 前のページへ：Linuxサーバーの「引き継ぎ地獄」を防ぐ3つの習慣｜現役講師が現場で学んだ属人化対策
- この記事の属するカテゴリ：Linux学習ガイドへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます