第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 は、次の検索インジケーターをサポートしています。

検索インジケーター説明

notes=P

ページ検索インジケーター。リソースが制限された LDAP クライアントでは、LDAP サーバーが検索操作の結果を返す速度を制御できます。実行された検索で LDAP 制御拡張を使用して検索結果を単純にページングすると、Directory Server は notes=P ページ検索インジケーターをログに記録します。このインジケーターは情報を提供するもので、それ以上のアクションは必要ありません。ページ検索インジケーターの詳細は、RFC 2696 仕様 を参照してください。

notes=A

インデックスのない検索インジケーター。フィルター内のすべての候補属性がインデックス化されておらず、テーブル全体のスキャンが必要な場合、Directory Server は notes=A をログに記録します。これは、nsslapd-lookthroughlimit 属性で設定した値を超えている場合があります。

notes=U

インデックスのない検索インジケーター。次の状況では、Directory Server は notes=U をログに記録します。

  • 少なくとも 1 つの検索用語がインデックス化されていない。
  • 検索操作が、nsslapd-idlistscanlimit 属性で設定された制限を超えている。

notes=F

不明な属性インジケーター。検索フィルターに不明な属性が含まれている場合、Directory Server は notes=F を記録します。

notes=M

MFA プラグインバインドインジケーター。MFA プラグインなどの事前バインド認証プラグインを使用してユーザーアカウントの 2 要素認証を設定すると、Directory Server は notes=M をログに記録します。

note レコードには、notes=P,Anotes=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 のレプリケーションエントリー要求

状態情報 (csn および UniqueIdentifier) を含むエントリーを保持し、レプリカの初期化を実行するために使用される。

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 タグが nsslapd-maxbersize 属性値よりも長くなっています。

B3

破損した BER タグが検出されました。

B4

サーバーがクライアントに応答を送り返すことができませんでした。

P2

終了または破損した接続が検出されました。

T1

nsslapd-idletimeout 属性で設定できるアイドル期間が経過し、クライアントが結果を受け取りません。

T2

nsslapd-ioblocktimeout で設定した時間が経過し、サーバーが停止した LDAP クライアントへの接続を閉じました。

T3

ページ結果検索に指定した時間制限を超えたため、サーバーが接続を閉じました。

U1

クライアントがバインド解除要求を送信した後に、サーバーが接続を閉じます。サーバーはバインド解除要求を受信すると、常に接続を閉じます。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.