第1章　キャパシティプランニングとリソース監視

LPIC-2 200.1〜200.2 相当

サーバー運用では、障害が起きてから対応するだけでなく、将来的にリソースが不足しないかを事前に予測する「キャパシティプランニング」が重要です。その土台となる監視コマンドを扱います。LPIC-2の201試験では、この分野からコマンドの用途と出力の読み方が具体的に問われる傾向があるため、単に名前を覚えるだけでなく、実際にどの数値に注目すべきかまで押さえておきましょう。

リソース監視の基本コマンド

$ vmstat 2 5      # 2秒間隔で5回表示
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      0 1150328 210044 11845200    0    0    12    18   45   80  8  2 89  1  0
 1  0      0 1148900 210044 11845400    0    0     0    24  520  910 42  5 51  2  0
$ iostat -x 2     # 詳細なディスクI/O統計を2秒間隔で表示
Device            r/s     w/s     rkB/s     wkB/s  await  %util
sda              2.10   15.30     84.40    612.80   3.40   45.20

この行のこの値に注目： vmstatの1行目は起動時からの累積平均のため参考程度にとどめ、2行目以降の直近間隔の値を見ます。wa（I/O待ち）列が高い状態が続く場合はディスクI/Oがボトルネックになっている可能性があり、iostat -xの%utilやawaitと併せて確認します。

free -hの出力を読む際は、usedの値だけを見て「メモリが枯渇している」と判断しないよう注意が必要です。

$ free -h
              total        used        free      shared  buff/cache   available
Mem:           15Gi       3.2Gi       1.1Gi       256Mi        11Gi        11Gi
Swap:         2.0Gi          0B       2.0Gi

Linuxカーネルは、空いているメモリをディスクキャッシュ（buff/cache列）として積極的に活用する設計になっており、これはメモリを無駄なく使っている健全な状態です。アプリケーションが実際に追加のメモリを必要とした場合、このキャッシュ分は即座に解放されて割り当てられます。実質的に使用可能なメモリ量はavailable列を見るべきで、free列だけを見て「メモリが少ない」と誤解しないようにしましょう。逆にavailableが枯渇し、swap行の使用量が増え続けている状態は、実際のメモリ不足のサインとして注視すべきポイントです。

iostat -x の出力を読む

-x（extended）オプションを付けると、単純な転送量だけでなく、ディスクごとのボトルネックを判断するための詳細な指標が表示されます。特に重要な列を押さえておきましょう。

sar — 履歴データの記録と分析

sar（system activity reporter）は sysstat パッケージに含まれ、cronによって定期的にリソース状況を記録し続けます。「先週の日中、CPU使用率がどう推移していたか」のような過去のデータを確認できるのが特徴です。

$ sudo apt install sysstat
Reading package lists... Done
...（省略）
Setting up sysstat (12.6.1-2) ...
$ sar -u 1 3        # CPU使用率を1秒間隔で3回
10:00:01 AM     CPU     %user     %nice   %system   %iowait    %idle
10:00:02 AM     all     12.50      0.00      3.20      1.10     83.20
10:00:03 AM     all     14.10      0.00      3.50      0.90     81.50
Average:        all     13.30      0.00      3.35      1.00     82.35
$ sar -r             # 本日のメモリ使用率の推移
12:00:01 AM kbmemfree kbavail kbmemused %memused kbbuffers kbcached
12:10:01 AM   1150328 11845200  14201600    92.40    210044  11635156

この行のこの値に注目： sar -uのAverage行は、指定した回数分の平均値です。%iowaitが高いまま続く場合はディスクI/O待ちがCPU使用率を圧迫していることを示します。sar -rの%memusedはfree -hのavailableとは異なる計算式なので、単純にメモリ逼迫の指標として鵜呑みにせず、傾向（増加し続けているか）で判断するのが安全です。

sarの主なオプションとログの保存先

