こんにちは。 運用グループ所属の安藤です。
私の所属する運用グループでは主にサーバーの監視業務を行っており、アラートが発生したら対象のサーバーにログインして状況を確認します。状況確認のために行う様々なことの中に、社内で「基本コマンド」と呼ばれている5種類のコマンドの確認があります。今回は監視業務においてそれらの基本コマンドをどのように使用してアラート状況を把握しているかを紹介します。
基本コマンド
弊社で使用している基本コマンドは以下の5種類です。 アラート対応でサーバーにログインした際に最初に必ず実行します。
- w コマンド
- ps コマンド
- top コマンド
- vmstat コマンド
- netstat/ss コマンド
監視業務における基本コマンドの使い方
ここでは監視業務で各基本コマンドをどのように使っているのか具体的に紹介します。本記事ではコマンド実行結果の確認ポイントにフォーカスし、コマンドの操作やオプションの解説は割愛します。各基本コマンドのオプションはmanコマンドやWeb検索で簡単に確認できますので、ぜひ調べてみてください。
なお、各コマンドの実行結果は、AlmaLinux OS 8.5のサーバーでの実行結果を参考に作成・記載しています。他の環境では多少異なる実行結果となる可能性があるのでご注意ください。
w コマンド
サーバーの負荷状況やログインユーザを表示するコマンドです。
監視業務においては、オプションは指定せずに実行します。
$ w
コマンドの実行結果は以下になります。
[my-user@hostname ~]$ w 16:18:58 up 378 days, 1:17, 13 users, load average: 0.05, 0.03, 0.00 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT user_1 pts/0 10.0.0.10 Mon22 17:30m 0.07s 0.05s -bash user_2 pts/1 10.0.0.10 12:22 3:00 0.04s 0.00s -bash my_user pts/2 10.0.0.12 15:00 1.00s 0.04s 0.00s w
● 本コマンドの確認ポイント
サーバーが再起動されていないか
上記のup 378 days, 1:17の部分から、サーバーの稼働時間を確認します。上記の例の場合、サーバーは378日と1時間17分の間、再起動なしに稼働し続けていることがわかります。サーバーが起動された直後の場合は1 minのようにサーバーの稼働時間が数分前と表示されます。
特にサーバーとの疎通が取れない旨のアラートが発生した場合に確認が必要となる箇所です。サーバーが再起動された影響で疎通が取れなかったのか、その他の原因で疎通が取れなかったのかを切り分けられます。
ロードアベレージが増加傾向か減少傾向か
load average: 0.05, 0.03, 0.00の部分から、ロードアベレージがどれくらい高いかを確認できます。ロードアベレージとは一定時間内での実行中プロセス数と実行待ちプロセス数の合計の平均値で、サーバーの負荷状況を大まかに把握するのに役立ちます。3つの数値がカンマで区切られており、左から順に 1分平均値・5分平均値・15分平均値 となります。
以下のように、5分平均値や15分平均値と比較して1分平均値が高い場合、数分前より負荷が高い可能性が高いです。
load average: 15.00, 1.00, 1.00
以下のように、1分平均値が低いが5分平均値と15分平均値のいずかもしくは両方が高い場合、数分前よりも負荷が減少傾向である可能性が高いです。
load average: 1.00, 15.00, 10.00
直近で作業をしているユーザはいないか
USER列からユーザ名、IDLE列から無操作時間がわかります。上記の例の場合、user_1ユーザの無操作時間は17時間30分で、user_2ユーザの無操作時間が3分であることがわかります。また、WHAT列からはそのユーザが実行中のコマンドを確認できます。
無操作時間の短いユーザがいる場合、直近で何らかの作業を実施していた可能性があります。アラートが発生したサーバーに無操作時間の短いユーザがいれば、そのユーザの作業影響でアラートが発生した可能性を疑います。何らかのコマンドを実行中のユーザがいる場合でも同様です。
不審なユーザがいないか
FROM列からはユーザの接続元IPアドレスまたはFQDNを確認できます。
覚えのない接続元のユーザがいる場合、不正アクセスの可能性があるので、該当ユーザのログインプロセスの停止や接続元の遮断を検討します。
ps コマンド
実行中のプロセスを表示するコマンドです。
監視業務においては、オプションを含めて以下のように実行します。
$ ps aufxww
コマンド実行結果は以下になります。なお、psコマンドの実行結果は非常に長くなるため、一部を抜粋して記載しています。
[my-user@hostname ~]$ ps aufxww USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 750 0.0 0.0 70232 184 ? Ssl 2022 3:46 /sbin/auditd chrony 805 0.0 0.0 149116 672 ? S 2022 0:06 /usr/sbin/chronyd root 824 0.0 0.0 92796 1936 ? Ss 2022 18:17 /usr/lib/systemd/systemd-logind root 851 0.0 0.0 599676 2760 ? Ssl 2022 7:13 /usr/sbin/NetworkManager --no-daemon root 818919 0.0 0.0 246728 1696 ? Ss Feb15 0:28 /usr/sbin/crond -n -m off root 578363 0.0 0.1 335900 6528 ? S 16:50 0:00 \_ /usr/sbin/CROND -n -m off root 578366 0.0 0.0 221360 1068 ? R 16:50 0:00 \_ /root/bin/my_script.sh root 990 0.0 0.1 366212 3792 ? Ss 2022 7:21 /usr/sbin/httpd -DFOREGROUND apache 4166375 0.0 0.1 618492 5552 ? Sl Mar19 0:34 \_ /usr/sbin/httpd -DFOREGROUND apache 4166470 0.0 0.1 421812 6036 ? Sl Mar19 0:27 \_ /usr/sbin/httpd -DFOREGROUND apache 4166509 0.0 0.1 421812 5412 ? Sl Mar19 0:27 \_ /usr/sbin/httpd -DFOREGROUND
● 本コマンドの確認ポイント
直近で起動しているプロセスがないか
TIME列でプロセスの起動日時を確認できます。上記の実行例の場合、my_script.shが16:50に実行されていることがわかります。現在時刻が16:50に近い場合、そのプロセスは直近で起動したことがわかります。
また、上記の実行例にてプロセスがツリー形式で表示されることも確認できます。子プロセスは必ず親プロセスから実行されます。上記の実行例の場合、my_script.shの親プロセスはcrondであることがわかります。
監視業務においては、直近で起動したプロセスを把握することで、発生したアラートとの関連を疑えます。
ステータスに偏りがないか
STAT列でプロセスのステータスを確認できます。特によく確認するステータスは以下のとおりです。
- S：スリープ状態のプロセス
- R：実行中、またはCPUが使用可能になり次第実行されるプロセス
- D：割り込み不可能なスリープ状態のプロセス。多くの場合、ディスクI/Oの処理の完了を待っている
監視業務では、主にR,D,Zのステータスのプロセスが多くないか確認します。RはCPUで処理を実行中もしくは実行待ちのプロセスであるため、そのプロセスがCPU負荷上昇の原因となります。DはI/O処理を行っているプロセスで、特にディスクI/Oが発生中である場合が多いため、そのプロセスがディスクI/O負荷上昇の原因となる可能性が高いです。wコマンドの結果からロードアベレージが高いことが分かっていれば、R,Dステータスのプロセスを確認することで原因となっているプロセスの目星をつけられます。
top コマンド
各プロセスの実行状況を表示するコマンドです。各種項目別にソートして表示できるため、CPU使用率の高いプロセスやメモリ使用率の高いプロセスを特定する際に役立ちます。
監視業務においては、オプションを含めて以下のように実行します。
$ top -cd1
コマンド実行結果は以下になります。なお、topコマンドの実行結果は長くなるため、一部を抜粋して記載しています。
[my-user@hostname ~]$ top -cd1
top - 17:22:51 up 120 days, 6:07, 1 user, load average: 0.62, 0.69, 0.77
Tasks: 208 total, 4 running, 204 sleeping, 0 stopped, 0 zombie
%Cpu(s): 49.8 us, 2.3 sy, 0.0 ni, 46.7 id, 0.0 wa, 1.1 hi, 0.0 si, 0.0 st
MiB Mem : 3688.6 total, 1724.1 free, 1334.1 used, 630.3 buff/cache
MiB Swap: 4096.0 total, 2341.6 free, 1754.4 used. 1954.7 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3924534 root 20 0 485680 247140 1804 S 99.2 6.5 13037:16 /root/bin/my_script.sh
861 root 20 0 123396 31728 4816 S 1.3 0.8 736:37.12 /usr/local/hb-agent/bin/happo-agent daemon
583778 my-user 20 0 275376 5448 4500 R 0.8 0.1 0:00.13 top -c
4166668 apache 20 0 421812 5532 4148 S 0.6 0.1 0:27.51 /usr/sbin/httpd -DFOREGROUND
● 本コマンドの確認ポイント
CPU使用率やメモリ使用率の高いプロセスがないか
%CPU列にはCPU使用率、%MEM列にはメモリ使用率、COMMAND列には実行されているコマンドが表示されます。topコマンドは指定した列を降順で表示できるため、CPUやメモリ使用率の高いプロセスを特定する際に役立ちます。上記の実行例ではCPU使用率の高い順にソートしているため、もっともCPU使用率の高いプロセスはmy_script.shであることがわかります。
異常にCPU使用率やメモリ使用率の高いプロセスがあればプロセス再起動を検討します。インターネットからの接続があるようなプロセス（sshdやhttpd等）のCPU使用率が高い場合は、そのプロセスのログからインターネットからの攻撃かどうかを判断し、必要に応じて接続元を遮断します。
vmstat コマンド
CPU、ディスクI/O、メモリ等の状況を指定秒数間隔で表示できるコマンドです。
監視業務においては、オプションを含めて以下のように実行します。
$ vmstat 1 -w
コマンド実行結果は以下になります。なお、本コマンドで表示される結果は基本的に各行の出力時点の状況ですが、コマンド実行直後の1行目の結果のみサーバー起動後からの統計情報です。今現在の状況を確認したい場合は、2行目以降を確認します。
[my-user@hostname ~]$ vmstat 1 -w procs -----------------------memory---------------------- ---swap-- -----io---- -system-- --------cpu-------- r b swpd free buff cache si so bi bo in cs us sy id wa st 0 0 744960 1188992 16 668852 0 0 16 40 1 0 5 2 94 0 0 0 0 744960 1173716 16 668696 0 0 0 16 1410 3800 36 11 54 0 0 1 0 744960 1190300 16 668808 0 0 0 260 1050 3275 35 11 53 1 0 0 0 744960 1190976 16 668760 0 0 0 124 226 947 18 3 79 0 0 1 0 744960 1190724 16 668744 0 0 0 85 125 995 11 2 86 0 0
● 本コマンドの確認ポイント
サーバー負荷の原因はCPU負荷かディスクI/O負荷か
procsのr列からはRステータスであるプロセスの合計数、b列からはDステータスであるプロセスの合計数を確認できます。
wコマンドのロードアベレージの確認結果と併せて、負荷の原因の大まかな切り分けを行います。
CPU負荷の原因は何か
cpuには単位時間におけるCPU使用時間が分類ごとに割合で表示されます。各列は以下の内容を表しています。
- us：一般的なプログラムの実行にCPUを使用した時間（user）
- sy：OS側の処理にCPUを使用した時間（system）
- id：アイドル時間（idle）
- wa：I/O処理（多くの場合ディスクI/O処理）を待っていた時間（iowait）
- st：仮想化環境において、要求したCPUリソースが割り当てられず使用できなかった時間（steal）
waが高い場合、ディスクI/O処理の時間が長い可能性が高いため、ディスクI/O負荷が高い可能性があります。
stは要求したCPUリソースが仮想化基盤※1側から割り当てられなかった場合に増加します。例えば、仮想化基盤のCPUリソース100%のうち仮想マシンAが80%のCPUリソースを使用していると、仮想マシンBが40%のCPUリソースを要求しても不足分の20%分は使用できないことになります。この20%がCPU Stealです。一般的な仮想化基盤であれば、CPU Stealは仮想化基盤側の問題である可能性があります。CPU Stealはシステムのパフォーマンス低下を招くため、仮想化基盤の変更やクラウドベンダー等への問い合わせをします。
AWSの場合、T系インスタンス※2のCPUクレジットが枯渇した状態でベースラインCPU使用率を超過するとstが増加します。そのため、対応としてインスタンスタイプの変更やUnlimitedモードの有効化を検討します。
仮想化基盤とは、仮想マシンが実際に動く物理サーバーなどで構成される実体の環境のことで、クラウドにおける仮想マシンなども仮想化基盤上で動いています。
T系ファミリーインスタンスにはベースラインのCPU使用率というものが決められており、そのCPU使用率を超過するとバーストという状態になります。バースト時はCPUクレジットを消費することで、ベースライン以上のパフォーマンスを出すことができます。しかし、CPUクレジットが枯渇するとバーストできなくなり、ベースライン以上のCPUを使用できなくなります。
スラッシングが発生していないか
procsのb列やcpuのwa列の値が高い場合、swapのsi列とso列からスワップ※3の状態も確認する必要があります。siはスワップイン、soはスワップアウトを表します。
スワップアウトは物理メモリ上に記憶されているデータをディスク上に退避すること、スワップインはディスク上に退避していたデータを物理メモリ上に戻すことを指します。いずれの処理もディスクI/Oが発生するため、多発するとパフォーマンスの低下を招きます。この状態をスラッシングといいます。siとsoが高い場合は、スラッシングが発生している可能性があります。物理メモリが不足している可能性があるため、物理メモリ使用率の高いプロセスの停止や物理メモリ増設を検討します。
スワップは物理メモリ上に記憶されているデータをディスク上に退避する処理のことで、主に物理メモリの空きが不足しているか、もしくは空き領域が断片化していることが原因でまとまったメモリ領域を確保できないときに発生します。すでに物理メモリ上に記憶されているデータをディスク上に退避することでまとまった物理メモリの空き領域を確保します。
netstat/ssコマンド
netstatとssはいずれもコネクションの状態を確認をするコマンドです。 ssコマンドはnetstatコマンドの代わりとして今後置き換わっていくコマンドです。確認できる内容はほとんど同じであるため、代表としてnetstatコマンドを紹介します。netstatコマンドがインストールされていない場合は、dnfコマンドを使ってnet-toolsパッケージをインストールしてください。
監視業務においては、オプションを含めて以下のように実行します。一般ユーザ権限でコマンドを実行すると情報が全て表示されないため、root権限でコマンドを実行する必要があります。
$ sudo netstat -anpt
ssコマンドも同様のオプションで同様の出力を得られます。
$ sudo ss -anpt
コマンド実行結果は以下になります。なお、netstatコマンドの実行結果は長くなるため、一部を抜粋して記載しています。
[my-user@hostname ~]$ sudo netstat -anpt Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 1/systemd tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 990/httpd tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 3450299/unbound tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1272/sshd tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 990/httpd tcp 0 0 10.19.0.10:33084 XXX.XXX.XXX.XXX:80 TIME_WAIT - tcp 0 0 10.19.0.10:443 XXX.XXX.XXX.XXX:53763 ESTABLISHED 2071/httpd tcp 0 0 10.19.0.10:443 XXX.XXX.XXX.XXX:59844 ESTABLISHED 2050/httpd tcp 0 0 10.19.0.10:33126 XXX.XXX.XXX.XXX:80 TIME_WAIT - tcp 0 0 10.19.0.10:33143 XXX.XXX.XXX.XXX:6777 TIME_WAIT - tcp 0 0 10.19.0.10:33013 XXX.XXX.XXX.XXX:80 TIME_WAIT - tcp 0 0 10.19.0.10:33119 XXX.XXX.XXX.XXX:6777 TIME_WAIT - tcp 0 0 10.19.0.10:33014 XXX.XXX.XXX.XXX:80 TIME_WAIT -
● 本コマンドの確認ポイント
特定のIPアドレスからのコネクションが多くないか
Foreign Address列から、本サーバーに接続しているIPアドレスを確認できます。
特定のIPアドレスから多数の接続がある場合、インターネットからの攻撃の疑いがあります。PID/Program列から接続先のプロセスを特定し、場合によっては遮断を実施します。
おわりに
本記事では、弊社で監視業務に使用している基本コマンドについて、どのようなポイントをチェックしているかを解説しました。実際の業務では各種ログやリソースグラフも確認しますので、今回ご紹介した内容はアラート対応のごく一部となりますが、サーバー運用における状況確認の参考になれば幸いです。
