Administrator's Guide — Chapter 12

Audit Log Files

When auditing is enabled, MarkLogic Server writes audit events to the AuditLog.txt file. Each host in a cluster maintains its own audit log files. Some actions might trigger multiple audit events, and those events might be logged over multiple hosts, as events are audited on the host in which the event occurs. For more information about the audit events, see Auditable Events. Note the following about the audit event log files:

• Writes messages to AuditLog.txt file for various events.
• Each event has a timestamp, event type, user, role, and other information relevant to the event (for example, document URI for document-read event). For an example of log entries, see Sample Audit Logs.
• You can configure how often to rotate the audit files (similar to the log files, as described in Log Files).
• The Audit log files are stored in the same directory as the Access log files (port_AccessLog.txt) and the Error log files (ErrorLog.txt), which is in the <marklogic-data-dir>/Logs directory. These files are private to the host in which the audit event occurred.
• You may view the current or any archived file log at any time using standard text file viewing tools. Additionally, you can access the log files from the Log tab on the main page of the Admin Interface.

The following table shows the location of the AuditLog.txt files on the various platforms.

Restricting Audit Events

You can configure auditing to restrict events that are audited based on the following criteria:

• You can select which events to audit.
• You can include or exclude events by user name. For included users, only events initiated by the named users are audited. For excluded users, only events initiated by users other that the named users are audited.
• You can include or exclude events by role. For included roles, only events initiated by users with the included roles are audited. For excluded roles, only events initiated by users who do not have the excluded roles are audited.
• You can include or exclude events by outcome of event (success/failure/both).
• You can include or exclude events by document URI. Documents URIs are audited if any fragment from that document is loaded into memory, and that audit event is written to the audit log on the host in which the forest that contains the document resides.

For the procedure to set up auditing, see Configuring Auditing to Audit Certain Events and Set Up Certain Restrictions.

Audit Successful, Unsuccessful, or Both Types of Events

You can choose to audit only unsuccessful, only successful, or both types of events. If you audit many events and/or if you audit both successful and unsuccessful events, then you may end up auditing a lot of events. It is not really a problem to audit many events, but it might make your audit logs get very large very fast. For the procedure to set up auditing, see Configuring Auditing to Audit Certain Events and Set Up Certain Restrictions.

Enabled at the Group Level

You can enable or disable auditing for each group. If auditing is enabled for a group, any configured auditable event for that group is audited. For details on the procedure to enable auditing, see Enabling Auditing for a Group.

Audit Log Content

The information included in an audit log depends on the type of event. All audit log entries include basic information such as the event type, user, success, and roles assigned to the user. Audit log entries may include the following space-separated fields:

Sample Audit Logs

Here are some sample AuditLog.txt entries with user-specific information obsfucated.

2012-03-26 10:55:53.735 event=amp-usage; 
function=http://marklogic.com/xdmp/admin:read-config-file;
uri=/MarkLogic/admin.xqy; database=filesystem;
success=true; user=admin; roles=admin;

2012-03-23 15:04:32.141 event=security-access; user(admin-xxx); success=true; 
user=admin-xxx; roles=admin;

2012-03-23 15:04:32.176 event=document-read;
uri=http://marklogic.com/xdmp/privileges/7768816571421711260;
database=Security; success=true; user=admin-xxx; roles=admin;

2012-03-23 15:05:26.957 event=lexicon-read;
expr=cts:element-value-query(xs:QName("info:status"),
("active", "unloading"), ("unstemmed","lang=en"), 1);
database=App-Services; success=true; user=infostudio-admin;
roles=cpf-restart,infostudio-user;

2012-03-23 15:07:05.164 event=document-update; type=node-update;
uri=/workspaces/14061174091930893017.xml; database=App-Services;
success=true; user=admin-xxx; roles=admin;

2012-03-23 15:07:05.674 event=document-insert; type=insert;
uri=/queries/5523898374388210414.txt; database=App-Services;
success=true; user=admin-xxx; roles=admin;

Enabling Auditing for a Group

Perform the following steps to enable auditing for a group:

1. Access the Admin Interface with a browser.
2. Open the Audit Configuration screen (Groups > group_name > Auditing).
3. Select True for the Audit Enabled radio button.
4. Configure any audit events and/or audit restrictions you want.
5. Click OK.

Disabling Auditing for a Group

Perform the following steps to disable auditing for a group:

1. Access the Admin Interface with a browser.
2. Open the Audit Configuration screen (Groups > group_name > Auditing).
3. Select False for the Audit Enabled radio button.
4. Click OK.

This will immediately disable auditing for the group. Any settings you had configured will remain, but will not be in effect until you enable auditing again.

Configuring Auditing to Audit Certain Events and Set Up Certain Restrictions

The following is the general procedure for configuring audit events and audit restrictions. Your procedure will vary depending on what events and restrictions you choose to configure.

1. Access the Admin Interface with a browser.
2. Open the Audit Configuration screen (Groups > group_name > Auditing).
3. Under Audit Events, choose the events you want audited. For a description of each event, see Auditable Events.
4. Under Audit Restrictions, enter any restrictions you want. For details on audit restrictions, see Restricting Audit Events.
5. Click OK to save your changes.