Linuxシステムの安定稼働には、適切なモニタリングツールの活用が欠かせません。
CPUやメモリの負荷、ディスクI/O、ネットワークトラフィックなど、リソースの使用状況をリアルタイムで監視することで、パフォーマンスの最適化や障害の早期発見が可能になります。
しかし、「topやvmstatで何を見ればいいのか？」「iostatの出力結果をどう解釈すればいいのか？」と悩むことはないでしょうか？
本記事では、システムモニタリングの基本から、ツールの選び方・活用方法、トラブルシューティングの実践テクニックまで、エンジニアが現場で使える知識を徹底解説します！
Linux基礎知識（全17記事）
├─【Linuxの基礎知識】Linuxとは？基本概要と仕組みをわかりやすく解説！
├─【Linuxの基礎知識】インストールからログインまでの完全マニュアル
├─【Linuxの基礎知識】カーネルの役割と起動プロセスをわかりやすく解説！
├─【Linuxの基礎知識】ファイルシステムを極める！ディレクトリ構造とその関連性を解説
├─【Linuxの基礎知識】ディレクトリとファイル操作を完全マスター！初心者向けガイド
├─【Linuxの基礎知識】初心者向け！Linux管理に役立つ基本コマンド完全ガイド
├─【Linuxの基礎知識】ユーザー管理を極める！アクセス権との連携で強固なシステム構築
├─【Linuxの基礎知識】リンクとiノードについて理解を深めよう！
├─【Linuxの基礎知識】LVMとは？ LVMを理解しよう！
├─【Linuxの基礎知識】過去事例から学ぶ！システムセキュリティの基本
├─【Linuxの基礎知識】ディスク管理の完全ガイド！初心者から実践までを徹底解説
├─【Linuxの基礎知識】ネットワーク設定とトラブルシューティングを徹底解説！
├─【Linuxの基礎知識】リソース監視ツールの使い方を徹底解説！
├─【Linuxの基礎知識】パッケージ管理の応用テクニックをマスター！
├─仮想化とコンテナの基本を学ぶ！
├─バックアップとリストアのベストプラクティス
└─RAIDとディスク管理を徹底解説！
システムモニタリングの重要性と基本概念
システムモニタリングは、Linux環境で安定した運用を維持するために欠かせないプロセスです。CPUやメモリ、ディスクI/O、ネットワークの負荷を常に把握し、パフォーマンス低下や障害の兆候を見逃さないことが重要です。本章では、システムモニタリングの必要性と、主要なリソース監視の基本要素、適切なツールの選定基準について解説します。
なぜシステムモニタリングが必要なのか？
- 障害の予防と早期検出
システムの負荷が異常に増大した場合、適切な対処を行わなければサーバーがダウンする可能性があります。モニタリングを実施することで、異常を検知し、問題が顕在化する前に対応できます。 - リソース管理の最適化
CPUやメモリ、ディスクI/Oの使用状況を監視し、ボトルネックを特定することで、効率的なリソース配分を実現できます。 - パフォーマンスの改善とチューニング
高負荷状態が続くと、アプリケーションのレスポンスが低下し、エンドユーザーの満足度が下がる可能性があります。定期的なモニタリングを行い、適切なチューニングを施すことで、システムのパフォーマンスを最適化できます。 - トラブルシューティングの迅速化
システム障害が発生した際、モニタリングツールのデータを活用することで、原因の特定が容易になります。これにより、ダウンタイムを最小限に抑えることが可能です。
リソース監視の基本要素（CPU、メモリ、ディスク、ネットワーク）
Linuxのシステムモニタリングでは、以下の4つの主要なリソースを重点的に監視する必要があります。
- CPU使用率
プロセスの負荷を監視し、異常な高負荷を検出する。
コマンド例:top,htop,mpstat - メモリ使用量
メモリの消費状況を把握し、スワップの使用を最小限に抑える。
コマンド例:free,vmstat,smem - ディスクI/O
ディスクの読み書き速度を測定し、I/Oボトルネックを特定する。
コマンド例:iostat,iotop,dstat - ネットワークトラフィック
帯域使用率を監視し、過剰なトラフィックや異常な通信を検出する。
コマンド例:netstat,iftop,bmon
システムモニタリングの一般的なアプローチとツールの選定基準
Linuxシステムのモニタリングには、主に以下のアプローチが存在します。
- リアルタイム監視
システムの負荷やリソース使用状況をリアルタイムで把握する。
代表的なツール:top,htop,glances - 定期的な統計収集
一定間隔でデータを収集し、履歴を分析する。
代表的なツール:sar,iostat,vmstat - ログ解析
システムログやアプリケーションログを分析し、異常の発生を検知する。
代表的なツール:journalctl,logwatch,logrotate - アラート通知
しきい値を超えた際にアラートを送信し、管理者に通知する。
代表的なツール:Nagios,Zabbix,Prometheus
適切なツールの選定基準
モニタリングツールを選ぶ際には、以下の点を考慮する必要があります。
- 監視対象のリソース: CPU、メモリ、ディスク、ネットワークのどの部分を監視するか。
- リアルタイム監視が必要か？: 即座に状況を把握する必要がある場合は
topやhtopなどが適している。 - 長期的なデータ分析が必要か？:
sarやPrometheusなど、ログ収集・可視化ツールが適している。 - アラートの設定が可能か？:
NagiosやZabbixなどの監視ツールを活用すれば、異常発生時にアラートを受信できる。 - 運用コストや学習コスト: シンプルなコマンドで済むのか、それとも設定が必要なツールなのかを考慮する。
適切なツールを活用することで、Linuxシステムの安定運用が可能になります。次章では、具体的なモニタリングツールの詳細な使い方について解説します。
Linuxの主要なシステムモニタリングツール一覧
Linuxには多くのシステムモニタリングツールが存在しますが、それぞれ異なる目的や用途に適しています。本章では、主要なツールを紹介し、どのような場面で活用できるのかを解説します。
プロセスとリソースのリアルタイム監視
top コマンドは、Linuxで最も基本的なプロセス監視ツールの一つです。CPU使用率、メモリ使用量、プロセスごとの負荷をリアルタイムで監視できます。
- 主な機能: CPU使用率、メモリ使用量、ロードアベレージの確認
- 使い方:
topを実行するだけで、システム全体の負荷を確認できる - ショートカットキー:
q: 終了k: プロセスを強制終了r: プロセスの優先度変更（renice）
インタラクティブなプロセス監視ツール
htop は top の強化版で、より直感的な操作が可能なプロセス監視ツールです。キーボードやマウス操作が可能で、プロセスの管理がしやすいのが特徴です。
- 主な機能: カラフルなUI、スクロール操作、プロセスの並べ替え
- インストール方法:
sudo dnf install htop # RHEL系
sudo apt install htop # Debian系 - 使い方:
htopコマンドを実行するだけで詳細な情報が確認可能
システムパフォーマンスの統計情報取得
vmstat は、メモリ、CPU、スワップ、ディスクI/Oなどのパフォーマンス統計を取得するためのツールです。
- 主な機能: システム全体のリソース使用状況を統計的に把握
- 基本的な使い方:
vmstat 5 10
（5秒ごとに10回データを取得）
ディスクI/Oの詳細な監視
iostat はディスクの読み書き速度やI/O負荷を確認するためのツールです。ストレージのボトルネックを特定するのに役立ちます。
- 主な機能: ディスクI/O、CPU使用率の測定
- 基本的な使い方:
iostat -x 5
（5秒ごとに詳細なI/O統計を表示）
ネットワーク接続の監視
netstat や ss コマンドは、ネットワーク接続状況を監視するために使用されます。どのポートが開いているのか、どのプロセスが通信しているのかを確認できます。
- 主な機能: アクティブな接続、リスニングポート、ネットワーク統計の確認
- 基本的な使い方:
netstat -tulnp
（使用中のポート一覧を表示）
長期間のシステムパフォーマンス収
sar コマンドは、システムパフォーマンスの長期的な統計を記録・分析するためのツールです。CPU、メモリ、ディスク、ネットワークのパフォーマンスデータを定期的に収集し、障害発生時の分析に活用できます。
- 主な機能: CPU、メモリ、ディスク、ネットワークの統計情報を長期間収集
- 基本的な使い方:
sar -u 5 10
（5秒ごとにCPU使用率を10回取得）
これらのツールを適切に使い分けることで、システムのパフォーマンス監視やトラブルシューティングがスムーズに行えます。次章では、具体的なシナリオごとのモニタリング手法について詳しく解説します。
状況別システムモニタリングの実践テクニック
システムが重い、レスポンスが遅い、アプリが固まるなどの問題が発生した際、 適切なモニタリングツールを活用すれば、素早く原因を特定できます。 本章では、問題ごとに「何を確認すべきか」「どう判断するか」「どのように対処するか」を解説します。
CPU使用率が高い場合の調査方法（top, htop, mpstat）
サーバーのレスポンスが遅い場合、まずCPUの負荷を確認します。 短時間のスパイクなら問題ありませんが、高負荷が続く場合は原因を特定する必要があります。
✅ まずはリアルタイムでCPU負荷を確認する
top
実行結果（CPU負荷が高い例）:
1 2 3 4 5 6 7 8 9 | top - 14:32:55 up 3 days, 5:42, 1 user, load average: 5.24, 3.98, 2.10 Tasks: 178 total, 2 running, 176 sleeping, 0 stopped, 0 zombie %Cpu(s): 85.6 us, 1.2 sy, 0.0 ni, 12.9 id, 0.1 wa, 0.1 hi, 0.1 si, 0.0 st MiB Mem : 8000.0 total, 105.0 free, 6500.0 used, 1400.0 buff/cache MiB Swap: 2000.0 total, 50.0 free, 1950.0 used. 120.0 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 12345 apache 20 0 400000 25000 3000 R 75.5 0.3 0:32.11 httpd 67890 root 20 0 100000 4000 2000 S 5.5 0.1 0:05.67 systemd |
どこを確認するか？
- Load Average（1分 / 5分 / 15分）:
5.24（CPUコア数が4なら負荷が高い） - %Cpu(s) の us（ユーザーCPU使用率）:
85.6%（プロセスがCPUを占有している） - 高負荷なプロセス:
apacheプロセスが75.5%のCPUを消費 → Webサーバーが原因
🔍 さらに詳細に調査する
mpstat -P ALL 1 5
実行結果:
1 2 3 4 5 6 | Linux 5.10.0-9-amd64 (myserver) 02/03/2025 _x86_64_ (8 CPU) 13:45:12 CPU %usr %nice %sys %iowait %idle 13:45:13 0 80.2 0.0 5.0 10.1 4.7 13:45:13 1 3.2 0.0 0.5 0.2 96.1 13:45:13 2 2.1 0.0 0.7 0.3 96.9 |
どこを確認するか？
- CPU0の %iowait（I/O待ち時間）:
10.1%→ ディスクI/Oのボトルネックが疑われる - CPU1,2はほぼアイドル状態 → 特定のコアに負荷が集中している可能性
対処法:
- Webサーバー（apache）が高負荷なら、アクセスログを確認し、過剰なリクエストがないかチェック
%iowaitが高い場合、ディスクI/Oを確認する（次のセクション参照）
ディスクI/Oのボトルネック解析（iostat, dstat, iotop）
CPUやメモリに問題がないのにシステムが重い場合、ディスクI/Oが詰まっている可能性があります。
✅ まずはディスクI/Oの状況を確認
iostat -x 5
実行結果:
1 2 3 | Device: rrqm/s wrqm/s r/s w/s await sda 0.00 0.00 150.5 30.1 50.3 sdb 0.00 0.00 2.0 1.1 0.5 |
どこを確認するか？
sdaの await（I/O待ち時間）:50.3ms→ ディスクアクセス遅延発生- 読み取りリクエスト（r/s）が
150.5→ 大量の読み取り処理が発生
対処法:
iotopでどのプロセスがディスクを大量に使っているかを特定df -hでディスク使用量をチェックし、空き容量が不足していないか確認
出力結果の解釈と対応策
システムの負荷が高い場合、モニタリングツールで取得したデータを適切に解釈し、 最適な対応を行うことが重要です。本章では、CPU負荷、メモリ不足、I/O負荷、ネットワーク遅延の それぞれのケースについて、出力結果の見方と適切な対応策を解説します。
CPU負荷が高い場合の対処法
CPU負荷が異常に高いとき、まずはどのプロセスが原因になっているのかを特定します。
✅ CPU使用率の確認
top
実行結果（CPU負荷が高い例）:
1 2 3 4 5 6 | top - 14:32:55 up 3 days, 5:42, 1 user, load average: 6.24, 5.98, 4.10 Tasks: 178 total, 2 running, 176 sleeping, 0 stopped, 0 zombie %Cpu(s): 90.6 us, 3.2 sy, 0.0 ni, 5.2 id, 1.0 wa, 0.0 hi, 0.0 si, 0.0 st PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 12345 apache 20 0 400000 25000 3000 R 85.5 0.3 1:32.11 httpd 67890 mysql 20 0 800000 60000 5000 S 60.2 1.5 2:15.47 mysqld |
どこを確認するか？
- Load Average: 6.24（CPUコアが4つなら負荷過多）
- %Cpu(s) の us（ユーザーCPU使用率）: 90.6%（高負荷の処理が続いている）
- 高負荷なプロセス: `httpd`（Apache）と `mysqld`（MySQL）がCPUを占有
🔍 CPU負荷の軽減策
- `renice` コマンドで優先度を下げる（例: Apache の優先度を調整）
renice 10 -p 12345
- 必要のないプロセスを終了する（強制終了する場合）
kill -9 12345
- 負荷分散を考慮し、Nginxの導入やCDNの活用を検討する
メモリ不足時の対応
システムが重い場合、メモリが不足している可能性があります。 特にスワップの使用量が増えている場合は、対処が必要です。
✅ メモリの使用状況を確認
free -h
1 2 3 | total used free shared buff/cache available Mem: 8000M 7800M 200M 100M 500M 300M Swap: 2000M 1800M 200M |
どこを確認するか？
- 使用済みメモリ: 7800MB（ほぼ全て使用済み）
- スワップ: 1800MB使用中 → メモリ不足でスワップに頼っている
🔍 メモリ不足の解決策
- メモリを大量に消費しているプロセスを特定
ps aux --sort=-%mem | head -10
- 不要なプロセスを終了
kill -9 [PID]
- キャッシュを解放
sync; echo 3 > /proc/sys/vm/drop_caches
I/O負荷が高い場合の対策
CPUやメモリに余裕があるのにシステムが遅い場合、 ディスクI/Oがボトルネックになっている可能性があります。
✅ I/Oの負荷状況を確認
iostat -x 5
1 2 3 | Device: rrqm/s wrqm/s r/s w/s await sda 0.00 0.00 150.5 30.1 50.3 sdb 0.00 0.00 2.0 1.1 0.5 |
どこを確認するか？
- await（I/O待ち時間）: 50.3ms（高負荷の兆候）
- 読み取りリクエスト（r/s）: 150.5（ディスクの負荷が高い）
🔍 I/O負荷の軽減策
- `iotop` でディスクを大量に使用しているプロセスを特定
iotop
- `fstrim` でSSDの最適化を実行（SSDの場合）
fstrim -av
- RAID構成の見直しやI/Oスケジューラの変更を検討
ネットワーク遅延の改善方法
「サイトが遅い」「SSHのレスポンスが悪い」場合、 ネットワークの遅延が原因かどうかを確認します。
✅ ネットワークの通信状況を確認
iftop -i eth0
実行結果（帯域が逼迫している例）:
1 2 3 | Hostname Bandwidth 192.168.1.10 => 192.168.1.1 500Kb 800Kb 192.168.1.10 => external.example.com 1.5Mb 3.2Mb |
どこを確認するか？
- 異常な帯域使用: 特定の外部サイトとの通信が多すぎる
🔍 ネットワーク遅延の改善策
- `tc` コマンドでトラフィック制御を設定
tc qdisc add dev eth0 root tbf rate 10mbit burst 32kbit latency 400ms
- ファイアウォールで不正アクセスをブロック
このように、システム負荷の状況を適切に判断し、最適な対策を取ることが重要です。
複数のモニタリングツールを組み合わせた高度な活用法
単体のモニタリングツールでは、システムの一部の情報しか取得できません。 異常の原因をより正確に特定するには、複数のツールを組み合わせることで、 より詳細な分析が可能になります。本章では、代表的な組み合わせ例を紹介します。
topとvmstatを組み合わせたCPU負荷の詳細分析
CPU使用率が高い場合、単に top でプロセスごとの負荷を見るだけでは不十分な場合があります。 このとき、vmstat を組み合わせることで、システム全体の負荷状況やスワップの影響を分析できます。
✅ CPU使用率の確認
top
1 2 3 4 5 6 | top - 14:32:55 up 3 days, 5:42, 1 user, load average: 6.24, 5.98, 4.10 Tasks: 178 total, 2 running, 176 sleeping, 0 stopped, 0 zombie %Cpu(s): 90.6 us, 3.2 sy, 0.0 ni, 5.2 id, 1.0 wa, 0.0 hi, 0.0 si, 0.0 st PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 12345 apache 20 0 400000 25000 3000 R 85.5 0.3 1:32.11 httpd 67890 mysql 20 0 800000 60000 5000 S 60.2 1.5 2:15.47 mysqld |
次に、CPU負荷の詳細を vmstat で確認します。
vmstat 1 5
1 2 3 4 | procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu------ r b swpd free buff cache si so bi bo in cs us sy id wa st 2 0 12000 30000 15000 500000 0 1 5 2 1000 1500 85 10 3 2 0 1 0 12000 28000 14000 520000 0 0 3 1 980 1480 83 12 2 3 0 |
どこを確認するか？
- CPU使用率（us: 85%, sy: 10%）: ユーザープロセスの負荷が高く、カーネルの負荷も高い
- wa（I/O待ち時間）が増えていないか: I/Oの影響でCPUが待機している場合は、ディスクI/Oを疑う
🔍 CPU負荷の改善策
- 負荷の高いプロセスの優先度を調整
renice 10 -p 12345
- I/O待ちが発生している場合、ディスクの状態を確認（次のセクション参照）
iostatとsarを活用したディスクパフォーマンスの長期分析
ディスクI/Oの問題は、瞬間的な負荷ではなく、長期間にわたるパターンを分析する必要があります。 iostat でリアルタイムのI/O状況を確認し、sar を使って長期的なトレンドを分析します。
✅ 現在のディスクI/O負荷を確認
iostat -x 5
1 2 3 | Device: rrqm/s wrqm/s r/s w/s await sda 0.00 0.00 150.5 30.1 50.3 sdb 0.00 0.00 2.0 1.1 0.5 |
どこを確認するか？
- await（I/O待ち時間）: 50.3ms（ディスクのレスポンスが遅い）
🔍 長期的なI/O負荷の分析
sar -d 5 10
1 2 | 12:00:01 AM DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await 12:05:01 AM sda 150.5 204800 102400 20.0 1.5 50.3 |
対策:
- `iotop` でディスクを大量に使っているプロセスを特定
- SSDの場合、`fstrim` で最適化
tcpdumpとnetstatによるネットワークトラブルシューティング
ネットワーク遅延が発生している場合、netstat で接続状況を確認し、 tcpdump で具体的なパケットの流れを調査します。
✅ アクティブな接続を確認
netstat -antp
1 2 3 | Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 192.168.1.10:22 192.168.1.1:50234 ESTABLISHED 1023/sshd tcp 0 0 192.168.1.10:80 192.168.1.2:49876 ESTABLISHED 2048/nginx |
🔍 異常なパケットの監視
tcpdump -i eth0 port 80
1 | 12:34:56.789012 IP 192.168.1.2.49876 > 192.168.1.10.80: Flags [S], seq 12345678, win 64240 |
対策:
- `iptables` で特定のIPをブロック
ELKスタックを使ったシステム全体の可視化と分析
ELKスタック（Elasticsearch, Logstash, Kibana）は、システム全体のログを収集・解析し、 リアルタイムで可視化できる強力なツールです。 特に、ログデータを JSON形式 にフォーマットして保存することで、 検索やフィルタリングがしやすくなり、異常検知やアラート設定も可能になります。
✅ ELKでログをJSON形式に変換する
ELKを使うと、システムログやWebサーバーログをJSON形式に変換し、Elasticsearchに保存できます。
📌 例1: Apacheのアクセスログ（元データ）
1 | 192.168.1.10 - - [03/Feb/2025:12:34:56 +0000] "GET /index.html HTTP/1.1" 200 1024 |
このような形式のログをそのまま扱うと、検索や解析が困難です。 Logstashを使うことで、以下のようなJSON形式に変換できます。
📌 LogstashでJSON形式に変換
1 2 3 4 5 6 7 8 9 | { "timestamp": "2025-02-03T12:34:56+0000", "client_ip": "192.168.1.10", "method": "GET", "url": "/index.html", "protocol": "HTTP/1.1", "status": 200, "bytes": 1024 } |
このように、各要素が整理され、Elasticsearchで効率的に検索・フィルタリングができるようになります。
✅ LogstashでログをJSON形式にフォーマットする設定
Logstashのフィルターを使うと、ログをJSON形式に変換できます。 例えば、Apacheのアクセスログを解析し、JSON形式にするには以下の設定を使用します。
📌 Logstashの設定例
1 2 3 4 5 6 7 8 9 | filter { grok { match => { "message" => "%{IP:client_ip} - - \[%{HTTPDATE:timestamp}\] \"%{WORD:method} %{URIPATHPARAM:url} %{WORD:protocol}\" %{NUMBER:status} %{NUMBER:bytes}" } } date { match => [ "timestamp", "dd/MMM/yyyy:HH:mm:ss Z" ] target => "@timestamp" } } |
この設定でできること:
- Apacheのアクセスログを解析し、
client_ip,timestamp,method,url,statusなどのフィールドに分割 - 時刻をISO 8601形式に変換し、時系列データとして管理しやすくする
✅ JSON形式にするメリット
- ログの検索・フィルタリングが容易
例:status:200 AND url:"/index.html"のように素早く検索可能 - 可視化がしやすい
Kibanaのダッシュボードで、ログの統計やエラーの発生状況をグラフ化 - 異常検知やアラート設定が可能
特定のエラー（例:status:500）が増えたら通知を送信
✅ ELKスタックを活用すると何ができるのか？
- システム全体のログを一元管理（複数サーバーのログを統合）
- ログの検索・分析が容易になり、異常を迅速に検知
- Kibanaでダッシュボードを作成し、リアルタイムで可視化
このように、ELKスタックを活用すれば、システム監視やトラブルシューティングが飛躍的に効率化できます。
システムモニタリングを自動化する方法
システムの監視を手動で行うのは手間がかかるため、定期的な監視やリアルタイムのアラート通知を自動化することが重要です。 本章では、cronを使った定期的なスクリプト実行、NagiosやZabbixによるリアルタイム監視、 PrometheusとGrafanaを活用したモダンな監視環境の構築方法について解説します。
cronを利用した定期的な監視スクリプトの実装
定期的にシステムの状態を記録し、異常を検知するために cron を利用できます。 例えば、CPUやメモリの使用状況を記録し、異常値があればメール通知するスクリプトを作成できます。
✅ 監視スクリプトの作成
以下のスクリプトは、CPU使用率が80%を超えた場合に管理者へ通知します。
/usr/local/bin/cpu_monitor.sh
1 2 3 4 5 6 7 | #!/bin/bash CPU_LOAD=$(top -bn1 | grep "Cpu(s)" | awk '{print $2 + $4}') THRESHOLD=80.0 if (( $(echo "$CPU_LOAD > $THRESHOLD" | bc -l) )); then echo "警告: CPU使用率が $CPU_LOAD% に達しました。" | mail -s "CPU負荷警告" admin@example.com fi |
✅ cronでスクリプトを定期実行
上記のスクリプトを cron に登録し、5分ごとに実行します。
crontab -e
1 | */5 * * * * /usr/local/bin/cpu_monitor.sh |
これにより、CPU負荷を定期的に監視し、異常時にメールで通知できるようになります。
Nagios/Zabbixを活用したリアルタイム監視の導入
より高度なリアルタイム監視を行うには、NagiosやZabbixなどの監視ツールを利用します。 これらのツールを使えば、システムの状態を常時監視し、異常を検知した際にアラートを発信できます。
✅ Nagiosによる監視の仕組み
- 各サーバーにエージェントをインストールし、定期的に監視データを収集
- CPU使用率、メモリ使用量、ディスクI/O、ネットワークトラフィックなどを監視
- 設定したしきい値を超えると、メールやSlackに通知
✅ Zabbixの特徴
- 専用エージェントを使って、より詳細なメトリクスを収集可能
- Webインターフェースで監視データをリアルタイムに可視化
- 自動アクション機能により、特定の異常時にスクリプトを実行可能
✅ Zabbixエージェントのインストール
RHEL系の場合
1 2 | sudo yum install zabbix-agent sudo systemctl enable --now zabbix-agent |
このように、NagiosやZabbixを導入することで、システム監視をより自動化し、異常検知をリアルタイムに行うことができます。
PrometheusとGrafanaを組み合わせたモダンな監視環境の構築
近年のクラウド環境では、PrometheusとGrafana を組み合わせることで、 柔軟で拡張性の高いモニタリングシステムを構築できます。
✅ Prometheusとは？
- メトリクスデータを収集し、時系列データとして保存
- プル型アーキテクチャ（監視対象のエンドポイントからデータを取得）
- しきい値を超えた場合のアラート機能を搭載
✅ Grafanaとは？
- Prometheusのデータを視覚的に可視化できるダッシュボード
- Web UIで直感的にグラフを作成・管理可能
- アラート通知機能を備え、Slackやメールと連携可能
✅ PrometheusとGrafanaの連携
Prometheusをインストールし、システムメトリクスを収集する設定を行います。
Prometheusの設定例（/etc/prometheus/prometheus.yml）
1 2 3 4 5 6 7 | global: scrape_interval: 10s scrape_configs: - job_name: 'node_exporter' static_configs: - targets: ['localhost:9100'] |
次に、Grafanaをインストールし、Prometheusをデータソースとして設定します。
✅ Grafanaのインストール（RHEL系）
1 2 | sudo yum install grafana sudo systemctl enable --now grafana-server |
✅ ダッシュボードで監視データを可視化
GrafanaのWebインターフェース（http://localhost:3000）にアクセスし、 Prometheusをデータソースとして設定すると、以下のようなダッシュボードが作成できます。
- CPU使用率、メモリ使用量、ディスクI/Oのリアルタイムモニタリング
- ネットワークトラフィックやリクエストレートの可視化
- しきい値を設定し、異常を検知した際にアラートを発信
このように、監視を自動化することで、システムの安定運用を実現できます。 運用環境や要件に応じて、最適な監視ツールを選択し、適切なアラート設定を行いましょう。
よくある質問（FAQ）
システムモニタリングを行う上で、よくある疑問について解説します。 各ツールの違いや、データの保存方法、メモリの管理、ログの解析方法など、 実際の運用で気になるポイントを整理しました。
なぜtopとhtopの数値が異なるのか？
top と htop はどちらもCPUやメモリの使用状況を監視するツールですが、 表示される数値が異なることがあります。これは、データの取得方法や更新頻度の違いによるものです。
✅ 主な違い
- データの更新頻度:
top はデフォルトで 3 秒ごとに更新されるのに対し、htop はより短い間隔（1 秒）で更新されるため、 数値の変動がより細かく反映されます。 - CPU使用率の計算:
top はプロセスごとの使用率を合計する方式をとりますが、htop はよりリアルタイムな負荷を表示するため、 数値が異なることがあります。 - カウント方式の違い:
top はスレッドごとにCPUをカウントする設定（デフォルト）ですが、htop はプロセス単位での表示が基本です。
✅ 解決策
- top でスレッド単位の表示を変更するには:
top -H
- top の更新頻度を htop と同じにするには:
top -d 1
sarのデータを長期間保存するには？
sar はデフォルトで一定期間（通常7日間）分のデータしか保存しません。 長期間の記録を保持する場合、設定を変更する必要があります。
✅ 保存期間の確認
cat /etc/sysconfig/sysstat
1 2 | # デフォルトの保存期間（7日） HISTORY=7 |
✅ 保存期間を変更する
例えば、30日間保存したい場合は、以下のように設定を変更します。
vi /etc/sysconfig/sysstat
1 2 | # 30日間データを保存 HISTORY=30 |
変更後、sysstat サービスを再起動します。
systemctl restart sysstat
メモリ使用率が100%でも問題ないのか？
Linuxでは、メモリ使用率が 100% に近くても、すぐに問題が発生するとは限りません。
✅ 理由
- Linux は未使用メモリを積極的にキャッシュとして利用するため、実際の「空きメモリ」が少なく見えることがある
- キャッシュメモリ（
buff/cache）は必要に応じて解放されるため、通常は問題にならない
✅ 本当にメモリ不足かどうかを確認する
free -h
1 2 3 | total used free shared buff/cache available Mem: 8000M 7800M 200M 100M 500M 300M Swap: 2000M 1800M 200M |
どこを確認するか？
- 「available」メモリが少ない（100MB未満）場合は、実際にメモリが逼迫している可能性がある
- スワップ（
Swap）の使用量が増えていないかチェック
✅ 対応策
- メモリを消費しているプロセスを特定
ps aux --sort=-%mem | head -10
- キャッシュを解放（通常は不要）
sync; echo 3 > /proc/sys/vm/drop_caches
ログを解析して異常を検出する最適な方法は？
ログを手動でチェックするのは効率が悪いため、専用ツールを使って自動的に異常を検出するのが最適です。
✅ 方法1: journalctl でエラーログを検索
journalctl -p 3 -xe
ポイント: -p 3 はエラーレベル（3=ERROR）以上のログを表示
✅ 方法2: grep を使って特定のキーワードを検索
grep -i "error" /var/log/syslog
✅ 方法3: ELKスタック（Elasticsearch, Logstash, Kibana）を導入
ELKを活用すると、ログを一元管理し、リアルタイムで異常検知が可能です。
- Logstash でログを収集・JSON形式にフォーマット
- Elasticsearch でログを検索し、異常値をフィルタリング
- Kibana で可視化し、異常なイベントをリアルタイムに検出
✅ Kibana でエラーログを検索するクエリ
1 2 3 4 5 6 7 | { "query": { "match": { "message": "error" } } } |
これにより、システムログの中からエラーに関連する情報を素早く抽出できます。
このように、各モニタリングツールの特性を理解し、適切に活用することで、 システムの異常を迅速に検出し、適切な対応を取ることができます。
まとめ
本記事では、システムモニタリングの基本から、実践的なツールの活用方法、 複数ツールを組み合わせた高度な監視手法、自動化と可視化の重要性について解説しました。
システムモニタリングツールの選び方と実践的な使い方のポイント
システムモニタリングでは、目的に応じた適切なツールを選択することが重要です。
✅ 主なモニタリングツールとその用途
- CPU/メモリ監視:
top,htop,vmstat - ディスクI/O監視:
iostat,iotop,dstat - ネットワーク監視:
netstat,iftop,bmon - ログ監視:
journalctl,logwatch,grep
これらのツールを使いこなすことで、システムの異常を迅速に特定し、適切な対応を取ることができます。
ツールの組み合わせによる高度な監視手法の活用
1つのツールだけでは、システムの全体像を把握するのは困難です。 複数のツールを組み合わせることで、より詳細な分析が可能になります。
✅ 代表的な組み合わせ例
- CPU負荷の詳細分析:
top+vmstat - ディスクI/Oの長期分析:
iostat+sar - ネットワークトラブルシューティング:
tcpdump+netstat - ログの統合管理と可視化: ELKスタック（Elasticsearch, Logstash, Kibana）
複数のツールを適切に組み合わせることで、システムの異常をより正確に特定し、 迅速なトラブルシューティングが可能になります。
効率的な監視のための自動化と可視化の重要性
システム監視を手作業で行うのは非効率なため、自動化と可視化が不可欠です。
✅ 監視の自動化
- cronによる定期的な監視スクリプトの実行
- Nagios/Zabbixを活用したリアルタイム監視
- Prometheus + Grafana を使ったメトリクスの収集と可視化
✅ 監視の可視化
システムの状態をグラフやダッシュボードで表示することで、 異常の兆候を事前に察知し、迅速な対応が可能になります。
- Kibana: ELKスタックと連携し、ログデータをリアルタイムで可視化
- Grafana: Prometheusと組み合わせ、CPU・メモリ・ネットワークの推移を分析
これらのツールを活用することで、障害発生のリスクを低減し、 より安定したシステム運用が実現できます。
本記事で紹介したモニタリング手法を活用し、システムの健全性を維持しながら、 効率的な監視とトラブルシューティングを実現してください。
この記事を読んだら、次は 「【Linuxの基礎知識】パッケージ管理の応用テクニックをマスター！」 を読むのがおすすめです！
