This documentation supports the 21.05 version of BMC Helix CMDB.

To view an earlier version, select the version from the Product version menu

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.

Scenario

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. 

Audit options for classes

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


Copy audit

A Copy audit creates a copy of each audited instance.
When you enable Copy audit for a class, each 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:

Form type

Class form

Audit form

Regular

BMC.CORE:BMC_BaseElement

BMC.CORE:BMC_BaseElement:AUDIT

Regular

BMC.CORE:BMC_Person_

BMC.CORE:BMC_Person_:AUDIT

Join

BMC.CORE:BMC_Person

BMC.CORE:BMC_Person:AUDIT

Log audit

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 name1name2name3 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.


Notes

  • When audit is enabled for a class, audits can be triggered by changes to attributes belonging to CIs of either the class or its subclasses even if auditing is not enabled for the subclass. The audit is triggered based on the hierarchical structure of class forms. When an audit is triggered by attributes belonging to an instance of a subclass, the attributes of the audit-enabled superclass are written to the audit form.
    If you do not want subclass instances to trigger an audit for the superclass, you must use an audit qualification for the subclass.
  • If you already have Copy audit enabled for a class, you cannot enable Log auditing for any of its superclasses. If you already have Log audit enabled for a class, you cannot enable Copy audit for any of its subclasses.

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 bring down the 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 select 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 with an example, the changes to the audit form and log form for operations that trigger an audit: 

Operation Order

Operation

AssignedTo (Audit)

AccountID (Copy)

SerialNumber
(Audit and Copy)

ShortDescription (None)

Audit triggered?

Attributes written to audit form

1.

Create

NULL

2255

NULL

Calbro Payroll Dept

Yes

AssignedTo, AccountID, SerialNumber

2.

Modify

Miguel

2255

NULL

Calbro Payroll comp assigned to Miguel

Yes

AssignedTo, AccountID, SerialNumber

3.

Modify

Miguel

2255I

NULL

Assigned to Miguel

No

None

4.

Modify

Miguel

2255I

SER234IO22

Assigned to Miguel

Yes

AccountID, SerialNumber

5.

Delete

N/A

N/A

N/A

N/A

Yes

AssignedTo, AccountID, SerialNumber

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. 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.



Was this page helpful? Yes No Submitting... Thank you

Comments