Writer instructions

Page title

For most spaces, this page must be titled Space announcements.

For spaces with localized content, this page must be titled Space announcements l10n.

Purpose

Provide an announcement banner on every page of your space.

Location

Move this page outside of your home branch.

Guidelines

Limited supportBMC provides limited support for this version of the product. As a result, BMC no longer accepts comments in this space. If you encounter problems with the product version or the space, contact BMC Support.BMC recommends upgrading to the latest version of the product. To see documentation for that version, see MainView Middleware Monitor 9.2.

Using audit logs to manage and maintain the product

The audit logging function enables administrators to maintain a permanent, predictable, and consistent record of activities for some of the actions performed by the MainView Middleware Monitor product. This function captures the time (local and server) that the action occurred, who initiated the action, and what the action entailed. Audit log data is stored in the database used by MainView Middleware Monitor. This logging provides a useful history that can be queried using the audittool CLI. It also provides a mechanism for administrators to review the audit log and correlate the log information against the external activity.

Related topics

Configuring-audit-logging-permissions-for-MQ-Actions 

Testing-and-querying-audit-records

Audited actions

Audited actions include policy actions, agent-related actions, and MQ actions. Except for MQ actions, all actions always have auditing enabled.

For MQ Actions, you can enable audit logging on a group level, enabling administrators to specify which user groups to log. MainView Middleware Monitor administrators define the groups to log, and whether a failure to log an event causes the loggable action to fail or proceed. If the audit log information cannot be updated for any reason, an error is issued and the action the user was attempting will either fail or proceed. If logging is configured to proceed on failure, an error is displayed but the item is not written to the log and, therefore, is lost from the audit log.

Best practices for maintaining audit logging in the database

  • Secure audit database/tables from unauthorized use: Database security for the audit information is beyond the scope of MainView Middleware Monitor; it is the responsibility of your system or database administrator. To prevent users from modifying or deleting information, administrators must apply database or table security to the audit database to ensure that appropriate security levels are maintained.
  • Manage the size of audit database: Make sure to allocate enough space for the database. If the database runs out of space and the security option Abort user action on audit error is checked, the action fails.

    If the database and/or table size is a concern, you might need to establish a method for archiving the information in the audit tables.

    Audit logging uses the following database tables: AUDITENDEVENT, AUDITINTPROPS, AUDITSTARTEVENT, AUDITSTRINGPROPS, and AUDITSYS.
  • Backup audit database: Back up and archive the appropriate pieces of the audit log database on a regular basis in case of database corruption.
  • Query and review audit data: Use the audittool CLI to query audit data. See Testing-and-querying-audit-records.

Log data written to the database

The following list is part of the audit log information that is written to the database in appropriate table columns. The actual message text is not part of the audit log information.

  • Event ID: A unique numeric field that identifies an event
  • Event Type: The type of action the event describes
  • Event Status: Completed, Failed
  • User ID
  • System Time: This is the database server time for start and end of action

    The System Time column holds the server date/time. The column type is Date on Oracle, DateTime on SQL Server and Timestamp on DB2. Note that this value is expressed in the local server time (not GMT). Therefore, if you want to record this as GMT time, you must appropriately modify the DateSQL column to reflect the addition or subtraction of time as required.
  • Local User Time: The local system time for start and end of action
  • Description Text
  • Object Type
  • Object Name
  • Host: The computer where the Application Service is running.

Note

The DateSQL column of the AuditSYS table is used to determine what database function is used to return the server date/time. Isolating this information in a database column allows for portability to other databases. The system determines this value automatically for known databases.

Loggable user actions

Actions are logged by object. The following table highlights the event type that applies to each type of object.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*