第7回「 sosreport ノススメ」


前回は、 Bugzilla と Red Hat 社のサポートケースについて紹介しました。今回は、Red Hat 社のサポートケースを利用する際に添付することが多い sosreport について紹介します。

sosreport は、システムに問題が発生した時に、ログファイルや設定ファイルなどシステムの状態を把握するための情報を一括して取得するためのツールです。
サポートの担当者は、 sosreport コマンドを用いて取得した sosreport ファイルの内容を確認することで状況を把握し、次の行動を考えます。

sosreport を取得する上での注意点としては、以下の点が挙げられます。

  1. カーネルモジュールの自動ロード
  2. CPU使用率とディスクI/O
  3. 取得するタイミング
  4. 含まれている内容

(1) カーネルモジュールの自動ロード
sosreport コマンドを実行すると、内部で様々なコマンドが実行されます。その中には、カーネルモジュールを自動的にロードしてしまうものもあります。知らない間にカーネルモジュールがロードされていないかどうかを確認するために、sosreport コマンドの実行前後で lsmod コマンドの実行結果を比較しましょう。
(2) CPU使用率とディスクI/O
sosreport では、各種ログファイルを収集するため、 sosreport コマンドの実行中はCPU使用率の上昇と大量のディスクI/Oが観測されます。
sosreport コマンドによる負荷を軽減するために、以下の方法を組み合わせることができます。
RHEL 6 では、 chrt コマンドを用いることで、CPUの優先度を下げることができます。
---------- RHEL 6 向けコマンドライン例 ここから ----------
/usr/bin/chrt -i 0 /usr/sbin/sosreport --batch
---------- RHEL 6 向けコマンドライン例 ここまで ----------
RHEL 5 では、 nice コマンドを用いることで、CPUの優先度を下げることができます。
---------- RHEL 5 向けコマンドライン例 ここから ----------
/bin/nice -n 19 /usr/sbin/sosreport --batch
---------- RHEL 5 向けコマンドライン例 ここまで ----------
さらに、特定のプロセスに特定のCPUを割り当てて動作させているシステムの場合、taskset コマンドを用いることで sosreport 関連プロセスを特定のCPU上でのみ動作させるように制限できます。
---------- コマンドライン例 ここから ----------
/bin/taskset -c 0 /usr/sbin/sosreport --batch
---------- コマンドライン例 ここまで ----------
また、I/Oスケジューラとして CFQ を使用している場合には、 ionice コマンドを用いることで、ディスクI/Oの優先度を下げることができます。
---------- コマンドライン例 ここから ----------
/usr/bin/ionice -c 3 /usr/sbin/sosreport --batch
---------- コマンドライン例 ここまで ----------
その他、 RHEL 5 の sosreport パッケージのデフォルト設定では、全ての rpmパッケージの整合性検査を行う( /usr/bin/rpm -Va コマンドが実行される)ようになっています。整合性検査は大量のディスクI/Oを発生させるため、ディスクI/Oによる影響を軽減したい場合、 -k rpm.rpmva=off というオプションを指定することにより、一部のパッケージの整合性検査だけを行うように指定することができます。発生している問題事象が、ファイルおよびファイルシステム関連の問題ではないことが明らかな場合、以下のように -k rpm.rpmva=off というオプションを指定すると良いでしょう。
---------- コマンドライン例 ここから ----------
/usr/sbin/sosreport --batch -k rpm.rpmva=off
---------- コマンドライン例 ここまで ----------
(3) 取得するタイミング
問題事象が発生したらすぐに取得することが大切です。たまに、問題事象の発生から1週間以上経過してから故障解析を依頼してくるお客様が見受けられるのですが、その頃には事象発生時のシステムのログやリソース使用状況などの履歴が既に消滅してしまっていて、状況を確認できないということがあります。
トラブルシューティングには、平常時の状態と問題発生時の状態とを見比べて、不審な点を見つけていくという側面があります。そのため、問題事象が発生していなくても、システムの運用を開始する直前やシステム構成の変更時といった契機に sosreport を取得しておきましょう。
問題事象が発生する前に取得することには、 sosreport コマンドを実行した場合の影響の有無や程度を予め確認しておくという狙いもあります。
(4) 含まれている内容
sosreport コマンドにより生成された sosreport ファイルには、全ての情報が含まれている訳ではありません。例えば、シリアルコンソールまたは netconsole の設定を行っている状態で予期せぬ再起動やハングアップが発生した場合には、( sosreport コマンドで収集される)
/var/log/messages に記録されていないカーネルメッセージが( sosreport コマンドでは収集されない)シリアルコンソールまたは netconsole のログに記録されている可能性がありますので、 sosreportファイルと一緒に収集しておきましょう。
また、ディストリビューションに同梱されていないソフトウェア(例えば商用の死活監視ソフトやセキュリティソフトなど)のログは sosreport コマンドでは収集されないため、どのような情報が sosreport ファイルに含まれているのかを事前に確認し、足りない情報が何であるかを把握して一緒に収集しておくと、サポート担当者としてもsosreport ファイルを解析したものの手掛かりを見つけられず「原因不明です」という残念な回答をする可能性を低減できます。

(半田哲夫)

コーヒーブレーク「急いては事をし損じる」

前回の記事では、サポートセンターへの依頼の際には調整が起こらないようにすべきということを書きました。調整は、主に依頼元の注文(特別なリクエスト)がきっかけとなり始まりますから、「依頼の際には、できるだけ注文をつけないほうが良い」ということです。

しばしばいただく注文を2例紹介しますと、

「お客様に○時までに報告しなければいけない」、あるいは「○時に社内でこの件の会議があり、そこで報告しなければいけない」

「本トラブルのために商用サービスが止まっているので、一刻も早く対処しなければならない。だから、とにかく現場に技術者をよこして欲しい」

です。これらの注文を見て、あなたはどう思われますか?「うん、いかにもありそうだ。サポートセンターは困っている人を助けるべきで、もちろん対応すべきだ」でしょうか。依頼する側から見ると、そうなると思います。これらの注文をサポートセンターの中から見ると、話は少し変わってきます。最初の注文について、中の人の受け取り方というか考え方は、

「依頼の内容を見てみないと対応時間はわからない。この件の対応時間が見えたとしても、対応中の他の案件や作業もあるから、調整してみないと約束はできない」

です。2つ目については、もう少し複雑で、

「移動の時間のロスが大きい」
「現場に行ってしまうと、サポートセンターの過去の対応履歴や技術情報が使えないからできることが限られてしまう。特殊な事情がない限り、むしろ残るほうが問題解決に有効で、依頼元の役に立つことができる」 「第一報の内容だけでは何が起こっているかよくわからない。とにかく来て欲しいと言われても人選のしようがない」
「(真に必要な状況のようなので)誰か行かせたいが、今日が期限の問い合わせの状況を確認してみないとなんとも言えない」

のように考えます。これらサポートセンターの中の人の考え方について、私は「科学的であり合理的」だと思いますが、いかがでしょうか。同意いただけない方もあるかもしれませんが、こうした考え方が「あくまで問題解決を優先している」こと、および「サポートセンターは全体の依頼を意識して動いている」ことは強調しておきたいと思います。

え?「サポートセンターの中の人の考え方はわかったけれど、結局、会議の報告はどうすれば良いのか?」ですって?それについては次回説明します(それまであなたのシステムが平和でありますように!)。

(原田季栄)



第7回「 sosreport ノススメ」