「サーバーが重い」「ログインできない」ときの確認順序
UbuntuやRHEL系Linux(RHEL/CentOS/Rocky Linux/AlmaLinuxなど、企業でよく使われるLinuxの仲間)で問い合わせを受けたときに、負荷・空き容量・サービス・ログ・通信・ログイン・ファイアウォールの順で状態を確認する練習です。ここに掲載した確認コマンドは情報を見るためのもので、設定変更や再起動は別の手順として扱います。
対象読者: Linuxコマンドの経験がない方も対象です。実行環境は2通りあります。1つはUbuntuまたはRHEL系のVM(仮想マシン/パソコンの中に作るもう1台のコンピューター)です。もう1つはWindowsのWSL2(Windowsの中でLinuxを動かす仕組み)と、ターミナル(文字でコマンドを打ち込む画面)です。どちらかを用意してから進めてください。環境をお持ちでない場合は、先に学習環境を0から用意するをご覧ください。
このページの全コマンドを1台の実機で試したわけではありません。2026年8月22日の実行記録で使ったのは、Docker(アプリを箱に入れて動かす仕組み)が事前に入った使い捨てのUbuntu 24.04環境です。そこでは、構築手順の実行、11個のコンテナ(アプリを入れた箱)の起動、通信制限、アプリ復旧、監視データの復元など23項目を確認しました。結果はすべて合格でした。WSL2上で行った監視と復旧の練習は2026年8月17日〜19日の別記録です。詳しい環境と未実施項目は実行記録ページで分けて掲載しています。
最初に覚える「事実を集める」7項目
かんたんに言うとトラブルの連絡を受けても、すぐ直そうとしないでください。まず「今どうなっているか」を7か所だけ順番に見て、事実をメモします。原因を決めつけて、よけいに壊さないための手順です。
いきなり再起動や設定変更をせず、まず状態を読み取ります。順番は状況に合わせて変えて構いませんが、初めは次の合言葉で確認漏れを減らします。
重さ → 空き → 動作 → 記録 → 通信 → ログイン → 防火壁、の順です。
- 重重さ(負荷・メモリ)
uptimeとfree -hで、処理やメモリが混んでいないかを見る。 - 空空き(ディスク)
df -hで、ログやデータを書ける空きがあるかを見る。 - 動動作(サービス)
systemctl --failedで、止まったサービス(OSが裏側で動かし続けるプログラム)がないかを見る。 - 記記録(ログ)
journalctl(OSやサービスが残した記録を読む道具)で、発生時刻とエラー内容を見る。 - 通通信(経路・ポート)
ip routeで通信の通り道を、ss -tulnpで外からの接続を待っている受付口(ポート)を見る。 - 入ログイン(認証)
lastとSSH(離れた場所から安全にサーバーへログインする仕組み)のログで、成功・失敗した接続を見る。 - 壁防火壁(許可ルール)
ufw statusなどで、通信を止めるルールを見る。
まず状態を見ます。次に、確認した時刻と結果を保存します。そのうえで、普段の値や設計と比べます。分からなければ相談します。再起動、削除、権限変更は、影響と戻し方を確認してから行います。
かんたんに言うとこの表は「どこを、どのコマンドで見て、どうなっていたら人に相談するか」の一覧です。数字を暗記するための表ではありません。
下記の数値は一律の正解ではなく、異常の可能性に気づくための目安です。まず普段の状態や設計値(そのシステムで想定している値)と比べます。それでも判断できない場合は、結果を保存して上位担当者へ相談します。
| 対象 | 確認観点 | 主なコマンド | 異常の可能性と相談の目安 |
|---|---|---|---|
| 負荷 | 処理の混み具合 / CPU使用率 / 負荷の高いプロセス | uptimetop -bn1 | head -n 20ps -eo pid,user,pcpu,pmem,etime,comm --sort=-pcpu | head |
5分間の平均負荷(load5)がCPU数を超える状態が続く場合は、普段の値と比べます。特定のプロセスに負荷が集中していれば、結果を添えて担当者へ相談します。 |
| メモリ | 使用量 / 利用可能量 / ディスクへの一時退避(swap) | free -hvmstat 1 5 |
利用可能なメモリが全体の10%を下回る、またはswapの使用が増え続ける場合は、メモリ不足の可能性として相談します。 |
| ディスク | 容量 / 作成できるファイル数(inode) / 読み書きの遅れ | df -hPT -x tmpfsdf -hPi -x tmpfsiostat -x 1 3† |
容量90%以上、inode 80%以上、読み書きの待ち時間が普段より長い状態が続く場合は、結果を保存して相談します。 |
| サービス | 停止・失敗したサービス / 自動起動の設定 | systemctl --failedsystemctl status ssh(Ubuntu)systemctl status sshd(RHEL系)systemctl list-unit-files --state=enabled |
失敗したサービスがあれば記録します。自動起動の設定があるのに停止している場合は、設計上正しい状態かを確認して担当者へ相談します。 |
| ログ | 直近のエラー / 該当サービス / 起動失敗 | journalctl -p err --since "30 min ago"※journalctl -u nginx -n 50dmesg -T --level=err | tail※ |
同じエラーの繰り返し、OS内部の重大エラー、メモリ不足による強制終了があれば、ログと発生時刻を添えて上位担当者へ相談します。 |
| ネットワーク | 通信経路 / 名前解決(DNS) / 接続を待ち受けているポート | ip routeresolvectl statusss -tulnp |
同じネットワーク内でも接続できないのか、別ネットワークへの経路で止まるのかを分けて確認します。 |
| 認証 | SSH接続の失敗 / ログイン履歴 / アカウントのロック | journalctl -u ssh -p warning(Ubuntu)journalctl -u sshd -p warning(RHEL系)last -n 20lastb -n 20※ |
同じIPアドレスからログイン失敗が繰り返されていれば、記録を保存してセキュリティまたはネットワーク担当者へ相談します。 |
| ファイアウォール | 許可されている通信 / ルールの適用状態 | ufw status verbose(Ubuntu)※firewall-cmd --list-all(RHEL系)※iptables -L -n -v※ |
申請にない通信許可、想定外の許可、ルールが設定されていない状態を見つけた場合は、変更せず担当者へ確認します。 |
※ 権限エラー(Permission deniedなど)が出た場合は、root権限(サーバーの管理者権限)が必要な可能性があります。コマンドの前にsudo(管理者として実行する命令)を付けて再実行してください。 † iostatを使うには、sysstatパッケージ(追加ソフトのまとまり)をあとから入れる必要があります(apt install sysstat / dnf install sysstat)。SSHのサービス名は、Ubuntuではssh、RHEL系(RHEL/CentOS/Rocky Linux/AlmaLinuxなど)ではsshdです。ファイアウォール(決めた条件で通信を許可・拒否する関所)は、Ubuntu/Debian系ではufwを使います。RHEL系は標準でfirewalld(操作するコマンドはfirewall-cmd)を使います。
以下は設定内容を理解するための学習例です。実務では、会社の手順、影響範囲、承認の有無を確認してから変更します。
SSH 鍵運用
ssh-keygen -t ed25519で接続用の鍵(ed25519は暗号方式の名前)を作り、鍵を守るパスフレーズを設定します。パスワードの代わりに鍵で本人確認をして、推測による不正ログインを防ぐためです。- サーバー側の鍵ファイルは、ほかの利用者から読まれない権限にします(ファイルは
600=本人だけが読み書きできる、ディレクトリは700=本人だけが読み書きと出入りをできる)。鍵を他人に読まれると、そのまま本人になりすまされるためです。 - パスワード接続や管理者の直接ログインを無効にする場合は、先に別の接続手段を確認してから設定します。設定を間違えると自分もログインできなくなり、その場で戻せなくなるためです。
- 退職・異動時は不要になった鍵を削除し、運用台帳と照合します。
権限・ファイルシステム
chown(ファイルの持ち主を変える)やchmod(読み書きの許可を変える)では、必要な利用者だけが操作できる権限にします。特定の人にだけ個別に権限を追加するときは、ACL(Access Control List/利用者ごとに細かく許可を決める仕組み)のsetfaclを使います。- 例:
setfacl -m u:username:rx /pathで、指定した利用者だけに読み取り・実行権限を追加できます(設定結果はgetfacl /pathで確認)。 - 機密ファイルは専用グループだけが読める権限にし、
ls -laで設定結果を確認します。 - 通常より強い権限(SUID / SGID=実行した人ではなく、ファイルの持ち主や所属グループの権限で動く設定)が付いたファイルは、必要なものか定期的に確認します。不要なものが残っていると、一般の利用者が管理者と同じ操作をできてしまうためです。
cron / systemd timer
- cron(決めた時刻に処理を自動で走らせる仕組み)の設定場所は、OS全体の設定と利用者ごとの設定に分かれます。
- 新しい定期処理は、実行結果をログで追いやすい
systemd timer(Linuxの起動・停止を管理するsystemdが持つタイマー機能)の利用を検討します。 - 定期処理を追加するときは、次の4つを記録します。誰の権限で実行するか、結果をどこへ保存するか、失敗したら何回やり直すか、何分で打ち切るか、です。あとから別の人が引き継げるようにするためです。
logrotate
logrotateは、古いログを一定期間ごとに整理し、ディスク不足を防ぐ仕組みです。- 新しいアプリを追加するときは、ログの保存期間とディスク使用率の監視も決めます。
- 変更前に
logrotate -dを使い、実際には処理せず設定内容だけを確認します。これで「設定を書き間違えていないこと」を、ログを消してしまう前に確かめられたと言えます。
毎日の差分バックアップ例
かんたんに言うと下のスクリプトは、毎日決まった時刻に/etcと/var/wwwを別のディスクへコピーし、30日より古いコピーを消す、という内容です。
同じサーバー内の別ディスクへ、設定ファイルとWebコンテンツを毎日コピーする学習例です。本番環境で実行した実績ではありません。同じサーバー内だけでは機器故障に備えられないため、実務では別の機器や離れた場所にも保存し、定期的に復元できるかを確認します。
実行前の注意: --deleteはバックアップ先の余分なファイルを削除し、末尾のfind ... rm -rfは30日を超えた保存先を削除します。最初は、コピー先をテスト用のディレクトリ(フォルダ)へ変更してください。そのうえでrsync --dry-run(実際にはコピーせず、何が起きるかだけを表示する実行)で、対象と差分を確認してください。いきなり本番のパスで実行すると、必要なファイルまで消えるおそれがあります。
#!/bin/bash
# /usr/local/sbin/daily-backup.sh
SRC1=/etc
SRC2=/var/www
DST=/mnt/backup/$(hostname)/$(date +%Y-%m-%d)
LOG=/var/log/daily-backup.log
mkdir -p "$DST"
rsync -aHAX --delete --numeric-ids \
--link-dest=/mnt/backup/$(hostname)/latest \
"$SRC1" "$SRC2" "$DST"/ 2>&1 | tee -a "$LOG"
ln -snf "$DST" /mnt/backup/$(hostname)/latest
find /mnt/backup/$(hostname) -maxdepth 1 -type d -mtime +30 -exec rm -rf {} +
毎日3時に自動実行する設定例(systemd timer):
# /etc/systemd/system/daily-backup.service [Unit] Description=Daily rsync backup [Service] Type=oneshot ExecStart=/usr/local/sbin/daily-backup.sh # /etc/systemd/system/daily-backup.timer [Unit] Description=Run daily-backup.sh at 03:00 [Timer] OnCalendar=*-*-* 03:00:00 Persistent=true [Install] WantedBy=timers.target
実際に有効化する場合のコマンド例(学習環境での実行を想定)です。daemon-reloadで追加した設定を読み直し、enable --nowで自動実行の登録とその場での開始を行います:
sudo chmod +x /usr/local/sbin/daily-backup.sh sudo mkdir -p /mnt/backup sudo systemctl daemon-reload sudo systemctl enable --now daily-backup.timer
復元手順と確認計画は、別のバックアップ・復元手順にまとめています。
基本情報を集めるbashスクリプト
ここまでの確認項目を1本にまとめたスクリプト(複数のコマンドを順番に実行する台本ファイル)です。状態を読み取るだけで、設定は変更しません。問い合わせを受けた直後に実行し、結果をテキストとして記録できます。面接や報告では「連絡を受けた時点のサーバーの状態を、手作業の抜けなく記録できる」と説明できます。
関連する学習資料
構築の自動化、クラウドのネットワーク設計、監視、ログ確認、テスト結果を別資料にまとめています。いずれも学習環境で確認できた範囲であり、長期間の実運用実績ではありません。