えいのうにっき

むかしのじぶんのために書いています

「障害発生時に即座に収集したいサーバの状態・14項目」を実際に収集してみた

僕はインフラエンジニアではないし、そうだったこともないのだけど、いま「インフラエンジニアの教科書2」という本を読んでいる。

インフラエンジニアの教科書2 スキルアップに効く技術と知識

インフラエンジニアの教科書2 スキルアップに効く技術と知識

Twitter かなにかでこの本の存在を知り、とりあえず買ってみたものの、しばらくの間積読状態になってしまっていた。…のだけど、最近になってようやくちまちまと読んでいる。関係ないけど、kindleで読めるのはほんとに便利だ。

f:id:a-know:20161120213000p:plain

この本の7章「障害対策と障害対応」で、『以下のような項目についてはサーバ障害時に即座に(20秒程度で!)収集できるべき』、とされていた。

  1. メモリの搭載量と使用量
  2. パーティションごとのディスクの使用率と空き容量
  3. CPUの種類とコア数
  4. ディスクのRAID構成
  5. CPU使用率
  6. ディスクアクセス率
  7. TCPコネクションの数
  8. 現在サーバにログインしているユーザ
  9. サーバが起動してからのえ経過時間
  10. (それが Web サーバの場合、)Webサーバには何が動いているか?
  11. (DBと連携しているWebサーバの場合、)何のDBサーバソフトウェアと接続しているか?
  12. メモリやハードディスクが故障していると仮定したときに、その証拠の調べ方
  13. サーバにはUSBメモリが接続されているか否か?
  14. ネットワーク機器とサーバのネットワークインタフェースは何Gbpsで接続されているか?

これら全ての項目の収集を20秒でやりきれる自信は僕にはさらさら無かったし、なによりこの本の中ではコマンドしか紹介されていなかったので、そのひとつひとつについて自分のサンドボックス的サーバに対しておもむろに実行してみた。これはそのまとめになる。

サンドボックス的サーバ」というのは、さくらのクラウドに立てているVMインスタンス。以下のようなかんじのもの。

$ cat /etc/system-release
CentOS Linux release 7.2.1511 (Core) 
$ uname -a
Linux sandbox 3.10.0-327.22.2.el7.x86_64 #1 SMP Thu Jun 23 17:05:11 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

1. メモリの搭載量と使用量

$ free
              total        used        free      shared  buff/cache   available
Mem:        2049096     1302304      163160      106752      583632      437524
Swap:       4194300       35276     4159024

free/proc/meminfo の内容を整形して表示するコマンド。特にオプションを指定せずに実行するとそのサイズの表示はキロバイト単位になる。

  • total
    • OSが認識している総メモリサイズ。
  • used
    • 使用しているメモリサイズ。
    • バッファ・ページキャッシュも含む。
  • free
    • 空きメモリのサイズ。
    • 基本的にOSは空きメモリをどんどんキャッシュに使用していくので、この値は0に近づいていく。
    • この値が常に低い値であるからといって、メモリが不足しているというわけではない。
  • shared
    • 共有メモリに割り当てられているサイズ。
    • 共有メモリとは、複数プロセス間で共有可能なメモリ領域(?)
  • buff/cache
    • バッファ・ページキャッシュに使用されているメモリサイズ。
  • available
    • 実際の空きメモリサイズと、キャッシュ済みのメモリ領域のうちすぐに開放可能な領域のサイズを足したもの?

Swapスワップ領域についての情報。

2. パーティションごとのディスクの使用率と空き容量

$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
/dev/vda3         16G  3.0G   12G   21% /
devtmpfs         987M     0  987M    0% /dev
tmpfs           1001M     0 1001M    0% /dev/shm
tmpfs           1001M  105M  897M   11% /run
tmpfs           1001M     0 1001M    0% /sys/fs/cgroup
tmpfs            201M     0  201M    0% /run/user/1000

3. CPUの種類とコア数

$ cat /proc/cpuinfo | grep -e "model name" -e cores
model name  : Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz
cpu cores   : 1

/proc/cpuinfo の中身をそのまま見てみる。

$ cat /proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model       : 45
model name  : Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz
stepping    : 7
microcode   : 0x1
cpu MHz     : 2499.998
cache size  : 4096 KB
physical id : 0
siblings    : 1
core id     : 0
cpu cores   : 1
apicid      : 0
initial apicid  : 0
fpu     : yes
fpu_exception   : yes
cpuid level : 13
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb lm constant_tsc arch_perfmon nopl eagerfpu pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx hypervisor lahf_lm xsaveopt
bogomips    : 4999.99
clflush size    : 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

