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.
Agentless monitoring or Remote Monitoring in Avantra is a powerful way to monitor and manage objects within your landscape where you are unable to install an Avantra Agent on the host in question. This is particularly useful for scenarios such as "Rise with SAP" or "HEC" implementations where the customer (and/or service provider) retain responsibility only for the application layer (client 000 and above). Avantra supports Agentless monitoring for:
SAP Systems and Instances
Agentless Monitoring means another agent located close enough from a network perspective will take over the management of the object and will access the monitored components over the network only. The only prerequisite is the Avantra Agent performing Agentless Monitoring is allowed to connect to the SAP Instances and Databases. Please make sure no firewalls on either host or network level are preventing this access.
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
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, 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.
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 Server. The Parameter Set's System Selector specifies the Servers (Avantra Agents) to which the Route shall be applied.