sarが記録した日次データは、既定で /var/log/sysstat/（ディストリビューションによっては /var/log/sa/）以下に saDD（DDは日付）という名前で保存されます。オプションを付けずにsarを実行すると当日分のCPU使用率が表示されますが、-f でファイルを指定すれば過去の記録もさかのぼって確認できます。

$ sar -n DEV 1 3         # ネットワークインターフェースごとの送受信統計を1秒間隔で3回
10:00:01 AM     IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s
10:00:02 AM      eth0     45.00     38.00      5.20      4.10
10:00:02 AM        lo      2.00      2.00      0.15      0.15
$ sar -f /var/log/sysstat/sa10 -s 09:00:00 -e 12:00:00
# 過去の記録ファイルから9時〜12時の範囲だけを抽出
09:00:01 AM     CPU     %user     %nice   %system   %iowait    %idle
09:10:01 AM     all     10.20      0.00      2.80      0.50     86.50
...（省略。10分おきのレコードが12時分まで続く）

この行のこの値に注目： sar -n DEVのrxkB/s・txkB/sがインターフェースの実際のスループットです。-fで過去ファイルを指定した場合、ファイル名のsa10が「10日」分のデータであることを示し、-s/-eで時刻範囲を絞り込めます。

プロセス単位の監視： mpstatとpidstat

sarやvmstatはシステム全体の集計値を示しますが、「どのプロセスが原因か」を突き止めるには、プロセスやコア単位で見られるツールが役立ちます。いずれもsysstatパッケージに含まれます。

$ pidstat -p 1234 1 3
Linux 6.1.0-generic     08/15/2026     _x86_64_    (4 CPU)

10:15:01      UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
10:15:02     1000      1234   45.00    5.00    0.00    2.00   50.00     2  myapp
10:15:03     1000      1234   47.00    4.00    0.00    1.00   51.00     2  myapp

この出力から、PID 1234のプロセスがCPUコア2番でおよそ50%のCPUを消費し続けていることが読み取れます。topのように多数のプロセスを一覧表示するのではなく、あらかじめ特定したPIDを継続的に追跡したい場合にpidstatは便利です。

ロードアベレージの読み方

uptime や top の先頭に表示される「ロードアベレージ（load average）」は、実行待ち・実行中のプロセス数を過去1分・5分・15分の指数移動平均で示した値です。単独の数値だけでは意味を持たず、必ずCPUのコア数と比較して解釈する必要があります。

$ uptime
 10:32:01 up 30 days,  4:12,  2 users,  load average: 3.85, 2.10, 1.50
$ nproc         # 論理CPUコア数を確認
4

この例では直近1分間のロードアベレージが3.85で、コア数が4なので使用率換算ではおよそ96%（3.85 ÷ 4）に相当します。1に近づくほど「1コア分をちょうど使い切っている」状態を意味し、コア数を超える値が続く場合はCPU待ちのプロセスが積み上がっていることを示します。また、3つの数値（1分・5分・15分）を見比べることで、負荷が上昇傾向にあるのか、すでにピークを越えて収束しつつあるのかも判断できます。

プロセス・ディスク・ネットワークの詳細監視ツール

ここまでのsar/vmstat/iostatはシステム全体の集計値を得意としますが、「具体的にどのプロセスが」「どの接続が」原因かを掘り下げるには、より粒度の細かいツールが必要です。ここではLPIC-2の200.2で扱われる代表的なツールを紹介します。

iotopは、topのディスクI/O版として使えるツールです。

$ sudo iotop -o -P
  PID USER  DISK READ DISK WRITE SWAPIN IO> COMMAND
 3421 mysql   1.20 M/s    850.00 K/s  0.00 % 12.50 % mysqld
 5502 root    0.00 B/s      0.00 B/s  0.00 %  0.00 % [kworker/0:1]

この行のこの値に注目： -o（--only）は実際にI/Oを行っているプロセスだけに絞り込み、アイドル中のプロセスを非表示にします。-P（--processes）はスレッド単位ではなくプロセス単位で集計します。指定しない場合は既定でスレッドごとに表示され、同じプロセスの合計I/O量が把握しにくくなります。

