トラブルシューティングの基本

JBoss

「JBoss徹底活用ガイド 」のために書いたボツ原稿をちょいちょいアップします。まずはトラブルシューティングの章の冒頭に書こうとしていた1節。

      • -

○トラブルシューティングの基本
まずはトラブルシューティングの基本として、以下を押さえておいてください

  • ログを読む
      • ログを読まないことには始まりません。英語が苦手でも1行や2行のメッセージは頑張って読んでください。
    • 例外クラス／例外メッセージ
      • 例外クラス名とそのメッセージで大半の障害は原因が推測できるはずです。
    • スタックトレース
      • スタックトレースのなかに自分のアプリケーションのクラス／メソッドがないか目を走らせましょう。「どこで」問題が起こったのかすぐに特定できます。またJBossやサードパーティライブラリのクラスしか見当たらなくても、クラス名／メソッド名から障害の見当をつけることができます
    • ラップされた例外
      • 例外がJBoss／アプリ内でcatchされ、別の例外にラップして再度throwされることはよくあります。ラップされた大元の原因はスタックトレース中「Caused by」に続いて出力されます。スタックトレースを見たら「Caused by」を探す習慣をつけましょう。
    • 起動時のログ
      • 正常にJBossが起動しておらず、それが原因となって副作用を引き起こすこともあります。起動時にエラーログが出ていないかどうかにも気を配りましょう
  • Webで検索
      • メッセージから原因がピンと来ない場合、まずは検索することになるでしょう
    • 検索キーワードを工夫する
      • メッセージから環境特有の単語を除いたり、スタックトレースの最上位の行のクラス・メソッドを検索キーワードに入れたりして、検索結果を絞り込みます。原因（「Caused by」）の例外を重視しましょう
    • JBoss Forumで検索する
      • JBoss Forumには大量の情報が蓄積されており、Googleにインデックス化されていないページも多数あります。http://www.jboss.org/index.html?module=bb の「Search」から検索が可能です。検索キーワードはデフォルトでOR検索になるため、「Search for all terms」を選択しましょう
  • 現象を明確にする
      • ログから手がかりになる情報が出力されていない場合、原因を絞り込むのは難しくなります。ただ、メーリングリストなどで質問するにせよ、現象を明確にしないと回答する側も困ってしまいます。どの処理では再現しない、どの環境では再現しない、などの材料を揃えます。また処理経路を追い、ログを埋め込んだり、デバッガを使ったりして、疑わしい範囲を絞っていきます。conf/jboss-log4j.xmlでログレベルを上げるという手もあります。このあたりは「こんなときどう対処すればいい？」も参考にしてください
  • 質問する
      • JBossの技術上の話題は japan-jbug-jboss@lists.sourceforge.jp で議論されています。回答の方も積極的に参加してくださいね！
      • -

なんか一般的過ぎて、入れるのを躊躇してしまいました。説教くさいですかね。新人によく言ってることもあったり。