Linuxサーバー監視の基礎|サーバー状態を見る11項目とコマンド対応表

宮崎智広 この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
HOMELinux技術 リナックスマスター.JP(Linuxマスター.JP)Linuxtips, システム管理 > Linuxサーバー監視の基礎|サーバー状態を見る11項目とコマンド対応表
「サーバーが重い気がする……でも、どこを確認すれば原因がわかるのか」
現場に出たての頃は、こういう状況で何から確認すればいいかわからず、ただログをじっと眺めていた経験がある人も多いはずです。

Linuxサーバーの監視には、押さえておくべき11の確認項目があります。この11項目を順番に確認できれば、たいていのパフォーマンス問題は根本原因にたどり着けます。

この記事では、Linuxサーバー監視の基礎として押さえるべき11項目と、それぞれに対応するコマンドを体系的に解説します。RHEL 9.4 / AlmaLinux 9 / Ubuntu 24.04 LTSで動作確認済みです。

この記事のポイント

・Linuxサーバーの状態は11項目で体系的に把握できる
・top/free/df/ss/journalctlなど標準コマンドで即日対応可能
・アラート設計はメール通知よりsystemdとcronの組み合わせが現実的
・Prometheus連携で長期トレンド監視に発展させられる


「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
図解60P/登録10秒/解除も3秒 / 詳細はこちら

なぜ「11項目」で監視するのか

サーバーの状態を把握するとき、「とりあえずtopを見る」「dfでディスクを確認する」という場当たり的なアプローチをとっていると、確認漏れが出ます。

実際にLinuxサーバーの障害原因を分類すると、次の11項目のどれかに必ず収まります。
CPU使用率:プロセスがCPUを占有していないか
メモリ使用量:スワップへのあふれが起きていないか
ディスク使用率:パーティションが満杯に近くないか
ディスクI/O:ストレージアクセスがボトルネックになっていないか
ネットワーク通信量:帯域の逼迫や異常な通信がないか
プロセス状態:重要なプロセスが死んでいないか
ログ:エラー・警告が発生していないか
サービス稼働:httpd/nginxなどが起動しているか
死活監視:サーバー自体にアクセスできるか
接続数・ポート状態:TCPコネクションが異常に積み上がっていないか
起動時間・ブート状態:再起動が発生していないか、起動に時間がかかっていないか

この11項目を順番に確認するクセをつけると、障害対応の時間が大幅に短くなります。

1. CPU使用率を確認する

1. topコマンドで即時確認

# topを起動してCPU使用率を確認する top # 非インタラクティブに1回だけ出力する場合 top -bn1 | head -20

topの出力の1行目に「%Cpu(s):」があります。「us」がユーザープロセス、「sy」がシステム(カーネル)、「wa」がI/O待ちです。「wa」が高い場合はCPUではなくディスクがボトルネックの可能性があります。

2. mpstatでコアごとのCPU使用率を確認

複数コアのどれが高いかを見たいときはmpstat(sysstat パッケージに含まれる)を使います。

# 全CPUコアの使用率を2秒ごとに5回表示 mpstat -P ALL 2 5

出力例(実サーバーのアウトプット):

Linux 5.14.0-427.26.1.el9_4.x86_64 (server01.example.com) 05/15/2026 Average: CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle Average: all 2.34 0.00 0.89 0.12 0.00 0.01 0.00 0.00 0.00 96.64 Average: 0 4.21 0.00 1.33 0.18 0.00 0.02 0.00 0.00 0.00 94.26 Average: 1 0.47 0.00 0.44 0.06 0.00 0.00 0.00 0.00 0.00 99.03

2. メモリ使用量を確認する

1. freeコマンドで全体把握

# メモリ使用量をMB単位で確認 free -m # GB単位で確認 free -g # 1秒ごとに繰り返し表示(Ctrl+Cで停止) free -m -s 1

実サーバーでの出力例:

total used free shared buff/cache available Mem: 15820 4231 9243 128 2345 11234 Swap: 4095 0 4095

