今回は，トラブルシューティングにおいて適切な情報収集の重要性を具体例から考えます。トラブルシューティングでは，誤った方向を向いて対応を実施しないためにも正しく問題を定義する必要があります。正しく問題を定義するためには，簡単に言えば「事象」という形のはっきりしないものを手にしているツールを利用し，「⁠その形を明らかにすること」が必要となります。筆者の日常業務であるRHELのサポートに寄せられる実際の問い合わせを具体例に，どのような情報収集の方法が有用なのかということを紹介します。

トラシュー事例（初級編）
「XX月YY日にシステムが予期せぬ再起動をしました。原因調査をしてください」

上記のような問い合わせについて，みなさんだったらどのような仮説が考えられるでしょうか。筆者が簡単に推測できる内容でも次のような要素が考えられます。

• ハードウェア
• アプリケーション
• ユーザによる操作
• カーネルパニック

このような問い合わせ内容の場合，具体的に収集することが望ましい情報というのは，上記の要素だけでもさまざまな種類のログやコマンド結果が必要となります。また情報収集は事象が発生している最中の情報収集が最も有用ですが，今回のような事象ではそれは望めません。ですから事象発生後に確認できる情報からみていきます。

情報収集の初期段階では，メッセージ，ログは，必ず一度に網羅的に収集することを心がけてください。これは，時間が経過するにつれて消失する情報があることや，さまざまな情報を簡単に確認できることが調査を進めるうえで非常に有効であるためです。Red Hat Enterprise Linux（以下，RHEL）では，一度に幅広い情報を手軽に収集を行うことを実現するツールとしてsosreportがあります。

sosreportとは

sosreportは，RHELの基本的なコマンドの結果や，サービスのログを収集するツールです。sosパッケージにて提供されており，ツールそのものはPythonで記述され，収集する情報の種類ごとにスクリプトがわかれています。具体的なファイル構成については，「⁠rpm -ql sos」を実行し，確認してみてください。

sosreportの構造

収集したsosreportは図1のようになっています。一般的に確認することが多いディレクトリについて紹介しています。この図から，sosreportがさまざまな情報を収集することがわかると思います。

.
├── boot /boot 配下の設定ファイルを収めている
├── etc /etc 配下の設定ファイルを収めている
├── proc /proc ファイルシステム配下から収集した情報を収めている
├── root /root 配下の収集したファイルを収めている
├── sos_commands 各スクリプトで実行したコマンドの実行結果をスクリプトごとに収めている
│   ├── autofs
│   ├── bootloader
│   ├── crontab
├── sys /sys ファイルシステム配下から収集した情報を収めている
└── var /var/ 配下のログなどを収めている
     ├── crash kdumpで取得されたvmcoreのデフォルトの保存先で，vmcore-dmesg.txtを配置している
     └── log 収集した一般的なログを収めている

soreportを使って調査してみよう

取得したsosreportから，今回の事象について調査をしてみましょう。ここでは，カーネルパニックが発生したという仮説の検証を行います。以降の本稿で取り上げる実機の情報は，RHEL6.6のインストールメディアを用いて標準インストールを行い，kernelのみ2015年2月10日時点の最新へアップデートした環境において取得したものとなります。

まず，kdumpサービスが正常に起動している環境であるか確認します。サービスの自動起動設定は，「⁠sos_commands/startup/chkconfig_--list」から確認できます。図2からkdumpサービスが自動起動する設定であることがわかります。

$ cat sos_commands/startup/chkconfig_--list ¦grep kdump
kdump           0:off 1:off 2:on 3:on 4:on 5:on 6:off

次に事象が発生した日時の直前のシステムログ（messages）から，kdumpサービスが正常に起動していることを確認します。

図3から，事象発生当時のシステムでは，kdumpサービスは正常に起動していたと考えられます。kdumpサービスによって今回の事象が発生していた場合には，vmcore（システム全体のメモリイメージ）が取得されていることが期待されます。vmcoreの出力先や，kdumpの挙動については，/etc/kdump.confにて設定します。

Feb 11 11:08:12 localhost kdump: kexec: loaded kdump kernel
Feb 11 11:08:12 localhost kdump: started up

保存先を指定するpathオプションを確認すると図4から保存先は/var/crashに指定されていることがわかります。ほかのオプションについては「man 5 kdump.conf」を参照してみてください。

$ cat etc/kdump.conf ¦ grep -v ^# ¦ grep -v ^[[:space:]]*$
path /var/crash
core_collector makedumpfile -c --message-level 1 -d 31

vmcoreが保存されている場合には，その取得したホスト名と，取得日時でディレクトリが作成され，そこに，vmcoreならびにvmcoredmesg.txtというvmcoreに含まれているkernelのリングバッファを出力したものが保存されます。RHEL6.6に同梱されているsosパッケージは，/var/crash配下にvmcore-dmesg.txtがある場合には，それを収集するようにスクリプトが作られていますので，sosreport内の「var/crash/<hostname>-<取得日付>」配下のvmcoredmesg.txtの内容を確認します。vmcore-dmesg.txtはファイルの最後尾に，カーネルパニックが発生した際の内容を記録していますので，まずそちらを確認するようにしてください。今回のケースでは，リスト1のような内容が記録されています。

<0>Uhhuh. NMI received for unknown reason 30 on CPU 0.
<0>Do you have a strange power saving mode enabled?
<0>Kernel panic - not syncing: NMI: Not continuing
<4>Pid: 0, comm: swapper Not tainted 2.6.32-504.8.1.el6.x86_64 #1
<4>Call Trace:
<4> <NMI> [<ffffffff815292d6>] ? panic+0xa7/0x16f
<4> [<ffffffff8152dec9>] ? do_nmi+0x329/0x340
<4> [<ffffffff8152d620>] ? nmi+0x20/0x30
<4> [<ffffffff81040f8b>] ? native_safe_halt+0xb/0x10
<4> <<EOE>> [<ffffffff810167ad>] ? default_idle+0x4d/0xb0
<4> [<ffffffff81009fc6>] ? cpu_idle+0xb6/0x110
<4> [<ffffffff8151061a>] ? rest_init+0x7a/0x80
<4> [<ffffffff81c29f8f>] ? start_kernel+0x424/0x430
<4> [<ffffffff81c2933a>] ? x86_64_start_reservations+0x125/0x129
<4> [<ffffffff81c29453>] ? x86_64_start_kernel+0x115/0x124

この内容から，今回の予期せぬ再起動は，カーネルパニックによってkdumpサービスが動作したことによって発生したことがわかります。

今回は，情報収集の方法についてRHELに塔載されている網羅的な情報収集ツール，sosreportを利用し，そこから実際の事象についての有用な情報をさまざまな視点から確認できることを示しました。このように，1つのツールを利用することで，気軽にさまざまな視点の情報を確認できるというのはsosreportの大きなメリットです。みなさんもトラブルシューティングの初動にはぜひ，sosreportを取得してさまざまな視点から取得された情報から事象を観察してみてください。

ここからは一歩進んだ情報収集について，具体例から紹介していきたいと思います。