サーバー更新後に確認すべき監視とチェック項目｜直後の確認から数日間の経過観察まで

Linuxサーバーのパッケージ更新は、apt upgrade や dnf upgrade が成功しただけでは終わりではありません。更新直後に「サービスが動いているか」「古いプロセスが残っていないか」「設定ファイルが置き換わっていないか」を確かめ、その後数日は普段と違う動きがないかを監視して、初めて安全に完了したといえます。この記事では、更新前に取っておく記録、更新直後のチェック項目、再起動の要否の判断、数日間の経過観察、問題が出たときの戻し方までを、Ubuntu・Debian と RHEL系（AlmaLinux・Rocky Linux など）の両方のコマンドで解説します（2026年10月現在）。

更新前に「平常時の状態」を記録しておく

更新後のチェックで一番困るのは、「これは更新のせいなのか、もともとそうだったのか」が分からないことです。比べる相手がなければ異常に気づけないため、更新の前に今の状態を保存しておきます。

mkdir -p ~/update-check && cd ~/update-check
systemctl list-units --type=service --state=running --no-legend > services-before.txt
ss -tlnp > ports-before.txt
uname -r > kernel-before.txt

あわせて、仮想サーバーならスナップショット、そうでなければ設定ファイル（/etc）とデータのバックアップを取っておきます。特にデータベースやWebサーバーの主要なバージョンが上がる更新では、戻せる手段を用意してから始めてください。何が更新されるかは事前に一覧できます。

# Ubuntu / Debian
sudo apt update && apt list --upgradable

# RHEL系
sudo dnf check-update

更新直後に確認すること

1. 停止・失敗したサービスがないか

最初に、起動に失敗したサービスがないかを確認し、更新前の一覧と比べます。

systemctl --failed
systemctl list-units --type=service --state=running --no-legend > services-after.txt
diff services-before.txt services-after.txt
ss -tlnp > ports-after.txt
diff ports-before.txt ports-after.txt

diff で消えているサービスや、待ち受けしなくなったポートがあれば、そこが調べる対象です。

2. エラーログ

更新の時間帯に出たエラーを、journald から重要度で絞り込んで確認します。

journalctl -p err --since "1 hour ago" --no-pager
journalctl -u nginx -u php8.3-fpm --since "1 hour ago" --no-pager

ユニット名は環境に合わせて置き換えてください。PHP-FPM のユニット名はバージョンを含むことが多く（Ubuntu の php8.3-fpm など）、ディストリビューションのアップグレードでPHPのバージョンが変わると、ユニット名やソケットのパスも変わります。Webサーバー側の設定が古いソケットを指したままだと、502エラーの原因になります。

3. 設定ファイルの差し替え

パッケージ更新で設定ファイルの新しい版が届いたとき、管理者が編集していたファイルは上書きされず、新しい版が別名で置かれることがあります。逆に、古い版が別名で退避されて新しい版に入れ替わることもあります。どちらも見落とすと、新機能や必要な設定が反映されなかったり、独自の設定が消えたりします。

# Ubuntu / Debian
sudo find /etc -name '*.dpkg-dist' -o -name '*.dpkg-old' -o -name '*.ucf-dist'

# RHEL系
sudo find /etc -name '*.rpmnew' -o -name '*.rpmsave'

見つかったファイルは、現在の設定と diff で比べ、必要な変更を手で取り込みます。

4. 設定の構文チェック

サービスを再起動する前に、設定の構文を検査します。構文エラーのまま再起動すると、サービスが起動せずに停止時間が延びます。

sudo nginx -t
sudo apachectl configtest        # Apache の場合
sudo php-fpm8.3 -t               # RHEL系では php-fpm -t
sudo postfix check               # メールサーバーの場合

5. 外から見た動作確認

サーバーの中で動いていても、利用者から見て正常とは限りません。実際にHTTPで応答を確認し、ステータスコードと応答時間を記録します。

curl -sS -o /dev/null -w '%{http_code} %{time_total}s\n' https://example.com/
curl -sS -o /dev/null -w '%{http_code} %{time_total}s\n' https://example.com/wp-login.php

WordPressを動かしているなら、トップページだけでなく管理画面へのログイン、フォームの送信、問い合わせメールの送信まで確認しておくと、PHPの拡張モジュールの欠落やメール設定の問題に早く気づけます。

再起動が必要かどうかを判断する

ライブラリやカーネルを更新しても、すでに動いているプロセスは古いファイルを使い続けます。セキュリティ更新を本当に効かせるには、該当するサービスの再起動、場合によってはOSの再起動が必要です。