「available」列が実際に使えるメモリの目安です。「Swap」行の「used」が増え始めたら要注意です。スワップを使い始めると、I/Oが激増してサーバーが極端に重くなります。

2. /proc/meminfoで詳細を確認

# メモリの詳細情報を確認 cat /proc/meminfo | grep -E "MemTotal|MemFree|MemAvailable|SwapTotal|SwapFree"

3. ディスク使用率を確認する

1. dfコマンドでパーティションごとの使用率を確認

# ディスク使用率を人が読みやすい単位で表示 df -h # ローカルファイルシステムのみ(NFSなどを除外) df -h -l

出力例(実サーバー):

Filesystem Size Used Avail Use% Mounted on /dev/mapper/rhel-root 70G 14G 57G 20% / /dev/sda1 1014M 322M 693M 32% /boot /dev/mapper/rhel-var 30G 22G 8.0G 74% /var

「Use%」が80%を超えたら対処が必要です。特に「/var」はログや一時ファイルで膨らみやすいため、個別監視することを推奨します。

2. duコマンドで大きなディレクトリを特定

# /varの中で容量を食っているディレクトリをトップ10表示 du -sh /var/* 2>/dev/null | sort -rh | head -10

4. ディスクI/Oを確認する

1. iostatでI/Oの状況を確認

# デバイスごとのI/O統計を2秒ごとに表示 iostat -x 2 # または人が読みやすい単位で表示 iostat -xh 2

「%util」が100%に近い場合、そのデバイスがボトルネックです。「await」(I/O待ち時間ミリ秒)が20ms以上になると体感的に重くなります。

2. iotopでプロセスごとのI/Oを特定

# I/Oを多く使うプロセスをリアルタイム表示(rootが必要) sudo iotop -o # 非インタラクティブに5回だけ表示 sudo iotop -bon 5

5. ネットワーク通信量を確認する

1. /proc/net/devで通信量を確認

# NICごとの通信量を確認 cat /proc/net/dev # ipコマンドで統計を確認 ip -s link show eth0

2. nloadで帯域をリアルタイム確認

# nloadのインストール(EPEL必要) sudo dnf install -y nload # NICを指定してリアルタイム表示 nload eth0

6. プロセス状態を確認する

1. psコマンドで実行中のプロセスを確認

# 全プロセスをCPU使用率の高い順に表示 ps aux --sort=-%cpu | head -20 # メモリ使用率の高い順に表示 ps aux --sort=-%mem | head -20 # 特定プロセスの状態確認 ps aux | grep httpd | grep -v grep

2. Zombieプロセス(ゾンビ)を確認する

ゾンビプロセス(Z状態)が大量に発生している場合、親プロセスが正しく終了処理をしていない可能性があります。

# ゾンビプロセスの数を確認 ps aux | grep Z | grep -v grep # topでもZOMBIE欄に表示される top -bn1 | grep "zombie"

7. ログを確認する

1. journalctlでsystemdのログを確認

RHEL 9系ではjournalctlが主要なログ参照コマンドです。

# 直近のログ(エラーレベル以上)を確認 journalctl -p err -n 50 # 特定サービスのログを確認 journalctl -u httpd -n 100 # 今日のログを確認 journalctl --since today # リアルタイムで追いかける journalctl -f

2. /var/log配下のログを確認

# システムメッセージ(RHEL/AlmaLinux) tail -100 /var/log/messages | grep -E "ERROR|error|WARN|warn|CRIT" # 認証関連のログ tail -100 /var/log/secure # Apacheのエラーログ tail -100 /var/log/httpd/error_log

8. サービスの稼働状態を確認する

systemdで管理されているサービスの状態確認にはsystemd-analyze で起動時間計測と合わせてsystemctlが基本です。

# 全サービスの状態を一覧表示 systemctl list-units --type=service --state=running # 失敗したサービスを確認 systemctl list-units --type=service --state=failed # 特定サービスの詳細確認 systemctl status httpd systemctl status mysqld systemctl status sshd

