SAP Instance - Built-in Checks

ASCS_MSGSRV checks if the ABAP message server of an SAP System is up and running. This can either be a stand-alone Abap_Scs instance or a message server of a classical Central. The Avantra Agent automatically determines if a message server is running on a classical Central instance, or if an Abap_Scs instance is present.

The Avantra Agent determines as well if the message server has been configured to use the HTTP protocol. If yes, the message server will be connected using HTTP and a status query is made. If the message server is not configured to use the HTTP protocol, the Check will connect the message server with TCP/IP on port sapms<SID> (which usually resolves to 36<sysnr>).

This Check monitors the FrontendResponseTime value of your SAP dialog instances. You may use monitoring parameters to include other response times as well.

This Check verifies the current usage of the kernel dispatcher queues. The current values are compared with the maximum number of entries of the queue, on the one hand, and the number of available work processes for the queue, on the other.

This Check connects an Enqueue Replication Server and verifies if the self-reported status is OK.

If the connection fails or times out, the check status turns to Warning. After ERSConnectErrsCrit connection attempts, the Check Result turns to Critical. The default of ERSConnectErrsCrit is 1.

Returns the overall status of all Checks executed during the Daily Check on a particular SAP Instance or Database.

For instance, if the connection attempt (to the SAP Instance or Database) failed, this check type returns a Critical message. If this check fails, all other dependent checks will have status Unknown.

In Ok status, the check explains which checks have been executed on the particular SAP Instance or Database, which profiles have been collected, etc.

You may want to skip the execution of Daily Checks on the weekend using Monitoring Parameter RunDailyCheckOnWE.

This Check verifies the Internet Communication Manager ( ICM ) of all SAP Instances with a Release >= 6.10. If ICM is not running, the check status turns to Critical. In addition, you can define thresholds for the current usage of created worker threads, connections, and queue entries.

See also transaction SMICM. If the Check result contains an error message, verify with this transaction first.

This Check calculates the percentage of used application threads in comparison to the maximum thread pool size.

If the number of used application threads (Visual Administrator monitoring tree: /Kernel/Application Threads Pool/ActiveThreadsCount) exceeds a percentage threshold of the maximum thread pool size (Visual Administrator monitoring tree: /Kernel/Application Threads Pool/MaximumThreadPoolSize) a Warning or Critical alert is issued.

J2EECONNECT checks the connection to the P4 port of the Java instance. This is the same connection port used by the SAP NetWeaver (formerly Visual) Administrator and is required for all JMX checks, e.g. like J2EEApplThreadsPool, JVM_MEMORY, JavaServerNodes, or the J2EE_JMX_MON Custom Check.

If the P4 connect fails or times out, the Check detects whether your Java instance has been shut down properly; if so, the check status is set to Warning with a corresponding message Instance was successfully shut down or Instance was shut down with exit code n.

After a configurable period of time (InstanceDowntimeCrit) the Warning will change to a Critical alert.

If the P4 connect fails or times out, but the instance is detected as not properly shut down, the status will be set to Warning. After J2EEConnectErrsCrit unsuccessful attempts, the check status will be set to Critical.

Since the default value of J2EEConnectErrsCrit is 1, the status is by default set to Critical after the first unsuccessful connection attempt.

J2EEConnectHttp verifies whether a system login using an HTTP connection to the SystemInfo page is possible. If the HTTP connect fails, the check result will be Warning. After J2EEConnectHttpErrsCrit successive failed connection attempts, the status will be set to Critical.

Since the default value of J2EEConnectHttpErrsCrit is 1, the status is by default set to Critical after the first unsuccessful connection attempt.

This Check calculates the percentage of used system threads in comparison to the maximum thread pool size.

If the number of used system threads (Visual Administrator monitoring tree: /Kernel/System Threads Pool/ActiveThreadsCount) exceeds a percentage threshold of the maximum thread pool size (/Kernel/System Threads Pool/MaximumThreadPoolSize) a Warning or Critical alert is issued.

Warning and Critical thresholds may be defined.

This Check reads the Average Response Time ( ART ) and the number of requests from the Java Application Response Time Measurement ( JARM ) as displayed in the Performance Tracing service of the SAP J2EE Engine Visual Administrator tool.

For kernel releases >= 7.30 the data is retrieved from the JMX monitoring tree directly.

If the ART is above the Warning or Critical thresholds, the corresponding alert will be raised. Please note that the Check by default automatically resets the JARM statistics after the data has been retrieved. The Check does therefore always show the average response time since the last executed Check (i.e. during one Basic Check Cycle). You can use the JavaASAvgRespTimeReset Monitoring Parameter to prevent the reset.

In this case, the Check displays the statistics data starting from the last reset.

AS Java reports the number of long-running threads (> 20 secs) as an MTE. Avantra Agent retrieves this value from the SAPControl web service and evaluates it in this check.

If the number of long runners is equal to or exceeds JavaLongRunningThreadsCountCrit (default 1), the check status will be Critical. If it’s below this value but higher than 0, the check status will be Warning.

If the default setting is left in place, the check will directly turn to Critical if there is any long-running thread on the cluster.

The general connection to an SAP J2EE instance is verified by the J2EECONNECT check. However, this check would not detect that a server node is not running, as long there is at least one that handles the login done by J2EECONNECT. This gap is filled by the JavaServerNodes check. It lists all nodes in a table and checks if their status is running.

If the percentage of running compared to all nodes is equal to or below JavaServerNodesRunningPctWarn (default 80 %) but still above JavaServerNodesRunningPctCrit (default 50 %), the check status will be Warning. If the percentage is equal to or below JavaServerNodesRunningPctCrit, check status is Critical. Please note that the "Disabled" nodes are not considered in the calculation.

