The main purpose of system monitoring is to periodically check your 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 System, SAP Instances, and Databases hosted on an operating system that is not supported by the Avantra Agent. In this case it is possibly to manage the SAP System, SAP Instances, and Databases remotely from a 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 to find the most relevant in a bunch of events, i.e. to pinpoint the one that causes all the other issues.
In Avantra Root Cause Analysis works somewhat different. 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
Physical Server (→ Virtual Cluster Server) → SAP Instance → SAP System
Physical Server (→ Virtual Cluster Server) → Database (→ SAP System)
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 there are the RFCConnect (ABAP and ABAP+Java) and the J2EECONNECT (Java) Checks playing 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 a SAP Instance identified as “central” SAP Instance, and if no other SAP Instance can play the “central” role, no (Database-independent) SAP System Check can be performed, the 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 a SAP System is the SystemAlive. It is a built-in Composite Check evaluating all the different connect checks for all the SAP Instances comprising a 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 real bad shape.
Technically a Route consists of a hidden Parameter Set containing the two parameters AgentConnectRoute and MasterConnectRoute, each of which contains a sequence of URLs describing the Route in direction of the Avantra Agents respectively the Avantra Master. The Parameter Set's System Selector specifies the Servers (Avantra Agents) which the Route shall be applied to.