iptraf-ngは、ncursesベースの対話型メニューから、インターフェースごとのトラフィック量やTCP/UDP接続ごとの内訳をリアルタイムに確認できるツールです。sar -n DEVが数値ベースの記録に向く一方、iptraf-ngは「今何が起きているか」を視覚的に素早く把握したい場面に向いています。

$ sudo iptraf-ng
# メニューから「IP traffic monitor」→対象インターフェースを選択
 TCP connections (source host:port to destination host:port)
 10.0.0.5:443      to 203.0.113.9:51322    23.4 kbps
 10.0.0.5:22       to 198.51.100.20:60110   1.2 kbps
（ncursesによる全画面表示。数値はリアルタイムに更新され続ける。qキーで終了）

lsof（list open files）は、Linuxでは「ネットワークソケットも1つのファイル」として扱われるという設計を利用し、プロセスが開いているあらゆるファイル・ソケットを横断的に確認できます。

$ sudo lsof -i -P -n | head -5
COMMAND   PID   USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
sshd     1200   root    3u  IPv4  28391      0t0  TCP *:22 (LISTEN)
nginx    2044 nginx     6u  IPv4  31022      0t0  TCP 10.0.0.5:443->203.0.113.9:51322 (ESTABLISHED)
$ sudo lsof -p 2044          # PID 2044が開いている全ファイルを表示
COMMAND  PID  USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
nginx   2044 nginx  cwd    DIR    8,1     4096       2 /
nginx   2044 nginx    3r   REG    8,1    12345  131050 /etc/nginx/nginx.conf
nginx   2044 nginx   13w   REG    8,1 52428800  131099 /var/log/nginx/access.log
$ sudo lsof +D /var/log      # /var/log配下で開かれているファイルを表示
COMMAND  PID  USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
rsyslogd 890 syslog    5w   REG    8,1  3145728  131020 /var/log/syslog
nginx   2044 nginx   13w   REG    8,1 52428800  131099 /var/log/nginx/access.log

この行のこの値に注目： FD列のwはそのプロセスが書き込みモードでファイルディスクリプタを保持していることを示します。ローテーション後もプロセスが古いファイルへ書き込み続けているかどうかは、+Dの結果に(deleted)という表記が付くかどうかで判別できます。

実務でよく使う使い方： ディスク使用量がdfの表示と実態でずれている場合、削除済みだが依然としてプロセスに開かれ続けているファイルが容量を占有している可能性があります。次のコマンドで、そのようなファイルを特定できます。

$ sudo lsof | grep deleted
nginx     2044 nginx   13w   REG   8,1  524288000   131099 /var/log/nginx/access.log (deleted)

pstree -pは、プロセスの親子関係をツリー形式で表示し、各プロセス名の末尾にPIDを添えます。あるプロセスがどこから起動されたのか、どのような子プロセスを抱えているのかを直感的に把握できます。

