SAP System - Monitoring Parameters

Indexes defined in this parameter are excluded from the "indexes missing" and "unknown indexes" part of the ABAP_DD_DB check. Please note that this parameter can only be used for indexes, but not for tables. Indexes listed must be separated by one or more spaces.

If the tables required for the DB2_CBO_STATS check cannot be found in the default schema you may define the appropriate schema in here.

If there are problems with the default ABAP class used to generate JSON in an SAP system, a compatibility mode can be chosen.

AutoChangeDetectionIgnore is used to exclude parameters from System Change Auto Detection. If, for example, a parameter value changes regularly and this behavior is well-known, you may add the parameter to the exclude list. The parameter value is still updated in the Avantra Database, but no change record will be created. Since there are several change detection objects, you must prefix the list with a keyword to indicate the object type.

For SAP Systems, only DBPARAM is currently supported. Wildcard * is supported to define multiple parameters, e.g. DBPARAM: *MEMORY*, CPU_COUNT

This parameter specifies clients which are excluded from all checks provided by BATCH_INPUT.

This parameter specifies the maximum age of batch input sessions. If there are records older than BatchInputMaxAge found, BATCH_INPUT will result as Warning. You can turn this part of BATCH_INPUT off if you change the parameter to 0.

This parameter specifies the maximum run time of batch input sessions. If there are running sessions older than BatchInputMaxRunTime found, BATCH_INPUT will result as Warning.

This parameter defines batch input sessions by Queue-ID which are excluded from all sub-Checks of the BATCH_INPUT Check. The list of Queue-IDs may be separated by blanks or commas. Wildcards are not supported.

Works together with BcsOutboundClientMode, either to specify clients to be excluded (BcsOutboundClientMode is in mode deny (Blacklist)) or limited to only clients listed (BcsOutboundClientMode is in mode allow (Whitelist)). Please be aware that if you change parameter BcsOutboundClientMode, you can also change this parameter to another list, since the default value 000 066 is intended to work in deny mode.

All Business Communication Services checks are designed to retrieve data of all clients found in an SAP system, no matter which client is used for RFC by the Avantra Agent. To exclude clients from being checked, you may use BcsOutboundClientList in either deny (Blacklist) or allow (Whitelist) mode. The default value is deny, i.e. all clients will be checked except clients 000 and 066. If you want to, for instance, only check on specific clients, you may change this mode to allow and specify the clients to be checked using parameter BcsOutboundClientList.

If the number of erroneous outbound business communication records since the last Daily Check start is equal to or above the defined value, the check status is set to Critical.

If the number of erroneous outbound business communication records since the last Daily Check start is equal to or above BcsOutboundErrorsNumWarn but below BcsOutboundErrorsNumCrit, the check status is set to Warning.

If the number of erroneous outbound business communication records in the last BcsOutboundErrStatTimeSpan minutes is equal to or above the defined value, the check status is set to Critical.

If the number of erroneous outbound business communication records in last BcsOutboundErrStatTimeSpan minutes is equal to or above BcsOutboundErrStatNumWarn but below BcsOutboundErrStatNumCrit, the check status is set to Warning.

If the date/time of an erroneous business communication record is after now minus BcsOutboundErrStatTimeSpan minutes, the record will be counted, otherwise, it is no longer retrieved.

If you want to use different wait times thresholds for certain outbound waiting records, you may use this parameter which follows the syntax:

