C

Avantra kann mit dem SAP CCMS (Computing Center Management System) interagieren und CCMS Monitoring Tree Elements als Echtzeit-Monitoring-Prüfungen einbinden.

Die Definition kann sogar auf der Ebene des "CCMS Monitors" erfolgen, wobei alle darunterliegenden "Monitoring Tree Elements" als einzelne Prüfungen integriert werden.

CCMS Alerts werden im SAP-System (optional) automatisch bestätigt, sobald sie in Avantra importiert wurden. Sie können sie über die Avantra UI überprüfen, über Benachrichtigungen weiterleiten und anschließend löschen. Darüber hinaus können "CCMS Monitoring Tree Elements" zentral gelesen und konfiguriert werden. Die Integration und Konfiguration erfolgen mittels Custom Checks.

Avantra bietet eine integrierte Change-Management-Lösung, die es Kunden ermöglicht, Änderungen an ihren Systemen zu beantragen. Viele der Systemänderungen werden automatisch mithilfe der System Change Auto Detection erfasst.

Die Überwachung in Avantra erfolgt durch die Ausführung der sogenannten Checks, die vom Avantra Agent und dem Avantra-Server durchgeführt werden.

Die Liste der ausgeführten Checks variiert je nach Systemtyp:

Jeder Check liefert ein Prüfergebnis unter Berücksichtigung der Ergebnisse der Root Cause Analysis.

Checks werden in verschiedenen Check-Zyklen ausgeführt, und die Liste der ausgeführten Checks hängt vom Systemtyp ab. Die Check-Zyklen sind:

Avantra-Checks bieten von Natur aus eine Root Cause Analysis und nutzen auch Trendanalyse und Vorhersage.

Einige Checks werden auf Abruf vom Avantra Server ausgeführt. Dies sind in erster Linie die Composite Checks und die Business Services.

Es gibt eine Option für {_Check Confirmation}, und sowohl für die Echtzeitüberwachung als auch für die täglichen Checks wird eine Historie geführt.

Jeder Avantra-Check gehört zu einer der folgenden Kategorien:

RealTime Monitoring Checks und Daily Checks können von einem Administrator bestätigt und zurückgesetzt werden, um zu dokumentieren, dass alle vom Check eventuell aufgeworfenen Probleme verfolgt wurden.

Jede einzelne Prüfung hat ein bestimmtes Prüfergebnis nach der Ausführung. Das Ergebnis besteht aus zwei Teilen: dem Prüfstatus und der Prüfnachricht. Während die Prüfnachricht ein freier Text ist (und in sehr wenigen Fällen sogar leer sein kann), z. B. WARNING — 'xyz' is used by 35.1%, ist das Prüfergebnis in jedem Fall eines der folgenden:

Ein Check Selector ist eine logische Gruppierung von Checks innerhalb von Avantra. Sie definieren eine Gruppe von Prüfungen, die im Echtzeit-Monitoring, bei Benachrichtigungen und in Business Services verwendet werden.

Ein Check Selector kann entweder Echtzeit-Monitoring-Prüfungen, tägliche Prüfungen oder beides gruppieren. Die Gruppe von Prüfungen, die aus dem Check Selector ausgewählt werden soll, kann durch von Ihnen definierte Attribute festgelegt werden.

Es ist auch möglich, die ausgewählten Prüfungen auf eine klar definierte Gruppe von überwachten Systemen mithilfe von Check Selectors zu beschränken.

Avantra provides the Cloud Service object type for integration with Software-as-a-Service (SaaS) solutions. Most SaaS solutions provide an API, and Avantra can work with them through the SAP Cloud Service object type. Knowing the solution’s API allows getting the required information, like errors, malfunctions, failures, etc., out of the product and then using it as a basis for Checks. Avantra proposes the following integration methods:

Avantra supports SAP Cloud Connector Integration, SAP Cloud Platform Integration, and SAP Cloud Platform Neo. Other integrations, like Ariba, SuccessFactors, Concur, etc., are planned.

Ein Composite Check ist ein Check, der aus einem oder (in der Regel) mehreren anderen Checks besteht. Dies können entweder eingebaute Checks, Custom Checks oder andere Composite Checks sein. Grob gesagt ist ein Composite Check eine Auswertungsregel, die ein Check-Ergebnis basierend auf den Check-Ergebnissen der Eingangs-Checks bestimmt.

Ähnlich wie bei Custom Checks können Composite Checks für eine statische Gruppe oder eine dynamische Gruppe von Systemen definiert werden. Die Auswertung des Check-Ergebnisses wird von Avantra Server durchgeführt.

Composite Checks zeichnen auch Verfügbarkeitsdaten auf. Der SystemAlive Check ist ein Beispiel für einen eingebauten Composite Check (der nicht geändert werden kann).

Avantra allows you to define Custom Attributes to fulfill your business needs. These attributes can be defined for any of the monitored object types (e.g. Server, SAP System, SAP Instance, BusinessObjects, Database, Cloud Service).

Additional attributes you define will become visible and can be populated in the System details dialog. They can also be used in Selectors.

Although not shown by default, you also have the option to show Custom Attributes in System lists. You can use the list configuration action to display the Custom Attributes in System lists.

Custom Attributes can also be used in Notifications Output Channels.

Das Monitoring kann durch sogenannte Custom Checks erweitert werden. Custom Checks werden bereitgestellt, um:

Ähnlich wie bei den Monitoring Parameter Sets können Custom Checks für eine dynamische Gruppe oder eine statische Gruppe von Systemen definiert werden.

Viele der oben aufgeführten Custom Checks sind auch in der Lage, die sogenannte Service Availability zu verfolgen und aufzuzeichnen. Custom Checks müssen — wie der Name schon sagt — manuell konfiguriert werden.

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.

Whether using Avantra as a single-tenant installation or multi-tenant, the customer setup is an important part of your Avantra installation. Avantra has been developed since the start from a Service Provider’s perspective and is at the core of all functions.

A customer makes a lot of sense for a service provider where there are literally different customers configured in the system and it is a logical separation of monitored objects, for single enterprises this can still be a very useful concept especially if you are dealing with different business units or entities that require logical separation.

Customers “own” the Systems contained within them. 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. Similarly, other Managed Objects are “owned” by Customers.

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.

A Customer Application is a grouping mechanism for Systems consisting of a Customer and an ApplicationType.