Resource usage of Snapshot, Audit, and Compliance Jobs

This section describes Snapshot, Audit, and rules-based Compliance Jobs and their resource usage.

Snapshot Jobs

Snapshot Jobs collect information about assets from a target and convey that information to the Application Server. The Application Server receives the information about each asset and stores it in a local file with an .snp (snapshot) suffix. If a snapshot includes a file's content, the Application Server receives that content as a separate file and does not include it in the .snp file. The Snapshot Job constructs one .snp file for each component part.

After it constructs the .snp file on the Application Server, the Snapshot Job scans the file and compares it to the most recent earlier snapshot from that target, if one exists. The new .snp file is compared to a .bnp (baseline snapshot) file that represents the previous scan. If the .bnp file from the last scan of this particular target exists on the file server, it is copied from the file server to the local Application Server and then used for comparison. Otherwise, the job server uses the data in the database to reconstruct a .bnp file as it would have existed following the last scan of this particular target.

After the comparison, only the differences between the two versions are stored in the BMC Server Automation database. Therefore, repeated snapshots of an asset that changes very little or not at all result in relatively little information being stored in the database. For example, in the case of an unchanged file, no additional data is recorded in the database.

Files are the most common type of asset used in Snapshot and Audit Jobs. To perform a full snapshot of a file, the entire contents of that file must be transferred to the Application Server. In contrast, to capture just the MD5 digest (checksum) of a file (instead of the actual contents), the 128-bit MD5 digest value is calculated on the target, and only that 128-bit value is transmitted to the Application Server for storage in the .snp file.

After completion of the Snapshot Job, the .snp and .bnp files are automatically deleted from the temporary folder on the file server.

The following table shows a summary of resource usage for Snapshot Jobs.

Audit Jobs

Audit Job behavior is largely similar to that of Snapshot Jobs, in that it involves constructing and comparing two snapshot files on the Application Server (with an .snp suffix this time), and recording only the differences.

For Audit Jobs, master .snp files are always constructed as part of the job. For live audits, a snapshot of the master target is performed and the results are captured in .snp files. For a snapshot-based audit, the master .snp file is generated from data in the database. The master .snp files are copied to the file server, if necessary, and shared among any Application Servers that run work items for the Audit Job.

After the master .snp files have been constructed, each target of the audit job is processed by first constructing a target .snp file and then comparing the master and target .snp files. Differences between the two .snp files are recorded in the database. For each difference detected, the asset from the target .snp file is persisted in the database, regardless of how many earlier audits might have detected the same difference. After each audit target is processed, the target .snp files for that target are discarded.

Upon completion of the Audit Job, master .snp files are automatically deleted from the temporary folder on the file server.

The following table shows a summary of resource usage for Audit Jobs.

Compliance Jobs

Compliance jobs, also called rule-based compliance jobs, perform the following actions:

• Collecting asset information on the target
• Transferring that data back to the Application Server
• Applying the user-specified rules to the returned data to assess the target's compliance

Unlike Audit and Snapshot Jobs, Compliance Jobs do not use temporary snapshot files (.snp or .bnp) on the Application Server. When a Compliance Job runs, each work item operates by looping through the component parts of its assigned component. For each component part, the work item decides whether or not it needs to retrieve data from the target. If it does need to retrieve assets for the current component part, a single request is issued to collect the required information for each of the assets to be tested. As each requested asset arrives on the Application Server, the relevant conditions are applied to determine compliance.

The result of applying each condition (compliant, noncompliant, or noncompliant with exception) is recorded in the database. In the case of a noncompliant result, the specific value under test is also recorded in the database. For example, a non-complying condition on file size causes the actual file size to be recorded in the database, but not the contents of the file.

Compliance autoremediation

If a target is noncompliant and if the Compliance Job has the Allow Auto-remediation option specified, then each non-compliant rule failure which has a remediation package associated is selected to be part of combined BLPackage for that host. (Any other hosts with the same combination of failing rules use the same remediation package.) The Compliance Job then runs a BLPackage Deploy Job against the noncompliant targets. The Compliance Job does not complete until the BLPackage Deploy Job has completed.

The table shows a summary of resource usage for Compliance Jobs that perform autoremediation.