【サーバー管理入門 最終回】ユーザーからのクレームを待つな。「監視」の技術とプロの運用論

【サーバー管理入門最終回】ユーザーからのクレームを待つな。「監視」の技術とプロの運用論
本講座のカリキュラム
1. 監視（モニタリング）の3大要素
2. リアルタイム監視の神器「top」と「htop」
1. Load Average の正体
2. 見やすい「htop」の導入
3. メモリ不足の真実「free」コマンド
4. 過去に遡って調査する「sar」コマンド
1. 導入と有効化
2. 過去ログの閲覧
5. ディスク容量と「i-node」の枯渇
1. 隠れた罠「i-node枯渇」
6. 障害発生時のプロの対応フロー（インシデントレスポンス）
講座のまとめ：管理者への道は続く

【サーバー管理入門最終回】ユーザーからのクレームを待つな。「監視」の技術とプロの運用論

こんにちは！「リナックス先生」です。
前回は、サーバー管理の最後の砦である「バックアップとリストア」を訓練しました。
これでシステムを構築し、守る準備は整いましたね。
コウ君、全12回の講座もいよいよこれが最後よ。

先生、寂しいです！でも、もうサーバー構築もできるし、自動化もバックアップも完璧です。
これで僕も、明日から一人前のサーバー管理者としてやっていけますよね？
もう何も怖いものはありません！

ふふ、慢心は最大の敵よ。
サーバー構築は「作って終わり」じゃない。そこからが本当の戦い、「運用」のスタートなの。
「Webサイトが見れません！」ってユーザーから怒りの電話が来てから気づくようじゃ三流よ。
最終回は、サーバーの悲鳴を予知する「監視（モニタリング）」と、プロの運用マインドについて叩き込むわ！

「Linuxサーバー管理者入門」最終回となる今回は、サーバーの健康状態を維持し続けるための「監視と運用」について解説します。
top や sar といったコマンドの使い方だけでなく、「何を監視すべきか」「障害が起きたらどう動くか」という、エンジニアとしての立ち振る舞いを学びましょう。

本講座のカリキュラム

1. 監視（モニタリング）の3大要素

一口に「サーバー監視」と言っても、見るべきポイントは大きく3つに分かれます。

監視の種類	内容	コマンド例
死活監視 (Alive Check)	サーバーが生きてるか？ネットワークが繋がるか？	`ping`
サービス監視 (Service Check)	WebやDBが動いているか？ポートが開いているか？	`systemctl status` `curl`, `nc`
リソース監視 (Resource Check)	CPU・メモリ・ディスクはパンクしていないか？	`top`, `free`, `df` `sar`

これらの異常を検知した瞬間に、メールやSlackで管理者に通知を飛ばす仕組みを作るのが、インフラエンジニアの仕事です。
（本格的な運用には Zabbix や Prometheus などの専用ツールを使いますが、まずはLinuxコマンドでの調査方法をマスターしましょう）

2. リアルタイム監視の神器「top」と「htop」

「サーバーが重い！」と言われた時、最初に叩くコマンドが top です。
Windowsのタスクマネージャーのようなものです。

[root@server01 ~]# top

画面の見方で、特に重要なのが「Load Average（ロードアベレージ）」です。

top - 10:00:00 up 10 days,  ...  load average: 0.05, 0.10, 0.08

Load Average の正体

これは単なるCPU使用率ではありません。「CPUでの処理を待っている、またはディスクI/Oを待っているプロセスの行列の長さ」を表します。
3つの数字は、左から「1分間」「5分間」「15分間」の平均値です。

CPUコア数以下なら安全： 2コアのサーバーで 1.5 なら余裕あり。
CPUコア数を超えたら危険： 2コアのサーバーで 5.0 なら、処理が詰まっていてレスポンスが悪化しています。

見やすい「htop」の導入

標準の top は少し見づらいので、色付きでグラフィカルな htop を入れるのが現代の主流です。
（EPELリポジトリが必要です。第3回参照）

[root@server01 ~]# dnf install epel-release -y
[root@server01 ~]# dnf install htop -y
[root@server01 ~]# htop

3. メモリ不足の真実「free」コマンド

メモリの空き状況を確認するには free -h を使います。

[root@server01 ~]# free -h
               total        used        free      shared  buff/cache   available
Mem:           1.8Gi       450Mi       120Mi       5.0Mi       1.2Gi       1.2Gi
Swap:          2.0Gi          0B       2.0Gi

⚠️ 「free」列を見てはいけない

初心者は free（完全な空き）の数字を見て「残り120MBしかない！メモリ不足だ！」と慌てがちです。
しかし、Linuxは余っているメモリを積極的に「キャッシュ（buff/cache）」として使い、ディスクアクセスを高速化する特性があります。
見るべきは「available（利用可能）」の列です。
ここが十分にあれば、アプリが必要とした瞬間にキャッシュを解放してメモリを明け渡してくれるので、問題ありません。

4. 過去に遡って調査する「sar」コマンド

top は「今」しか見れません。
「昨日の夜中3時にサーバーが止まったらしい」という時、どうしますか？
そんな時に役立つのが、システムの統計情報を記録し続けるツール sysstat (sar) です。

導入と有効化

[root@server01 ~]# dnf install sysstat -y
[root@server01 ~]# systemctl enable --now sysstat

これで、10分おき（デフォルト）にあらゆるリソース情報が記録され始めます。

過去ログの閲覧

# 今日のCPU使用率履歴を見る
[root@server01 ~]# sar -u

# メモリ使用率履歴を見る
[root@server01 ~]# sar -r

# 特定の日付（ファイル指定）を見る
[root@server01 ~]# sar -u -f /var/log/sa/sa20

「夜中にバックアップ処理が走ってCPUが100%になっていた」などの犯人探しには欠かせないツールです。

5. ディスク容量と「i-node」の枯渇

第5回でLVMを学びましたが、監視においてもディスクは最重要項目です。

[root@server01 ~]# df -h
Filesystem                  Size  Used Avail Use% Mounted on
/dev/mapper/almalinux-root   27G  1.8G   26G   7% /

隠れた罠「i-node枯渇」

ディスク容量（GB）は余っているのに、「No space left on device」というエラーが出てファイルが作れなくなることがあります。
これは「i-node（ファイルを管理する番号）」が足りなくなった状態です。
大量の小さなファイル（メールやキャッシュファイルなど数百万個）を作成すると発生します。

# i-nodeの使用率を確認
[root@server01 ~]# df -i

容量監視だけでなく、i-node監視も忘れないのがプロの証です。

6. 障害発生時のプロの対応フロー（インシデントレスポンス）

実際にアラートが鳴り響いた時、どう動くべきでしょうか？
パニックにならず、以下の手順で動くことが求められます。

状況把握 (Status Check)：
- サービスは落ちているのか？重いだけか？
- エラー画面は出ているか？
影響範囲の特定 (Scope)：
- 全ユーザーか？特定の機能だけか？
- Webサーバーだけか？ DBもか？
一次対応 (Workaround)：
- サービスの再起動は最後の手段。
- まずはログ (journalctl, /var/log/messages) を確保する。
- 明らかに攻撃を受けているならファイアウォールで遮断。
恒久対策 (Fix)：
- 根本原因（コードのバグ、スペック不足など）を取り除く。