R

The main purpose of system monitoring is to periodically check the systems' health conditions and to report critical conditions to an administrator immediately. This is what many system monitoring applications do, and so does Avantra. And since this reporting shall happen immediately, we call this kind of monitoring RealTime Monitoring.

The term Remote Monitoring is used to describe the option to manage SAP Systems, SAP Instances, and Databases hosted on an operating system that is not supported by the Avantra Agent. In this case, it is possible to manage the SAP System, SAP Instances, and Databases remotely from an Avantra Agent installed on a different host.

We also refer to remote monitoring as agentless monitoring.

Usually, Root Cause Analysis, in the context of system monitoring, means finding the most relevant event in a bunch of events, that is, to pinpoint one that causes all other issues.

In Avantra, Root Cause Analysis works somewhat differently. By hierarchical execution of Checks, the potential “Root Causes” are verified first. In case these Checks turn to Critical, all other “dependent” Checks turn to Unknown.

The different system layers

or

imply a dependency between the executed checks:

The most basic Check for a Physical Server is the so-called AGENTALIVE Check. It basically verifies if the Avantra Agent itself is operating properly. If this Check fails, the monitoring agent or even the whole server is probably down, or at least unreachable from the network. Consequently, no other Checks can be performed, the Check Results of all Checks executed by this particular agent on this host are considered Unknown (be it Server, SAP Instance, SAP System, or Database Checks).

Similarly, there is an AGENTALIVE Check for Virtual Cluster Servers. If a Virtual Cluster Server is no longer discovered on any Physical Server, no Checks can be performed for applications hosted by this Virtual Cluster Server, so their status is considered Unknown. In addition, the AGENTALIVE Check indicates at Warning level if the Virtual Cluster Server has switched from one Physical Server to another.

At the SAP Instance layer, the RFCConnect (ABAP and ABAP+Java) and the J2EECONNECT (Java) Checks play a special role: they verify if the Avantra Agent is able to connect to the SAP Instance. If these Checks fail, the SAP Instance is probably blocked or down. Consequently, no other SAP Instance-specific Checks can be performed, the results of these checks are considered Unknown. In case the RFCConnect or J2EECONNECT Check fails for an SAP Instance identified as the “central” SAP Instance, and if no other SAP Instance can play the “central” role, then no (Database-independent) SAP System Check can be performed and results of these Checks are considered Unknown.

At the Database layer, there is the DBCONNECT Check. It verifies if the Avantra Agent is able to connect to the Database. If this Check fails, no other Database (and Database-dependent SAP System) Checks can be performed. Hence the results of these Checks are considered Unknown.

The most important Check for an SAP System is the SystemAlive Check. It is a built-in Composite Check evaluating all the different connect checks for all SAP Instances comprising an SAP System, including the DBCONNECT. In other words, as long as the SystemAlive is Ok, your SAP System is operable, even if one or the other SAP Instance is down. But if it is not Ok, your SAP System is in really bad shape.

A Route describes the routing to a set of Avantra Agents and back to Avantra Master. Routes are only used when Avantra Master cannot reach Avantra Agents directly (and/or vice versa).

Technically, a Route consists of a hidden Parameter Set containing two parameters - AgentConnectRoute and MasterConnectRoute - each of which contains a sequence of URLs describing the Route in the direction from Avantra Agents to Avantra Master. The Parameter Set's System Selector specifies the Servers (Avantra Agents) to which the Route shall be applied.