Example: If a J2EE instance is configured with 4 nodes but 3 are running, the percentage of running nodes is 67 %, and thus check result would be Warning. If only two nodes are running, the percentage would be 50 % resulting in a Critical status.

This check type comprises two different sub-checks:

This Check calculates the ratio of memory used by the Java Virtual Machine to the available memory in percent.

If the amount of memory used (Visual Administrator monitoring tree: /Services/Memory/UsedMemory) reaches a percentage threshold of the available memory (/Services/Memory/AvailableMemory) a Warning or Critical alert is issued.

Warning and Critical thresholds may be defined.

JVM_MEMORY monitors the virtual machine memory consumption of all processes of a J2EE cluster, the Dispatcher, and any Server 0 …​ n.

The check verifies that the separation of internal and external communication with the message server is activated (defined by rdisp/msserv and rdisp/msserv_internal). Furthermore, it checks that only named servers are listed in the ACL file which controls the access to the message server over the internal port. The ACL file is defined by the parameter ms/acl_info. Please see as well SAP note 821875 "Security settings in the message server". Transaction to check the above settings in SAP is SMMS.

The following parameters are checked

The check status is Critical if any of the above rules are violated.

The SAP Instance profile files are checked for invalid (concerning the file’s syntax) or duplicate entries. For Central SAP Instances, the DEFAULT profile is checked as well.

For ABAP SAP Instances the profile files will be additionally checked for consistency with the values stored in the SAP System's database. This check is equivalent to the function Compare profile in database with active profile of transaction RZ10 and displays the same messages.

This Check verifies whether a system login using Remote Function Call (RFC) to an SAP Instance is possible.

It is the most important SAP Instance Check (ABAP). If the RFC connection attempt fails, Avantra Agent checks if the SAP System was properly shut down or is in database reconnect state; if so, it displays a Warning message.

After a configurable period of time (given by InstanceDowntimeCrit) the Warning will change to a Critical alert.

If the SAP Instance cannot be connected and the instance was not properly shut down (e.g. all SAP disp+work processes are in use) a Warning is raised.

Starting from RFCConnectErrsCrit consecutive failed connection attempts, the Warning will change to a Critical alert.

This check retrieves the certificate validity information for all valid PSEs so that a customer can be alerted before they expire and perform maintenance.

The check verifies if network-based ACLs (Access Control Lists) are active. The security of the SAP Gateway (and therefore the entire SAP system) is controlled by the files reginfo (defined by gw/reg_info) and secinfo (defined by gw/sec_info). Please see as well SAP note 1408081 "Basic settings for reg_info and sec_info".

Both files are checked individually, and the overall Check Result is the worst of both. The procedure below is written for gw/reg_info, it is the same for gw/sec_info.

First, the file found in profile parameter gw/reg_info is checked. If it does not exist, the profile parameter gw/acl_mode is checked. If gw/acl_mode is set to 0, the Check Result will be Critical with the message:

In case gw/acl_mode is set to 1, this is evaluated as OK with the message

If the reginfo file is found, it is checked as follows.

The check status is Critical if any of the above rules is violated.

This Check verifies whether a connection (using HTTP) to the Java_Scs Messaging Server is possible.

If the connect fails or times out, the Check detects whether the Java instance has been shut down properly; if so, the check status is set to Warning with a corresponding message Instance was shut down.

After a configurable period of time (InstanceDowntimeCrit) the Warning will change to a Critical alert.

If the connect fails or times out, but the instance is not detected as properly shut down, the check status turns to Warning. After SCSMsgSrvConnectErrsCrit connection attempts, the Check Result turns to Critical. The default of SCSMsgSrvConnectErrsCrit is 1.

This Check verifies whether a connection (using HTTP) to the Trex SAP Instance is possible.

The list of Checks executed depends on the configuration of the Trex Alert Server. In order to configure these checks, you have to configure the Alert Server accordingly.

This Check retrieves the SSL certificates of a Web Dispatcher instance and checks whether they are valid, i.e. not expired. If the period before a certificate expires is less than configurable thresholds WDCertDaysWarn or WDCertDaysCrit, the check result will be either Warning or Critical.

Per default, self-signed certificates are allowed, meaning that the certificateʼs trust chain is not verified against the root certificates available in the Java VM running the Avantra Agent. You can change this behavior by disabling WDCertAllowSelfSigned. WD_Certificates check will then try to build a certificate path to trusted root of the peer certificate and verifies if it is trusted. If it is not trusted, the check result will be Warning.

This Check connects a Web Dispatcher instance and verifies if the self-reported status is OK.

If the connect fails or times out, the check status turns to Warning. After WDConnectErrsCrit connection attempts, the Check Result turns to Critical. The default of WDConnectErrsCrit is 1.

This Check shows all open connections of Web Dispatcher SAP Instances and calculates the percentage of used connections in comparison to the maximum number of connections available.

If the number of used connections exceeds percentage thresholds WDConnUsageWarn or WDConnUsageCrit a Warning or Critical check status is issued.

This Check shows all queue entries of Web Dispatcher SAP Instances and calculates the percentage of queue entries in comparison to the maximum number of entries available.

If the number of used queue entries exceeds percentage thresholds WDQueueUsageWarn or WDQueueUsageCrit, a Warning or Critical check status is issued.

This Check shows all worker threads of Web Dispatcher SAP Instances and calculates the percentage of threads used in comparison to the maximum number of threads available.

If the number of used worker threads exceeds percentage thresholds WDThreadsUsageWarn or WDThreadsUsageCrit a Warning or Critical check status is issued.

This Check verifies the ABAP dialog processes in a similar way an administrator would do. It consists of two mandatory and one optional sub-check. Additionally, it will display an overview of all work processes including type.