実サーバーでの出力例(failed状態のサービス確認):

UNIT LOAD ACTIVE SUB DESCRIPTION * mysqld.service loaded failed failed MySQL 8.0 Database Server LOAD = Reflects whether the unit definition was properly loaded. ACTIVE = The high-level unit activation state. SUB = The low-level unit activation state. 1 loaded units listed.

9. 死活監視(外部からの疎通確認)

1. pingで基本疎通を確認

# ICMPで疎通確認(4回送信) ping -c 4 192.168.1.10 # タイムアウトを設定して確認 ping -c 4 -W 3 192.168.1.10

2. curlでHTTP応答を確認

# HTTPステータスコードを確認(本文は表示しない) curl -o /dev/null -s -w "%{http_code}\n" http://192.168.1.10/ # レスポンスタイムも確認する場合 curl -o /dev/null -s -w "status=%{http_code} time=%{time_total}\n" http://192.168.1.10/

10. 接続数・ポート状態を確認する

Linux ポート確認の全コマンドで詳しく解説していますが、監視の視点では以下が重要です。

# 開放中のポートとリッスン状態を確認 ss -tlnp # 確立済み接続数を確認(ESTABLISHED) ss -s # HTTPの接続数が急増していないか確認 ss -tn | grep ":80" | wc -l # TIME_WAITが大量に積み上がっていないか ss -tn | grep TIME-WAIT | wc -l

実サーバーの出力例(ssコマンド):

Total: 245 (kernel 272) TCP: 187 (estab 142, closed 31, orphaned 0, synrecv 0, timewait 31/0), ports 0 Transport Total IP IPv6 * 272 - - RAW 0 0 0 UDP 6 4 2 TCP 156 143 13 INET 162 147 15 FRAG 0 0 0

11. 起動時間・ブート状態を確認する

1. uptimeで稼働時間を確認

# サーバーの稼働時間とロードアベレージを確認 uptime # または cat /proc/uptime

出力例:

09:30:15 up 42 days, 3:14, 2 users, load average: 0.15, 0.22, 0.19

load averageはCPUコア数を超えると混雑しています。2コアなら2.0以上で要注意です。

2. lastで再起動履歴を確認

# 再起動の履歴を確認 last reboot | head -10 # システムシャットダウン履歴 last -x shutdown | head -10

3. who -bで前回の起動時刻を確認

# 最後の起動時刻を確認 who -b

監視を自動化する方法

1. cronで定期チェックスクリプトを動かす

11項目の基本的な監視は、以下のようなシェルスクリプトをcronで実行することで自動化できます。

#!/bin/bash # server-health-check.sh — サーバー基本監視スクリプト ALERT_EMAIL="admin@example.com" THRESHOLD_CPU=90 THRESHOLD_MEM=90 THRESHOLD_DISK=85 # CPU使用率チェック CPU_USAGE=$(top -bn1 | grep "Cpu(s)" | awk '{print $2}' | cut -d'%' -f1 | cut -d'.' -f1) if [ "$CPU_USAGE" -gt "$THRESHOLD_CPU" ]; then echo "CPU使用率が高い: ${CPU_USAGE}%" | mail -s "[ALERT] CPU高負荷 $(hostname)" "$ALERT_EMAIL" fi # ディスク使用率チェック(80%超のパーティションを検出) df -h | awk 'NR>1 {sub(/%/,"",$5); if ($5+0 > '"$THRESHOLD_DISK"') print $0}' | while read line; do echo "ディスク使用率超過: $line" | mail -s "[ALERT] ディスク残量不足 $(hostname)" "$ALERT_EMAIL" done # サービス稼働確認(httpdが停止していたら再起動) if ! systemctl is-active --quiet httpd; then systemctl start httpd echo "httpdを再起動しました" | mail -s "[WARN] httpd再起動 $(hostname)" "$ALERT_EMAIL" fi

このスクリプトを5分ごとに実行するcrontab設定例:

