2020-05-28_00-43-49_.Selecting instances and attributes to be included in an audit v9.1.04
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.
Note
As long as a class has at least one attribute with the Audit, Copy, or Audit and Copy option specified, a Create or Delete operation triggers an audit regardless of the values of the attributes. Audit, Copy, and Audit and Copy attributes are all written during such an audit.
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.
Audit life cycle of a sample instance
Operation order | Operation | Attribute1 (Audit) | Attribute2 (Copy) | Attribute3 (Audit and Copy) | Attribute4 (None) | Audit triggered? | Attributes written to audit form |
---|---|---|---|---|---|---|---|
1 | Create | NULL | Chicago | NULL | Compact disc | Yes | Attribute1 Attribute2 Attribute3 |
2 | Modify | Green | Chicago | NULL | Cassette tape | Yes | Attribute1 Attribute2 Attribute3 |
3 | Modify | Green | Dallas | NULL | 8-track tape | No | None |
4 | Modify | Green | Dallas | Bicycle | 8-track tape | Yes | Attribute2 Attribute3 |
5 | Delete | N/A | N/A | N/A | N/A | Yes | Attribute1 Attribute2 Attribute3 |
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
orModifiedDate
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 ofBMC_ComputerSystem
,BMC_OperatingSystem
, andBMC_ApplicationSystem
; you want to trigger an audit only if the value of theOwnerName
attribute changes; and you want to writeOwnerName
andName
to the audit form or log form. BecauseOwnerName
andName
are both inherited fromBMC_BaseElement
, you would enable auditing for that class and use a qualification onClassId
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), useMarkAsDeleted
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
Comments
Log in or register to comment.