Auditing overview

A configuration manager can track the changes to a CI by enabling audit for the class to which the CI belongs, and the attributes of the CI. Auditing involves tracking changes to a CI by creating a copy of the instance that was created or modified, or by writing the changes to a log.

Example

Chris, the configuration manager at Calbro Services wants to understand and identify all the changes to business services and the supporting technical services. Chris enables Copy audit on the BMC_BusinessService class. 

Auditing options for classes

You can specify the following types of audit for a class:

• Copy
• Log

Copy 

A Copy audit creates a copy of each audited instance.
When you enable Copy audit for a class, each Remedy AR System form belonging to that class is duplicated to create audit forms. Audit forms hold audited instances. The forms belonging to superclasses are also copied, because they hold data for instances of the superclasses.
The audit forms are named with the suffix :AUDIT. For example, if you enable audit for the BMC_Person class, which is a subclass of the BMC_BaseElement class, the following audit forms are created:

Log

When you enable Log audit for a class, you must specify the name of the log form to use. If this form does not already exist, the application creates the form. You can use the same log form for multiple classes.
When an audit is triggered, an entry is created in the log form. 

An example log form is shown in the following figure:

Each Log audit form includes the following fields:

• GUID — The InstanceId of the audited instance.
• Log Key1 — The ClassId of the audited instance.
• Log Key2 — The DatasetId of the audited instance.
• Fields Changed — A list of the attributes in the format name1; name2; name3 with values that changed in the action that triggered the audit. This field is not populated for Delete action on classes and attributes.
• Log — A list of the attribute values written for the audit.
• Audit Date — The timestamp of the audit.
• User — The user who performed the action that triggered the audit.

• Action — An integer representing the action that triggered the audit.
  The following table lists the possible values:

  Action	Value
  Modify	2
  Create	4
  Delete	8
  Merge	16

When an audit is triggered, an entry is created in the log form. 

For information about selecting attributes to write to the Log field, see Auditing options for attributes.

Best practices when deciding to select Copy audit or Log audit

Use the following considerations to decide whether to use Copy or Log audit:

• Copy audits degrade performance because their structure matches the actual CMDB class forms that use database joins. Because the join forms must be created when Copy audit is enabled, there is a bigger performance cost and possibly more disruption related to the change control procedure.
• Copy audits provide a more powerful search capability than Log audits because you can search on each attribute in a separate field.

Auditing options for attributes

For each attribute in a class, you can choose one of the following audit options:

• None — None is the default option.
  If this option is selected, changes to the attribute do not trigger an audit and its value is not copied or logged in the audit entry. For a Copy audit entry, this attribute is always NULL in the audit form. For a log audit entry, this attribute is not part of the Log field.
• Audit — An audit is triggered when there are changes to the attribute for which audit is enabled. The audit attribute is copied only if it changes and triggers an audit. Otherwise, it is not copied.  
• Copy — An audit is not triggered when there are changes to the attribute for which copy audit is enabled, but the attribute value is written to the audit form or log form when another attribute triggers an audit.
• Audit and Copy —An audit is triggered when there are changes to the attribute for which audit is enabled. This attribute value is written to the audit form or log form in any audit, regardless of whether its value changed or not.

The following table explains the changes to the audit form and log form for operations that trigger an audit: 

In this example, Audit attribute AssignedTo and Audit and Copy attribute SerialNumber are the only attributes that can trigger an audit. However, when the instance is created, an audit is triggered regardless of the fact that they are both NULL.

When the instance is modified in Operation 2, the value of AssignedTo changes, triggering an audit that writes that attribute. AccountID and SerialNumber are also written, as they are in any audit. Both AccountID and SerialNumber change value in Operation 3, but no audit is triggered.

In Operation 4, SerialNumber changed value and another audit is triggered. This time AssignedTo is not written because its value did not change. And when the instance is deleted in Operation 5, a final audit is triggered.