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 Master.
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.
Check Category
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
Check Selector is a user interface element defining a group of Checks to be used in RealTime Monitoring, Notifications, and Business Services.
A Check Selector can select either RealTime Monitoring Checks, Daily Checks, or both. The group of Checks to select from the Check Selector can be defined by attributes.
Is also possible to limit the selected Checks to a well-defined set of Monitored Systems using Check Selectors.
Cloud Authentication
In case Avantra detects a Cloud Server, it needs to access the API of the corresponding cloud provider in order to provide automation options, e.g. to stop and start these Cloud Servers.
| This function is only available with the Avantra Pro Edition. |
Cloud Server
A Physical Server hosted on one of the major cloud platforms: Amazon Web Services, Microsoft Azure, and Google Cloud Platform.
The term “physical” may be misleading in this context. In Avantra, a Physical Server refers to anything that has an operating system installed and running an Avantra Agent. In the Cloud context, these are usually “instances” or “virtual machines”.
Avantra automatically detects if it is running in a Cloud Server. If so, and if Cloud Authentication is configured properly, you can start and stop Cloud Servers from the UI, within Maintenance Windows, and using Notifications.
| This function is only available with the Avantra Pro Edition. |
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
You can use Custom Attributes to add additional attributes to Systems. Those attributes are shown in lists and can be used in Selectors and 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
Avantra is developed consistently from a Service Provider’s perspective. Therefore Customers play an important role in Avantra.
Customers “own” the Systems operated by the Service Provider. 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.
Consequently, the Service Provider in terms of Avantra (at least) monitors the Systems of the Customer.
Similarly, other Managed Objects are “owned” by Customers.
In the case of large enterprises, you can think of Customers as departments or business units, or even projects.
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.