# cronに登録(crontab -e で編集) */5 * * * * /usr/local/bin/server-health-check.sh >> /var/log/health-check.log 2>&1

2. Prometheusで長期トレンド監視に発展させる

単発のコマンド確認だけでは「いつから重くなり始めたか」がわかりません。長期的なトレンドを把握するには、PrometheusとGrafanaの組み合わせが現実解です。

# node_exporterのインストール(AlmaLinux 9 / RHEL 9) sudo dnf install -y golang-github-prometheus-node-exporter # 起動と自動起動設定 sudo systemctl enable --now node_exporter # メトリクスが取れているか確認 curl -s http://localhost:9100/metrics | grep "node_cpu_seconds_total" | head -5

node_exporterを入れておくだけで、CPUやポートの接続数など200項目以上のメトリクスを自動収集できます。

アラート設計の考え方

監視ツールを導入しても、アラートの閾値が適切でないと「アラート地獄」になります。現場で使える基準値の目安は以下のとおりです。
監視項目 警告(Warning) 重大(Critical)
CPU使用率 80%以上が5分継続 95%以上が5分継続
メモリ使用量 available < 20% Swapを50%以上使用
ディスク使用率 80%以上 90%以上
load average コア数 × 0.8 コア数 × 1.5
HTTP応答時間 1秒以上 5秒以上または応答なし
ディスクI/O待ち(%util) 70%以上が持続 95%以上が持続

トラブルシュート:よくある確認漏れパターン

「topでCPUは低いのに重い」ケース

topのCPUが低くても重い場合、I/O待ち(wa値)を確認してください。「wa」が高ければディスクがボトルネックです。iostatで該当デバイスを特定します。

「dfで空きがあるのに書き込めない」ケース

inodeが枯渇している可能性があります。

# inode使用量を確認 df -i # inodeを大量消費しているディレクトリを特定 find /var -xdev -type f | awk -F'/' '{print NF, $0}' | sort -rn | head -20

「メモリに余裕があるのにOOMKillerが動く」ケース

特定プロセスへのメモリ割り当て制限(cgroupのメモリ制限)を確認してください。

# OOMKillerの発動履歴を確認 journalctl -k | grep -i "oom\|killed process" # cgroupのメモリ制限を確認 systemctl show httpd | grep MemoryLimit

本記事のまとめ

Linuxサーバー監視の11項目とコマンドをまとめます。
監視項目 主要コマンド 確認ポイント
CPU使用率 top -bn1 us/sy/wa値に注目
メモリ使用量 free -m available列とSwap使用量
ディスク使用率 df -h Use%が80%以上で要注意
ディスクI/O iostat -x 2 %utilとawait値
ネットワーク通信量 ip -s link RX/TX byte数の変化
プロセス状態 ps aux --sort=-%cpu ゾンビプロセスの有無
ログ journalctl -p err エラー・警告の発生
サービス稼働 systemctl list-units --state=failed failedサービスの有無
死活監視 curl -w "%{http_code}" 200以外のレスポンス
接続数・ポート状態 ss -s TIME-WAITの積み上がり
起動時間・ブート状態 uptime load averageとコア数の比較
11項目を順に確認するクセをつけると、「なんとなく重い」という状態から「/varのinodeが枯渇していた」という具体的な原因にすぐたどり着けるようになります。

サーバー管理の実務では、このような確認手順を自分の頭の中に定着させることが重要です。Linux Master Pro Seminarでは、実サーバーを操作しながらこういった監視・トラブルシュートの手順を体で覚えるハンズオン形式で学べます。

サーバー監視の基礎を固めたら、次はサーバー構築の全体像を体系的に学びませんか?

監視できるということは、サーバーの構造を理解しているということです。その理解をさらに深めて、安全なLinuxサーバーを自分で構築できる力を身につけてみませんか。
ネットの切れ端の情報をコピペするだけでなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル(図解60P)』を完全無料でプレゼントしています。

「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

登録10秒/合わなければ解除3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。