Selecting instances and attributes to be included in an audit

You can restrict which instances of a given class are audited and determine which attributes can trigger an audit and are written in an audit.

Restricting audited instances with a qualification

You restrict which instances are audited by specifying an audit qualification for each class that has auditing enabled. If an instance does not match the qualification, an audit cannot be triggered for it.

However, a superclass with auditing enabled can alter the effect of an audit qualification. If an instance of an auditing-enabled class fails the audit qualification for that class but matches the audit qualification of an auditing-enabled superclass, the attributes of the instance that are inherited from the superclass are audited.

For example, if auditing is enabled for both BMC_System and BMC_ComputerSystem, and an instance of BMC_ComputerSystem fails its own audit qualification but matches that of BMC_System, the attributes of BMC_System are audited for the instance. If BMC_System did not have auditing enabled, no part of the instance would be audited.

 Setting the Audit option for attributes

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

• None — Changes to this attribute do not trigger an audit. NULL is written to the attribute in the audit form in a Copy audit, and nothing is written to the Log field in a Log audit. This option is the default.
• Audit — Changes to this attribute trigger an audit, and the attribute value is written to the audit form or log form. When another attribute triggers an audit, this attribute is not written.
• Copy — Changes to this attribute do not trigger an audit, but the attribute value is written to the audit form or log form when another attribute triggers an audit.
• Audit and Copy — Changes to this attribute trigger an audit. This attribute value is written to the audit form or log form in any audit, regardless of whether its value changed.

The following table shows whether certain operations to a sample instance, taken in chronological order, trigger an audit. It assumes an instance that matches the audit qualification for its class.

In this example, Audit attribute Attribute1 and Audit and Copy attribute Attribute3 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 Attribute1 changes, triggering an audit that writes that attribute. Attribute2 and Attribute3 are also written, as they are in any audit. Both Attribute2 and Attribute4 change value in Operation 3, but no audit is triggered.

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

Recommendations

This section gives you several recommendations for working with auditing.

• Enable auditing for only up to five classes, as high on the inheritance tree as possible and preferably no more than five join levels deep. For each of those, use only up to five Audit attributes.
• Do not audit system attributes like LastModifiedBy or ModifiedDate if you use Log auditing. BMC Remedy AR System keeps a history of these already.
• Rather than auditing a lower-level class in your data model inheritance tree, audit the highest-level class with attributes you want to keep and then use a qualification on the ClassId attribute to control which classes' instances are audited. This improves performance by preventing join forms from being involved.
   For example, imagine that you want to audit instances of BMC_ComputerSystem, BMC_OperatingSystem, and BMC_ApplicationSystem ; you want to trigger an audit only if the value of the OwnerName attribute changes; and you want to write OwnerName and Name to the audit form or log form. Because OwnerName and Name are both inherited from BMC_BaseElement, you would enable auditing for that class and use a qualification on ClassId to select only the subclasses that you want.
• Use a qualification on the DatasetId attribute to restrict auditing to your production dataset. You rarely need to audit other datasets, so you will save processor time and disk space.
• When a component such as a disk drive disappears from the display of its parent configuration item (CI) such as a computer system in BMC Asset Management, it is usually caused by the connecting relationship being unintentionally soft-deleted while the component CI still exists. To track this behavior, enable auditing on BMC_BaseRelationship (with a qualification on source and destination class IDs if you want), use MarkAsDeleted as an Audit attribute, and use the source and destination instance IDs as Copy attributes.
• Not every Copy attribute must also be an Audit attribute.

Related topics

Differences-between-auditing-and-the-compare-dataset-activity

Types-of-auditing

Receiving-CI-change-events-with-Event-Channels