第11章 ログファイルのリファレンス
Directory Server は、既存の問題を解決するために、また障害やパフォーマンスの低下を引き起こす可能性のある潜在的な問題を予測するために不可欠なイベントをログファイルに記録します。
ログファイルを使用すると、次の目標を達成できます。
- 問題のトラブルシューティング
- サーバーのアクティビティーの監視
- ディレクトリーのアクティビティーの分析
ディレクトリーを効果的に監視するには、ログファイルの構造と内容を理解する必要があります。
この章にはログメッセージの完全なリストはありません。以下に提示する情報は、一般的な問題を解決し、アクセス、エラー、監査、監査失敗、およびセキュアログの記録を理解するための良い出発点として役立ちます。
Directory Server インスタンスは、ログを /var/log/dirsrv/slapd-instance_name
ディレクトリーに保存します。
11.1. アクセスログのリファレンス
Directory Server のアクセスログには、ディレクトリーへのクライアント接続に関する詳細情報が含まれます。接続は、同じクライアントからのリクエストシーケンスで、以下の設定になっています。
- 接続インデックスとクライアントの IP アドレスを提供する接続レコード
- バインドレコード
- バインド結果レコード
- レコードの操作要求と操作結果ペアのシーケンス、または接続、クローズ、および破棄レコードの場合の個別レコード
- バインド解除レコード
- クローズレコード
アクセスログレコードの例:
[time_stamp] conn=1 op=73 SRCH base="dc=example,dc=com" scope=2 filter="(&(objectClass=top)(objectClass=ldapsubentry)(objectClass=passwordpolicy))" attrs="distinguishedName" [time_stamp] conn=1 op=73 RESULT err=0 tag=101 nentries=24 wtime=0.000078414 optime=0.001614101 etime=0.001690742
ほとんどすべてのレコードは、サービスリクエストレコード (この例の SRCH
) と RESULT
レコードのペアで表示されます。接続、クローズ、破棄のレコードは個別に表示されます。
アクセスログには、いくつかのレベルのログがあります。これは、nsslapd-accesslog-level
属性を使用して設定できます。
11.1.1. アクセスロギングレベル
アクセスログのレベルに応じて、Directory Server が実行するさまざまな種類の操作が記録されます。
アクセスログには次のログレベルがあります。
- アクセスログなし (0)。
- 内部アクセス操作のロギング (4)。
- 接続、操作、および結果のロギング (256)。デフォルトのレベルです。
- エントリーおよび参照へのアクセスのロギング (512)。
nsslapd-accesslog-level
属性を使用して、アクセスログのレベルを設定します。属性値は加算されます。ログレベル値を 260 に設定すると、この値にはレベル 256 と 4 が含まれます。
11.1.2. デフォルトのアクセスログの内容
デフォルトでは、Directory Server のログレベルは 256 です。このレベルでは、エントリーへのアクセスに加えて、以下の情報が記録されます。
接続番号 (conn)
Directory Server は、すべての外部 LDAP 要求を、一連の接続番号 (この例では conn=13)
とともにリストします。接続番号は、サーバー起動直後の conn=0
から始まります。
[time_stamp] conn=13 fd=608 slot=608 connection from 172.17.0.2 to 172.17.0.2
Directory Server は、デフォルトでは内部 LDAP 要求を記録しません。内部アクセス操作のロギングを有効にするには、nsslapd-accesslog-level
設定属性を使用します。
ファイル記述子 (fd)
外部 LDAP クライアントから Directory Server へのすべての接続には、オペレーティングシステムからのファイル記述子またはソケット記述子 (この場合は fd=608
) が必要です。fd=608
値は、外部 LDAP クライアントが、使用可能なファイル記述子の合計プールのうちファイル記述子番号 608 を使用したことを示します。
[time_stamp] conn=11 fd=608 slot=608 connection from 172.17.0.2 to 172.17.0.2
スロット番号 (slot)
スロット番号 (この例では slot=608)
は、アクセスログのレガシー部分で、ファイル記述子と同じ意味を持ちます。アクセスログのこの部分は無視してください。
[time_stamp] conn=11 fd=608 slot=608 connection from 172.17.0.2 to 172.17.0.2.
操作番号 (opt)
LDAP 要求を処理するために、Directory Server は一連の操作を実行します。接続については、さまざまな操作を識別するために、すべての操作要求と操作結果のペアに op=0
で始まる一連の操作番号が割り当てられます。
[time_stamp] conn=14 op=0 BIND dn="cn=Directory Manager" method=128 version=3 [time_stamp] conn=14 op=0 RESULT err=0 tag=97 nentries=0 wtime=0.000076581 optime=0.000082736 etime=0.000158680 [time_stamp] conn=14 op=1 SRCH base="dc=example,dc=com" scope=2 filter="(uid=bjensen)" [time_stamp] conn=14 op=2 ABANDON targetop=2 msgid=3 nentries=0 etime=0.0000113702 [time_stamp] conn=14 op=3 UNBIND [time_stamp] conn=14 op=3 fd=634 closed - U1
上記の例では、以下のようになります。
-
op=0
: バインド操作の要求と結果 -
op=1
: LDAP 検索の要求と結果 -
op=2
: 破棄操作 -
op=3
: LDAP クライアントが送信するバインド解除操作とその結果
メソッドのタイプ (method)
メソッド番号 (この例では method=128)
は、クライアントがどの LDAPv3 バインドメソッドを使用したかを示します。
[time_stamp] conn=11 op=0 BIND dn="cn=Directory Manager" method=128 version=3
メソッドのタイプには、次の 3 つの値があります。
-
0
: 認証の場合 -
128
: ユーザーパスワードを使用した単純なバインドの場合 -
sasl
: 外部認証メカニズムを使用する SASL バインドの場合
バージョン番号 (version)
バージョン番号は、LDAP クライアントが LDAP サーバーと通信するために使用した LDAP のバージョン番号を示します。LDAP バージョン番号は、LDAPv2 または LDAPv3 のいずれかになります。この例では、version=3
を使用しています。
[time_stamp] conn=11 op=0 BIND dn="cn=Directory Manager" method=128 version=3
エラー番号 (err)
エラー番号は、実行された LDAP 操作を返す LDAP 結果コードを示します。LDAP エラー番号 0
は、操作が成功したことを意味します。この例では op=0
です。
[time_stamp] conn=2 op=0 RESULT err=0 tag=97 nentries=0 wtime=0.000076581 optime=0.000082736 etime=0.000158680
タグ番号 (tag)
タグ番号は、操作で返された結果のタイプを示します。Directory Server は、LDAP プロトコルの BER タグを使用します。この例では tag=97
です。
[time_stamp] conn=11 op=0 RESULT err=0 tag=97 nentries=0 wtime=0.000076581 optime=0.000082736 etime=0.000158680
次の表に、一般的に使用されるタグを示します。
Tag | 説明 |
---|---|
tag=97 | クライアントのバインド操作の結果。 |
tag=100 | Directory Server が検索した実際のエントリー。これは結果タグではなく、アクセスログにこのようなタグは含まれません。 |
tag=101 | 検索操作の結果。 |
tag=103 | 変更操作の結果。 |
tag=105 | 追加操作の結果。 |
tag=107 | 削除操作の結果。 |
tag=109 | moddn (名前変更) 操作の結果。 |
tag=111 | 比較操作の結果。 |
tag=115 | 操作の検索対象のエントリーが、必要なエントリーへの参照を保持している場合の検索参照。これは結果タグではなく、アクセスログにこのようなタグは含まれません。 |
tag=120 | 拡張操作の結果。 |
tag=121 | 中間操作の結果。 |
エントリー数 (nentries)
nentries
レコードは、検索操作で LDAP クライアントの要求と一致することが検出されたエントリーの数を示します。
[time_stamp] conn=11 op=0 RESULT err=0 tag=97 nentries=0 wtime=0.000076581 optime=0.000082736 etime=0.000158680
この例では nentries=0
です。つまり、Directory Server は一致するエントリーを検出しませんでした。
経過時間 (etime)
etime
レコードは、Directory Server が LDAP 操作の実行に費やした経過時間または期間 (秒単位) を示します。
[time_stamp] conn=11 op=1 RESULT err=0 tag=101 nentries=1 wtime=0.000076581 optime=0.000082736 etime=0.000158680 notes=U
この例では、Directory Server は操作の実行に 0.000158680 秒かかりました。
etime
値が 0 の場合は、操作の実行に実際には 0 ナノ秒かかったことを意味します。
LDAP 要求タイプ
LDAP 要求タイプは、LDAP クライアントが発行した LDAP 要求のタイプを示します。可能な値は次のとおりです。
-
SRCH
: 検索操作の場合 -
MOD
: 変更操作の場合 -
DEL
: 削除操作の場合 -
ADD
: 追加操作の場合 -
MODDN
: moddn (名前変更) 操作の場合 -
EXT
: 拡張操作の場合 -
ABANDON
: 破棄操作の場合 -
SORT serialno
: LDAP 要求の結果としてエントリーがソートされる場合
[time_stamp] conn=114 op=68 SORT serialno (1)
この例の括弧で囲まれた数字は、LDAP 要求によって 1 つの候補エントリーがソートされたことを示しています。
LDAP 応答タイプ
Directory Server は、次の 3 つの LDAP 応答タイプを発行できます。
-
RESULT
は、クライアントの LDAP 要求に対する結果を意味します。 -
ENTRY
は、検索操作に応答して Directory Server が返すエントリーを意味します。 -
REFERRAL
は、Directory Server が LDAP 要求を別のサーバーに送信することを意味します。
RESULT
メッセージには、以下のパフォーマンス関連のレコードが含まれます。
wtime
- ワーカースレッドが操作をピックアップするまで、操作がワークキューで待機していた時間
optime
- 実際の操作がタスクを実行するのにかかった時間
etime
- Directory Server が要求を受信してから、サーバーが結果をクライアントに送り返すまでの時間
wtime
および optime
の値により、サーバーがどのように負荷をおよび操作を処理するかに関する有用な情報を提供されます。Directory Server がこれらの統計を収集するには時間がかかるため、wtime
値と optime
値の合計は etime
値よりわずかに大きくなります。
検索インジケーター (note)
Directory Server は、ログエントリーの note メッセージで検索に関する追加情報を提供します。以下に例を示します。
[time_stamp] conn=11 op=1 RESULT err=0 tag=101 nentries=1 wtime=0.000076581 optime=0.000082736 etime=0.000158680 notes=U
Directory Server は、次の検索インジケーターをサポートしています。
検索インジケーター | 説明 |
---|---|
|
ページ検索インジケーター。リソースが制限された LDAP クライアントでは、LDAP サーバーが検索操作の結果を返す速度を制御できます。実行された検索で LDAP 制御拡張を使用して検索結果を単純にページングすると、Directory Server は |
|
インデックスのない検索インジケーター。フィルター内のすべての候補属性がインデックス化されておらず、テーブル全体のスキャンが必要な場合、Directory Server は |
|
インデックスのない検索インジケーター。次の状況では、Directory Server は
|
|
不明な属性インジケーター。検索フィルターに不明な属性が含まれている場合、Directory Server は |
|
MFA プラグインバインドインジケーター。MFA プラグインなどの事前バインド認証プラグインを使用してユーザーアカウントの 2 要素認証を設定すると、Directory Server は |
note レコードには、notes=P,A
や notes=U,P
など、値の組み合わせが含まれることがあります。
属性がインデックス化されていない場合、Directory Server はそれらを直接データベースで検索する必要があります。この手順では、インデックスファイルを検索する場合よりも多くのリソースが消費されます。
インデックス化されていない検索は、以下のシナリオで発生します。
-
インデックスファイルを使用した場合でも、検索操作が
nsslapd-idlistscanlimit
属性に設定された検索エントリー数を超えている。nsslapd-idlistscanlimit
属性の詳細は、nsslapd-idlistscanlimit の説明 を参照してください。 - インデックスファイルが存在しない。
- インデックスファイルが検索で必要な方法で設定されなかった。
今後の検索を最適化するには、インデックスに頻繁に検索されるインデックス化されていない属性を追加します。
通常、インデックス化されていない検索には時間がかかるため、インデックス化されていない検索インジケーターには大きな etime
値が伴うことがよくあります。
MFA プラグインバインド
MFA プラグインなどの事前バインド認証プラグインを使用してユーザーアカウントの 2 要素認証を設定すると、アクセスログが notes=M
メモメッセージを次のファイルに記録します。
[time_stamp] conn=1 op=0 BIND dn=“uid=jdoe,ou=people,dc=example,dc=com” method=128 version=3
[time_stamp] conn=1 op=0 RESULT err=0 tag=97 nentries=0 wtime=0.000111632 optime=0.006612223 etime=0.006722325 notes=M details=“Multi-factor Authentication” dn=“uid=jdoe,ou=people,dc=example,dc=com”
アクセスログに notes=M
ノートメッセージを記録するには、このプラグインにバインドが含まれている場合、事前バインド認証プラグインで SLAPI API を使用してフラグを設定する必要があります。
VLV 関連エントリー (VLV)
検索に仮想リストビュー (VLV) が含まれる場合、Directory Server は適切なエントリーをアクセスログファイルに記録します。他のエントリーと同様に、VLV 固有のレコードには、要求と応答の情報が一緒に表示されます。
[time_stamp] conn=67 op=8530 VLV 0:5:0210 10:5397 (0)
この例では、要求情報は 0:5:0210
で、形式は beforeCount:afterCount:index:contentCount
です。応答情報は 10:5397 (0)
で、形式は targetPosition:contentCount (resultCode)
です。
クライアントが position-by-value VLV 要求を使用する場合、要求情報の形式は beforeCount: afterCount: value
となります。
検索範囲 (scope)
scope
エントリーは、実行される検索操作のスコープを定義し、次のいずれかの値を持ちます。
-
0
: ベース検索の場合 -
1
: 1 レベルの検索の場合 -
2
: サブツリー検索の場合
拡張操作の OID (oid)
oid
レコードは、実行された拡張操作のオブジェクト識別子 (OID) を提供します。以下は、拡張操作の OID を含むアクセスログレコードの例です。
[time_stamp] conn=13 op=1 EXT oid="2.16.840.1.113730.3.5.3" ... [time_stamp] conn=15 op=3 EXT oid="2.16.840.1.113730.3.5.5"
Directory Server は、以下の LDAPv3 拡張操作とその OID をサポートしています。
拡張操作名 | 説明 | OID |
---|---|---|
Directory Server のレプリケーション開始要求 | レプリケーションイニシエーターがレプリケーションセッションを要求する。 | 2.16.840.1.113730.3.5.3 |
Directory Server のレプリケーション応答 | レプリケーションレスポンダーが、レプリケーション開始要求の拡張操作またはレプリケーション終了要求の拡張操作に対して応答する。 | 2.16.840.1.113730.3.5.4 |
Directory Server のレプリケーション終了要求 | レプリケーションイニシエーターがレプリケーションセッションを終了する。 | 2.16.840.1.113730.3.5.5 |
Directory Server のレプリケーションエントリー要求 |
状態情報 ( | 2.16.840.1.113730.3.5.6 |
Directory Server の一括インポートの開始 | クライアントが一括インポート開始操作を使用してインポートされた接尾辞による一括インポートを要求し、Directory Server が一括インポートを開始できることを示す。 | 2.16.840.1.113730.3.5.7 |
Directory Server の一括インポートの完了 | クライアントが一括インポート完了操作を使用して一括インポートを終了し、Directory Server が一括インポートの終了を確認する。 | 2.16.840.1.113730.3.5.8 |
シーケンス番号の変更 (csn)
csn=3b4c8cfb000000030000
などの csn
メッセージは、Directory Server が 'csn' で識別される更新を受信し、処理したことを示します。
破棄メッセージ (ABANDON)
破棄メッセージは、クライアントまたは Directory Server が操作を終了したことを示します。
以下は、破棄メッセージを含むログレコードの例です。
[time_stamp] conn=12 op=1 SRCH base="dc=example,dc=com" scope=2 filter="(uid=bjensen)" [time_stamp] conn=12 op=2 ABANDON targetop=2 msgid=3 nentries=0 etime=0.0000113980
nentries=0
値は、操作が終了する前に Directory Server が送信したエントリーの数を示します。etime=0.0000113980
値は、経過時間 (秒単位) を示します。targetop =2
は、Directory Server が以前に開始した操作番号 (opt =2
) に対応します。
Directory Server が破棄する操作を見つけられない場合、ログレコードには targetop=NOTFOUND
メッセージが含まれます。
[time_stamp] conn=12 op=2 ABANDON targetop=NOTFOUND msgid=2
このメッセージ例は、Directory Server が操作を以前に完了したか、不明な操作であることを意味します。
メッセージ ID (msgid)
LDAP SDK クライアントは、msgid=2
などのメッセージ ID を生成します。これは、LDAP 操作識別子でもあります。msgid
値は opt
値と異なる場合があります。ただし、これは同じ操作を識別するものです。Directory Server は、ABANDON
操作を含む msgid
を記録し、どのクライアント操作が破棄されたかをユーザーに通知します。
[time_stamp] conn=12 op=2 ABANDON targetop=NOTFOUND msgid=2
Directory Server の操作番号 opt
は、ある接続に対して 0 からカウントされます。ほとんどの LDAP SDK/クライアント実装では、メッセージ ID 番号 msgid
は 1 からカウントされます。msgid
が、Directory Server の opt
に 1 を加えたものと等しいことが多いのはそのためです。
SASL マルチステージバインドロギング
Directory Server は、バインドプロセスの各段階をログに記録します。SASL 接続のエラーコードは、実際には戻りコードです。
[time_stamp] conn=16 op=0 BIND dn="" method=sasl version=3 mech=DIGEST-MD5 [time_stamp] conn=16 op=0 RESULT err=14 tag=97 nentries=0 wtime=0.000076581 optime=0.000082736 etime=0.000158680, SASL bind in progress
このレコード例は、SASL バインドが現在進行中 (SASL bind in progress
) であり、戻りコード err=14
があることを示しています。これは、接続がまだ開いていることを意味します。Directory Server は、LDAP バージョン番号 (version=3
) および使用された SASL メカニズム (mech=DIGEST-MD5
) とともに SASL バインド情報をログに記録します。
SASL 認証には複数のステップが必要なため、Directory Server がバインドプロセスを完了すると、認証された DN (アクセス制御の決定に使用される DN) がバインドの RESULT 行に記録されます。これは、どのエントリーが SASL バインド要求にマップされたかを示しています。
[time_stamp] conn=14 op=1 RESULT err=0 tag=97 nentries=0 wtime=0.000076581 optime=0.000082736 etime=0.000158680 dn="uid=jdoe,dc=example,dc=com"
11.1.3. デフォルト以外のアクセスログの内容
デフォルト以外のログレベルを設定するか、特定のログ設定を適用すると、Directory Server はアクセスログファイルへの追加情報の記録を開始します。
内部操作のレコード
内部操作のロギングを有効にすると (4
)、Directory Server は、Directory Server またはクライアントによって開始された内部操作の記録を開始します。
サーバーが開始する内部操作
クライアントがエントリーを削除すると、サーバーはエントリーの検索や、ユーザーが所属していたグループの更新など、いくつかの内部処理を行います。
次の例は、サーバーが開始する内部操作のログ形式を示しています。
[time_stamp] conn=Internal(0) op=0(0)(0) MOD dn="cn=uniqueid generator,cn=config" [time_stamp] conn=Internal(0) op=0(0)(0) RESULT err=0 tag=48 nentries=0 wtime=0.0003979676 optime=0.0003989250 etime=0.0007968796
この例のレコードには conn=Internal
があり、その後に (0)
と op=0(0)(nesting_level)
が続いています。操作 ID と内部操作 ID は常に 0
です。ネストされていないログレコードの場合、ネストレベルは 0
です。
クライアントが開始する内部操作
クライアントが開始する内部操作のログには、実行された検索の詳細に加えて、検索ベース、スコープ、フィルター、および要求された検索属性が含まれます。次の例は、ログレコードの形式を示しています。
[time_stamp] conn=5 (Internal) op=15(1)(0) SRCH base="cn=config,cn=userroot,cn=ldbm database,cn=plugins,cn=config" scope=1 filter="objectclass=vlvsearch" attrs=ALL [time_stamp] conn=5 (Internal) op=15(1)(0) RESULT err=0 tag=48 nentries=0 wtime=0.0000143989 optime=0.0000151450 etime=0.0000295419 [time_stamp] conn=5 (Internal) op=15(2)(0) SRCH base="cn=config,cn=example,cn=ldbm database,cn=plugins,cn=config" scope=1 filter="objectclass=vlvsearch" attrs=ALL [time_stamp] conn=5 (Internal) op=15(2)(0) RESULT err=0
この例のレコードには、クライアント接続 ID に設定された conn
レコードがあり、その後に文字列 (Internal)
が続いています。op
レコードには、操作 ID と (internal_operation_ID)(nesting_level)
が含まれています。内部操作 ID は異なる場合があります。ネストされていないログエントリーの場合、ネストレベルは 0
です。
プラグインロギングが有効になっている場合の内部操作
nsslapd-plugin-logging
パラメーターが on
に設定されており、内部操作のロギング (4) が有効になっている場合、Directory Server はさらにプラグインの内部操作をログに記録します。
たとえば、uid=user,dc=example,dc=com
エントリーを削除し、Referential Integrity プラグインがこのエントリーを example
グループから自動的に削除すると、サーバーは次の内容をログに記録します。
[time_stamp] conn=2 op=37 DEL dn="uid=user,dc=example,dc=com" [time_stamp] conn=2 (Internal) op=37(1) SRCH base="uid=user,dc=example,dc=com" scope=0 filter="(|(objectclass=*)(objectclass=ldapsubentry))" attrs=ALL [time_stamp] conn=2 (Internal) op=37(1) RESULT err=0 tag=48 nentries=1 wtime=0.0000062569 optime=0.0000067203 etime=0.0000129148 [time_stamp] conn=2 (Internal) op=37(2) SRCH base="dc=example,dc=com" scope=2 filter="(member=uid=user,dc=example,dc=com)" attrs="member" [time_stamp] conn=2 (Internal) op=37(2) RESULT err=0 tag=48 nentries=0 wtime=0.0000058002 optime=0.0000065198 etime=0.0000123162 [time_stamp] conn=2 (Internal) op=37(3) SRCH base="dc=example,dc=com" scope=2 filter="(uniquemember=uid=user,dc=example,dc=com)" attrs="uniquemember" [time_stamp] conn=2 (Internal) op=37(3) RESULT err=0 tag=48 nentries=1 wtime=0.0000062123 optime=0.0000066022 etime=0.0000128104 [time_stamp] conn=2 (Internal) op=37(4) MOD dn="cn=example,dc=example,dc=com" [time_stamp] conn=2 (Internal) op=37(5) SRCH base="cn=example,dc=example,dc=com" scope=0 filter="(|(objectclass=\*)(objectclass=ldapsubentry))" attrs=ALL [time_stamp] conn=2 (Internal) op=37(5) RESULT err=0 tag=48 nentries=1 wtime=0.0000061994 optime=0.0000068742 etime=0.0000130685 [time_stamp] conn=2 (Internal) op=37(4) RESULT err=0 tag=48 nentries=0 wtime=0.0002600573 optime=0.0002617786 etime=0.0005217545 [time_stamp] conn=2 (Internal) op=37(6) SRCH base="dc=example,dc=com" scope=2 filter="(owner=uid=user,dc=example,dc=com)" attrs="owner" [time_stamp] conn=2 (Internal) op=37(6) RESULT err=0 tag=48 nentries=0 wtime=0.000061678 optime=0.000076107 etime=0.0000137656 [time_stamp] conn=2 (Internal) op=37(7) SRCH base="dc=example,dc=com" scope=2 filter="(seeAlso=uid=user,dc=example,dc=com)" attrs="seeAlso" [time_stamp] conn=2 (Internal) op=37(7) RESULT err=0 tag=48 nentries=0 wtime=0.0000031789 optime=0.0000035354 etime=0.0000066978 [time_stamp] conn=2 (Internal) op=37(8) SRCH base="o=example" scope=2 filter="(member=uid=user,dc=example,dc=com)" attrs="member" [time_stamp] conn=2 (Internal) op=37(8) RESULT err=0 tag=48 nentries=0 wtime=0.0000030987 optime=0.0000032456 etime=0.0000063316 [time_stamp] conn=2 (Internal) op=37(9) SRCH base="o=example" scope=2 filter="(uniquemember=uid=user,dc=example,dc=com)" attrs="uniquemember" [time_stamp] conn=2 (Internal) op=37(9) RESULT err=0 tag=48 nentries=0 wtime=0.0000021958 optime=0.0000026676 etime=0.0000048634 [time_stamp] conn=2 (Internal) op=37(10) SRCH base="o=example" scope=2 filter="(owner=uid=user,dc=example,dc=com)" attrs="owner" [time_stamp] conn=2 (Internal) op=37(10) RESULT err=0 tag=48 nentries=0 wtime=0.0000022109 optime=0.00000268003 etime=00000048854 [time_stamp] conn=2 (Internal) op=37(11) SRCH base="o=example" scope=2 filter="(seeAlso=uid=user,dc=example,dc=com)" attrs="seeAlso" [time_stamp] conn=2 (Internal) op=37(11) RESULT err=0 tag=48 nentries=0 wtime=0.0000021786 optime=0.0000024867 etime=0.0000046522 [time_stamp] conn=2 op=37 RESULT err=0 tag=107 nentries=0 wtime=0.005147365 optime=0.005150798 etime=0.0010297858
エントリーと参照へのアクセス
エントリーと参照へのアクセスのロギングを有効にすると (512
)、Directory Server のアクセスログファイルに次のレコードが記録されます。
[time_stamp] conn=306 fd=60 slot=60 connection from 127.0.0.1 to 127.0.0.1 [time_stamp] conn=306 op=0 SRCH base="dc=example,dc=com" scope=2 filter="(description=*)" attrs=ALL [time_stamp] conn=306 op=0 ENTRY dn="ou=Special [time_stamp] conn=306 op=0 ENTRY dn="cn=Accounting Managers,ou=groups,dc=example,dc=com" [time_stamp] conn=306 op=0 ENTRY dn="cn=HR Managers,ou=groups,dc=example,dc=com" [time_stamp] conn=306 op=0 ENTRY dn="cn=QA Managers,ou=groups,dc=example,dc=com" [time_stamp] conn=306 op=0 ENTRY dn="cn=PD Managers,ou=groups,dc=example,dc=com" [time_stamp] conn=306 op=0 ENTRY dn="ou=Red Hat Servers,dc=example,dc=com" [time_stamp0] conn=306 op=0 REFERRAL
この例は、ロギングレベルが 768
(512
+ 256
) であり、検索要求の応答として返される 6 つのエントリーと 1 つの参照を示しています。
オプションの説明
options=persistent
メッセージは、Directory Server が永続的な検索を実行することを示します。モニタリング目的で永続的な検索を使用し、変更が発生したときに指定した設定に変更を返すように設定できます。
次の例は、オプションの説明を含む 512
および 4
のログレベルを示しています。
[time_stamps] conn=1 (Internal) op=2(1)(0) SRCH base="cn=\22dc=example,dc=com\22,cn=mapping tree,cn=config"scope=0 filter="objectclass=nsMappingTree"attrs="nsslapd-referral" options=persistent
検索操作ごとの統計情報
nsslapd-statlog-level
属性を 1
に設定すると、アクセスログは、検索操作ごとに、インデックス検索の数やインデックス検索の全体的な時間などのメトリクスの収集を開始します。
[time_stamps] conn=1 op=73 SRCH base="dc=example,dc=com" scope=2 filter="(cn=user_*)" attrs=ALL [time_stamps] conn=1 op=73 STAT read index: attribute=objectclass key(eq)=referral --> count 0 [time_stamps] conn=1 op=73 STAT read index: attribute=cn key(sub)=er_ --> count 24 [time_stamps] conn=1 op=73 STAT read index: attribute=cn key(sub)=ser --> count 25 [time_stamps] conn=1 op=73 STAT read index: attribute=cn key(sub)=use --> count 25 [time_stamps] conn=1 op=73 STAT read index: attribute=cn key(sub)=^us --> count 24 [time_stamps] conn=1 op=73 STAT read index: duration 0.000010276 [time_stamps] conn=1 op=73 RESULT err=0 tag=101 nentries=24 wtime=0.00007841
このログレコードの例は、フィルター (cn=user_*)
を使用した検索中に、Directory Server が次の数のデータベース検索を実行したことを示しています。
- 参照は 0 回
-
er_
キーは 24 回 -
ser
キーは 25 回 -
use
キーは 25 回 -
^us
キーは 24 回
11.1.4. 一般的な接続コード
Directory Server は、接続の終了に関連する追加情報を含む接続コードを終了ログメッセージに追加します。
接続コード | 説明 |
---|---|
A1 | クライアントが接続を中断しました。 |
B1 | 破損した BER タグが検出されました。Directory Server は、回線経由で送信された破損した BER タグを受信すると、B1 接続コードをアクセスログに記録します。BER タグは、物理層ネットワークの問題や、LDAP クライアントがすべての要求の結果を受信する前に操作をキャンセルするなど、不適切な LDAP クライアント操作により破損する可能性があります。 |
B2 |
BER タグが |
B3 | 破損した BER タグが検出されました。 |
B4 | サーバーがクライアントに応答を送り返すことができませんでした。 |
P2 | 終了または破損した接続が検出されました。 |
T1 |
|
T2 |
|
T3 | ページ結果検索に指定した時間制限を超えたため、サーバーが接続を閉じました。 |
U1 | クライアントがバインド解除要求を送信した後に、サーバーが接続を閉じます。サーバーはバインド解除要求を受信すると、常に接続を閉じます。 |