C
(SAP) CCMS Integration
Avantra can interface with the SAP CCMS (Computing Center Management System) and include CCMS Monitoring Tree Elements as RealTime Monitoring Checks.
The definition can even be on the “CCMS Monitor” level, integrating all the “Monitoring Tree Elements” below as single Checks.
CCMS Alerts will be acknowledged automatically in the SAP System (optional) once they are imported into Avantra. You can verify them using Avantra UI, forward them using Notifications, and delete them afterwards. In addition, “CCMS Monitoring Tree Elements” can be read and configured centrally. Integration and configuration are implemented by means of Custom Checks.
Change Management
Avantra provides a built-in Change Management solution allowing Customers to request changes on their Systems. Many of the System changes are recorded automatically using System Change Auto Detection.
Check
Monitoring in Avantra is performed by execution of the so-called Checks performed by Avantra Agent and Avantra Server.
The list of executed Checks varies depending on the System Type:
- Physical Server
-
For a Physical Server, it is basically verified if the server is available, and the most important operating system conditions are checked.
All Checks for a Physical Server are executed by Avantra Agent installed on the Physical Server itself.
- Virtual Cluster Server
-
For a Virtual Cluster Server, the main focus is to detect cluster switches. This Check is performed on all Physical Servers that may run the Virtual Cluster Server.
- SAP Instance
-
For an SAP Instance there are different types of connection checks depending on the instance type, and also some checks for the health conditions of the application server, first of all in the Java area.
All Checks for an SAP Instance are executed by Avantra Agent installed on the Physical Server hosting the SAP Instance, either directly or via a Virtual Cluster Server.
- SAP System
-
For an SAP System, there are basically three groups of checks:
-
Verification of the health status of the Database instance, like different space consumption checks for the Database itself and the transaction logs and backup checks. The Database-dependent SAP System checks are executed on the host running the Database instance.
From a monitoring perspective, the Database Checks of a Database instance are considered SAP System Checks. -
Database-independent health conditions, like the status of the updater, output request errors, short dumps, aborted jobs, etc. All Database-independent SAP System Checks are executed on the host running the SAP Instance identified as “central”, i.e. the Central or Central+Java SAP Instance, or one chosen by Avantra (for Java-only systems or ASCS installations).
-
Specific Checks for certain types of SAP applications, like SAP BW/BI, SAP XI/PI.
-
- Stand-alone Database
-
For stand-alone Databases, the same Checks are executed as for Database instances of an SAP System.
Every check provides a Check Result under consideration of the results of the Root Cause Analysis.
Checks are executed in different Check Cycles, and the list of checks executed depends on the System Type. The Check Cycles are:
Basic |
The Basic Check Cycle is scheduled by Avantra Agent every 5 minutes (by default). During the Basic Check Cycle all Checks for Physical Servers, Virtual Cluster Servers, SAP Instances, and Databases are executed. Checks executed in the Basic Check Cycle are part of the RealTime Monitoring. |
Medium |
The Medium Check Cycle is scheduled by Avantra Agent every 10 minutes (by default). During the Medium Check Cycle, all checks for SAP PI/XI are executed. Checks executed in the Medium Check Cycle are part of the RealTime Monitoring. |
Full, Daily |
The Full Check Cycle (or Daily Check Cycle) is scheduled by Avantra Agent every 24 hours. As the name indicates, the Checks executed during this Check Cycle are the so-called Daily Checks. |
Avantra Checks inherently provide a Root Cause Analysis and they also make use of Trend Analysis and Forecasting.
Some Checks are executed by Avantra Server on demand. These are, first of all, the Composite Checks and the Business Services.
There is an option for {_Check Confirmation}, and history is kept for both RealTime Monitoring and Daily Checks.
Every Avantra Check belongs to one of the following categories:
Static |
Static Checks are executed on every System of a given System Type. For instance, Avantra Agent verifies the CPU usage of every Physical Server. |
Dynamic |
Dynamic Checks are only executed if a System fulfills certain conditions. For instance, Avantra Agent executes SAP BW/BI related Checks only for SAP BW/BI systems. |
Custom |
This category comprises all the Checks that are only executed if they are explicitly configured, like Custom Checks, Composite Checks, and Business Services. |
Check Result
Every single check has a particular check result after being executed. The result is composed of two parts: the check status and the check message. While the check message is some free text (and in a very few cases can even be empty), e.g. WARNING — 'xyz' is used by 35.1%, the check result in any case is one of the following:
Everything is working as expected. |
|
Either a warning threshold has been exceeded, or a system condition was met that should be followed up, but is not an error condition. In some cases, checks that cannot be performed — although they are supposed to — also report a warning result. |
|
Either a critical threshold has been exceeded, or an erroneous system condition was met. In some cases, checks that cannot be performed — although they are supposed to — also report a critical result. |
|
The check result cannot be determined. In most cases, this check result is an effect of the Root Cause Analysis. |
|
The check has been disabled intentionally, or the check is not executed on the system (within Daily Checks). |
Check Selector
A Check Selector is a logical grouping of Checks within Avantra. They define a group of Checks to be used in RealTime Monitoring, Notifications, and Business Services.
A Check Selector can group either RealTime Monitoring Checks, Daily Checks, or both. The group of Checks to select from the Check Selector can be defined by attributes as defined by you.
Is also possible to limit the selected Checks to a well-defined set of Monitored Systems using Check Selectors.
Cloud Services
Avantra provides the Cloud Service object type for integration with Software-as-a-Service (SaaS) solutions. Most SaaS solutions provide an API, and Avantra can work with them through the SAP Cloud Service object type. Knowing the solution’s API allows getting the required information, like errors, malfunctions, failures, etc., out of the product and then using it as a basis for Checks. Avantra proposes the following integration methods:
-
Generic - supports various authentication methods and enables you to integrate with any SaaS solution with disclosed API. The generic integration will be used with the RUN_JS Custom Check type and the JavaScript-based Custom Check API. There are examples available in our knowledge base at support.avantra.com.
-
Dedicated - simplifies the setup and provides out-of-the-box support for business-relevant checks. The Avantra team develops and configures all necessary Checks, so you can use them for monitoring purposes immediately without needing to go through the configuration process. However, you can always create new or tweak the existing checks as you see fit.
Avantra supports SAP Cloud Connector Integration, SAP Cloud Platform Integration, and SAP Cloud Platform Neo. Other integrations, like Ariba, SuccessFactors, Concur, etc., are planned.
Composite Check
A Composite Check is a Check that is composed of one or (usually) more other Checks. This can be either built-in Checks, Custom Checks, or other Composite Checks. Roughly speaking, a Composite Check is an evaluation rule that determines a Check Result based on the Check Results of its input Checks.
Similar to Custom Checks, Composite Checks can be defined for a Static Group or a Dynamic Group of Systems. The evaluation of the Check Result is performed by Avantra Server.
Composite Checks also record Availability Data. The SystemAlive Check is an example of a built-in Composite Check (which cannot be modified).
Custom Attributes
Avantra allows you to define Custom Attributes to fulfill your business needs. These attributes can be defined for any of the monitored object types (e.g. Server, SAP System, SAP Instance, Business Objects, Database, Cloud Service).
Additional attributes you define will become visible and can be populated in the System details dialog. They can also be used in Selectors.
Although not shown by default, you also have the option to show Custom Attributes in System lists. You can use the list configuration action to display the Custom Attributes in System lists.
Custom Attributes can also be used in Notifications Output Channels.
Custom Check
Monitoring can be extended by the so-called Custom Checks. Custom Checks are provided in order to:
-
monitor the SAP R/3 system log, your specific SAP Jobs, or certain SAP transaction run-times
-
execute your own ABAP reports as Avantra Checks
-
verify uploads to your SAP BW/BI systems
-
verify RFC destinations
-
integrate with the JMX (Java Management Extensions) monitoring tree of either the managed SAP System or any other Java Application Server
-
monitor processes or services (on Microsoft Windows operating systems) and dedicated filesystems
-
monitor file interfaces or check network response times
-
monitor Web sites, including basic authentication, form handling, certificate expiration, and response
-
deploy and run your own scripts or programs as Avantra Checks (sort of plug-ins)
-
monitor arbitrary log files and the Microsoft Windows EventLog for certain patterns
-
integrate with and configure the SAP CCMS, either a single monitoring tree element or a whole monitoring tree
-
monitor Disk I/O and Network I/O
-
verify the values of profile parameters, the status of Java components, and the active ABAP and Java users in an SAP System
Similar to the Monitoring Parameter Sets, Custom Checks can be defined for a Dynamic Group or a Static Group of Systems.
Many of the Custom Checks listed above are also capable of tracking and recording the so-called Service Availability. Custom Checks — as the name indicates — need to be manually configured.
Custom Monitoring Parameter
Custom Monitoring Parameters are an extension to Custom Checks. There may be cases where the built-in Monitoring Parameters do not provide the necessary information you want to use in a Custom Check, or where a single customizable setting would save you from duplicating Custom Check definitions.
You first have to define Custom Monitoring Parameters on an application-wide level with a System Type they are bound to, the unit, and a default value. This default setting is then known to all Avantra Agents connected. If the default value does not suit in all cases, you can change the Custom Monitoring Parameter on a per-System level or within a Parameter Set – like a normal Monitoring Parameter.
Custom Monitoring Parameter names have to start with the cust. prefix.
Customer Overview
Whether using Avantra as a single-tenant installation or multi-tenant, the customer setup is an important part of your Avantra installation. Avantra has been developed since the start from a Service Provider’s perspective and is at the core of all functions.
A customer makes a lot of sense for a service provider where there are literally different customers configured in the system and it is a logical separation of monitored objects, for single enterprises this can still be a very useful concept especially if you are dealing with different business units or entities that require logical separation.
Customers “own” the Systems contained within them. In other words, Systems are grouped by Customers within Avantra, where by default no representative of Customer A has the permission to access any data of Customer B. Similarly, other Managed Objects are “owned” by Customers.
Customers may be arranged hierarchically in order to allow inheritance of Permissions. On top of this hierarchy, there is a so-called root customer which cannot be modified and cannot own Systems, but which can be used to assign Permissions to. In other words, users who have permissions on a top customer get the same permissions also on all contained sub-customers. For example, this can be very useful for international organizations, where systems are grouped into different geographical locations.