| Oracle® Fusion Middleware Oracle Identity Governanceの管理 12c (12.2.1.3.3) E88285-04 |
|
 前 |
 次 |
この章では、Oracle Enterprise Managerを使用してOracle Identity Managerを構成する行う方法について説明します。内容は次のとおりです。
Oracle Identity Managerは構成ファイルをMDSに格納します。ほとんどの構成はMBeanとして公開されます。そのため、Oracle Enterprise Managerを使用して構成値を制御できます。場合によっては、ファイル一式をファイル・システムにエクスポートし、必要な変更を行い、それからリポジトリにインポートして戻す必要があります。
この項の内容は次のとおりです。
構成ファイルを変更するには、既存の構成ファイルを外部ファイル・システムにエクスポートし、必要な変更を加えるためにファイルを編集し、新たに編集したファイルをリポジトリにインポートして戻します。
構成ファイルをエクスポートまたはインポートするには:
管理サーバーと少なくとも1つのOracle Identity Manager管理対象サーバーが稼動している場合は、次の形式のURLを使用してOracle Enterprise Manager Fusion Middleware Controlにログインします。
http://ADMINSTRATION_SERVER:PORT/em
「アイデンティティ」→「アクセス」→「OIM」に移動します。右クリックして「システムMBeanブラウザ」に移動します。
「アプリケーション定義のMBeans」で、「oracle.mds.lcm」→「サーバー:oim_server1」→「アプリケーション:OIMMetadata」→「MDSAppRuntime」に移動します。
構成ファイルをエクスポートするには:
「操作」タブをクリックし、次にexportMetaDataをクリックします。
toLocationフィールドに、 /tmpまたは別のディレクトリの名前を入力します。
createSubDirにfalseを選択します。
docsフィールドに、完全なファイルの場所を要素として入力します。
excludeAllCust、excludeBaseDocs、excludeExtendedMetadataに対してもfalseを選択します。次に「起動」をクリックします。
これで、docsフィールドで指定されたファイルがtoLocationフィールドで指定されたディレクトリにエクスポートされます。
構成ファイルをインポートするには:
「importMetaData」をクリックします。
fromLocationフィールドに、/tmpまたは構成ファイルを含むディレクトリの名前を入力します。
createSubDirにfalseを選択します。
docsフィールドに、完全なファイルの場所を要素として入力します。たとえば/db/oim-config.xmlのようにします。
excludeAllCust、excludeBaseDocs、excludeExtendedMetadataに対してもfalseを選択します。次に「起動」をクリックします。
これで、docsフィールドで指定されたファイルがtoLocation フィールドで指定されたMDSにインポートされます。
OrchestrationEngine MBeanの使用には、OrchestrationEngine Mbeanへのアクセス、MBeanによってサポートされる操作、および操作失敗の診断が含まれます。
Oracle Enterprise Managerに用意されているOrchestrationEngine MBeanを使用して、編成エンジンを管理できます。この項では、MBeanとその様々な操作およびパラメータについて説明します。次の項目が含まれます。
Oracle Enterprise Managerにログインし、システムMBeanブラウザを開き、「アプリケーション定義のMBean」の下にOrchestrationEngine MBeanのMBean情報を表示します。
OrchestrationEngine MBeanにアクセスするには:
OrchestrationEngine MBeanでは、dump、findEventHandlers、findEventsForProcess、findOperationsなど、様々な操作がサポートされます。
表26-1に、OrchestrationEngine MBeanによってサポートされる操作をリストします。
表26-1 OrchestrationEngineによってサポートされる操作
| 操作 | 説明 |
|---|---|
dump |
この操作は、完全な編成をコンソールまたはファイルにダンプします。コンソールでは、サイズ制限のために3から5を超える編成を出力できないため、ファイル・システムを使用する必要があります。 ダンプするプロセスの数が多い場合、サーバーに負荷がかかる可能性があるため、チャンク内のデータをダンプするためにページングを使用する必要があります。ページングを使用してデータを単一のファイルにダンプする場合は、appendFileパラメータをtrueに設定し、ページ・ダンプがファイルに追加されるようにします。それ以外の場合、ページ・ダンプごとに個別のファイルを使用します。 |
familyTree |
この操作は、IDがパラメータとして提供されるプロセスのファミリ・ツリー全体を戻します。ファミリには、子、兄弟、および親がnレベルまで含まれます。
|
findEventHandlers |
この操作は、エンティティ・タイプと操作の特定の組合せに対してサポートされているイベント・ハンドラのリストを戻します。 この操作のパラメータでは大文字と小文字が区別されます。このため、いくつかのカスタム・ハンドラを定義する場合、これらの値は大文字と小文字を区別して使用されるため、その区別が正しければデバッグがしやすくなります。 すべてのハンドラは実行の順序で戻されます。 |
findEventsForProcess |
この操作は、IDまたは名前(あるいはその両方)が提供されているプロセスのコンテキスト/フローで適用できるイベントの実際のリストを戻します。 ハンドラは実行の順序で戻されます。 ハンドラのリストは、エンティティ・タイプおよび操作の完全なハンドラ・リストではありません。 |
findOperations |
この操作は、1つのエンティティ・タイプに対して構成されているすべての操作のリストを戻します。 パラメータが指定されていない場合は、すべてのエンティティ操作にわたる操作の完全なリストを戻します。 |
findProcess |
この操作は、渡されたパスワードに基づいて基準を満たすプロセスのリストを戻します。 検索がIDベースでない場合、コールの負荷が大きいため、
パラメータ値が指定されていない場合、データベースに保存されているすべてのプロセスが戻されますが、この数は大きくなる可能性があります。 |
listEntityTypes |
この操作は、Oracle Identity Managerのエンティティ・タイプのリストを戻します。 |
Oracle Identity Managerの様々なエンティティに対して行われる操作のほとんどは、編成エンジンを介して行われます。編成エンジンを基礎として使用するエンティティ・タイプのリストは、OrchestrationEngine Mbeanに対するlistEntityTypes操作を介して取得できます。
ログ・ファイルには、すべての操作のエンドツーエンドの詳細なフローが記録されます。デバッグを目的として、oracle.iam.platform.kernelロガーのロギング・レベルをINFOまたはFINEに設定することにより、より精度の高い詳細を取得できます。
編成がデータベース内でシリアル化されるのは、これらが完了ステータスになっていない場合のみです。このようなステータスになる可能性があるのは、障害が発生した場合や、別のスレッドが処理を再開するのを待機している場合などです。
編成プロセスの処理が不完全になる原因(これには様々な理由が考えられます)を把握するには、ログを参照するか、ログから取得できる編成プロセスIDを使用して、OrchestrationEngine Mbeanの詳細を取得します。
注意:
編成プロセスIDは、LONG型のIDと文字列型のNameという2つのフィールドの一意の組合せです。これら2つのいずれかをMbean操作に指定して結果を取得できます。これら両方を指定して正確に一致するレコードを取得できます。
編成プロセスIDは、次の方法で取得できます。
ログ・ファイルから
リコンシリエーション・フローのEventDiagnostic Mbean (oracle.iam:Location=oim_server1,name=EventDiagnostic,type=Reconciliation,Application=oim)のgetOrchestrationIds操作から
リクエストIDを指定してRequestDiagnostic MBean (oracle.iam:Location=oim_server1,name=RequestDiagnosticMXBean,type=IAMAppRuntimeMBean,Application=oim)のprocessInfo操作から、またはリクエスト・フローのリクエスト表のorchestration_process_id列から
指定した基準に基づいて不完全な編成のデータベース内を検索するOrchestrationEngine MBeanのfindProcess操作を使用して
注意:
特定のプロセスIDを検索するためのMBeanのfindProcess操作で何も戻されない場合、指定したIDが正しくないか、特定のプロセスが正常に完了してデータベース内に存在しないことを意味します。このようなプロセスIDに関する情報はログ・ファイル内でのみ参照できます。
編成エンジンを使用して操作の失敗を診断するには、プロセスの内部詳細を有効化し、findEventsForProcess操作の後にdump操作を呼び出し、親と子の編成のためにfamilyTree操作を呼び出します。
プロセスIDが見つかったら、次の手順を実行し、操作の失敗を診断します。
MBeanのfindProcessを起動し、プロセスIDを渡し、detailedパラメータをtrueとして設定します。これにより、プロセスの内部詳細がすべて示されます。
MBeanのfindEventsForProcess操作を起動し、関連するハンドラの詳細を実行順に取得します。
MBeanのdump操作を起動し、完全なプロセスをコンソールまたはファイルにダンプします。プロセスIDおよびファイル名をファイルにダンプする必要がある場合は、これらを渡します。
OrchestrationEngine MBeanのfamilyTree操作を起動すると、nレベルまでの親と子の編成が関連する複雑な事例を完全に追跡できます。
プロセスIDが見つからない場合は、MBeanに指定されているパラメータに基づいて、MBeanのダンプ操作を使用して複数の編成を1つのファイルにダンプできます。このダンプ・ファイルとともにログ・ファイルを使用することにより、様々な問題の原因を理解しやすくなります。これらのファイルは、サービス・リクエストの一環としてOracleサポートに提供することもできます。
Oracle Identity Managerでは、2つのロギング・サービス、大多数のOracle Fusion Middlewareアプリケーションで使用されるロギング・サービスOracle Diagnostic Logging (ODL)とApache log4jが使用されます。
Oracle Identity Managerのロギングは、主としてODLを使用して行われます。Apache log4jは、デプロイメント・マネージャやワークフロー・デザイナでのNexaweb、キャッシングでのOSCacheなど、サードパーティ・アプリケーションでのみ使用されます。
この項の内容は次のとおりです。
ODLを使用してロギングするには、メッセージのタイプとレベル、ログ・ハンドラおよびロギング構成を理解し、ロガーとログ・ハンドらを構成し、ジョブを起動して停止します。
この項では、ODLを使用してOracle Identity Managerで生成されるログについて説明します。内容は次のとおりです。
Oracle Diagnostic Logging (ODL)は、Oracle Identity Managerが使用する主要なロギング・サービスです。ODLロギングを動作させるには、ロガーとログ・ハンドラの両方を構成する必要があります。ロガーはハンドラにメッセージを送信し、ハンドラはメッセージを受け入れてログ・ファイルに出力します。
「ログ・ハンドラとロガーの構成」で説明しているように、ロギング構成はlogging.xmlファイルによって制御されます。このファイルは、直接編集することも、Enterprise Managerを介して編集することもできます。Enterprise Managerでは、OIMサーバー・リンクをクリックして上部のWebLogic Serverドロップダウンを選択し、「ログ」→「ログ構成」をクリックしてロギング構成にアクセスできます。
Enterprise Managerでロギング構成にアクセスするには、次の手順を実行します。
OIMサーバー・リンクをクリックします。
WebLogic Serverのリストから、「ログ」→「ログ構成」を選択します。ログ構成画面に、ロギングに利用できるすべてのパッケージが表示されます。
Enterprise Managerで利用できない追加パッケージ(コネクタのためのパッケージなど)のロギングは、次の指示に従ってlogging.xmlファイルを手動で編集します。Oracle Identity Manager固有のパッケージには、oracle.iamからアクセスできます。Oracle Diagnostic Loggingレベル列で、各ログ・レベルを選択できます。特定のログ・レベルを選択し、「適用」をクリックして変更を適用します。また、「ログ・ファイル」タブをクリックして、新しいログ・ハンドラを作成して構成することもできます。
Oracle Identity Managerの各モジュールには、個別に構成できる独自のロガーがあり、それぞれ異なる情報量を1つ以上のログ・ハンドラに送信できます。表26-3に、ログ・ハンドラへのメッセージ送信を構成できるOracle Identity Managerの20種類以上のロガーを示します。
ログに出力する情報量は、各ロガーのレベル属性を調整して制御できます。ロギング・レベルを選択するには、5つのメッセージ・タイプ(INCIDENT_ERROR、ERROR、WARNING、NOTIFICATION、TRACE)からいずれか1つを選びます。各メッセージ・タイプで1(最高重大度) - 32(最低重大度)の数値を使用して、ロガーで出力されるメッセージ量をさらに制限することもできます。2ページの表1に、最もよく使用されるメッセージ・タイプとレベルの組合せを示します。
ログ・ハンドラは、ログ・メッセージを表示するターゲットを指定します。たとえば、コンソール、各種ログ・ファイルおよび追加の出力にメッセージを書き込むことができます。
ODLでは、INCIDENT_ERROR、ERROR、WARNING、NOTIFICATION、TRACEの5つのメッセージ・タイプを認識します。各メッセージ・タイプで1(最高重大度) - 32(最低重大度)の数値を使用して、メッセージ出力をさらに制限することもできます。
メッセージ・タイプを指定すると、ODLではそのタイプのすべてのメッセージと、指定したタイプ以上の重大度のメッセージが返されます。たとえば、メッセージ・タイプをWARNINGに設定した場合、ODLではINCIDENT_ERRORとERRORのタイプのメッセージも返されます。
メッセージのタイプとレベルの詳細は、管理者ガイドのログ・ファイルに書き込まれる情報レベルの設定に関する項を参照してください。表26-2に、Oracle Identity Managerで最もよく使用される診断メッセージのタイプを示します。
表26-2 Oracle Identity Managerの診断メッセージのタイプ
| メッセージ・タイプおよび数値 | 説明 |
|---|---|
INCIDENT_ERROR:1 |
製品のbugが原因の可能性があり、Oracleサポートに報告する必要がある重大な問題。 この例として、回復不能なエラーがあります。 |
ERROR:1 |
管理者がただちに対処する必要があり、製品のbug以外が原因の重大な問題。 この例として、Oracle Fusion Middlewareがログ・ファイルを処理できないものの、ドキュメントに対する権限の調整によって問題の修正が可能な場合などがあります。 |
WARNING:1 |
管理者による確認を要する、潜在的な問題。 この例としては、パラメータ値が無効な場合や指定したファイルが存在しない場合などがあります。 |
NOTIFICATION:1 |
プライマリ・サブコンポーネントや機能のアクティブ化や非アクティブ化などの主要なライフサイクル・イベント。 これはNOTIFICATIONのデフォルト・レベルです。 |
NOTIFICATION:16 |
通常のイベントをレポートする粒度の詳細なレベル。 |
TRACE:1 |
パブリックAPIエントリや終了ポイントなど、管理者に重要なイベントに関するトレースまたはデバッグ情報。 |
TRACE:16 |
詳細なトレースまたはデバッグ情報で、Oracleサポートによる特定のサブシステムの問題診断に有益なもの。 |
TRACE:32 |
非常に詳細なトレースまたはデバッグ情報で、Oracleサポートによる特定のサブシステムの問題診断に有益なもの。 |
ログ・ハンドラとロガーはどちらもlogging.xmlを編集して構成できます。このファイルは次の場所に格納されています。
DOMAIN_NAME/config/fmwconfig/servers/SERVER_NAME/logging.xml
ここで、DOMAIN_NAMEとSERVER_NAMEは、それぞれOracle Identity Managerのインストール時に指定されたドメイン名とサーバー名です。
logging.xmlファイルには<log_handlers>構成セクションがあり、その下に<loggers>構成セクションが続きます。各ログ・ハンドラを、<log_handlers>セクションで定義し、各ロガーを<loggers>セクションで定義します。
ファイルの基本構造は次のとおりです。
<logging configuration>
<log_handlers>
<log_handler name='console-handler' level="NOTIFICATION:16"></log_handler>
<log_handler name='odl-handler'></log_handler>
<!--Additional log_handler elements defined here....-->
</log_handlers>
<loggers>
<logger name="example.logger.one" level="NOTIFICATION:16">
<handler name="console-handler"/>
</logger>
<logger name="example.logger.two" />
<logger name="example.logger.three" />
<!--Additional logger elements defined here....-->
</loggers>
</logging_configuration>
メッセージをコンソールかファイルのどちらかに書き込むようにロガーを構成する場合は、ロガーとハンドラの両方の構成変更を行います。ロガーでのレベル属性の設定は、ロガーがハンドラに送信する詳細の量(つまりメッセージ量)を構成します。同様に、ハンドラでのレベル属性の設定は、ハンドラがロガーから受け入れる詳細の量を構成します。
注意:
ログに期待する量のメッセージが出力されない場合は、ロガーとログ・ハンドラのレベル属性が適切に設定されているか確認してください。たとえば、ロガーがTRACEに設定され、ログ・ハンドラがWARNに設定されている場合、ハンドラはWARNより詳細なメッセージは生成しません。
個々のログ・ハンドラは、logging.xmlファイルの<log_handlers>セクションで構成されます。ハンドラのレベル属性を構成して、ハンドラがロガーから受け入れる詳細の量を設定します。
ログ・ハンドラのレベル属性を構成するには:
注意:
logging.xmlファイルを修正するには、XML構文の基本を理解している必要があります。
ファイルに書き込むログ・ハンドラには、構成可能な追加プロパティがあります。たとえば、次に示すlogging.xmlからの抜粋では、odl-handlerが構成されています。
<log_handler name='odl-handler' class='oracle.core.ojdl.logging.ODLHandlerFactory' filter='oracle.dfw.incident.IncidentDetectionLogFilter'>
<property name='path' value='${domain.home}/servers/${weblogic.Name}/logs/${weblogic.Name}-diagnostic.log'/>
<property name='maxFileSize' value='10485760'/>
<property name='maxLogSize' value='104857600'/>
<property name='encoding' value='UTF-8'/>
<property name='useThreadName' value='true'/>
<property name='supplementalAttributes' value='J2EE_APP.name,J2EE_MODULE.name, WEBSERVICE.name,WEBSERVICE_PORT.name,composite_instance_id,component_instance_id, composite_name,component_name'/>
</log_handler>
ログ・ハンドラのプロパティは、Fusion Middleware ControlツールまたはWLSTコマンド行ツールを使用して変更できます。
関連項目:
Fusion Middleware ControlツールおよびWLSTコマンド行ツールの詳細は、管理者ガイドのログ・ファイルの設定の構成に関する項を参照してください。
WLSTコマンド行ツールの詳細は、WebLogic Scripting Toolコマンド・リファレンスのカスタムWLSTコマンドのロギングに関する項を参照してください。
各ログ・ハンドラは、logging.xmlファイルの<loggers>セクションで構成されます。ログ・ハンドラにメッセージを送信するために構成できる、20種類を超えるOracle Identity Managerのロガーがあります。Oracle Identity Managerのロガーについては、7ページの表2で説明されています。ロガーのレベル属性の設定で、ロガーがハンドラに送信する詳細の量(つまりメッセージ量)が構成されます。1つ以上の<handler>要素を<logger>要素内にネストすると、ロガーにハンドラが割り当てられます。OIMCP.PSFTCOMMONと呼ばれるロガーを次の抜粋に示します。level属性にはWARNING:32が設定され、ロガーによって3つのハンドラにメッセージが送信されます。
<logger name="OIMCP.PSFTCOMMON" level="WARNING:32" useParentHandlers="false"> <handler name="odl-handler"/> <handler name="wls-domain"/> <handler name="console-handler"/> </logger>
ロガーは、親のレベル設定やその他の属性、親のロガーのハンドラなど、親のロガーの設定を継承します。継承を無効にするには、前述の抜粋に示すように、useParentHandlers属性を「false」に設定します。
ロガーの継承ツリーの最上部にあるのがルート・ロガーです。ルート・ロガーは、次の例に示すように、名前属性が空のロガーです。
<loggers>
<logger name="" level="WARNING:1">
<handler name="odl-handler"/>
<handler name="wls-domain"/>
<handler name="console-handler"/>
</logger>
<!-- Additional loggers listed here -->
</loggers>
次の例に示すように、ロガーを名前属性のみで構成すると、ロガーは残りの属性をルート・ロガーから継承します。
<loggers>
<logger name="oracle.iam.identity.rolemgmt"/>
<!-- Additional loggers listed here -->
</loggers>
次のODLログの抜粋は、想定される出力例を示しています。
<Jun 15, 2010 2:01:20 AM IST> <Error> <oracle.iam.platform.authz.impl> <IAM-1010032> <No OES Policy found for the given Action.> <Jun 15, 2010 2:02:02 AM IST> <Warning> <oracle.iam.platform.canonic.agentry> <IAM-0091108> <readme.txt is not a valid connector resource file.> <Jun 15, 2010 2:02:52 AM IST> <Error> <oracle.iam.configservice.impl> <IAM-3020003> <The attribute User Type does not exist!>
ログ出力の管理および解釈の詳細は、管理者ガイドのログ・ファイルと診断データの管理に関する項を参照してください。
Apachelog4jは、Nexawebやキャッシング用のOSCacheなどのサードパーティ製アプリケーションで使用されます。
log4j構成ファイルは次の場所に格納されています。
OIM_HOME/config/log.properties
log4jを使用したOracle Identity Managerでのロギングについて、次の各項で説明します。
表26-4に、log4jのログ・レベルのリストを示します。
表26-4 log4jのログ・レベル
| ログ・レベル | 説明 |
|---|---|
DEBUG |
DEBUGレベルは、アプリケーションのデバッグに役立つ詳細な情報イベントを示します。 |
INFO |
INFOレベルは、アプリケーションの進捗状況を大まかなレベルで強調表示する情報メッセージを示します。 |
WARN |
WARNレベルは、危険な状況になる可能性のあることを示します。 |
ERROR |
ERRORレベルは、アプリケーションの続行が可能なエラー・イベントを示します。 |
ALL |
ALLレベルは下限ランクで、すべてのロギングが有効化されます。 |
OFF |
OFFレベルは上限ランクで、ロギングは無効化されます。 |
サードパーティのアプリケーションには、次のロガーが使用されます。
Nexawebの場合: com.nexaweb.server
OSCacheの場合: com.opensymphony.oscache
Oracle Identity Managerサーバーの警告状態を設定するには、すべてのOIM JMSキューの再配信制限を1に設定し、すべての不正なメッセージをパージして、サーバーを再起動します。
Oracle Identity Managerサーバーの警告状態を設定するには:
すべてのOIM JMSキューで再配信の制限を1に設定します。これを行うには、次のようにします。
WebLogic管理コンソールに管理ユーザーとしてログインします。
「JMSモジュール」をホーム・ページでクリックします。
「OIMJMSModule」をクリックします。
「ロックして編集」をクリックします。
各キューで、キューをクリックしてから、「配信の失敗」タブをクリックします。「再配信の制限」値を-1から1に変更してから、「保存」をクリックします。
OIMJMSModuleにあるすべてのキューで手順1.dと手順1.eを実行したことを確認します。
構成をリリースしてから、Oracle Identity Managerを再起動します。
この再配信は既存のメッセージに適用されません。サーバーが再起動した際、すべての良好なメッセージが処理されるのを待機します。その後で、すべての不正なメッセージを消去する必要があります。
すべての不正なメッセージを消去するには:
WebLogic管理コンソールに管理ユーザーとしてログインします。
「JMSサーバー」をホーム・ページでクリックします。
OIMJMSServer→「モニタリング」→「アクティブな宛先」に移動します。
メッセージを含むキューを選択します。「消費」→「休止」をクリックします。
次のURLに示すように、メッセージを削除します。
メッセージが削除されたら、手順2.dで休止している消費を再開します。
Oracle Identity Managerを再起動します。