$ pstree -p 1200
sshd(1200)---sshd(2301)---bash(2302)---mysql(2350)-+-mysqld(2355)
                                                       `-mysqld(2356)

$ w
 10:32:01 up 30 days,  4:12,  2 users,  load average: 3.85, 2.10, 1.50
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
kosuke   pts/0    203.0.113.9      09:58    0.00s  0.12s  0.02s w
$ last -n 5
kosuke   pts/0        203.0.113.9      Thu Aug 20 09:58   still logged in
root     pts/1        203.0.113.4      Wed Aug 19 22:10 - 22:45  (00:35)

予期しない時間帯のログインや、見覚えのないIPアドレスからのアクセスがlastの履歴に残っていないかを定期的に確認することは、不正アクセスの早期発見にもつながります。

中級で扱ったssには、状況に応じて組み合わせるべき詳細なオプションがあります。

$ sudo ss -tulnp
Netid State  Local Address:Port  Peer Address:Port  Process
tcp   LISTEN 0.0.0.0:22          0.0.0.0:*           users:(("sshd",pid=1200,fd=3))
tcp   LISTEN 127.0.0.1:3306      0.0.0.0:*           users:(("mysqld",pid=2355,fd=15))
$ ss -t state established     # ESTABLISHED状態のTCP接続だけに絞り込む
State  Recv-Q Send-Q  Local Address:Port   Peer Address:Port
ESTAB  0      0       10.0.0.5:443         203.0.113.9:51322
ESTAB  0      0       10.0.0.5:22          198.51.100.20:60110
$ ss -s                       # ソケット数の統計サマリー
Total: 312
TCP:   48 (estab 12, closed 30, orphaned 0, timewait 28)

Transport Total     IP        IPv6
RAW	  0         0         0
UDP	  6         4         2
TCP	  18        14        4

この行のこの値に注目： ss -sのtimewait件数が異常に多い場合、短命な接続を大量に開いては閉じているアプリケーションの挙動を疑います。ss -t state establishedで実際に通信中のTCP接続の相手先を確認し、想定外のIPアドレスがないかをチェックできます。

ss stateに続けてestablished・listening・time-waitのような状態名を指定すると、その状態のソケットだけに絞り込めます。TIME-WAIT状態のソケットが極端に多い場合、短命な接続を大量に張っては切っているアプリケーションの挙動や、TCPの再利用設定（net.ipv4.tcp_tw_reuseなど）を見直すきっかけになります。

procファイルシステムから直接値を読み取る

sarやvmstatなどのコマンドは、実は内部で/proc以下の仮想ファイルを読み取って加工表示しているに過ぎません。/procを直接読むスキルがあると、専用コマンドがない環境でも同等の情報を取得でき、スクリプトに組み込んで自動化する際にも役立ちます。

$ cat /proc/loadavg
3.85 2.10 1.50 2/456 8821

この行のこの値に注目： 前半3つの数値が1分・5分・15分のロードアベレージです。2/456は「現在実行中または実行待ちのプロセス数／システム全体のプロセス・スレッド総数」を表し、末尾の8821は直近に割り当てられたPIDです。

$ cat /proc/meminfo | head -5
MemTotal:       16273408 kB
MemFree:         1152340 kB
MemAvailable:   11534200 kB
Buffers:          412300 kB
Cached:          9821004 kB

free -hコマンドのavailable列は、このMemAvailableの値をそのまま人間が読みやすい単位に変換したものです。

$ cat /proc/stat | head -1
cpu  123456 234 45678 9876543 12345 0 6789 0 0 0

この行のこの値に注目： cpu行の各数値は、システム起動時からの累積のCPU時間（クロックティック単位）で、左から順にuser・nice・system・idle・iowait・irq・softirqを意味します。topやvmstatが表示するパーセンテージは、この累積値を一定間隔で2回サンプリングし、その差分から算出しています。

$ cat /proc/1234/status | grep -E "State|VmRSS|Threads"
State:  S (sleeping)
VmRSS:      45680 kB
Threads:        8

VmRSS（Resident Set Size）は、そのプロセスが実際に物理メモリ上に確保しているサイズです。psやtopのRSS列も、この値を情報源としています。

$ ls -l /proc/1234/fd/ | head -4
lrwx------ 1 mysql mysql 64 Aug 20 10:00 0 -> /dev/null
lrwx------ 1 mysql mysql 64 Aug 20 10:00 3 -> /var/lib/mysql/ibdata1
lrwx------ 1 mysql mysql 64 Aug 20 10:00 4 -> socket:[31022]

/proc/<pid>/fd/以下の各シンボリックリンクは、そのプロセスが開いている個々のファイルディスクリプタです。前述のlsof -pは、内部的にこのディレクトリを走査して情報をまとめています。

$ cat /proc/1234/limits | head -4
Limit                     Soft Limit           Hard Limit           Units
Max open files            1024                 4096                 files
Max processes             7864                 7864                 processes

I/Oでブロックされているプロセスの特定

CPU使用率が低いにもかかわらずシステム全体が「遅い」と感じられる場合、ディスクI/O待ちでプロセスが動けなくなっている可能性を疑います。

$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  4      0 1152340 412300 9821004    0    0  1200   850 1500 3200  8  3 40 49  0

この行のこの値に注目： procs欄のb列（blocked）は、ディスクI/Oの完了待ちで動けなくなっている（uninterruptible sleep状態の）プロセス数です。この値が0より大きい状態が続く場合、CPUには余裕があってもディスクI/O待ちがボトルネックになっている可能性が高いといえます。この例ではid（アイドル）が40%あるにもかかわらずwa（I/O待ち）が49%を占めており、CPUよりディスクI/Oの遅延が支配的であることが読み取れます。

$ ps aux | awk '$8 ~ /D/ {print}'
mysql     2355  4.2  3.1 1245680 512300 ?      Dl   10:15   0:42 mysqld

この行のこの値に注目： STAT列（この出力では8列目）にDが含まれるプロセスは、uninterruptible sleep（中断不可能なスリープ）状態、つまりカーネル内部でI/O完了を待っており、シグナルすら受け付けられない状態にあります。この状態が数秒以上続くプロセスがいれば、ディスクI/Oのボトルネックを強く疑うべきサインです。

$ cat /proc/2355/stack
[<0>] io_schedule+0x42/0x70
[<0>] wait_on_page_bit+0x139/0x230
[<0>] __filemap_fdatawait_range+0x8a/0x110
[<0>] vfs_fsync_range+0x4a/0xa0

/proc/<pid>/stackには、そのプロセスがカーネル内部のどの処理で停止しているかのコールスタック（呼び出し履歴）が表示されます。io_scheduleやwait_on_page_bitのような関数名が見えれば、そのプロセスがディスクI/Oの完了を待っている最中であることを直接確認できます。

ボトルネックの切り分けフローチャート

「サーバーが遅い」という漠然とした訴えを受けたとき、CPU・メモリ・ディスクI/O・ネットワーク・アプリケーションのどこに原因があるのかを、数値のしきい値を伴った手順で絞り込みます。

「遅い」という報告
   │
   ▼
① uptimeでロードアベレージを確認
   （コア数 × 1 を大きく超えているか？）
   │ YES                         │ NO（ロードは正常）
   ▼                             ▼
② vmstatで内訳を確認             ⑤ アプリケーション自体を疑う
   （r列とb列、どちらが多いか）     （スロークエリ、GC、外部API待ちなど）
   │
   ├─ r列（実行待ち）が多い → ③ CPUがボトルネック
   │     mpstat -P ALLで特定コアへの偏りを確認
   │
   └─ b列（I/O待ち）が多い → ④ ディスクI/Oがボトルネック
         iostat -xで%utilとawaitを確認
         lsof / iotopで原因プロセスを特定

この手順に沿って原因を絞り込む際の、代表的な判断基準（しきい値の目安）は次の通りです。

USEメソッドによる体系的な調査

場当たり的にコマンドを打っていくのではなく、体系的にボトルネックを洗い出す考え方としてUSEメソッド（Utilization / Saturation / Errorsメソッド）があります。これはシステムを構成する各リソース（CPU・メモリ・ディスク・ネットワークなど）について、次の3つの観点を機械的にチェックしていく手法です。

USEメソッドの利点は、「CPUだけ見て安心する」といった見落としを防げる点にあります。すべてのリソースについて機械的にUtilization・Saturation・Errorsの3点を確認していけば、原因の可能性がある箇所を漏れなく洗い出せます。特にErrorsは見落とされがちですが、エラーが多発しているリソースは、たとえ使用率が低くても実質的な性能低下（リトライによる遅延など）を引き起こしている場合があります。

キャパシティプランニングの考え方

単発の数値だけでなく、時系列でのトレンドを追うことが重要です。たとえば「ディスク使用率が毎月3%ずつ増加している」というトレンドが分かれば、あと何か月で満杯になるかを予測し、余裕を持って増設を計画できます。ピーク時の瞬間的な最大値だけでなく、平均的な使用率と、繁忙時間帯の90パーセンタイル値のような指標を組み合わせて見ることで、より現実的な余裕（ヘッドルーム）を見積もれます。

具体的な例で考えてみましょう。あるサーバーのディスク使用率が、sarのログから1月に60%、2月に63%、3月に66%と推移していたとします。この場合、月あたり約3ポイントずつ増加しているため、単純に線形で外挿すると「使用率90%（一般に運用上の危険水域とされることが多いしきい値）に達するまでおよそ8か月」という見積もりが立てられます。この予測をもとに、ディスク増設や不要データの削除といった対応を、実際に容量が逼迫する前の余裕を持ったタイミングで計画できるのが、キャパシティプランニングの本質的な価値です。

トレンド分析の実践 — 増加率から枯渇時期を予測する

キャパシティプランニングの核心は、過去のデータから将来を予測することです。具体的な数値を使って、実際にどう計算するかを見てみましょう。

sarのログから、あるサーバーのディスク使用率が次のように推移していたとします。

この2か月間で使用率が60%から66%まで、合計6ポイント増加しています。月あたりの増加率は次のように求められます。

月あたりの増加率 = (66% - 60%) ÷ 2か月 = 3ポイント/月

この増加率が今後も一定のペースで続くと仮定すると、危険水域とされることの多い90%に到達するまでの残り月数は次の計算で見積もれます。

90%到達までの残り月数 = (90% - 66%) ÷ 3ポイント/月 = 8か月

この見積もりにより、「あと8か月でディスクが逼迫する」という具体的な期限が分かり、増設や不要データの削除を計画的に進められます。実務では、このような計算を毎月手作業で行うのではなく、Zabbix・Prometheusなどの監視ツールに搭載されたトレンド予測機能（線形回帰による将来予測）を活用することが一般的です。

なぜ平均値ではなく90パーセンタイルを使うのか

キャパシティプランニングでは、単純な平均値ではなく90パーセンタイル（全サンプルのうち下から90%に位置する値）を使うことがよくあります。平均値は瞬間的なピークをならしてしまい、実際の負荷の厳しさを過小評価する傾向があるためです。一方、瞬間的な最大値（100パーセンタイル）をそのまま基準にすると、ごく短時間だけ発生した異常なスパイク1つに引きずられて、過剰な設備投資につながりかねません。90パーセンタイルは、「ごく稀な突発的ピークは無視しつつ、通常の繁忙時にどの程度の負荷がかかっているか」を現実的に捉えるための折衷的な指標として広く使われています。

しきい値設計 — 誤報を防ぐ2段階のしきい値と持続時間条件

監視システムでアラートを設定する際、単純に「1つのしきい値を超えたら即座に通知する」設計にすると、一時的な瞬間的なスパイクにも過剰に反応し、運用担当者が「オオカミ少年」化したアラートを無視するようになってしまう危険があります。実務では、次の2つの工夫を組み合わせて誤報を抑えます。

警告と危険の2段階しきい値

1つの指標に対して、「注意が必要な水準（Warning）」と「即座の対応が必要な水準（Critical）」の2段階のしきい値を設定するのが基本です。

持続時間条件によるスパイクの除外

もう1つの重要な工夫は、「しきい値を1回超えただけでは通知せず、一定時間その状態が継続した場合にのみ通知する」という持続時間条件を組み合わせることです。たとえば「CPU使用率が90%を1回超えた」だけでは通知せず、「CPU使用率90%以上の状態が5分間継続した」場合に初めて通知する、といった条件です。バッチ処理の開始直後など、数秒〜数十秒だけ一時的にリソース使用率が跳ね上がることは正常な運用でもよくあるため、この持続時間条件によって、そうした無害な瞬間的スパイクをアラートの対象から除外できます。

継続的な監視ソリューションの位置づけ

sarのようなコマンドは、その場での確認や簡単な履歴確認には便利ですが、複数台のサーバーを継続的に監視し、しきい値超過時に通知するといった運用には、専用の監視ソリューションを組み合わせるのが一般的です。LPIC-2の出題範囲では、代表的なツールとして以下が挙げられています。

これらのツールに共通するのは、単発の数値確認ではなく、継続的にメトリクスを収集・蓄積し、グラフとして可視化したりしきい値超過時にアラートを飛ばしたりする点です。MRTGやCactiのような可視化中心のツールと、Nagios/Icinga2のようなアラート・死活監視中心のツールを組み合わせて使う構成もよく見られます。試験対策としては、それぞれのツール名と大まかな役割（死活監視系か、グラフ化系か）を対応付けて覚えておくと十分です。

RRDtool（Round Robin Database Tool）は、CactiやMRTGが内部で利用しているデータ格納の仕組みです。通常のログファイルのようにデータを際限なく追記し続けるのではなく、あらかじめ固定サイズの「ラウンドロビン（円環状）」のデータベースを用意し、新しいデータが1件追加されるたびに、最も古いデータを上書きしていく設計になっています。この仕組みにより、データベースのファイルサイズが運用期間の長さに関わらず一定に保たれるという利点がありますが、裏を返すと、古い詳細データは時間の経過とともに自動的に集約・間引きされて失われていく（一定期間を過ぎると、1分単位の詳細データが1時間単位の平均値に集約されるなど）という特性もあります。

MRTG・Cacti・Nagios・Icinga2・collectdはいずれも歴史のあるツールで、LPIC-2の出題範囲には明示的に含まれていますが、現在の実務ではこれらに代わってPrometheus（メトリクス収集・保存）・Grafana（可視化）・Zabbix（統合監視）の組み合わせが広く使われる傾向にあります。基本的な役割の対応関係は次のように整理できます。

試験対策としては、まず出題範囲に明示されている5つのツール（Nagios/Icinga2/collectd/MRTG/Cacti）の名前と役割を正確に対応づけて覚えたうえで、実務ではその考え方が現代的なツールに引き継がれている、という背景まで理解しておくと理解が深まります。

SNMPの基礎

MRTGやCactiのような伝統的な監視ツールは、多くの場合SNMP（Simple Network Management Protocol）を使ってネットワーク機器やサーバーからメトリクスを取得します。SNMPは、ネットワーク経由でデバイスの状態を問い合わせるための古くからある標準プロトコルです。

$ snmpwalk -v2c -c public 192.0.2.10 1.3.6.1.2.1.1
iso.3.6.1.2.1.1.1.0 = STRING: "Linux router01 6.1.0-generic"
iso.3.6.1.2.1.1.3.0 = Timeticks: (12345678) 1 day, 10:17:36
iso.3.6.1.2.1.1.5.0 = STRING: "router01"

この行のこの値に注目： -v2cはSNMPのバージョン（v2c）、-c publicはコミュニティ文字列の指定です。指定したOID（この例では1.3.6.1.2.1.1、systemグループ全体）以下の情報を、対象デバイスから一括して取得（walk）しています。出力のsysDescr（システムの説明）やsysUpTime（稼働時間）といった項目名は、MIBファイルによってOIDの数値列から変換されたものです。

MRTGやCactiは、内部でこのsnmpwalk相当の処理を定期的に実行し、取得した数値をRRDtool形式のデータベースへ蓄積してグラフ化しています。SNMPの仕組みを理解しておくと、これらのツールがなぜネットワーク機器の情報まで扱えるのか、その裏側の動作を把握しやすくなります。

ネットワークI/Oの監視

CPU・メモリ・ディスクI/Oに加えて、ネットワーク帯域もキャパシティプランニングで見落とされがちな指標です。sar -n DEV 1を実行すると、各ネットワークインターフェースの送受信バイト数を秒間隔で確認でき、ip -s link（現行標準）やifconfig（非推奨の旧コマンド）でも累積の送受信量を確認できます。動画配信やファイル転送を伴うサービスでは、CPUやディスクに余裕があってもネットワーク帯域が先に上限に達してしまうことがあり、契約している回線やクラウドインスタンスの帯域上限を把握したうえで監視しておくことが望まれます。