コラム

CTC教育サービス・ホーム　＞　コラム　＞　クラウド時代のサーバー運用入門　＞　第2回　クラウド時代の障害対応術 (2) 各コマンドの使いどころ解説

クラウド時代のサーバー運用入門

CTC 教育サービス

[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes

第2回　クラウド時代の障害対応術 (2) 各コマンドの使いどころ解説 (濱田康貴) 2017年11月

本コラム第1回目、「第1回クラウド時代の障害対応術 (1) コンピューターの部品をイメージしよう」では、「厳選！障害対応お役立ちツール」として、以下のコマンドの使用頻度が高いと申し上げました。

curl df dig du fuser ip last lsof nc ping ps ss telnet top vmstat w whois

今回は、上記に挙げたコマンドの実例をいくつか紹介しますので、「そのコマンドを実行したらどうなるのか」「端末に表示された内容の意味は何なのか」を意識しながら体で覚えてください。スペースの都合上、今回のコラムで上記すべてのコマンドをご紹介することはできませんが、いくつかの回に分けて網羅していきたいと思います。今回は「リモートホストの状態確認を行う」というケースを想定してみたいと思います。

リモートホストの状態を確認するコマンドの一例

リモートホストの状態を確認するコマンドを以下の表に簡単にまとめてみました。

コマンド	使用目的 (の一例)
curl	引数にURLを渡し、対象URLの内容を出力する。オプションによっては、ヘッダのみを出力したりすることもできる。
dig	DNSサーバーに名前解決の問い合わせを行うコマンド。
nc	TCPおよびUDPの、任意のポートを対象に読み書きができる。
ping	IPネットワークにおいて、ノードの到達性を確認する。
telnet	リモートホストを手元の端末から操作できるようにする仮想端末、またはそれを可能にするプロトコルを指す。IDやパスワードも含め平文でやり取りするため、リモートホストにログインする手段としては、より安全なSSHでログインすることがほとんどであるが、引数にポート番号を与えることで、httpサーバーやSMTPサーバーへtelnetコマンドで接続して、簡単な通信テストを行うこともできる。
whois	インターネット上でのドメイン名、IPアドレス、AS番号の所有者を検索するためのプロトコルおよびそのコマンド。

単にコマンドのオプションを知りたい場合は、各コマンドのmanページを読むか、manページの日本語訳を読みたい場合は、JM Projectのサイトが役立つでしょう。しかし、コマンドのオプションを覚えることが目的では、障害発生時に結局何をしてよいのかわからなくなってしまいます。
それぞれのコマンドにはいくつか(多数、の場合もあり)のオプションがありますので、これを全部いちどに覚えるのは困難です。しかし、まず「ちゃんと動いていることが確認できた」という動作を理屈と体で覚えれば、障害対応という素早く正確な対応が求められるシチュエーションにおいても、慌てることはなくなるでしょう。

メールができない！という申告があったときの調査

例えば、あるメールサーバーを利用しているユーザーが「メールができない」とだけアラートを上げてきたとします。随分アバウトですがそんなものです。この場合、telnetやncのコマンドを使って「一体何がおきているのか」を外形監視して切り分けることも可能です。

あるメールサーバーの「hamada」から「nullpopopo」へメールを送信するのも、netcat(nc)コマンドなら一撃です。

$ nc mail.example.com 25 < MAIL FROM: hamada@example.com
> RCPT TO: nullpopopo@example.com
> DATA
> FROM: hamada@example.com
> TO: nullpopopo@example.com
> SUBJECT: testmail
> Hi, This is test mail.
> .
> QUIT
> !
220 admin.ll4u.in ESMTP Postfix
250 2.1.0 Ok
250 2.1.5 Ok
354 End data with .
250 2.0.0 Ok: queued as 3BF4C140261
221 2.0.0 Bye

反対に、nullpopopoがメールを受信できているかも、ncコマンドで確認することが可能です。

$ nc mail.example.com 110 <
(略)

telnetコマンドの場合、上記ncコマンドとは少し異なり、対話式のコマンドとして使用することがほとんどです(無理やりsleepを挟んでヒアドキュメント形式で自動化できなくもないですが、ncコマンドで実行するほうが簡単です)。

$ telnet mail.example.com 110
Trying 172.16.10.22...
Connected to mail.example.com.
Escape character is '^]'.
+OK Dovecot ready.
user nullpopopo
+OK
pass PASSWORD_IS_HERE
+OK Logged in.
list
+OK 7465 messages:
1 4009
2 1885
3 1884
4 2003
(略)
7463 106204
7464 107147
7465 2270
.
top 7465 1000
+OK
(略)
quit
+OK Logging out.
Connection closed by foreign host.

上記のように、 telnet <ホスト名> <ポート番号> のようにログインを行い、シェルがPOPサーバーのシェルに切り替わったあとは、POPサーバーのコマンドを実行します。

WEBサーバーのトラブルシュート基本のキ

さて、WEBのサービスを運用しているとよくあるトラブルが

•　そもそもWEBサーバーがダウンしているので繋がらない

•　ブラウザでリロードするたびに・・・

◦　繋がったり繋がらなかったりする

◦　違う内容のコンテンツが見えてしまう

•　一部のコンテンツだけが閲覧できない

というようなケースではないでしょうか。

しかしこれは、あくまで「目に見えておきている現象」であるか、直接ブラウザで見ていない(誰かからの申告があった)場合は、そもそも事実であるかどうかを確認する必要があります。

上記に挙げたトラブルの例だけでも、掘り下げると結構なボリュームになってしまいますので、回を改めてご紹介したいと思いますが、簡単な実行例は以下の通りです。

単純に「死活監視だけできればよい」「ヘッダ情報だけ取得できればよい」という目的でしたら、 curl -LIs で充分でしょう。

$ curl -LIs https://example.com/
HTTP/2 200 
server: nginx
date: Fri, 20 Oct 2017 11:15:03 GMT
content-type: text/html; charset=UTF-8
expires: Wed, 11 Jan 1984 05:00:00 GMT
cache-control: no-cache, must-revalidate, max-age=0
x-b-cache: BYPASS
link: ; rel="https://api.w.org/"
link: ; rel=shortlink
x-f-cache: BYPASS
x-signature: KUSANAGI

ステータスコードのみを取得したい、という場合には、コンテンツを /dev/null へ捨てつつ、 curlコマンドの出力でステータスコードのみを表示させるようにします。

$ curl -LIs https://example.com/ -o /dev/null -w '%{http_code}\n'
200

このように、必要な情報のみが出力されていれば、他のプログラムから上記の出力結果を読み込んで処理させることも楽になりそうです。例えば、監視対象URLにアクセスしてステータスコードが200でなければ管理者にメールを飛ばす、といったシェルスクリプトもこんな感じに書くことができます(連続した通知をしない、などの工夫はしていません)。

#!/bin/bash
MAILTO=root@example.com
TARGET_URI=https://example.com/
STATUSCODE=$(curl -LIs ${TARGET_URI} -o /dev/null -w '%{http_code}\n')
if [ ! 200 = ${STATUSCODE} ];
then
  echo -e "$(date)\n${TARGET_URI} is Down." | \
  mail -s "$(date) ${TARGET_URI} ALERT" ${MAILTO}
fi

WEBサーバーのステータスコードについては、rfc2616で規定されていますので、WEBサーバー異常時には「何が理由で繋がらないのか」を把握するためにも一読をおすすめします。

参考URL : https://tools.ietf.org/html/rfc2616

curlコマンドで、「-w '%{http_code}\n'」オプションをつけて実行した際にステータスコードを取得できることは先に述べましたが、そもそもWEBサーバーがダウンしている、あるいはWEBサーバーは正常動作しているにもかかわらずdnsによる名前解決ができない場合は 000 と出力されます。この場合の切り分けに役立つのが dig コマンドです。

WEBサーバーなどのように、FQDNとIPアドレスの対応づけを検索するには、digコマンドを使用します。digコマンドの引数にFQDNのみを与えて検索した場合、通常の動作としてAレコードを検索します。

$ dig wwww.example.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.4 <<>> wwww.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 47941
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;wwww.example.com.              IN      A
;; AUTHORITY SECTION:
example.com.            2779    IN      SOA     sns.dns.icann.org. noc.dns.icann.org. 2017042799 7200 3600 1209600 3600
;; Query time: 110 msec
;; SERVER: 210.188.224.10#53(210.188.224.10)
;; WHEN: Fri Oct 20 20:33:01 2017
;; MSG SIZE  rcvd: 91

上記の例は、わざと「存在しないホスト」をdigコマンドで検索した例です。wwww.example.com というAレコードはそもそも存在しないので表示されません。

次に、存在するホスト www.example.com のAレコードを検索してみましょう。

$ dig www.example.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.4 <<>> www.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11065
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.example.com.               IN      A
;; ANSWER SECTION:
www.example.com.        4611    IN      A       93.184.216.34
;; Query time: 1 msec
;; SERVER: 210.188.224.10#53(210.188.224.10)
;; WHEN: Fri Oct 20 20:43:11 2017
;; MSG SIZE  rcvd: 49

このように、Aレコードが表示されました。

コマンドだけを列挙しても少々わかりにくいかと思いますので、これまでに例示したコマンドだけで故障被疑部位特定のフローをまとめてみました。