About Logs
| Type | Description |
|---|---|
| Access | Messages about clients accessing the server. Each message includes a datestamp, information about the connection, and information about the operation. DS servers implement access logs for HTTP and LDAP. It is possible to configure multiple access logs at the same time. Do not enable multiple unfiltered file-based access loggers for the same protocol, however. This can put significant write load on the disk subsystem for access log files, because every client request results in at least one new log message. |
| Audit | Records changes to directory data in LDIF. DS servers implement an audit log as a special type of file-based access log. By default, the server writes messages to For an example, see "Enable an Audit Log". |
| Debug | Messages tracing internal server events, for troubleshooting. By default, this is a file-based log, written to Debug logs can grow large quickly, and therefore no debug logs are enabled by default. For debug logging, you must set a debug target to control what gets logged. For details, see "Debug Logging". |
| Error | Messages tracing server events, error conditions, and warnings, categorized and identified by severity. By default, this is a file-based log, written to Messages have the following format: [datestamp] category=category severity=severity msgID=ID number msg=message string For lists of severe and fatal error messages by category, see the Log Message Reference. |
| Replication repair | Messages to help repair problems in data replication. This is a file-based log, written to Messages have the following format: [datestamp] category=SYNC severity=severity msgID=ID number msg=message string The replication log does not trace replication operations. Use the external changelog instead to get notifications about changes to directory data. For details, see Changelog for Notifications. |
| Server | Messages about server events since startup. This is a file-based log, written to Messages in this file have the same format as error log messages. |
You configure logging using log publishers. Log publishers determine which messages to publish, where to publish them, and what output format to use.
DS server logging supports extensibility through the ForgeRock Common Audit event framework. Common Audit deals with any event you can audit, not only the data updates recorded in a directory audit log. The ForgeRock Common Audit event framework provides log handlers for publishing to local files or to remote systems.
Common ForgeRock Access Logs
DS servers support the ForgeRock Common Audit event framework. The log message formats are compatible for all products using the framework. The framework uses transaction IDs to correlate requests as they traverse the platform. This makes it easier to monitor activity and to enrich reports:
The ForgeRock Common Audit event framework is built on audit event handlers. Audit event handlers can encapsulate their own configurations. Audit event handlers are the same in each product in the ForgeRock platform. You can plug in custom handlers that comply with the framework without having to upgrade the server.
The ForgeRock Common Audit event framework includes handlers for logging to local files and to external services.
Although the ForgeRock Common Audit event framework supports multiple topics, DS software currently supports handling only access events. DS software divides access events into
ldap-accessevents andhttp-accessevents.Common Audit transaction IDs are not recorded by default. To record transaction IDs in the access logs, configure the DS server to trust them.
Common Audit LDAP events have the following format:
{
"eventName": "DJ-LDAP",
"client": {
"ip": string, // Client IP address
"port": number // Client port number
},
"server": {
"ip": string, // Server IP address
"port": number // Server port number
},
"request": { // LDAP request
"attrs": [ string ], // Requested attributes
"authType": string, // Bind type such as "SIMPLE"
"connId": number, // Connection ID
"controls": string, // Request controls
"deleteOldRDN": boolean, // For a modify DN request
"dn": string, // Bind DN
"filter": string, // Search filter
"idToAbandon": number, // ID to use to abandon operation
"message": string, // Localized request message
"msgId": number, // Message ID
"name": string, // Operation name
"newRDN": string, // For a modify DN request
"newSup": string, // For a modify DN request
"oid": string, // Operation name or OID
"operation": string, // Examples: "CONNECT", "BIND", "SEARCH"
"opType": "sync", // Replication operation
"protocol": "LDAP",
"runAs": string, // Authorization ID
"scope": string, // Search scope such as "sub"
"version": string // Version "2", "3"
},
"response": {
"additionalItems": string // Additional information
"controls": string, // Response controls
"elapsedTime": number, // Number of time units
"elapsedTimeUnits": string, // Time unit such as "MILLISECONDS"
"failureReason": string, // Human-readable information
"maskedMessage": string, // Real, masked result message
"maskedResult": string, // Real, masked result code
"nentries": number, // Number of entries returned
"reason": string, // Reason for disconnect
"status": string, // "SUCCESSFUL", "FAILED"
"statusCode": string // For example, "0" for success
},
"timestamp": string, // UTC date
"transactionId": string, // Unique ID for the transaction
"userId": string, // User who requested the operation
"_id": string // Unique ID for the operation
}Common Audit HTTP events have the following format:
{
"eventName": "DJ-HTTP",
"client": {
"ip": string, // Client IP address
"port": number // Client port number
},
"server": {
"ip": string, // Server IP address
"port": number // Server port number
},
"http": { // HTTP request and response
"request": {
"secure": boolean, // HTTP: false; HTTPS: true
"method": string, // Examples: "GET", "POST", "PUT"
"path": string, // URL
"queryParameters": map, // map: { key-string: [ value-string ] }
"cookies": map // map: { key-string: [ value-string ] }
},
"response": {
"headers": map // map: { key-string: [ value-string ] }
}
},
"response": {
"detail": string, // Human-readable information
"elapsedTime": number, // Number of time units
"elapsedTimeUnits": string, // Time unit such as "MILLISECONDS"
"status": string, // "SUCCESSFUL", "FAILED"
"statusCode": string // For example, "0" for success
},
"timestamp": string, // UTC date
"transactionId": string, // Unique ID for the transaction
"trackingIds": [ string ], // Unique IDs from the transaction context
"userId": string, // User who requested the operation
"_id": string // Unique ID for the operation
}Access Log Filtering
With the default access log configuration (no filtering), for every client application request, the server writes at least one message to its access log. This volume of logging gives you the information to analyze overall access patterns, or to audit access when you do not know in advance what you are looking for.
When you do know what you are looking for, log filtering lets you throttle logging to focus on what you want to see. You specify the criteria for a filtering policy, and apply the policy to a log publisher.
Log filtering policies use the following criteria:
Client IP address, bind DN, group membership
Operation type (abandon, add, bind, compare, connect, delete, disconnect, extended operation, modify, rename, search, and unbind)
Port number
Protocol used
Response time
Result codes (only log error results, for example)
Search response criteria (number of entries returned, unindexed search, and others)
Target DN
User DN and group membership
A log publisher's filtering policy determines whether to include or exclude log messages that match the criteria.
For examples, see "Filter Out Administrative Messages" and "Audit Configuration Changes".