Cloud Service - Custom Checks
Here you will find detailed information about Custom Checks for Cloud monitored objects.
Custom checks are chosen, adapted and deployed by you for one or more monitored objects and they are designed to allow quick and easy fulfilling of business monitoring requirements. Avantra custom checks are a mix of no-code, low-code and pro-code extensions to the Avantra AIOps platform. Each monitored object type has a number of custom check capabilities.
|
All custom checks within Avantra have a number of standard or common attributes. For more information please review our page on Custom Checks. |
RUN_JS
RUN_JS is a very powerful Custom Check type, which combines several different ways to retrieve data and evaluate the results using JavaScript. RUN_JS can easily access ready-to-use objects. For example, established RFC connections to SAP ABAP systems, established database connections, an OS object to run commands, or make HTTP requests to Cloud Services. This custom check type can be used to generate comprehensive check results, including sortable tables, that can even combine different sources of data retrieval.
|
The RUN_JS custom check is a very powerful tool. Data retrieval by RFC, SQL, OS, or HTTP is executed using the permissions you have provided for the corresponding user. You can gain access to sensitive data if RFC, database, or OS user permissions are not restricted. Use this custom check at your own risk. Avantra shall not be liable for any direct, indirect, special, incidental, or consequential damages arising from the use of this custom check. Nor can we provide any support for designing data retrieval and writing evaluation scripts. |
|
The RUN_JS custom check supports ECMAScript 2019 for Avantra Agents 20.11 and higher and ECMAScript 5.1 for older versions. Starting with Avantra 20.11.5, this custom check type depends on the global Avantra server setting Security.EnableOSCodeExec. |
The check evaluation logic is provided by a (usually small) JavaScript program. This script can access objects which are provided by the Avantra Agent, so the programmer can focus on the check logic and not worry about establishing connections, etc.
To script the evaluation logic, users of this check type need to be familiar with the built-in variables and API to use them, as described in section API Documentation below.
The RUN_JS custom check can be created for any monitored object type, however, certain built-in variables are only available in the context of the corresponding system type, i. e. an RFC connection to an ABAP system is only available in the context of SAP systems and SAP instances.
Apart from the examples provided in the API Documentation below, see also solution document RUN_JS Custom Check Examples, which contains ready-to-use examples for download.
| You need a Java Virtual Machine 1.8.0_65 or higher in order to make use of all functions of this Check. |
| Managed Object |
Dynamic Group or Static Group of Servers, SAP Instances, SAP Systems, stand-alone Databases, Cloud Services |
| Depends on | |
| Monitoring Parameter |
- Script
-
The JavaScript program providing the check data retrieval and evaluation logic. See section API Documentation.
- Script timeout
-
Define a time values, in seconds, for the timeout of the script. If no value is defined, the default cycle time is used as for the timeout.
- Return Timeout as
-
If a timeout occurs, defined how the timeout is reported. Select from
OK, WARNING, CRITICAL, UNKNOWN.blankis the default state of the dropdown as shouldn’t be used. - Report Execution Time
-
If this option is enabled, the time to run the script is appended to the check result text. This might be useful to check if the performance of a script is good.
- Execute Test Run
-
Starting with Avantra Version 21.11, you can run tests for newly created RUN_JS checks on the selected Agent directly from the Avantra WebUI. This feature does not require saving or activating the check, i.e. it can be tested before affecting the execution of the check on other systems.
To test your check code:
After modifying your script in the Script field, click the Execute test run button under the check name at the top of the dialogue box. Select one or multiple system to test the check on and click the Test button to run your script directly on those selected systems.
Although this is a testing tool, the script will execute on the systems in the same way it does in a real check execution. If the check has any side effects then these will also happen in test mode.
This feature can be disabled by the
Security.RUNJSEnableTestExecutionsetting in your Avantra Server.
SCI_MessageLogs
This custom check monitors the SAP Cloud Integration messages for all failed messages, where the statuses are either ESCALATED or FAILED.
|
With the release of Avantra 25, SCI_MessageLogs replaces the existing built-in check |
| Managed Object | |
| Depends on |
N/A |
Configuring this check requires you to define some General and Specific properties.
General Properties
The general properties are for defining the check, and how it is to be executed.
| Field | Details |
|---|---|
Custom Check Name |
Mandatory field for the name of the check |
Description |
Description of the check |
Customer |
The chosen Customer |
Execution |
Select from either daily, RealTime Monitoring, or both. Selecting RealTime Monitoring by default will execute in the Agent basic cycle time of 5 minutes. Define a time if you do not want to use the default |
Specific Properties
Specific properties defined how package(s) will be monitored. Multiple rows can be defined, allowing full customization.
| Field | Details |
|---|---|
Packages (wildcard * allowed) |
Defines the packages to be included in the current configuration row. Wildcards (*) can be used. Multiple packages can be defined in one row by using a comma-separated list with no spaces. |
Exclude packages (optional) |
An optional field to define packages that are excluded in the current configuration row. Wildcards (*) can be used. Multiple packages can be defined in one row by using a comma-separated list with no spaces. |
IDs (wildcard * allowed) |
Defines the IDs to be included in the current configuration row. To include all IDs, set to *. Multiple IDs can be defined using a comma-separated list with no spaces. Wildcards (*) can be used. |
Exclude IDs (optional) |
An optional field to define IDs that are excluded in the current configuration row. Wildcards (*) can be used. Multiple packages can be defined in one row by using a comma-separated list with no spaces. |
Threshold Window |
The number of hours or days the current configuration row that the check uses as a time threshold to apply the Warning and Critical statuses to any matching messages in the row. This field provides the value of the time threshold. For example, if the Unit field is set to hours and this field has a value of 10, the check will look at messages during the last 10 hours. |
Unit |
Can be set to hours or days, and defines the period for the threshold window. |
Warning |
Defines the threshold for the number of messages that will set this configuration row to Warning. For example if there are 60 matching records, and the Warning threshold is set to 60 and the Critical threshold is set to 80, the check message will state the row has triggered a Warning status. The overall check result will be Warning, unless another configuration row triggers a Critical status. |
Critical |
Defines a threshold for the number of messages that will set this configuration row to Critical. The overall check status will always turn to Critical if one configuration row triggers a Critical status. |
Tag |
A free text field to add a custom reference that will appear in the check output. |
The image below is an example of how to configure this check.
The image below is the results of the example.
|
For existing users of the now deprecated built-in check CPI_MessageLogs, setting the SCI_MessageLogs check to have the following Specific properties in a single row will produce the same behavior.
The image below shows these settings. 
|
S4PubSecurityUsers
This custom check alerts on report of business users that have specific Business Catalogs in their role, and/or specific Business Roles assigned.
If no configuration is done for this check, a tabled of all fields on all users is returned.
| {_managed*object} |
S/4HANA Cloud Public Edition |
| Depends on |
N/A |
Security Users selection parameters
-
In the Include User IDs field, define users with certain Business User IDs to include in the monitoring. Separate types by comma, and wildcards
*are allowed. -
In the Exclude User IDs field, define users with certain Business User IDs to exclude in the monitoring. Separate types by comma, and wildcards
*are allowed. -
In the Include Emails field, define users with certain email addresses to include in the monitoring. Separate types by comma, and wildcards
*are allowed. -
In the Exclude Emails field, define users with certain email addresses to exclude in the monitoring. Separate types by comma, and wildcards
*are allowed.You can filter either by Business Roles or by Catalogs.
-
The Filter by Roles radio button, when selected, enables filtering by Business Role.
-
In the Include Roles field, define users with certain Business Roles to include in the monitoring. Separate types by comma, and wildcards
*are allowed. -
In the Exclude Roles field, define define users with certain Business Roles to exclude in the monitoring. Separate types by comma, and wildcards
*are allowed.
-
-
The Filter by Catalogs radio button, when selected, enables filtering by catalog.
-
In the Include Catalogs field, define users with a role that contains a certain Catalog to include in the monitoring. Separate types by comma, and wildcards
*are allowed. -
In the Exclude Catalogs field, define define users with a role that contains a certain Catalog to exclude in the monitoring. Separate types by comma, and wildcards
*are allowed.
-
-
For the Modified fields, select from the dropdown the option to select users within the last or NOT within the last defined amount of time. Define the time in the second field in the format
hh:mm. -
The Lock Status dropdown is optional, and can be set to either include All, Locked or Unlocked users in the results.
-
The Validity dropdown is optional, and can be set to either include All, Valid or Invalid users in the results.
Security Users check parameters
-
The Threshold Logic dropdown defines how the Warning and Critical thresholds will evaluate the results and determine a check status. Define by less than or equal to (
⇐) or greater than or equal to (>=). -
The Critical and Warning fields are number fields. Define the number that will be used to define the Warning and Critical thresholds. This value is dependent on the option selected for the Threshold Logic.