35 Oracle Unified Directoryのモニタリング
トピック
35.1 モニタリング情報の概要
ログおよびアラートを使用して、モニタリング情報やパフォーマンス・データを確認できます。また、LDAPおよびSNMPを使用してサーバーをモニターすることもできます。
-
ログ
ログの構成の詳細は、「ログの構成」を参照してください。
-
アラート
アラートの構成の詳細は、「アラートおよびアカウント・ステータス通知ハンドラの構成」を参照してください。
-
cn=monitor
cn=monitor
の詳細は、「LDAPを使用したサーバーのモニタリング」を参照してください。 -
RFC 2605で定義されている
DIRECTORY_SERVER_MIB
SNMPを使用したサーバーのモニタリングの詳細は、「SNMPを使用したサーバーのモニタリング」を参照してください。
モニタリング情報にアクセスするには、必要なプロトコルを持っていることを確認します:
-
ログの場合、ファイル・システムが必要です。
-
アラートの場合、JMX:RMIまたはSMTPが必要です。
-
cn=monitor
の場合、LDAPまたはJMX:RMI (たとえばjconsole)が必要です。 -
DIRECTORY_SERVER_MIBの場合、SNMPが必要です。
35.2 モニター・プロバイダの構成
モニター・プロバイダは、デフォルトで有効になっており、モニタリング目的またはトラブルシューティング目的で役に立つサーバーの情報を提供します。cn=monitor
エントリには、モニター・プロバイダによって公開されるモニタリング情報が含まれています。
モニター・プロバイダが無効になっていると、提供される情報をcn=monitor
の下で使用できなくなります。
モニター・プロバイダは、dsconfig
コマンドを使用して構成できます。詳細は、「dsconfigを使用したサーバー構成の管理」を参照してください。
この項には次のトピックが含まれます:
35.2.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
35.2.2 モニター・プロバイダの無効化
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
35.3 ログの構成
Oracle Unified Directoryでは、アクセス・ログ、監査ログ、エラー・ログ、デバッグ・ログ、レプリケーション修復ログなど、様々なタイプのログが提供されます。レプリケーション修復ログは読取り専用であり、レプリケーションの競合解決を有効にする場合のみ使用できます。
次の各トピックでは、dsconfig
コマンド行インタフェースまたはOracle Unified Directory Services Managerを使用して、アクセス・ログ、監査ログ、エラー・ログおよびデバッグ・ログを構成する方法を説明します。
また、この項では、管理操作のログ方法も説明します。
ログの結果コードの詳細は、「結果コード」を参照してください。
35.3.1 dsconfig
を使用したログの構成
dsconfig
を使用してロギングを構成する最も簡単な方法は、このコマンドを対話モードで使用して、構成に導いてもらうことです。
この項では、非対話モードで必要なコマンドを示し、設定される特定のパラメータがわかるようにします。dsconfig
の詳細は、「dsconfigを使用したサーバー構成の管理」を参照してください。
ログ構成には、次の3つの構成オブジェクトの定義が含まれています:
-
ログ・パブリッシャ。ログ・パブリッシャは、各ロガーに対して定義されます。ログ・パブリッシャのタイプは、ログのタイプに対応します。ログ・パブリッシャの詳細は、「ログ・パブリッシャの構成」を参照してください。
-
ログ保存ポリシー。保存ポリシーによって、アーカイブされたログ・ファイルの格納期間が決まります。ログ保存ポリシーの詳細は、「ログ保存ポリシーの構成」を参照してください。
-
ログ・ローテーション・ポリシー。ローテーション・ポリシーによって、ログ・ファイルのローテーション頻度が決まります。ログ・ローテーション・ポリシーの詳細は、「ログ・ローテーション・ポリシーの構成」を参照してください。
- HTTP/HTTPS操作のログの構成
35.3.1.1 ログ・パブリッシャの構成
Oracle Unified Directoryは、デフォルトでいくつかのログ・パブリッシャを提供します。
任意のタイプのログ・パブリッシャを任意の数定義して、いつでもアクティブにできます。つまり、様々な場所または様々なタイプのリポジトリにログでき、ログに含めるものに関して様々な条件セットを指定できます。
ログ・パブリッシャに関連付けられている構成プロパティの詳細は、『Oracle Unified Directory構成リファレンス』を参照してください。
この項には次のトピックが含まれます:
35.3.1.1.2 ログ・パブリッシャの有効化
すべてのログ・パブリッシャがデフォルトで有効になっているわけではありません。ログ・パブリッシャが無効になっている場合、そのタイプのメッセージはログされません。
ログ・パブリッシャを有効にするには、その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
ログ・パブリッシャが有効になると、サーバーは、適切なパブリッシャへのメッセージのロギングをすぐに開始します。この変更を有効にするためにサーバーを再起動する必要はありません。
35.3.1.1.3 ログ・パブリッシャの削除
dsconfig
コマンドを使用すると、既存のログ・パブリッシャを削除できます。
ログ・パブリッシャを削除するには、たとえばFile-Based Audit Logger
に次のコマンドを実行します。
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ delete-log-publisher --publisher-name "File-Based Audit Logger"
ロガーが正常に削除されます。
ノート:
監査ロガーはFile-Based Access Log
です。そのため、File-Based Audit Logger
を作成するには、対話モードでadvanced
オプションを使用して次のdsconfig
コマンドを実行し、Javaクラスをorg.opends.server.loggers.TextAuditLogPublisher
に設定する必要があります。
$ dsconfig -X -j pwd-file --advanced
または、次のようにdsconfig
コマンドの非対話モードを使用して、監査ロガーを作成することもできます。
dsconfig create-log-publisher \ --set enabled:false \ --set log-file:log/myauditlog \ --set java-class:org.opends.server.loggers.TextAuditLogPublisher \ --type file-based-access \ --publisher-name myauditlog \ --hostname localhost \ --port 4444 \ --trustAll \ --bindDN cn=Directory Manager \ --bindPasswordFile /tmp/password.txt \ --no-prompt
35.3.1.1.4 ODL形式でのロギング
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
このコンテンツは、OUDバンドル・パッチ12.2.1.4.211008以降のリリースにのみ適用されます。
ノート:
ODLロガーを有効にした後に標準ファイル・ベースのロガーを無効にする必要があります(特別に両方の形式のログを保持する場合を除く)。ファイルへの書込みはコストのかかる操作であり、パフォーマンスに影響します。
ODLの詳細(ログ・ファイルの形式の説明を含む)は、『Oracle Fusion Middleware管理者ガイド』のログ・ファイルと診断データの管理に関する項を参照してください。
35.3.1.1.5 内部操作のロギング
バージョン11.1.2.3以降で内部操作をログに記録するには、add operations-to-log
プロパティをinternal
に設定します。
11.1.2.2以前のバージョンでは、ログ・パブリッシャのsuppress-internal-logging
プロパティの値をfalse
に設定すれば、内部操作をログに記録できました。バージョン11.1.2.3以降では、suppress-internal-logging
プロパティが非推奨になりました。現在はadd operations-to-log
を使用すれば、内部操作(LDIF接続ハンドラおよび特定のプラグインによって実行される操作など)をログに記録できます。デフォルトでは、このプロパティはinternal
に設定されています。add operations-to-log
プロパティの値がinternal
の場合は、内部操作が自動的にログに記録されます。
次の例では、ファイルベースのアクセス・ロガーのadd operations-to-log
プロパティがinternal
に設定されています。
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
35.3.1.1.6 追加接続の詳細のロギング
log-connection-details
フラグがtrue
に設定されている場合、LDAP操作のログ・メッセージには、bindDN、プロトコル、クライアントおよびサーバーのIPアドレスなどの追加の詳細が含まれます。
セキュアなチャネルを介して接続が行われると、TLSバージョンおよびネゴシエートされた暗号スイートもログに記録されます。
ノート:
SSL接続情報を記録できるようになりました。これにより、SSLの問題を柔軟かつ効果的に分析およびデバッグできます。次のコマンドは、ファイルベースのアクセス・ロガーのlog-connection-details
フラグをtrue
に設定する方法について説明しています。
dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
set-log-publisher-prop --publisher-name "File-Based Access Logger" \
--set log-connection-details:true
35.3.1.1.7 ローカル・タイムスタンプを使用したログ・ファイルのローテーション名の構成
デフォルトでは、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 "File-Based Access Logger" \ --set log-file-use-local-time:true
ノート:
ローカル・タイムスタンプを使用したローテーション・ログ・ファイル名は、互換性を確保するためにOracle Directory Server Enterprise Editionで使用する形式に従います。
35.3.1.2 ログ保存ポリシーの構成
ログ保存ポリシーによって、ログ・ファイルのサイズと容量の制限が決定されます。Oracle Unified Directoryには、次の3つのログ保存ポリシーが用意されています。
-
ファイル数保存(
file-count
)。デフォルトでは、このポリシーは、指定したタイプのログ・ファイルの最大ログ・ファイル数を10に設定します。 -
空きディスク領域保存(
free-disk-space
)。デフォルトでは、このポリシーは、指定したタイプのログ・ファイルの残りの最小空きディスク領域の制限を500MBに設定します。 -
サイズ制限保存(
size-limit
)。デフォルトでは、このポリシーは、指定したタイプのログ・ファイルの使用されるディスク領域を最大500MBに設定します。
デフォルトでは、有効になっているログ保存ポリシーは、ファイル数保存です。
独自のカスタム・ログ保存ポリシーを作成することも可能です。詳細は、「ログ保存ポリシーの作成」を参照してください。
この項では、次の項目について説明します。
35.3.1.2.1 ログ保存ポリシーの表示
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"-j
pwd-file-X
-n
\ get-log-retention-policy-prop --policy-name "Free Disk Space Retention Policy"
35.3.1.2.2 ログ保存ポリシーの作成
dsconfig
コマンドを使用すると、ログ保存ポリシーを作成できます。
次のようにこのコマンドを実行して、ログ保存ポリシーを作成し、それが有効になるように設定します。
$ dsconfig -h localhost -p 4444-D
"cn=Directory Manager"-w
pwd-file-X
-n
create-log-retention-policy --policy-name MyMaxDiskSpace \ --type size-limit --set disk-space-used:100mb
35.3.1.2.3 ログ保存ポリシーの変更
dsconfig
コマンドを使用すると、既存のログ保存ポリシーを変更できます。
次のようにコマンドを実行します。
$ dsconfig -h localhost -p 4444-D
"cn=Directory Manager"-w
pwd-file-X
-n
\ set-log-retention-policy-prop --policy-name "File Count Retention Policy" \ --set number-of-files:20
プロパティ値を設定するかわりに、--add
、--reset
または--remove
サブコマンドを--set
サブコマンドのかわりに使用して、プロパティ値を追加、リセットまたは削除できます。詳細は、「dsconfig」を参照してください
35.3.1.3 ログ・ローテーション・ポリシーの構成
ログ・ローテーション・ポリシーは、ファイルをローテーションする頻度(つまり、ログ・ファイルが様々な条件に基づいて保持される期間)を決定します。
この項では、次の項目について説明します。
35.3.1.3.1 ログ・ローテーション・ポリシーの概要
Oracle Unified Directoryには、次の4つのログ・ローテーション・ポリシーがあります。
-
24時間制限のローテーション・ポリシー。デフォルトでは、このポリシーは、ローテーション間隔を1日に設定します。時刻を構成できます。
-
7日間制限のローテーション・ポリシー。デフォルトでは、このポリシーは、ローテーション間隔を1週間に設定します。時刻を構成できます。
-
固定時間制限のローテーション・ポリシー。デフォルトでは、このポリシーは、ログ・ファイルをローテーションする時刻を深夜の1分前に設定します。
-
サイズ時間制限のローテーション・ポリシー。デフォルトでは、このポリシーは、ログ・ファイルが到達できる最大サイズを100MBに設定し、これに到達するとログ・ファイルはローテーションされます。
ノート:
複数のローテーション・ポリシーが同じログに対して指定された場合、到達した最初のしきい値によってローテーションがトリガーされます。
デフォルトで有効になっているログ・ローテーション・ポリシーのタイプは、ログ・タイプによって異なります。
-
アクセス・ログと監査ログでは、次のポリシーが有効になっています:
-
24時間制限のローテーション・ポリシー
-
サイズ時間制限のローテーション・ポリシー
-
-
エラー・ログとレプリケーション修復ログでは、次のポリシーが有効になっています:
-
7日間制限のローテーション・ポリシー
-
サイズ時間制限のローテーション・ポリシー
-
独自のカスタム・ログ・ローテーション・ポリシーを作成することも可能です。
35.3.1.3.2 ログ・ローテーション・ポリシーの表示
dsconfig
コマンドを使用すると、既存のログ・ローテーション・ポリシーを表示できます。
次のようにコマンドを実行します。
$ dsconfig -h localhost -p 4444-D
"cn=Directory Manager"-j
pwd-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"-j
pwd-file-X
-n
\ get-log-rotation-policy-prop "Fixed Time Rotation Policy"
35.3.1.3.3 ログ・ローテーション・ポリシーの作成
dsconfig
コマンドを使用すると、ログ・ローテーション・ポリシーを作成できます。
ポリシー・タイプは次のいずれかにできます:
-
size-limit
-
fixed-time
-
time-limit
次のようにコマンドを実行します。
$ dsconfig -h localhost -p 4444-D
"cn=Directory Manager"-j
pwd-file-X
-n
\ create-log-rotation-policy --policy-name my2DayPolicy \ --type time-limit --set rotation-interval:2d
35.3.1.3.4 特定のログ・ファイルへのログ・ローテーションまたはログ保存の設定
特定のログ・ファイルにローテーション・ポリシーまたは保存ポリシーを設定するには、ログ・パブリッシャを作成し、ログ・ローテーション・ポリシーまたはログ保存ポリシーを設定する必要があります。
次のように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
35.3.1.4 HTTP/HTTPS操作のログの構成
次のトピックでは、HTTP/HTTPS操作用に構成できる様々なタイプのロガーについて説明します:
35.3.1.4.1 SCIMおよびREST操作のアクセス・ロガーの概要
OUDでは、詳細なHTTPログ・パブリッシャが、SCIMおよびREST操作のリクエストおよびレスポンスの詳細を取得するために、World Wide Web Consortium (W3C)とNagios Service Check Acceptor (NSCA)の2つの異なるログ・フォーマットで提供されます。
次のHTTPアクセス・ロガーは、SCIMおよびRESTのリクエストおよびレスポンスの詳細を取得するのに役立ちます。
ノート:
log-connection-details
フラグをtrue
に設定すると、TLSバージョンおよびネゴシエートされた暗号スイートも、ログのx-additional-details
列の一部として失敗したシナリオの適切なエラー・メッセージとともに取得されます。
- HTTP W3Cロガー:
HTTP操作ごとに、W3C形式のログには、(スペースで区切られた)各フィールドの値が次の順序で格納されます:
date c-ip cs-username s-ip cs-method cs-uri-stem cs-uri-query sc-status sc-bytes cs-bytes time-taken cs-version cs(User-Agent) cs(Cookie) cs(Referer) x-additional-details
次のコマンドは、W3Cロガーの
log-connection-details
フラグをtrue
に設定する方法について説明しています:dsconfig -h localhost -p 8081 -D "cn=Directory Manager" -j pwd-file -X -n \ set-log-publisher-prop --publisher-name "File-Based HTTP W3C Access Logger" \ --set "log-connection-details:true"
- HTTP NSCAロガー:
HTTP操作ごとに、NSCA形式のログには、(スペースで区切られた)各フィールドの値が次の順序で格納されます:
remote-host user-identifier auth-user request date status bytes referrer user-agent cookie connection-id etime x-additional-details
次のコマンドは、NSCAロガーの
log-connection-details
フラグをtrue
に設定する方法について説明しています:dsconfig -h localhost -p 8081 -D "cn=Directory Manager" -j pwd-file -X -n \ set-log-publisher-prop --publisher-name "File-Based HTTP NSCA Access Logger" \ --set "log-connection-details:true"
35.3.1.4.2 管理アクセス・ロガーの概要
HTTP経由で実行される管理操作の場合、アクセス・ログ・メッセージには、ファイルベースのHTTP管理ロガーのaccess-log-format-mode
プロパティ用に構成された値(w3cまたはnsca)に従った情報が格納されます。
ノート:
log-connection-details
フラグをtrue
に設定すると、管理操作のログ・メッセージに追加の詳細(暗号スイート、TLSバージョン、適切なエラー・メッセージなど)が表示されます。
次のコマンドは、ファイルベースのHTTP管理ロガーのlog-connection-details
フラグをtrue
に設定する方法について説明しています:
dsconfig -h localhost -p 8444 -D "cn=Directory Manager" -j pwd-file -X -n \
set-log-publisher-prop --publisher-name "File-Based HTTP Admin Logger" \
--set "log-connection-details:true"
ノート:
管理ロガーでは、W3CおよびNSCAに対して「SCIMおよびREST操作のアクセス・ロガーの概要」で定義されている形式と同じ形式がサポートされています。35.3.2 OUDSMを使用したログの構成
Oracle Unified Directory Services Manager (OUDSM)を使用すると、ログ出力プロパティ、ログ・ローテーション・ポリシーおよびログ保存ポリシーを構成できます。
次の各トピックでは、OUDSMを使用してログを構成する方法について説明します。
35.3.2.1 ロガー・プロパティの変更
Oracle Unified Directoryは、デフォルトでいくつかのログ・パブリッシャ(またはロガー)を提供します。任意のタイプのロガーを任意の数定義して、いつでもアクティブにできます。つまり、様々な場所または様々なタイプのリポジトリにログでき、ログに含めるものに関して様々な条件セットを指定できます。
OUDSMを使用して新規ログ・パブリッシャを作成できませんが、既存のログ・パブリッシャのプロパティを変更できます。
OUDSMを使用してロガー・プロパティを構成するには:
35.3.2.2 ログ・ローテーション・ポリシーの変更
ログ・ファイルをローテーションする頻度(つまり、ログ・ファイルが様々な条件に基づいて保持される期間)は、ログ・ローテーション・ポリシーによって決まります。
Oracle Unified Directoryには、次の4つのログ・ローテーション・ポリシーがあります。
-
24時間制限のローテーション・ポリシー。デフォルトでは、このポリシーは、ローテーション間隔を1日に設定します。時刻を構成できます。
-
7日間制限のローテーション・ポリシー。デフォルトでは、このポリシーは、ローテーション間隔を1週間に設定します。時刻を構成できます。
-
固定時間制限のローテーション・ポリシー。デフォルトでは、このポリシーは、ログ・ファイルをローテーションする時刻を深夜の1分前に設定します。
-
サイズ時間制限のローテーション・ポリシー。デフォルトでは、このポリシーは、ログ・ファイルが到達できる最大サイズを100MBに設定し、これに到達するとログ・ファイルはローテーションされます。
デフォルトで有効になっているログ・ローテーション・ポリシーのタイプは、ロガー・タイプによって異なります。
OUDSMを使用してログ・ローテーション・ポリシーを構成するには:
- 「OUDSMを使用したサーバーへの接続」の説明に従って、OUDSMからディレクトリ・サーバーに接続します。
- 「構成」タブを選択します。
- 「一般構成」要素を展開します。
- 「ロギング」要素を展開します。
- 「ローテーション・ポリシー」要素を選択し、必要なプロパティを変更します。
このページで「追加」アイコンや「削除」アイコンをクリックし、必要な情報を入力することによって、新規ローテーション・ポリシーの追加や既存のローテーション・ポリシーの削除も行えます。
35.3.2.3 ログ保存ポリシーの変更
ログ保存ポリシーによって、ログ・ファイルのサイズと容量の制限が決定されます。Oracle Unified Directoryには、デフォルトで次の3つのログ保存ポリシーが用意されています。
-
ファイル数保存(file-count)。デフォルトでは、このポリシーは、指定したタイプのログ・ファイルの最大ログ・ファイル数を10に設定します。
-
空きディスク領域保存(free-disk-space)。デフォルトでは、このポリシーは、指定したタイプのログ・ファイルの残りの最小空きディスク領域の制限を500MBに設定します。
-
サイズ制限保存(size-limit)。デフォルトでは、このポリシーは、指定したタイプのログ・ファイルの使用されるディスク領域を最大500MBに設定します。デフォルトでは、有効になっているログ保存ポリシーは、ファイル数保存です。
OUDSMを使用してログ保存ポリシーを構成するには:
- 「OUDSMを使用したサーバーへの接続」の説明に従って、OUDSMからディレクトリ・サーバーに接続します。
- 「構成」タブを選択します。
- 「一般構成」要素を展開します。
- 「ロギング」要素を展開します。
- 「保存ポリシー」要素を選択し、必要なプロパティを変更します。
このページで「追加」アイコンや「削除」アイコンをクリックし、必要な情報を入力することによって、新規保存ポリシーの追加や既存の保存ポリシーの削除も行えます。
35.3.3 アクセス・ログ・パブリッシャへの操作のロギング
Oracle Unified Directoryの新規パラメータadmin loggerを使用すると、ログに記録する操作と、その記録した操作をアクセス・ログ・パブリッシャで構成する方法を指定できます。
35.3.3.1 管理ロガーの概要
Oracle Unified Directoryには、管理コネクタを使用して管理ログをユーザー・ログから分離するメカニズムがあります。管理操作は、管理トラフィックと関連付けられたロギング情報を提供する異なるファイルにログされるようになります。
ノート:
Oracle Unified Directoryは、デフォルトで管理コネクタの操作のみを含むファイルベースの管理アクセス・ロガー
という専用アクセス・ロガーをサポートしています。したがって、異なるファイルに管理操作を記録するために特別なアクションを実行する必要はありません。
operations-to-log
プロパティを使用して、アクセス・ログを構成してログに記録する操作のタイプを指定できます。このプロパティはオプションで、次構成可能な値を持っています:
-
SYNCHRONIZATION
-
INTERNAL
-
ADMINISTRATION
-
USER
-
ADMIN_BROWSING
-
ALL
この意味では、Oracle Unified Directoryは、次の操作タイプをサポートしています。
-
同期操作
ロック、プロセス同期、属性マッピング、変換などの同期操作。
-
内部操作
内部操作は、クライアントからの外部リクエストによってではなく、プラグインによって内部的に開始されるため、内部的です。クライアントのリクエストが存在しない操作を実行するためにプラグインがディレクトリ・サーバーを必要とする場合、内部操作コールを使用する必要があります。
-
管理操作
管理操作は、ネットワーク・グループ選択コントロールに関連付けられた操作を除いて、管理ネットワーク・グループに対して実行されます。
-
ユーザー操作
ユーザー操作は、ネットワーク・グループ選択コントロールに関連付けられた操作を除いて、任意のユーザー・ネットワーク・グループに対して実行されます。
-
管理参照操作
管理参照操作は、ネットワーク・グループ選択コントロールと関連付けられています。これは、ネットワーク・グループ依存に関連付けられた操作を除外します。
ノート:
ネットワーク・グループによって処理された操作はユーザーによって作成され、管理接尾辞にアクセスすることはユーザー操作と見なされます。
35.3.4 監査ログでの属性のマスク
Oracle Unified Directoryを使用すると、監査ログで特定の属性をマスクできます。
この節では、以下のトピックについて説明します。
35.3.4.1 監査ログでの属性のマスクの概要
Oracle Unified Directoryを使用すると、userpassword
などの特定の属性を監査ログに表示する方法を制御できます。
デフォルトでは、Oracle Unified Directoryは5つのアスタリスク文字列(*****
)を使用して監査ログで次の属性をマスクするため、認識できる値はありません。マスクされていない属性は、クリアで表示されます(暗号化された属性またはパスワードでない場合)。
-
サーバーで定義されたパスワード属性
-
暗号化として定義された属性
-
監査ログでマスク対象のユーザー指定の属性のリスト
ノート:
属性マスキングは、監査ログが有効になっている場合にのみ関係します。監査ログ・ファイルは次の場所にあります。
<OUD_INSTALLATION_PATH>/OUD/logs/audit
表35-1は、パスワード属性、暗号化された属性およびユーザー指定属性を監査ログに表示する方法を制御するパラメータを示しています。
表35-1 監査ログ・マスキングの構成パラメータ
名前 | 形式 | デフォルト値 | 単一値/複数値 | オプション | 説明 |
---|---|---|---|---|---|
|
ブール値( |
true |
S |
はい |
パスワード・マスキングを有効化または無効化します。
|
|
ブール値( |
true |
S |
はい |
監査ログでどの属性および接尾辞の値をマスクするかを決定するデータ暗号化構成を有効化または無効化します。
ノート: このパラメータの |
|
1つの属性名またはOIDを表す文字列。 |
なし |
M |
はい |
マスクする属性のリストを定義するために使用します。
このパラメータは、 |
|
1つの接尾辞を表す文字列 |
なし |
M |
はい |
マスクする接尾辞のリストを定義するために使用します。
このパラメータは、 |
標準のdsconfig
コマンド、または対話モードでdsconfig
を使用して、これらのパラメータを読み取り、変更できます。最も簡単な方法は、ウィザードのように機能する対話モードでdsconfig
を使用する方法です。対話モードは説明不要であるため、この項では対話モードを使用して監査ログの構成を変更する手順は説明しませんが、同等のdsconfig
コマンドについて説明します。
ノート:
dsconfig
の使用方法の詳細は、「dsconfigコマンドの使用」および「対話モードでのdsconfigの使用」を参照してください。
35.3.4.2 監査ログ・マスキングの構成
dsconfig
コマンドを使用すると、監査ログ・マスキングを構成できます。
次のようにコマンドを実行します。
./dsconfig -n -X -h localhost -p 1444 -D "cn=Directory Manager" -j /security/password set-log-publisher-prop --publisher-name "File-Based Audit Logger" --set "maskpasswords:true" ./dsconfig -n -X -h localhost -p 1444 -D "cn=Directory Manager" -j /security/password get-log-publisher-prop --publisher-name "File-Based Audit Logger" Property : Value(s) -------------------------------:----------------------------------------------- append : true enabled : false log-file : logs/audit log-file-permissions : 640 log-file-use-local-time : false mask-passwords : true masked-attribute : - masked-suffix : - masking-uses-encryption-config : true operations-to-log : adminbrowsing, administration, : synchronization, user retention-policy : File Count Retention Policy rotation-policy : 24 Hours Time Limit Rotation Policy, Size : Limit Rotation Policy
ノート:
構成変更はすぐに有効になりますが、過去にさかのぼることはありません。監査ログ構成エントリの更新は、監査ログ・ファイルの将来のログのみに影響します。
35.4 アラートおよびアカウント・ステータス通知ハンドラの構成
Oracle Unified Directoryには、JMX拡張子またはSMTP拡張子によってアラートおよびアカウント・ステータス通知を転送するメカニズムがあります。ディレクトリ・サーバーを構成して、処理中にイベントが発生したときにアラート通知を送信できます。
一般的なサーバー・イベントには、サーバーの起動とシャットダウン、サーバーによって検出される問題(構成ファイルに書き込もうとするなど)が含まれます。
パスワード・ポリシーの処理中にイベント(アカウントのロック・アウト、アカウントの期限切れ、パスワードの期限切れなど)が発生したときにアカウント・ステータス通知を受信することも可能です。
アラートとアカウント・ステータス通知ハンドラは、dsconfig
コマンドを使用して構成されます。詳細は、「dsconfigを使用したサーバー構成の管理」を参照してください。
この項の各トピックの詳細は、「パスワード・ポリシーの管理」および『Oracle Unified Directory構成リファレンス』のアラート・ハンドラ構成に関する項を参照してください。
この項では、次の項目について説明します。
35.4.1 アラート・ハンドラの管理
Oracle Unified Directoryには、JMX拡張子またはSMTP拡張子によってアラートおよびアカウント・ステータス通知を転送するメカニズムがあります。
処理中にイベントが発生したらアラート通知を送信するようにOracle Unified Directoryを構成できます。一般的なサーバー・イベントには、サーバーの起動とシャットダウン、サーバーによって検出される問題(構成ファイルに書き込もうとするなど)が含まれます。パスワード・ポリシーの処理中にイベント(アカウントのロック・アウト、アカウントの期限切れ、パスワードの期限切れなど)が発生したときにアカウント・ステータス通知を受信することも可能です。
Oracle Unified Directoryでは、次のアラート・ハンドラがサポートされます。
-
JMX通知用のJMXアラート・ハンドラ
-
電子メール通知用のSMTPアラート・ハンドラ
次のトピックでは、アラート・ハンドラ構成の管理方法を説明します:
-
dsconfigを使用したアラート・ハンドラの管理
35.4.1.1 dsconfig
を使用したアラート・ハンドラの管理
dsconfig
コマンドを使用すると、アラート・ハンドラ構成を管理できます。OUDSMインタフェースを使用したアラートの構成の詳細は、「OUDSMを使用したアラート・ハンドラの管理」を参照してください。
この項では、次の項目について説明します。
35.4.1.1.1 構成済のアラート・ハンドラの表示
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
35.4.1.1.2 アラート・ハンドラの有効化
JMXアラート・ハンドラはデフォルトでは無効になっています。開始する前に、サーバー上でJMXを構成する必要があります。詳細は、「JConsoleを使用したサーバーのモニタリング」を参照してください。
35.4.1.1.3 新規アラート・ハンドラの作成
この項の例では、新規SMTPハンドラを構成します。この手順を開始する前に、Oracle Unified DirectoryのSMTPサーバーが構成済である必要があります。
35.4.1.1.4 アラート・ハンドラの削除
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"
アラート・ハンドラを削除するかわりに、これを単に無効にできます。この場合、将来このアラート・ハンドラを再有効化する必要がある場合、これを使用できます。詳細は、「許可されているアラート・タイプのコントロール」を参照してください。
35.4.1.1.5 許可されているアラート・タイプのコントロール
Oracle Unified Directoryは、デフォルトではサポートされているアラート・タイプが許可されます。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
35.4.1.2 OUDSMを使用したアラート・ハンドラの管理
OUDSMを使用すると、アラート・ハンドラ構成を管理できます。dsconfig
を使用したアラート・ハンドラの構成の詳細は、「dsconfigを使用したアラート・ハンドラの管理」を参照してください。
この項では、次の項目について説明します。
35.4.1.2.2 アラート・ハンドラの変更
OUDSMを使用して既存のアラート・ハンドラを変更するには:
- 「OUDSMを使用したサーバーへの接続」の説明に従って、OUDSMからディレクトリ・サーバーに接続します。
- 「構成」タブを選択します。
- 「一般構成」要素を展開します。
- 「アラート・ハンドラ」要素を展開します。
- 変更するプロパティを持つアラート・ハンドラを選択します。
- 右側のペインにプロパティが表示されます。
- 必要なプロパティを変更したら、「適用」をクリックします。
35.4.1.2.3 アラート・ハンドラの削除
OUDSMを使用して既存のアラート・ハンドラを削除するには:
- 「OUDSMを使用したサーバーへの接続」の説明に従って、OUDSMからディレクトリ・サーバーに接続します。
- 「構成」タブを選択します。
- 「一般構成」要素を展開します。
- 「アラート・ハンドラ」要素を展開します。
- 削除するアラート・ハンドラを選択し、「構成の削除」アイコンをクリックします。
- 削除の確認を求められます。「はい」をクリックします。
35.4.1.3 サポートされているアラート・タイプ
サーバーは、システムでアラート・タイプ・イベントが発生すると、メッセージ・アラートを送信します。サポートされているアラート・タイプは、次の表で定義されています。
アラート・タイプ | 説明 |
---|---|
アクセス制御無効 Javaクラス: |
アクセス・コントロール・ハンドラが無効になったことを管理者に通知します。 |
アクセス制御有効 Javaクラス: |
アクセス・コントロール・ハンドラが有効になったことを管理者に通知します。 |
アクセス制御の解析に失敗しました Javaクラス: |
サーバーを初めて起動したときに、Oracle Directory Server Enterprise Edition互換のアクセス・コントロール・サブシステムが1つ以上のACIルールを正しく解析できなかったことを管理者に通知します。 |
アクセス制御変更 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)をサポートしていない場合に発生します。 |
35.4.2 アカウント・ステータス通知ハンドラの管理
アカウント・ステータス通知ハンドラは、パスワード・ポリシーの処理中にイベントのアラートを提供します。デフォルトでは、エラー・ログ・アカウント・ステータス通知ハンドラは、初期構成時に有効に設定されます。
サーバーは、次のいずれかのイベントがパスワード・ポリシーで構成済で、パスワード・ポリシーの処理中にこれが発生した場合にメッセージをサーバーのエラー・ログに書き込みます。
-
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
にあります。
この項では、次の項目について説明します。
35.4.2.1 構成済のアカウント・ステータス通知ハンドラの表示
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
35.4.2.2 アカウント・ステータス通知ハンドラの有効化
dsconfig
コマンドを使用して、既存のアカウント・ステータス通知ハンドラを有効にします。デフォルトでは、ディレクトリ・サーバーは、サーバーが最初に構成されるときにエラー・ログ・ハンドラを有効にします。この例では、SMTP通知ハンドラを有効にします。
35.4.2.4 アカウント・ステータス通知ハンドラの削除
アカウント・ステータス通知ハンドラを削除するかわりにこれを無効にできます。この場合、将来このアラート・ハンドラを再有効化する必要がある場合、これを使用できます。
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"
35.4.2.5 SMTPアカウント・ステータス通知ハンドラのメッセージ・テンプレート・ファイルのカスタマイズ
電子メール通知メッセージの生成に使用されるメッセージ・テンプレートを含むメッセージ・テンプレート・ファイルをカスタマイズできます。
dsconfig
コマンドを実行して、次のようにSMTPアカウント・ステータス通知ハンドラで使用可能なメッセージ・テンプレート・ファイルを表示します:$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file --trustALL \
get-account-status-notification-handler-prop --handler-name "SMTP Handler" --property message-template-file
次のような出力結果が表示されます。
Property : Value(s)
------------------------:---------------------------------------------------------------------
message-template-file : account-disabled:config/messages/account-disabled.template,
: account-enabled:config/messages/account-enabled.template,
: account-expired:config/messages/account-expired.template,
: account-idle-locked:config/messages/account-idle-locked.template,
: account-permanently-locked:config/messages/account-permanently-locked.template,
: account-reset-locked:config/messages/account-reset-locked.template,
: account-temporarily-locked:config/messages/account-temporarily-locked.template,
: account-unlocked:config/messages/account-unlocked.template,
: password-changed:config/messages/password-changed.template,
: password-expired:config/messages/password-expired.template,
: password-expiring:config/messages/password-expiring.template
: password-reset:config/messages/password-reset.template
message-template-file
オプションは、前述のテンプレート・ファイルを使用して構成できます。ファイルは、OUD_INSTANCE
/OUD/config/messages
にあります。これらのテンプレート・ファイルには、すべてのアカウント・アクティビティに対するデフォルトの電子メール本文テキストがすでに含まれています。
プレースホルダを使用すると、メッセージ・テンプレートをカスタマイズして、ユーザーのDNやその他の属性、通知タイプなどの動的パラメータを含めることができます。サポートされているプレースホルダのリストは、次のとおりです。
プレースホルダ | 説明 |
---|---|
%%notification-type%% | 通知のタイプを指定します。 |
%%notification-message%% | 電子メールの件名を指定します。 |
%%notification-user-dn%% | ユーザーのdn を指定します。
|
%%notification-user-attr:sn%% | ユーザーのsn を指定します。
|
%%notification-user-attr:uid%% | ユーザーのuid を指定します。
|
%%notification-property:old-password%% | これは、password-changed通知タイプに適用されます。 |
%%notification-property:new-password%% | これは、password-changed通知タイプに適用されます。 |
%%notification-user-attr:<attribute_name>%% | ディレクトリ・エントリのその他の有効な<attribute_name>を指定します。たとえば、%%notification-user-attr:mail%%、%%notification-user-attr:phone%%などです。 |
35.5 LDAPを使用したサーバーのモニタリング
Oracle Unified Directoryには、デバッグまたはトラブルシューティングの目的でサーバーの現在の状態をモニターする様々な方法があります。
この項のトピックでは、サーバーでのプロバイダのモニタリングを構成済であることを前提としています。詳細は、「モニター・プロバイダの構成」を参照してください。
いくつかの方法でLDAPを介してサーバーをモニターできます。これらの機能については、次の各項で説明します:
35.5.1 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を介した管理ポートを使用します。詳細は、「サーバーへの管理トラフィックの管理」を参照してください。
この項には次のトピックが含まれます:
35.5.1.1 プロキシのモニターされる属性の概要
プロキシに関するモニタリング情報は、数十の属性(次のものに関係のある属性など)に関して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.0port
ポート番号,cn=monitor
の下 -
LDAP接続ハンドラ:
cn=LDAP Connection Handler
0.0.0.0port
ポート番号,cn=monitor
-
LDAP接続ハンドラ統計:
cn=LDAP Connection Handler
0.0.0.0port
ポート番号statistics
,cn=monitor
-
SNMP接続ハンドラ:
cn=SNMP Connection Handler,cn=Monitor
-
JMX接続ハンドラ:
cn=JMX Connection Handler
ポート番号,cn=monitor
-
管理コネクタ:
cn=Administration Connector
0.0.0.0port
ポート番号,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
エントリで使用してこれらの統計をすべてリストできます(「使用可能なモニタリング情報の表示」を参照)。cn=monitor
エントリへのアクセスは、ACIのバイパス権限を持つユーザーに制限されています。
次の手順は、コマンド行インタフェースでldapsearch
コマンドを使用します。
グローバル索引のレプリケーションに関するステータス情報を表示するには、gicadm status-replication
コマンドを使用します。詳細は、「レプリケートされたグローバル索引カタログ構成のステータスの表示」を参照してください
35.5.1.2 使用可能なモニタリング情報の表示
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
35.5.1.3 汎用サーバー情報のモニタリング
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=monitor currentTime: 20240111082026Z totalConnections: 7 vendorName: Oracle Corporation cn: monitor vendorVersion: Oracle Unified Directory 12.2.1.4.240213 version: Oracle Unified Directory 12.2.1.4.240213 currentConnections: 1 objectClass: top objectClass: ds-monitor-entry objectClass: extensibleObject upTime: 57 days 21 hours 18 minutes 30 seconds startTime: 20240110110156Z maxConnections: 1 productName: Oracle Unified Directory
35.5.1.4 システム情報のモニタリング
ldapsearchコマンドを使用すると、システム情報をモニターできます。
次のように、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: /export/home/oracle/OUD/asinst_1/OUD javaVersion: 1.8.0_211-b12 jvmArchitecture: 64-bit jvmArguments: "-Dorg.opends.server.scriptName=start-ds" jvmVersion: 24.65-b04 classPath: /export/home/oracle/OUD/asinst_1/OUD/classes:/export/home/oracle/OUD/ OracleUnifiedDirectory/winlib/classpath.jar:/export/home/oracle/OUD/asinst_1/OU D/lib/*.jar usedMemory: 69402624 freeUsedMemory: 23084640 objectClass: extensibleObject objectClass: top objectClass: ds-monitor-entry javaVendor: Oracle Corporation operatingSystem: Linux 2.6.32-200.13.1.el5uek amd64 cn: System Information systemName: sboy installPath: /export/home/oracle/OUD/OracleUnifiedDirectory workingDirectory: /export/home/oracle/OUD/asinst_1/OUD/bin availableCPUs: 2 maxMemory: 922746880 javaHome: /usr/lib/jvm/jdk8/jre jvmVendor: Oracle Corporation
35.5.1.5 バージョン情報のモニタリング
ldapsearch
コマンドを使用すると、バージョン情報をモニターできます。
次のように、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 componentVersion: 4 fullVersion: Oracle Unified Directory 12.2.1.4.240213 buildID: 20240215065722Z shortName: OUD compactVersion: OUD-12.2.1.4.240213 cn: Version version: Oracle Unified Directory 12.2.1.4.240213 objectClass: top objectClass: ds-monitor-entry objectClass: extensibleObject labelIdentifier: 2402130001 maintenanceVersion: 2 majorVersion: 12 releaseVersion: 1 platformVersion: 240213 productName: Oracle Unified Directory
35.5.1.6 ユーザー・ルート・バックエンドのモニタリング
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
35.5.1.7 バックアップ・バックエンドのモニタリング
ldapsearchコマンドを使用すると、バックアップ・バックエンドをモニターできます。
次のように、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
35.5.1.8 タスク・バックエンドのモニタリング
タスクは、ある将来の日付に処理または反復して処理を行うためにスケジュールできる管理機能(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
35.5.1.9 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
35.5.1.10 スキーマ・バックエンドのモニタリング
このモニターには、スキーマのバックエンドの一般プロパティ(書込み可能性モード、ベース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
35.5.1.11 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
35.5.1.12 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
35.5.1.13 クライアント接続のモニタリング
このモニターは、オープン状態のすべてのクライアント接続を表します。この内容は、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
35.5.1.14 LDAP接続ハンドラのモニタリング
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"
35.5.1.15 LDAP接続ハンドラの統計のモニタリング
ldapsearchコマンドを使用すると、LDAP接続ハンドラ統計をモニターできます。
次のように、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)
35.5.1.16 LDAP接続ハンドラの接続のモニタリング
このモニターは、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"
35.5.1.17 管理コネクタのモニタリング
このモニターは、管理コネクタの基本情報を提供します。詳細は、「サーバーへの管理トラフィックの管理」を参照してください。
次のように、ldapsearch
コマンドを"cn=LDAP Administration Connector 0.0.0.0 port 4444,cn=monitor"
のベースDNとともに実行します。
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -b "cn=LDAP Administration Connector 0.0.0.0 port 4444,cn=monitor" \ "(objectclass=*)"
構成に応じて、出力は次のようになります:
objectClass: top objectClass: ds-monitor-entry objectClass: ds-connectionhandler-monitor-entry dn: cn=LDAP 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
35.5.1.18 管理コネクタ統計のモニタリング
このモニターは、管理コネクタを介して実行される操作に関する広範な統計情報を提供します。詳細は、「サーバーへの管理トラフィックの管理」を参照してください。
次のように、ldapsearch
コマンドを"cn=LDAP Administration Connector 0.0.0.0 port 4444,cn=monitor"
のベースDNとともに実行します。
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll \ -b "cn=LDAP Administration Connector 0.0.0.0 port 4444,cn=monitor" \ "(objectclass=*)"
構成に応じて、出力は次のようになります:
dn: cn=LDAP 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)...
35.5.1.19 管理コネクタの接続のモニタリング
このモニターは、管理コネクタのオープン状態のクライアント接続を表します。
次のように、ldapsearch
コマンドを"cn=Client Connections,cn=LDAP 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=LDAP Administration Connector 0.0.0.0 \ port 4444,cn=monitor" \ "(objectclass=*)"
構成に応じて、出力は次のようになります:
objectClass: top objectClass: ds-monitor-entry objectClass: extensibleObject dn: cn=Client Connections,cn=LDAP 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
35.5.1.20 LDIF接続ハンドラのモニタリング
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
35.5.1.21 ワーク・キューのモニタリング
ワーク・キューは、未処理のクライアント・リクエストを追跡し、これらが確実に処理されるようにします。
次のように、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
35.5.1.22 JVMスタック・トレース情報のモニタリング
ディレクトリ・サーバー・インスタンスの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)...
35.5.1.23 JVMメモリー使用量のモニタリング
ldapsearch
コマンドを使用すると、JVMメモリーを構成できます。
次のように、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
35.5.1.24 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)...
35.5.1.25 データベース・キャッシュの管理
次の各トピックでは、データベース・キャッシュおよびそのモニター方法について説明します。
35.5.1.25.1 データベース・キャッシュの概要
データベース(DB)キャッシュは、Java Editionノードを格納するために使用されます。DBキャッシュは、ディレクトリ・サーバーのパフォーマンス全体の重要なコンポーネントです。DBキャッシュを注意深くチューニングしてモニターしてください。DBキャッシュには、次のノードが含まれています:
-
上位ノード
-
内部ノード
-
リーフ・ノード
上位ノードおよび内部ノードは内部Bツリー構造を表し、リーフ・ノードはユーザー・エントリを表します。可能な最高のパフォーマンスを得るためには、すべてのDBキャッシュ・ノードをDBキャッシュに配置することをお薦めします。DBキャッシュに少なくともBツリー内部構造(上位ノードおよび内部ノード)を含むようにDBキャッシュをサイズ設定することをお薦めします。DBキャッシュが短すぎると、多くの失敗および頻繁な削除が発生し、このことがディレクトリ・サーバーのパフォーマンスに悪影響する可能性があります。
キャッシュのサイズのチューニングは次の方法で行います:
-
dbcache-percent
の設定 -
Oracle Unified Directory JVMヒープ(特に古いもの)の適切なサイズ設定。
次のDBキャッシュ成功と失敗カウンタを以下に説明します:
カウンタ | 説明 |
---|---|
|
キャッシュからフェッチされた上位内部ノードの蓄積数。 |
|
失敗した上位内部ノードの蓄積数。 |
|
キャッシュからフェッチされた下位内部ノードの蓄積数。 |
|
失敗した上位内部ノードの蓄積数。 |
|
キャッシュからフェッチされたリーフ・ノードの蓄積数。 |
|
失敗したリーフ・ノードの蓄積数。 |
Oracle Unified Directoryが適切に機能するためには、すべてのノードを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)
可能な最高のパフォーマンスを得るためには、たとえば次のようにして、Oracle Unified Directoryもユーザー・エントリをDBキャッシュに配置することをお薦めします。
((DeltaNLNsMiss/DeltaNLNsFetch)*100)
できるかぎり0
に近づけます。
インポート完了後(およびデータ準備後)デルタ比を0
に近づけて開始し、時間の経過とともにデルタ比は、データベースのサイズの増加(レプリケーション・メタデータ、最小利用のクリアのインパクト、エントリ(新規アプリケーション)の増大、およびエントリ数が原因の)によって大きくなります。このため、(カスタム・スクリプトまたはUIを使用して) DBキャッシュをモニターし、適切なアクション(DBキャッシュのパーセントまたはOracle Unified Directory JVMヒープの増大など)を行うことをお薦めします。
35.5.1.25.2 データベース・キャッシュのモニタリング
ldapsearch
コマンドをcn=userRoot Database Environment,cn=monitor
のベースDNとともに使用すると、DBキャッシュをモニターできます。
次のようにコマンドを実行します。
$ 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)...
35.5.1.26 エントリ・キャッシュのモニタリング
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 ...
35.5.1.27 ネットワーク・グループのモニタリング
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 ...
35.5.1.28 分散のモニタリング
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 ...
35.5.1.29 ロード・バランシングのモニタリング
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
35.5.1.30 リモートLDAPサーバーのモニタリング
ldapsearch
コマンドを"cn=LDAP Servers,cn=monitor"
のベースDNとともに使用すると、リモートLDAPサーバーをモニターできます。
次のようにコマンドを実行します。
$ 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
35.5.1.31 グローバル索引のモニタリング
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
35.5.1.32 グローバル索引カタログのモニタリング
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
35.5.2 manage-tasks
コマンドを使用したモニタリング
Oracle Unified Directoryは、特定のタスク(import-ldif
、export-ldif
、backup
、restore
など)をスケジュールして処理するメカニズムを提供するタスク・バックエンドを提供します。タスクをスケジュールして、反復期間の特定の時刻に実行できます。
スケジュール済のタスクをモニターするには、manage-tasks
コマンドを使用します。詳細は、「タスクとしてのコマンドの構成」を参照してください。
35.5.3 JConsoleを使用したサーバーのモニタリング
JConsole (jconsole
) Javaユーティリティは、管理エージェントを使用して起動された実行中のJava仮想マシンに接続しているJMX準拠のグラフィカル・ツールです。この汎用ツールは、サーバー・モニタリング情報にアクセスするために使用できます。
この項では、次の項目について説明します。
35.5.3.2 JConsoleの起動
コンソールを起動するには、端末ウィンドウでjconsole
と入力する必要があります。
コマンド行からjconsole
を実行するには、JAVA_HOME/binをパスに追加する必要がある場合があります。ここで、JAVA_HOME
はJDKを含むディレクトリです。または、コマンドを入力するときにフルパスを入力することもできます。
35.5.3.3 JConsoleからサーバー・インスタンスにアクセスする方法の理解
JConsoleをサーバー・インスタンスに接続するには、リモート・プロセス・フィールドを使用します。次のフィールドが必要です:
-
JMX URL:
service:jmx:rmi:///jndi/rmi://''host'':''port''/org.opends.server.protocols.jmx.client-unknown
-
hostは、ホスト名、IPv4数値ホスト・アドレスまたは角括弧で囲まれたIPv6数値アドレスです。
-
portは、JMXコネクタの10進数のポート番号です。(「アラートおよびアカウント・ステータス通知ハンドラの構成」を参照。)
デフォルトのJMX URLは次のとおりです:
service:jmx:rmi:///jndi/rmi://198.51.100.0:1689/org.opends.server.protocols.jmx.client-unknown
-
-
「ユーザー名」。有効なLDAPユーザー名です。
デフォルトのディレクトリ・マネージャのユーザー名は
cn=Directory Manager
です。 -
パスワード。ユーザーのLDAPパスワードです。
35.5.4 ログへのアクセス
サーバーには、サーバー・インスタンスのアクセス、エラーまたはデバッグの情報を記録するロギング・メカニズムがあります。指定されたタイプの複数のロガーをいつでもアクティブにできるため、特定のサブツリーまたは異なるリポジトリのログを作成できます。サーバーは、ログの情報のタイプを制限するロギング・フィルタを現在提供していません。
この項では、次の項目について説明します。
35.5.4.1 様々なログ・タイプの理解
Oracle Unified Directoryでは、次のログがサポートされています。
-
アクセス・ログ。アクセス・ログには、ディレクトリ・サーバーによって処理された操作のタイプに関する情報が記録されます。アクセス・ログはデフォルトで提供されます。
-
監査ログ。監査ログは、アクセス・ログの一種で、ディレクトリ・サーバー上のすべてのアクティビティを記録します。監査ログは、デフォルトでは有効になっていません。
-
デバッグ・ログ。デバッグ・ログは、ディレクトリ・サーバーの問題のトラブルシューティングまたはディレクトリ・サーバーの処理に関する詳細情報の提供に使用できる情報を記録します。デバッグ・ログは、デフォルトでは有効になっていません。
-
エラー・ログ。エラー・ログは、ディレクトリ・サーバーの処理中に発生したすべての警告、エラーまたは重大なイベントを記録します。
-
レプリケーション修復ログ。レプリケーション修復ログは、トポロジの単一のディレクトリ・サーバーの非一貫性を記録します。
レプリケーション修復ログは読取り専用であり、レプリケーションの競合解決を有効にする場合のみ使用できます。
-
OUD設定ログ。設定ログは、Oracle Unified Directoryのプロキシ・サーバー・インスタンスまたはレプリケーション・ゲートウェイ・インスタンスのインストール中に実行した同等のコマンド行引数を記録します。このログによって、以前のインストールに基づいて、プロキシ・サーバーまたはゲートウェイ・サーバーの「サイレント・インストール」を実行できます。
このファイルは、ディレクトリ・サーバー・インスタンスの出力ではありません。
-
server.outログ。Server.outログは、ブートストラップ構成プロセスを記録し、jarファイルからロードされた拡張子をリストし、接続およびアラートの通知アクティビティを示します。現時点では、server.outログが書き込まれる場所を変更することはできません。
35.5.4.7 server.outログの表示
35.5.4.7.1 server.outログのOUDインスタンス名のロギング
OUDインスタンス名は、OUDによって生成される各ログ・メッセージのヘッダーの一部としてデフォルトで取得されます。
このコンテンツは、OUDバンドル・パッチ12.2.1.4.240319以降のリリースにのみ適用されます。
cat
コマンドを使用して、server.outログ・ファイルの内容を表示できます:
cat ../logs/server.out
[12/Feb/2024:08:38:05 +0000][asinst_1] category=CORE severity=INFORMATION msgID=132 msg=The Directory Server is beginning the configuration bootstrapping process
[12/Feb/2024:08:38:06 +0000][asinst_1] category=CORE severity=NOTICE msgID=458886 msg=Oracle Unified Directory 12.2.1.4.240209 (build 20240211082854Z, R2402091051) starting up
[12/Feb/2024:08:38:08 +0000][asinst_1] category=RUNTIME_INFORMATION severity=NOTICE msgID=20381717 msg=Installation Directory: /scratch/OUD_BASE/OUD/MAIN/OracleUnifiedDirectory
[12/Feb/2024:08:38:08 +0000][asinst_1] category=RUNTIME_INFORMATION severity=NOTICE msgID=20381719 msg=Instance Directory: /scratch/OUD_BASE/OUD/MAIN/asinst_1/OUD
[12/Feb/2024:08:38:08 +0000][asinst_1] category=RUNTIME_INFORMATION severity=NOTICE msgID=20381713 msg=JVM Information: 1.8.0_211-b12 by Oracle Corporation, 64-bit architecture, 6484000768 bytes heap size
config/java.propertiesのstart-ds.java-args
プロパティを変更することで、server.outのインスタンス名のロギングを無効にできます。
server.outのインスタンス名のロギングを無効にするには、次のステップを実行します:
- 次のように、config/java.propertiesファイルの
-Dlog.instance.details
パラメータをfalse
に設定します:start-ds.java-args=-Xms6285m -Xmx6285m -d64 -XX:+UseCompressedOops -server -Xmn1g -XX:MaxTenuringThreshold=1 -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=60 -Dlog.instance.details=false
dsjavaproperties
コマンドを実行して、新しい設定を適用します。
サーバーを再起動すると、インスタンス名は記録されなくなります。
ノート:
インスタンス名は、OUDによって生成されたログに対してのみ記録されます。JDKまたはその他の基礎となるライブラリからのメッセージには、インスタンス名が記録されない場合があります。35.5.4.8 設定ログの表示
設定ログ・ファイルはoud-proxy-setup
、oud-setup
またはoud-replication-gateway-setup
によって生成できます。任意のタイプのインスタンスの設定ログ・ファイルを表示できますが、出力はインスタンス・タイプに応じて多少異なります。たとえば:
-
Directory Serverインスタンスの出力
Jan 27, 2015 4:40:04 PM org.opends.quicksetup.QuickSetupLog initLogFileHandler INFO: QuickSetup application January 27, 2015 4:40:04 PM MET
-
レプリケーション・ゲートウェイ・インスタンスの出力
Jan 27, 2015 2:53:21 PM org.opends.guitools.util.ControlPanelLog initLogFileHandler INFO: Application launched January 27, 2015 2:53:21 PM MET
-
プロキシ・サーバー・インスタンスの出力
Jan 27, 2015 2:40:13 PM com.sun.dps.ui.deploy.SetupLog initLogFileHandler INFO: oudproxy-setup application launched January 27, 2015 2:40:13 PM MET
設定ログを表示するには:
35.6 SNMPを使用したサーバーのモニタリング
Oracle Unified Directoryでは、管理情報ベース(MIB) 2605サポートのSimple Network Management Protocol (SNMP)接続ハンドラが提供されます。MIB 2605により、SNMPマネージャはサーバー・モニタリング情報にアクセスできます。MIBの拡張には、SNMP接続ハンドラ、MIB 2605オブジェクトとSNMPリクエストをサポートするために必要なクラス、およびSNMPマネージャによるサーバー・モニタリング情報へのアクセスを可能にするSNMPアダプタが含まれます。SNMP MIB 2605の説明は、install-dir/snmp/mib/rfc2605.txt
のファイルにあります。
Oracle Unified Directoryを使用すると、SNMP接続ハンドラを有効にして構成できます。
この項の手順を開始する前に、対象のシステムでSNMP管理対象ネットワークを設定済であることを確認してください。
この項では、次の項目について説明します。
35.6.1 サーバーでのSNMPの構成
Simple Network Management Protocol (SNMP)を介したモニタリング用にOracle Unified Directoryを構成できます。サーバーは、Java Dynamic Management Kit (JDMK)を使用して、SNMP接続ハンドラのスマート・エージェントを作成します。
35.6.2 SNMP接続ハンドラのプロパティの表示
dsconfig
コマンドを使用すると、既存の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 : -
35.6.4 SNMPセキュリティ構成の理解
Simple Network Management Protocol (SNMP)のセキュリティ構成は、現在使用中のSNMPのバージョンによって異なります。
次の各トピックでは、SNMP V1およびV2cと、V3のセキュリティ構成について説明します。
35.6.4.1 SNMPセキュリティ構成について: V1およびV2c
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 } }
35.6.4.2 SNMPセキュリティ構成について: V3
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 = * } }
35.6.4.3 SNMP USM構成について: V3
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
ノート:
ユーザーを永続にするためにセキュリティ・ファイルも使用されます。
35.6.5 SNMPトラップの構成
SNMPトラップをモニタリング用に構成できます。
既存のOUDアラートは、SNMP V1トラップとして使用できます。SNMPハンドラが有効になっている場合は、OUDサーバーがアラートを生成するたびに、適切なSNMPトラップが送信されます。基になるアラート・タイプとその関連メッセージの両方がSNMPトラップに含まれています。
要件に基づいて、次のSNMPトラップ設定を構成できます:
enabled-traps
トラップとして送信できるサーバー・アラート・タイプの名前を指定します。この属性に値がある場合、それらのサーバー・アラートのみがトラップとして送信されます(それらが無効なトラップに含まれない場合に限ります)。この属性に値がない場合、無効なトラップのリストにないすべてのサーバー・アラート・タイプはトラップとして送信されます。
dsconfig set-connection-handler-prop --handler-name "SNMP Connection Handler" --set
enabled-traps:org.opends.server.DirectoryServerShutdown
disabled-traps
トラップとして送信されないサーバー・アラート・タイプの名前を指定します。この属性に値がある場合、それらのサーバー・アラート・タイプのトラップは送信されません。この属性に値がない場合、enabled-traps
構成に基づくトラップのみが送信されます。
dsconfig set-connection-handler-prop --handler-name "SNMP Connection Handler" --set
disabled-traps:org.opends.server.authorization.dseecompat.AciModified
disable-all-traps
これがtrue
に設定されている場合、サーバーはトラップを送信しません。
dsconfig set-connection-handler-prop --handler-name "SNMP Connection Handler" --set disable-all-traps:true
35.6.6 サポートされているSNMPトラップのOIDマッピング
システムでアラート・タイプ・イベントが発生すると、OUDサーバーはアラート・メッセージを送信し、SNMPハンドラ(有効な場合)は関連するSNMPトラップを送信します。
次の表に、サポートされているSNMPトラップをそのOIDマッピングとともに示します。
SNMPトラップ | 説明 | OIDマッピング |
---|---|---|
DirectoryServerStarted | org.opends.server.DirectoryServerStarted アラートのSNMPトラップ。
|
1.3.6.1.4.1.111.9118.2.1 |
DirectoryServerShutdown | org.opends.server.DirectoryServerShutdown アラートのSNMPトラップ。
|
1.3.6.1.4.1.111.9118.2.2 |
UncaughtException | org.opends.server.UncaughtException アラートのSNMPトラップ。
|
1.3.6.1.4.1.111.9118.2.3 |
CannotCopySchemaFiles | org.opends.server.CannotCopySchemaFiles アラートのSNMPトラップ。
|
1.3.6.1.4.1.111.9118.2.4 |
CannotWriteNewSchemaFiles | org.opends.server.CannotWriteNewSchemaFiles アラートのSNMPトラップ。
|
1.3.6.1.4.1.111.9118.2.5 |
AciModified | org.opends.server.authorization.dseecompat.AciModified アラートのSNMPトラップ。
|
1.3.6.1.4.1.111.9118.2.6 |
ACIParseFailed | org.opends.server.authorization.dseecompat.ACIParseFailed アラートのSNMPトラップ。
|
1.3.6.1.4.1.111.9118.2.7 |
BackendRunRecovery | org.opends.server.BackendRunRecovery アラートのSNMPトラップ。
|
1.3.6.1.4.1.111.9118.2.8 |
LDIFBackendCannotWriteUpdate | org.opends.server.LDIFBackendCannotWriteUpdate アラートのSNMPトラップ。
|
1.3.6.1.4.1.111.9118.2.11 |
LDIFConnectionHandlerParseError | org.opends.server.LDIFConnectionHandlerParseError アラートのSNMPトラップ。
|
1.3.6.1.4.1.111.9118.2.12 |
LDIFConnectionHandlerIOError | org.opends.server.LDIFConnectionHandlerIOError アラートのSNMPトラップ。
|
1.3.6.1.4.1.111.9118.2.13 |
UniqueAttributeSynchronizationConflict | org.opends.server.UniqueAttributeSynchronizationConflict アラートのSNMPトラップ。
|
1.3.6.1.4.1.111.9118.2.14 |
UniqueAttributeSynchronizationError | org.opends.server.UniqueAttributeSynchronizationError アラートのSNMPトラップ。
|
1.3.6.1.4.1.111.9118.2.15 |
Replication Server UnresolvedConflict | org.opends.server.replication.UnresolvedConflict アラートのSNMPトラップ。
|
1.3.6.1.4.1.111.9118.2.17 |
AccessControlDisabled | org.opends.server.AccessControlDisabled アラートのSNMPトラップ。
|
1.3.6.1.4.1.111.9118.2.20 |
AccessControlEnabled | org.opends.server.AccessControlEnabled アラートのSNMPトラップ。
|
1.3.6.1.4.1.111.9118.2.21 |
CannotRenameCurrentTaskFile | org.opends.server.CannotRenameCurrentTaskFile アラートのSNMPトラップ。
|
1.3.6.1.4.1.111.9118.2.22 |
CannotRenameNewTaskFile | org.opends.server.CannotRenameNewTaskFile アラートのSNMPトラップ。
|
1.3.6.1.4.1.111.9118.2.23 |
CannotScheduleRecurringIteration | org.opends.server.CannotScheduleRecurringIteration アラートのSNMPトラップ。
|
1.3.6.1.4.1.111.9118.2.24 |
CannotWriteConfig | org.opends.server.CannotWriteConfig アラートのSNMPトラップ。
|
1.3.6.1.4.1.111.9118.2.25 |
EnteringLockdownMode | org.opends.server.EnteringLockdownMode アラートのSNMPトラップ。
|
1.3.6.1.4.1.111.9118.2.26 |
LeavingLockdownMode | org.opends.server.LeavingLockdownMode アラートのSNMPトラップ。
|
1.3.6.1.4.1.111.9118.2.27 |
ManualConfigEditHandled | org.opends.server.ManualConfigEditHandled アラートのSNMPトラップ。
|
1.3.6.1.4.1.111.9118.2.28 |
ManualConfigEditLost | org.opends.server.ManualConfigEditLost アラートのSNMPトラップ。
|
1.3.6.1.4.1.111.9118.2.29 |
CannotWriteTaskFile | org.opends.server.CannotWriteTaskFile アラートのSNMPトラップ。
|
1.3.6.1.4.1.111.9118.2.30 |
LDAPHandlerDisabledByConsecutiveFailures | org.opends.server.LDAPHandlerDisabledByConsecutiveFailures アラートのSNMPトラップ。
|
1.3.6.1.4.1.111.9118.2.31 |
LDAPHandlerUncaughtError | org.opends.server.LDAPHandlerUncaughtError アラートのSNMPトラップ。
|
1.3.6.1.4.1.111.9118.2.32 |
HTTPHandlerDisabledByConsecutiveFailures | org.opends.server.HTTPHandlerDisabledByConsecutiveFailures アラートのSNMPトラップ。
|
1.3.6.1.4.1.111.9118.2.33 |
HTTPHandlerUncaughtError | org.opends.server.HTTPHandlerUncaughtError アラートのSNMPトラップ。
|
1.3.6.1.4.1.111.9118.2.34 |
SaturationLoadBalancer | com.sun.dps.server.SaturationLoadBalancer アラートのSNMPトラップ。
|
1.3.6.1.4.1.111.9118.2.35 |
UnsupportedDirectoryBackend | com.sun.dps.server.distribution.globalindex.UnsupportedDirectoryBackend アラートのSNMPトラップ。
|
1.3.6.1.4.1.111.9118.2.36 |
LDAPServerExtensionUp | com.sun.dps.server.workflowelement.proxyldap.LDAPServerExtension.LDAPServerExtensionUp アラートのSNMPトラップ。
|
1.3.6.1.4.1.111.9118.2.37 |
LDAPServerExtensionDown | com.sun.dps.server.workflowelement.proxyldap.LDAPServerExtension.LDAPServerExtensionDown アラートのSNMPトラップ。
|
1.3.6.1.4.1.111.9118.2.38 |
FailoverLoadBalancer | com.sun.dps.server.FailoverLoadBalancer アラートのSNMPトラップ。
|
1.3.6.1.4.1.111.9118.2.40 |
35.7 レプリケートされたトポロジのモニタリング
ディレクトリ・サーバーのレプリケーションが有効になると、1台のディレクトリ・サーバーに行われた変更が、ただちにトポロジ内の複数のディレクトリに伝播、すなわちレプリケートされます。dsreplication status
コマンドを使用してレプリケーション・ステータス情報を取得することで、Oracle Unified Directoryレプリケーション・ステータスをモニターできます。
レプリケーション・ゲートウェイ・サーバーを有効化した場合は、トポロジ内のOracle Unified Directoryディレクトリ・サーバーとODSEEディレクトリ・サーバーの両方のレプリケーション・ステータスをモニターできます。
ディレクトリ・サーバーのレプリケーションの動作の一般的な情報は、「Oracle Unified Directoryレプリケーション・モデルの理解」を参照してください。レプリケーション・ゲートウェイの使用に関する一般的な情報は、「レプリケーション・ゲートウェイの概要」を参照してください。
この項には次のサブセクションが含まれます:
-
dsreplicationを使用した基本的なOracle Unified Directoryレプリケーション・ステータスのモニタリング
-
dsreplicationを使用した詳細なOracle Unified Directoryレプリケーション・ステータスのモニタリング
-
レプリケーション・ゲートウェイを使用したデプロイメントのOracle Unified DirectoryおよびODSEEレプリケーション・ステータスのモニタリング
35.7.1 dsreplication
を使用した基本的なOracle Unified Directoryレプリケーション・ステータスのモニタリング
Oracle Unified Directoryのレプリケーションをモニターする最も簡単な方法は、dsreplication status
コマンドを使用することです。
このコマンドは、次の情報を含むレプリケーション・ステータスの表を提供します:
-
トポロジおよびその接続
-
レプリケートされるサーバー間の待機時間
-
レプリケートされるサーバー間のデータ一貫性
-
レプリケートされるサーバー間のセキュリティ構成
-
レプリケーション・プロトコルのピア・ツー・ピア
この項の残りの部分の例では、次の単純なレプリケーション・トポロジを想定しています。
次の項では、基本的なレプリケーション・ステータス情報を取得する方法を説明します。
より詳細な情報の取得の詳細は、「dsreplicationを使用した詳細なOracle Unified Directoryレプリケーション・ステータスのモニタリング」を参照してください。
35.7.1.1 最小限の基本レプリケーション・ステータス情報の表示
dsreplication
コマンドを使用すると、最小限の基本レプリケーション・ステータス情報を表示できます。
次のようにコマンドを実行します。
$ 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サーバーは、ポートに接続されています。
-
ステータス。このディレクトリ・サーバーのレプリケーション・ドメインのステータスを示します。
データ(レプリケーション・ドメイン)を含むディレクトリ・サーバーの場合、ステータスは次のいずれかになります。
-
「正常」。レプリケーション・サーバーへの接続は、正しいデータ・セットで確立されます。レプリケーションが機能しています。確実なモードを使用すると、このディレクトリ・サーバーからの確認が送信されます。
-
「遅延」。レプリケーション・サーバーへの接続は、正しいデータ・セットで確立されます。ディレクトリ・サーバー内の欠落している変更の数がレプリケーション・サーバー構成で定義されたしきい値を超えると、レプリケーションは遅延とマークされます。変更の数がこのしきい値を下回ると、ステータスは正常に戻ります。
-
「完全更新」。レプリケーション・サーバーとの接続が確立され、ローカル・バックエンドを初期化するために、新しいデータ・セットがこの接続から受信されます(オンライン・インポート)。
-
「不正データ・セット」。レプリケーション・サーバーとの接続が、トポロジの他のディレクトリ・サーバーとは異なるデータ・セットで確立されます。レプリケーションは動作しません。トポロジの他のディレクトリ・サーバーを互換性のあるデータ・セットを使用して初期化する必要があるか、またはこのサーバーを他のサーバーと互換性のある別のデータ・セットを使用して初期化する必要があります。
-
「未接続」。ディレクトリ・サーバーは、どのレプリケーション・サーバーとも接続されていません。
-
「不明」。ステータスを特定できません。これは、主にサーバーが停止中または到達不能な場合に起こりますが、別のサーバーのモニタリングで参照されます。
-
「無効」。これは、内部使用のためのものです。ディレクトリ・サーバーの状態が変更され、ステート・マシンによると遷移が不可能な場合、INVALID_STATUSが戻されます。
レプリケーション・サーバーなどのディレクトリ・サーバーにレプリケートされたデータが含まれない場合や、
--expanded option
を指定する場合、レプリケーション・サーバーのステータスは次の値になります。-
「稼働」。レプリケーション・サーバーが稼働中で、他のサーバーに正しく接続されています。
-
「停止」。レプリケーション・サーバーが他のサーバーに接続されておらず、正しく実行されていません。
-
「不明」。ステータスを特定できません。これは、主にレプリケーション・サーバーが停止中または到達不能なOracle Unified Directoryインスタンスに起こりますが、レプリケーション・サーバーは別のサーバーの構成で参照されます。
-
35.7.1.2 追加の基本レプリケーション・ステータス情報の表示
dsreplication
コマンドを使用すると、追加の基本レプリケーション・ステータス情報を表示できます。
次のようにコマンドを実行します。
$ dsreplication status --adminUID admin --adminPasswordFile pwd.txt -X \ --hostname host1 --port 4444 --dataToDisplay compat-view
結果のcompat-view
は、Oracle Unified Directoryの以前のバージョンで表示されたビューと同じです。「最小限の基本レプリケーション・ステータス情報の表示」で説明した情報に加え、次の情報も表示されます。
-
暗号化。LDAPサーバーとそのレプリケーション・サーバーの間でSSL暗号化が有効になっているかどうかを示します。
-
信頼。このサーバーが信頼できるサーバーとして構成されているか、信頼されないサーバーとして構成されているかを示します。詳細は、「分離レプリカの理解」を参照してください。
-
U.C。信頼されないサーバーで行われたが、まだトポロジにレプリケートされていない変更の数を指定します。詳細は、「分離レプリカの理解」を参照してください。
-
変更ログ。外部変更ログがこのサーバーのベースDNに対して有効になっているかどうかを示します。詳細は、「外部変更ログの使用」を参照してください。
-
グループID。サーバーが属しているレプリケーション・グループのIDです。詳細は、「レプリケーション・グループについて」を参照してください。
-
接続先。このディレクトリ・サーバーの接続先のレプリケーション・サーバーの名前、IPアドレスおよびレプリケーション・ポートを表示します。
35.7.2 dsreplication
を使用した詳細なOracle Unified Directoryレプリケーション・ステータスのモニタリング
dsreplication enable
コマンドとdataToDisplay
オプションを使用して、特定のモニタリング属性を追跡できます。これは、基本的なレプリケーション・ステータス情報よりも、されに詳細で包括的なレプリケーション・ステータスのビューを提供します。
モニタリング情報は、レプリケーション・サーバーによって統合されます。したがって、モニタリング情報は、実行中のレプリケーション・サーバーをホストしているディレクトリ・サーバーを検索することによってのみ取得できます。
この項の残りの部分の例では、次の単純なレプリケーション・トポロジを想定しています。
この項では、次のモニタリング・トピックについて説明します:
35.7.2.1 使用可能なレプリケーション・ステータス情報の包括的なリストの表示
dsreplication
コマンドを使用すると、表示可能なすべてのレプリケーション・ステータス属性のリストを属性の簡単な説明も含めて表示できます。
次のようにコマンドを実行します。
dsreplication status --advanced --listDataToDisplay
35.7.2.2 トポロジおよびその接続のモニタリング
各ディレクトリ・サーバーには、レプリケートされたベースDNそれぞれに対するレプリケーション・サーバーの候補のリストが含まれています。ただし、1つのディレクトリ・サーバーは、一度に1つのレプリケーション・サーバーのみと接続されます。
レプリケーション・トポロジおよびその接続の概要を取得するには、レプリケーション・サーバーをホストしているトポロジの任意のディレクトリ・サーバーで次のコマンドを実行します:
bin/dsreplication status -X -p 4444 --adminPasswordFile /tmp/password.txt -n --dataToDisplay connected-to --dataToDisplay lost-connections Establishing connections ...... Done. dc=example,dc=com - Replication Enabled ======================================= Server : Port [1] : Connected To [2] : L.C. [3] -------------------:----------:--------------------:--------- host1:4444 : 8989 : host1:8989 (GID=1) : 0 host2:5444 : 9989 : host2:9989 (GID=1) : 0 [1] The replication port used to communicate between the servers whose contents are being replicated. [2] The replication server this element is connected to with its group ID between brackets. [3] Lost Connections.
Connected To
列は、特定のベースDNに関して各ディレクトリ・サーバーが現在接続されているレプリケーション・サーバーを示します。すべてのレプリケーション・サーバーがその他のすべてのレプリケーション・サーバーと永続的に接続されるため、Connected To
列にはレプリケーション・サーバーはリストされません。
失われた接続(L.C.
)列は、ディレクトリ・サーバーとレプリケーション・サーバーの間の接続切断数を示します。各ディレクトリ・サーバーに示される値は、そのサーバーでレプリケーションが停止した回数に近い値になります。この属性の値がずっと大きい場合、予期しない接続損失があり、これを調査する必要があります。
35.7.2.3 レプリケーション待機時間のモニタリング
レプリケーション待機時間をモニタリングすると、特定のレプリケーション・サーバーがトポロジ内のその他のサーバーから遅れているかどうかを確認できます。これによって、レプリケーションの遅延および現在のサービスのクオリティの全体像が提供されます。
レプリケーション待機時間をモニターするには、レプリケーション・サーバーをホストしているトポロジの任意のサーバーで次の検索を実行します:
bin/dsreplication status -X -p 4444 --adminPasswordFile /tmp/password.txt -n --dataToDisplay missing-changes --dataToDisplay aoomc Establishing connections ..... Done. dc=example,dc=com - Replication Enabled ======================================= Server : M.C. [1] : A.O.M.C. [2] : Port [3] -------------------:----------:--------------:--------- host1:4444 : 0 : N/A : 8989 host2:5444 : 0 : N/A : 9989 [1] The number of changes that are still missing on this element (and that have been applied to at least one other server). [2] Age of oldest missing change: the age (in seconds) of the oldest change that has not yet arrived on this element. [3] The replication port used to communicate between the servers whose contents are being replicated.
この例では、最も古い欠落している変更の経過時間(A.O.M.C.
)コマンドが実行されてからの秒数で示されます。最も古い更新は、トポロジの他のディレクトリ・サーバーからプッシュされます。最も古い更新は、指定したディレクトリ・サーバーでまだ処理されていない場合があります。
欠落している変更(M.C.
)列は、トポロジの他のディレクトリ・サーバーによってすでにプッシュされたが指定したディレクトリ・サーバーでまだリプレイされていない更新数を指定します。
ノート:
これらの属性によって定義されているようなレプリケーション待機時間が大きい場合、送受信された更新数を確認し、トポロジで待機時間の原因になっているサーバーを特定します。これらの属性は、このドキュメントで後述します。
35.7.2.4 データの一貫性のモニタリング
データの一貫性をモニタリングすると、トポロジの各レプリケーション・サーバーがトポロジで発生した最新の変更と同期化されて最新であるかどうかを確認できます。
データに一貫性がない場合、Status
列にBad Data Set
が示されます。生成IDを表示するには、次のコマンドを実行します:
bin/dsreplication status -X -p 4444 --adminPasswordFile /tmp/password.txt -n --dataToDisplay status --dataToDisplay generation-id Establishing connections ......... Done. dc=example,dc=com - Replication Enabled ======================================= Server : Port [1] : Status [2] : Gen. ID [3] -------------------:----------:--------------:------------ host1:4444 : 8989 : Bad Data Set : 19399981 host2:5444 : 9989 : Normal : 19399981 [1] The replication port used to communicate between the servers whose contents are being replicated. [2] The status of the replication on this element. [3] The generation ID: the version of the data in each replicated base DN, for each directory server.
生成ID (Gen. ID
)列は、各ディレクトリ・サーバーに対して、レプリケートされた各ベースDNのデータのバージョンを示します。ベースDN dc=example,dc=com
のすべてのサーバーの生成IDは、19399981
です。生成IDの一貫性は、これらのサーバーのデータがそのベースDNで同じであることを意味します。
各ディレクトリ・サーバーも接続先のレプリケーション・サーバーの生成IDを認識しています。レプリケーション・サーバーの生成IDは、そのベースDNの変更ログ・データベースに格納されている更新と関係があります。
指定したベースDNの2つのディレクトリ・サーバーおよびそのレプリケーション・サーバーがすべて同じ生成IDを持っている場合、その2つのディレクトリ・サーバー間でレプリケーションが正しく動作していると見なされます。
35.7.2.5 レプリケーションのセキュリティのモニタリング
セキュア・レプリケーション・トポロジでは、特定のベースDNに対して、サーバー間でSSL暗号化が有効になっています。
レプリケーションのセキュリティをモニターするには、レプリケーション・サーバーをホストしているトポロジの任意のサーバーで次のコマンドを実行します:
bin/dsreplication status -X -p 4444 --adminPasswordFile /tmp/password.txt -n --dataToDisplay secure-conf Establishing connections ......... Done. dc=example,dc=com - Replication Enabled ======================================= Server : Port [1] : Encryption [2] -------------------:----------:--------------- host1:4444 : 8989 : Disabled host2:5444 : 9989 : Disabled [1] The replication port used to communicate between the servers whose contents are being replicated. [2] Whether the replication communication initiated by this element is encrypted or not.
Encryption
列は、指定したベースDNの2つのサーバー間でSSLプロトコルが有効化されているか無効化されているかを示します。この情報は、ディレクトリ・サーバーまたはレプリケーション・サーバーそれぞれに対して使用できます。レプリケーション・セッションの認証はモニターされません。
dsreplication enable
を対話的に使用して、または次の2つの引数を使用して、暗号化された通信を使用するようサーバーを構成できます。
35.7.2.6 レプリケートされた更新のモニタリング
トポロジのサーバーによって送受信された更新数をモニタリングすると、レプリケーションの動作状況がわかります。
送受信された更新をモニターするには、次のコマンドを実行します:
bin/dsreplication status -X -p 4444 --adminPasswordFile /tmp/password.txt -n --dataToDisplay sent-updates --dataToDisplay received-updates --dataToDisplay send-window Establishing connections ......... Done. dc=example,dc=com - Replication Enabled ======================================= Server : Port [1] : R.U. [2] : S.U. [3] : S.W. [4] -------------------:----------:----------:----------:--------- host1:4444 : 8989 : 0 : 0 : 100 host2:5444 : 9989 : 0 : 0 : 100 [1] The replication port used to communicate between the servers whose contents are being replicated. [2] Received updates. [3] Sent updates. [4] Send window between this element and the replication server it is connected to.
送信された更新(S.U.
)列は、このディレクトリ・サーバーまたはレプリケーション・サーバーによって送信された更新数を示します。
受信した更新 (R.U.
)列は、このディレクトリ・サーバーまたはレプリケーション・サーバーが受信した更新数を示します。
これらの属性の値は、トポロジ内の更新のフローを判断する際に役立ちます。レプリケーションが非常に遅いと思われる場合、これらの属性をモニターすると役に立ちます。あるサーバーによって送信された更新数が別のサーバーによって受信された更新数より一貫してずっと多い場合、2番目のサーバーがトポロジ内でボトルネックになっている可能性が高いです。
レプリケーション・プロトコルは、2つのサーバー間の更新のフローを制御します。これによって、多数の更新が2つのサーバー間で交換される場合、サーバーはより高い優先度の操作の処理を妨げられることがなくなります。この機能は、送信サーバーが送信できる更新数を受信サーバーが定期的に送信サーバーに提供するウィンドウ・メカニズムに依存しています。
max-send-window
構成属性およびmax-rcv-window
構成属性を設定して、送信ウィンドウおよび受信ウィンドウのサイズを指定できます。詳細は、「dsconfigによるレプリケーション構成の変更」を参照してください。
35.7.2.7 レプリケーションの競合のモニタリング
同時に同じエントリで複数の操作が実行されると、レプリケーションの競合が発生する可能性があります。場合によっては、レプリケーション・メカニズムによって競合を解決できます。手動の競合解決が必要な場合もあります。
3種類の競合属性をモニターできます:
-
unresolved-naming-conflicts
。レプリケーション・メカニズムによって解決できない名前の競合の数を示します。 -
resolved-naming-conflicts
。解決された名前の競合の数を示します。 -
resolved-modify-conflicts
。解決された変更の競合の数を示します。
解決済のレプリケーションの競合および未解決のレプリケーションの競合をモニターするには、次のコマンドを実行します:
bin/dsreplication status -X -p 4444 --adminPasswordFile /tmp/password.txt -n --dataToDisplay resolved-naming-conflicts --dataToDisplay unresolved-naming-conflicts --dataToDisplay resolved-modify-conflicts Establishing connections ...... Done. dc=example,dc=com - Replication Enabled ======================================= Server : Port [1] : R.N.C. [2] : U.N.C. [3] : R.M.C. [4] -------------------:----------:------------:------------:----------- host1:4444 : 8989 : 0 : 0 : 0 host2:5444 : 9989 : 0 : 0 : 0 [1] The replication port used to communicate between the servers whose contents are being replicated. [2] Resolved Naming Conflicts. [3] Unresolved Naming Conflicts. [4] Resolved Modify Conflicts.
35.7.3 レプリケーション・ゲートウェイを使用したデプロイメントのOracle Unified DirectoryおよびODSEEレプリケーション・ステータスのモニタリング
レプリケーション・ゲートウェイは、レプリケート・トポロジ内のOracle Directory Server Enterprise EditionサーバーとOracle Unified Directoryサーバーの間で、レプリケーション情報を変換し、伝播するサーバーです。
変換は、必要に応じてデータをディスクに格納せずに管理されます。レプリケーション・ゲートウェイがデプロイされると、Oracle Unified Directory dsreplication
コマンドまたはODSEEコンソールを使用してレプリケーション・ステータス情報をモニターできます。
レプリケーション・ゲートウェイの使用に関する一般的な情報は、「レプリケーション・ゲートウェイの概要」を参照してください。
この項では、次の項目について説明します。
35.7.3.1 dsreplication
を使用したOracle Unified Directoryトポロジに加えられた変更のモニター
dsreplication
を使用して、Oracle Unified Directoryトポロジに加えられた変更がレプリケーション・ゲートウェイを介してどのようにODSEEに伝播されているかをモニターできます。
次の例は、Oracle Unified Directoryトポロジで送受信された更新をモニターする方法を示します。図35-4に、次のコマンドを実行したときに戻される結果を示します。
# dsreplication status -d compat-view
図35-4 dsreplication status
の結果とデプロイ済のレプリケーション・ゲートウェイ
「図35-4 dsreplication statusの結果とデプロイ済のレプリケーション・ゲートウェイ」の説明
これらの結果は、このコマンドから戻される追加情報で説明されています。
[1] The number of changes that are still missing on this element (and that have been applied to at least one other server). [2] Age of oldest missing change: the age (in seconds) of the oldest change that has not yet arrived on this element. [3] The replication port used to communicate between the servers whose contents are being replicated. [4] Whether the replication communication initiated by this element is encrypted or not. [5] Whether the directory server is trusted or not. Updates coming from an untrusted server are discarded and not propagated. [6] The number of untrusted changes. These are changes generated on this server while it is untrusted. Those changes are not propagated to the rest of the topology but are effective on the untrusted server. [7] The status of the replication on this element. [8] Whether the external change log is enabled for the base DN on this server or not. [9] The ID of the replication group to which the server belongs. [10] The replication server this element is connected to with its group ID between brackets. [11] The protocol used by the replication gateway to connect to the DSEE server. [12] Replicate OUD Changes to DSEE
35.7.3.2 DSCCを使用してレプリケーション・ゲートウェイをモニターする方法の理解
DSEE 6.xおよびODSEE 11gディレクトリ・サーバーは、Directory Service Control Center (DSCC)でのモニタリング・ツールを提供します。DSCCとその関連ツールdsccmon
と連携するようOracle Unified Directoryレプリケーション・ゲートウェイを構成し、ODSEEサーバーに対して行われ、Oracle Unified Directoryトポロジにレプリケートされた変更をモニターできます。
レプリケーション・ゲートウェイをインストールおよび構成すると、DSCCの「ディレクトリ・サーバー」パネルに、次の情報が表示されます。
-
「サーバー」タブには、レプリケーション・ゲートウェイがODSEEサーバーとして表示されます。「説明」フィールドには、ODSEEサーバーがOracle Unified Directoryレプリケーション・ゲートウェイであることが示され、レプリケーション・ゲートウェイ・サーバーの実際のバージョンが表示されます。ポート番号、インスタンスのパスおよびサーバーのステータスも表示されます。
-
「接尾辞」タブには、レプリケーション・ゲートウェイがエントリおよびレプリケーション承諾なしで表示されます。これは、Oracle Unified Directoryトポロジのアクセス・ポイントを示します。ここで、Oracle Unified Directoryトポロジの状態とODSEEサーバーに対して行われた変更をモニターできます。
-
「レプリケーション承諾」タブでは、レプリケーション・ゲートウェイは宛先サーバーの1つです。レプリケーション・ゲートウェイの設定後、ODSEEトポロジに対して少なくとも1つの変更が行われたときにレプリケーション・モニタリングが開始します。
-
レプリケーション・ゲートウェイは、「トポロジの表示」の描画にも表示されます。
重要: DSCCではOracle Unified Directoryレプリケーション・ゲートウェイを表示できますが、起動、停止、Oracle Unified Directoryレプリケーション・ゲートウェイ・サーバーの構成などの管理操作を実行することはできません。
レプリケーション・ゲートウェイの設定の詳細は、インストレーション・ガイドを参照してください。
35.8 プロキシLDAPコネクタのモニタリング
Oracle Unified Directoryプロキシ・サーバーは、LDAPコネクタ(LDAPServerExtension
構成オブジェクトとも呼ばれる)を使用してリモートLDAPサーバーと通信します。各LDAPコネクタは、リアルタイム・モニタリング・パネルでモニターできる接続プールを管理します。
このモニタリング・パネルは次の情報を報告します。
-
サーバー・ステータス
-
各操作タイプの現在のスループット
-
接続プールのステータス
この項では、次の項目について説明します。
35.8.1 モニタリング・パネルの表示
モニタリング・パネルを表示するには、サーバーを起動する前に、MONITOR_LDAP_SERVER_EXTENSION
環境変数を設定する必要があります。
export
コマンドを次のように実行します。
$ export MONITOR_LDAP_SERVER_EXTENSION=yes $ start-ds
図35-5のように、1つのモニタリング・パネルには、1つのLDAPコネクタの情報が表示されます。
図35-5 LDAPコネクタ・モニタリング・パネルの例
35.8.2 LDAPコネクタ・モニタリング・パネルを読む方法の理解
LDAPコネクタ・モニタリング・パネルには、各操作タイプのスループット、サーバーのステータスと飽和索引、接続の数などが表示されます。
LDAPコネクタ・モニタリング・パネルの表示は、次のように読み取ります。
-
左側の棒グラフは、バインド、検索、追加、削除、変更操作などの各操作タイプのスループットを示します。
ノート:
各棒グラフは20,000操作/秒に制限されており、それぞれの棒は1000操作/秒のスループットを表します。
MONITOR_LDAP_SERVER_EXTENSION_MAX_THROUGHPUT=100000
を設定し、サーバーを再起動することによって、制限を20,000から100,000に引き上げることができます。 -
右側の最上位のエントリはサーバーのステータスで、リモートLDAPサーバーがUPかDOWNかを示します。たとえば、図35-5で、サーバー
ldap-01
はUP
です。 -
Sat. 0% (0%)
フィールドは、サーバーの飽和索引を示します。-
0%
の飽和索引値は、サーバーが完全に機能することを示します。 -
100%
の飽和索引値は、サーバーが飽和していることを示します。 -
カッコ内の値
(0%)
は、飽和索引がこれまでに達した最大値(ピーク値)です。サーバーを再起動すると、ピーク値は0%にリセットされます。
-
-
右側の残りのエントリは、接続プールの現在のサイズおよび接続数を示します。これらのエントリには、次のものが含まれています。
-
pool x/y [full z]
説明
-
xは、接続プールの現在のサイズです(作成された接続の数と同じ)。
-
yは、最大プール・サイズです。
-
zは、「プールが一杯」の発生です(現在の実装では常に0)。
-
-
free cnx
は、空いている接続の数です。 -
cc-cache
は、クライアントにバインドされた接続キャッシュ内の接続の数です。 -
pr-cache
は、プロキシにバインドされた接続キャッシュ内の接続の数です。 -
cnx in use
は、使用中の接続の数です。 -
stolen cnx
は、いずれかのキャッシュで失われている接続の数です。 -
silent binds
は、接続を使用する前にサーバーが通知なく実行するバインドの数です。Oracle Unified Directoryは、接続がまだバインドされていない場合、または接続が関連のない資格証明のセットにバインドされている場合、接続でサイレント・バインドをリクエストします。 -
invalid cnx
は、無効として解放されている接続の数です。 -
client cnx
は、現在接続され、コネクタを使用しているクライアント接続の数です。 -
closed cc
は、未処理のクローズされたクライアント接続の数です。
次のことは、いつでも不変である必要があります。
pool = free-cnx + cnx in use + cc-cache + pr-cache
実行中の操作がない場合、次のカウント値は0に設定されています(ゼロ以外のカウントは接続管理の問題を表します)。
cnx in use = 0 client-cnx = 0 closed-cnx = 0
-
ノート:
失われた接続とは、空いている接続がなく、プールをこれ以上拡張できないため、cc-cache
またはpr-cache
からフェッチされた接続のことです。失われた接続が多いことは多数のサイレント・リバインドを意味するため、失われた接続の数が多い場合、サーバーのパフォーマンスに影響します。失われた接続を回避するには、プール・サイズを大きくします。
35.9 汎用のエンタープライズのモニタリングのソリューションの理解
様々な汎用UNIXツールを使用して、サーバー環境をモニターできます。これらのツールの詳細は、UNIXシステムのマニュアル・ページを参照してください。
汎用のエンタープライズのモニタリングのソリューションについては、次の各項で説明します。
35.9.1 汎用のUNIXモニタリング・ツールについて
Oracle Unified Directoryで使用できる汎用のUNIXモニタリング・ツールについては、このトピックを参照してください。
次の表に、Oracle Unified Directoryで使用される汎用のUNIXモニタリング・ツールを示します。
ツール | 説明 |
---|---|
|
ディスクI/OおよびCPUの使用量に関する情報を提供します。 |
|
オープン・ファイル・ディスクリプタに関する情報を提供します。 |
|
ファイル・システム・ロックに関する情報を提供します。 |
|
ネットワーク機能の統計を提供します。 |
|
ホストおよびドメインに関する情報をDNSサーバーに問い合せることができます。 |
|
リモート・ホストまたはネットワーク・ゲートウェイのステータスを問い合せることができます。 |
|
UNIXシステムVのパフォーマンス・モニタリング・ツール。 |
|
ネットワーク・トラフィックをデバッグおよびモニターできます。 |
|
プロセスおよびCPUアクティビティの素早く簡単なモニタリングを提供します。 |
|
プロセスが行うシステム・コールに関する情報を提供します。 |
|
最終宛先に到達するためにインターネット全体でパケットが取るパスを提供します。 |
|
プロセス、仮想メモリー、ディスク、トラップおよびCPUアクティビティに関する統計を提供します。 |
35.9.2 Solarisモニタリング・ツールについて
Oracle Unified Directoryで使用できるいくつかのSolarisモニタリング・ツールについては、このトピックを参照してください。
次の表に、Oracle Unified Directoryで使用されるSolarisモニタリング・ツールを示します。
ツール | 説明 |
---|---|
|
OSおよびアプリケーションのロックに関する情報を提供します。DTrace権限が必要です。 |
|
システムの各プロセッサに関する統計を提供します。 |
|
プロセスで使用しているメモリーのブレークダウンを提供します。 |
|
プロセスおよびスレッドをモニターします。 |
|
ネットワーク・トラフィックをモニターします。低レベルのパケットをデバッグする際には必須です。 |
|
前述のツールなどの機能を提供します。 |
|
プロセスが行うシステム・コールに関する情報を提供します。 |
35.9.3 HP-UXモニタリング・ツールについて
Oracle Unified Directoryで使用できるいくつかのHP-UXモニタリング・ツールについては、このトピックを参照してください。
次の表に、Oracle Unified Directoryで使用されるHP-UXモニタリング・ツールを示します。
ツール | 説明 |
---|---|
|
オープン・ファイル・ディスクリプタ、ロックおよびスレッドに関する詳細システム情報を提供します。 |
|
GlancePlusは、グラフィカル・リアルタイム・パフォーマンス診断ツールです。Glanceは文字ベースのコンポーネントです。 |
|
システム・コール・トラップ機能を提供します。 |
|
カーネル・パラメータに関する情報を提供します。 |
|
ネットワーク統計をモニターします。 |
|
一般的なシステム管理ツールを提供します。 |