<list of clients> or * for all | <list of send methods> or * for all | warning threshold in minutes | critical threshold in minutes`

Multiple clients and send methods of an exception are separated by comma (,). Please use the short name of the send method. Multiple exceptions are separated by semicolon (;). Spaces may exist at any place of the parameter string, since they will be ignored.

There is also a special value 0 for the warning and critical thresholds. 0 means that the corresponding threshold will not be verified. So if you set both to 0, you can exclude records completely from being verified. They are, however, still displayed in the result table.

If the number of waiting business communication records in an SAP client is above BcsOutboundWaitNumCrit and the wait time is above BcsOutboundWaitTimeCrit, the check result status of BCS_OutboundWaitStat will be Critical.

If the number of waiting business communication records in an SAP client is above BcsOutboundWaitNumWarn and the wait time is above BcsOutboundWaitTimeWarn, the check result status of BCS_OutboundWaitStat will be Warning, as long as the number and time are still below the Critical thresholds.

See description of BcsOutboundWaitNumCrit.

See description of BcsOutboundWaitNumWarn.

This monitoring parameter sets the number of days from today to check for BDoc message monitor errors. If zero (0), then it will be all of today, i.e., today - zero = today.

This parameter specifies the filter for including/excluding BDoc types. The format is comma-separated without spaces, i.e., OBJCL_MESSAGE,VEND_MAIN,BU*, etc.

This monitoring parameter configures the warning threshold for CRM_BDOC_MONITOR check based on the number of records returned.

This monitoring parameter configures the critical threshold for CRM_BDOC_MONITOR check based on the number of records returned.

Define the status that should be reported if one of the process chains is cancelled.

Process chains defined in this parameter are not considered for the check status.

If one of the process chains exceeds the runtime threshold defined, the check status turns to Critical.

If one of the process chains exceeds the runtime threshold defined, but none exceeds the threshold defined in BWProcessChainsRTCrit and none terminates with errors, the check status turns to Warning.

If a query within an SAP BW/BI System runs longer than the time defined in this parameter, the check turns to Critical.

Queries added to this list are not considered for the check result.

If a query within an SAP BW/BI System runs longer than the time defined in this parameter, but not longer than BWQueryRuntimeCrit, the check turns to Warning.

A CCMS monitor tree of a CCMS_MONSET Custom Check may contain a lot of MTEs, which results in many checks being created in Avantra’s RealTime Monitoring. If you want to limit this number of checks, you can set the CCMSMonsetMTEMaxCount parameter. When MTEs are CCMS Monitor tree is read, and the number of CCMSMonsetMTEMaxCount is exceeded, the remaining MTEs are ignored and the corresponding CCMS_MONSET Custom Check will report a Warning result.

Per default, this parameter is 0, i.e. it is inactive and the number of MTEs is unlimited.

This monitoring parameter activates/deactivates the call of cleanipc command during the restart of an SAP System. The settings for this monitoring parameter will be the same for all the instances of this SAP System.

If any component version shows 0 instead of the correct version using the function DELIVERY_GET_INSTALLED_COMPS, it is recommended to use the function OCS_GET_INSTALLED_COMPS.

If during a reported day period the number of dialog steps is less than the defined value, the runtime of the steps is not considered for the Check Result of the DIALOGPERF and WORKLOAD Checks.

Roughly speaking, if you have less than 1000 dialog steps from — let’s say — 6h to 7h, it won’t hurt if 20% of them run longer than a second. Obviously, this is different for 10000 dialog steps.

The check turns Critical if less than DialogPerfPctCumulatedCrit percent of the dialog steps finish within DialogPerfRespTimeLimit, except if only less than DialogPerfMinStepCount are performed.

The check turns to Warning if more than DialogPerfPctCumulatedCrit percent but less than DialogPerfPctCumulatedWarn percent of the dialog steps finish within DialogPerfRespTimeLimit except if only less than DialogPerfMinStepCount are performed.

Defined the runtime threshold. Valid parameters are: 0.1, 0.2, 0.3, 0.4, 0.5, 1, 2, 3, 10

Defines the time period the check should consider. Valid values are within the range 00-24, like e.g. 06-18.

If the SAP Systems average dialog response time exceeds DialogRespTimeCrit ms, the check status is set to Critical.

If the SAP Systems average dialog response time exceeds DialogRespTimeWarn ms, but does not exceed DialogRespTimeCrit ms, the check status is set to Warning.

By default, the DialogResponseTimes check only monitors FrontendResponseTime.

Other typical response times are: ResponseTimeDialog, ResponseTimeDialogRFC, ResponseTimeHTTP.

If there are IDOCs older than IdocsAgeWarn days, the check result is set to Warning.

If the number of IDOCS in group "red" exceeds IdocsGrpRedCountCrit during IdocsGrpRedTimeSpan minutes, the check result is set to Critical.

If the number of IDOCS in group "red" exceeds IdocsGrpRedCountWarn during IdocsGrpRedTimeSpan minutes, but does not exceed IdocsGrpRedCountCrit, the check result is set to Warning.

If the number of IDOCS in group "red" exceeds IdocsGrpRedDailyCountCrit in the daily check, the result of IDOCS check is set to Critical.

If the number of IDOCS in group "red" exceeds IdocsGrpRedDailyCountWarn in the daily check, but does not exceed IdocsGrpRedDailyCountCrit, the result of IDOCScheck is set to Warning.

See the description of parameters IdocsGrpRedCountCrit and IdocsGrpRedCountCrit

If the tables required to retrieve the J2EE Software Components cannot be found in the default schema you may define the appropriate schema in here.

Defines the time the span jobs are checked by the JavaJobStat check.

Defines the time the span jobs are checked by the JavaJobs check.

If the number of aborted jobs exceeds JobAbortCountCrit during the last JobAbortTimespan minutes, the check result is set to Critical.

If the number of aborted jobs exceeds JobAbortCountWarn during the last JobAbortTimespan minutes, but does not exceed JobAbortCountCrit, the check result is set to Warning

Defines job names excluded from aborted jobs monitoring. Separate multiple entries by spaces (wildcard * allowed). If your job name includes spaces, put double quotes (") around it.

Defines job users excluded from aborted jobs or delayed jobs monitoring. Separate multiple entries by spaces (wildcard * allowed). If your job user includes spaces, put double quotes (") around it.

See the description of parameters JobAbortCountCrit and JobAbortCountWarn

If JobDelayedCountCrit jobs are delayed for more than JobDelayedTimeCrit minutes, the check status is set to Critical.

If JobDelayedCountWarn jobs are delayed for more than JobDelayedTimeWarn minutes, but jobs are still below JobDelayedCountCrit/JobDelayedTimeCrit criteria, the check status is set to Warning.

Defines job names excluded from job delay monitoring. Separate multiple entries by spaces (wildcard \* allowed). If your job name includes spaces, put double quotes (") around it.

If set (which is the default), jobs with configured and expired No start after date/time are considered as delayed jobs as well. You can exclude expired jobs from delay monitoring by disabling this parameter.

For the monitoring of aborted and delayed jobs, only this number of jobs are considered.

See description of JobDelayedCountCrit above.

See description of JobDelayedCountWarn above.

If the number of aborted jobs reported in a daily check exceeds this value, the daily check result is set to Critical.

If the number of aborted jobs reported in a daily check exceeds this value but does not exceed JobsDailyCountCrit, the daily check result is set to Warning.

This parameter configures the local SAP Kernel Backup directory where existing kernel packages are backed up.

This parameter configures the target directory for kernel packages on the SAP server.

If you set this parameter Avantra will stop monitoring the System.

This setting can be used if you want to monitor this System only using End-to-End Application Monitoring (from a different System).

If an SAP lock is older than LockAgeCrit hours, the check status is set to Critical

If an SAP lock is older than LockAgeWarn hours, but not older than LockAgeCrit hours, the check status is set to Warning

This parameter is used to exclude certain locks from the LOCKTABLE check. You can specify the locks to be excluded by client, user, table, and optionally argument. The syntax of parameter values is: client:user:table. If you want to exclude by the lock argument, use this syntax: client:user:table:argument. Wildcards * are allowed, e.g. if you specify *:*:*, all locks will be excluded and the check will always result in Ok (which is certainly not recommended). Multiple lock exclude specs are separated by one or more spaces.

If you, for instance; want to exclude all locks of user BGRFCSUPER on all tables starting with BGRFC, and additionally all locks on WSRM_EH* tables, no matter which user but only in client 000, your LockExclude specification would look like:

If you want to exclude all locks containing ESH in lock arguments, your LockExclude specification would look like:

Colons : and spaces must be escaped by \ (backslash) if used as values.

This monitoring parameter masks user emails and full names from the BCS_OutboundErrors, BCS_OutboundErrStat, and BCS_OutboundWaitStat checks so that check results are anonymized.

If the number range’s exhaustion exceeds NumRangesUsageWarn percent, but does not exceed NumRangesUsageCrit percent, the check status turns to Warning.

If the NumberRanges exhaustion exceeds NumRangesUsageCrit percent, the check status turns to Critical.

To exclude clients from being checked, you may use NumRangesClientList in either deny (Blacklist) (default) or allow (Whitelist) mode. If you want to exclude specific clients, change this mode to deny and specify the clients to be excluded using parameter NumRangesClientList. If you want to check on specific clients only, change this mode to allow and specify the clients to be checked using parameter NumRangesClientList.

Works together with NumRangesClientMode either to specify clients to be excluded or to specify clients to include.

You may exclude some Number Ranges from monitoring with this monitoring parameter. The syntax of an exclude specification is:<Object>:<Subobject>:<Number>. Please make sure to not use any spaces between the separation char : since spaces or semicolon ; are used to separate multiple entries. You can use wildcard * in an exclude specification.

To exclude all Number Ranges you can use *. This makes sense if you would want to use the individual thresholds only as defined in SAP transaction SNUM. See NumRangesUseObjectDef for further information.

Examples:

You may include some Number Ranges from monitoring with this monitoring parameter. The syntax of an include specification is:<Object>:<Subobject>:<Number>. It is exactly the same syntax as described in NumRangesExclude parameter. Please note that NumRangesInclude precedes before NumRangesExclude.

The default warning and critical thresholds for Number Ranges can be set with NumRangesUsageWarn and NumRangesUsageCrit monitoring parameters. If you need different threshold values for your Number Ranges, then use NumRangesUsageEx to define individual thresholds. The syntax is as follows:

<Client>:<Object>:<Subobject>:<Number>:warn:crit

Please make sure to not use any spaces between the separation char : since spaces or semicolon ; are used to separate multiple entries. You can use wildcard *. Please note that all 6 values must be set for a valid usage specification.

Examples:

Each SAP Number Range may define a specific threshold. Those thresholds can have a different value. Avantra does not use those thresholds by default. Avantra uses the monitoring parameters NumRangesUsageWarn and NumRangesUsageCrit to define thresholds. If you want to use the threshold defined for the Number Range in your SAP System, use this monitoring parameter. Since the SAP System only provides one threshold, you need to specify if the check status is set to Critical or Warning when the threshold exceeds. The syntax is: <Object>:<CRITICAL|WARNING>. Multiple specifications are separated by a space or semicolon. You can use wildcard * in a specification.

SAP Number Ranges can be rolling or not. NumberRanges selects by default both rolling and non-rolling Number Ranges. If you want to select only non-rolling Number Ranges, then deselect this option.

This parameter does exactly the same as SAP Instances, except that it will control the Performance Data Collection of the SAP system, i.e. the total values of the configured ABAP task types.

Controls whether or not Performance Data Collection is turned on for Systems. If you do not want the Avantra Agent to collect performance data you may remove the flag.

Transactions with a percentage of the total number of transaction steps below threshold PerfDataTARuntimeStepsMinPct will not be listed in section Top N transaction response times sorted by average response time of the Service Level Report. This is to ignore transactions with a very low number of steps which often have a high response time and thus makes the service level report more significant.

Defines the number of transactions to be listed in the section Top N transaction response times sorted by average response time of the service level report.

Defines the number of transactions to be listed in the section Top N transaction response times sorted by number of steps of the service level report.

Set this monitoring parameter to include reports in Top N performance chart. If this monitoring parameter is not set, only transactions are included in Top N performance chart.

Defines the SAP transactions of which you want to explicitly collect performance data. The response times of these transactions will be reported in the service level report in section Monthly average response times of named transactions.

Defines the time ranges in days and hours for which performance data of SAP transactions defined in PerfDataTransactions is effectively collected. If this parameter is not set, performance data is collected 7 days a week and 24 hours per day. If, for instance, you want to collect transaction performance data only from Monday to Friday and from 08:00 to 17:00, then set this value to: 1-5:8-17

The first part defines the day range, where 1 is Monday and 7 is Sunday. The second part defines the hours within a day.

You can define multiple ranges by separating them with a comma. Following patterns selects transaction performance data from Monday to Thursday from 08:00 to 17:00 and Friday from 08:00 to 16:00 only: 1-4:8-17,5:8-16

If the number of erroneous PI Adapter Engine XML messages since the last Daily Check start is equal to or above this value, the check status is set to Critical.

If the number of erroneous PI Adapter Engine XML messages since the last Daily Check start is equal to or above PIAEMessagesNumWarn but below PIAEMessagesNumCrit, the check status is set to Warning.

If the number of erroneous PI Adapter Engine XML messages in last PIAEMessagesStatTimeSpan minutes is equal to or above this value, the check status is set to Critical.

If the number of erroneous PI Adapter Engine XML messages in last PIAEMessagesStatTimeSpan minutes is equal to or above PIAEMessagesStatNumWarn but below PIAEMessagesStatNumCrit, the check status is set to Warning.

If the date/time of an erroneous PI Adapter Engine XML message is after now minus PIAEMessagesStatTimeSpan minutes, the message will be counted, otherwise, it is no longer retrieved.

If your PI J2EE instance is configured to use https only, usually due to security reasons, please use this parameter to indicate that the Agent shall use https to get the PI Adapter engine data.

Defines the amount of channels that must have a failure state at the same time to turn the check state of the entire PI_CommChannels check to Critical. Channels are checked every Medium Check Cycle, i.e. per default every 10 minutes.

Defines the amount of channels that must have a failure state at the same time to turn the check state of the entire PI_CommChannels check to Warning. When PICommChannelsCountCrit is smaller or equal, this parameter won’t have any effect. Channels are checked every Medium Check Cycle, i.e. per default every 10 minutes.

Defines the number of subsequent ERROR channel states, before the check state of a channel is Critical. Channels are checked every Medium Check Cycle, i.e. per default every 10 minutes.

Defines the number of subsequent ERROR channel states, before the check state of a channel is Warning. However, if the number of subsequent ERROR channel states is equal to or above PICommChannelsErrsCrit, this parameter has no effect. Channels are checked every Medium Check Cycle, i.e. per default every 10 minutes.

Defines the number of minutes before the check state of a channel is reported as Critical. Please consider that channels are checked every Medium Check Cycle, i.e. per default every 15 minutes, so the reporting might be delayed additionally by the Medium Check Cycle interval.

Defines the number of minutes before the check state of a channel is reported as Warning. Please consider that channels are checked every Medium Check Cycle cycle, i.e. per default every 10 minutes, so the reporting might be delayed additionally by the Medium Check Cycle interval.

If the setting is equal to or above PICommChannelsTimeCrit, this parameter has no effect.

If a channel matches at least one criteria of the list of exclude criteria provided, it will be excluded from the check evaluation. The syntax of an excluded criterion is:

Exclude term: party|service|channel|activationState|channelState=<pattern>. A pattern may contain placeholders * (for any number of any characters) and/or ? (for a single character).

An exclude criteria consists of at least one or multiple exclude terms separated by a comma and surrounded by {}: {`Exclude specification(,Exclude specification)*}`. All exclude terms must match, i.e. the exclude terms are combined by logical AND.

Multiple criteria can be concatenated either by comma (,) or semicolon (;). A channel is excluded if it matches any of the listed criteria, i.e. the criteria are combined by logical OR.

Under certain circumstances, PI checks might report features with status not OK which results in Critical status of the whole check. You can exclude a certain feature from contributing to the check status. To do this, simply put the name of the feature on the comma-separated list provided by PIExcludeSelftestFeatures.

Excluded features will still be listed in the check result table, but the not OK status is are marked in grey color and is appended by Excluded info.

You can set this Monitoring Parameter to force the Avantra Agent to detect an SAP PI system in the rare case it does not automatically.

Works together with PIIEMessagesClientMode, either to specify clients to be excluded (PIIEMessagesClientMode is in mode deny (Blacklist)) or limited to only clients listed (PIIEMessagesClientMode is in mode allow (]list)). Please be aware that if you change parameter PIIEMessagesClientMode, you can also change this parameter to another list, since the default value 000 066 is intended to work in deny mode.

PI Integration Engine XML messages checks are designed to retrieve data of all clients found in an SAP system, no matter which client is used for RFC by the Avantra Agent. To exclude clients from being checked, you may use PIIEMessagesClientList in either deny (Blacklist) or allow (Whitelist) mode. The default value is deny, i.e. all clients will be checked except client 000 and 066. If you want to, for instance, only check on specific clients, you may change this mode to allow and specify the clients to be checked using parameter PIIEMessagesClientList.

If the number of erroneous PI Integration Engine XML messages since the last Daily Check start is equal to or above this value, the check status is set to Critical.

If the number of erroneous PI Integration Engine XML messages since the last Daily Check start is equal to or above PIIEMessagesNumWarn but below PIIEMessagesNumCrit the check status is set to Warning.

If the number of erroneous PI Integration Engine XML messages in last PIIEMessagesStatTimeSpan minutes is equal to or above this value the check status is set to Critical. Please note that the threshold is applied to each client individually, see PIIEMessagesClientMode and PIIEMessagesClientList parameters.

If the number of erroneous PI Integration Engine XML messages in last PIIEMessagesStatTimeSpan minutes is equal to or above PIIEMessagesStatNumWarn but below PIIEMessagesStatNumCrit the check status is set to Warning. Please note that the threshold is applied to each client individually, see PIIEMessagesClientMode and PIIEMessagesClientList parameters.

If the date/time of an erroneous PI Integration Engine XML message is after now minus PIIEMessagesStatTimeSpan minutes, the message will be counted, otherwise, it is no longer retrieved.

Defines if or if not Ok check messages are displayed for the SAP PI checks

Use this monitoring parameter to configure the Predictive Analytics engine for the SAP System. By default the engine is configured as Balanced.

List of SAP or database profile parameters allowed to occur multiple times in a file. Parameters listed here will no longer be considered as duplicate entries in the Profiles PROFILES check.

One of Auto:HTTP:HTTPS:HTTP+HTTPS, defines which protocol/port is used to connect to the SAP host control service. AUTO uses HTTPS if available else HTTP; the others force the respective protocol/port; HTTP+HTTPS probes both, like AUTO, but reports if the other is working too.

Defines the hostname/IP address to which the host agent is configured to listen to. It can override the default (localhost/127.0.0.1) setting.

If this parameter is set to a value, the SAPHostAgentStatus check is always enabled and ignores local detection. Setting a value that is not the server’s hostname, machine name or any alias will force the check to remote mode and skip monitoring of the local daemon.

Activates/deactivates the SAPOSCOL sub-check for the SAPHostAgentStatus check. This sub-check needs additional authorisations (sapadm) to operate.

This monitoring parameter excludes the expired certificates so, if they are expired for the number of days defined by SAPLicenseIgnore or more, they are not displayed in the status of SAPLicense check.

This monitoring parameter makes the certificates where the Software Product is ‘Maintenance*’ (where * is a wildcard) to be ignored.

If one or more licenses are found, that expire in predefined by SAPLicenseCrit number of days or less, the check status is set to Critical.

If one or more licenses are found, that expire in predefined by SAPLicenseWarn number of days or less, but do not expire in set by SAPLicenseCrit number of days or less, then the check status is set to Warning.

If defined, the checks QRFC_IN and QRFC_IN_ERRQ will ignore all queues defined in QRFCInQueueExclude.

Separate multiple queues by blank space (wildcard * is allowed)

You may also restrict queues based on the client if you use the format queue₁:client₁₁,client₁₂,…​ queue₂:client₂₁,client₂₂,…​

If there are QRFCInQueueHangCrit or more hanging queues, the check status is set to Critical.

If there are QRFCInQueueHangWarn or more hanging queues, but still less than QRFCInQueueHangCrit the check status is set to Warning.

If there are queues with more than QRFCInRecQueuedCrit records, the check status is set to Critical.

If there are queues with more than QRFCInRecQueuedWarn records, there is no queue with more than QRFCInRecQueuedCrit records, the check status is set to Warning.

If defined, the checks QRFC_OUT and QRFC_OUT_ERRQ will ignore all queues defined in QRFCOutQueueExclude. Separate multiple queues by blank space (wildcard * is allowed)

You may also restrict queues based on the client if you use the format queue₁:client₁₁,client₁₂,…​ queue₂:client₂₁,client₂₂,…​

If there are QRFCOutQueueHangCrit or more hanging queues, the check status is set to Critical.

If there are QRFCOutQueueHangWarn or more hanging queues, but still less than QRFCOutQueueHangCrit the check status is set to Warning.

If there are queues with more than QRFCOutRecQueuedCrit records, the check status is set to Critical.

If there are queues with more than QRFCOutRecQueuedWarn records, there is no queue with more than QRFCOutRecQueuedCrit records, the check status is set to Warning.

Defines a list of Daily Check details that are considered relevant for the Daily Check status, i.e. the status of which contribute to the overall status. By default the parameter is not defined, i.e. all Daily Check details contribute.

If you define an empty list no Daily Check detail will contribute. In this case, the status of the Daily Check will be Unknown always.

In order to assure that the Avantra Agent does not allocate too many work processes, it checks the amount of work processes being used by the SAP System RFC user before running new RFC calls.

If more than RFCConnectorWPMaxUsed work processes are already used, the Avantra Agent stops with an error message, like Too many [3] dialog work processes in use by Avantra RFC user [AVANTRA_RFC]

If set, Daily Checks will run on Saturday and Sunday as well.

RunJSAllowDBWrite monitoring parameters can be set to ‘Enabled’ or ‘Disabled’ (default) value. It allows SQL queries defined within custom checks and workflows to change the data in the Database.

This monitoring parameter is specified as a comma-separated list of buffer and value pairs, for example CALE:95,TABL:92,*:90.

You can also specify a general threshold for all other buffers by using a wildcard value, for example *:90, that is used if the specific buffer is not included.

This monitoring parameter is specified as a comma-separated list of buffer and value pairs, for example CALE:95,TABL:92,*:90.

You can also specify a general threshold for all other buffers by using a wildcard value, for example *:90, that is used if the specific buffer is not included.

This monitoring parameter is specified as a comma-separated list of buffer and value pairs, for example CALE:95,TABL:92,*:90.

You can also specify a general threshold for all other buffers by using a wildcard value, for example *:90, that is used if the specific buffer is not included.

This monitoring parameter is specified as a comma-separated list of buffer and value pairs, for example CALE:95,TABL:92,*:90.

You can also specify a general threshold for all other buffers by using a wildcard value, for example *:90, that is used if the specific buffer is not included.

If any of the 5 valid to dates PSE files is within the specified threshold set by monitoring parameter SAPPSECertCrit, the check status is set to Critical.

If any of the 5 valid to dates PSE files is within the threshold set by monitoring parameter SAPPSECertWarn, but not lower than the SAPPSECertCrit value, the check status is set to Warning.

This parameter defines the list of SAP components that are excluded from the SAP_Notes check.

This parameter defines the list of SAP components that are included in the SAP_Notes check.

This parameter defines the list of SAP note IDs that are excluded from the SAP_Notes check.

If there are short dumps older than ShortDumpAgeWarn days, the check status of the SHORTDUMPS check is set to Warning.

If the number of short dumps exceeds ShortDumpCountCrit during ShortDumpTimeSpan minutes, the check status is set to Critical.

If the number of short dumps exceeds ShortDumpCountWarn during the last ShortDumpTimeSpan minutes, but does not exceed ShortDumpCountCrit, the check status is set to Warning.

If the number of short dumps reported within Daily Checks exceeds this value the check status is set to Critical.

If the number of short dumps reported within Daily Checks exceeds ShortDumpDailyCountWarn but does not exceed ShortDumpDailyCountCrit the check status is set to Warning.

Defines short dump Error IDs (as displayed in SAP transaction ST22) to be excluded from monitoring. Separate multiple entries by commas. Wildcard * is allowed.

See the description of parameters ShortDumpCountCrit and ShortDumpCountWarn.

The number of short dumps returned SHORTDUMPS and ShortDumpStat check are limited to this value.

List of jobs suffix separated with ';' and having the following syntax: INCLUDE:job10, job11; EXCLUDE:job01;job02 Wildcards are allowed. If the parameter is empty (default) all jobs with the prefix "/1LT/IUC_" are monitored.

Max job runtime duration before CRITICAL.

Max job runtime duration before WARNING.

List of SLT configurations separated with ';' and having the following syntax: INCLUDE:config10, config11; EXCLUDE:config01;config02 Wildcards are allowed. If the parameter is empty (default) all configuration are monitored.

List of tables separated with ';' and having the following syntax: INCLUDE:table10, table11; EXCLUDE:table01;table02 Wildcards are allowed. If the parameter is empty (default) all tables are monitored.

This monitoring parameter allows turning off the irrelevant sub checks performed by SLT_Status. The configurations are semicolon-separated, and the ignored sub checks should be comma-separated, e.g. <CONFIGURATION_NAME_1>:<SUBCHECK1>,<SUBCHECK2>;<CONFIGURATION_NAME2>:<SUBCHECK3>,<SUBCHECK4> Possible values of the sub check names are:

Wildcards (*) are supported for configuration names.

If the configuration matches this monitoring parameter, the check is disabled (status is set to DISABLED); otherwise, the check is performed and the status is WARNING if the configuration is not active with the message “Configuration <configuration name> is not active”. By default this monitoring parameter is empty (“”) meaning all configurations are checked. Also, it allows using wildcards (“*”) to match multiple configurations.

This parameter configures the jobs to be included in the SLT_IUCJobs check. Use commas to define multiple jobs, wildcards * are allowed.

If there were no SLT jobs finished within the time period specified by this parameter, the check result is set to CRITICAL.

If there were no SLT jobs finished within the time period specified by this parameter, the check result is set to WARNING.

This parameter filters SLT configuration names considered for the SLT_SrcTrgt check, which must be separated by commas.

This parameter filters SLT MTIDs (3-digit numbers) considered for the SLT_SrcTrgt check, which must be separated by commas.

With this parameter, you can set a CRITICAL threshold for the difference between the source and target line numbers. If the difference is greater than or equal to the set parameter value, the evaluation result will be CRITICAL.

With this parameter, you can set a WARNING threshold for the difference between the source and target line numbers. If the difference is greater than or equal to this parameter value, but less than the value of the SLTSrcTrgtCrit parameter, the evaluation result will be WARNING.

This parameter configures the SLT status IDs (3-digit numbers) to be included. Use commas to define multiple IDs, wildcards * are allowed.

This monitoring parameter sets warning and critical thresholds for SLT when table record counts differ for different tables. The first record of the * table can provide the default behavior, and subsequent lines provide override behavior for particular tables. The SLTSrcTrgtRecordDiff can be configured in UI with a special editor. This editor supports the wildcards for tables, and warning thresholds can be set for specific tables. The tables marked as ‘not replicated’ should not be included in the result except if a specific entry is included with “include”.

Set this parameter to filter SLT configurations considered during the SLT_Status check. The listed configuration names must be separated by a comma. If the value is empty, all configurations are retrieved.

Set this parameter to filter SLT configurations considered during the SLT_UnprocRecs check. The listed configuration names must be separated by a comma. If the value is empty, all configurations are retrieved.

With this parameter, you can define different warning and critical thresholds for the count of unprocessed records in each table as well as the warning and critical thresholds for the allowed latency for replication delay evaluation. Wildcards * are supported. Use the provided editor to set this monitoring parameter.

Set this parameter to filter SLT configuration IDs considered during the SLT_UnprocRecs check. The listed SLT configuration IDs (3-digit numbers) must be separated by a comma. When empty, all available configurations are retrieved.

With this parameter, you can override the client this check gets data from. By default it is taken from the system properties.

This setting is used as parameter JCO_CLIENT_SNC_QOP for the SAP JCo connection and configures the SNC quality of protection level setting. The default value is 3, i.e. Privacy protection.

Possible values are:

This parameter defines the path and file name of the SAP Cryptographic Library to use for SNC encryption of ABAP RFC connection, i.e. the RFCConnect check. The file must be found by the Avantra Agent locally on the Server file system and must be accessible, of course. The SAP Cryptographic Library is used by all clients with SNC communication e.g. SAP GUI, so you can find out more details on this file by checking your existing configuration.

Enabling this parameter will use SNC for the RFCConnect check. Before you enable this parameter, you need to make sure to completely configure the SNC settings, i.e. you need to configure the required SNC parameters according to your SNC setup, these are: SNCLibraryPath and SNCPartnerName. Also, setting SNCMyName is recommended.

This is a specific string containing the user name and some additional product information. The normal format is: <name type>:<external name>.

Specifies the AS ABAP’s SNC name the Avantra Agent connects to. You can find the application server’s SNC name in the profile parameter snc/identity/as.

Defines the value for the SECUDIR environment variable that is used by the RFC connection over SNC.

Do not use unless instructed by the Avantra Support.

If the number of unprocessed or erroneous output requests (older than SpoolNOkTimeOffset minutes) during the last SpoolNOkTimeSpan minutes exceeds this value, the check status is set to Critical.

If the number of unprocessed or erroneous output requests (older than SpoolNOkTimeOffset minutes) during the last SpoolNOkTimeSpan minutes exceeds this value but does not exceed SpoolNOkCountCrit, the check status is set to Warning.

If the number of unprocessed or erroneous output requests (older than SpoolNOkTimeOffset minutes) within Daily-Checks exceeds this value the check status is set to Critical.

If the number of unprocessed or erroneous output requests (older than SpoolNOkTimeOffset minutes) within Daily-Checks minutes exceeds this value but does not exceed SpoolNOkDailyCountCrit, the check status is set to Warning.

See the description of parameters SpoolNOkCountCrit, SpoolNOkCountWarn, SpoolNOkDailyCountCrit and SpoolNOkDailyCountWarn.

See the description of parameters SpoolNOkCountCritand SpoolNOkCountWarn.

If the percentage of used spool requests exceeds the SpoolNumRangeUsageCrit threshold the check status is set to Critical.

Defines if or if not the SPOOLSTAT check verifies the number range usage ratio.

If the percentage of used spool requests exceeds the SpoolNumRangeUsageWarn threshold but not the SpoolNumRangeUsageCrit threshold the check status is set to Warning.

Defines access methods excluded from monitoring. Output requests which use a device with an access method specified in this list will not contribute to the check status. This is especially useful if you want to exclude all output requests which go to front end printers. You would then set the parameter to F. Separate multiple entries by spaces (wildcard * is allowed).

Defines output devices excluded from monitoring. Output requests which go to a device specified in this list will not contribute to the check status. Separate multiple entries by spaces (wildcard \* is allowed).

Defines output devices types excluded from monitoring. Output requests which go to an output device with a device type specified in this list will not contribute to the check status. For example, you might want to use this parameter to exclude all output requests which go output devices with device type SAPWIN. Separate multiple entries by spaces (wildcard \* is allowed).

This monitoring parameter filters the spool requests retrieved from SPOOL daily check. The format is comma-separated without spaces, i.e., 1,2,3,….. The statuses are 1 (Time / Scheduled), 2 (Waiting or In Processing), 3 (Waiting), 4 (In Processing), 5 (In Processing), 6 (Problem), 7 (Printing), and 8 (<F5>).

Note: Default ( * ) refers to all statuses.

If there are spool requests older than SpoolReqAgeWarn days, the check status is set to Warning.

You can ignore spool requests which have a deletion date in the future. If the deletion date of the spool request is after the current date plus the number of days defined by SpoolReqIgnoreFutureDelDate, then the spool request is ignored and not reported in the check. The default value of 0 days ignores the deletion date. In other words, all spool requests with a deletion date also very far in the future are reported.

If there are one or more certificates found, which expire in SSLCertificatesValidityCrit days or less, the check status is set to Critical.

Expired certificates no longer contribute to the status of SSLCertificatesValidity if they are expired for SSLCertificatesValidityIgnore days or more.

If there are one or more certificates found, which expires in SSLCertificatesValidityWarn days or less, but do not expire in SSLCertificatesValidityCrit days or less, the check status is set to Warning.

Works together with SXMBMessagesClientMode, either to specify clients to be excluded (SXMBMessagesClientMode is in mode deny (Blacklist)) or limited to only clients listed (SXMBMessagesClientMode is in mode allow (Whitelist)). Please be aware that if you change parameter SXMBMessagesClientMode, you may also change this parameter to another list, since the default value 000 066 is intended to work in deny mode.

PI Integration Engine XML messages checks are designed to retrieve data of all clients found in an SAP system, no matter which client is used for RFC by the Avantra Agent. To exclude clients from being checked, you may use SXMBMessagesClientList in either deny (Blacklist) or allow (Whitelist) mode. The default value isdeny, i.e. all clients will be checked except client 000 and 066. If you want to, for instance, only check on specific clients, you may change this mode to allow and specify the clients to be checked using parameter SXMBMessagesClientList.

If the number of erroneous PI Integration Engine XML messages since the last Daily Check start is equal to or above this value the check status is set to Critical.

If the number of erroneous PI Integration Engine XML messages since the last Daily Check start is equal to or above SXMBMessagesNumWarn but below SXMBMessagesNumCrit the check status is set to Warning.

If the number of erroneous PI Integration Engine XML messages in last SXMBMessagesStatTimeSpan minutes is equal to or above this value, the check status is set to Critical. Please note that the threshold is applied to each client individually, see SXMBMessagesClientMode and SXMBMessagesClientList parameters.

If the number of erroneous PI Integration Engine XML messages in last SXMBMessagesStatTimeSpan minutes is equal to or above SXMBMessagesStatNumWarn but below SXMBMessagesStatNumCrit, the check status is set to Warning. Please note that the threshold is applied to each client individually, see SXMBMessagesClientMode and SXMBMessagesClientList parameters.

If the date/time of an erroneous PI Integration Engine XML message is after now minus SXMBMessagesStatTimeSpan minutes, the message will be counted, otherwise, it is no longer retrieved.

Defines how long a Warning SystemAlive check waits before turning to Critical if required SAP Instances are missing or no SAP Instance is available for a certain SAP System.

SAPControl is used for several operations during monitoring, like remote detection of instances for agentless SAP system monitoring, certain checks, etc. This monitoring parameter allows you to configure the connect and read timeout for those SAPControl operations.

Same as TMSImportStatReturnCodeCrit except that it configures Daily Check TMS_Imports instead of TMS_ImportStat. See also TMS_ImportStat for examples of TMSImportReturnCodeCrit usage.

Same as TMSImportStatReturnCodeWarn except that it configures Daily Check TMS_Imports instead of TMS_ImportStat. See section TMS_ImportStat for examples of TMSImportReturnCodeWarn usage.

If a transport request with return code equal to or above TMSImportStatReturnCodeCrit is found, TMS_ImportStat check status will be Critical. You can turn off Critical status completely when you set the value to off. See section TMS_ImportStat for examples of TMSImportStatReturnCodeCrit usage.

If a transport request with return code equal to or above TMSImportStatReturnCodeWarn is found, and no transport request with return code equal to or above TMSImportStatReturnCodeCrit is found, TMS_ImportStat check status will be Warning. You can turn off Warning status completely when you set the value to off. See section TMS_ImportStat for examples of TMSImportStatReturnCodeWarn usage.

If the date/time of a transport request import is after now minus TMSImportStatTimeSpan minutes, the record will be counted, otherwise, it is no longer retrieved.

If there are tRFC records older than TRFCAgeWarn days, the check result of TRFC_IN or TRFC_OUT is set to Warning.

If the number of tRFC records with status CPICERR, SYSFAIL or SYSLOAD (older than TRFCOutTimeOffset minutes) during the last TRFCOutTimeSpan minutes exceeds this value the check status is set to Critical.

If the number of tRFC records with status CPICERR, SYSFAIL or SYSLOAD (older than TRFCOutTimeOffset minutes) during the last TRFCOutTimeSpan minutes exceeds this value but does not exceed TRFCOutCountCrit the check status is set to Warning.

See the description of parameters TRFCOutCountCrit and TRFCOutCountWarn

See the description of parameters TRFCOutCountCrit and TRFCOutCountWarn

This parameter is used to exclude certain functions from the TRFCOutStat check. The list of functions may be separated by blanks or a comma. Wildcards * and ? are supported.

This parameter is used to exclude certain users from the TRFCOutStat check. The list of functions may be separated by blanks or a comma. Wildcards * and ? are supported.

If the number of update errors exceeds UpdateErrCountCrit during the lastUpdateRecErrTimeSpan minutes, the check status is set to Critical.

If the number of update errors exceeds UpdateErrCountWarn during the lastUpdateRecErrTimeSpan minutes, but does not exceed UpdateErrCountCrit, the check status is set to Warning.

If there are UpdateQueueCountCrit or more update records older than UpdateQueueAgeCrit seconds, the check status is set to Critical

If there are UpdateQueueCountWarn or more update records older than UpdateQueueAgeWarn seconds, but the number of update records older than UpdateQueueAgeCrit seconds is below UpdateQueueCountCrit the check status is set to Warning

See the description of parameter UpdateQueueAgeCrit

See the description of parameter UpdateQueueAgeWarn

See the description of parameters UpdateErrCountCrit and UpdateErrCountWarn

Use only if instructed by Avantra support

Tells USER_PWD_AUDIT to exclude the listed users from the check result evaluation. If one of the users on this list has a well-known password, it is listed in the check message but does not contribute to the check status. Anyway, USER_PWD_AUDIT checks if the users on this list are locked.

{UserPWDAuditFailedLogonSeverity} controls how users locked due to unsuccessful login attempts will be checked. If this parameter is set to _Critical a user locked due to unsuccessful login attempts will be reported as {Critical}. If UserPWDAuditFailedLogonSeverity is set to _OK (not recommended), a user locked due to unsuccessful login attempts will not contribute to the check result.

Defines whether the CCMS properties variant defined by XALVariantName will be activated automatically. If this parameter is set to 0, the Avantra properties variant is not activated automatically, so the settings may be written to an inactive variant and are not used by CCMS. If the parameter is set to 1, which is the default, XALVariantName is automatically activated and will stay active because any manual changes to the active variant using SAP transaction RZ21 will be overwritten periodically.

Defines the name of the CCMS properties variant when settings are written to CCMS using Avantra. Use SAP transaction RZ21 to get an overview of properties variants. If you change XALVariantName you need to make sure that the variant already exists and the owner of the variant is set to SYSLINK. The default variant name SYSLINK is automatically created if it does not exist.

This parameter is only applicable if your SAP database runs on a Windows operating system as a Windows service. Avantra Automation can start and stop those windows services, but Avantra does not know if dependent Windows services should be started or stopped as well. If you want to start and stop those dependent Windows services as well, then activate this with this parameter.

After Avantra starts a system (e.g SAP System, database, or server), Avantra sets the monitoring switch to on. Avantra already has some built-in logic to detect whether the system is up and running, but sometimes a system responds that it is running, but in fact it is not yet ready for production ussage. The time until the system is ready highly depends on the system internals and is unknown to Avantra. With this parameter, you can define how long Avantra should wait after starting the system until the monitoring switch is turned on.

Avantra turns the monitoring switch off before stopping a system. Use this parameter to define how long Avantra should wait after turning the monitoring switch off until Avantra stops the system.