僕はインフラエンジニアではないし、そうだったこともないのだけど、いま「インフラエンジニアの教科書２」という本を読んでいる。
- 作者: 佐野裕
- 出版社/メーカー: シーアンドアール研究所
- 発売日: 2016/08/26
- メディア: Kindle版
- この商品を含むブログを見る
Twitter かなにかでこの本の存在を知り、とりあえず買ってみたものの、しばらくの間積読状態になってしまっていた。...のだけど、最近になってようやくちまちまと読んでいる。関係ないけど、kindleで読めるのはほんとに便利だ。
この本の7章「障害対策と障害対応」で、『以下のような項目についてはサーバ障害時に即座に（20秒程度で！）収集できるべき』、とされていた。
- メモリの搭載量と使用量
- パーティションごとのディスクの使用率と空き容量
- CPUの種類とコア数
- ディスクのRAID構成
- CPU使用率
- ディスクアクセス率
- TCPコネクションの数
- 現在サーバにログインしているユーザ
- サーバが起動してからのえ経過時間
- （それが Web サーバの場合、）Webサーバには何が動いているか？
- （DBと連携しているWebサーバの場合、）何のDBサーバソフトウェアと接続しているか？
- メモリやハードディスクが故障していると仮定したときに、その証拠の調べ方
- サーバにはUSBメモリが接続されているか否か？
- ネットワーク機器とサーバのネットワークインタフェースは何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 コマンドを使うのだけど、未インストールだった。てことで、この機会にインストールを実施。
https://github.com/a-know/a-know-home-server/pull/180github.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-cpu と Device のセットが、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 らしいのでその点は注意が必要なのかも。）
https://github.com/a-know/a-know-home-server/pull/181github.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経由でいろんなものをいろんなところに投げている）。ちなみに ESTABLISHED は TCP コネクションが確立され、通信が行われている状態のもの。
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 だけ実行したら履歴がすごいことになっていた。ｗ
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 ）。でもこれらは変更することができると思うので、あくまで参考ってかんじかなと。
330654321521- Oracle database
14331434
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の項目は全て確認してみたことになる。これらのコマンドを状況に応じて使い分けて、障害原因の切り分けをささっとできるの、かっこいい。
こうやってひとつずつ試してみて、改めて、ぼくはこれらのごく一部しか知らなかったんだなーということがわかった。もしかしたら「インフラエンジニアの教科書」（２じゃない方）も読む必要があるのかもしれない。でもまぁ今回こうして、障害時に見るポイント（それを見るためのコマンド）の一部が知れたことは、普段「サーバの監視」ということについて考えることが多い僕にとっても、とても良いことだったと思う。
インフラエンジニアの教科書２、あともう少しで読み終わるので引き続き読み進めていく。
