この章では、トレーシングを使用してエラーの解決に役立てる方法、パフォーマンス問題の解決方法、Identity Manager 内のフローを理解する方法について説明します。この章では、各種 Identity Manager コンポーネントで起こりうる問題のトラブルシューティング方法についても説明します。
この章では、次のトピックについて説明します。
Identity Manager のトレースやトラブルシューティングを始める前に、次のセクションの内容を確認しておいてください。
この章は、アプリケーションサーバーとデータベースの管理者、第一線のサポートエンジニア、および配備環境で Identity Manager の維持管理を担当しているパートナーの方を対象としています。
Identity Manager の問題をトラブルシューティングする前に、次が必要になります。
Java 5.0 (Sun Identity Manager 8.1 に必須) に使い慣れておくこと。
トラブルシューティングしようとしているコンポーネントを理解していること。
Identity Manager のトレースまたはトラブルシューティングを開始する前に、次の点にご注意ください。
トレースは、システムパフォーマンスに影響を及ぼします。最適なパフォーマンスが得られるようにするには、システムのデバッグ終了後に最小限のトレースレベルに抑えるか、トレースを無効にします。
com.waveset クラスにはトレースを有効に設定しないでください。com.waveset クラスは冗長で多数のクラスがあるため、このクラスをトレースするとサーバーがハングすることがあります。
Sun サポートから特定の指示がない限りは、Identity Manager が高度なレベルでトレースするように設定しないでください。
特定の問題をデバッグするのに Waveset.properties ファイルの exception.trace を使用する場合は、長期間使用せず、デバッグが終了したら必ず無効に設定してください。Waveset.properties ファイルの exception.trace を設定すると、システムパフォーマンスに著しい影響を及ぼします。
Sun テクニカルサポートにサポートをお問い合わせになる前に、問題の領域を絞り込むことができる次の推奨事項を試してみてください。
Web ブラウザの検索ツールで、問題を調べてみる。
リソースに固有のサポートオプションがあれば、それを使用する。リソースに関連する問題では、リソースのパッチを使用すれば解決することがあります。
適切なクライアントツールが使用できればそれを使用して、その状況から Identity Manager をアンインストールします。たとえば、Java LDAP ブラウザを使用します。
また、Sun サポートにサポートをお問い合わせになる前に、次の情報を集めて用意しておく必要があります。
Identity Manager のトレースとトラブルシューティングについては、この章で説明する内容のほかにもこのセクションに記載されているドキュメントと Web サイトをご覧ください。
Identity Manager のトレースとトラブルシューティングについては、次のドキュメントを参照してください。
XPRESS 関数の推奨トレース方法については、『Sun Identity Manager Deployment Reference』の「Testing Your Customized Form」を参照してください。
JConsole を使用して Java プラットフォームで動作するアプリケーションを監視する方法については、「JConsole を使用したアプリケーションの監視」 という記事。この記事は、次の URL から入手できます。
http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html
次の表に、Identity Manager のトラブルシューティングに関する Web サイトを説明します。
表 5–1 有用な Web サイト
次の図に示す手順に従えば、通常は使用中の配備の問題を見つけて解決することができます。
Identity Manager の各種オブジェクトとアクティビティーのトレースを有効にする方法については、「Identity Manager のオブジェクトとアクティビティーのトレース」を参照してください。
オブジェクトとアクティビティーによくある問題をトラブルシューティングする方法については、「よくある問題のトラブルシューティングと解決策」を参照してください。
トレース出力は、問題を見つけて解決する際にも、カスタムのリソースアダプタを開発する際にも非常に有用です。
ここでは、Identity Manager の各種オブジェクトとアクティビティーのトレースを有効に設定する方法について説明します。説明する内容は次のとおりです。
トレースは、システムパフォーマンスに影響を及ぼします。最適なパフォーマンスが得られるようにするには、システムのデバッグ終了後に最小限のトレースレベルに抑えるか、トレースを無効にします。
Identity Manager の中には、トレースを有効に設定できる場所が複数用意されています。次に、この手順について説明していきます。
「System Settings」ページが Product_IDMgr; のデバッグページのメイン画面になります。
このページから行える操作は、次のとおりです。
リポジトリ内のオブジェクトの表示と編集
キャッシュの消去
特殊なトレースの設定
Waveset.properties ファイルの再読み込み
Identity Manager の「System Settings」ページからトレースを有効にする手順は、次のとおりです。
ブラウザを開いて、Identity Manager 管理者インタフェースにログインします。
次の URL を入力します。
http://host port/idm/debug
各表記の意味は次のとおりです。
host は、Identity Manager の実行先ローカルサーバーです。
port は、このサーバーが監視中の TCP ポート数です。
「System Settings」ページが表示されたら「Show Trace」をクリックして、単一のトレース設定を操作します。ここから、最大 10 個までのトレース設定を作成、変更、削除できます。
これ以降の説明は、トレース設定が 1 つしかないものとして説明します。
複数のトレース設定を操作するには、代わりに「Show Trace List」ボタンをクリックしてください。「Trace Configuration」ページが表示されたら、これまでの設定を編集する設定名をクリックします。
Identity Manager には、デフォルトでグローバル設定が用意されています。しかし、Identity Manager インスタンスに複数のサーバーがある場合は、これ以外の設定を定義した方が便利かもしれません。トレース設定名と現ホスト名が重複する場合は、ホスト設定の方がグローバル設定よりも優先されます。
トレースを設定した後は、次のセクションで説明するように、デフォルトのグローバルトレース設定オブジェクトを表示して編集したり、設定オブジェクトを新規作成できます。
「Edit Trace Configuration」ページから、「Trace Enabled」ボックスをクリックしてトレースを有効にします。
このボックスの選択を解除するとトレースは終了しますが、設定はそのまま残ります。トレースしていたクラスを覚えておいて入力し直さなくても、トレースの有効と無効を切り替えられます。
トレースするクラス、パッケージ、またはメソッド名をテーブルに入力して指定します。
たとえば、次のようにします。
waveset.repository パッケージ内にあるすべてのクラスをトレースするには、com.waveset.repository と入力します。
waveset.repository パッケージ内にある AbstractDataStore クラスをトレースするには、com.waveset.repository.AbstractDataStore と入力します。
waveset パッケージ内にある AbstractDataStore クラスのリストメソッドをトレースするには、 com.waveset.repository.AbstractDataStore#list と入力します。
com.waveset クラスにはトレースを有効に設定しないでください。com.waveset クラスは冗長で多数のクラスがあるため、このクラスをトレースするとサーバーがハングすることがあります。
このテーブルの「Level」メニューから、「Method」または「Class」のトレースレベルを選択します。
次の表で説明するように、それぞれのレベルで異なる種類の情報が取り込まれます。
トレースレベル |
説明 |
---|---|
0 |
最小デバッグ出力、トレース例外、およびエラー情報のみ |
1 |
トレースレベル 0 イベント + Public メソッドのエントリと終了 |
2 |
トレースレベル 1 イベント + Public 以外のメソッドのエントリと終了 |
3 |
トレースレベル 2 + 決定点と重要変数 |
4 |
最大デバッグ出力 |
メソッド/クラスのトレースは予測できますが、場合によってはトレース出力が大量になることがあります。トレースするメソッドとクラスを指定するときは、できる限り明確に指定するようにしてください。
(オプショナル) 下位呼び出しのトレースを有効にするには、「Subcall Tracing」メニューからレベルを選択します。このメニューで使用されるトレース番号のレベルは、先の表で説明したものと同じです。
デフォルトの下位呼び出しトレースレベルは、なしです。これにより、メソッド単位またはクラス単位での下位呼び出しトレースが無効になります。
下位呼び出しトレースレベルは、先の手順で指定したメソッド/クラスのトレースレベルとは関係ありません。
下位呼び出しトレースをサポートしている特定のメソッドに「下位呼び出しトレース」を有効にすると、このメソッドから呼び出されるメソッドにはトレースレベルが自動的に設定されるようになります。下位呼び出しトレースを使用すると、指定メソッドへのエントリとメソッドの終了により終了したエントリを契機に、短くても詳細なトレース出力のバーストが生成できます。
たとえば、com.waveset.adapter.NewRes#init メソッドのトレース設定を作成した場合は、メソッド/クラスのトレースをレベル 1 に設定し、下位呼び出しトレースをレベル 3 に設定します。
さらに、init メソッドが次のもう 2 つのメソッドを呼び出すとします。
NewRes#subcallA
NewRes#subcallB
init メソッドが実行されると、com.waveset.adapter.NewRes#init メソッドは、 subcallA に達するまで、レベル 1 でトレース出力を生成します。subcallA の実行が開始されると、トレースレベルが 3 に変わり、subcallA が終了するまでこのレベルが継続されます。com.waveset.adapter.NewRes#init メソッドが init メソッドに戻り、トレースレベルを 1 に戻します。その後、init が subcallB を呼び出すと、subcallB が存在する限り、別のバーストのトレースレベル 3 の詳細が続きます。最後に、init が存在すれば、トレースレベル 1 が終了します。
トレース結果を指定ファイルの場所に送信するか、stdout に送信します。
ファイルへの出力を選択すると、「Trace File」フィールドが表示されます。このフィールドから、別の場所を指定したり、トレース出力ファイルのファイル名を指定します。デフォルトの出力場所とファイル名は、次のとおりです。
path_to_idm_install\export\pipeline\config\WSTrace.log |
格納する最大トレースファイル数を指定します (デフォルトは 2)。
各ファイルの最大サイズを指定します (デフォルトは 512K)。
トレース出力ファイルを生成時に書き込むか (同期的)、そのデータをキューに入れておいてからトレースファイルに書き込むか (非同期的) を指定します。
変更を保存します。
トレース設定オブジェクトを新規作成するには、次の項目を実行します。
トレース対象とするパッケージまたはメソッドを決定します。
通常は、リソースアダプタ名を指定するか、エラーメッセージに表示された情報を使用します。
Identity Manager 管理者インタフェースにログインし、「System Settings」ページからトレースを有効にするに説明したとおりに「System Settings」ページを開きます。
「System Settings」ページで、「Show Trace List」をクリックします。
Identity Manager の「Trace Configuration」ページが表示されたら、「New」をクリックします。
「Edit Trace Configuration」ページから、トレースを有効にします。
「Trace Configuration」メニューから、次のオプションのいずれかを選択します。
「Global」。すべてのサーバーのトレースを有効にするように選択します。
サーバー名。サーバー名を選択して、特定のサーバーのトレースを有効にします。
「Trace Enabled」ボックスを選択して、このオブジェクトのトレースを有効にし、デフォルトの設定オブジェクトを編集するに説明したとおりにこのページの残りのパラメータを設定します。
変更を保存します。
ここでは、Identity Manager のデバッグページからトレースを有効にする方法について説明します。
ブラウザを開いて、Identity Manager 管理者インタフェースにログインします。
次の URL を入力します。
http:// host:port /idm/debug/ pageName.jsp
各表記の意味は次のとおりです。
host は、Identity Manager の実行先ローカルサーバーです。
port は、このサーバーが監視中の TCP ポート数です。
pageName.jsp は、開こうとしている個々のデバッグページです。
たとえば、カスタムアダプタにアダプタクラスとメソッドをトレースするには、次の URL を入力して「Edit Trace Configuration」ページを開きます。
http://host : port/idm/debug/Show_Trace.jsp
ここでは、Identity Manager コンソールからトレースを有効にする方法について説明します。
$WSHOME を設定します。
たとえば、この変数をデフォルトのインストールディレクトリに設定するには、次のように指定します。
set WSHOME=C:\Program Files\tomcat\webapps\idm |
Identity Manager コンソールを bin ディレクトリから開くには、lh console と入力します。
コンソールから、trace と入力して、enable や disable など使用可能なトレースオプションの詳細なまとめを表示します。
このコマンドの構文は次のとおりです。
trace [ -s server ] $subcommand
デフォルトでは、Identity Manager はトレース情報を WSTrace#.log というファイルに送信します。これは path_to_idm_install\export\pipeline\config\ ディレクトリにあります。必要ならば、オブジェクトのトレースを設定する際に別のファイル名と場所を指定することもできます。
それぞれのログファイルは、「Edit Trace Configuration」ページで指定した最大ファイル数まで連続して番号が付けられます。たとえば、最大ファイル数を 3 に指定した場合は、ファイルには WSTrace1.log、WSTrace2.log、および WSTrace3.log が付けられます。
これらのログファイルを表示するには、次のいずれかの方法を使用します。
トレース情報をファイルに送信する場合は、指定した場所からそのトレースファイルを開きます。例を示します。
path_to_idm_install \export\pipeline\config\WSTrace2.log |
トレース情報を stdout に送信する場合は、使用しているアプリケーションサーバーの stdout ファイルをテキストエディタで開いて、トレース出力ログを表示します。
Identity Manager は、Java ベースの製品です。この実行可能ファイルは、パッケージとしてグループ化されている Java クラスから構成されています。コードを実装すると、多くのクラスでトレースを出力できるようになります。
Identity Manager サーバーをトレースすると、サーバーの障害箇所、問題のある箇所、実行していない箇所などの有用な情報が入手できます。Identity Manager を実行中のサーバーでパッケージレベルとメソッドレベルのトレースを有効にするには、Identity Manager のデバッグページを使用します。
Sun サポートから指示がない限りは、Identity Manager がこの高度なレベルでトレースするように設定しないでください。
トレース情報を使用すると、リソースアダプタが起動していることを確認し、すべての設定の変更内容が保存されていることを確認し、アダプタの問題を診断することができます。
ここでは、アダプタのトレース設定に役立つ内容について説明します。このセクションは、次のトピックから構成されています。
アダプタのトレースを有効に設定するには、次を入力してトレース対象とするメソッドを特定する必要があります。
com.waveset.adapter.sample.MyResourceAdapter |
また、アダプタがリソース設定をログファイルに書き込めるように、使用中のカスタムリソースアダプタに新メソッドがあれば、呼び出しを指定してログエントリを作成する必要があります。
場合によっては、リソースインスタンスにさらに次のようなログパラメータを指定することもできます。
ログアーカイブの最大数
アクティブログの最大有効期間
ログファイルパス
ログファイルの最大サイズ
ログレベル
さらに同期プロセスをデバッグするには、ActiveSync アダプタに同期ログを設定してください。この手順は、Identity Manager のオンラインヘルプで説明しています。
カスタム Java コードのトレースは、お客様独自のリソースアダプタを書き込む際に有用です。詳細は、「カスタムコードのトレース」を参照してください。
問題をより効率的に評価して解決するには、トレースポイントがあるコードを測定します。詳細は、「トレースポイントがあるコードの計測」を参照してください。
特定のアダプタメソッドをトレースする方法の詳細は、『Sun Identity Manager 8.1 リソースリファレンス』を参照してください。
Identity Manager は、トレース機能を使用すると、アダプタコンポーネント (リソースアダプタ) でアダプタのトレースポイントがあるコードを計測できるようになります。ここでは、トレースポイントを使用し続けてアダプタ問題を評価し、解決に役立つガイドラインをいくつか説明します。
トレースポイントがあるコードを測定するためのガイドラインの方針は、次のとおりです。
関連情報を表示して、本稼働環境と開発環境の両方で、トレースポイントをトラブルシューティングにできる限り役立つようにする。
重要なメソッドごとに、1 つのエントリポイントと 1 つの終了ポイント、または例外トレースポイントを作成する。
通常の処理中、および次の操作によってトレースが有効になっているときに、トレースポイントをできる限り効果的に活用する。
トレースレベルのチェック数を最小限におさえる。
トレースが有効に設定されているときにオブジェクトの作成を最小限に抑える。
表示する情報量を制御するには、トレースポイントのトレースレベルを指定します。次の表は、com.sun.idm.logging.TraceManager インタフェースで定義される各トレースレベルを説明したものです。
表 5–2 定義されているトレースレベル
トレースレベル |
トレース変数 |
使用状況 |
---|---|---|
1 |
Trace.LEVEL1 |
リソースアダプタインタフェースの Public メソッドのエントリポイントと終了ポイント |
2 |
Trace.LEVEL2 |
Public メソッド以外または Identity Manager コンポーネント外部インタフェースに含まれているメソッドのメソッドのエントリポイントと終了ポイント |
3 |
Trace.LEVEL3 |
決定点または重要変数 |
4 |
Trace.LEVEL4 |
ループ内の重要変数など、極めて詳細な情報 |
n/a |
Trace.ALWAYS |
トレースレベルのチェックを行わない 注意: このオプションは、すでにトレースレベルを条件に指定している場合に使用してください。 |
循環的に依存しないようにするには、com.sun.idm.logging.TraceManager インタフェースを実装する com.sun.idm.logging パッケージに、com.sun.idm.logging.Trace クラスを使用します。
トレースポイントをコードに追加するときは、次の点に注意してください。
メソッドへのトレース引数、およびメソッドからの戻り値。
引数が「print large」の場合、テキスト表現が短くなければ、そのオブジェクトを null かどか指定してください。引数または戻り値が配列かリストで、その値の印刷が大きい場合は、配列サイズかリストサイズを指定すれば十分です。null 値を避けるには、com.waveset.util.Util.length() ユーティリティーメソッドが使用できます。
トレース情報をフォーマットするか有意義にトレース情報を与えるオブジェクトを作成するには、指定トレースレベルが有効にならない限り Identity Manager がトレースポイントデータを整列化しないように、Trace.getLevel メソッドと isLogging(level) メソッドを使用してトレース文の周りに if 文を配備します。
この構文を使用するときは、条件内のトレースポイントに Trace.ALWAYS トレースレベルを指定してください。条件内でチェックがすでに行われていれば、このトレースレベルがトレースレベルに不要なチェックを防いでくれます。
obj.getName() などの印刷可能表現を取得するのにメソッドの呼び出しを必要とするオブジェクト値をトレースする場合は、トレースが有効になった場合に NullPointerException が発生しないように null オブジェクトを避けてください。
通常は、単純な getter や setter メソッドなどの簡易メソッドにトレースポイントを使用しないでください。
WSUser オブジェクトをトレースするときは、 toString() メソッドを getName() メソッドの代わりに使用して、オブジェクトの値を表示します。toString()) メソッドの方が、getName() よりも堅牢性があり、有用な情報を印刷します。user.getName() のトレースの代わりに、toString() を暗黙に呼び出す user をトレースしてください。
メソッドまたはコンストラクタが単なるラッパーの場合、つまりメソッドまたはコンストラクタが別のメソッドやコンストラクタを、同名だが異なる署名で呼び出すだけでまったく重要でない場合は、トレースポイントを行き先メソッドやコンスタラクタに直接配備します。
パフォーマンスが不可欠で、そのメソッドが何度も呼び出される場合は、エラーを示すように情報トレースポイントを使用します。そのメソッドには、エントリや終了トレースポイントを付けないでください。このオプションは慎重に使用してください。
トレースポイントを付ける前に、フィールドの問題を見つけるのにそのトレースポイントから有用な情報が得られるかどうか確認してください。
次のセクションでは、各トレースレベルをより詳細に説明していき、コードでのトレースポイントの使用例を紹介していきます。
使用するコードにエントリおよび終了トレースポイントを追加する前に、これらのガイドラインをお読みください。
すべての Identity Manager コンポーネントの外部インタフェースメソッドには、リソースアダプタインタフェースで宣言されている public メソッドの Trace.Level1 エントリまたは終了トレースポイントを使用します。
コンストラクタや静的メソッドや Identity Manager コンポーネントの外部インタフェースに含まれていないメソッドなど、重要な public メソッド以外には、Trace.Level2 エントリまたは終了トレースポイントを使用します。
トレースポイントの中に引数を指定します。
その引数が基本型または java.lang.String でなく、各種オブジェクトの作成やメソッドの呼び出しを必要とする引数の場合は、エントリトレースポイントを条件付きにして、トレースが有効な場合のみフォーマット処理が行われるようにします。
終了トレースポイントを指定する際には、そのメソッドが基本型か java.lang.String の場合、戻り値を表示してください。戻り値に何らかのフォーマットが必要な場合は、このガイドラインに説明したとおりにオブジェクトのフォーマットを条件付きにしてください。以下を使用します。
int getLevel() int getLevel (Method) boolean isLogging(level,method) boolean level1 (method) boolean level2 (method) boolean level31 (method) boolean level4 (method) |
複数の java.lang.String を一緒に付与する必要がある情報をトレースする場合は、java.lang.String の代わりに java.lang.StringBuffer を使用します。java.lang.StringBuffer を使用するよりも、付与した方が早く済みます。また、前述の箇条書き項目のとおりに条件付きにしてください。
重要なコンストラクタにエントリまたは終了トレースポイントを追加する際は、コンストラクタ内の this() や super() メソッド呼び出しの前にトレースポイントを配備することはできません。this() や super() メソッド呼び出しの直後に、エントリトレースポイントを配備してください。
例外条件をトレースするには、終了トレースポイントを使用しないでください。メソッドが例外をスローする場合は、例外がスローされる直前に、エントリまたは終了トレースポイントと同じトレースレベルで、例外トレースポイントを使用します。詳細は、「例外トレースポイントの使用方法」を参照してください。
メソッドにエントリトレースポイントが含まれている場合は、そのメソッドに throwing メソッド、caught メソッド、または終了のいずれかを実行するコードパスも含めてください。
次に、簡易エントリと終了トレース文の例を示します。この例では、次の CLASS 変数が各文に宣言されているものとします。
private static final String CLASS = "com.waveset.adapter.MyResourceAdapter"; protected static Trace _trace = Trace.getTrace();
final String METHOD = methodName; _trace.entry(_trace.LEVEL1, CLASS, METHOD); _trace.entry(_trace.LEVEL1, CLASS, METHOD, user); if (_trace.level1(CLASS, METHOD)) { _trace.entry(_trace.ALWAYS, CLASS, METHOD, user= + user); } // Show the size of an array argument // ASSUME: password is an argument to the method // Note the use of the Util.length() method. It is // a convenience method that guards against null. if (_trace.level1(CLASS, METHOD)) { StringBuffer sb = new StringBuffer(32); sb.append(password length=); ab.append(Util.length(password)); _trace.entry(_trace.ALWAYS, CLASS, METHOD, sb.toString()); }
_trace.exit(_trace.LEVEL1, CLASS, METHOD); _trace.exit(_trace.LEVEL1, CLASS, METHOD, returnValue); if (_trace.level1(CLASS, METHOD)) { _trace.exit(_trace.ALWAYS, CLASS, METHOD, returnValue != null ? returnValue.getName() : returnValue); } // Show the size of an array String[] accounts = ... if (_trace.level1(CLASS, METHOD)) { StringBuffer sb = new StringBuffer(32) sb.append(accounts length=); ab.append(accounts.length); _trace.exit(_trace.ALWAYS, CLASS, METHOD, sb.toString()); }
使用するコードに情報トレースポイントを追加する前に、これらのガイドラインをお読みください。
情報データトレースポイント、変数データトレースポイント、およびデータトレースポイントには通常、Trace.Level3 または Trace.Level4 を使用します。トレースレベルは、表示された情報の重要度、工数および詳細度によって決まります。
重要な条件、分岐、コードパスで発生する情報などをトレースするには、Trace.Level3 と Trace.Level4 の情報と変数トレースポイントを使用します。
変数トレースポイントは情報トレースポイントと同様に便利なメソッドですが、変数トレースポイントが引数値をプリントするだけでなく variable=<variable> をプリントアウトします。さらにこのメソッドは、引数に指定したトレースレベルが一致しない限りは情報をフォーマットしません。
メソッドに例外条件があってもその例外を再スローしない場合は、情報トレースポイントを使用しないでください。caught メソッドを使用してください。たとえば、「例外トレースポイントの使用方法」を参照してください。
バイト配列で情報を表示するには、Trace.Level3 と Trace.Level4 データトレースポイントを使用します。その情報がそのトレースレベルに合っており短い場合は、下位のトレースレベルを使用してもかまいません。
重要だが短い情報をトレースするには、Trace.Level1 と Trace.Level2 情報トレースポイント、変数トレースポイント、およびデータトレースポイントが使用できます。ただし、このレベルのトレースポイントはほとんど使用しないでください。
次に、簡易情報トレース文の例を示します。この例では、次の CLASS 変数が宣言されているものとします。
private static final String CLASS = "com.waveset.adapter.MyResourceAdapter"; protected static Trace _trace = Trace.getTrace();
_trace.info(_trace.LEVEL3, CLASS, METHOD, Some Message); WavesetResult result = new WavesetResult(); try { someMethod(); } catch(Exception e) { String msg = Some Error Message; WavesetException we = new Waveset(msg, e); _trace.caught(_trace.LEVEL3, CLASS, METHOD, e); result.addException(we); }
使用するコードに例外トレースポイントを追加する前に、これらのガイドラインをお読みください。
エントリまたは終了トレースポイントが指定されているすべてのメソッドにトレースポイントを使用します。また、例外を取得して再スローするメソッドにトレースポイントを使用します。Identity Manager は、新しい例外が元の例外をラップしている例外をスローすることがあります。エントリと終了トレースポイントで使用しているものと同じトレースレベルを使用してください。
現メソッドから例外が作成されてスローされる場合は、例外トレースポイントを使用します。
例外が取得されて処理される場合は、例外トレースポイント caught メソッドを使用します。たとえば、現メソッドから例外がスローされない場合などです。この状況は、Identity Manager が例外を取得して処理する際、後から調査しようと WavesetResult などのコンテナにそれを配備したときによく起こります。
現メソッドからスローされた例外が、java.lang.RuntimeException または java.lang.Error を拡張する例外の checked 例外でなければ、ほかの措置が講じられるまでこのメソッドの終了ポイントはトレースされません。この状況で例外トレースポイントを設定するには、try/catch ブロックをそのメソッドの重大域の周りに使用して、発生する例外を再スローする方法があります。つまり、メソッドが成功したか失敗したかを調べることが欠かせないときは、通常 Trace.Level3 以上の使用が必要になります。
次に、簡易例外トレース文の例を示します。この例では、次の CLASS 変数が宣言されているものとします。
private static final String CLASS = "com.waveset.adapter.MyResourceAdapter"; protected static Trace _trace = Trace.getTrace();
try { someMethod(); } catch(Exception e) { _trace.throwing(_trace.ALWAYS, CLASS, METHOD, e); throw e; } try { someMethod(); } catch(Exception e) { _trace.throwing(_trace.ALWAYS, CLASS, METHOD, e); WavesetException we = new WavesetException(Some Message, e); throw we; } if (error) { WavesetException e = new WavesetException(Some Error Message.; _trace.throwing(_trace.LEVEL3, CLASS, METHOD, e); throw e; } try { someMethod(); } catch(Exception e) { _trace.caught(_trace.LEVEL1, CLASS, METHOD, e); } // execution continues. someOtherMethod();
トレースポイントのテンプレートを使用すると、Identity Manager リソースアダプタに一貫した有用なトレースポイントを作成できるようになります。Identity Manager には、次の場所に Eclipse テンプレートが用意されています。
src/wps/doc/eclipse-trace-templates.xml
これらのテンプレートを Eclipse にインポートするには、「ウィンドウ」>「環境設定」>「Java」>「エディタ」>「テンプレート」の順に選択します。
Emacs または IDEA を使用している場合は、同様のテンプレートが作成できます。
ここでは、次を含む補足的なトレースガイドラインを説明します。
重要メソッドは内部クラスでトレースしてください。内部クラスに何かトレースメソッドがある場合は、最終的に静的な CLASS 変数を必ず宣言してください。
private final static String CLASS = com.waveset.adapter.SomeResourceAdapter$AdapterInnerClass;
通常は、静的初期化子にトレース機能を使用しないでください。Identity Manager は、リポジトリが初期化されたとき起こるクラスのロード時にこの初期化子を実行します。静的初期化子で重要なものをトレースするには、Debug クラスを使用します。
Identity Auditor を使用すると、次のメソッドをトレースして問題をトラブルシューティングできます。
com.sun.idm.auditor.policy - Audit Scan の問題をトレースします。
com.sun.idm.auditor.accessreview - Access Reviews の問題をトレースします。
com.sun.idm.auditor.report - Audit Reports の問題をトレースします。
com.sun.idm.auditor.view - Auditor Views の問題をトレースします。
ブラウザを開き、管理者インタフェースにログインします。
「設定」>「サーバー」の順に選択します。
「サーバー設定」ページが表示されたら、「サーバー」列からサーバー名をクリックしてその設定を編集します。
「サーバー設定の編集」ページで、「スケジューラ」タブをクリックします。
スケジューラのデバッグトレースを起動してその結果を stdout に書き込むには、「トレースの有効化」ボックスを選択します。
変更を保存します。
使用中の配備をトラブルシューティングする際にシームレス統合を実現するには、カスタム記述コードに Identity Manager のトレース機能を使用します。
このトレース機能を使用するには、次のクラスを使用します。
トレースの下位システムとを接続するには、com.sun.idm.logging.trace.Trace オブジェクトを使用します。
これらのオブジェクトのファクトリには、com.sun.idm.logging.trace.TraceManager を使用します。
この com.sun.idm.logging.trace 機能は、トレース出力の記録にも使用できます。この機能とクラスの詳細は、JavadocTM を参照してください。
この com.sun.idm.logging.trace 機能は、Identity Manager Version 6.0 SP1 リリース以前には搭載されておりません。これ以前の Identity Manager には、代わりに com.waveset.util.Trace クラスを使用してください。
例外ログは、Identity Manager の「デバッグ」ページまたは config/Waveset.properties ファイルから表示できる静的トレースです。トレースデータには、デフォルトですべての例外が含まれていませんが、例外ログは重要で有益なトラブルシューティングツールになります。
例外ログを有効にするには、次のうちいずれかのメソッドを使用します。
Identity Manager の管理者インタフェースから「Waveset プロパティー」ページ (debug/Show_WSProp.jsp) を開きます。exception.trace キーを見つけて、値を true に変更します。
config/Waveset.properties ファイルをテキストエディタで開いて、exception.trace キー値を true に変更します。次の図は、例外トレースの一例を示したものです。
Identity Manager は、アプリケーションサーバーのコンソールになることが多い Web アプリケーションインスタンスにある例外ログを stdout に送信します。
完了したら、アプリケーションサーバーログに不要に出力されないよう、例外ログを無効にします。例外ログを無効にするには、 exception.trace キー値を false に戻します。
トレースを有効にすると、フォームフィールド内の編集済みフォームをトラブルシューティングし式文エラーをチェックできます。
トレースを有効にするには、次のうちいずれかの方法を使用します。
Identity Manager の管理者インタフェースから「Waveset Properties」ページ (debug/Show_WSProp.jsp) を開きます。form.trace キーを見つけて、値を true に変更します。
config/Waveset.properties ファイルをテキストエディタで開いて、form.trace キー値を true に変更します。
Identity Manager は、フォームの式構文に問題があれば標準の出力にレポートします。
form.trace キーはデフォルトで無効になっています。これは、「アカウントリスト」などの各ページの各フィールドにトレース情報を生成するのでシステムパフォーマンスに影響を及ぼすためです。メソッドをトレーシングするフォームとフィールドには、より対象に近いものを使用するようにしてください。
フォームのトラブルシューティングが完了したら、 form.trace キー値を false に変更し直してトレースを無効にしてください。
フォームとフォームのプロセスを開発したり更新している最中には、グローバル XPRESS のトレースも有用です。グローバル XPRESS のトレースは、システムパフォーマンスに影響するほど大量の出力が生成されますが、このトレース方法は XPRESS 出力を表示して、フォームのどこに問題が発生しているかがわかることがあります。
詳細は、次を参照してください。
通常はお勧めしていませんが、コードがどこにあっても XPRESS コードをトレースするには、グローバル XPRESS トレースが使用できます。たとえば、フォーム、ビュー、およびワークフロー内で XPRESS コードがトレースできます。結果のトレースには、潜在的な問題がわかる XPRESS 出力が表示されます。
XPRESS のトレースはシステムパフォーマンスに影響するほど大量の出力が生成されるため、デフォルトで無効に設定されています。
XPRESS 関数のトレースの詳細は、『Sun Identity Manager Deployment Reference』の「Testing Your Customized Form」を参照してください。
コマンドウィンドウを開きます。
Identity Manager のデフォルトのインストール先ディレクトリにある config/Waveset.properties にディレクトリ移動します。
config/Waveset.properties ファイルを開き、xpress.trace 行を次のように編集します。
xpress.trace=true |
Waveset.properties ファイルを保存します。
アプリケーションサーバーを再起動するか、Waveset.properties ファイルを Identity Manager のデバッグページから再読み込みします。
次の行を Waveset.properties ファイルに追加して、XPRESS トレース出力をファイルにコピーします。
xpress.traceFile=FileName.txt |
xpress.traceFileOnly=true |
Waveset.properties に xpress.traceFileOnly=true を設定すると、xpress.traceFile に指定したファイルの中に、すべての XPRESS 文の評価によってトレースメッセージが生成されます。それ以外の場合は、 xpress.traceFile に値があれば、トレースメッセージがコンソールとファイルの両方に出力先が変更されます。
ここでは、PasswordSync のトレースを有効にする方法と、Direct アクセスまたは JMS モードでトレースを設定する方法について説明します。
Identity Manager の PasswordSync 機能のトレースを設定するには、次の方法があります。
ここでは、PasswordSync 設定ツールの「Trace」タブからトレースを設定する方法について説明します。
PasswordSync のインストール方法と設定方法の詳細は、『Sun Identity Manager 8.1 ビジネス管理者ガイド』の第 11 章「PasswordSync」を参照してください。
この設定ツールを初めて実行したときは、ウィザードでトレースを設定できません。それ以降は、設定ツールを実行するとウィザードに「Trace」タブが設定され、ここからトレースを設定できるようになります。
次の図は、PasswordSync 設定ツールの「Trace」タブを表したものです。
このタブから指定できる操作は、次のとおりです。
PasswordSync がトレースログの書き込み時に表示する詳細レベルを指定するには、「Trace Level」フィールドを使用します。 0 の値はトレースを無効にし、4 の値は全詳細を表示します。
ログファイルの最大サイズを指定するには、「Max File Size」フィールドを使用します。
トレースファイルが「Max File Size (MB)」フィールドに指定したサイズを超えると、PasswordSync が新しいトレースファイルを開始して、古い方のトレースファイル名に .bk を付与します。たとえばトレースレベルが 100 M バイトに設定されている場合、トレースファイルは C:\logs\pwicsvc.log に書き込まれますが、このトレースファイルのサイズが 100 M バイトを超えると PasswordSync がファイル名を C:\logs\pwicsvc.log.bk に変更します。すると PasswordSync が新しい C:\logs\pwicsvc.log ファイル を作成して、ここに新しいトレースファイルのメッセージが書き込まれるようになります。
PasswordSync トレースファイルの場所を指定するには、「Trace File」フィールドを使用します。
別の PasswordSync 設定を有効にするには、PasswordSync 設定ツールを使用して次の PasswordSync レジストリキーを編集します。
PasswordSync レジストリキーを編集するには、PasswordSync 設定ツールを使用するのが一番安全な方法です。これらのキーを直接 Windows レジストリで編集することはお勧めしません。
キー名 |
種類 |
説明 |
---|---|---|
dumpFilebase |
REG_SZ |
PasswordSync DLL が例外を表示する場合は、Windows がダンプファイルを生成できるようにこのレジストリキーを設定します。 メモリーダンプの書き込み先となる、省略されていないディレクトリパスに、このレジストリキーを設定する必要があります。例: c:\temp パスワード処理中に Identity Manager が例外を取得するたびにメモリーダンプを書き込むには、このレジストリキーを設定します。 注意: Windows 2000 サーバー (全サービスパック) では、Microsoft から入手できる設定ディレクトリ DbgHelp.dll もインストールする必要があります。DbgHelp.dll ファイルの最低リリースバージョンは、Version 5.1 です。DbgHelp.dll ファイルは次からダウンロードしてください。 http://www.microsoft.com/whdc/DevTools/Debugging/default.mspx DbgHelp.dll がインストールされていなければ、Windows 2000 にはダンプファイルが生成されません。 ダンプファイル名の形式は、次のとおりです。 lhpwic-YYYYMMDD-HHmm-xxxxx.dmp この名前の YYYYMMDD はダンプ日、HHmm はダンプ時刻 (24 時間制)、xxxxx は、アプリケーションのスレッド番号になります。 ダンプファイルは手動で削除する必要があります。ダンプファイルのサイズは、Windows の Local Security Authority Subsystem (LSASS) プロセスのサイズに応じて変わりますが、20 M バイトから 100 M バイト以上です。このダンプファイルを削除しないと、時間が経つにつれて、ディスク空き容量の限られたシステムがいっぱいになります。 |
installdir |
REG_SZ |
PasswordSync アプリケーションのインストール先ディレクトリ |
PasswordSync レジストリキーは、次の場所にあります。
HKEY_LOCAL_MACHINE\SOFTWARE\Waveset\Lighthouse\PasswordSync
ほかのキーは、この場所にあります。
直接アクセスモードを使用していても JMS モードの設定を使用していても、PasswordSync のトレースログは変わりません。ただし、これらのトレースログには、部分情報しか表示されません。各設定にサーバー側にログを収集するには、次のセクションで説明するとおりにそれぞれのクラスを設定する必要があります。
直接アクセスモードで PasswordSync を使用すると、トレースログにはエラーが表示されますが、ログの中のすべてのエラーが実際のエラーとは限りません。たとえば、場合によってはビューのチェックインに時間が掛かりすぎてログにエラーが表示されることもあります。この情報を表示するには、サーバー側でトレースする必要があります。
直接モードでは、チェック対象のビューをリポジトリに生成するサーブレットと PasswordSync が通信します。パスワードの変更内容の受信から、サーブレットに生成され返されたものの応答まで、すべてのパスワード同期段階を表示するには、com.waveset.rpc.GenericMessageHandler をクラスレベル 4 でトレースします。レベル 4 は、トラブルシューティングに十分な詳細情報を提供できる唯一のレベルです。
JMS モード設定で PasswordSync を使用すると、ログには送信が成功したか失敗したかの情報しか JMS サーバーに表示されません。この点で、サーバー側のログの方を頼る必要があります。JMS トレースの方が、多少複雑です。
PasswordSync dll を JMS メッセージに生成したメッセージを変換し、そのメッセージを JMS キューに追加するには、com.waveset.rpc.PasswordSyncHandler クラスをレベル 4 でトレースします。このクラスではトレースの制限が可能で、トラブルシューティングに役立つ十分な情報を提供できるのはレベル 4 だけです。
PasswordSync が正常に JMS メッセージを JMS キューに送信した場合は、トレースを見ても問題の原因が見つからないでしょう。次に、最終手段として JMS アダプタをトレースします。この手順については、『Sun Identity Manager 8.1 リソースリファレンス』を参照してください。
ルール駆動型メンバーのキャッシュをトレースしてその結果を基に、Waveset.properties のキャッシュプロパティーをチューニングできます。
com.waveset.server.RuleDrivenMembersCache をレベル 1 でトレースする場合は、結果の情報に追加数、削除数、キャッシュヒット数などが記載されます。この情報を基にキャッシュサイズを評価して、Waveset.properties のキャッシュプロパティーをチューニングする必要があるかどうかを判断します。
ルール駆動型メンバーのキャッシュを制御するには、Waveset.properties の次のプロパティーを使用します。
サブジェクト単位でキャッシュされる最大オブジェクトリスト数を指定するには、ruledrivenmemberslistcache.size = 値を使用します。(デフォルトは 20 です。)
サブジェクト単位でキャッシュされる最大オブジェクト総数を指定するには、ruledrivenmemberslistcache.rowlimit = 値を使用します。(デフォルトは 100000 です。)
デフォルトでは Identity Manager が、指定の組織に関連付けられているユーザーメンバールールを評価し、ユーザーの動的リストがあるユーザーメンバーリストのキャッシュを作成します。ただし、所定サブジェクトの指定ユーザー組に動的メンバー組織があるユーザーメンバーリストのキャッシュも作成できます。このキャッシュのキーは、オブジェクト ID で連結されたオブジェクト型です。たとえば、User#ID#Configurator オブジェクト ID と連結された User オブジェクト型です。それぞれキーとなる値は、このオブジェクトが動的メンバーとなるオブジェクトグループのリストです。
評価対象のオブジェクトが動的メンバーかどうかを判定するには、リストキャッシュで使用されるものと同じ組織単位のユーザーメンバールールをキャッシュが評価します。そのオブジェクトが動的メンバーであれば、Identity Manager がそのオブジェクトをリストに追加してからリストをキャッシュします。Identity Manager は、キャッシュのヒット率が最高になるよう、空と非空の両方のリストをキャッシュします。
このキャッシュには、Waveset.properties の次のプロパティーを使用して、パフォーマンスに影響する必要メモリーを制御します。
サブジェクト単位でキャッシュされるメンバーオブジェクトグループリスト数を指定するには、ruledrivenmembersobjectcache.size = 値を使用します。デフォルト値は 100 です。
サブジェクト単位でキャッシュされる最大メンバーオブジェクトグループ総数を指定するには、ruledrivenmembersobjectcache.rowlimit = 値 を使用します。デフォルト値は 100000 です。
Identity Manager がメソッド/クラス レベル 2 でトレースできるように有効に設定すると、Identity Manager Service Provider (サービスプロバイダ) ユーザーをリストするかアクセスしたとき、および サービスプロバイダ ユーザーがログインしたときに AdminRoles が動的に割り当てられていると認証フローがトレースできるようになります。
サービスプロバイダ ユーザーを検索するときは com.sun.idm.idmx.view.IDMXBrowseViewer をトレースします。
サービスプロバイダ ユーザーを作成、編集、または削除するときは com.sun.idm.idmx.view.IDMXUserViewer をトレースします。
上記クラスの両方を使用するときは com.sun.idm.idmx.api.IDMXServerUtils をトレースします。
サービスプロバイダ ユーザーとしてログインしているときは、com.waveset.security.authn.WSSPELoginModule をトレースします。
Identity Manager のデバッグページから サービスプロバイダ がトレースするように設定します。手順については、「Identity Manager サーバーのトレース」を必要に応じて参照してください。
調整タスクに問題がある場合は、com.waveset.task.Reconciler に標準のトレース機能を使用して、調整サーバーをトレースします。
トレースを有効にするには、次のうちいずれかの方法を使用します。
Identity Manager の管理者インタフェースから「Waveset Properties」ページ (debug/Show_WSProp.jsp) を開きます。exception.trace キーを見つけて、値を true に変更します。
config/Waveset.properties ファイルをテキストエディタで開いて、exception.trace キー値を true に変更します。
有用なデバッグ情報を表示するには、記載されているメソッド/クラスのトレースレベルで「System Settings 」ページからトレースして、次の調整メソッドをトレースすることもできます。
表 5–4 トレース対象となる調整メソッド/クラス
トレース対象となる com.waveset.recon.メソッド/クラス |
実行すべきトレースレベル |
表示対象 |
---|---|---|
ReconTask$WorkerThread#reconcileAccount |
2 |
調整されている個々のアカウント |
ReconTask$WorkerThread#performResponse |
2 |
応答中の個々のアカウントとユーザー |
ReconUtil#deleteAccountIndex |
2 |
アカウントインデックスから削除対象となるユーザー情報。 |
UserContext#aquireRepoLock |
2 |
更新にロックされているユーザー。 |
UserContext#releaseRepoLock |
2 |
ユーザー。リポジトリでロック解除されているユーザー。 |
ReconUtil#deleteAccountIndex |
2 |
アカウントインデックスから削除対象となるユーザー情報。 |
UserContext#aquireRepoLock |
2 |
更新にロックされているユーザー。 |
ReconTask$WorkerThread#failUserExamination |
2 |
エラーで失敗した、すべてのユーザー検査要求 |
ReconTask$WorkerThread#failUserResponses |
2 |
エラーで失敗した、すべてのユーザー応答要求 |
UserContext#releaseRepoLock |
2 |
ユーザー。リポジトリでロック解除されているユーザー。 |
ReconTask$ResourceThread#examineResource |
3 |
リソースから読み込まれたアカウント数。 |
ReconTask$ResourceThread#queueAccountReconciles |
3 |
accountId 、accountGUID、accountDisabled など、リソースから読み込まれた各アカウントの情報 |
ReconTask$ResourceThread#examineLighthouse |
3 |
キューに入れられた調整済みリソースにアカウントを所有するために使用する Identity Manager ユーザークレーム数。 |
ReconTask$WorkerThread#findClaimants |
3 |
リソースのアカウントを要求するすべての Identity Manager ユーザー。 |
ReconTask$WorkerThread#confirmPossibleOwners |
3 |
リソースアカウントのすべての確定済み所有者のリスト。 |
ReconTask$WorkerThread#applyResponse |
3 |
適用されている応答リスト。 |
AccountContext#processAttributeWorkflow |
3 |
属性変更ワークフロー開始中の、属性変更内容と、フォーマット済み変更内容。 |
ReconUtil#getRuleState |
3 |
ルール処理中の、ユーザー属性を示したフルユーザービュー。 |
ReconUtil#evaluateCorrelationRule |
3 |
相互規則の状態の値と、検査の結果。 |
ReconUtil#confirmPotentialOwners |
3 |
確定ルールを使用して確定されたユーザーのリスト。 |
ReconUtil#getIfExistsAccountIndexEntry |
3 |
指定したエントリに対するアカウントインデックスの検査に関する情報の出力。 |
ReconUtil#launchWorkflow |
3 |
開始時のタスクインスタンスとタスク定義情報。 |
ReconUtil#indexFoundAccount |
3 |
存在が判明しているアカウントのインデックスの作成中または更新中に記録されたアカウントと状況。 |
ReconUtil#indexMissingAccount |
3 |
存在が判明していないアカウントのインデックスの作成中または更新中に記録されたアカウントと状況。 |
ReconUtil#listAccountsIndexSaysExist |
3 |
インデックスに存在が表示されているアカウント情報。 |
ReconTask$ResourceThreadwaitForLighthouseWorkItems# |
4 |
Identity Manager ユーザー検査プロセス中に、キューに入れられ処理されたユーザー数。 |
ReconTask$ResourceThread#waitForReconcileWorkItems |
4 |
指定リソースのキューに入れられ処理された調整と応答数。 |
ReconTask$WorkerThread#correlateUsers |
4 |
相互に関係するユーザーまたは確定ユーザーのリスト。 |
ReconTask$WorkerThread#respondOrRequeue |
4 |
アカウントに対し、前の応答メソッドの処理に問題があれば示されるエラーメッセージ。 |
Response#perform |
4 |
修正が行われる前と行われた後のユーザー、応答、およびユーザーのリソース情報 XML。 |
Response#perform |
4 |
ユーザーの応答アクションの概要。 |
Response#createNewUserFromAccount |
4 |
ユーザーの応答アクションの全詳細。 |
ReconUtil#evaluateConfirmationRule |
4 |
確定規則の状態の値と、検査の結果。 |
ReconUtil#getCorrelatedUsers |
4 |
指定ルールの結果に一致する相互関係ユーザーのリスト。 |
トレースレベルが高いほど、トレースファイルが大きくなります。また、これらのすべてのメソッドを同時にトレースすると、非常に大きなトレースファイルが作成されます。
トラブルシューティングが完了したら、exception.trace キー値を false に設定し直してトレースを無効にしてください。
setRepo コマンドを使用した Identity Manager リポジトリの設定中にエラーが表示されたら、次のフラグを使用して問題を切り離し、デバッグします。
-Dtrace.enabled=true -Dtrace.level.com.waveset.repository.AbstractDataStore=2 -Dtrace.level.com.waveset.repository.DefaultTypeHandler=4 // Use one of the following based on your repository type -Dtrace.level.com.waveset.repository.OracleDataStore=4 -Dtrace.level.com.waveset.repository.SqlServerDataStore=4 -Dtrace.level.com.waveset.repository.MysqlDataStore=4 -Dtrace.level.com.waveset.repository.DB2DataStore=4 |
Identity Manager が setRepo コマンドからデフォルトの $WSHOME/config/WSTrace.log ファイルに出力を送信します。
ここでは、SPML Version 1.0 と SPML Version 2.0 のトレースを有効にするためのメソッドについて説明します。
SPML 1.0 には、Identity Manager の SPML トラフィックと診断問題をログできるよう、トレース出力のチューニングに次のオプションが用意されています。
SPML 1.0 のトレースを有効に設定するには、SpmlClient と LighthouseClient クラスから提供される setTrace メソッドを使用します。
この setTrace メソッドを有効にすると、クライアントから送信された要求の XML と、サーバーから受信した応答の XML が、随時送受信時に クライアント コンソールに印字されます。
setTrace メソッドは、Boolean 引数を使用します。例を示します。
SpmlClient client = new SpmlClient(); client.setURL("http://localhost:8080/idm/spml"); client.setTrace(true); |
サードパーティである OpenSPML 団体のオープンソースクラスである org.openspml.server.SOAPRouter サーブレットの初期化時に、トレースを有効にできます。このサーブレットは、サーブレットが SPML 要求を処理できるよう、RPC トラフィック情報の出力を制御します。
このメソッドを有効にするには、次を WEB-INF/web.xml ファイルに追加します。
<servlet> <servlet-name>rpcrouter2</servlet-name> <display-name>OpenSPML SOAP Router</display-name> <description>no description</description> <servlet-class> org.openspml.server.SOAPRouter </servlet-class> <init-param> <param-name>trace</param-name> <param-value>true</param-value> </init-param> ... </servlet> |
次に、SPML 1.0 トレースの出力例を示します。
SpmlClient: sending to http://example.com:8080/idm/servlet/rpcrouter2 <spml:addRequest xmlns:spml='urn:oasis:names:tc:SPML:1:0' xmlns:dsml='urn:oasis:names:tc:DSML:2:0:core'> <spml:operationalAttributes> <dsml:attr name='session'> <dsml:value>session token</dsml:value> </dsml:attr> </spml:operationalAttributes> <spml:identifier type='urn:oasis:names:tc:SPML:1:0#GUID'> <spml:id>suetonius</spml:id> </spml:identifier> <spml:attributes> <dsml:attr name='objectclass'> <dsml:value>person</dsml:value> </dsml:attr <dsml:attr name='password' <dsml:value>password</dsml:value> </dsml:attr> <dsml:attr name='gn'> <dsml:value>Suetonius</dsml:value> </dsml:attr> <dsml:attr name='sn'> <dsml:value>Tranquillus</dsml:value> </dsml:attr> <dsml:attr name='email'> <dsml:value>twelve@example.com</dsml:value> </dsml:attr> </spml:attributes> </spml:addRequest> SpmlClient: received <?xml version='1.0' encoding='UTF-8'?> <SOAP-ENV:Envelope xmlns:SOAP-ENV='http://schemas.xmlsoap.org/soap/envelope/'> <SOAP-ENV:Body> <spml:addResponse xmlns:spml='urn:oasis:names:tc:SPML:1:0' xmlns:dsml='urn:oasis:names:tc:DSML:2:0:core' result='urn:oasis:names:tc: SPML:1:0#success'> <spml:operationalAttributes> <dsml:attr name='session'> <dsml:value>session token</dsml:value> </dsml:attr> </spml:operationalAttributes> <spml:identifier type='urn:oasis:names:tc:SPML:1:0#GUID'> <spml:id>suetonius</spml:id> </spml:identifier> </spml:addResponse> /SOAP-ENV:Body> </SOAP-ENV:Envelope> |
SOAP rpcrouter サーブレットの詳細は、OpenSPML Toolkit マニュアルを参照してください。
個々の SPML RPC 要求のトレースを有効に設定するには、trace オペレーショナル属性をサーバー側の RPC 要求に渡します。
サーブレット初期化中にトレースが実行され、サーブレットの RPC トラフィックが SPML Version 1.0 の要求を処理できるように、情報を出力する方法を制御します。たとえばこのトレースは raw XML を出力します。これは System.out が (アプリケーションコンテナの関数である) そのサーブレット用のものかどうかにかかわらず、行ったりきたり送信されます。たとえば、次のようになります。
AddRequest ar = new AddRequest(); ar.setOperationalAttribute("trace", "true"); |
trace 属性を使用したとき、属性がサーバー処理に影響を与える度合いはベンダーによって異なります。現在のところ、Identity Manager は raw 要求データと応答データをサーバーコンソールに出力しています。これは、クライアントアプリケーションがコンソールウィンドウに関連付けられていない場合に有用です。
詳細は、OpenSPML Toolkit 製品のマニュアルを参照してください。
SPML 2.0 には、Identity Manager の SPML トラフィックと診断問題をログできるよう、トレース出力のチューニングに次のオプションが用意されています。
SPML 1.0 と同様、サーブレットが SPML 2.0 要求を処理できるように、RPC トラフィック情報の出力を制御する org.openspml.v2.transport.RPCRouterServlet クラスの初期化時に、SPML 2.0 用のトレースが有効に設定できます。
このメソッドを有効にするには、次を WEB-INF/web.xml ファイルに追加します。
<servlet> <servlet-name>openspmlRouter</servlet-name> <display-name>OpenSPML SOAP Router</display-name> <description>A router of RPC traffic - nominally SPML 2.0 over SOAP</description> <servlet-class> org.openspml.v2.transport.RPCRouterServlet </servlet-class> <init-param> <param-name>trace</param-name> <param-value>true</param-value> </init-param> ... </servlet> |
次の例は、rpcrouter サーブレットトレースからの出力を表したものです。
RPCRouterServlet: <?xml version='1.0' encoding='UTF-8'?><SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"><SOAP-ENV:Header/> <SOAP-ENV:Body><lookupRequest xmlns='urn:oasis:names:tc:SPML:2:0' requestID='random name' executionMode='synchronous' returnData='everything'> <openspml:operationalNameValuePair xmlns:openspml='urn:org:openspml:v2:util:xml' name=' session'value=session token'/> <psoID ID='random name' targetID='spml2-DSML-Target'/> </lookupRequest> </SOAP-ENV:Body></SOAP-ENV:Envelope> RPCRouterServlet: response: <?xml version='1.0' encoding='UTF-8'?> <SOAP-ENV:Envelope xmlns:SOAP-ENV='http://schemas.xmlsoap.org/soap/envelope/'> <SOAP-ENV:Body> <lookupResponse xmlns='urn:oasis:names:tc:SPML:2:0' status='failure' requestID='random name'error='noSuchIdentifier'> <openspml:operationalNameValuePair xmlns:openspml='urn:org:openspml:v2:util:xml' name='session' value=session token/> <errorMessage>Item User:random name was not found in the repository, it may have been deleted in another session.</errorMessage> </lookupResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
詳細は、「SPML 1.0 のトレースを有効にする」セクションの「メソッド 2: org.openspml.server.SOAPRouter サーブレットの初期化」を参照してください。
SPML 2.0 は、有用なトラブルシューティングツールとして使用できる、簡易テキストのアクセスログです。このログは常に使用可能で、受信された要求の種類、その要求の処理に掛かった所要時間、要求が完了したかどうかなどの情報を、トレースを有効に設定しなくても表示できます。
この SPML テキストのアクセスログの設定手順は、『Sun Identity Manager 8.1 Web Services』の「Configuring SPML Tracing」に記載されています。
スケジューラタスクに問題がある場合は、com.waveset.task.Scheduler にある標準トレース機能を使用してタスクスケジューラをトレースできます。この出力には、タスクスケジュールについての詳細情報が表示されます。
ブラウザを開き、管理者インタフェースにログインします。
「設定」>「サーバー」の順に選択します。
「サーバー設定」ページが表示されたら、「サーバー」列からサーバー名をクリックしてその設定を編集します。
「サーバー設定の編集」ページで、「スケジューラ」タブをクリックします。
スケジューラのデバッグトレースを起動してその結果を stdout に書き込むには、「トレースの有効化」ボックスを選択します。
変更を保存します。
クラスター化された環境で、各インスタンスでトレースが実行されます。
トレース設定オブジェクトの定義と編集方法、およびトレースファイルの表示方法については、「Identity Manager サーバーのトレース」を参照してください。
ワークフローのトレースを有効にすると、ワークフローアクティビティの問題を解決して、ワークフロープロセスが把握できるようになります。
クラスター化された環境で、各インスタンスでトレースが実行されます。
複数台のサーバー配備でワークフローをデバッグするには、1 台のサーバーを残してすべてシャットダウンするようにしてください。すべてのサーバーが実行中の場合は、環境内でどのサーバーがワークフローを実行中かを判断できず、トラブルシューティング問題の原因が特定できません。
ワークフローのトレースを有効にするには、次の項目を実行します。
ブラウザを開いて、Identity Manager 管理者インタフェースにログインします。
「System Settings 」ページの「List Objects Type」メニューから「Configuration」を選択します。
「List Objects」ボタンをクリックします。
「List Objects of type: Configuration」ページが表示されたら、オブジェクトリストをスクロールダウンして System Configuration オブジェクトを見つけ、その編集リンクをクリックします。
「Checkout Object: Configuration, #ID#CONFIGURATION:SYSTEMCONFIGURATION 」ページが表示されたら、SystemConfiguration オブジェクトの次のいずれの workflow オプションでも編集できます。
通常、有効にするオプションは 1 つだけですが、同時に複数のオプションを有効にすることもできます。
これらの属性は、互いに依存していません。一種類のトレースを有効にしながら、他の種類を無効に設定することが可能です。
アプリケーションサーバーのコンソールにワークフローのトレースメッセージをリダイレクトするには、workflow.consoleTrace=true を指定します。この属性の方が workflow.fileTrace よりも多くのトレース出力を出力するため、致命的な例外でワークフローが終了したときに役立ちます。(デフォルト値は false です。)
ワークフローのトレースメッセージを読みやすいファイルにリダイレクトするには、workflow.fileTrace=PathtoFile を指定します。この属性には、デフォルトで値がありません。
<Attribute name=’fileTrace’/>
workflow.fileTrace 属性に値タグを付け、Unix 式の普通のスラッシでログファイルにパスを入力します。Identity Manager が、アプリケーションサーバーのインストールディレクトリに関する相対パスを格納します。例を示します。
Windows の場合。 <Attribute name=’fileTrace’ value=’C:\mydir\workflow.txt’/>
Solaris/UNIX の場合。 <Attribute name=’fileTrace’ value=’/mydir/workflow.txt’/>
表示するワークフローのトレースレベルをを指定するには、workflow.traceLevel=tracingLevel を指定します。
ワークフロープロセスをトレースするには、workflow.Trace=true を指定します。このオプションでトレースを開始するには、アプリケーションサーバーを再起動する必要があります。Identity Manager が、タスクの WavesetResult オブジェクトにトレース結果を格納します。ファイルシステムにアクセスできない場合は、このトレースオプションを使用してください。(デフォルト値は false です。)
タスクの WavesetResult にあるメッセージをトレースします。(デフォルト値は 1 です。)
workflow.Trace=true を指定すると、読みにくくて長い未フォーマットの 1 つの文字列にトレースメッセージが付与されます。このオプションは、ファイルシステムにアクセスできない場合のみ使用してください。
最初の 2 つのオプションを使用すると、致命的な例外が発生した場合に、ワークフローのトレースの一部を紛失してしまうことがあります。
SystemConfiguration オブジェクトを保存します。
アプリケーションサーバーを再起動するか、SystemConfiguration オブジェクトを Identity Manager のデバッグページから再読み込みします。
指定のワークフローのトレースを有効にするには、次のいずれかの方法を用います。
WFProcess 定義の編集。特定のプロセスに条件付きトレースを有効にするには、trace=’console の属性を <WFProcess> 要素に追加して、TaskDefinition オブジェクトの XML を編集します。
ワークフロー変数の編集。ワークフロー変数を使用すると、トレースのタイミングをより細かく制御できるようになります。ワークフローエンジンは、trace という最上位のワークフロー変数を検索します。
次の例は、ワークフロー変数のトレース方法の一例を示したものです。
<Variable name=’trace’> <cond><eq><ref>accountId</ref><s>jfaux</s></eq> <s>workflowTrace.txt</s> </cond> </Variable> |
trace 変数は、そのワークフローが jfaux というユーザー名で処理されている場合だけ、トレースを有効にします。さらに、トレースを対話式に制御するには、フォームフィールドの trace を指定します。
たとえば、トレース出力は workflowTrace.txt ファイルに書き込まれます。
現在使用中の Identity Manager バージョンの情報を表示するには、次のいずれかの方法を用います。
Identity Manager アプリケーションウィンドウの右上にある「ヘルプ」ボタンの上にカーソルを置きます。バージョン番号が記載されたポップアップが表示されます。
Waveset.properties ファイルを開き、ファイルの最上部にある情報をチェックします。
現在使用中の JVM バージョン情報とその他システムソフトウェアのバージョン情報を表示するには、「Identity Manager System Properties」ページ (/debug/SysInfo.jsp ) を使用します。
ここでは、Sun Identity Manager Gateway のオブジェクトとアクティビティーのトレース方法について説明します。この内容は、次のように構成されています。
ゲートウェイのトレースファイルを表示したり編集するときは、メモ帳を使用してファイル制限を回避します。
ゲートウェイを起動すると、エントリを削除せずに、プログラムがトレースファイルに新しいトレースエントリを追加します。ゲートウェイのトレースエントリ開始点を探すには、Gateway version 文字列を探します。
ゲートウェイバージョンは、ゲートウェイ起動時にトレースに自動的に出力されます。このバージョンを表示するには、コマンドラインから gateway -v と入力することもできます。
Identity Manager で Windows アカウントの問題をデバッグするには、「ゲートウェイデバッグ」ページ(Gateway.jsp) またはコマンドラインから有効にします。
次に、この手順について説明していきます。
ゲートウェイにアクセスできない場合は、「ゲートウェイデバッグ」ページ (Gateway.jsp) から、トレースを有効にします。このデバッグページから、ゲートウェイトレースファイルを指定して検索することができます。
Identity Manager 管理者インタフェースにログインします。
この「ゲートウェイデバッグページ」を開くには、ブラウザに次の URL を入力します。
http://host :port/idm/debug/Gateway.jsp
「ゲートウェイリソースリスト」から、トレースするリソースを選択します。
必要に応じて、今までの設定を修正します。
設定を修正するには、次のボタンをクリックします。
「バージョンの取得」。ゲートウェイを実行中のマシンのゲートウェイバージョンとオペレーティングシステムのバージョンを返します。
「トレースファイルの取得」。トレースファイルのコンテンツを返します。
「トレースパラメータの取得」。トレースファイルのパス、トレースレベル、およびトレースファイルの最大サイズを返します。
「トーレスパラメータの設定」。以上のオプションについては、「トレース設定オブジェクトを新規作成する」を参照してください。
「ロードされたモジュールの取得」。ゲートウェイで使用中のモジュール (DLL) のロードアドレスを返します。
「ロードしたモジュールの取得」リストはロードアドレスから構成され、その後にモジュール名が続き、ロードされたモジュールだけが記載されます。このリストには、呼び出されずに遅延してロードされたモジュールは記載されません。
「ロードしたモジュールの取得」オプションは、Active Directory と Domino にのみ対応しています。
幅広いオプションを使用するには、コマンドラインからのトレースを有効にすると便利です。
コマンドウィンドウを開きます。
必要なトレースのコマンド引数を指定して、ゲートウェイを起動します。
ゲートウェイをトレースするコマンドライン引数は、次の表のとおりです。
使用状況: gateway -f name -l -m
例を示します。
cd %WSHOME%\bin\winnt gateway -d -p 11319 -f %CD%\gateway.trc -l 2 -m 500 |
上記の呼び出しにより、次の特性を備えたゲートウェイが起動します。
-d – 通常アプリケーションを使用 (サービス以外)
-p 11319 – ポート 11319 を使用
ゲートウェイリソースには、Identity Manager のリソース設定からこのポートを設定しておく必要があります。たとえば、Active Directory リソースの場合
-f %CD%\gateway.trc – トレース出力の書き込み先となるディレクトリ。Identity Manager は、このディレクトリのトレース出力をテキストファイルに書き込みます。
-l 2 – ゲートウェイトレースの出力レベル 2。
-m – トレースのログファイルの最大サイズ (KB 単位)。
指定されていれば、次回ゲートウェイをコマンドラインからまたはサービスとして実行したときに同じ値が使用されるように、Identity Manager が -f 値、-l 値、および -m 値をレジストリに保存します。
Identity Manager はゲートウェイのトレース出力をコンソールおよびトレースファイルに送信します。
PowerShellExecutor.dll は、ゲートウェイと Microsoft PowerShell 間の通信を実装するアドオンです。この PowerShell は、Exchange Server 2007 アカウントを管理するのに使用します。このアドオンは、残りのゲートウェイとトレース機能を共有せず、残りのゲートウェイと同様のスタンドアロンのトレース機能を備えています。
PowerShellExecutor のトレース設定は、ほかのゲートウェイのレジストリキーとして同じレジストリキーに格納されます。
HKEY_LOCAL_MACHINE\Software\Waveset\Lighthouse\Gateway
このベースキーは、Identity Manager のデバッグページからトレースを設定したり、トレースコマンド引数でゲートウェイを開始すると作成されます。
シャットダウン時に、レジストリにトレースできるようにゲートウェイから現 PowerShellExecutor 設定が書き込まれます。次の設定があります。
traceFileName
コンテンツ。 トレース出力用のファイル名 (レジストリ型 REG_SZ)
「デフォルト」。" "
PowerShellExecutor トレースに生成するトレースファイル名。このファイル名には、
ファイル名などが省略されていないパスを設定できます。
スラッシュ (\) で終わることはできません。
ファイルを除き、traceFileName 内の省略されていないパスが必要です。
これが設定されている場合、そのファイルがもはやアクティブでなければ、ローテーション後にログのローテーションから設定済みファイル名にタイムスタンプが付与されます。このタイムスタンプは、次の形式で表示されます。
yyyyMMddHHmmss
traceLevel
コンテンツ。 トレースレベル (レジストリ型 REG_DWORD)
「デフォルト」。0 (トレースなし)
許容。0–4
このキーは、残りのゲートウェイと共有されます。ゲートウェイ全体は、常に同じレベルでトレースを行います。
traceMaxSize
「内容」。バイト単位の最大ファイルサイズ (レジストリ型 REG_DWORD または REG_QWORD)
「デフォルト」。100000 バイト
最小。100000 バイト
ほかのシステムに移動できるよう、トレーステキストは、バイトオーダーマークが付いた UTF–8 エンコード化テキストで書き込まれます。
traceMaxFiles
「内容」。トレースファイル数 (レジストリ型 REG_DWORD )
「デフォルト」。2
最小。1
この設定は、システムで保持するトレースファイル数を制御します。最大ファイル数の設定を 1 にし続けると、最大サイズに達したときにファイルが上書きされてしまいます。最後の書き込み時刻を基にして一番古いファイルは、最大ファイル数に達したときに削除されます。
traceConfigInterval
「内容」。ミリ秒単位のタイムアウト (レジストリ型 REG_DWORD)
「デフォルト」。300000 ms (5 分)
最小。60000 ミリ秒 (1 分)
すべてのトレース設定は、このタイムアウト値を基にしてレジストリから再読み取りされます。本稼動環境では、オーバーヘッドを最小限に抑えるために、この値を 24 時間などの大きな値に設定するようにしてください。
ゲートウェイに深刻な問題が生じて異常終了した場合は、表示されたワトソン博士のログを Sun サポートに送信して解析を依頼することができます。
これらのログを表示するには、そのシステムの管理者権限が必要です。
Windows の「イベントビューア」を開きます。
アプリケーションログを開きます。
DrWatson ソースのイベントを探します。
詳細を表示するには、そのイベントを開きます。
「データ」に「バイト」オプションが選択されていることを確認します。
ディスプレイダイアログを右クリックして、メニューから「すべて選択」を選択します。
情報をコピーするには、Ctrl-C キーを押します。
この情報をメモ帳に貼り付け、ファイルを保存します。
問題の詳細な説明を記述して、そのファイルを Sun サポートまで電子メールで送信します。実行中の Identity Manager ゲートウェイのバージョンを必ず記載してください。
Identity Manager を使用中に発生した問題を診断して解決できるようにするには、次のセクションに説明している情報をご利用ください。
Identity Manager の FAQ など、これ以外のトラブルシューティングについては次の URL にアクセスしてください。
https://sharespace.sun.com/gm/document-1.26.2296/IdM_FAQ.html?
注意: このサイトに記載している説明にアクセスするには、Share Space ID を登録している必要があります。
使用中の Identity Manager 配備で問題を特定して解決できるようにするには、数種類のデバッグツールが使用できます。次のツールがあります。
使用中の配備で問題を特定して解決できるようにするには、Identity Manager のデバッグページを使用します。たとえば、各種アクティビティーとオブジェクトのトレースの有効化と無効化、統計情報の収集、実行中のプロセスの検証、またはボトルネックとメモリー問題の調査が行えます。
一番よく使用されるデバッグページとその実際の .jsp ファイル名は、次の表のとおりです。
すべての Identity Manager デバッグページの総覧については、コマンドウィンドウを開いき、idm/debug ディレクトリのコンテンツを一覧表示します。
以上のデバッグページの詳細は、「Identity Manager のデバッグページの使用」を参照してください。
Identity Manager のデバッグページにアクセスして操作を実行するには、デバッグ機能が必要です。デバッグ機能がない場合は、エラーメッセージが表示されます。管理者とコンフィギュレータには、デフォルトでこのデバッグ機能が割り当てられています。
ブラウザを開き、管理者インタフェースにログインします。
次の URL を入力して、「System Settings 」ページを開きます。
http://host:port/idm/debug
各表記の意味は次のとおりです。
host は、Identity Manager の実行先ローカルサーバーです。
port は、このサーバーが監視中の TCP ポート数です。
このページから、Identity Manager の各種アクティビティーやオブジェクトのトレースを有効にしたり無効にできるほか、これらのページに表示される情報を基に、使用中の配備の問題をトラブルシューティングできます。
デバッグページの中には、「System Settings」ページにリンクされていないものもありますので、そのページの .jsp ファイル名を入力してページを開く必要があります。例を示します。
http:// host:port/idm/debug/ pageName.jsp
ここで、pageName.jsp は、開こうとしている個々のデバッグページです。
SunTM Sun Identity Manager 統合開発環境 (Identity Manager IDE) は、使用中の配備の Sun Identity Manager (Identity Manager) オブジェクトを表示、カスタマイズ、デバッグできる Java アプリケーションです。
具体的に言うと、Identity Manager IDE にはグラフィカルなデバッガが用意されており、Identity Manager のフォーム、ルール、およびワークフローをデバッグに使用することができます。このデバッガを使用すると、ブレークポイントとウォッチの設定、コードのステップ実行、変数の検査と修正、クラスと呼び出しスタックの検査、スレッドの抽出、およびマルチセッションの実行が行えます。
Sun Identity Manager 統合開発環境 (Identity Manager IDE) のインストール手順と設定手順は、次の URL から入手できるようになりました。https://identitymanageride.dev.java.net
Identity Manager のシステム監視を設定すると、システムイベントを追跡できます。システム監視は、各種レベルで統計を収集して集約し、仕様に従ってシステムイベントをリアルタイムに表示します。
この情報を計器盤グラフで表示すると、監査ログを見る前に、システムリソースの即時評価、異常の表示、履歴パフォーマンスの傾向の把握、および対話式で問題を切り離すことができます。計器盤は監査ログほど詳細に表示しませんが、この計器盤を見ると、ログのどこを見れば問題が探せるかがわかります。
計器盤とシステム監視の詳細は、『Sun Identity Manager 8.1 ビジネス管理者ガイド』の第 8 章「レポート」を参照してください。
アダプタログは、現在処理中のアダプタ情報を取り込みます。この情報を基に、アダプタの進捗を監視し、アダプタの問題を診断してデバッグすることができます。
トレースを有効に設定し、ログが実行される前にトレースが必要なメソッドを特定しておく必要があります。また、カスタマイズしたアダプタには、この新しいメソッドのログエントリを作成する呼び出しを含めておく必要があります。
ほぼすべてのアダプタに、独自のログファイル、パス、およびログレベルがあります。適切な Identity Manager または サービスプロバイダ ユーザータイプの同期ポリシーにある「ログ」セクションのほかの値をとともに、このアダプタログで取り込む詳細レベルを指定できます。
デバッグツールとしてアダプタログファイルを使用する詳細は、「アダプタのトラブルシューティング」を参照してください。
DTrace とは、Solaris オペレーティング環境に使用する、総合的な動的トレースのフレームワークです。DTrace には 30,000 を超えるプローブを使用中の本稼動システムに提供し、ユーザーレベルのトレースとカーネルレベルのトレースを統合します。JVM アクティビティーを監視するには、DTrace を使用します。この機能を使用すると、D 言語 (C 言語や awk のようなもの) も使用して任意のデータと式をトレースできるようになります。
Java Monitoring and Management Console (JConsole) とは、Java Management Extension (JMX) 技術に対応したグラフィカル管理ツールで、JDK 5 (以降) に付属しています。JConsole は実行中の JVM に接続し、接続している JMX エージェントの JVM MBeans から情報を収集します。
たとえば、JConsole を使用してできる操作には次のようなものがあります。
低位アドレスメモリーの検出
ガベージコレクションの有効化または無効化
冗長トレースの有効化または無効化
デッドロックの検出
Identity Manager のログレベルの制御
システムリソースの操作に関するアクセス情報 (Sun のプラットフォーム拡張)
MBeans の監視と管理
JVM、監視した値、アプリケーションで実行中のスレッド、およびクラスのローディングについての情報表示
JConsole の詳細は、「JConsole を使用したアプリケーションの監視」というタイトルの記事を参照してください。この記事は、次の URL から表示できます。
http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html
アクションを実行した後に Identity Manager インタフェースに赤いエラーメッセージが表示された場合は、ページのソースを表示して保存し、情報全体を表示してエラーを解析してください。
ページのソースの表示する
Internet Explorer を利用している場合は、メニューバーから「表示」>「ソース」の順に選択します。
NetscapeTM を利用している場合は、メニューバーから「表示」>「ページのソース」の順に選択します。
それでもまだ問題の解決にサポートが必要な場合は、
ページソースを表示してから、「ファイル」>「保存」の順に選択してシステムにこのファイルを保存します。
保存したファイルから、エラーを見つけます。
エラー情報、問題が発生したページの URL、問題の説明を電子メールで Sun サポートまで送信し、解決サポートを依頼してください。
アダプタをトラブルシューティングするには、アダプタのログファイルをレビューします。ほとんどのアダプタはそのリソース設定をログファイルに書き込んでいるため、この情報を基に、そのアダプタが起動していること、すべての設定の変更内容が保存されていることを確認できます。
トレースを有効に設定し、ログが実行される前にトレースが必要なメソッドを特定しておく必要があります。また、カスタムアダプタには、この新しいメソッドのログエントリを作成する呼び出しを含めておく必要があります。
トレースを有効にする手順については、必要に応じて「Identity Manager サーバーのトレース」を参照してください。
ほとんどのアダプタログファイルは、$WSHOME/config ディレクトリにあり、WSTrace1.log という名前が付けられています。
ActiveSyncUtil インスタンスへのログ呼び出しを作成し Active Sync が有効に設定されているアダプタは、Log File Path リソース属性で指定されたディレクトリにログファイルまたはログファイルセットを作成します。このほかにも Active Sync 関連のログエントリがないか、このログファイルを必ずチェックしてください。
この節の情報は、次のように構成されています。
カスタムアダプタをデバッグするには、この一般的な手順に従ってください。
アダプタにテストプログラムを作成し、この Java ファイルが次の基本機能を実行することを確認します。
リソースの新規作成
ユーザーの作成
ユーザーの取得
ユーザーの更新
ユーザーの削除
複数ユーザーに、作成、取得、更新、および削除の操作を実行します。
サンプルテストファイル (SkeletonResourceTests.java) が、インストール CD の/REF ディレクトリに用意されています。
デバッグに適切なログレベルを設定します。
たとえば、最初のデバッグパスには、ログレベル (最大デバッグ出力) を 4 まで上げ、ログファイルのパスを設定し、最大ファイルサイズを指定します。
アダプタを起動すると、すべてのリソース設定がこのログファイルに書き込まれます。この情報を基に、アダプタが起動したこと、全ての設定の変更内容が保存されたことを確認できます。
アダプタをコンパイルしてテストします。
テストプログラムをコンパイルするには、コマンドウィンドウを開いて javac -dtest/filename.java コマンドを入力します。このコマンドは、適切な com/waveset/adapter/test ディレクトリにクラスファイルを作成します。
このクラスファイルを使用して新アダプタをテストするには、コンパイルしたアダプタが com/waveset/adapter ディレクトリにあることを確認して、次のコマンドでこのアダプタを実行してください。
java– D waveset.home=path com.waveset.adapter.test. MyResourceAdapter |
リソースの HTML ヘルプファイルを作成します。
サンプルのヘルプファイルが、com/waveset/msgcat/help/resources ディレクトリの idm.jar ファイルに用意されています。
アプリケーションのオンラインヘルプを記載する方法については、『Sun Identity Manager Deployment Reference』を参照してください。
(Active Sync が有効なアダプタの場合のみ) 最後のリソースで同期をリセットするには、XmlData SYNC_resourceName オブジェクトを削除します。
エラーログを読み、アダプタを修正します。
ログレベルをリセットします。
たとえばレベル 2 のデバッグを指定すると、アダプタ設定とエラーに関する情報が表示されますが、ログの詳細量が管理できるレベルまでに制限されます。
Identity Manager を起動する前に、resource.adapters エントリの下にあるアダプタ名を設定して $WSHOME/config/Waveset.properties ファイルにある新アダプタを特定しておく必要があります。そうしないと、Identity Manager がそのアダプタを認識できません。
アダプタとその関連ヘルプファイルを Identity Manager にインストールします。
Identity Manager がディスプレイ内の新アダプタのインスタンスを認識できるようにする前に、そのタイプの新リソースを「リソースのリスト」ページから作成しておく必要があります。
このページから「新規」>「新アダプタ」の順に選択し、「リソースウィザード」から新アダプタを作成します。
Identity Manager で、そのリソースにリソースとユーザーを作成します。
Active Sync 有効アダプタをトラブルシューティングする際、XmlData SYNC_resourceName オブジェクトを編集して Active Sync 同期プロセスの MapEntry を「デバッグ」ページから削除していれば、アダプタが最初に検出された変更点からやり直します。
IAPI イベントを使用した場合に、最後に処理した変更値などのリソースの同期状態を格納するには、Property() メソッドを設定する必要があります。このメソッドを設定すると、アダプタのトラブルシューティングに非常に役立ちます。過去の変更内容を実行して無視するようにアダプタを設定することができます。それ以降は、アダプタを修正して、変更結果をアダプタのログファイルに表示できるようになります。
使用中のリソースが Active Sync リソースの場合は、そのリソースの編集ページでログを有効にしていれば、さらに情報が表示されることもあります。ログレベル (0-4) を設定し、ログファイルの書き込み先となるファイルパスを設定します ( resource_name.log など)。
(Active Sync 有効アダプタの場合のみ) 最後のリソースの同期を再起動します。
LoginConfig 関連の変更点をデバッグするには、次を行う必要があります。
選択したファイルのトレースを有効にし、メソッド/クラスレベル 1 トレースで次のクラスをトレースします。
com.waveset.security.authn.WSResourceLoginModule
com.waveset.session.LocalSession
com.waveset.session.SessionFactory
com.waveset.ui.LoginHelper
com.waveset.ui.web.common.ContinueLoginForm
com.waveset.ui.web.common.LoginForm
Telnet で、次のようにシングルサインオン (SSO) のパススルー認証ログインをテストします。
SSO ログインモジュールを正しく設定したら、HTTP ポートに直接 telnet し、HTTP 要求を login.jsp に送信します。
次の要求を telnet セッションに貼り付けます。これには、sm_user HTTP ヘッダーを検索する SSO ログインモジュールが記載されています。
HEAD /idm/login.jsp HTTP/1.0 Accept: text/plain,text/html,*/* Accept-Language: en-us Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 Host: LOCALHOST sm_user: Configurator |
トレースに、ユーザーが正常にログインしたと表示されます。例を示します。
2003.07.08 14:14:16.837 Thread-7 WSResourceLoginModule#checkForAuthenticatedResourceInfo() Found authenticated resource accountId, ’Configurator@Netegrity SiteMinder’on Identity Manager user ’Configurator’. null null 2003.07.08 14:14:16.837 Thread-7 WSResourceLoginModule#checkForAuthenticatedResourceInfo() Exit null null 2003.07.08 14:14:16.837 Thread-7 WSResourceLoginModule#login() Exit, return code = true null null 2003.07.08 14:14:16.847 Thread-7 LocalSession#login() Login succeeded via Netegrity SiteMinder null null 2003.07.08 14:14:16.847 Thread-7 LocalSession#login() Overall authentication succeeded null null 2003.07.08 14:14:16.897 Thread-7 LocalSession#checkIfUserDisabled() Entry null null 2003.07.08 14:14:16.897 Thread-7 LocalSession#checkIfUserDisabled() Exit null null 2003.07.08 14:14:16.927 Thread-7 LocalSession#login() Exit null null |
ここでは、よくあるアダプタ接続問題のデバッグ方法について説明します。
このセクションのトピックは、次のように構成されています。
通常、アダプタクラスの com.waveset.adapter.adapter_classname をトレースすれば、アダプタの接続問題を特定できます。例を示します。
com.waveset.adapter.ADSIResourceAdapter
トレースを有効にする手順については、「Identity Manager サーバーのトレース」を必要に応じて参照してください。
よくある認証問題には、次のようなものがあります。
認証プロパティーが欠落している。
指定した DataSource タイプのプロパティー名をトレースの名前セット出力に含める必要があります。
Identity Manager ユーザーに、一致するリソースアカウントがない。
リソースアダプタの認証に成功したが、リソースアカウント ID と一致する Identity Manager ユーザーが見つからなかったという例外が発生した場合は、そのユーザーに関連付けられているリソースの accountId が、リソースアダプタの認証メソッドで返された accountId と同じであることを確認してください。
Identity Manager ユーザーのリソース accountId を検証するには、Identity Manager の「トレース設定の編集」ページ (debug/Show_Trace.jsp ) をレビューします。不一致が合った場合は、authenticate メソッドから返される名称を変更するか、使用リソースの ID テンプレートを変更してください。テンプレートは、authenticate メソッドで返される accountId と一致するリソース accountId を生成する必要があります。
カスタム Active Sync アダプタで最もよくある問題は、フォーム関連のものです。この種のエラーは通常、必須フィールドにパスワードや電子メール情報など必要な情報を入力しなかったために起こります。
Identity Manager は、ビューの最終 XML の後に、フォーム検証エラーをアダプタログに出力します。例を示します。
20030414 17:23:57.469: result from submit (blank means no errors): 20030414 17:23:57.509: Validation error: missing required field password |
Identity Manager は、アダプタログにすべてのメッセージも出力します。このメッセージには、アカウント作成時と更新時、アダプタエラー、スキーママップデータなどが記載されます。
Active Sync リソースアダプタは、最後に処理した変更内容についての情報を SYNC.resourceName XMLData オブジェクトに格納します。
次に、よくある Domino ゲートウェイとアダプタの設定エラーと、この問題の解決手順を説明します。
エラーメッセージに「"新しい Domino ゲートウェイ" にアクセスできません、接続が拒否されました」というエラーメッセージが表示された場合は、Identity Manager のゲートウェイを終了して再起動してみてください。
「ID ファイル名が指定されていません、userID ファイルへのパスが正しく設定されていません」というエラーメッセージが表示された場合は、userID の目標位置を指定し、リソースアダプタを編集してこの属性を正しいパスに設定します。通常、userID ファイルの目標位置は、ゲートウェイのインストール先ディレクトリにあります。
「このサーバーを使用する権限がありません。」というエラーメッセージが表示された場合は、ID ファイルに正しいアクセス権限が設定されていません。このファイルに正しい権限を指定してから、やり直してください。
RACF、ACF2、または TopSecret のホストアダプタが接続を再利用できなかったりキャッシュできないと、ユーザーが頻繁にログインしなくてはならなくなります。これにより、パフォーマンスに悪影響を与えます。この問題は、キャッシュのタイムアウト設定に原因があることがよくあります。
キャッシュのタイムアウト設定を確認するには、Identity Manager のアダプタ接続プールを次のようにトレースします。
Identity Manager の「Edit Configuration Object」ページから、com.waveset.adapter.HostConnPool#reapConnections メソッドをレベル 4 でトレースします。
トレースを有効にする手順については、「Identity Manager サーバーのトレース」を必要に応じて参照してください。
アダプタが操作を実行中に、十分な長さの期間のトレースを取り込みます (最低 30-60 分)。
アプリケーションサーバーの stdout のトレース出力またはトレースファイルをレビューして、Info reaping connection エントリを見つけます。
もしもこのエントリが 30 分おきに 1 回以上発生している場合は、接続が不必要にタイムアウトになっているということです。
この問題を解決するには、Idle Timeout リソース属性値を上げて、接続が頻繁にリープされすぎないようにします。Idle Timeout 属性値は、接続がログアウトされるまでのアイドル期間を制御します。デフォルト値は 90 秒ですが、これですと新たなログインが頻繁に発生します。
理想的には、配備環境に合わせて、平均的なアイドル時間より長い値を指定してください。たとえば、Idle Timeout 属性値を 30 分 (1800000 ミリ秒) 以上に調節します。
ここでは、次のような PeopleSoft のアダプタ問題をトラブルシューティングする方法について説明します。
PeopleSoft リソースアダプタから「テスト接続」を実行すると、多様な例外状態が発生する原因となります。
Waveset.properties ファイルを開き、 exception.trace=true を設定します。
テスト接続を再試行し、次のような結果が表示される場合があります。
FormState: expansion complete java.lang.NullPointerException: PSProperties not loaded from file WavesetException: WavesetException: ==> com.waveset.util.WavesetException: FormState: derivation Log in to the PeopleSoft web interface to verify that you are using the correct UID and password. |
この PeopleSoft アプリケーションサーバーのログには、ログインしようとしている試行がありません。
この問題は、接続先の PeopleSoft インストールに付属している psjoa.jar ファイルを使用しなかったためによく起こります。(PeopleSoft リソースアダプタの詳細は、『Sun Identity Manager 8.1 リソースリファレンス』 を参照してください。)
SAP or SAP HR Active Sync アダプタから SAP システムへの接続をテストしようとしてエラーが発生した場合は、コマンドウィンドウを開き、インストール先ディレクトリ WEB-INF/lib からこのコマンドを実行します。
java -jar sapjco.jar
sapjco.jar コマンドは、インストールされている SAP Java Connector (JCO) のバージョンと、このアダプタが正しくインストールされているかを表示します。このコマンドは、JavaTM Native Interface (JNITM) の参照先プラットフォーム、および SAP システムと通信している RFC ライブラリも返します。
この参照先プラットフォームのライブラリが見つからない場合は、SAP マニュアルを参照して、SAP Java Connector の正しいインストール方法を調べてください。
ここでは、UNIX アダプタによくある問題をデバッグする方法について説明します。
UNIX リソースアダプタへのプロビジョニング中にタイムアウトエラーが表示された場合は、最大ログ出力が得られるメソッド/クラスレベル 4 で com.waveset.adapter.ScriptedConnection をトレースすれば、プロビジョニングプロセスが失敗している場所を見つけることができます。
管理上のコマンドを実行する root になるときに、リソースアダプタが su root コマンドを su - root コマンドの代わりに実行すると、カスタムプロンプトなど、root に定義されているカスタム環境変数が環境に何も継承されなくなります (PS1 の環境変数)。
UNIX アダプタを設定する際、次のようにすれば Root Shell Prompt フィールドに入力すべきプロンプトを判断できます。
「ログインユーザー」フィールドに指定したユーザーでシステムに Telnet または ssh します。
パスワードを入力してログインしたら、ダッシュなしで su root を入力して改行キーを押します。
root パスワードを入力します。
次に表示されたプロンプトが、Root Shell Prompt フィールドに入力すべきプロンプトです。
Identity Auditor を使用すると、次のメソッドをトレースして問題をトラブルシューティングできます。
com.sun.idm.auditor.policy - Audit Scan の問題をトレースします。
com.sun.idm.auditor.accessreview - Access Reviews の問題をトレースします。
com.sun.idm.auditor.report - Audit Reports の問題をトレースします。
com.sun.idm.auditor.view - Auditor Views の問題をトレースします。
また、Form または TaskDefinitions を修正すれば、次の非表示フラグを設定できます。
Audit Policy Scan Task - maxThreads (int)。使用した並行スレッド数。(デフォルトは 5)。
Audit Policy Scan Task - userLock (int)。ユーザーオブジェクトでロックを取得するまでの時間 (ミリ秒単位)。(デフォルトは 5000)。
Audit Policy Scan Task - scanDelay (int)。新しいスキャンスレッドを開始する間の遅延時間 (ミリ秒単位)。(デフォルトは 0 で、遅延なし)。
Audit Policy Scan Task - clearuserLocks (boolean)。true の場合は、スキャンする前にスキャナがユーザーロックの消去を試みます。
また、「Show Timings」ページ (/debug/callTimer.jsp ) に次の情報が表示されます。
スキャン中の初期ユーザービューの取得に掛かる所要時間 (リソースなし)
スキャン中の初期ユーザービューの取得に掛かる所要時間 (リソース含む)
ユーザービューのポリシー評価に掛かる所要時間
ユーザービューの取得やポリシー評価など、各ユーザースキャンに掛かる所要時間
アクセスをレビューするためにユーザーリストの取得に掛かる所要時間
アクセスレビューでアクセスアテステーションルールの評価に掛かる所要時間
ClassNotFound の例外エラーのイベント発生時には、サーバーのクラスパスに欠けているクラスがないか確認します。このクラスパスが適切に設定されている場合は、親クラスのローダーの前にアプリケーションクラスローダーがロードしたとおりにアプリケーションサーバーを設定してみてください。場合によっては、アプリケーションのクラスパスをサーバーのクラスパスの前にロードすると、この問題が解決できることがあります。この手順については、アプリケーションサーバーのマニュアルを参照してください。
ここでは、よくあるフォーム問題と、この問題の解決方法について説明します。
<script> タグをユーザーフォームに追加したが、ユーザーフォームにアクセスしようとすると次の例外が表示される場合。
java.lang.NoClassDefFoundError: org/mozilla/javascript/NativeScript
WEB-INF/lib/javascript.jar ファイルをアプリケーションサーバーのクラスパスに配備する必要があります。例を示します。
Tomcat をサービスとしてインストールした場合は (Windows のみ)、次のレジストリキーを編集します。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tomcat\Parameters\JVM Option Number 0
JVM Option Number 0 キー文字列値があればどこにあってもその終わりに、jar ファイルへのパスを付けます。例を示します。
;C:\tomcat\lib\javascript.jar
コマンドラインから Tomcat を起動したばかりの場合は、jar ファイルを tomcat/lib ディレクトリに移動します。
タブ付きのユーザーフォームをカスタマイズしたが、User Creation でフォームにアクセスしようとすると、次の例外が表示される場合。
com.waveset.util.WavesetException: Maximum form stack depth exceeded
スタックに転送できるハードコード要素は 1000 までと制限されており、この上限値を超えました。
Field コンテナ名に一致する FieldRef または Field を含む Field コンテナを検出するチェックを追加した場合、気づかないうちに循環参照をフォームに作成してしまった可能性があります。この問題を解決するには、FieldRef または Field 名を変更します。
LDAP ユーザーのフォームに MultiSelect フィールドを使用し、このフィールドのユーザーにグループを割り当て、ユーザーを編集し直してから、両側の MultiSelect に同じグループが表示された場合。例を示します。
左側の値。 cn=Group1,dc=test,dc=Com
右側の値。 cn=Group1,dc=test,dc=com
この例では、LDAP baseContext リソースフィールドが dc=test,dc=com に設定されており、LDAP グループが dc=test,dc=Com としてリストされています。LDAP は大文字と小文字を区別しませんが MultiSelect ウィジェットは大文字と小文字を区別するため、この問題が発生しています。
この問題を多少とも解決するには、LDAP リソースの baseContext を LDAP リソース dc=test,dc=Com の大文字と小文字に合わせて変更するか、<upcase> XPRESS 関数を使用して左側と右側の両方の表示を大文字にします。
Sun Identity Manager Gateway, をトラブルシューティングする際に、ゲートウェイをコマンドラインから実行すると役立つことがよくあります。コマンドラインのオプションを使用すれば、サービスではなく通常のアプリケーションとしてゲートウェイを起動したり、別のポートでゲートウェイを実行したりと、より広範囲の起動オプションが入力できるようになります。
コマンドラインから実行する前に、サービスとしての Identity Manager ゲートウェイを kill しておく必要があります。たとえば、次のように入力します。
gateway.exe -k
ゲートウェイのコマンドライン引数は、次の表のとおりです。
引数 |
説明 |
---|---|
-i |
指定した起動で、このプログラムを NT サービスとしてインストールします。 |
-r |
Service Manager からこのプログラムを削除します。 |
-s |
サービスを開始します。 |
-k |
サービスを強制終了します。 |
-t |
既存サービスに起動を設定します。 |
-d |
通常のアプリケーションとしてデバッグして実行します。 |
-p |
TCP/IP ポート番号 (デフォルトは 9278) を指定します。 |
-f |
トレースファイルへのパスを指定します。 |
-l |
トレースレベルを指定します (デフォルトは 0 で、情報なし)。 |
-m |
トレースファイルの最大サイズを KB 単位で指定します。 |
-v |
バージョンを表示します。 |
用途: gateway -i n -r -s -k -t n -d -p n -f name -l n -m n -v。
-d と -s オプションは、相互に排除的です。
ゲートウェイのトレースレベルの詳細は、「コマンドラインから」を参照してください。
ゲートウェイのトラブルシューティングは、Identity Manager ゲートウェイのデバッグページからも行えます。 (debug/Gateway.jsp )。 詳細は、「「ゲートウェイデバッグ」ページからトレースを設定する方法」を参照してください。
Identity Manager を使用するのに必要な基本的な Java プログラミングのスキルがあれば、ほとんどの Java コード問題を診断して解決できるはずです。
ただし、データベースへの接続を開いてその接続を適切に閉じなかった方がいると、問題が発生することがかなりよくあります。接続を適切に閉じなかった場合、パフォーマンス問題につながります。
ここでは、低位アドレスメモリー状態の調査に使用できる次のツールについて説明します。
Identity Manager のデバッグページにアクセスして操作を実行するには、デバッグ機能が必要です。管理者とコンフィギュレータには、デフォルトでこの機能が割り当てられています。
デバッグ機能がない場合は、エラーメッセージが表示されます。
次の Identity Manager デバッグページを管理者インタフェースから開いて、システムで使用中のメモリー量を監視することができます。
ホスト接続プールページ (debug/Show_ConnectionPools.jsp)。 (データソースを使用していない場合に) 接続プール統計概要を表示します。プールのバージョン、接続の作成回数、アクティブ数、プール内にある接続数、プールから処理された要求数、切断された接続数などがあります。
このホスト接続プールページは、ゲートウェイへの接続管理に使用された接続プールの概要を表示する際にも使用できます。この情報を使用して、低位アドレスメモリー状態を調べられます。
消去されたキャッシュの一覧表示 (debug/Clear_XMLParser_Cache.jsp )。 最近使用した XML パーサーのキャッシュを消去します。
非公開収集プール ( debug/Show_JDBC.jsp)。 リポジトリと一部のリソースアダプタで使用されている Java DataBase Connectivity (JDBCTM) 接続のキャッシュ概要を表示します。
「System Memory Summary」ページ ( debug/Show_Memory.jsp)。 システム内の使用中メモリーと総メモリーを表示します。直前に使用されたメモリー値を取得するには、「Garbage Collect」ボタンをクリックする必要があります。
「System Memory Summary」ページ ( debug/Show_Memory2.jsp)。 更新された Show_Memory.jsp ページを表示します。ここから、ヒープ使用量を調査できるように JVM にある未使用メモリーをすべて消去することができます。
ユーザーセッションプールの消去 ( Clear_User_Cache.jsp)。 最近ログインしたユーザーのキャッシュ済みセッションを消去します。
フラッシュされて消去された XML リソースアダプタキャッシュ (Clear_XMLResourceAdapter_Cache.jsp)。 テスト XML リソースアダプタのキャッシュを消去します。
低位アドレスメモリーとデッドロックを検出するには、Java Monitoring and Management Console (JConsole) を使用します。JConsole とは、Java Management Extension (JMXTM) 技術に対応したグラフィカル管理ツールで、JDK 5 (以降) に同梱されています。
JConsole は、メモリーシステム、メモリープール、MBeans ガベージコレクタにアクセスして、メモリー消費量などのメモリー使用量、メモリープール、およびガベージコレクション統計についての情報を表示します。JConsole を使用すると、現在のヒープメモリー使用とヒープメモリー使用以外を調べるために MBeans を監視することもできます。
Java プラットフォームで実行するアプリケーションを JConsole を使用して監視する方法については、「JConsole を使用したアプリケーションの監視」を参照してください。 このドキュメントは、次の URL から入手できます。
http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html
PasswordSync の問題をトラブルシューティングしようとする際は、次のログを参考までにお読みください。
PasswordSync Error Logs。 PasswordSync はすべての障害情報を Windows イベントビューアに書き込みます。(イベントビューアの詳細は、Windows のヘルプを参照してください。)エラーログエントリのソース名は「PasswordSync」です。
PasswordSync Trace Logs。 PasswordSync はすべてのログを、トレースを設定したときに指定したファイルの場所に書き込みます。「PasswordSync 設定ツールの使用方法」を参照してください。
よくある PasswordSync 問題とソリューションは、次のとおりです。
PasswordSync は、Windows サーバーから Identity Manager へパスワード変更を伝えません。
PasswordSync は、Active Directory から Identity Manager Server への接続を作成したときのレジストリ設定を基にしています。PasswordSync は、レジストリを読み取ってその設定を処理しますが、接続を作成できるかどうかを調べるチェックは一切行いません。
次に、PasswordSync サーバーのレジストリエントリ例を示します。この例では、デフォルトのレジストリ設定値が含まれていますが、PasswordSync が使用したすべての設定が表示されているわけではありません。
[HKEY_LOCAL_MACHINE\SOFTWARE\Waveset\Lighthouse\PasswordSync] "reinitIntervalMilli"=dword:0001d4c0 "securityIgnoreCertRevoke"=dword:00000000 "securityAllowInvalidCert"=dword:00000000 "directMode"=dword:00000001 "lhuser"="config" "lhcred"="rsVtQZpa5Ys=" "endpointURL"="http://10.10.10.10:8080/idm/servlet/PasswordSync" "installdir"="C:\\Program Files\\Sun Microsystems\\Sun Identity Manager PasswordSync" "tracelevel"=dword:00000000 "tracemaxKB"=dword:00002710 "tracefile"="C:\\Program Files\\Sun Microsystems\\Sun Identity Manager PasswordSync\\trace.log" |
適切なレベルのトレースを有効していないと、PasswordSync はあまり詳細な接続障害情報のログを記録しません。詳細なトレース情報の詳細を表示するには、「レジストリキーの編集方法」で説明したとおりに PasswordSync レジストリ設定を編集してください。最大トレース情報を出力するように tracelevel 4 を指定し、tracefile 値を書き込み可能ファイルを指すように変更します。例を示します。
"tracelevel"=dword:00000004 "tracefile"="C:\\Program Files\\Sun\\IdentityManager\\PasswordSync\\pwicsvc.log"
このレジストリ設定は、レジストリの <i>reinitIntervalMilli</i> 設定を基に再読み取りされます。このレジストリ設定の再読み取り後、PasswordSync はレジストリに設定されたトレースパラメータに応じて自動的にトレースを開始したり終了したりします。阻止されたそれぞれのパスワード変更については、PasswordSync がそのパスワードを Identity Manager へ転送するために講じた措置のログを記録します。
作成中に接続障害がある場合は、次の状況が考えられます。
このような状況には、それぞれ独自のエラーコードとログエントリ一式が用意されています。Identity Manager は、省略するためにこれらのエントリから日付、タイムスタンプ、およびプロセス番号を削除します。
不正または到達不能な URL エラー。サーバーが到達できない場合、サーバーが実行中でない場合、またはサーバーが正しい応答で応答しない場合などに起こります。
PasswordSync からサーバーとページにアクセスできることを確認します。
サーバーが実行中であること、ファイアウォールとルーターを正しく設定していることを確認します。
アプリケーションサーバーが実行中であること、アプリケーションパスがなくても PasswordSync がエンドポイント URL に接続できることを確認します。PasswordSync がページもエラーも返さない場合は、アプリケーションサーバーが実行されていません。
エンドポイント URL を標準ブラウザで開いて、サーブレットの応答を確認します。com.waveset.util.WavesetException で始まるエラーが表示されない場合は、サーブレットがコンパイルで使用できるかどうか確認します。
PasswordSync のJMS 使用は、クラスパスで使用可能になっている jms.jar を基にしています。正しいファイルを配備せずにエンドポイント URL にアクセスすると、次の例外メッセージが表示されます。
com.waveset.util.WavesetException: A JMS request arrived, but JMS PasswordSync is unavailable. Is JMS jar file available? |
lhuser エントリに格納されている userID に誤りがあると、不正なユーザー名エラーが発生することがよくあります。ユーザーを置き換えるか lhuser レジストリのキー値を有効な userID と置き換えるには、Configure.exe ユーティリティーを使用します。
不正なパスワードエラーは、lhcred エントリに格納されているパスワードが、userID stored in lhuser に格納されている userID と組み合わせて使用されたときに誤っているとよく起こります。パスワードを置き換えるには、Configure.exe ユーティリティーを使用します。ただし、lhcred レジストリキーは手動で編集しないでください。
パスワードエントリエラーのガベージは、レジストリキーが壊れている場合やレジストリキーが手動で編集されている場合によく起こり、これがパスワードエントリのガベージの原因となります。
この状況によって RAEncryptor::Decrypt3DES 内のプロセスがハングし、PasswordSync がそのエントリを複合化できなくなります。 パスワードを置き換えるには、Configure.exe ユーティリティーを使用してください。
調整タスクの問題をトラブルシューティングしようとする際は、調整ステータスのデバッグページ ( debug/Show_Reconciler.jsp) を見て、どのリソーススレッドが稼動中か調べてください。
よくある調整問題には、次のようなものがあります。
調整が開始されない。
「System Threads」デバッグページ (debug/Show_Threads.jsp ) を開き、Reconcilerserver_name タスクが実行中かどうか調べます。
このタスクが実行中でない場合は、「System Settings」ページを開いて「Trace Scheduler」をクリックします。
スケジューラを実行すると、Reconciler server_name タスクが再起動されます。
「System Threads」ページをもう一度確認します。Reconciler server_name タスクが再起動されていなければ、スケジューラがハングします。
アプリケーションサーバーを再起動します。
あるユーザーオブジェクトで調整が落ちる。
そのオブジェクトが Identity Manager に存在する場合は、そのオブジェクトを直接修正してみます。その Identity Manager アカウントが存在していない場合は、そのリソースからアカウントのどれか 1 つをロードします。
調整ユーザーに適切なアクセス権があることを確認してください。
調整と同じコードパスで、そのオブジェクトをファイルへ展開します。
「System Memory Summary」ページ (debug/Show_Memory.jsp or debug/Show_Memory2.jsp) を開き、十分な空きメモリーがあることを確認します。
接続問題をトラブルシューティングするには、Identity Manager の lh コマンドが非常に有用です。 このコマンドは Identity Manager の Web アプリケーションインストールを使用しますが、等式からそのアプリケーションサーバーを削除します。
ここでは、次の項目について説明します。
ここでは、lh コマンドの使用方法について説明します。基本的なコマンドから始めて、Identity Manager の大部分を実行できるようなコマンドの使用方法まで進んでいきます。
これらのデバッグツールに慣れると、これらの lh コマンドを使用するのに独自のバリエーションが展開できるようになります。
一番基本的な接続テストを実行するには、lh setRepo -c -n コマンドを使用します。これで、現在のリポジトリの場所を接続しなくても調べられるようになります。Uこのコマンドを使用すると、RL や JDBC ドライバなどのパラメータが正しいかどうか検証できます。
正常に接続している場合は、ServerRepository.xml ブートストラップファイルを読みます。
接続障害がある場合は、この障害を先に解決してみます。この障害の原因は、複合化エラーによくあります。たとえば、J2EE 不一致やクラスパスの競合があることが考えられます。
現リポジトリの場所に 接続して調べるには、lh setRepo -c -v コマンドを使用します。(-v は、冗長出力を表示します。) このコマンドを使用すると、Identity Manager サーバーを必要とせずに、ほぼすべてのリポジトリコードが実行できます。
正常に接続している場合は、現リポジトリの場所に正常に接続します。
接続障害がある場合は、この問題を先に解決してみます。この接続問題を解決すると、DNS、ファイアウォール、リモート接続権限問題を解決するのに役立ちます。
詳細は、「DataSource 接続のテスト」を参照してください。
新しいリポジトリの場所を指定したり、リポジトリを同じ場所に設定するには、setRepo コマンドをデバッグプロセス全体にわたって使用します。
このコマンドを使用すると、JAR ファイルなど必要なコンポーネントがすべて所定の位置にあるか確認できます。setRepo コマンドはまた、テーブルの所有者や権限問題をデバッグするのに userid や password などの接続情報を変えられます。
WEB-INF/lib 内の JAR ファイルと、WSHOME の下にある WEB-INF/classes 内のクラスを使用している Identity Manager サーバーを実際に起動するには、このコマンドを使用します。lh console コマンドは、Identity Manager インストール環境を使用して、実際に Identity Manager アプリケーションを起動しますが、等式からアプリケーションサーバーを削除します。
正常に接続した場合、この問題はアプリケーションサーバー環境か設定に固有のものです。
接続障害が発生した場合は、障害メッセージをレビューします。
接続障害がアプリケーションサーバー障害と同じ場合は、これまでよりずっと変数を減らしてみてもこの問題が再現するはずです。
アプリケーションサーバー障害と違う障害が発生する場合は、こちらの方が変数が少なく、Identity Manager コントロール下により多くの変数があるため、Identity Manager 接続問題を先に解決してみます。
DataSource 接続をテストしていると、lh setRepo -c コマンドが失敗することがあります。
この障害は、アプリケーションサーバーのデータベース接続サービスやアプリケーションサーバーのディレクトリサービスを使用できるように Identity Manager を設定していると特に起こりやすくなります。このサービスは、実行中のアプリケーションサーバーが Web アプリケーションに提供している環境でのみ機能します。
まず、目的の DataSource 設定から手順を追いながら取り掛かります。この手順に慣れたら、自分の目的に合うようにこの方法を改変することができます。
アプリケーションサーバーのデータベース接続サービスを省略する DataSource 以外の接続など、直接 JDBC DriverManager 接続を使用してみてください。
DataSource を使用しますが、アプリケーションサーバーのディレクトリサービス以外の ディレクトリサービスにある DataSource オブジェクトを格納します。
ほかに使用可能なディレクトリサービスがない場合は、ローカルファイルシステムのみを使用する JNDI の参照実装など、フリーのディレクトリサービスをダウンロードすることができます。
これがうまくいったら、アプリケーションサーバーへの問題を突き止められます。
次に、有用であれば、アプリケーションサーバーのデータベース接続サービスまたはアプリケーションサーバのディレクトリサービスを追加することもできます。アプリケーションサーバーが Web アプリケーションに提供する環境外で機能しているサービスであればどちらでもかまいません。
アプリケーションサーバーのログを解析して、致命的なエラーとその他サーバー関連の問題がないか調べることができます。
サーバー問題をトラブルシューティングするには、アプリケーションサーバーの管理者コンソールを使用して、各モジュールのログレベルを高めます。詳細は、サーバーに付属している製品マニュアルを参照してください。
ほとんどのアプリケーションサーバーには、アプリケーションサーバーを実行する JVM の 標準出力ファイル (stdout) と標準エラーファイル (stderr) に標準の場所があります。アプリケーションサーバーログを解析するには、Identity Manager アプリケーションサーバーに指定したこのログディレクトリまたはログファイルを見つけます。
軽度のメッセージとその他トレースを表示するには、stdout ファイルを開きます。
致命的な例外と重大な例外を表示するには、stderr ファイルを開きます。
このトレース出力には、Identity Manager の起動とシャットダウンメッセージが表示されます。
Identity Manager Version 7.1, 以降、Oracle 10g on Sun Application Server Enterprise Edition 8.2 を搭載した Identity Manager を使用したときに、シーリング違反の例外がアプリケーションサーバーログに発生するようになりました。
この例外は、Oracle JDBC ドライバを備えた複数の Java Archive file (JAR ファイル) を使用した場合によく起こります。
この問題を防ぐには、CLASSPATH に JDBC ドライバ JAR ファイルが 1 つしかないこと、 Oracle 10g に用意されている ojdbc14_g.jar を使用していることを確認します。さらに、確実に正しく処理できるよう、Oracle 10g インストールに用意されている ojdbc14_g.jar だけを使用してください。
WebSphere の Identity Manager Service Provider 「エンドユーザーログイン」ページを使用し、javax.servlet.UnavailableException が 404 エラーとともにブラウザに表示された場合は、IBM 1.5 JDK のプロパティーをいくつかリセットする必要があります。
次の手順を使用します。
was-install/java/jre/lib ディレクトリで、jaxb.properties.sample を jax.properties に変え、この 2 行のコメントを解除します。
javax.xml.parsers.SAXParserFactory= org.apache.xerces.jaxp.SAXParserFactoryImpl javax.xml.parsers.DocumentBuilderFactory= org.apache.xerces.jaxp.DocumentBuilderFactoryImpl |
ファイルを保存してアプリケーションサーバーを再起動します。
SPML 設定をテストする
「接続」ページを開き、「テスト」をクリックします。
正常に接続しましたというダイアログがポップアップします。
「スキーマ」ページを開き、「送信」をクリックします。
Identity Manager サーバーでサポートされているスキーマの階層ビューが表示されます。
正常な接続を確立できない場合は、次の操作を行います。
入力した URL をダブルクリックします。
受信したエラーに no response や connection refused といったフレーズが含まれている場合は、接続 URL で使用されているホストかポートに問題があると考えられます。
接続は確率したが、Web アプリケーションかサーブレットが見つからなかったというエラーの場合は、WEB-INF/web.xml ファイルに問題があると考えられます。
アップグレード中に問題が発生した場合は、$WSHOME/patches/ logs でぃれくとりにあるアップグレードログファイルを確認します。このログのファイル名は、タイムスタンプとアップグレードのステージに基づいています。
アップグレード後、Identity Manager が次の例外で起動できない場合は、使用中の JDK/JRE に問題がある可能性があります。
java.lang.IllegalStateException: Error attempting to decrypt: Given final block not properly padded |
以前使用していたベンダーと同じベンダー製の JDK/JRE を使用していることを確認します。たとえば、以前 IBM 製の JDK を使用していた場合は、Sun JDK にアップグレードできません。この問題を解決するには、JDK/JRE をアンインストールして、以前のベンダー製の JDK または JRE をインストールします。