# Ubuntu / Debian：OS再起動が必要なら次のファイルが作られる
cat /var/run/reboot-required /var/run/reboot-required.pkgs 2>/dev/null

# 古いライブラリを使い続けているサービスの一覧（needrestart が入っている場合）
sudo needrestart -r l

# RHEL系：OS再起動の要否（終了コード1なら再起動が必要）
sudo dnf needs-restarting -r
sudo dnf needs-restarting -s      # 再起動が必要なサービス

Ubuntu Server では needrestart が標準で入っていることが多く、apt upgrade の後に再起動を勧めるサービスを表示します。RHEL系の needs-restarting は dnf のプラグイン（dnf-plugins-core）に含まれています。

カーネルを更新した場合は、再起動後に uname -r で新しいカーネルで起動しているかを確認し、記録しておいた kernel-before.txt と比べます。再起動後にサーバーが戻らない事態に備え、VPSのコンソール機能へアクセスできることを事前に確認しておくと安心です。

数日間の経過観察で見る項目

更新直後には問題がなくても、時間がたってから現れる不具合があります。メモリーリーク、ログの増え方の変化、夜間のバッチだけが失敗する、といったものです。更新後の数日間は、次の項目を普段より注意して見ます。

• エラー率：Webサーバーのアクセスログに占める5xxの割合が、更新前より増えていないか
• 応答時間：平均だけでなく、遅いリクエストの割合が悪化していないか
• メモリー使用量：少しずつ増え続けていないか（リークの兆候）
• CPU・ロードアベレージ：同じアクセス量で負荷が上がっていないか
• 定期処理：cronやsystemdタイマーのバックアップ・証明書更新が成功しているか
• ディスク：ログの急増で空き容量が減っていないか

5xxの割合は、アクセスログから簡単に集計できます。

# 直近10万行のステータスコード別件数（combined 形式のログを想定）
tail -n 100000 /var/log/nginx/access.log | awk '{print $9}' | sort | uniq -c | sort -rn | head

Zabbix や Prometheus などの監視ツールを使っている場合は、更新した日時をグラフに注記しておくと、後から変化と更新を結びつけやすくなります。監視の仕組みがまだない場合でも、sar（sysstat）を入れておけば過去のCPU・メモリー・I/Oの推移を後から確認できます。

問題が出たときの戻し方

更新が原因と分かったら、まずどのパッケージがいつ更新されたかを確認します。

# Ubuntu / Debian
less /var/log/apt/history.log
grep ' upgrade ' /var/log/dpkg.log | tail -n 30

# RHEL系
sudo dnf history
sudo dnf history info last

RHEL系では dnf history undo <ID> で、特定の更新をまとめて取り消せます（古い版がリポジトリに残っている場合に限ります）。Ubuntu・Debian では apt install パッケージ名=バージョン で特定のバージョンに戻し、apt-mark hold パッケージ名 で再び更新されないよう固定します。固定したパッケージはセキュリティ更新も受け取らなくなるため、原因が解消したら apt-mark unhold で解除することを忘れないようにしてください。

戻しても直らない場合や、複数のパッケージが絡んでいる場合は、更新前に取ったスナップショットから戻すのが最も早い手段です。

自動更新を使っている場合

unattended-upgrades（Ubuntu・Debian）や dnf-automatic（RHEL系）で自動更新している場合、更新は気づかないうちに行われます。そのため、上のチェックを手作業で行う代わりに、次のような仕組みを用意しておきます。

• 自動更新のログ（Ubuntu・Debian では /var/log/unattended-upgrades/）を定期的に確認する
• systemctl --failed の結果や、外形監視（HTTPの死活監視）の失敗を通知する
• 再起動が必要な状態が長く続いていないかを確認する

まとめ

• 更新前にサービス・ポート・カーネルの状態を記録し、スナップショットかバックアップを取る
• 更新直後は失敗したサービス、エラーログ、.dpkg-dist・.rpmnew などの設定ファイル、構文、外からの応答を確認する
• needrestart や dnf needs-restarting で、再起動が必要なサービスとOS再起動の要否を判断する
• その後数日は、エラー率・応答時間・メモリー・定期処理の成否を普段より注意して見る
• 問題が出たら更新履歴から原因のパッケージを特定し、戻すか固定する。固定は原因の解消後に外す

• journalctlでLinuxのログを確認する方法
• Linuxカーネルのセキュリティアップデートの適用方法