Types of auditing

You can audit by creating a copy of the instance that was created, modified, or deleted, or by writing the changes to a log.

You cannot use Log auditing above Copy auditing in the inheritance tree. This means that if you already have Copy auditing enabled for a class you cannot enable Log auditing for any of its superclasses, and if you already have Log auditing enabled for a class you cannot enable Copy auditing for any of its subclasses. This is due to the structure of audit forms.

Recommendations

Keep these considerations in mind when deciding whether to use Copy or Log auditing:

• Copy audits degrade performance more than Log audits because their structure matches that of the actual CMDB class forms, which use database joins. Also, because those join forms must be created when Copy auditing is enabled, there is a bigger performance cost at that time and possibly more disruption related to your 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.

Copy auditing

Copy auditing creates a copy of each audited instance. When you enable Copy auditing for a class, each form pertaining to that class is duplicated to create audit forms that hold audited instances. This includes forms from superclasses, because they hold data for instances of their subclasses. The audit forms are automatically named with the suffix :AUDIT. For example, if you enable auditing for the BMC_Person class, which is a subclass of the BMC_BaseElement class, three audit forms are created:

Audit forms created for BMC_Person

The audit forms have the same BMC Remedy AR System permissions as the class itself. If you make a change to a class after these forms have been created, they are automatically updated to match. When you delete a class, its associated audit forms are also deleted.

Each audit of each instance results in an entry in the audit form, so multiple entries can be related to a given instance.

The audit form mirrors the class form, containing a field for each attribute in the class. When an audit occurs, values for the selected attributes are written to their respective fields, creating a new copy of the instance.

In addition to the class attribute fields, each audit form also includes the following fields:

• Audit Join Key — A GUID representing the specific audit entry.
• Fields Changed (multiple) — A field is created for each Audit attribute and Audit and Copy attribute to specify whether that attribute value changed in the audited instance. If such an attribute changed value, its corresponding Fields Changed field in the audit form contains a 1. If not, the field is empty. The name of each Fields Changed field is F_ fieldId_C, using the field ID of the attribute on its class form.

Copy attributes and None attributes do not have Fields Changed fields in the audit form because they cannot trigger an 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 and their meanings:

Audit actions

When an audit is triggered, the audited instance is copied from each class form to the corresponding audit form.

Copy auditing in BMC CMDB is implemented using BMC Remedy AR System form-style auditing. For more information about form-style auditing, see Developing an application in the BMC Remedy Action Request System online documentation.

Log auditing

Log auditing creates an entry in a log form that stores all attribute values from the audited instance in one field. When you enable Log auditing for a class, you specify the name of the log form to use. If this form does not already exist, it is created automatically. You can use the same log form with multiple classes.

Each Log audit form includes these 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 with values that changed in the action that triggered the audit, in the format name1; name2; name3. This field is not populated when the Action is Delete.
• Log — A list of the attribute values written for the audit, in the following format:
  name1: value1
  name2: value2
  [ name3: value3]
• 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 and their meanings.

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 Setting the Audit option for attributes.

Log auditing in BMC CMDB is implemented using BMC Remedy AR System log-style auditing. For more information about log-style auditing, see Developing an application in the BMC Remedy AR System online documentation.

How Calbro Services uses auditing

The Calbro Services administrator knows that changes to the service model can be disruptive to the customers using those services. To help identify all of the changes to business services and the supporting technical services, the administrator decides to audit the BMC_BusinessService class.

Copy auditing this class should not affect overall system performance because changes to the BMC_BusinessService class should be few in number. Copy auditing also enables greater ability to search for changes to the class. For these reasons, the administrator configures copy auditing instead of log auditing.

Related topics

Differences between auditing and the compare dataset activity

Selecting instances and attributes to be included in an audit

Receiving CI change events with Event Channels