Central Management Server Audit Test

Auditing allows you to keep a record of significant events on servers and applications, which helps give you a picture of what information is being accessed, how it's being accessed and changed, and who is performing these operations.

The Central Management Server (CMS) acts as the system auditor, while each server or application that triggers an auditable event acts as an auditee. When an audited event is triggered, the auditee will generate a record and store it in a local temporary file. At regular intervals, the CMS communicates with the auditees to request these records and writes the data to a database called the Auditing Data Store (ADS).

If the CMS is not able to connect to the ADS, then audit records cannot be written to the ADS. Without audit records, custom audit reports cannot be generated. In the absence of such reports, administrators cannot audit accesses to servers/applications or detect logins that are suspect; this could pose a serious security threat.

Also, if the CMS is not able to write events to the ADS as quickly as the auditee sends records to it, the auditing load on the CMS is bound to increase, resulting in auditing delays.

By quickly detecting connection issues with ADS and processing delays with CMS and rapidly fixing them, administrators can ensure that auditing operations function without a glitch. The Central Management Server Audit test helps with this.

This test periodically checks the CMS – ADS connection and reports breaks (if any). In addition, the test monitors how quickly CMS writes event records to the ADS and highlights bottlenecks in the writing process. With the help of the actionable information the test provides, administrators can accurately identify what is ailing the auditing function and how it can be optimized.

Target of the test : A SAP BOBI Node

Agent deploying the test : An internal/remote agent

Outputs of the test : One set of results for the CMS running in the node monitored.

Configurable parameters for the test

Parameter	Description
Test period	How often should the test be executed.
Host	Host name of the server for which the test is to be configured.
Port	Enter the port to which the specified host listens. This should be the port at which the web application server hosting SAP BOBI listens.
JMX Remote Port	Specify the RMI port number of the BOBI monitoring application. To know the RMI port number of the monitoring application, refer to Enabling the Monitoring Application of the SAP BOBI Platform.
JNDI Name	Specify the lookup name for connecting to the JMX connector of the BOBI monitoring application. To know the JNDI name, refer to Enabling the Monitoring Application of the SAP BOBI Platform.
JMX User and JMX Password	Enter the credentials of an enterprise authenticated BOBI user belonging to the default monitoring users group.
Confirm Password	Confirm the password by retyping it here.
Node Name	Specify the name of the BOBI node being monitored.
Detailed Diagnosis	To make diagnosis more efficient and accurate, the eG Enterprise embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option. The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled: The eG manager license should allow the detailed diagnosis capability Both the normal and abnormal frequencies configured for the detailed diagnosis measures should not be 0.

Measurements made by the test

Measurement	Description	Measurement Unit	Interpretation
Connection to auditing database is established ?	Indicates whether/not the CMS has a healthy connection to the ADS.		The values that this measure can report and their corresponding numeric values are discussed in the table below: Measure Value Numeric Value No 0 Yes 1 If this measure reports the value No, then use the detailed diagnosis of this measure to know the time that has elapsed since the last time the CMS wrote audit records in the ADS. This will enable administrators to figure out how long the ADS has remained inaccessible to the CMS. The connection name and user name will also be displayed as part of the detailed diagnostics. Note: By default, this measure reports the Measure Values listed in the table above to indicate whether/not the CMS is able to connect to the ADS. In the graph of this measure however, the same is represented using the numeric values only.
Auditing thread utilization	Indicates the percentage of the polling cycle during which the CMS is collecting data from auditees.	Percent	If this value approaches 100%, it implies that the CMS is still receiving events as the next polling cycle is due to start. This will cause many events to remain pending on the CMS, resulting in significant delays in writing events to the ADS.  To fix this, you may want to consider configuring the ADS to receive data at a higher rate or decreasing the number of auditing events.
Is auditor?	Indicates whether/not the CMS is the auditor.		The values that this measure can report and their corresponding numeric values are discussed in the table below: Measure Value Numeric Value No 0 Yes 1 Note: By default, this measure reports the Measure Values listed in the table above to indicate whether/not the CMS is the auditor. In the graph of this measure however, the same is represented using the numeric values only.
Time consumed for auditing	Indicates the time taken by the CMS to perform auditing.	Mins	Polling cycle for healthy systems should be less than 20 minutes. Cycles more than 120 minutes indicate a very busy system and this needs to be fixed by setting the auditing DB to receive events at a higher data rate or decreasing the number of events being audited.
Current number of auditing events queue	Reports the number of auditing events that an Auditee has recorded, but which have not yet been retrieved by the CMS Auditor.	Number	If this number increases without bound, it could mean indicate that auditing has not been configured properly or that the system is heavily loaded and generating auditing events faster than the auditor can retrieve them.  When stopping servers, it is advisable to disable them first and wait for auditing events to be fully retrieved and this queue becomes empty. Otherwise, they may be retrieved only when this server has been restarted and the CMS polls for them. Critical events may be missed out as a result.