Guidelines for configuring auditing
Before you configure auditing, consider these guidelines for creating an audit plan, creating audit definitions, and managing the audit log.
Creating an audit plan
- Create an audit plan. Decide what information you want to see. Reviewing audit logs can take up time. Do not audit events that you are not interested in.
- Consider the resources you have available. Audit logs take up storage space.
Creating audit definitions
- If you are interested in the history of a document, audit checkin events.
if you are interested in the value of a particular field, audit update events.
- If you want to audit a specific field value, configure the field for auditing and audit the creation, update, and deletion events instead of selecting the option to record before and after snapshots of the object.
- If you want to audit a specific property in all classes where it is defined, set the Audit As value on the property template. If you want to audit the property only on some classes, set the Audit As value on the property definition for each class you want to audit.
- If you want to audit a specific property for all events, add the property to the Object Change Event class. If you want to audit the property only on some events, add the property to the event subclasses that you want to audit.
- If you want a complete record of the changes to an object, set the object state recording level to capture before and after snapshots of the object. Snapshots use a lot of database space, so consider your storage resources before including snapshots.
- If possible, minimize the number of columns that you add to the audit log by setting the Audit As value to a generic property on the event class. You can use a generic property for the Audit As value as long as the classes being audited are not the same. For example, if you want to audit the document title for the Document class and the folder name for the Folder class, you can set the Audit As values for both classes to use a single event class property called
ObjectName
.
- Whenever possible, use the same data type for the property to be audited and for the property that is added to the event class that triggers the audit.
Data type of the property to be audited |
Data type of the associated event property |
Binary |
Binary |
Boolean |
Boolean, string |
DateTime |
DateTime, string |
Float |
Float, string |
ID |
ID, string |
Integer |
Integer, string |
Object |
Object, string, ID |
String |
String |
In addition, the single or multi-value attribute of the property to be audited and the property you select for the Audit As value must match.
Managing the audit log
- Implement an audit disposition policy to delete obsolete event records from the audit log.
- An audit processing client is responsible to create a bookmark and to update it each time it processes a batch of records. If an audit processing client neglects to create or update its bookmark, audit disposition is controlled solely by the audit disposition policies of the object store. Depending on the disposition rules defined in the policies, unprocessed audited records might get deleted prematurely. To avoid premature deletion of audit entries, do not enable audit disposition until after audit processing clients have begun operations.
- Do not remove user-defined property definitions on an audited event class as a way to stop auditing specific object properties. Doing so results in removing the corresponding values from existing audit entries in the audit log.