A

Activation is a part of the License request and refresh process.

As soon as you have requested and applied a license it is automatically activated. This activation step is repeated automatically every 30 days, and whenever you request additional license items. The Avantra Server contacts our activation servers at https://api.avantra.com and https://api.syslink-xandria.com, and it considers the proxy definitions in HttpProxyHost and the related settings.

The term Agentless 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 agentless monitoring as remote monitoring.

In order to make the deployment of updates for the Avantra Agent easier it contains self updating functions. Update packages can be copied to the web server included in the Avantra Master. Once you trigger the update (centrally, for one or multiple Physical Servers), the Avantra Agent will download the package from this location (transparently through any Avantra Gateways eventually used) and afterwards update itself.

One of the attributes and a standard grouping mechanism every System in Avantra has.

Default Application Types are: Generic, SAP R/3, SAP BW, Utilities, SAP CRM, SAP Workplace, SAP APO, SAP R/3 Enterprise, SAP NetWeaver

Other Application Types can de defined as well.

In Avantra SAP Instances and SAP System Databases are discovered automatically. You only need to install Avantra Agents on all Servers hosting SAP Instances and SAP System Databases, and to define the SAP Systems and Servers within the Avantra UI. All the rest is done automatically.

If a SAP Instance is no longer discovered on any Avantra Agent it is flagged with the  icon and monitoring is turned off. After RemoveFromDBDelay days the SAP Instance is removed from Avantra.

The Avantra Agent is the part of the Avantra architecture that actually performs monitoring and management tasks. You will probably have multiple Avantra Agents installed in your environment.

The Avantra Agent is supposed to run on every Physical Server hosting a System Avantra is supposed to manage. The Managed Object can be the Physical Server itself, any Virtual Cluster Server eventually hosted, a Database or a SAP Instance installed on either the Physical Server, the Virtual Cluster Server, or both.

The Avantra Agent runs as a service (on Microsoft Windows operating systems) or as a daemon (on Unix-like operating systems). Its main purposes are to

Configuration of the Avantra Agents is kept centrally in the Avantra Database and is transmitted to the Avantra Agent whenever configuration items change. Data sent to and from the Avantra Agent is encrypted using HTTPS.

The technical name of the Avantra Agent used e.g. with file names or directories, executable files, log files, and installer packages is agent.

Avantra uses the PostgreSQL (on Unix-like operating systems) and Microsoft SQL Server (on Microsoft Windows operating systems) Relational Database Management Systems (RDBMS) in order to store all data.

The Avantra Database runs on the Avantra Server (or on a separate host) and can be accessed using the Avantra UI. It is also accessed by the Avantra Master, but there is no direct connection between any Avantra Agent and the Avantra Database. Database backups can be dumped to the filesystem and thus can be picked up by an ordinary filesystem backup.

The technical name of the Avantra Database used e.g. with file names or directories, executable files, log files, and installer packages is xandriadb.

The stand-alone Avantra Gateway component acting as a gateway between the Avantra Server and the Avantra Agents has been discontinued. Starting with Avantra 7.3, it is replaced by a gateway service within every Avantra Agent. Every Avantra Agent can take over the role of routing traffic from and to the Avantra Server if the network layout requires it.

The Avantra Master is one of the most central and important components of Avantra. It is the communication peer of the Avantra Agents i.e. it receives Check Results and other data provided by the Avantra Agent.

More exactly it performs the following tasks:

Most of the configuration of the Avantra Master can be performed using the Avantra UI. Only the access data for the Avantra Database is required to be configured in a text file.

The Avantra Master runs as a service (on Microsoft Windows operating systems) or as a daemon (on Unix-like operating systems).

The technical name of Avantra Master used e.g. with file names or directories, executable files, log files, and installer packages is master.

The term refers to either of the two: * Monolithic installation and update package for Avantra Master, Avantra UI, and the Avantra Database. * The server hosting the Avantra Master and the Avantra UI (and usually also the Avantra Database.

Avantra UI is the web based user interface to Avantra. Almost all configuration and operation tasks of Avantra are performed with this interface. Depending on the user Permissions you have many of the functions provided by the Avantra UI may be read-only or not available at all.

Being a web application, Avantra UI can easily be deployed in a way that both, internal staff (i.e. representatives of the Service Provider operating Avantra) and Customers have access to it. Avantra UI uses the Jetty HTTP server and Java Servlet container.

The technical name of Avantra UI used e.g. with file names or directories, executable files, log files, and installer packages is xangui.

Availability Data is collected for Servers, SAP Instances, SAP Systems, Databases, and Business Services. Data collection is performed locally by the Avantra Agent (except for SAP Systems and Business Services) in order to be independent from any network interruptions, etc.

A Physical Server is considered available (or UP) as long as the installed Avantra Agent is running. During the startup phase the Avantra Agent tries to determine since when a Physical Server was running already and it generates availability data back in the past. For time periods the Physical Server can not determine the System is running the availability is considered UNKNOWN.

Consequently, a Virtual Cluster Server is considered available as long as there is a Avantra Agent running on the Physical Server the Virtual Cluster Server is active on.

A SAP Instance is considered available if the following checks are Ok:

In other words, a SAP Instance is considered UP as long as the Avantra Agent can login. If the login attempt fails, the SAP Instance is considered DOWN.

An SAP System is considered available if the SystemAlive Check is OK. Unlike other Availability Data, the data for an SAP System is collected constantly in the background and is updated immediately.

A Database is considered available if the DBCONNECT Check is OK.

In addition to the availability of Systems there is also the so called Service Availability for some of the Custom Checks or Composite Checks. Roughly speaking, as long as the Custom Checks or Composite Checks are OK, the Service in considered available, otherwise it is not.

The availability of the Database instance of an SAP System is reported as a special Service Availability for the service DATABASE.

In the context of End-to-End Application Monitoring there is also the so called End Point Availability.

A BusinessService is considered available, as long as its check status is OK.

Before you generate Service Level Reports you have the opportunity to modify UNKNOWN periods and enter the real availability status during time periods the Avantra Agent could not cover. You can also add additional description, or correct availability records in case you forgot to plan Maintenance Windows. If a System is Down during a Maintenance Window (or more general: if monitoring is turned off) the Downtime is considered “planned” (as opposed to “unplanned” Downtime else). “Planned” Downtime is not counted for the Service Level.