はじめに
Linuxを勉強していると、
top
free
df
ps
systemctl
ss
ip
ping
など、サーバの状態を確認するためのさまざまなコマンドが出てきます。
それぞれのコマンドの役割は分かっても、
「実際にLinuxサーバを点検するとしたら、何をどの順番で確認すればいいのか？」
という疑問がありました。
そこで今回は、自宅のUbuntu Serverを使って、正常な状態の日次点検を実際に行ってみました。
今回確認した流れは次のとおりです。
操作対象
↓
稼働時間・Load Average
↓
CPU・プロセス
↓
メモリ
↓
ディスク
↓
nginxサービス
↓
nginxプロセス
↓
80番ポート
↓
HTTP応答
↓
アクセスログ
↓
IPアドレス
↓
疎通確認
一つのコマンドだけで「正常」と判断するのではなく、確認した結果を次の確認につなげていくことを意識しました。
検証環境
今回使用したのは、VirtualBox上に構築したUbuntu Serverです。
| ホスト | IPアドレス | 用途 |
|---|---|---|
| controller | 192.168.56.10 | 操作用 |
| tokyo | 192.168.56.11 | 点検対象 |
controllerからtokyoへSSH接続し、tokyoの状態を確認します。
今回はAnsibleなどによる自動化は行いません。
まず手作業で、
「何を確認するために、そのコマンドを使うのか」
を理解することを目的にしています。
1. 操作しているサーバを確認する
最初にcontrollerからtokyoへSSH接続します。
ssh tokyo@192.168.56.11
接続したらホスト名を確認します。
hostname
結果：
tokyo
続いてIPアドレスも確認しました。
hostname -I
表示されたIPアドレスの中に、
192.168.56.11
が含まれていることを確認しました。
基本的な確認ですが、複数台のサーバを扱う場合、
「今どのサーバを操作しているのか」
を最初に確認しておくことは重要だと感じました。
別のサーバを誤って操作しないためにも、まず対象を確認してから点検を始めます。
2. uptimeで稼働時間とLoad Averageを確認する
まずサーバ全体の様子を見るため、uptimeを実行しました。
uptime
今回の結果は、
22:44:44 up 15 min, 1 user, load average: 0.04, 0.34, 0.70
でした。
ここから、
- 起動してから15分
- ログインユーザー1人
- Load Average：0.04 / 0.34 / 0.70
であることが分かります。
ただし、Load Averageの数字だけを見ても判断しにくいため、CPU数も確認しました。
nproc
結果：
1
今回のtokyoにはCPUが1つ割り当てられています。
uptimeだけを見るのではなく、CPU数と組み合わせて状態を見るようにしました。
3. topでサーバ全体の状態を確認する
続いて、
top
を実行しました。
確認した時点では、次のような状態でした。
Tasks : 115
zombie : 0
CPU idle : 99.2%
I/O wait : 0.0%
Memory total : 961.6 MiB
available : 582.6 MiB
Swap used : 0.0 MiB
topには多くの情報が表示されます。
今回は、
Load Average
↓
プロセス数
↓
CPU
↓
メモリ
↓
Swap
↓
CPUやメモリを使用しているプロセス
という順番で確認しました。
CPUについては、
99.2 id
となっていました。
idはCPUがアイドル状態である割合なので、今回確認した時点ではCPUの大部分が使用されていない状態でした。
また、
zombie：0
I/O wait：0.0%
であることも確認しました。
topは情報量が多いですが、見る場所をある程度決めておくとサーバ全体の状態を確認しやすくなりました。
4. free -hでメモリを確認する
topでもメモリは確認できますが、もう少し見やすく確認するため、
free -h
を実行しました。
今回の結果は次のとおりです。
total : 961Mi
used : 378Mi
free : 227Mi
buff/cache : 498Mi
available : 582Mi
Swap used : 0B
最初に、
free：227Mi
が目に入りました。
約1GBのメモリに対して227MiBしか空いていないように見えます。
しかし、Linuxでは空いているメモリをキャッシュなどにも利用します。
そこでavailableを見ると、
582Mi
となっていました。
そのため、freeだけを見て、
「空きメモリが少ない＝すぐにメモリ不足」
とは判断せず、availableも確認する必要があることが分かりました。
5. df -hでディスク容量を確認する
次はディスクを確認します。
df -h
ルートファイルシステムは、
/dev/sda2 25G 5.7G 18G 25% /
となっていました。
今回の環境には、ルートファイルシステム以外にも、
/lvmdata
/data
という領域があります。
ここで気づいたのが、
使用率だけではなく、どのファイルシステムなのかも確認する必要がある
ということです。
例えば同じ「ディスク使用率が高い」という状態でも、
/
なのか、
/data
なのかによって、その後確認する場所も変わります。
そのためdf -hでは、使用率とマウント先をセットで見るようにしました。
6. systemctlでnginxの状態を確認する
CPU・メモリ・ディスクを確認したら、次はサービスを確認します。
今回のtokyoではnginxを動かしています。
systemctl status nginx
確認した結果、
Loaded: loaded
enabled
Active: active (running)
となっていました。
ここで確認したのが、
enabled
と、
active (running)
の違いです。
enabledはOS起動時にnginxが自動起動する設定になっていることを示します。
一方、
active (running)は現在nginxが動作していることを示します。
似たように見えますが、確認している内容は異なります。
7. psでnginxのプロセスを確認する
systemctlではnginxが動作していました。
続いて、実際にnginxのプロセスが存在することも確認しました。
ps aux | grep nginx
結果には、
nginx: master process
nginx: worker process
が表示されました。
さらに確認すると、systemctl status nginxで表示されたMain PIDと、psで確認できたPIDも一致していました。
つまり、
systemctl
→ サービスとしての状態
ps
→ 実際のプロセス
という異なる角度からnginxを確認できました。
8. ssで80番ポートを確認する
プロセスが存在していても、
実際にWebサーバとして接続を受け付けているか
はまだ確認できていません。
そこで、
sudo ss -lntp | grep ':80'
を実行しました。
結果には、
0.0.0.0:80
[::]:80
が表示され、どちらもLISTENとなっていました。
これでnginxがTCPの80番ポートで接続を待ち受けていることを確認できました。
9. curlで実際にHTTPリクエストを送る
ここまでで、
サービスが動作している
↓
プロセスが存在している
↓
80番ポートでLISTENしている
ことは確認できました。
ただし、
実際にHTTPリクエストへ正常に応答できるか
はまだ分かりません。
そこで、
curl -I http://localhost
を実行しました。
結果：
HTTP/1.1 200 OK
これで、実際のHTTPリクエストにも正常に応答できていることを確認できました。
10. nginxのアクセスログを確認する
最後に、先ほどのHTTPリクエストがログにも記録されているか確認しました。
sudo tail -n 20 /var/log/nginx/access.log
ログには、
::1 - - [27/Sep/2026:23:04:00 +0000] "HEAD / HTTP/1.1" 200 0 "-" "curl/8.5.0"
という記録がありました。
直前に実行した、
curl -I http://localhost
の記録です。
-Iを付けているため、
HEAD / HTTP/1.1
と記録されています。
ステータスコードも、
200
でした。
ここまで確認すると、nginxについては、
systemctl
↓
サービス状態
ps
↓
プロセス
ss
↓
80番ポート
curl
↓
HTTP応答
access.log
↓
実際のアクセス記録
という流れで確認できました。
個人的には、今回の日次点検で一番勉強になった部分です。
それぞれ別々に覚えていたLinuxコマンドが、一つの確認作業としてつながりました。
11. ip addrでネットワーク設定を確認する
nginxだけではなく、ネットワークについても正常状態を確認します。
ip addr
今回の環境ではenp0s8に、
192.168.56.11/24
が設定されていることを確認しました。
12. pingで実際の通信も確認する
IPアドレスが設定されているだけでは、相手と通信できるとは限りません。
そこでtokyoからcontrollerへ、
ping -c 4 192.168.56.10
を実行しました。
結果：
4 packets transmitted, 4 received, 0% packet loss
正常に通信できることを確認できました。
この確認は、nginxで行った、
サービスが動いている
↓
実際にHTTPリクエストを送る
という確認と似ていると感じました。
ネットワークでも、
IPアドレスが設定されている
↓
実際に通信できる
まで確認することで、より実際の状態を確認できます。
日次点検で使ったコマンドを整理する
今回使用したコマンドをまとめると次のようになります。
| 確認内容 | コマンド |
|---|---|
| ホスト名 | hostname |
| IPアドレス |
hostname -I / ip addr
|
| 稼働時間・Load Average | uptime |
| CPU数 | nproc |
| CPU・プロセス・メモリ | top |
| メモリ | free -h |
| ディスク | df -h |
| nginxサービス | systemctl status nginx |
| nginxプロセス | ps aux | grep nginx |
| 80番ポート | sudo ss -lntp | grep ':80' |
| HTTP応答 | curl -I http://localhost |
| nginxアクセスログ | sudo tail -n 20 /var/log/nginx/access.log |
| 疎通確認 | ping -c 4 192.168.56.10 |
今回重要だと感じたのは、コマンドの数そのものではありません。
一つの確認結果を、次の確認につなげること
です。
例えばnginxなら、
systemctl
↓
ps
↓
ss
↓
curl
↓
access.log
と確認しました。
ネットワークなら、
ip addr
↓
ping
です。
単にコマンドを覚えるだけではなく、
「この結果が正常なら、次に何を確認するのか」
まで考えることで、それぞれのコマンドの役割がつながって見えるようになりました。
まとめ
今回は、自宅のUbuntu Serverで正常状態の日次点検を行いました。
確認したのは、
操作対象
↓
稼働時間・負荷
↓
CPU・プロセス
↓
メモリ
↓
ディスク
↓
サービス
↓
プロセス
↓
ポート
↓
HTTP応答
↓
ログ
↓
ネットワーク
↓
疎通
です。
今回の目的は、
「この数値なら絶対に正常」
という基準を作ることではありません。
まず正常な状態で実際のコマンド結果を確認し、今後障害を再現したときに、
「正常時と何が変わったのか」
を比較できる状態にすることです。
次は、この正常状態をあえて崩し、
症状を確認
↓
コマンドで切り分け
↓
原因を調査
↓
修正
↓
正常状態へ復旧
という流れを実機で試していきます。
この検証の続きを読みたい方へ
この記事では、Linuxサーバの日次点検で使用したコマンドと、実際にどの順番で確認したかに絞ってまとめました。
今回の検証は、
「LinuCレベル1で勉強したLinuxの知識を、実際のLinuxサーバで使ってみる」
という実機検証シリーズの一部です。
実機検証の流れを最初から読みたい
noteでは、なぜこの検証を始めたのかというところから、実際のコマンド結果や、確認しながら気づいたことまで含めて記録しています。
今後は正常状態の確認だけでなく、実際に障害を再現し、
障害発生
↓
症状確認
↓
切り分け
↓
原因調査
↓
修正
↓
復旧確認
まで試していく予定です。
note
今後の検証を追いたい
Xでは、Linux・Ansible・Python・Excelなどの実機検証について、記事になる前の途中経過や、実際に試して気づいたことも投稿しています。
「次はどんな障害を起こして、どう切り分けるのか」
など、今後の検証も追ってみたい方はこちらからどうぞ。
X