| Oracle® Fusion Middleware Oracle Unified Directory管理者ガイド 11g リリース2 (11.1.2) B72794-02 |
|
 前 |
 次 |
Oracle Unified Directoryでは拡張可能な監視フレームワークが提供されます。この章では、監視機能の概要と、監視の構成方法を説明します。監視フレームワークが構成されると、サーバー・インスタンスの統計またはレプリケートされたトポロジを表示できます。
この章では、次のトピックを取り扱います:
監視情報およびパフォーマンス・データは、次の場所にあります:
ログ
ログの構成の詳細は、第29.3項「ログの構成」を参照してください。
アラート
アラートの構成の詳細は、第29.4項「アラートおよびアカウント・ステータス通知ハンドラの構成」を参照してください。
cn=monitor
cn=monitorの詳細は、第29.5項「LDAPを使用したサーバーの監視」を参照してください。
RFC 2605で定義されているDIRECTORY_SERVER_MIB
SNMPを使用したサーバーの監視の詳細は、第29.6項「SNMPを使用したサーバーの監視」を参照してください。
監視情報にアクセスするには、必要なプロトコルを持っていることを確認します:
ログの場合、ファイル・システムが必要です。
アラートの場合、JMX:RMIまたはSMTPが必要です。
cn=monitorの場合、LDAPまたはJMX:RMI (たとえばjconsole)が必要です。
DIRECTORY_SERVER_MIBの場合、SNMPが必要です。
監視プロバイダは、デフォルトで有効になっており、監視目的またはトラブルシューティング目的で役に立つサーバーの情報を提供します。cn=monitorエントリには、監視プロバイダによって公開される監視情報が含まれています。監視プロバイダが無効になっていると、提供される情報をcn=monitorの下で使用できなくなります。
監視プロバイダは、dsconfigコマンドを使用して構成できます。詳細は、第14.1項「dsconfigを使用したサーバー構成の管理」を参照してください。
次に示すように、dsconfigコマンドをlist-monitor-providersサブコマンドとともに実行します:
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ list-monitor-providers Monitor Provider : Type : enabled -------------------:-------------------:-------- Client Connections : client-connection : true Entry Caches : entry-cache : true JVM Memory Usage : memory-usage : true JVM Stack Trace : stack-trace : true System Info : system-info : true Version : version : true
次に示すように、dsconfigコマンドをset-monitor-provider-propとともに実行します:
たとえば、JVM Stack Trace監視プロバイダをfalseに設定するには、次のコマンドを使用します:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ set-monitor-provider-prop --provider-name "JVM Stack Trace" \ --set enabled:false
ここでdsconfigコマンドをlist-monitor-providersサブコマンドとともに実行すると、JVM Stack Trace監視プロバイダがfalseとして表示されます:
Monitor Provider : Type : enabled -------------------:-------------------:-------- Client Connections : client-connection : true Entry Caches : entry-cache : true JVM Memory Usage : memory-usage : true JVM Stack Trace : stack-trace : false System Info : system-info : true Version : version : true
Oracle Unified Directoryでは、アクセス・ログ、監査ログ、エラー・ログ、デバッグ・ログ、レプリケーション修復ログなど、様々なタイプのログが提供されます。レプリケーション修復ログは読取り専用であり、レプリケーションの競合解決を有効にする場合のみ使用できます。次の各項では、dsconfigコマンドライン・インタフェースまたはOracle Directory Services Managerを使用して、アクセス・ログ、監査ログ、エラー・ログおよびデバッグ・ログを構成する方法を説明します。また、この項では、管理操作のログ方法も説明します。
ログの結果コードの詳細は、第D.17.11項「結果コード」を参照してください。
この項には次のトピックが含まれます:
dsconfigを使用してロギングを構成する最も簡単な方法は、このコマンドを対話モードで使用して、構成に導いてもらうことです。この項では、非対話モードで必要なコマンドを示し、設定される特定のパラメータがわかるようにします。dsconfigの詳細は、第14.1項「dsconfigを使用したサーバー構成の管理」を参照してください。
ログ構成には、次の3つの構成オブジェクトの定義が含まれています:
ログ・パブリッシャ。ログ・パブリッシャは、各ロガーに対して定義されます。ログ・パブリッシャのタイプは、ログのタイプに対応します。ログ・パブリッシャの詳細は、第29.3.1.1項「ログ・パブリッシャの構成」を参照してください。
ログ保存ポリシー。保存ポリシーによって、アーカイブされたログ・ファイルの格納期間が決まります。ログ保存ポリシーの詳細は、第29.3.1.2項「ログ保存ポリシーの構成」を参照してください。
ログ・ローテーション・ポリシー。ローテーション・ポリシーによって、ログ・ファイルのローテーション頻度が決まります。ログ・ローテーション・ポリシーの詳細は、第29.3.1.3項「ログ・ローテーション・ポリシーの構成」を参照してください。
Oracle Unified Directoryは、デフォルトでいくつかのログ・パブリッシャを提供します。
任意のタイプのログ・パブリッシャを任意の数定義して、いつでもアクティブにできます。つまり、様々な場所または様々なタイプのリポジトリにログでき、ログに含めるものに関して様々な条件セットを指定できます。
ログ・パブリッシャに関連付けられた構成プロパティの詳細は、Oracle Unified Directory構成リファレンスを参照してください。
この項の内容は次のとおりです:
既存のログ・パブリッシャを表示するには、次のdsconfigコマンドを実行します:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ list-log-publishers
デフォルトの出力は、次のようなものです:
Log Publisher : Type : enabled -------------------------------:-------------------:-------- File-Based Access Logger : file-based-access : true File-Based Admin Access Logger : file-based-access : true File-Based Audit Logger : file-based-access : false File-Based Debug Logger : file-based-debug : false File-Based Error Logger : file-based-error : true Oracle Access Logger : file-based-access : false Oracle Error Logger : file-based-error : false Replication Repair Logger : file-based-error : true
ログ・パブリッシャのプロパティを表示するには、次のdsconfigコマンドを実行します:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ get-log-publisher-prop --publisher-name "File-Based Error Logger"
すべてのログ・パブリッシャがデフォルトで有効になっているわけではありません。ログ・パブリッシャが無効になっている場合、そのタイプのメッセージはログされません。
ログ・パブリッシャを有効にするには、そのenabledプロパティをtrueに設定します。たとえば、監査ロガーを有効にするには、次のコマンドを実行します:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ set-log-publisher-prop --publisher-name "File-Based Audit Logger" \ --set enabled:true
ログ・パブリッシャが有効になると、サーバーは、適切なパブリッシャへのメッセージのロギングをすぐに開始します。この変更を有効にするためにサーバーを再起動する必要はありません。
Oracle Unified Directoryは、診断ログ・ファイルのOracle Diagnostic Logging形式(ODL)での書込みも実行します。
デフォルトではODLは無効になっています。ODLを有効にするには、ODL Access LogパブリッシャまたはODL Error Logパブリッシャのenabledプロパティをtrueに設定します。次の例では、アクセス・ロガーが有効になります:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ set-log-publisher-prop --publisher-name "Oracle Access Logger" \ --set enabled:true
エラー・ロガーを有効にするには、--publisher-name "Oracle Error Logger"を使用します。
ODLアクセス・ログは、次のファイルに格納されます:
instance_dir/OUD/logs/access.log
ODLエラー・ログは、次のディレクトリに格納されます:
instance_dir/OUD/logs/errors.log
標準アクセス・ロガーおよびエラー・ロガーは、ODLロガーを有効にしても無効になりません。したがって、ODLロガーを有効にした後に標準アクセス・ログおよびエラー・ログを無効にする必要があります(特別に両方の形式のログを保持する場合を除く)。
ODLの詳細(ログ・ファイルの形式の説明を含む)は、『Oracle Fusion Middleware管理者ガイド』のログ・ファイルと診断データの管理に関する項を参照してください。
デフォルトでは、パブリッシャのsuppress-internal-loggingプロパティはtrueに設定されています。内部操作(LDIF接続ハンドラおよび特定のプラグインによって実行される操作など)をログに記録する必要がある場合、suppress-internal-loggingをfalseに設定します。次の例では、ファイルベースのアクセス・ロガーに関してsuppress-internal-loggingがfalseに設定されます:
dsconfig set-log-publisher-prop \ --publisher-name File-Based\ Access\ Logger \ --add operations-to-log:internal \ --hostname localhost \ --port 4444 \ -X \ --bindDN cn=directory\ manager \ --bindPasswordFile /tmp/password \ --no-prompt
デフォルトでは、Oracle Unified Directoryは自動的にGMT形式の日付スタンプを使用して、ローカル・サーバーのログ・ファイルの名前を変更(ローテーション)します。
ログ・ファイルのローテーションに関するこれらのデフォルト設定は変更することができます。ローテーションされたログ・ファイルのファイル名にローカル・タイムスタンプを含めるように、サーバー・インスタンスを構成することもできます。
ローカル・タイムスタンプを使用してログ・ファイル名を構成するには、適切なログ・パブリッシャのlog-file-use-local-timeプロパティをtrueに設定する必要があります。次に、ローテーションされたアクセス・ログ・ファイルのファイル名にローカル・タイムスタンプを設定する方法の例を示します。
dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ set-log-publisher-prop --publisher-name "Oracle Access Logger" \ --set log-file-use-local-time:true
|
注意: ローカル・タイムスタンプを使用したローテーション・ログ・ファイル名は、互換性を確保するためにOracle Directory Server Enterprise Editionで使用する形式に従います。 |
ログ・ファイルのサイズおよび領域制限は、ログ保存ポリシーによって決まります。Oracle Unified Directoryには、次の3つのログ保存ポリシーがあります:
ファイル数保存(file-count)。デフォルトでは、このポリシーは、指定したタイプのログ・ファイルの最大ログ・ファイル数を10に設定します。
空きディスク領域保存(free-disk-space)。デフォルトでは、このポリシーは、指定したタイプのログ・ファイルの残りの最小空きディスク領域の制限を500MBに設定します。
サイズ制限保存(size-limit)。デフォルトでは、このポリシーは、指定したタイプのログ・ファイルの使用されるディスク領域を最大500MBに設定します。
デフォルトでは、有効になっているログ保存ポリシーは、ファイル数保存です。
独自のカスタム・ログ保存ポリシーを作成することも可能です。
既存のログ保存ポリシーのリストを表示するには、次のdsconfigコマンドを実行します:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ list-log-retention-policies
デフォルトの出力は、次のようなものです:
Log Retention Policy : Type : disk-space-used : free-disk-space : number-of-files ---------------------------------:-----------------:-----------------:-----------------:---------------- File Count Retention Policy : file-count : - : - : 10 Free Disk Space Retention Policy : free-disk-space : - : 500 mb : - Size Limit Retention Policy : size-limit : 500 mb : - : -
ログ保存ポリシーのプロパティをリストするには、次のdsconfigコマンドを実行します。
$ dsconfig -h localhost -p 4444-D"cn=Directory Manager"-jpwd-file-X-n\ get-log-retention-policy-prop --policy-name "Free Disk Space Retention Policy"
ログ保存ポリシーを作成し、これをenabledに設定するには、次のように入力します:
$ dsconfig -h localhost -p 4444-D"cn=Directory Manager"-wpwd-file-X-ncreate-log-retention-policy --policy-name MyMaxDiskSpace \ --type size-limit --set disk-space-used:100mb
既存のログ保存ポリシーのプロパティを変更するには、次のdsconfigコマンドを実行します:
$ dsconfig -h localhost -p 4444-D"cn=Directory Manager"-wpwd-file-X-n\ set-log-retention-policy-prop --policy-name "File Count Retention Policy" \ --set number-of-files:20
プロパティ値を設定するかわりに、--add、--resetまたは--removeサブコマンドを--setサブコマンドのかわりに使用して、プロパティ値を追加、リセットまたは削除できます。詳細は、第A.2.4項「dsconfig」を参照してください。
ファイルをローテーションする頻度(つまり、ログ・ファイルが様々な条件に基づいて保持される期間)は、ログ・ローテーション・ポリシーによって決まります。Oracle Unified Directoryには、次の4つのログ・ローテーション・ポリシーがあります:
24時間制限のローテーション・ポリシー。デフォルトでは、このポリシーは、ローテーション間隔を1日に設定します。時刻は構成できます。
7日間制限のローテーション・ポリシー。デフォルトでは、このポリシーは、ローテーション間隔を1週間に設定します。時刻は構成できます。
固定時間制限のローテーション・ポリシー。デフォルトでは、このポリシーは、ログ・ファイルをローテーションする時刻を深夜の1分前に設定します。
サイズ時間制限のローテーション・ポリシー。デフォルトでは、このポリシーは、ログ・ファイルが到達できる最大サイズを100MBに設定し、これに到達するとログ・ファイルはローテーションされます。
デフォルトで有効になっているログ・ローテーション・ポリシーのタイプは、ログ・タイプによって異なります。
アクセス・ログと監査ログでは、次のポリシーが有効になっています:
24時間制限のローテーション・ポリシー
サイズ時間制限のローテーション・ポリシー
エラー・ログとレプリケーション修復ログでは、次のポリシーが有効になっています:
7日間制限のローテーション・ポリシー
サイズ時間制限のローテーション・ポリシー
独自のカスタム・ログ・ローテーション・ポリシーを作成することも可能です。
|
注意: 複数のローテーション・ポリシーが同じログに対して指定された場合、到達した最初のしきい値によってローテーションがトリガーされます。 |
既存のログ・ローテーション・ポリシーのリストを表示するには、次のdsconfigコマンドを実行します:
$ dsconfig -h localhost -p 4444-D"cn=Directory Manager"-wpwd-file-X-n\ list-log-rotation-policies
デフォルトの出力は、次のようなものです:
Log Rotation Policy : Type : file-size-limit : rotation-interval : time-of-day ------------------------------------:------------:-----------------:-------------------:------------ 24 Hours Time Limit Rotation Policy : time-limit : - : 1 d : - 7 Days Time Limit Rotation Policy : time-limit : - : 1 w : - Fixed Time Rotation Policy : fixed-time : - : - : 2359 Size Limit Rotation Policy : size-limit : 100 mb : - : -
ログ・ローテーション・ポリシーのプロパティを表示するには、次のコマンドを実行します:
$ dsconfig -h localhost -p 4444-D"cn=Directory Manager"-wpwd-file-X-n\ get-log-rotation-policy-prop "Fixed Time Rotation Policy"
ログ・ローテーション・ポリシーを作成するには、次のdsconfigコマンドを実行します:
$ dsconfig -h localhost -p 4444-D"cn=Directory Manager"-wpwd-file-X-n\ create-log-rotation-policy --policy-name my2DayPolicy \ --type time-limit --set rotation-interval:2d
ポリシー・タイプは次のいずれかにできます:
size-limit
fixed-time
time-limit
特定のログ・ファイルにローテーション・ポリシーまたは保存ポリシーを設定するには、ログ・パブリッシャを作成し、ログ・ローテーション・ポリシーまたはログ保存ポリシーを設定する必要があります。
特定のログ・ファイルにログ・ローテーションまたはログ保存を設定するには、次のdsconfigコマンドを実行します:
$ dsconfig -h localhost -p 1444 -D "cn=Directoy manager" -j pwd-file -n -X \ create-log-publisher --publisher-name myPublisher \ --type file-based-access --set log-file:logs/myLogs --set enabled:true \ --set retention-policy:MyMaxDiskSpace --set rotation-policy:my2DayPolicy
この項では、ODSMを使用してログを構成する方法を説明します。次のトピックが含まれます:
Oracle Unified Directoryは、デフォルトでいくつかのログ・パブリッシャ(またはロガー)を提供します。任意のタイプのロガーを任意の数定義して、いつでもアクティブにできます。つまり、様々な場所または様々なタイプのリポジトリにログでき、ログに含めるものに関して様々な条件セットを指定できます。
ODSMを使用して新規ログ・パブリッシャを作成できませんが、既存のログ・パブリッシャのプロパティを変更できます。
ODSMを使用してロガー・プロパティを構成するには、次の手順に従います:
第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「構成」タブを選択します。
「一般構成」要素を展開します。
「ロギング」要素を展開します。
「ロガー」要素を展開し、変更するプロパティを持つロガーをクリックします。
ロガーのプロパティが右側のペインに表示されます。構成可能なプロパティは、選択したロガーのタイプによって異なります。構成可能なすべてのプロパティおよび設定可能なプロパティ値の包括的なリストは、Oracle Unified Directory構成リファレンスを参照してください。
Oracle Unified Directoryは、選択したロガーのタイプに応じて、次の一般構成ポリシーを提供します:
有効。これは、ログ・パブリッシャの使用が有効になっているかどうかを示します。
ログ・パブリッシャ・ファイルの場所。これは、ファイルベースのアクセス・ログ・パブリッシャによって生成されたログ・ファイルに使用するファイル名を指定します。ファイルへのパスは、サーバー・ルートに対して相対的です。
ログ・パブリッシャの権限。これは、このファイルベースのアクセス・ログ・パブリッシャによって作成されたログ・ファイルのUNIX権限を示します。
ログに記録する操作。これは、ログに記録する必要がある操作を示します。
このプロパティは、アクセス・ログ・パブリッシャおよび監査ログ・パブリッシャに対してのみ使用可能です。
リクエスト・コントロールおよびレスポンス・コントロールのロギング。これは、クライアント・アプリケーションによってリクエストされた操作とともにリクエスト・コントロールおよびレスポンス・コントロールをログに記録する必要があるかどうかを示します。
このプロパティは、アクセス・ログ・パブリッシャおよび監査ログ・パブリッシャに対してのみ使用可能です。
デフォルト重大度。これは、ロガーのデフォルトの重大度レベルを指定します。
このプロパティは、エラー・ログ・パブリッシャに対してのみ使用可能です。
デフォルト・デバッグ・レベル。これは、定義済のターゲットのいずれもメッセージと一致しない場合にログに記録するデバッグ・メッセージの最低の重大度レベルを指定します。
このプロパティは、デバッグ・ログ・パブリッシャに対してのみ使用可能です。
構成可能なすべてのプロパティおよび各ロガーに設定可能なプロパティ値の包括的なリストは、Oracle Unified Directory構成リファレンスを参照してください。
|
注意: 手順5で選択したロガーにログ・ローテーション・ポリシーおよびログ保存ポリシーを構成できます。ログ・ローテーション・ポリシーおよびログ保存ポリシーの構成の詳細は、第29.3.2.2項「ログ・ローテーション・ポリシーの変更」および第29.3.2.3項「ログ保存ポリシーの変更」を参照してください。 |
ログ・ファイルをローテーションする頻度(つまり、ログ・ファイルが様々な条件に基づいて保持される期間)は、ログ・ローテーション・ポリシーによって決まります。
Oracle Unified Directoryには、次の4つのログ・ローテーション・ポリシーがあります:
24時間制限のローテーション・ポリシー。デフォルトでは、このポリシーは、ローテーション間隔を1日に設定します。時刻は構成できます。
7日間制限のローテーション・ポリシー。デフォルトでは、このポリシーは、ローテーション間隔を1週間に設定します。時刻は構成できます。
固定時間制限のローテーション・ポリシー。デフォルトでは、このポリシーは、ログ・ファイルをローテーションする時刻を深夜の1分前に設定します。
サイズ時間制限のローテーション・ポリシー。デフォルトでは、このポリシーは、ログ・ファイルが到達できる最大サイズを100MBに設定し、これに到達するとログ・ファイルはローテーションされます。
デフォルトで有効になっているログ・ローテーション・ポリシーのタイプは、ロガー・タイプによって異なります。
次のようにODSMを使用して、ログ・ローテーション・ポリシーを構成できます:
第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「構成」タブを選択します。
「一般構成」要素を展開します。
「ロギング」要素を展開します。
「ローテーション・ポリシー」要素を選択し、必要なプロパティを変更します。
このページで「追加」アイコンや「削除」アイコンをクリックし、必要な情報を入力することによって、新規ローテーション・ポリシーの追加や既存のローテーション・ポリシーの削除も行えます。
ログ・ファイルのサイズおよび領域制限は、ログ保存ポリシーによって決まります。Oracle Unified Directoryには、デフォルトで次の3つのログ保存ポリシーがあります:
ファイル数保存(file-count)。デフォルトでは、このポリシーは、指定したタイプのログ・ファイルの最大ログ・ファイル数を10に設定します。
空きディスク領域保存(free-disk-space)。デフォルトでは、このポリシーは、指定したタイプのログ・ファイルの残りの最小空きディスク領域の制限を500MBに設定します。
サイズ制限保存(size-limit)。デフォルトでは、このポリシーは、指定したタイプのログ・ファイルの使用されるディスク領域を最大500MBに設定します。デフォルトでは、有効になっているログ保存ポリシーは、ファイル数保存です。
次のようにODSMを使用して、ログ保存ポリシーを構成できます:
第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「構成」タブを選択します。
「一般構成」要素を展開します。
「ロギング」要素を展開します。
「保存ポリシー」要素を選択し、必要なプロパティを変更します。
このページで「追加」アイコンや「削除」アイコンをクリックし、必要な情報を入力することによって、新規保存ポリシーの追加や既存の保存ポリシーの削除も行えます。
Oracle Unified Directoryには、ログに記録する操作を指定する新規パラメータがあります。この項では、この新規構成パラメータについて説明し、次のトピックを説明します:
Oracle Unified Directoryには、管理コネクタを使用して管理ログをユーザー・ログから分離するメカニズムがあります。管理操作は、管理トラフィックと関連付けられたロギング情報を提供する異なるファイルにログされるようになります。
|
注意: Oracle Unified Directoryは、元の状態で、管理コネクタの操作のみを含む |
operations-to-logプロパティを使用して、アクセス・ログを構成してログに記録する操作のタイプを指定できます。このプロパティはオプションで、次構成可能な値を持っています:
SYNCHRONIZATION
INTERNAL
ADMINISTRATION
USER
ADMIN_BROWSING
ALL
この意味では、Oracle Unified Directoryは、次の操作タイプをサポートしています:
同期操作
ロック、プロセス同期、属性マッピング、変換などの同期操作。
内部操作
内部操作は、クライアントからの外部リクエストによってではなく、プラグインによって内部的に開始されるため、内部的です。クライアントのリクエストが存在しない操作を実行するためにプラグインがディレクトリ・サーバーを必要とする場合、内部操作コールを使用する必要があります。
管理操作
管理操作は、ネットワーク・グループ選択コントロールに関連付けられた操作を除いて、管理ネットワーク・グループに対して実行されます。
ユーザー操作
ユーザー操作は、ネットワーク・グループ選択コントロールに関連付けられた操作を除いて、任意のユーザー・ネットワーク・グループに対して実行されます。
管理参照操作
管理参照操作は、ネットワーク・グループ選択コントロールと関連付けられています。これは、ネットワーク・グループ依存に関連付けられた操作を除外します。
|
注意: ネットワーク・グループによって処理された操作はユーザーによって作成され、管理接尾辞にアクセスすることはユーザー操作と見なされます。 |
ODSMは、ログ・パブリッシャのプロパティの特性および動作に応じて、ログ・パブリッシャのプロパティを3つの異なるヘッダー(「ロガーの一般プロパティ」、「ローテーションおよび保持ポリシー」および「拡張プロパティ」)にグループ化します。「ロガーの一般プロパティ」リージョンは、デフォルトですべてのロガーに表示可能で、ファイルベースのアクセス・ロガーにログに記録する操作を構成できます。
次のようにODSMを使用して、アクセス・ログ・パブリッシャにログに記録する操作を構成できます:
第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーまたはディレクトリ・プロキシ・サーバーに接続します。
「構成」タブを選択します。
「一般構成」要素を展開します。
「ロギング」要素を展開します。
「ロガー」要素を展開します。
変更するファイルベースのアクセス・ロガー(たとえば、ファイルベースの管理アクセス・ロガー)をクリックします。
「ロガーの一般プロパティ」リージョンで、次の手順を実行します:
「ログに記録する操作」リストから、ログに記録する操作を選択します。
「適用」をクリックします。
Oracle Unified Directoryには、JMX拡張子またはSMTP拡張子によってアラートおよびアカウント・ステータス通知を転送するメカニズムがあります。ディレクトリ・サーバーを構成して、処理中にイベントが発生したときにアラート通知を送信できます。一般的なサーバー・イベントには、サーバーの起動とシャットダウン、サーバーによって検出される問題(構成ファイルに書き込もうとするなど)が含まれます。
パスワード・ポリシーの処理中にイベント(アカウントのロック・アウト、アカウントの期限切れ、パスワードの期限切れなど)が発生したときにアカウント・ステータス通知を受信することも可能です。
アラートとアカウント・ステータス通知ハンドラは、dsconfigコマンドを使用して構成されます。詳細は、第14.1項「dsconfigを使用したサーバー構成の管理」を参照してください。
この項のトピックの詳細は、第24章「パスワード・ポリシーの管理」およびOracle Unified Directory構成リファレンスのアラート・ハンドラ構成に関する項を参照してください。
Oracle Unified Directoryには、JMX拡張子またはSMTP拡張子によってアラートおよびアカウント・ステータス通知を転送するメカニズムがあります。
Oracle Unified Directoryを構成して、処理中にイベントが発生したときにアラート通知を送信できます。一般的なサーバー・イベントには、サーバーの起動とシャットダウン、サーバーによって検出される問題(構成ファイルに書き込もうとするなど)が含まれます。パスワード・ポリシーの処理中にイベント(アカウントのロック・アウト、アカウントの期限切れ、パスワードの期限切れなど)が発生したときにアカウント・ステータス通知を受信することも可能です。
Oracle Unified Directoryでは、次のアラート・ハンドラがサポートされます:
JMX通知用のJMXアラート・ハンドラ
電子メール通知用のSMTPアラート・ハンドラ
次のトピックでは、アラート・ハンドラ構成の管理方法を説明します:
dsconfigを使用したアラート・ハンドラの管理次の項では、dsconfigを使用したアラート・ハンドラ構成の管理方法を説明します。ODSMインタフェースを使用したアラートの構成の詳細は、第29.4.1.2項「ODSMを使用したアラート・ハンドラの管理」を参照してください。
この項には次のトピックが含まれます:
Oracle Unified Directoryは、アラート・ハンドラの情報をcn=Alert Handlers,cn=configサブツリーの下の構成ファイルに格納します。この情報には、dsconfigコマンドを使用してアクセスできます。
アラート・ハンドラのリストを表示するには、次のdsconfigコマンドを実行します:
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ list-alert-handlers Alert Handler : Type : enabled ------------------:------:-------- JMX Alert Handler : jmx : false
JMXアラート・ハンドラはデフォルトでは無効になっています。開始する前に、サーバー上でJMXを構成する必要があります。詳細は、第29.5.3項「JConsoleを使用したサーバーの監視」を参照してください。
アラート・ハンドラのプロパティをリストするには、次のようにdsconfigコマンドを使用します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ get-alert-handler-prop --handler-name "JMX Alert Handler" Property : Value(s) --------------------:--------------------------------------------- disabled-alert-type : - enabled : false enabled-alert-type : -
アラート・ハンドラを有効にするには、次のようにdsconfigを使用します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ set-alert-handler-prop --handler-name "JMX Alert Handler" --set enabled:true
dsconfigを使用して変更内容を確認します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ get-alert-handler-prop --handler-name "JMX Alert Handler" Property : Value(s) --------------------:--------------------------------------------- disabled-alert-type : - enabled : true enabled-alert-type : -
次の例では、新規SMTPハンドラを構成します。この手順を開始する前に、Oracle Unified DirectoryのSMTPサーバーが構成済である必要があります。
アラート・ハンドラを作成するには、dsconfigをcreate-alert-handlerサブコマンドとともに実行します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ create-alert-handler --handler-name "my SMTP Handler" --type smtp \ --set enabled:true --set message-body:"Alert Type: %%alert-type%% \n\nAlert ID: %%alert-id%%\n\nAlert Message: %%alert-message%%" \ --set message-subject:"Alert Message" \ --set recipient-address:directorymanager@example.com \ --set sender-address:OUD-Alerts@directory.example.com
次のようにアラート・ハンドラのリストを表示します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ list-alert-handlers
アラート・ハンドラを削除するには、dsconfig delete-alert-handlerコマンドを使用します。次の例では、JMXアラート・ハンドラを削除します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ delete-alert-handler --handler-name "JMX Alert Handler"
アラート・ハンドラを削除するかわりに、これを単に無効にできます。この場合、将来このアラート・ハンドラを再有効化する必要がある場合、これを使用できます。詳細は、第29.4.1.1.5項「許可されているアラート・タイプをコントロールするには」を参照してください。
サポートされているすべてのアラート・タイプのリストは、第29.4.1.3項「サポートされているアラート・タイプ」を参照してください。
デフォルトでは、サポートされているすべてのアラート・タイプが許可されます。enabled-alert-typeプロパティに値を指定すると、これらのタイプのいずれかであるアラートのみが許可されます。disabled-alert-typeプロパティに値を指定すると、このプロパティの値のタイプを除くすべてのアラート・タイプが許可されます。アラート・タイプは、この例に示すようにJavaクラスによって指定されます。
アラート・タイプを無効にするには、そのJavaクラスをdisabled-alert-typeプロパティの値として指定します。
このコマンドは、JMXアラート・ハンドラから起動アラートを無効にします。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ set-alert-handler-prop --handler-name "JMX Alert Handler" \ --set disabled-alert-type:org.opends.server.DirectoryServerStarted
次の項では、ODSMを使用したアラート・ハンドラ構成の管理方法を説明します。dsconfigを使用したアラート・ハンドラの構成の詳細は、第29.4.1.1項「dsconfigを使用したアラート・ハンドラの管理」を参照してください。
ODSMを使用してアラート・ハンドラを作成するには、次の手順を実行します:
第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「構成」タブを選択します。
「作成」メニューから、「アラート・ハンドラ」を選択します。
作成するアラート・ハンドラのタイプを選択します:
JMX。このアラート・ハンドラは、JMX通知を生成して、サーバー内で発生する重大なイベントを管理者にアラートするために使用されます。
SMTP。このアラート・ハンドラは、電子メール・メッセージを送信して、サーバー内で発生する重大なイベントを管理者に通知するために使用されます。
右側のペインにプロパティを入力して接続ハンドラを構成します。
構成可能なプロパティは、選択したアラート・ハンドラのタイプによって異なります。構成可能なすべてのプロパティおよび設定可能なプロパティ値の包括的なリストは、Oracle Unified Directory構成リファレンスのアラート・ハンドラ構成に関する項を参照してください。
|
注意: デフォルトでは、すべてのアラート・タイプが許可されます。「有効なアラート・タイプ」フィールドで1つ以上の値を指定すると、これらのタイプのいずれかであるアラートのみが許可されます。「無効なアラート・タイプ」フィールドに1つ以上の値を指定すると、このフィールドの値のタイプを除くすべてのアラート・タイプが許可されます。 サポートされているすべてのアラート・タイプのリストは、第29.4.1.3項「サポートされているアラート・タイプ」を参照してください。 |
特定のアラート・ハンドラ・タイプに必要なプロパティを構成済の場合、「作成」をクリックします。
次のようにODSMを使用して、既存のアラート・ハンドラを変更できます:
第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「構成」タブを選択します。
「一般構成」要素を展開します。
「アラート・ハンドラ」要素を展開します。
変更するプロパティを持つアラート・ハンドラを選択します。
右側のペインにプロパティが表示されます。
必要なプロパティを変更したら、「適用」をクリックします。
次のようにODSMを使用して、既存のアラート・ハンドラを変更できます:
第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「構成」タブを選択します。
「一般構成」要素を展開します。
「アラート・ハンドラ」要素を展開します。
削除するアラート・ハンドラを選択し、「構成の削除」アイコンをクリックします。
削除の確認を求められます。「はい」をクリックします。
サーバーは、システムでアラート・タイプ・イベントが発生すると、メッセージ・アラートを送信します。サポートされているアラート・タイプは、次の表で定義されています。
| アラート・タイプ | 説明 |
|---|---|
|
アクセス制御無効 Javaクラス: |
アクセス・コントロール・ハンドラが無効になったことを管理者に通知します。 |
|
アクセス制御有効 Javaクラス: |
アクセス・コントロール・ハンドラが有効になったことを管理者に通知します。 |
|
アクセス制御の解析に失敗しました Javaクラス: |
サーバーを初めて起動したときに、Oracle Directory Server Enterprise Edition互換のアクセス・コントロール・サブシステムが1つ以上のACIルールを正しく解析できなかったことを管理者に通知します。 |
|
バックエンド環境使用不可 Javaクラス: |
JEバックエンドが |
|
スキーマ・ファイルをコピーできません Javaクラス: |
スキーマの更新の前に既存のスキーマ構成のコピーを作成しようとしている間に問題が発生し、スキーマ構成が一貫性のない状態のままになっている可能性がある場合に管理者に通知します。 |
|
繰返しタスクが見つかりません Javaクラス: |
前の繰返しが完了した後、次の繰返しをスケジュールするための反復タスク定義をディレクトリ・サーバーが見つけられなかった場合に管理者に通知します。 |
|
現在のタスク・ファイルの名前を変更できません Javaクラス: |
更新したバージョンを書き込もうとするプロセスで、ディレクトリ・サーバーが現在のタスクのバッキング・ファイルの名前を変更できない場合に管理者に通知します。 |
|
新規タスク・ファイルの名前を変更できません Javaクラス: |
ディレクトリ・サーバーが新規タスクのバッキング・ファイルの名前を適切に変更できない場合に管理者に通知します。 |
|
反復の繰返しをスケジュールできません Javaクラス: |
ディレクトリ・サーバーが繰返しタスクの反復をスケジュールできない場合に管理者に通知します。 |
|
構成を書き込めません Javaクラス: |
ディレクトリ・サーバーがなんらかの理由で更新した構成を書き込めず、サーバーを再起動してもサーバーが新規構成を表示できない場合に管理者に通知します。 |
|
新規スキーマ・ファイルを書き込めません Javaクラス: |
新しいバージョンのサーバー・スキーマ構成ファイルを書き込もうとしている間に問題が発生し、スキーマ構成が一貫性のない状態のままになっている可能性がある場合に管理者に通知します。 |
|
タスク・ファイルを書き込めません Javaクラス: |
ディレクトリ・サーバーが更新したタスクのバッキング・ファイルをなんらかの理由で書き込めない場合に管理者に通知します。 |
|
分散バックエンドはPreRead制御をサポートしていません Javaクラス: |
分散によってグローバル索引カタログの内容を維持できない場合に管理者に通知します。これは、1つ以上のサーバーが読込み前エントリ制御(RFC 4527)をサポートしていない場合に発生します。 |
|
ロックダウン・モードの開始中 Javaクラス: |
ルート・ユーザーのみがループバック・アドレスを介してのみ操作の実行を許可されているロックダウン・モードをディレクトリ・サーバーが開始中の場合に管理者に通知します。 |
|
LDAP接続ハンドラ連続失敗 Javaクラス: |
LDAP接続ハンドラで連続して失敗が発生し、このハンドラが無効になったことを管理者に通知します。 |
|
LDAP接続ハンドラ・キャッチなしエラー Javaクラス: |
LDAP接続ハンドラでキャッチなしエラーが発生し、このハンドラが無効になったことを管理者に通知します。 |
|
LDAPサーバー拡張失敗 Javaクラス: |
LDAPサーバー拡張が停止中として検出されたことを管理者に通知します。 |
|
LDAPサーバー拡張稼働 Javaクラス: |
LDAPサーバー拡張が稼働中として検出されたことを管理者に通知します。 |
|
LDIFバックエンドは更新を書き込めません Javaクラス: |
書込み操作の処理後、更新したLDIFファイルのコピーをLDIFバックエンドが格納できなかったことを管理者に通知します。 |
|
LDIF ConnHandler解析エラー Javaクラス: |
LDIFファイルを解析しようとしてLDIF接続ハンドラでリカバリ不能なエラーが発生したことを管理者に通知します。 |
|
LDIF ConnHandler IOエラー Javaクラス: |
LDIF接続ハンドラでI/Oエラーが発生し、処理を完了できなかったことを管理者に通知します。 |
|
ロックダウン・モードの終了中 Javaクラス: |
ディレクトリ・サーバーがロックダウン・モードを終了中であることを管理者に通知します。 |
|
手動構成編集が処理されました Javaクラス: |
サーバーがオンラインの状態でディレクトリ・サーバーの構成が手動で編集され、その変更がサーバーを介して行われた別の変更によってオーバーライドされたことをディレクトリ・サーバーが検出した場合に管理者に通知します。手動で編集した構成は別の場所にコピーされます。 |
|
手動構成編集が失われました Javaクラス: |
サーバーがオンラインの状態でディレクトリ・サーバーの構成が手動で編集され、その変更がサーバーを介して行われた別の変更によってオーバーライドされたことをディレクトリ・サーバーが検出した場合に管理者に通知します。手動で編集した構成は、予期しないエラーのために保存できませんでした。 |
|
SaturationLoadBalancingAlgorithmによって選択された新規ルート Javaクラス: |
飽和ロード・バランシング・アルゴリズムによって新規ルートがアクティブ・ルートとして選択されたことを管理者に通知します。 |
|
FailoverLoadBalancingAlgorithmによって選択された新規ルート Javaクラス: |
フェイルオーバー・ロード・バランシング・アルゴリズムによって新規ルートがアクティブ・ルートとして選択されたことを管理者に通知します。 |
|
レプリケーション未解決競合 Javaクラス: |
マルチマスター・レプリケーションが競合を自動的に解決できない場合に管理者に通知します。 |
|
サーバーが起動しました Javaクラス: |
ディレクトリ・サーバーが起動プロセスを完了したことを管理者に通知します。 |
|
サーバーのシャットダウン Javaクラス: |
ディレクトリ・サーバーがシャットダウンのプロセスを開始したことを管理者に通知します。 |
|
飽和ロード・バランシング・ルートの状態変更 Javaクラス: |
飽和ロード・バランシング・ルートの状態が変化した(飽和から未飽和または未飽和から飽和のいずれか)ことを管理者に通知します。 |
|
キャッチなし例外 Javaクラス: |
ディレクトリ・サーバーのスレッドでキャッチなし例外が発生し、スレッドが異常終了した場合に管理者に通知します。この問題がディレクトリ・サーバーに与える影響は、影響を受けたスレッドおよび例外の特性によって異なります。 |
|
一意属性同期競合 Javaクラス: |
一意属性競合が同期処理中に検出されたことを管理者に通知します。 |
|
一意属性同期エラー Javaクラス: |
同期処理中に一意属性競合検出を実行しようとしてエラーが発生したことを管理者に通知します。 |
|
サポートされていないディレクトリ・バックエンド Javaクラス: |
分散によってグローバル索引カタログの内容を維持できないことを管理者に通知します。これは、1つ以上のサーバーが読込み前エントリ制御(RFC 4527)をサポートしていない場合に発生します。 |
アカウント・ステータス通知ハンドラは、パスワード・ポリシーの処理中にイベントのアラートを提供します。デフォルトでは、エラー・ログ・アカウント・ステータス通知ハンドラは、初期構成時に有効に設定されます。サーバーは、次のいずれかのイベントがパスワード・ポリシーで構成済で、パスワード・ポリシーの処理中にこれが発生した場合にメッセージをサーバーのエラー・ログに書き込みます:
account-temporarily-locked
account-permanently-locked
account-unlocked
account-idle-locked
account-reset-locked
account-disabled
account-expired
password-expired
password expiring
password-reset
password-changed
エラー・ログは、instance-dir/OUD/logs/errorsにあります。
dsconfigをlist-account-status-notification-handlersサブコマンドとともに使用します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ list-account-status-notification-handlers Account Status Notification Handler : Type : enabled ------------------------------------:-----------:-------- Error Log Handler : error-log : true SMTP Handler : smtp : false
dsconfigコマンドを使用して、既存のアカウント・ステータス通知ハンドラを有効にできます。デフォルトでは、ディレクトリ・サーバーは、サーバーが最初に構成されるときにエラー・ログ・ハンドラを有効にします。この例では、SMTP通知ハンドラを有効にします。
enabledプロパティを表示するには、dsconfigをget-account-status-notification-handler-propサブコマンドとともに使用します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ get-account-status-notification-handler-prop --handler-name "SMTP Handler" \ --property enabled Property : Value(s) ---------:--------- enabled : false
通知ハンドラを有効にするには、dsconfigをset-account-status-notification-handler-propサブコマンドとともに使用します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ set-account-status-notification-handler-prop --handler-name "SMTP Handler" \ --set property:enabled
dsconfigをcreate-account-status-notification-handlerサブコマンドとともに使用してハンドラを作成します。
タイプを指定するとき、error-logまたはgeneric(デフォルト)を使用できます。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ create-account-status-notification-handler \ --handler-name "My Password Reset Logger" --type error-log \ --set enabled:true --set account-status-notification-type:password-reset
dsconfigを使用して、アカウント・ステータス通知ハンドラのリストを表示します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ list-account-status-notification-handlers Account Status Notification Handler : Type : enabled ------------------------------------:-----------:-------- Error Log Handler : error-log : true my Password Reset Logger : error-log : true SMTP Handler : smtp : false
アカウント・ステータス通知ハンドラを削除するかわりにこれを無効にできます。この場合、将来このアラート・ハンドラを再有効化する必要がある場合、これを使用できます。
dsconfigを使用して、アカウント・ステータス通知ハンドラを完全に削除できます。
dsconfigをdelete-account-status-notification-handlerサブコマンドとともに使用します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ delete-account-status-notification-handler \ --handler-name "My Password Reset Logger"
Oracle Unified Directoryには、デバッグまたはトラブルシューティングの目的でサーバーの現在の状態を監視する様々な方法があります。
この項のトピックでは、サーバーでのプロバイダの監視を構成済であることを前提としています。詳細は、第29.2項「監視プロバイダの構成」を参照してください。
いくつかの方法でLDAPを介してサーバーを監視できます。これらの機能については、次の各項で説明します:
cn=monitorエントリを使用した監視情報の表示ディレクトリ・サーバーは、cn=monitorのベースDNを使用して、システム、パフォーマンスおよびバージョンの情報をエントリとして記録します。このエントリは、便利なパフォーマンス・メトリックおよびサーバーの状態の情報を提供し、これを使用してディレクトリ・サーバー・インスタンスを管理およびデバッグできます。
管理ポートからのみcn=monitor接尾辞にアクセスできます。管理ポートを使用すると、監視情報にアクセスできる利点があります。管理コネクタの主な利点は、ユーザー・トラフィックと管理トラフィックを分離できることです。
たとえば、通常のLDAPポートを介してLDAP接続ハンドラの接続数を監視する場合、("cn=Client Connections,cn=LDAP Connection Handler 0.0.0.0 port port-number,cn=monitor")、管理データは監視リクエスト自身によって「汚されます」。この項の例はすべて、SSLを介した管理ポートを使用します。詳細は、第14.3項「サーバーへの管理トラフィックの管理」を参照してください。
プロキシに関する監視情報は、数十の属性(次のものに関係のある属性など)に関してcn=Monitorの下のレベルで収集できます:
ワークフロー: cn=workflow,cn=monitor
ネットワーク・グループ: cn=Network Groups,cn=monitor
ロード・バランサ: cn=load balancing,cn=monitor
分散: cn=distribution,cn=monitor
グローバル索引カタログ: cn=Global Index Catalogs,cn=monitor
クライアント接続: cn=Client Connections,cn=monitor、またはcn=Client Connections,cn=LDAP Connection Handler 0.0.0.0 port ポート番号,cn=monitorの下
LDAP接続ハンドラ: cn=LDAP Connection Handler 0.0.0.0 port ポート番号,cn=monitor
LDAP接続ハンドラ統計: cn=LDAP Connection Handler 0.0.0.0 portポート番号 statistics,cn=monitor
SNMP接続ハンドラ: cn=SNMP Connection Handler,cn=Monitor
JMX接続ハンドラ: cn=JMX Connection Handler ポート番号,cn=monitor
管理コネクタ: cn=Administration Connector 0.0.0.0 port ポート番号,cn=monitor
システム情報: cn=System Information,cn=monitor
バージョン: cn=Version,cn=monitor
バックエンドLDAPサーバー: cn=LDAP Servers,cn=monitor
JVMスタック・トレース: cn=JVM Stack Trace,cn=monitor
JVMメモリー使用量: cn=JVM Memory Usage,cn=Monitor
SNMP: cn=SNMP,cn=Monitor
バックエンド・バックアップ: cn=backup Backend,cn=monitor
バックエンド・データの監視: cn=monitor Backend,cn=monitor
バックエンド・バックアップのタスク: cn=backup Backend,cn=monitor
エントリ・キャッシュ: cn=Entry Caches,cn=monitor
ワーク・キュー: cn=Work Queue,cn=monitor
その他の属性は、dnツリーの前述のそれぞれの下で監視されます。たとえば、クライアント接続は、cn=Client Connections, 0.0.0.0 port ポート番号,cn=monitorとcn=Client Connections,cn=Administration Connector 0.0.0.0 port ポート番号, cn=monitorの下の両方で監視されます。
ワークフロー要素は、そのワークフロー要素が関係するツリーの一部の下で監視されます。たとえば、ロード・バランシング・ワークフロー要素は、cn=load-bal-route1,cn=load balancing,cn=monitorとして監視できます。
数百の統計が監視のためにプロキシによって収集されます。たとえば永続検索機能では、psearchCountは永続検索操作数をリストし、psearchTotalCountは最後のサーバー再起動以降の永続検索操作数をリストします。
ldapsearchコマンドをcn=monitorエントリで使用してこれらの統計をすべてリストできます(第29.5.1.2項「使用可能な監視情報を表示するには」を参照)。cn=monitorエントリへのアクセスは、ACIのバイパス権限を持つユーザーに制限されています。
次の手順は、コマンドライン・インタフェースでldapsearchコマンドを使用します。
グローバル索引のレプリケーションに関するステータス情報を表示するには、gicadm status-replicationコマンドを使用します。詳細は、第15.1.7.2.5項「レプリケートされたグローバル索引カタログ構成のステータスを表示するには」を参照してください。
ldapsearchコマンドを使用して、cn=monitorの属性を検査します。この例では、各監視エントリのベースDNをリストします。
検索範囲をsub、検索属性を1.1に設定して、ldapsearchコマンドを実行します。
この検索属性は、一致するエントリに属性が含まれていてはいけないことを示します。
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -s sub -b "cn=monitor" "(objectclass=*)" "1.1" dn: cn=monitor dn: cn=Client Connections,cn=monitor dn: cn=ads-truststore Backend,cn=monitor dn: cn=Network Groups,cn=monitor dn: cn=internal,cn=Network Groups,cn=monitor dn: cn=default,cn=Network Groups,cn=monitor dn: cn=LDAP Connection Handler 0.0.0.0 port 1389 Statistics,cn=monitor dn: cn=Administration Connector 0.0.0.0 port 4444,cn=monitor dn: cn=Client Connections,cn=Administration Connector 0.0.0.0 port 4444,cn=monitor dn: cn=backup Backend,cn=monitor dn: cn=Version,cn=monitor dn: cn=Work Queue,cn=monitor dn: cn=System Information,cn=monitor dn: cn=userRoot Database Environment,cn=monitor dn: cn=tasks Backend,cn=monitor dn: cn=adminRoot Backend,cn=monitor dn: cn=userRoot Backend,cn=monitor dn: cn=schema Backend,cn=monitor dn: cn=LDAP Connection Handler 0.0.0.0 port 1389,cn=monitor dn: cn=admin,cn=Network Groups,cn=monitor dn: cn=Client Connections,cn=LDAP Connection Handler 0.0.0.0 port 1389,cn=monitor dn: cn=JVM Memory Usage,cn=monitor dn: cn=Administration Connector 0.0.0.0 port 4444 Statistics,cn=monitor dn: cn=JVM Stack Trace,cn=monitor dn: cn=Entry Caches,cn=monitor dn: cn=monitor Backend,cn=monitor
ldapsearchコマンドを"cn=monitor"のベースDNとともに使用します。
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -s base -b "cn=monitor" "(objectclass=*)"
出力は、次のようになります:
dn: cn=monitorstartTime: 20120110110156ZobjectClass: extensibleObjectobjectClass: topobjectClass: ds-monitor-entrycn: monitorvendorName: Oracle CorporationcurrentTime: 20120111082026ZvendorVersion: Oracle Unified Directory 11.1.2.0maxConnections: 1productName: Oracle Unified DirectorycurrentConnections: 1totalConnections: 8upTime: 57 days 21 hours 18 minutes 30 seconds
ldapsearchコマンドを"cn=System Information,cn=monitor"のベースDNとともに使用します。
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -s base -b "cn=System Information,cn=monitor" "(objectclass=*)"
構成に応じて、出力は次のようになります:
dn: cn=System Information,cn=monitor instancePath: /local/asinst_2/OUD javaVersion: 1.6.0_10 jvmArchitecture: 32-bit jvmArguments: "-Dorg.opends.server.scriptName=start-ds" jvmVersion: 11.0-b15 classPath: /local/instances/OUD/classes: /local/asinst_2/OUD/resources/resources.jar: /local/asinst_2/OUD/lib/activation.jar: /local/asinst_2/OUD/lib/aspectjrt.jar: /local/asinst_2/OUD/lib/je.jar: /local/asinst_2/OUD/lib/mail.jar: /local/asinst_2/OUD/lib/OUD_de.jar: /local/asinst_2/OUD/lib/OUD_es.jar: /local/asinst_2/OUD/lib/OUD_fr.jar: /local/asinst_2/OUD/lib/OUD_ja.jar: /local/asinst_2/OUD/lib/OUD.jar: /local/asinst_2/OUD/lib/OUD_zh_CN.jar: /local/asinst_2/OUD/lib/quicksetup.jar usedMemory: 83361792 freeUsedMemory: 21020432 objectClass: extensibleObject objectClass: top objectClass: ds-monitor-entry javaVendor: Oracle Corporation operatingSystem: SunOS 5.11 x86 cn: System Information systemName: llandudno workingDirectory: /local/asinst_2/OUD/bin maxMemory: 518717440 availableCPUs: 2 javaHome: /usr/jdk/instances/jdk1.6.0/jre jvmVendor: Oracle Corporation
ldapsearchコマンドを"cn=Version,cn=monitor"のベースDNとともに使用します。
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -b "cn=Version,cn=Monitor" "(objectclass=*)"
出力は、次のようなものです:
dn: cn=Version,cn=monitor shortName: OUD labelNumber: 1112231410 objectClass: extensibleObject objectClass: top objectClass: ds-monitor-entry cn: Version pointVersion: 2 compactVersion: OUD-11.1 buildID: 20111224012512Z majorVersion: 11 productName: Oracle Unified Directory minorVersion: 1 versionQualifier: 0 fullVersion: Oracle Unified Directory 11.1.2.0
userRootバックエンドは、データのバックエンド・データベース(JE環境)です。このモニターには、バックエンドの一般プロパティ(書込み可能性モード、ベースDN、バックエンドID、エントリ数などのプロパティ)が表示されます。
ldapsearchコマンドを"cn=userRoot Backend,cn=monitor"のベースDNとともに使用します。
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -s base -b "cn=userRoot Backend,cn=monitor" "(objectclass=*)"
構成に応じて、出力は次のようになります:
dn: cn=userRoot Backend,cn=monitor objectClass: top objectClass: ds-monitor-entry objectClass: ds-backend-monitor-entry ds-backend-is-private: FALSE cn: userRoot Backend ds-backend-writability-mode: enabled ds-backend-entry-count: 2002 ds-backend-id: userRoot ds-base-dn-entry-count: 2002 dc=example,dc=com ds-backend-base-dn: dc=example,dc=com
ldapsearchコマンドを"cn=backup Backend,cn=monitor"のベースDNとともに使用します。
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -s base -b "cn=backup Backend,cn=monitor" "(objectclass=*)"
構成に応じて、出力は次のようになります:
dn: cn=backup Backend,cn=monitor objectClass: top objectClass: ds-monitor-entry objectClass: ds-backend-monitor-entry ds-backend-is-private: TRUE cn: backup Backend ds-backend-writability-mode: disabled ds-backend-entry-count: 1 ds-backend-id: backup ds-base-dn-entry-count: 1 cn=backups ds-backend-base-dn: cn=backups
タスクは、ある将来の日付に処理または反復して処理を行うためにスケジュールできる管理機能(import-ldif、export-ldif、backup、restoreなど)です。このモニターには、タスクのバックエンドの一般プロパティ(書込み可能性モード、ベースDN、バックエンドID、エントリ数などのプロパティ)が表示されます。
ldapsearchコマンドを"cn=Tasks Backend,cn=monitor"のベースDNとともに使用します。
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -s base -b "cn=Tasks Backend,cn=monitor" "(objectclass=*)"
構成に応じて、出力は次のようになります:
dn: cn=tasks Backend,cn=monitor objectClass: top objectClass: ds-monitor-entry objectClass: ds-backend-monitor-entry ds-backend-is-private: TRUE cn: tasks Backend ds-backend-writability-mode: enabled ds-backend-entry-count: 3 ds-backend-id: tasks ds-base-dn-entry-count: 3 cn=tasks ds-backend-base-dn: cn=tasks
monitorバックエンドを監視するにはこのモニターには、バックエンドの一般プロパティ(書込み可能性モード、ベースDN、バックエンドID、エントリ数などのプロパティ)が表示されます。
ldapsearchコマンドを"cn=monitor Backend,cn=monitor"のベースDNとともに使用します。
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -s base -b "cn=monitor Backend,cn=monitor" "(objectclass=*)"
構成に応じて、出力は次のようになります:
dn: cn=monitor Backend,cn=monitor objectClass: top objectClass: ds-monitor-entry objectClass: ds-backend-monitor-entry ds-backend-is-private: TRUE cn: monitor Backend ds-backend-writability-mode: disabled ds-backend-entry-count: 25 ds-backend-id: monitor ds-base-dn-entry-count: 25 cn=monitor ds-backend-base-dn: cn=monitor
このモニターには、スキーマのバックエンドの一般プロパティ(書込み可能性モード、ベースDN、バックエンドID、エントリ数などのプロパティ)が表示されます。
ldapsearchコマンドを"cn=schema Backend,cn=monitor"のベースDNとともに使用します。
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -s base -b "cn=schema Backend,cn=monitor" "(objectclass=*)"
構成に応じて、出力は次のようになります:
dn: cn=schema Backend,cn=monitor objectClass: top objectClass: ds-monitor-entry objectClass: ds-backend-monitor-entry ds-backend-is-private: TRUE cn: schema Backend ds-backend-writability-mode: enabled ds-backend-entry-count: 1 ds-backend-id: schema ds-base-dn-entry-count: 1 cn=schema ds-backend-base-dn: cn=schema
adminRootバックエンドを監視するにはこのモニターには、adminRootバックエンドの一般プロパティ(書込み可能性モード、ベースDN、バックエンドID、エントリ数などのプロパティ)が表示されます。
ldapsearchコマンドを"cn=adminRoot Backend,cn=monitor"のベースDNとともに使用します。
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -s base -b "cn=adminRoot Backend,cn=monitor" "(objectclass=*)"
構成に応じて、出力は次のようになります:
dn: cn=adminRoot Backend,cn=monitor objectClass: top objectClass: ds-monitor-entry objectClass: ds-backend-monitor-entry ds-backend-is-private: TRUE cn: adminRoot Backend ds-backend-writability-mode: enabled ds-backend-entry-count: 7 ds-backend-id: adminRoot ds-base-dn-entry-count: 7 cn=admin data ds-backend-base-dn: cn=admin data
ads-truststoreバックエンドを監視するにはads-truststoreは、新規インスタンスがADSドメインの既存のサーバーに対して信頼を確立できるように、リモート管理ディレクトリ・サービス(ADS)のホストのADSキー・エントリのミラー(またはコピー)を保持します。このモニターには、バックエンドの一般プロパティ(書込み可能性モード、ベースDN、バックエンドID、エントリ数などのプロパティ)が表示されます。
ldapsearchコマンドを"cn=ads-truststore Backend,cn=monitor"のベースDNとともに使用します。
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -s base -b "cn=ads-truststore Backend,cn=monitor" "(objectclass=*)"
構成に応じて、出力は次のようになります:
dn: cn=ads-truststore Backend,cn=monitor objectClass: top objectClass: ds-monitor-entry objectClass: ds-backend-monitor-entry ds-backend-is-private: TRUE cn: ads-truststore Backend ds-backend-writability-mode: enabled ds-backend-entry-count: 3 ds-backend-id: ads-truststore ds-base-dn-entry-count: 3 cn=ads-truststore ds-backend-base-dn: cn=ads-truststore
このモニターは、オープン状態のすべてのクライアント接続を表します。この内容は、LDAP接続ハンドラのオープン状態のクライアント接続のみを記述する"cn=Client Connections,cn=LDAP Connection Handler 0.0.0.0 port 1389,cn=monitor"のDNの内容とは異なります。
ldapsearchコマンドを"cn=Client Connections,cn=monitor"のベースDNとともに使用します。
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -s base -b "cn=Client Connections,cn=monitor" "(objectclass=*)"
構成に応じて、出力は次のようになります:
dn: cn=Client Connections,cn=monitor connection: connID="11" connectTime="20090702125632Z" source="198.51.100.0:54044" destination="198.51.100.23:1389" ldapVersion="3" authDN="cn=Directory Manager,cn=Root DNs, cn=config" security="none" opsInProgress="1" cn: Client Connections objectClass: extensibleObject objectClass: top objectClass: ds-monitor-entry
LDAP接続ハンドラは、LDAPを介してクライアントと対話するために使用されます。
ldapsearchコマンドを"cn=LDAP Connection Handler 0.0.0.0 port port-number,cn=monitor"のベースDNとともに使用します。
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -s base \ -b "cn=LDAP Connection Handler 0.0.0.0 port 1389,cn=monitor" \ "(objectclass=*)"
構成に応じて、出力は次のようになります:
dn: cn=LDAP Connection Handler 0.0.0.0 port 1389,cn=monitor ds-connectionhandler-listener: 0.0.0.0:1389 ds-connectionhandler-num-connections: 1 ds-connectionhandler-protocol: LDAP objectClass: top objectClass: ds-monitor-entry objectClass: ds-connectionhandler-monitor-entry ds-mon-config-dn: cn=ldap connection handler,cn=connection handlers,cn=config cn: LDAP Connection Handler 0.0.0.0 port 1389 ds-connectionhandler-connection: connID="22" connectTime="20120302133936Z" source="198.51.100.0:39574" destination="198.51.100.23:1389" ldapVersion="3" authDN="cn=Directory Manager,cn=Root DNs,cn=config" security="none" opsInProgress="1"
ldapsearchコマンドを"cn=LDAP Connection Handler 0.0.0.0 port port-number Statistics,cn=monitor"のベースDNとともに使用します。
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -s base \ -b "cn=LDAP Connection Handler 0.0.0.0 port 1389 Statistics,cn=monitor" \ "(objectclass=*)"
構成に応じて、出力は次のようになります:
dn: cn=LDAP Connection Handler 0.0.0.0 port 1389 Statistics,cn=monitor objectClass: ds-monitor-entry objectClass: top objectClass: extensibleObject operationsCompleted: 37 compareRequests: 0 bytesWritten: 99488 extendedRequests: 0 addRequests: 0 bindRequests: 19 ...(more output)
このモニターは、LDAP接続ハンドラのオープン状態のクライアント接続を表します。
ldapsearchコマンドを"cn=Client Connections,cn=LDAP Connection Handler 0.0.0.0 port port-number,cn=monitor"のベースDNとともに使用します。
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file \ --useSSL --trustAll \ -b "cn=Client Connections,cn=LDAP Connection Handler 0.0.0.0 port 1389 \ cn=monitor" \ "(objectclass=*)"
構成に応じて、出力は次のようになります:
dn: cn=Client Connections,cn=LDAP Connection Handler 0.0.0.0 port 1389,cn=monitor connection: connID="0" connectTime="20090706084747Z" source="198.51.100.0:57523" destination="198.51.100.0:1389" ldapVersion="3" authDN="" security="none" opsInProgress="0" connection: connID="1" connectTime="20090706084747Z" source="198.51.100.0:57524" destination="198.51.100.0:1389" ldapVersion="3" authDN="" security="none" opsInProgress="0" connection: connID="2" connectTime="20090706084747Z" source="198.51.100.0:57525" destination="198.51.100.0:1389" ldapVersion="3" authDN="" security="none" opsInProgress="0" connection: connID="3" connectTime="20090706084747Z" source="198.51.100.0:57526" destination="198.51.100.0:1389" ldapVersion="3" authDN="" security="none" opsInProgress="0" connection: connID="4" connectTime="20090706084747Z" source="198.51.100.0:57527" destination="198.51.100.0:1389" ldapVersion="3" authDN="" security="none" opsInProgress="0"
このモニターは、管理コネクタの基本情報を提供します。詳細は、第14.3項「サーバーへの管理トラフィックの管理」を参照してください。
ldapsearchコマンドを"cn=Administration Connector 0.0.0.0 port admin-port-number,cn=monitor"のベースDNとともに使用します。
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -b "cn=Administration Connector 0.0.0.0 port 4444,cn=monitor" \ "(objectclass=*)"
構成に応じて、出力は次のようになります:
objectClass: top objectClass: ds-monitor-entry objectClass: ds-connectionhandler-monitor-entry dn: cn=Administration Connector 0.0.0.0 port 4444,cn=monitor ds-connectionhandler-listener: 0.0.0.0:4444 ds-connectionhandler-num-connections: 0 ds-connectionhandler-protocol: LDAPS cn: Administration Connector 0.0.0.0 port 4444 ds-mon-config-dn: cn=administration connector,cn=config
このモニターは、管理コネクタを介して実行される操作に関する広範な統計情報を提供します。詳細は、第14.3項「サーバーへの管理トラフィックの管理」を参照してください。
ldapsearchコマンドを"cn=Administration Connector 0.0.0.0 port admin-port-number Statistics,cn=monitor"のベースDNとともに使用します。
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll \ -b "cn=Administration Connector 0.0.0.0 port 4444 Statistics,cn=monitor" \ "(objectclass=*)"
構成に応じて、出力は次のようになります:
dn: cn=Administration Connector 0.0.0.0 port 4444 Statistics,cn=monitor compareResponses: 0 connectionsClosed: 1 searchResultsDone: 4 ds-mon-resident-time-mod-operations-total-time: 92257568 extendedResponses: 0 bindRequests: 2 operationsAbandoned: 0 bytesWritten: 45056 addResponses: 0 addRequests: 0 ds-mon-resident-time-moddn-operations-total-time: 0 ds-mon-extended-operations-total-count: 0 ds-mon-moddn-operations-total-count: 0 modifyResponses: 1 operationsCompleted: 7 ...(more output)...
このモニターは、管理コネクタのオープン状態のクライアント接続を表します。
ldapsearchコマンドを"cn=Client Connections,cn=Administration Connector 0.0.0.0 port port-number,cn=monitor"のベースDNとともに使用します。
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file \ --useSSL --trustAll \ -b "cn=Client Connections,cn=Administration Connector 0.0.0.0 \ port 4444,cn=monitor" \ "(objectclass=*)"
構成に応じて、出力は次のようになります:
objectClass: top objectClass: ds-monitor-entry objectClass: extensibleObject dn: cn=Client Connections,cn=Administration Connector 0.0.0.0 port 4444,cn=monitor connection: connID="339" connectTime="20120307075218Z" source="198.51.100.0:48213" destination="198.51.100.0:4444" ldapVersion="3" authDN="" security="TLS" opsInProgress="1" cn: Client Connections
LDIF接続ハンドラは、内部操作を使用してLDIFファイルから読み取られる変更を処理するために使用されます。LDIF接続ハンドラの情報の監視は、接続ハンドラが有効になっている場合のみ使用できます。
ldapsearchコマンドを"cn=LDIF Connection Handler,cn=monitor"のベースDNとともに使用します。
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -s base -b "cn=LDIF Connection Handler,cn=monitor" "(objectclass=*)"
構成に応じて、出力は次のようになります:
objectClass: top objectClass: ds-monitor-entry objectClass: ds-connectionhandler-monitor-entry dn: cn=LDIF Connection Handler,cn=monitor ds-connectionhandler-num-connections: 0 ds-connectionhandler-protocol: LDIF ds-mon-config-dn: cn=ldif connection handler,cn=connection handlers,cn=config cn: LDIF Connection Handler
ワーク・キューは、未処理のクライアント・リクエストを追跡し、これらが確実に処理されるようにします。
ldapsearchコマンドを"cn=Work Queue,cn=monitor"のベースDNとともに使用します。
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -s base -b "cn=Work Queue,cn=monitor" "(objectclass=*)"
構成に応じて、出力は次のようになります:
dn: cn=Work Queue,cn=monitor currentRequestBacklog: 0 objectClass: extensibleObject objectClass: top objectClass: ds-monitor-entry requestsSubmitted: 25 cn: Work Queue maxRequestBacklog: 0 averageRequestBacklog: 0 requestsRejectedDueToQueueFull: 0
ディレクトリ・サーバー・インスタンスのJVMスタック・トレース情報にアクセスできます。このリソース・モニターは、org.opends.server.monitors.StackTraceMonitorProviderクラスに実装され、カスタム構成を必要としません。
ldapsearchコマンドを"cn=JVM Stack Trace,cn=monitor"のベースDNとともに使用します。
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -s base -b "cn=JVM Stack Trace,cn=monitor" "(objectclass=*)"
構成に応じて、出力の先頭は次のようになります:
dn: cn=JVM Stack Trace,cn=monitor cn: JVM Stack Trace jvmThread: id=2 ---------- Reference Handler ---------- jvmThread: id=2 frame[0]=java.lang.Object.wait(Object.java:native) jvmThread: id=2 frame[1]=java.lang.Object.wait(Object.java:485) jvmThread: id=2 frame[2]=java.lang.ref.Reference$ReferenceHandler.run(Reference. java:116) jvmThread: id=3 ---------- Finalizer ---------- jvmThread: id=3 frame[0]=java.lang.Object.wait(Object.java:native) jvmThread: id=3 frame[1]=java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java :116) jvmThread: id=3 frame[2]=java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java :132) jvmThread: id=3 frame[3]=java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.j ava:159) jvmThread: id=4 ---------- Signal Dispatcher ---------- jvmThread: id=10 ---------- Time Thread ---------- jvmThread: id=10 frame[0]=sun.misc.Unsafe.park(Unsafe.java:native) jvmThread: id=10 frame[1]=java.util.concurrent.locks.LockSupport.parkNanos(LockS upport.java:198) ...(more output)...
ldapsearchコマンドを"cn=JVM Memory Usage,cn=monitor"のベースDNとともに使用します。
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -s base -b "cn=JVM Memory Usage,cn=monitor" "(objectclass=*)"
構成に応じて、出力は次のようになります:
dn: cn=JVM Memory Usage,cn=monitor ps-eden-space-bytes-used-after-last-collection: 0 ps-mark-sweep-total-collection-count: 0 code-cache-bytes-used-after-last-collection: 0 ps-old-gen-current-bytes-used: 25260472 ps-perm-gen-bytes-used-after-last-collection: 0 ps-scavenge-recent-collection-duration: 3 ps-scavenge-total-collection-count: 17 ps-eden-space-current-bytes-used: 32001992 ps-perm-gen-current-bytes-used: 21179960 ps-old-gen-bytes-used-after-last-collection: 0 ps-mark-sweep-total-collection-duration: 0 ps-mark-sweep-average-collection-duration: 0 ps-scavenge-average-collection-duration: 26 ps-scavenge-total-collection-duration: 443 objectClass: extensibleObject objectClass: top objectClass: ds-monitor-entry ps-mark-sweep-recent-collection-duration: 0 ps-survivor-space-bytes-used-after-last-collection: 622592 cn: JVM Memory Usage code-cache-current-bytes-used: 2143680 ps-survivor-space-current-bytes-used: 622592
userRootデータベース環境を監視するにはuserRootデータベース環境は、Berkeley DB Java Editionのバックエンドを利用します。JE監視データ(cn=*Database Environment,cn=monitorの下のデータ)は、短期間のみ信頼できます。サーバー・アクティビティが多い間(たとえば、カウンタに応じて1時間から数日)、このデータはオーバーフローする可能性があります。このような場合、JE監視データは、負の値または正の値だが正しくない値を示す可能性があります。これは既知の問題で、Berkeley DB Java Editionの次の主要なリリースで修正される予定です。Oracle SR番号15979と15985がこの問題に対応しています。
ldapsearchコマンドを"cn=userRoot Database Environment,cn=monitor"のベースDNとともに使用します。
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -s base -b "cn=userRoot Database Environment,cn=monitor" \ "(objectclass=*)" dn: cn=userRoot Database Environment,cn=monitor
構成に応じて、出力は次のようになります:
EnvironmentNTempBufferWrites: 0 EnvironmentNNodesExplicitlyEvicted: 0 EnvironmentCleanerBacklog: 0 EnvironmentTotalLogSize: 5386067 EnvironmentLockBytes: 2000 EnvironmentNFullBINFlush: 2 EnvironmentNBINsStripped: 0 EnvironmentLastCheckpointEnd: 5385359 TransactionNCommits: 24 EnvironmentNCleanerEntriesRead: 0 EnvironmentNRepeatFaultReads: 2 TransactionNXACommits: 0 EnvironmentNClusterLNsProcessed: 0 TransactionNBegins: 24 LockNOwners: 25 ...(more output)...
データベース(DB)キャッシュは、Java Editionノードを格納するために使用されます。DBキャッシュは、ディレクトリ・サーバーのパフォーマンス全体の重要なコンポーネントです。DBキャッシュを注意深くチューニングして監視してください。DBキャッシュには、次のノードが含まれています:
上位ノード
内部ノード
リーフ・ノード
上位ノードおよび内部ノードは内部Bツリー構造を表し、リーフ・ノードはユーザー・エントリを表します。可能な最高のパフォーマンスを得るためには、すべてのDBキャッシュ・ノードをDBキャッシュに配置することをお薦めします。DBキャッシュに少なくともBツリー内部構造(上位ノードおよび内部ノード)を含むようにDBキャッシュをサイズ設定することをお薦めします。DBキャッシュが短すぎると、多くの失敗および頻繁な削除が発生し、このことがディレクトリ・サーバーのパフォーマンスに悪影響する可能性があります。
キャッシュのサイズのチューニングは次の方法で行います:
dbcache-percentの設定
OUD JVMヒープ(特に古いもの)の適切なサイズ設定。
DBキャッシュの監視は、ldapsearchコマンドをcn=userRoot Database Environment,cn=monitorのベースDNとともに使用して行うことができます:
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -s base -b "cn=userRoot Database Environment,cn=monitor" \ "(objectclass=*)" dn: cn=userRoot Database Environment,cn=monitor
構成に応じて、出力は次のようになります:
EnvironmentNTempBufferWrites: 0 EnvironmentNNodesExplicitlyEvicted: 0 EnvironmentCleanerBacklog: 0 EnvironmentTotalLogSize: 5386067 EnvironmentLockBytes: 2000 EnvironmentNFullBINFlush: 2 EnvironmentNBINsStripped: 0 EnvironmentLastCheckpointEnd: 5385359 TransactionNCommits: 24 EnvironmentNCleanerEntriesRead: 0 EnvironmentNRepeatFaultReads: 2 TransactionNXACommits: 0 EnvironmentNClusterLNsProcessed: 0 TransactionNBegins: 24 LockNOwners: 25 ...(more output)...
次のDBキャッシュ成功と失敗カウンタを以下に説明します:
| カウンタ | 説明 |
|---|---|
|
|
キャッシュからフェッチされた上位内部ノードの蓄積数。 |
|
|
失敗した上位内部ノードの蓄積数。 |
|
|
キャッシュからフェッチされた下位内部ノードの蓄積数。 |
|
|
失敗した上位内部ノードの蓄積数。 |
|
|
キャッシュからフェッチされたリーフ・ノードの蓄積数。 |
|
|
失敗したリーフ・ノードの蓄積数。 |
OUDのパフォーマンスを良好にするには、DBキャッシュ内にすべてのノードを配置するか、または少なくともDBキャッシュ内にすべての内部ノードを配置することをお薦めします。
cn=monitorの値は蓄積されるため、定期的(たとえば1分おき)にデルタを計算し、経時的にデルタの増加を監視することが重要です。次のものを更新する必要があります:
DeltaNUpperINsMiss=EnvironmentNUpperINsFetchMiss - EnvironmentNUpperINsFetchMissPrev DeltaNUpperINsFetch=EnvironmentNUpperINsFetch - EnvironmentNUpperINsFetchPrev DeltaBINsMiss=EnvironmentNBINsFetchMiss - EnvironmentNBINsFetchMissPrev DeltaBINsFetch=EnvironmentNBINsFetch - EnvironmentNBINsFetchPrev DeltaNLNsMiss=EnvironmentNLNsFetchMiss - EnvironmentNLNsFetchMissPrev DeltaNLNsFetch=EnvironmentNLNsFetch - EnvironmentNLNsFetchPrev
最小レベルのパフォーマンスでOracle Unified Directoryを実行できます。以下に示すように、Bツリー構造をDBキャッシュ内に配置することをお薦めします:
((DeltaNUpperINsMiss/DeltaNUpperINsFetch)*100) as close to 0 as possible ((DeltaNBINsMiss/DeltaNBINsFetch)*100) as close to 0 as possible (< 5% remains acceptable)
可能な最高のパフォーマンスを得るためには、OUDがユーザー・エントリもDBキャッシュ内に配置することをお薦めします。たとえば、次のようにします:
((DeltaNLNsMiss/DeltaNLNsFetch)*100) できるかぎり0に近づけます。
インポート完了後(およびデータ準備後)デルタ比を0に近づけて開始し、時間の経過とともにデルタ比は、データベースのサイズの増加(レプリケーション・メタデータのbc、最小利用のクリアのインパクト、エントリ(新規アプリケーション)の増大、およびエントリ数)によって大きくなります。このため、(カスタム・スクリプトまたはUIを介して)DBキャッシュを監視し、適切なアクション(DBキャッシュのパーセントまたはOUD JVMヒープの増大など)を行うことをお薦めします。
cn=Entry Caches,cn=Monitorエントリにアクセスすることによって、ディレクトリ・サーバー・インスタンスの蓄積状態のすべてのアクティブ・エントリ・キャッシュにアクセスできます。エントリ・キャッシュ・インスタンスがディレクトリ・サーバー構成で有効になっている場合、サーバーは特定のインスタンスの「キャッシュごと」の監視データもリクエストできます:
cn=FIFO Entry Cache,cn=Monitor
cn=Soft Reference Entry Cache,cn=Monitor
cn=File System Entry Cache,cn=Monitor
また、任意の名前を付けられたアクティブ・エントリ・キャッシュ・インスタンス(たとえば、cn=Any Arbitrary Name Entry Cache,cn=Monitor)は、そのインスタンス名でアクセスできるモニターを提供する必要があります。
ldapsearchコマンドを"cn=Entry Caches,cn=monitor"のベースDNとともに使用します。
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -s base -b "cn=Entry Caches,cn=monitor" "(objectclass=*)"
構成に応じて、出力は次のようになります:
dn: cn=Entry Caches,cn=monitor entryCacheHits: 0 entryCacheTries: 0 currentEntryCacheCount: 0 objectClass: extensibleObject objectClass: top objectClass: ds-monitor-entry entryCacheHitRatio: 0 cn: Entry Caches ...
ldapsearchコマンドを"cn=Network Groups,cn=monitor"のベースDNとともに使用します。
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file \
--useSSL --trustAll -b "cn=Network Groups,cn=monitor" "(objectclass=*)"
構成に応じて、出力は次のようになります:
objectClass: top objectClass: ds-monitor-entry objectClass: ds-mon-branch dn: cn=Network Groups,cn=monitor dn: cn=admin,cn=Network Groups,cn=monitor ds-mon-compare-operations-total-count: 0 ds-mon-failed-referrals-total-count: 15 ds-mon-unbind-operations-total-count: 13 ds-mon-followed-referrals-total-count: 34 ds-mon-violations-schema-total-count: Not implemented ds-mon-bind-operations-total-count: 98 ds-mon-persistent-searchs-count: Not implemented ds-mon-add-operations-total-count: 37 ds-mon-abandon-operations-total-count: 0 ds-mon-moddn-operations-total-count: 0 ds-mon-extended-operations-total-count: 0 ds-mon-searchsubtree-operations-total-count: 310 objectClass: top objectClass: ds-monitor-entry objectClass: extensibleObject ds-mon-discarded-referrals-total-count: Not implemented ds-mon-mod-operations-total-count: 1 ds-mon-forwarded-referrals-total-count: Not implemented cn: admin ds-mon-searchonelevel-operations-total-count: 92966 ds-mon-delete-operations-total-count: 0 dn: cn=default,cn=Network Groups,cn=monitor ...
ldapsearchコマンドを"cn=Distribution,cn=monitor"のベースDNとともに使用します。
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file \ --useSSL --trustAll -b "cn=Distribution,cn=monitor" "(objectclass=*)"
構成に応じて、出力は次のようになります:
objectClass: top objectClass: ds-monitor-entry objectClass: ds-mon-branch dn: cn=distribution,cn=monitor cn: distrib-we ds-mon-searchonelevel-operations-total-count: 0 ds-mon-residenttime-bind-operations-max-time: 0 ... ds-mon-delete-operations-total-count: 0 dn: cn=algorithm,cn=distrib-we,cn=distribution,cn=monitor ds-mon-residenttime-total-time: 0 ds-mon-residenttime-max-time: 0 cn: algorithm ds-mon-runs-total-count: 0 ds-mon-residenttime-min-time: 0 objectClass: top objectClass: ds-monitor-entry objectClass: extensibleObject dn: cn=partitions,cn=algorithm,cn=distrib-we,cn=distribution,cn=monitor objectClass: top objectClass: ds-monitor-entry objectClass: ds-mon-branch dn: cn=distrib-part1,cn=partitions,cn=algorithm,cn=distrib-we,cn=distribution,cn =monitor ... objectClass: top objectClass: ds-monitor-entry objectClass: extensibleObject ds-mon-modify-operations-total-count: 0 cn: distrib-part1 ds-mon-searchonelevel-operations-total-count: 0 ds-mon-delete-operations-total-count: 0 dn: cn=distrib-part2,cn=partitions,cn=algorithm,cn=distrib-we,cn=distribution,cn =monitor ...
ldapsearchコマンドを"cn=load balancing,cn=monitor"のベースDNとともに使用します。
$ ldapsearch -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file \ --useSSL --trustAll -b "cn=load balancing,cn=monitor" "(objectclass=*)"
構成に応じて、出力は次のようになります:
objectClass: top objectClass: ds-monitor-entry objectClass: ds-mon-branch dn: cn=load balancing,cn=monitor dn: cn=load-bal-we1,cn=load balancing,cn=monitor ds-mon-aborted-add-operations-total-count: 0 ... dn: cn=algorithm,cn=load-bal-we1,cn=load balancing,cn=monitor dn: cn=routes,cn=algorithm,cn=load-bal-we1,cn=load balancing,cn=monitor ... dn: cn=load-bal-route1,cn=routes,cn=algorithm,cn=load-bal-we1,cn=load balancing,cn=monitor ... dn: cn=load-bal-we2,cn=load balancing,cn=monitor ... dn: cn=algorithm,cn=load-bal-we2,cn=load balancing,cn=monitor ... dn: cn=routes,cn=algorithm,cn=load-bal-we2,cn=load balancing,cn=monitor dn: cn=load-bal-route1,cn=routes,cn=algorithm,cn=load-bal-we2,cn=load balancing,cn=monitor ... cn: load-bal-route1 dn: cn=load-bal-route2,cn=routes,cn=algorithm,cn=load-bal-we1,cn=load balancing,cn=monitor ... cn: load-bal-route2 dn: cn=load-bal-route2,cn=routes,cn=algorithm,cn=load-bal-we2,cn=load balancing,cn=monitor cn: load-bal-route2 ds-mon-searchonelevel-operations-total-count: 9 ds-mon-delete-operations-total-count: 0
ldapsearchコマンドを"cn=LDAP Servers,cn=monitor"のベースDNとともに使用します。
$ ldapsearch -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file \ --useSSL --trustAll -b "cn=LDAP Servers,cn=monitor" "(objectclass=*)"
構成に応じて、出力は次のようになります:
objectClass: top objectClass: ds-monitor-entry objectClass: ds-mon-branch dn: cn=LDAP Servers,cn=monitor dn: cn=proxy1,cn=LDAP Servers,cn=monitor ds-mon-aborted-add-operations-total-count: 0 ... cn: proxy1 ds-mon-searchonelevel-operations-total-count: 0 ... objectClass: top objectClass: ds-monitor-entry objectClass: extensibleObject dn: cn=proxy2,cn=LDAP Servers,cn=monitor ds-mon-aborted-add-operations-total-count: 0 ... cn: proxy2 ds-mon-searchonelevel-operations-total-count: 0 ... objectClass: top objectClass: ds-monitor-entry objectClass: extensibleObject ... dn: cn=proxy3,cn=LDAP Servers,cn=monitor ... cn: proxy3 ds-mon-searchonelevel-operations-total-count: 0 ... objectClass: top objectClass: ds-monitor-entry objectClass: extensibleObject ... dn: cn=proxy4,cn=LDAP Servers,cn=monitor ... cn: proxy4 ... objectClass: top objectClass: ds-monitor-entry objectClass: extensibleObject
ldapsearchコマンドを"cn=givenname,cn=gi-catalog,cn=Global Index Catalogs,cn=monitor"のベースDNとともに使用します。
givennameが索引化された属性の名前に対応し(たとえば、cnを索引化した場合、cn)、gi-catalogがグローバル索引カタログの名前に対応するようにします。
$ ldapsearch -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file --useSSL \ --trustAll -b "cn=givenname,cn=gi-catalog,cn=Global Index Catalogs,cn=monitor" "(objectclass=*)"
構成に応じて、出力は次のようになります:
dn: cn=givenname,cn=gi-catalog,cn=Global Index Catalogs,cn=monitor ds-mon-add-operations-min-time: 0 ds-mon-add-operations-aborted-count: 0 ds-mon-lookup-operations-min-time: 0 ds-mon-getpartitions-operations-total-count: 0 ds-mon-add-operations-max-time: 0 ds-mon-lookup-operations-total-count: 0 ds-mon-memorized-remove-operations-count: 0 ds-mon-remove-operations-aborted-count: 0 ds-mon-add-operations-total-time: 0 ds-mon-getpartitions-operations-aborted-count: 0 ds-mon-lookup-operations-total-time: 0 ds-mon-index-entries: 0 ds-mon-remove-operations-failed-count: 0 ds-mon-getpartitions-operations-min-time: 0 ds-mon-lookup-operations-max-time: 0 ds-mon-getpartitions-operations-average-time: 0 ds-mon-index-creation-date: 1252483187019 ds-mon-getpartitions-operations-last-access-date: 0 ds-mon-remove-operations-total-count: 0 ds-mon-lookup-operations-failed-count: 0 ds-mon-add-operations-failed-count: 0 ds-mon-remove-operations-min-time: 0 ds-mon-add-operations-average-time: 0 ds-mon-lookup-operations-aborted-count: 0 ds-mon-getpartitions-operations-total-time: 0 ds-mon-remove-operations-max-time: 0 ds-mon-getpartitions-operations-max-time: 0 ds-mon-lookup-operations-last-access-date: 0 ds-mon-add-operations-total-count: 0 ds-mon-remove-operations-total-time: 0 ds-mon-remove-operations-average-time: 0 ds-mon-getpartitions-operations-failed-count: 0 objectClass: ds-monitor-entry objectClass: top objectClass: extensibleObject ds-mon-lookup-operations-average-time: 0 ds-mon-remove-operations-last-access-date: 0 cn: givenname ds-mon-add-operations-last-access-date: 0
ldapsearchコマンドを"cn=gi-catalog,cn=Global Index Catalogs,cn=monitor"のベースDNとともに使用します。
givennameが索引化された属性の名前に対応し(たとえば、cnを索引化した場合cn)、gi-catalogがグローバル索引カタログの名前に対応するようにします。
$ ldapsearch -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file --useSSL \ --trustAll -b "cn=gi-catalog,cn=Global Index Catalogs,cn=monitor" \ "(objectclass=*)"
構成に応じて、出力は次のようになります:
dn: cn=gi-catalog,cn=Global Index Catalogs,cn=monitor ds-mon-replication-received-update-message-errors: 0 ds-mon-configured-index-number: 1 ds-mon-replication-full-update-pending-attribute: ds-mon-replication-full-update-status: NONE ds-mon-state: RUNNING_STANDALONE ds-mon-replication-published-update-message-number: 0 ds-mon-replication-active: false ds-mon-replication-auto-sync-retries: 0 ds-mon-replication-published-update-message-errors: 0 ds-mon-replication-full-update-errors: 0 ds-mon-replication-received-update-message-number: 0 ds-mon-replication-auto-sync-is-running: false objectClass: ds-monitor-entry objectClass: top objectClass: extensibleObject ds-mon-replication-configured: false cn: gi-catalog
manage-tasksコマンドを使用した監視Oracle Unified Directoryは、特定のタスク(import-ldif、export-ldif、backup、restoreなど)をスケジュールして処理するメカニズムを提供するタスク・バックエンドを提供します。タスクをスケジュールして、反復期間の特定の時刻に実行できます。スケジュール済のタスクを監視するには、manage-tasksコマンドを使用します。詳細は、第14.4項「タスクとしてのコマンドの構成」を参照してください。
JConsole (jconsole) Javaユーティリティは、管理エージェントを使用して起動された実行中のJava仮想マシンに接続しているJMX準拠のグラフィカル・ツールです。この汎用ツールは、サーバー監視情報にアクセスするために使用できます。
サーバーを起動します。
JMX接続ハンドラを有効にし、JMXで使用するポート番号を設定します。
未使用かつサーバーを実行しているユーザーがアクセス権を持っているポートを選択します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ set-connection-handler-prop --handler-name "JMX Connection Handler" \ --set enabled:true --set listen-port:1689
JMXの読取り、書込みおよび通知の権限をルートDNに追加します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ set-root-dn-prop \ --add default-root-privilege-name:jmx-read \ --add default-root-privilege-name:jmx-write \ --add default-root-privilege-name:jmx-notify
サーバーを再起動します。
端末ウィンドウでjconsoleと入力してコンソールを起動します。
コマンドラインからjconsoleを実行するには、JAVA_HOME/binをパスに追加する必要がある場合があります。ここで、JAVA_HOMEはJDKを含むディレクトリです。または、コマンドを入力するときにフルパスを入力することもできます。
JConsoleの使用の詳細は、「JConsoleの使用」(http://download.oracle.com/docs/cd/E17409_01/javase/6/docs/technotes/guides/management/jconsole.html)を参照してください。
JConsoleをサーバー・インスタンスに接続するには、リモート・プロセス・フィールドを使用します。次のフィールドが必要です:
JMX URL:
service:jmx:rmi:///jndi/rmi://''host'':''port''/org.opends.server.protocols.jmx.client-unknown
hostは、ホスト名、IPv4数値ホスト・アドレスまたは角括弧で囲まれたIPv6数値アドレスです。
portは、JMXコネクタの10進数のポート番号です。(第29.4項「アラートおよびアカウント・ステータス通知ハンドラの構成」を参照)。
デフォルトのJMX URLは次のとおりです:
service:jmx:rmi:///jndi/rmi://198.51.100.0:1689/org.opends.server.protocols.jmx.client-unknown
ユーザー名。有効なLDAPユーザー名です。
デフォルトのディレクトリ・マネージャのユーザー名はcn=Directory Managerです。
パスワード。ユーザーのLDAPパスワードです。
JConsoleがサーバー・インスタンスに接続されている場合、これは管理オブジェクト(MBean)を表示します。左側のペインのツリーは、現在使用可能なすべてのMBeanを示しています。関連するMBeanを選択することによって、右側のペインでサーバー監視情報にアクセスできます。
次の図は、サーバーcn=LDAP Connection Handler 0.0.0.0 port 1389 Statistics,cn=monitorの属性リストを示しています。
サーバーには、サーバー・インスタンスのアクセス、エラーまたはデバッグの情報を記録するロギング・メカニズムがあります。指定されたタイプの複数のロガーをいつでもアクティブにできるため、特定のサブツリーまたは異なるリポジトリのログを作成できます。サーバーは、ログの情報のタイプを制限するロギング・フィルタを現在提供していません。
次のログが用意されています:
アクセス・ログ。アクセス・ログには、ディレクトリ・サーバーによって処理された操作のタイプに関する情報が記録されます。アクセス・ログはデフォルトで提供されます。
監査ログ。監査ログは、アクセス・ログの一種で、ディレクトリ・サーバー上のすべてのアクティビティを記録します。監査ログは、デフォルトでは有効になっていません。
デバッグ・ログ。デバッグ・ログは、ディレクトリ・サーバーの問題のトラブルシューティングまたはディレクトリ・サーバーの処理に関する詳細情報の提供に使用できる情報を記録します。デバッグ・ログは、デフォルトでは有効になっていません。
エラー・ログ。エラー・ログは、ディレクトリ・サーバーの処理中に発生したすべての警告、エラーまたは重大なイベントを記録します。
レプリケーション修復ログ。レプリケーション修復ログは、トポロジの単一のディレクトリ・サーバーの非一貫性を記録します。
レプリケーション修復ログは読取り専用であり、レプリケーションの競合解決を有効にする場合のみ使用できます。
OUD設定ログ。この設定ログは、Oracle Unified Directoryのプロキシ・サーバー・インスタンスまたはレプリケーション・ゲートウェイ・インスタンスのインストール中に実行した同等のコマンドライン引数を記録します。これによって、以前のインストールに基づいて、プロキシ・サーバーまたはゲートウェイ・サーバーの「サイレント・インストール」を実行できます。
このファイルは、ディレクトリ・サーバー・インスタンスの出力ではありません。
server.outログ。server.outログは、ブートストラップ構成プロセスを記録し、jarファイルからロードされた拡張子をリストし、接続およびアラートの通知アクティビティを示します。
サーバー・インスタンスのログ・ディレクトリに変更します。
$ cd INSTANCE_DIR/OUD/logs
テキスト・エディタまたはUNIXのcatコマンドを使用して、accessファイルを開きます。
$ cat access | more [10/Jan/2012:12:02:11 +0100] CONNECT conn=0 from=198.51.100.0:55416 to=198.51.100.0:5444 protocol=LDAPS [10/Jan/2012:12:02:12 +0100] BIND REQ conn=0 op=0 msgID=1 type=SIMPLE dn="cn=Directory Manager" [10/Jan/2012:12:02:12 +0100] BIND RES conn=0 op=0 msgID=1 result=0 authDN="cn=Directory Manager,cn=Root DNs,cn=config" etime=36 [10/Jan/2012:12:02:12 +0100] UNBIND REQ conn=0 op=1 msgID=2 [10/Jan/2012:12:02:12 +0100] DISCONNECT conn=0 reason="Client Disconnect" ...(more output)...
監査ログのパブリッシャが有効になっていない場合、第29.3.1.1.2項「ログ・パブリッシャを有効にするには」の説明に従ってこれを有効にします。
サーバー・インスタンスのログ・ディレクトリに変更します。
$ cd INSTANCE_DIR/OUD/logs
テキスト・エディタまたはUNIXのcatコマンドを使用して、auditファイルを開きます。
$ cat audit | more # 11/Jan/2012:11:20:00 +0100; conn=10; op=18 dn: cn=File-Based Audit Logger,cn=Loggers,cn=config changetype: modify replace: ds-cfg-enabled ds-cfg-enabled: true - replace: modifiersName modifiersName: cn=directory manager - replace: modifyTimestamp modifyTimestamp: 20120111102000Z # 11/Jan/2012:11:20:20 +0100; conn=11; op=6 dn: cn=File-Based Debug Logger,cn=Loggers,cn=config changetype: modify replace: ds-cfg-enabled ds-cfg-enabled: true - replace: modifiersName modifiersName: cn=directory manager - replace: modifyTimestamp modifyTimestamp: 20120111102020Z ...(more output)...
デバッグ・ログのパブリッシャが有効になっていない場合、第29.3.1.1.2項「ログ・パブリッシャを有効にするには」の説明に従ってこれを有効にします。
サーバー・インスタンスのログ・ディレクトリに変更します。
$ cd INSTANCE_DIR/OUD/logs
テキスト・エディタまたはUNIXのcatコマンドを使用して、debugファイルを開きます。
$ cat debug | more
[11/Jan/2012:11:39:48 +0100] 0 caught error thread={Worker Thread 43(118)} threadDetail={parentThread=main(1) isDaemon=false clientConnection=LDAP client connection from 198.51.100.0:56288 to 198.51.100.0:2389 operation=SearchOperation(connID=13, opID=1, baseDN=dc=example,dc=com, scope=wholeSubtree, filter=(objectclass=*)) } method={run(SearchOperationBas
is.java:1513)} caught={org.opends.server.types.CanceledOperationException: Client Disconnect}
...(more output)...
サーバー・インスタンスのログ・ディレクトリに変更します。
$ cd INSTANCE_DIR/OUD/logs
テキスト・エディタまたはUNIXのcatコマンドを使用して、errorsファイルを開きます。
$ cat errors | more [11/Jan/2012:15:14:13 +0100] category=RUNTIME_INFORMATION severity=NOTICE msgID=20381717 msg=Installation Directory: /local/OUD_BASE/Oracle_OUD1[11/Jan/2012:15:14:13 +0100] category=RUNTIME_INFORMATION severity=NOTICE msgID=20381719 msg=Instance Directory: /local/OUD_BASE/asinst_4/OUD[11/Jan/2012:15:14:13 +0100] category=RUNTIME_INFORMATION severity=NOTICE msgID=20381713 msg=JVM Information: 1.6.0_30-b12 by Sun Microsystems Inc., 32-bit architecture, 957743104 bytes heap size[11/Jan/2012:15:14:13 +0100] category=RUNTIME_INFORMATION severity=NOTICE msgID=20381714 msg=JVM Host: host1, running SunOS 5.10 sparc, 103079215104 bytes physical memory size, number of processors available 24[11/Jan/2012:15:14:13 +0100] category=RUNTIME_INFORMATION severity=NOTICE msgID=20381715 msg=JVM Arguments: "-Dorg.opends.server.scriptName=start-ds"[11/Jan/2012:15:14:16 +0100] category=PROTOCOL severity=NOTICE msgID=2556180 msg=Started listening for new connections on Administration Connector 0.0.0.0 port 7444[11/Jan/2012:15:14:16 +0100] category=PROTOCOL severity=NOTICE msgID=2556180 msg=Started listening for new connections on LDAP Connection Handler 0.0.0.0 port 4389[11/Jan/2012:15:14:16 +0100] category=CORE severity=NOTICE msgID=458887 msg=TheDirectory Server has started successfully...(more output)...
サーバー・インスタンスのログ・ディレクトリに変更します。
$ cd INSTANCE_DIR/OUD/logs
テキスト・エディタまたはUNIXのcatコマンドを使用して、replicationファイルを開きます。
$ cat replication | more [13/Jan/2012:15:00:50 +0100] category=SYNC severity=NOTICE msgID=15139035 msg=The replication server database has version 2 format[13/Jan/2012:15:00:50 +0100] category=SYNC severity=NOTICE msgID=15138878 msg=Replication is up and running for domain cn=admin data with replication server id 18049 host1/198.51.100.0:8989 - local server id is 9338 - data generation is 93408[13/Jan/2012:15:00:52 +0100] category=SYNC severity=NOTICE msgID=15138878 msg=Replication is up and running for domain dc=example,dc=com with replication server id 18049 host1/198.51.100.0:8989 - local server id is 25340 - data generation is 19449577[13/Jan/2012:15:00:53 +0100] category=SYNC severity=NOTICE msgID=15138878 msg=Replication is up and running for domain cn=schema with replication server id 18049 host1/198.51.100.0:8989 - local server id is 13881 - data generation is 8408[13/Jan/2012:15:08:28 +0100] category=SYNC severity=NOTICE msgID=15138893 msg=On suffix cn=admin data, replication server 3844 presented generation ID=-1 when expected generation ID=93408[13/Jan/2012:15:08:28 +0100] category=SYNC severity=MILD_ERROR msgID=14876753 msg=In RS 18049 for dn cn=admin data, update 00000134d765d4b1247a00000001 will not be sent to RS 3844 with generation id -1 different from local generation id 93408[13/Jan/2012:15:08:28 +0100] category=SYNC severity=MILD_ERROR msgID=14876753 msg=In RS 18049 for dn cn=admin data, update 00000134d765d4b1247a00000002 will not be sent to RS 3844 with generation id -1 different from local generation id 93408...(more output)...
サーバー・インスタンスのログ・ディレクトリに変更します。
$ cd INSTANCE_DIR/OUD/logs
テキスト・エディタまたはUNIXのcatコマンドを使用して、server.outファイルを開きます。
$ cat server.out | more [23/May/2011:02:27:59 -0700] category=CORE severity=INFORMATION msgID=132 msg=The Directory Server is beginning the configuration bootstrapping process [23/May/2011:02:28:00 -0700] category=EXTENSIONS severity=INFORMATION msgID=1049147 msg=Loaded extension from file '/OUD_BASE/ORACLE_HOME/lib/extensions/globalindex.jar' (build 1.0.0) [23/May/2011:02:28:00 -0700] category=EXTENSIONS severity=INFORMATION msgID=1049147 msg=Loaded extension from file '/OUD_BASE/ORACLE_HOME/lib/extensions/replication-gateway.jar' (build 1.0.0) [23/May/2011:02:28:00 -0700] category=EXTENSIONS severity=INFORMATION msgID=1049147 msg=Loaded extension from file '/OUD_BASE/ORACLE_HOME/lib/extensions/snmp-mib2605.jar' (build 11.1.1.5.0) [23/May/2011:02:28:00 -0700] category=EXTENSIONS severity=INFORMATION msgID=1049147 msg=Loaded extension from file '/OUD_BASE/ORACLE_HOME/lib/extensions/loadbalancing.jar' (build 1.0.0) [23/May/2011:02:28:00 -0700] category=EXTENSIONS severity=INFORMATION msgID=1049147 msg=Loaded extension from file '/OUD_BASE/ORACLE_HOME/lib/extensions/virtualization.jar' (build 1.0.0) [23/May/2011:02:28:00 -0700] category=EXTENSIONS severity=INFORMATION msgID=1049147 msg=Loaded extension from file '/OUD_BASE/ORACLE_HOME/lib/extensions/distribution.jar' (build 1.0.0) ... more output ...
このログ・ファイルは、プロキシ・サーバーおよびレプリケーション・ゲートウェイのインスタンスに対してのみ使用できます。
サーバー・インスタンスのログ・ディレクトリに変更します。
$ cd INSTANCE_DIR/OUD/logs
テキスト・エディタまたはUNIXのcatコマンドを使用して、oud-setupファイルを開きます。
$ cat oud-setup | more May 19, 2011 2:24:36 AM com.sun.dps.ui.deploy.SetupLog initLogFileHandler INFO: oud-setup application launched May 19, 2011 2:24:36 AM PDT ...(more output)...
Oracle Unified Directoryでは、管理情報ベース(MIB) 2605サポートのSimple Network Management Protocol (SNMP)接続ハンドラを含むjarファイル拡張が提供されます。この拡張には、SNMP接続ハンドラ、MIB 2605オブジェクトとSNMPリクエストをサポートするために必要なクラス、およびSNMPマネージャによるサーバー監視情報へのアクセスを可能にするSNMPアダプタが含まれます。
この項の手順を開始する前に、対象のシステムでSNMP管理対象ネットワークを設定済であることを確認してください。
Oracle Unified Directoryには、有効にして構成できるSNMP接続ハンドラが用意されています。SNMP接続ハンドラは、jarファイル拡張子として提供され、install-dir/lib/extensions/snmp-mib2605.jarにあります。
Oracle Unified Directoryを構成して、Simple Network Management Protocol (SNMP)を使用して監視できます。サーバーは、Java Dynamic Management Kit (JDMK)を使用して、SNMP接続ハンドラのスマート・エージェントを作成します。
次のようにdsconfigを使用して、SNMP接続ハンドラが現在の接続ハンドラのリストの下に表示されていることを確認します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \ list-connection-handlers Connection Handler : Type : enabled : listen-port : use-ssl -------------------------:------:---------:-------------:-------- JMX Connection Handler : jmx : false : 1689 : false LDAP Connection Handler : ldap : true : 1389 : false LDAPS Connection Handler : ldap : false : 636 : true LDIF Connection Handler : ldif : true : - : - SNMP Connection Handler : snmp : false : 161 : -
dsconfigコマンドを使用して、サーバーのSNMPを有効にし、リスニング・ポートを設定します。
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -n -X \ set-connection-handler-prop --handler-name "SNMP Connection Handler" \ --set enabled:true --set listen-port:8085
次のコマンドを実行して、SNMP接続ハンドラのプロパティのリストを表示します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \ get-connection-handler-prop --handler-name "SNMP Connection Handler"
接続ハンドラのプロパティは、次のようにその値とともにリストされます。
Property : Value(s) --------------------:------------------------------------------ allowed-client : - allowed-manager : * allowed-user : * community : OUD denied-client : - enabled : false listen-port : 161 opendmk-jarfile : - registered-mbean : false security-agent-file : config/snmp/security/oud-snmp.security security-level : authnopriv trap-port : 162 traps-community : OUD traps-destination : -
stop-dsおよびstart-dsを使用して、サーバーを再起動します。
サーバーを起動して、構成を変更しなかった場合、再起動操作は必要ありません。
SNMP接続ハンドラが動作中であることを確認します。
$ snmpwalk -v 2c -c OUD@OUD localhost:8085 mib-2.66 SNMPv2-SMI::mib-2.66.1.1.1.1 = STRING: "Oracle Unified Directory Server 11.1.1.5.0 - 20090310152800Z" SNMPv2-SMI::mib-2.66.1.1.2.1 = STRING: "INSTANCE_DIR/bin" SNMPv2-SMI::mib-2.66.1.1.3.1 = Gauge32: 35 SNMPv2-SMI::mib-2.66.1.1.4.1 = Gauge32: 1 SNMPv2-SMI::mib-2.66.1.1.5.1 = Gauge32: 0 SNMPv2-SMI::mib-2.66.1.1.6.1 = Counter32: 0 SNMPv2-SMI::mib-2.66.1.1.7.1 = Counter32: 1 SNMPv2-SMI::mib-2.66.2.1.1.1.1 = INTEGER: 1 SNMPv2-SMI::mib-2.66.2.1.1.1.2 = INTEGER: 2 SNMPv2-SMI::mib-2.66.2.1.1.1.3 = INTEGER: 3 SNMPv2-SMI::mib-2.66.2.1.2.1.1 = OID: SNMPv2-SMI::internet.27.3.8085 SNMPv2-SMI::mib-2.66.2.1.2.1.2 = OID: SNMPv2-SMI::internet.27.3.1389 SNMPv2-SMI::mib-2.66.2.1.2.1.3 = OID: SNMPv2-SMI::enterprises.42 SNMPv2-SMI::mib-2.66.2.1.3.1.1 = Counter32: 1 SNMPv2-SMI::mib-2.66.2.1.3.1.2 = Counter32: 1 SNMPv2-SMI::mib-2.66.2.1.3.1.3 = Counter32: 1 SNMPv2-SMI::mib-2.66.2.1.4.1.1 = Counter32: 1 SNMPv2-SMI::mib-2.66.2.1.4.1.2 = Counter32: 1 SNMPv2-SMI::mib-2.66.2.1.4.1.3 = Counter32: 1 SNMPv2-SMI::mib-2.66.2.1.5.1.1 = Counter32: 1 SNMPv2-SMI::mib-2.66.2.1.5.1.2 = Counter32: 1 ...
MIB 2605に含まれている管理対象オブジェクトは、3つの表(dsTable、dsAppliIfOpsTableおよびdsIntTable)に分割されます。現在、dsIntTable表は実装されていません。
SNMPセキュリティ構成は、使用しているSNMPのバージョンによって異なります。このトピックでは、SNMP V1およびV2c、ならびにV3のセキュリティ構成について説明します。
SNMP v1およびSNMP v2cの下で、エージェントは情報サーバーとして動作し、IPベースのアクセス制御によってこの情報は不正なアクセスから保護されます。デフォルトでは、MIB 2605は、コミュニティ文字列OUD@OUDを使用して、v1およびv2cでアクセスできます。すべてのマネージャは、MIB 2605によって公開された監視情報を読み取ることができます。
|
注意: MIB 2605では読取りアクセスのみが認可されます。 |
dsconfigコマンドを使用して、SNMP接続ハンドラのプロパティを設定することによってSNMP v1およびSNMP v2cを構成できます。SNMP v1およびSNMP v2cのセキュリティ構成に関するプロパティには次のものがあります:
allowed-manager
community
SNMP v1トラップは、サーバー起動時およびサーバーのシャットダウン時に送信されます。デフォルトでは、これらのトラップはlocalhostに送信され、トラップ・コミュニティ文字列「OUD」を使用します。
|
注意: デフォルトのトラップ・ポートは、システムで許可されている値に変更する必要がある場合があります。 |
SNMPトラップも、dsconfigコマンドを使用して、SNMP接続プロパティを設定することによって構成できます。SNMPトラップに関するプロパティには次のものがあります:
trap-port
traps-community
traps-destination
SNMP接続ハンドラのデフォルト値に対応するACLファイルは次のように表されます:
acl = {
{
communities = OUD
access = read-only
managers = all
}
}
trap = {
{
traps-community = OUD
hosts = localhost
}
}
SNMP v3プロトコルには、SNMP v1およびSNMP v2cよりも複雑なセキュリティ・メカニズムが用意されています。SNMP v3は、エージェントとそのマネージャ間を送信されるリクエストを認証して暗号化するユーザー・ベースのセキュリティ・モデル(USM)を実装し、ユーザー・ベースのアクセス制御を提供します。defaultUserテンプレートは、SNMPクローニング・メカニズムを使用してエージェント・エンジンの認可されたユーザーを追加するために提供されます。
SNMP v3の下で、前の項で説明したコミュニティ文字列は、MIB 2605の登録元の「コンテキスト」として使用されます。デフォルトでは、MIB2605は、コンテキスト「OUD」を使用してv3でアクセスできます。すべてのユーザーがこれにアクセスできます。
SNMP v3 UACLは、dsconfigコマンドライン・ユーティリティを使用してSNMP接続ハンドラのプロパティを設定することによって構成されます。SNMP v3 UACL構成に関するプロパティには次のものがあります:
community
allowed-user
security-level
SNMP接続ハンドラのデフォルト値に対応するUACLファイルは次のように表されます:
uacl = {
{
context-names = OUD
access = read-only
security-level = authNoPriv
users = *
}
}
USM MIB (つまり、許可されたユーザーを定義するMIB)は、nullコンテキストで登録され、authNoPrivのセキュリティ・レベルのsnmpAdminユーザーのみがこれに対する読取り/書込みアクセス権を持っています。このsnmpAdminユーザーは、MIB 2605情報にアクセスできるユーザーを追加できます。
SNMP v3 USM構成は、INSTANCE_DIR/OUD/config/snmp/security/oud-snmp.securityにあるテンプレート・ファイルから読み取られます。テンプレート・ファイルは暗号化されていません。
サーバー・エージェントのMIB 2605にアクセスするには、SNMPクローン・メカニズムを使用してユーザーをセキュリティ・ファイルに追加します。snmpAdminを使用して、次の示すようにクローン・メカニズムのSNMPリクエストを送信します。クローニングするユーザーはdefaultUserです。snmpAdminユーザーおよびdefaultUserユーザーはMIB 2605情報にアクセスできません。
追加して他のユーザーを構成する管理ユーザー。
userEntry=localEngineID,snmpAdmin,null,usmHMACMD5AuthProtocol,passadmin
読取りアクセス権限および書込みアクセス権限を付与されずにクローニングされるテンプレート・ユーザー。
userEntry=localEngineID,defaultUser,,usmHMACMD5AuthProtocol,password,,,3,true
|
注意: ユーザーを永続にするためにセキュリティ・ファイルも使用されます。 |
これらのトピックでは、dsreplication statusコマンドを使用してレプリケートされたトポロジを監視する方法およびldapsearchコマンドを使用してさらに詳細な監視情報を取得する方法を説明します。
dsreplicationを使用したレプリケーション・ステータスの監視レプリケーションを監視する最も簡単な方法は、dsreplication statusコマンドを使用することです。このコマンドは、次の情報を含むレプリケーション・ステータスの表を提供します:
トポロジおよびその接続
レプリケートされるサーバー間の待機時間
レプリケートされるサーバー間のデータ一貫性
レプリケートされるサーバー間のセキュリティ構成
レプリケーション・プロトコルのピア・ツー・ピア
この項の残りの部分の例では、次の単純なレプリケーション・トポロジを想定しています。
レプリケーション・ステータスを取得するには、次のコマンドを実行します:
$ dsreplication status --adminUID admin --adminPasswordFile pwd.txt -X \ --hostname host1 --port 4444
このコマンドの出力には次のものが含まれます:
サーバー。トポロジのLDAPサーバーおよびLDAPサーバーがLDAP接続をリスニングしているポートをリストします。
エントリ。指定したベースDNの各サーバーのエントリ数を示します。この列の情報がすべてのサーバー間で同じでない場合、レプリケーション・トポロジは同期化されていません。
M.C。トポロジの他のLDAPサーバーによってすでにプッシュされたが指定したLDAPサーバーでまだリプレイされていない更新数を示します。この数が特定のサーバーで大きい場合、そのサーバーの待機時間を調査します。
A.O.M.C。トポロジの他のディレクトリ・サーバーによってプッシュされたが指定したLDAPサーバーでまだ処理されていない最も古い更新のおよその日付を指定します。
ポート。指定したLDAPサーバーの直接の接続先のレプリケーション・サーバーのポートを示します。
暗号化。LDAPサーバーとそのレプリケーション・サーバーの間でSSL暗号化が有効になっているかどうかを示します。
信頼。このサーバーが信頼できるサーバーとして構成されているか、信頼されないサーバーとして構成されているかを示します。詳細は、第26.10項「分離レプリカの使用」を参照してください。
U.C。信頼されないサーバーで行われたが、まだトポロジにレプリケートされていない変更の数を指定します。詳細は、第26.10項「分離レプリカの使用」を参照してください。
ステータス。このディレクトリ・サーバーのレプリケーション・ドメインのステータスを示します。ステータスは次のいずれかになります:
正常。レプリケーション・サーバーへの接続は、正しいデータ・セットで確立されます。レプリケーションが機能しています。確実なモードを使用すると、このディレクトリ・サーバーからの確認が送信されます。
機能低下。レプリケーション・サーバーへの接続は、正しいデータ・セットで確立されます。ディレクトリ・サーバーにはレプリケーション・サーバーのキューで保留中の変更が多数あるため、レプリケーションは低下モードで動作しています。確実なモードを使用すると、このディレクトリ・サーバーからの確認は送信されません。
完全更新。レプリケーション・サーバーとの接続が確立され、ローカル・バックエンドを初期化するために、新しいデータ・セットがこの接続から受信されます(オンライン・インポート)。
不正データ・セット。レプリケーション・サーバーとの接続が、トポロジの他のディレクトリ・サーバーとは異なるデータ・セットで確立されます。レプリケーションは動作しません。トポロジの他のディレクトリ・サーバーを互換性のあるデータ・セットを使用して初期化する必要があるか、またはこのサーバーを他のサーバーと互換性のある別のデータ・セットを使用して初期化する必要があります。
未接続。ディレクトリ・サーバーは、どのレプリケーション・サーバーとも接続されていません。
変更ログ。外部変更ログがこのサーバーのベースDNに対して有効になっているかどうかを示します。詳細は、第26.5項「外部変更ログの使用」を参照してください。
グループID。サーバーが属しているレプリケーション・グループのIDです。詳細は、第6.6項「レプリケーション・グループ」を参照してください。
接続先。このディレクトリ・サーバーの接続先のレプリケーション・サーバーの名前、IPアドレスおよびレプリケーション・ポートを表示します。
追加のレプリケーション監視情報は、cn=monitorエントリにあります。ldapsearchコマンドを使用して、レプリケーション・ステータスの包括的なビューを提供する特定の監視属性を追跡できます。詳細は、第29.7.2項「詳細レプリケーション監視」を参照してください。
レプリケーション・ステータスを監視する最も簡単な方法は、dsreplication statusコマンドを使用することです。ただし、詳細なレプリケーション監視情報は、cn=monitorエントリにあります。ldapsearchコマンドを使用して、レプリケーション・ステータスの包括的なビューを提供する特定の監視属性を追跡できます。監視情報は、レプリケーション・サーバーによって統合されます。したがって、監視情報は、実行中のレプリケーション・サーバーをホストしているディレクトリ・サーバーを検索することによってのみ取得できます。
この項の残りの部分の例では、次の単純なレプリケーション・トポロジを想定しています。
これらの例は、管理ポートのcn=monitorエントリにSSL(--useSSL)を介してアクセスし、サーバー(--trustAll)によって示される証明書を自動的に信頼します。
cn=monitorの下の情報は、レプリケートされた単一のベースDNを含むようにフィルタできます。これは、次の2つの方法で実行できます:
domain-name属性をフィルタとして指定します。例:
$ ldapsearch -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -b "cn=monitor" "(domain-name=dc=example,dc=com)"
検索ベースのベースDNを組み込みます。例:
$ ldapsearch -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -b "cn=dc_example_dc_com,cn=replication,cn=monitor" \ "(objectclass=*)"
この項では、次の監視トピックについて説明します:
各ディレクトリ・サーバーには、レプリケートされたベースDNそれぞれに対するレプリケーション・サーバーの候補のリストが含まれています。ただし、1つのディレクトリ・サーバーは、一度に1つのレプリケーション・サーバーのみと接続されます。
レプリケーション・トポロジおよびその接続の概要を取得するには、レプリケーション・サーバーをホストしているトポロジの任意のディレクトリ・サーバーで次の検索を実行します:
$ ldapsearch -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -b "cn=monitor" "(connected-to=*)" "connected-to" "lost-connections" dn: cn=Replication Domain 30839,cn=dc_example_dc_com,cn=replication,cn=monitor lost-connections: 0 connected-to: llandudno/0:0:0:0:0:0:0:1:8989 dn: cn=Replication Domain 14142,cn=cn_schema,cn=replication,cn=monitor lost-connections: 0 connected-to: llandudno/0:0:0:0:0:0:0:1:8989 dn: cn=Connected Replica llandudno 27742,cn=Replication Server 8989 1740,cn=cn_ admin data,cn=replication,cn=monitor connected-to: Replication Server 8989 1740 dn: cn=Connected Replica llandudno 30839,cn=Replication Server 8989 1740,cn=dc_ example_dc_com,cn=replication,cn=monitor connected-to: Replication Server 8989 1740 dn: cn=Connected Replica llandudno 14142,cn=Replication Server 8989 1740,cn=cn_ schema,cn=replication,cn=monitor connected-to: Replication Server 8989 1740 dn: cn=Undirect Replica 22052,cn=Connected Replication Server noordhoek:9989 71 64,cn=Replication Server 8989 1740,cn=cn_schema,cn=replication,cn=monitor connected-to: Connected Replication Server noordhoek:9989 7164,cn=Replication Se rver 8989 1740,cn=cn_schema,cn=replication dn: cn=Undirect Replica 19984,cn=Connected Replication Server noordhoek:9989 71 64,cn=Replication Server 8989 1740,cn=dc_example_dc_com,cn=replication,cn=moni tor connected-to: Connected Replication Server noordhoek:9989 7164,cn=Replication Se rver 8989 1740,cn=dc_example_dc_com,cn=replication dn: cn=Undirect Replica 30030,cn=Connected Replication Server noordhoek:9989 71 64,cn=Replication Server 8989 1740,cn=cn_admin data,cn=replication,cn=monitor connected-to: Connected Replication Server noordhoek:9989 7164,cn=Replication Se rver 8989 1740,cn=cn_admin data,cn=replication dn: cn=Replication Domain 27742,cn=cn_admin data,cn=replication,cn=monitor lost-connections: 0 connected-to: llandudno/0:0:0:0:0:0:0:1:8989
connected-to属性は、特定のベースDNに関して各ディレクトリ・サーバーが現在接続されているレプリケーション・サーバーを指定します。ディレクトリ・サーバーがレプリケーション・サーバーに直接接続される場合、そのDNにはcn=Connected Replicaが含まれます。トポロジにあるが異なるレプリケーション・サーバーに接続されているディレクトリ・サーバーは、そのDNにcn=Undirect Replicaが含まれます。すべてのレプリケーション・サーバーがその他のすべてのレプリケーション・サーバーと永続的に接続されるため、connected-to属性はレプリケーション・サーバーには存在しません。
lost-connections属性は、ディレクトリ・サーバーとレプリケーション・サーバーの間の接続切断数を示します。各ディレクトリ・サーバーのこの属性の値は、そのサーバーでレプリケーションが停止された回数に近いはずです。この属性の値がずっと大きい場合、予期しない接続損失があり、これを調査する必要があります。
レプリケーション待機時間を監視すると、特定のレプリケーション・サーバーがトポロジ内のその他のサーバーから遅れているかどうかを確認できます。これによって、レプリケーションの遅延および現在のサービスのクオリティの全体像が提供されます。
レプリケーション待機時間を監視するには、レプリケーション・サーバーをホストしているトポロジの任意のサーバーで次の検索を実行します:
$ ldapsearch -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -b "cn=monitor" "domain-name=dc=example,dc=com" "missing-changes" \ "approx-older-change-not-synchronized" dn: cn=Replication Domain 30839,cn=dc_example_dc_com,cn=replication,cn=monitor dn: cn=Replication Server 8989 1740,cn=dc_example_dc_com,cn=replication,cn=monitor missing-changes: 0 dn: cn=Connected Replica llandudno 30839,cn=Replication Server 8989 1740,cn=dc_ example_dc_com,cn=replication,cn=monitor missing-changes: 0 dn: cn=Connected Replication Server noordhoek:9989 7164,cn=Replication Server 8989 1740,cn=dc_example_dc_com,cn=replication,cn=monitor missing-changes: 0 dn: cn=Undirect Replica 19984,cn=Connected Replication Server noordhoek:9989 7164,cn=Replication Server 8989 1740,cn=dc_example_dc_com,cn=replication,cn=monitor missing-changes: 0
missing-changes属性は、トポロジの他のディレクトリ・サーバーによってすでにプッシュされたが指定したディレクトリ・サーバーでまだリプレイされていない更新数を指定します。
approx-older-change-not-synchronized属性は、トポロジの他のディレクトリ・サーバーによってプッシュされたが指定したディレクトリ・サーバーでまだ処理されていない最も古い更新のおよその日付を指定します。
|
注意: これらの属性によって定義されているようなレプリケーション待機時間が大きい場合、送受信された更新数を確認し、トポロジで待機時間の原因になっているサーバーを特定します。これらの属性は、このドキュメントで後述します。 |
データの一貫性を監視すると、トポロジの各レプリケーション・サーバーがトポロジで発生した最新の変更と同期化されて最新であるかどうかを確認できます。
トポロジのディレクトリ・サーバー間でのデータの一貫性を監視するには、レプリケーション・サーバーをホストしているトポロジの任意のサーバーで次の検索を実行します:
$ ldapsearch -p 4444 -D "cn=directory manager" -j pwd-file --useSSL --trustAll \ -b "cn=monitor" "(generation-id=*)" "generation-id" dn: cn=Replication Server 8989 1740,cn=cn_admin data,cn=replication,cn=monitor generation-id: cn=admin data 94310 dn: cn=Connected Replication Server noordhoek:9989 7164,cn=Replication Server 8989 1740,cn=cn_admin data,cn=replication,cn=monitor generation-id: 94310 dn: cn=Replication Domain 30839,cn=dc_example_dc_com,cn=replication,cn=monitor generation-id: 19399981 dn: cn=Replication Domain 14142,cn=cn_schema,cn=replication,cn=monitor generation-id: 8468 dn: cn=Connected Replica llandudno 27742,cn=Replication Server 8989 1740,cn=cn_ admin data,cn=replication,cn=monitor generation-id: 94310 dn: cn=Replication Server 8989 1740,cn=cn_schema,cn=replication,cn=monitor generation-id: cn=schema 8468 dn: cn=Replication Server 8989 1740,cn=dc_example_dc_com,cn=replication,cn=monitor generation-id: dc=example,dc=com 19399981 dn: cn=Connected Replica llandudno 30839,cn=Replication Server 8989 1740,cn=dc_ example_dc_com,cn=replication,cn=monitor generation-id: 19399981 dn: cn=Connected Replication Server noordhoek:9989 7164,cn=Replication Server 8989 1740,cn=cn_schema,cn=replication,cn=monitor generation-id: 8468 dn: cn=Connected Replica llandudno 14142,cn=Replication Server 8989 1740,cn=cn_ schema,cn=replication,cn=monitor generation-id: 8468 dn: cn=Connected Replication Server noordhoek:9989 7164,cn=Replication Server 8989 1740,cn=dc_example_dc_com,cn=replication,cn=monitor generation-id: 19399981 dn: cn=Replication Domain 27742,cn=cn_admin data,cn=replication,cn=monitor generation-id: 94310
generation-id属性は、各ディレクトリ・サーバーに対して、レプリケートされた各ベースDNのデータのバージョンを示します。ベースDN dc=example,dc=comのすべてのサーバーの生成IDは、19399981です。生成IDの一貫性は、これらのサーバーのデータがそのベースDNで同じであることを意味します。
各ディレクトリ・サーバーも接続先のレプリケーション・サーバーの生成IDを認識しています。レプリケーション・サーバーの生成IDは、そのベースDNの変更ログ・データベースに格納されている更新と関係があります。
指定したベースDNの2つのディレクトリ・サーバーおよびそのレプリケーション・サーバーがすべて同じ生成IDを持っている場合、その2つのディレクトリ・サーバー間でレプリケーションが正しく動作していると見なされます。
セキュア・レプリケーション・トポロジでは、特定のベースDNに対して、サーバー間でSSL暗号化が有効になっています。
レプリケーションのセキュリティを監視するには、レプリケーション・サーバーをホストしているトポロジの任意のサーバーで次の検索を実行します:
$ ldapsearch -p 4444 -D "cn=directory manager" -j pwd-file --useSSL --trustAll \ -b "cn=monitor" "(ssl-encryption=*)" "ssl-encryption" dn: cn=Connected Replication Server noordhoek:9989 7164,cn=Replication Server 89 89 1740,cn=cn_admin data,cn=replication,cn=monitor ssl-encryption: true dn: cn=Replication Domain 30839,cn=dc_example_dc_com,cn=replication,cn=monitor ssl-encryption: true dn: cn=Replication Domain 14142,cn=cn_schema,cn=replication,cn=monitor ssl-encryption: true dn: cn=Connected Replica llandudno 27742,cn=Replication Server 8989 1740,cn=cn_ admin data,cn=replication,cn=monitor ssl-encryption: true dn: cn=Connected Replica llandudno 30839,cn=Replication Server 8989 1740,cn=dc_ example_dc_com,cn=replication,cn=monitor ssl-encryption: true dn: cn=Connected Replication Server noordhoek:9989 7164,cn=Replication Server 89 89 1740,cn=cn_schema,cn=replication,cn=monitor ssl-encryption: true dn: cn=Connected Replica llandudno 14142,cn=Replication Server 8989 1740,cn=cn_ schema,cn=replication,cn=monitor ssl-encryption: true dn: cn=Connected Replication Server noordhoek:9989 7164,cn=Replication Server 8989 1740,cn=dc_example_dc_com,cn=replication,cn=monitor ssl-encryption: true dn: cn=Replication Domain 27742,cn=cn_admin data,cn=replication,cn=monitor ssl-encryption: true
ssl-encryption属性は、指定したベースDNの2つのサーバー間でレプリケーション・プロトコルを暗号化するかどうかを指定します。この情報は、ディレクトリ・サーバーまたはレプリケーション・サーバーそれぞれに対して使用できます。レプリケーション・セッションの認証は監視されません。
トポロジのサーバーによって送受信された更新数を監視すると、レプリケーションの動作状況がわかります。
送受信された更新を監視するには、次のコマンドを入力します:
$ ldapsearch -p 4444 -D "cn=directory manager" -j pwd-file --useSSL --trustAll \ -b "cn=monitor" "(&(sent-updates=*)(received-updates=*))" \ "sent-updates" "received-updates" dn: cn=Connected Replication Server noordhoek:9989 7164,cn=Replication Server 8989 1740,cn=cn_admin data,cn=replication,cn=monitor sent-updates: 7 received-updates: 0 dn: cn=Replication Domain 30839,cn=dc_example_dc_com,cn=replication,cn=monitor received-updates: 28 sent-updates: 0 dn: cn=Replication Domain 14142,cn=cn_schema,cn=replication,cn=monitor received-updates: 0 sent-updates: 0 dn: cn=Connected Replica llandudno 27742,cn=Replication Server 8989 1740,cn=cn_ admin data,cn=replication,cn=monitor sent-updates: 0 received-updates: 0 dn: cn=Connected Replica llandudno 30839,cn=Replication Server 8989 1740,cn=dc_ example_dc_com,cn=replication,cn=monitor sent-updates: 28 received-updates: 0 dn: cn=Connected Replication Server noordhoek:9989 7164,cn=Replication Server 8989 1740,cn=cn_schema,cn=replication,cn=monitor sent-updates: 0 received-updates: 0 dn: cn=Connected Replica llandudno 14142,cn=Replication Server 8989 1740,cn=cn_ schema,cn=replication,cn=monitor sent-updates: 0 received-updates: 0 dn: cn=Connected Replication Server noordhoek:9989 7164,cn=Replication Server 8989 1740,cn=dc_example_dc_com,cn=replication,cn=monitor sent-updates: 0 received-updates: 28 dn: cn=Replication Domain 27742,cn=cn_admin data,cn=replication,cn=monitor received-updates: 0 sent-updates: 0
sent-updates属性は、このディレクトリ・サーバーまたはレプリケーション・サーバーによって送信された更新数を示します。
received-updates属性は、このディレクトリ・サーバーまたはレプリケーション・サーバーによって受信された更新数を示します。
これらの属性の値は、トポロジ内の更新のフローを判断する際に役立ちます。レプリケーションが非常に遅いと思われる場合、これらの属性を監視すると役に立ちます。あるサーバーによって送信された更新数が別のサーバーによって受信された更新数より一貫してずっと多い場合、2番目のサーバーがトポロジ内でボトルネックになっている可能性が高いです。
レプリケーション・プロトコルは、2つのサーバー間の更新のフローを制御します。これによって、多数の更新が2つのサーバー間で交換される場合、サーバーはより高い優先度の操作の処理を妨げられることがなくなります。この機能は、送信サーバーが送信できる更新数を受信サーバーが定期的に送信サーバーに提供するウィンドウ・メカニズムに依存しています。
max-send-window構成属性およびmax-rcv-window構成属性を設定して、送信ウィンドウおよび受信ウィンドウのサイズを指定できます。詳細は、第26.3項「dsconfigによるレプリケーション構成の変更」を参照してください。
current-send-window監視属性は、指定時間に送信サーバーが受信サーバーに送信できる変更数を示します。current-send-window属性の値が0と等しくなることが多い場合、転送が停止し、受信サーバーがトポロジのボトルネックになっている可能性が高いです。current-send-window属性の値がmax-send-window属性の値と等しくなることが多い場合、レプリケーション待機時間が長くなっていて、送信サーバーがトポロジのボトルネックになっている可能性が高いです。
current-send-windowプロパティの値を取得するには、次のコマンドを入力します:
$ ldapsearch -p 4444 -D "cn=directory manager" -j pwd-file --useSSL --trustAll \ -b "cn=monitor" "(current-send-window=*)" "current-send-window" dn: cn=Connected Replication Server noordhoek:9989 7164,cn=Replication Server 8989 1740,cn=cn_admin data,cn=replication,cn=monitor current-send-window: 93 dn: cn=Replication Domain 30839,cn=dc_example_dc_com,cn=replication,cn=monitor current-send-window: 100 dn: cn=Replication Domain 14142,cn=cn_schema,cn=replication,cn=monitor current-send-window: 100 dn: cn=Connected Replica llandudno 27742,cn=Replication Server 8989 1740,cn=cn_ admin data,cn=replication,cn=monitor current-send-window: 100 dn: cn=Connected Replica llandudno 30839,cn=Replication Server 8989 1740,cn=dc_ example_dc_com,cn=replication,cn=monitor current-send-window: 72 dn: cn=Connected Replication Server noordhoek:9989 7164,cn=Replication Server 8989 1740,cn=cn_schema,cn=replication,cn=monitor current-send-window: 100 dn: cn=Connected Replica llandudno 14142,cn=Replication Server 8989 1740,cn=cn_ schema,cn=replication,cn=monitor current-send-window: 100 dn: cn=Connected Replication Server noordhoek:9989 7164,cn=Replication Server 8989 1740,cn=dc_example_dc_com,cn=replication,cn=monitor current-send-window: 100 dn: cn=Replication Domain 27742,cn=cn_admin data,cn=replication,cn=monitor current-send-window: 100
同時に同じエントリで複数の操作が実行されると、レプリケーションの競合が発生する可能性があります。場合によっては、レプリケーション・メカニズムによって競合を解決できます。手動の競合解決が必要な場合もあります。
3種類の競合属性を監視できます:
unresolved-naming-conflicts。レプリケーション・メカニズムによって解決できない名前の競合の数を示します。
resolved-naming-conflicts。解決された名前の競合の数を示します。
resolved-modify-conflicts。解決された変更の競合の数を示します。
解決済のレプリケーションの競合および未解決のレプリケーションの競合を監視するには、次のコマンドを実行します:
$ ldapsearch -p 4444 -D "cn=directory manager" -j pwd-file --useSSL --trustAll \ -b "cn=monitor" "(&(unresolved-naming-conflicts=*) \ (resolved-naming-conflicts=*) (resolved-modify-conflicts=*))" \ "unresolved-naming-conflicts" "resolved-naming-conflicts" \ "resolved-modify-conflicts" dn: cn=Replication Domain 30839,cn=dc_example_dc_com,cn=replication,cn=monitor resolved-naming-conflicts: 0 unresolved-naming-conflicts: 0 resolved-modify-conflicts: 0 dn: cn=Replication Domain 14142,cn=cn_schema,cn=replication,cn=monitor resolved-naming-conflicts: 0 unresolved-naming-conflicts: 0 resolved-modify-conflicts: 0 dn: cn=Replication Domain 27742,cn=cn_admin data,cn=replication,cn=monitor resolved-naming-conflicts: 0 unresolved-naming-conflicts: 0 resolved-modify-conflicts: 0
様々な汎用UNIXツールを使用して、サーバー環境を監視できます。これらのツールの詳細は、UNIXシステムのマニュアル・ページを参照してください。
Oracle Unified Directoryでは次の汎用UNIX監視ツールを使用できます。
| ツール | 説明 |
|---|---|
|
|
ディスクI/OおよびCPUの使用量に関する情報を提供します。 |
|
|
オープン・ファイル・ディスクリプタに関する情報を提供します。 |
|
|
ファイル・システム・ロックに関する情報を提供します。 |
|
|
ネットワーク機能の統計を提供します。 |
|
|
ホストおよびドメインに関する情報をDNSサーバーに問い合せることができます。 |
|
|
リモート・ホストまたはネットワーク・ゲートウェイのステータスを問い合せることができます。 |
|
|
UNIXシステムVのパフォーマンス監視ツール。 |
|
|
ネットワーク・トラフィックをデバッグおよび監視できます。 |
|
|
プロセスおよびCPUアクティビティの素早く簡単な監視を提供します。 |
|
|
プロセスが行うシステム・コールに関する情報を提供します。 |
|
|
最終宛先に到達するためにインターネット全体でパケットが取るパスを提供します。 |
|
|
プロセス、仮想メモリー、ディスク、トラップおよびCPUアクティビティに関する統計を提供します。 |
Oracle Unified Directoryでは次のSolarisの監視ツールを使用できます。
| ツール | 説明 |
|---|---|
|
|
OSおよびアプリケーションのロックに関する情報を提供します。DTrace権限が必要です。 |
|
|
システムの各プロセッサに関する統計を提供します。 |
|
|
プロセスで使用しているメモリーのブレークダウンを提供します。 |
|
|
プロセスおよびスレッドを監視します。 |
|
|
ネットワーク・トラフィックを監視します。低レベルのパケットをデバッグする際には必須です。 |
|
|
前述のツールなどの機能を提供します。 |
|
|
プロセスが行うシステム・コールに関する情報を提供します。 |
Oracle Unified Directoryでは次のHP-UXの監視ツールを使用できます。
| ツール | 説明 |
|---|---|
|
|
オープン・ファイル・ディスクリプタ、ロックおよびスレッドに関する詳細システム情報を提供します。 |
|
|
GlancePlusは、グラフィカル・リアルタイム・パフォーマンス診断ツールです。Glanceは文字ベースのコンポーネントです。 |
|
|
システム・コール・トラップ機能を提供します。 |
|
|
カーネル・パラメータに関する情報を提供します。 |
|
|
ネットワーク統計を監視します。 |
|
|
一般的なシステム管理ツールを提供します。 |