4. ディスクのRAID構成

これについては MegaCli hpssacli のいずれかを用いて調べるコマンドが載ってたんだけど、僕のサーバはクラウドサーバということもあってか?どちらも使えなかった。

5. CPU使用率

$ w
 19:50:04 up 57 days, 21:52,  1 user,  load average: 0.35, 0.20, 1.37
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
a-know   pts/0    xxx.xx.xx.xx     19:13    4.00s  0.02s  0.00s w

w コマンド自体はCPU使用率を調べるためのコマンドというよりは、そのホストに現在ログインしているユーザとその利用状況を表示するためのコマンド。 コマンド結果の一行目は、

を、それぞれ表している。

$ top -d 1

こちらは言わずと知れた top コマンド。これの実行結果は割愛するけど、-d オプションで表示更新間隔を指定できる。

6. ディスクアクセス率

iostat コマンドを使うのだけど、未インストールだった。てことで、この機会にインストールを実施。

github.com

$ iostat 1
Linux 3.10.0-327.22.2.el7.x86_64 (sandbox)  2016年11月19日   _x86_64_    (1 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          23.37    0.00    7.30    0.05    2.44   66.84

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
vda               0.85         0.31         7.15    1233871   28242364

avg-cpuDevice のセットが、1秒ごとにずらずらと表示される。

が、iostat には -x オプションがあり、これを指定するとさらに詳しい情報が見られる。

$ iostat 1 -x
Linux 3.10.0-327.22.2.el7.x86_64 (sandbox)  2016年11月19日   _x86_64_    (1 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          23.37    0.00    7.30    0.05    2.44   66.85

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     0.73    0.02    0.84     0.32     7.15    17.47     0.01    7.46    4.80    7.51   1.50   0.13

avgqu-sz は平均I/Oキューサイズ。I/O待ちの平均の数、と思えばいいのかな。%util はディスクビジー率なので、この数値が100に近いほど、このディスクの性能の限界近くディスクアクセスが行われている、ということになるようだ。

7. TCPコネクションの数

netstat を用いる。これまた未インストールだったので入れる。 (ちなみに netstat が含まれている net-tools パッケージは deprecated らしいのでその点は注意が必要なのかも。)

github.com

$ netstat -an | grep ESTABLISHED | wc -l
111

111…、、想像してたのより多い印象だけど大丈夫かな。中身を少し見てみる。

$ netstat -an | grep ESTABLISHED
tcp        0      0 127.0.0.1:48346         127.0.0.1:24224         ESTABLISHED
tcp        0      0 127.0.0.1:49526         127.0.0.1:24224         ESTABLISHED
tcp        0      0 127.0.0.1:24224         127.0.0.1:49140         ESTABLISHED
...

なるほど。 24224 ポートなので、fluentd のコネクションがほとんどみたいだ(このサンドボックスサーバでは、fluentd経由でいろんなものをいろんなところに投げている)。ちなみに ESTABLISHEDTCP コネクションが確立され、通信が行われている状態のもの。

8. 現在サーバにログインしているユーザ

$ last | grep "still logged in"
a-know   pts/0        xxx.x.xx.xxx     Sun Nov 20 11:37   still logged in

last はそのホストへのログイン履歴を日時降順で表示してくれるコマンド。

ぼくは serverspec を使っているので、last だけ実行したら履歴がすごいことになっていた。w

9. サーバが起動してからの経過時間

$ uptime
 11:39:01 up 58 days, 13:41,  1 user,  load average: 0.11, 0.27, 0.34

さっきの w でも見れる情報ですな。

10.(それが Web サーバの場合、)Webサーバには何が動いているか?

$ sudo netstat -lnp | grep 80
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      2636/nginx: master
$ ps -ef | grep 2636
root      2636     1  0  9月22 ?      00:00:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx     4888  2636  0  9月24 ?      01:50:56 nginx: worker process

netstat のコマンドの方は、本では sudo なしで紹介されていたけど、僕の環境だと (Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.) と表示されたので sudo を付けた。

11.(DBと連携しているWebサーバの場合、)何のDBサーバソフトウェアと接続しているか?

僕のサンドボックス的サーバはなんのDBとの接続も行っていないので、ここにはそのコマンドだけ載せておく。

$ netstat -an | grep ESTABLISHED

使ってるコマンドとしては、さっきも使った netstat 。本には、このコマンド実行結果から 「接続している先のポート番号で判断する。例えばTCP 3306番ポートに接続している場合は MySQL と推測できる。」 としてる。うーん、結構大変な方法だなぁ。

いちおう、DBサーバごとの代表的なポート番号を調べてみた( TCPやUDPにおけるポート番号の一覧 - Wikipedia )。でもこれらは変更することができると思うので、あくまで参考ってかんじかなと。

12. メモリやハードディスクが故障していると仮定したときに、その証拠の調べ方

$ dmesg
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 3.10.0-327.22.2.el7.x86_64 (builder@kbuilder.dev.centos.org) (gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC) ) #1 SMP Thu Jun 23 17:05:11 UTC 2016
...

本でもこのコマンドがペロっと紹介されてるだけで、ハッキリいってなんのためのコマンドだがさっぱりわかんなかったので少し調べてみた。

dmesg は、カーネルのメッセージバッファーの内容を表示するコマンドらしい。なので、このコマンドで得られた出力に ERROR とか err とかっていった文字列があるかないか・あればそれはどんな内容か、を確認することで原因の切り分けができるようなもの、のようだ。

$ dmesg | grep err
[    0.000000] ACPI: IRQ0 used by override.
[    0.000000] ACPI: IRQ5 used by override.
[    0.000000] ACPI: IRQ9 used by override.
[    0.000000] ACPI: IRQ10 used by override.
[    0.000000] ACPI: IRQ11 used by override.
[    0.064011] perf_event_intel: PEBS disabled due to CPU errata, please upgrade microcode
[    0.094974] ACPI: Using IOAPIC for interrupt routing
[    0.159679] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11)
[    0.161088] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11)
[    0.162072] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11)
[    0.163124] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 10 *11)
[    0.164041] ACPI: PCI Interrupt Link [LNKS] (IRQs *9)
[    0.209087] ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11
[    0.765584] ioremap error for 0x7ffff000-0x80000000, requested 0x10, got 0x0

