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 TrueSight Middleware and Transaction 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 TrueSight Middleware and Transaction 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.

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. TrueSight Middleware and Transaction 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 TrueSight Middleware and Transaction 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.

Object Type

Event Type (Action)

Agent

Reconfirm

Discovery

Register

Unregister

Authinfo

Create

Delete

Change Attributes

Set Authorities

Display Authorities

Channel Initiator

Channels

Create

Delete

Change Attributes

Reset

Ping

Resolve

Start Listener

Set Authorities

Display Authorities

Import/export

Various

Listeners

Create

Delete

Change Attributes

Set Authorities

Display Authorities

Namelists

Create

Delete

Change Attributes

Set Authorities

Display Authorities

Processes

Create

Delete

Change Attributes

Set Authorities

Display Authorities

Queue Manager

Start Command Server

Start Channel Initiators

Start Channel Listener

Display Authorities

Set Authorities

Create

Delete

Change Attributes

Discovery

Queues

Create

Delete

Change Attributes

Set Authorities

Display Authorities

Services

Create

Delete

Change Attributes

Set Authorities

Display Authorities

Subscriptions

Create

Delete

Change Attributes

Topics

Create

Delete

Change Attributes

Set Authorities

Display Authorities

Publishing Message

Trigger Monitor

Any object on which a policy action may apply

Associate-Event-Template

Dissociate-Event-Template

Associate-History-Template

Dissociate-History-Template

Policy-Conflict

Schedule-Discovery

Suppress-Events

Create-Admin-WMQ-Connection

Modify-Dashboard

Distribute Packages

Run-Script

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

Comments