なるほどなー。

その他にも以下のようなコマンドにより /var/log/messages を見ることでも、メモリやハードディスク故障の証左を探すことができる可能性があるっぽい。

$ sudo more /var/log/messages
Nov 20 04:32:03 sandbox systemd: Removed slice user-0.slice.
Nov 20 04:32:03 sandbox systemd: Stopping user-0.slice.
...

でもまぁこういった「ハードウェアの故障を調べる」というの、クラウドサーバを使ってる場合はあまり縁のないもの、なんだろうか(だからといって軽視するつもりはないけど、日頃自分が直面する機会は少なさそうだなぁ、という意)。

13. サーバにはUSBメモリが接続されているか否か?

$ parted -l

partedパーティション関連の操作を行うためのコマンドらしい。-lパーティション一覧を見るためのオプション、かな? 僕のサンドボックスだと何も出てこなかったんだけど、これは大丈夫なんだろうか…。

本の中ではもうひとつ、lsusb というコマンドも紹介されていた。USBデバイスに関する情報を表示するためのコマンドなんだそうだ。特化したコマンドがあるのすごい。

14. ネットワーク機器とサーバのネットワークインタフェースは何Gbpsで接続されているか?

$ ethtool eth0 | grep Speed

これも、僕のサンドボックスでは結果が得られなかった。これもクラウドサーバだから(仮想化されているから?)、なんだろうか。

ちなみにパイプより前のコマンドだけでの実行結果は以下。

$ sudo ethtool eth0
Settings for eth0:
    Link detected: yes

おわり

これでいちおう、14の項目は全て確認してみたことになる。これらのコマンドを状況に応じて使い分けて、障害原因の切り分けをささっとできるの、かっこいい。

こうやってひとつずつ試してみて、改めて、ぼくはこれらのごく一部しか知らなかったんだなーということがわかった。もしかしたら「インフラエンジニアの教科書」(2じゃない方)も読む必要があるのかもしれない。でもまぁ今回こうして、障害時に見るポイント(それを見るためのコマンド)の一部が知れたことは、普段「サーバの監視」ということについて考えることが多い僕にとっても、とても良いことだったと思う。

インフラエンジニアの教科書2、あともう少しで読み終わるので引き続き読み進めていく。



follow us in feedly