Extend Monitoring

Die sogenannten Custom Checks, Composite Checks, Business Services und Externally Managed Checks sind das Toolkit, das Avantra bereitstellt, um die Kernfunktionen von RealTime Monitoring und Daily Check an spezifische Anforderungen anzupassen.

Benutzerdefinierte Prüfungen

Die am häufigsten verwendete Erweiterung für Avantra erfolgt über Custom Checks. Ein Custom Check verwendet unser umfangreiches Toolkit, um zusätzliche Überwachungsinformationen von verwalteten Systemen und anderen Systemen und Diensten in Avantra zu integrieren. Custom Checks verwenden das Pull-Prinzip, das bedeutet, dass der Avantra Agent aktiv einen Custom Check ausführt, um die Daten zu erhalten. Einige Custom Check-Typen bieten Skriptfunktionen mit der Bereitstellung von Skripten und können sehr leistungsfähig sein. Siehe die Abschnitte Extending by Custom Checks und API Documentation für weitere Informationen.

Extern verwaltete Prüfungen

Externally Managed Checks sind ähnlich wie Custom Checks, müssen jedoch an Avantra über die Web-Service-API oder die Befehlszeile übermittelt werden. Externally Managed Checks werden vollständig von einem externen Programm oder Skript gesteuert, sie werden nicht automatisch wie Custom Checks ausgelöst. Avantra prüft jedoch, ob Externally Managed Checks auf dem neuesten Stand sind, um sicherzustellen, dass keine verwaisten Informationen vorhanden sind. Technisch werden die extern verwalteten Prüfungen über die Web-Service- oder Befehlszeilenschnittstelle erstellt (siehe unten).

Erweiterung durch benutzerdefinierte Prüfungen

Definieren von benutzerdefinierten Prüfungen

Einige der Custom Checks können nur für SAP Systems oder SAP Instances definiert werden, während andere für jeden System Type definiert werden können. Custom Checks werden immer auf dem Physical Server ausgeführt, der die Überwachung des Systems durchführt, für das der Custom Check definiert ist.

Für einige der SAP-spezifischen Custom Checks können Sie auswählen, ob Sie den Custom Check auf der Central SAP Instance oder auf dem Database-Host ausführen möchten.

Procedure: Definieren einer benutzerdefinierten Prüfung

  1. Wählen Sie im Top-Level-Menü Configuration  Custom Check und drücken Sie die Schaltfläche New.

  2. Wählen Sie einen der Custom Checks aus der Liste aus.

  3. Geben Sie einen CustomCheck Name ein. Die folgenden Zeichen sind nicht erlaubt: /\:*?"<>|

  4. Wählen Sie den entsprechenden System Type. Der Custom Check wird dann im Kontext des ausgewählten Systemtyps ausgeführt, d. h. er wird ausgeführt, wenn der entsprechende Check Cycle des Systems läuft. Nicht alle System Types sind für jeden Custom Check verfügbar.

  5. Wählen Sie optional einen Customer aus. Falls Sie einen auswählen, werden nur die Systems dieses Customer (und seiner Nachfolger, falls eine Customer-Hierarchie verwendet wird) berücksichtigt. Außerdem muss ein User über die Berechtigung View Custom Checks / Edit Custom Checks für den benannten Customer verfügen, um den Custom Check anzuzeigen oder zu ändern.

    Wenn Sie dieses Feld leer lassen, werden Systems aller Customers berücksichtigt, aber ein Benutzer benötigt die Berechtigung View Custom Checks / Edit Custom Checks für alle Customers, um den Custom Check anzuzeigen oder zu ändern.

  6. Drücken Sie die Schaltfläche Create, um den Datensatz zu erstellen. Die Details des neu erstellten Custom Check werden geöffnet. Die Definition ist noch nicht abgeschlossen und der neue Custom Check ist daher noch nicht aktiv.

  7. Optional können Sie eine aussagekräftige Beschreibung hinzufügen.

  8. Optional können Sie einen Ausführungszyklus auswählen. Standardmäßig werden Custom Checks im Basic Check Cycle des Avantra Agent ausgeführt (Listenwert RTM). Sie können einen eigenen Ausführungszyklus eingeben oder den Custom Check im täglichen Zyklus ausführen (siehe Full Check Cycle).

    Die tatsächliche Zykluszeit wird immer auf die nächste Basic Check Cycle-Ausführungszeit "aufgerundet". Wenn Sie beispielsweise 8 Minuten als Zykluszeit eingeben und der Basic Check Cycle standardmäßig 5 Minuten beträgt, wird der Check alle 10 Minuten in jedem 2. Basic Check Cycle ausgeführt.

  9. Optional können Sie Benachrichtigungen für jeden benutzerdefinierten Check aktivieren/deaktivieren, indem Sie das Kontrollkästchen Enable Notifications aktivieren.

  10. Füllen Sie im Abschnitt Specific die erforderlichen Werte aus.

  11. Drücken Sie die Schaltfläche Apply, um Ihre Daten zu speichern.

    Ein Dialogfeld Activate Custom Check wird angezeigt und fragt, ob der Custom Check aktiviert werden soll. Wählen Sie Yes, wenn alles in Ordnung ist, oder No, wenn Sie Änderungen vornehmen möchten.

Sie können Custom Checks deaktivieren, wie in Systems, für die der Custom Check definiert wurde, beschrieben. Wenn Sie den Custom Check deaktivieren, wird er offensichtlich auf allen definierten Systems deaktiviert.

Benutzerdefinierte Prüfungen nach Typ auflisten

In größeren Avantra-Installationen können viele Custom Check-Definitionen vorhanden sein, wodurch Sie möglicherweise den Überblick verlieren. Um Ihnen in einer solchen Situation zu helfen, gibt es eine spezielle Listenansicht.

Wenn Sie noch nicht dort sind, gehen Sie zu Configuration  Custom Checks und wählen dann More  Show Checks of Type  Choose the Type….

Ein neuer Tab wird geöffnet, in dem alle Custom Checks des gleichen Typs einschließlich der Konfigurationsparameter in einer Liste angezeigt werden. Wenn Sie einen bearbeiten möchten, können Sie ihn einfach durch Doppelklicken öffnen, wie in der Hauptliste, und dann Ihre Änderungen vornehmen.

Bitte beachten Sie, dass standardmäßig nicht alle Konfigurationsparameter angezeigt werden, da die Tabelle viele Spalten enthalten kann. Sie können jedoch die Parameter auswählen, die angezeigt werden sollen, indem Sie auf das kleine Zahnradsymbol in der letzten Spalte klicken.

Exportieren und Importieren von benutzerdefinierten Prüfungen

Custom Check-Definitionen können in eine ZIP-Datei exportiert und auf einem anderen Avantra-Server importiert werden. Dies kann nützlich sein, wenn Sie einen benutzerdefinierten Custom Check auf einem Test-Avantra Server getestet haben, bevor Sie ihn auf einem anderen produktiv verwenden möchten. Sie können Custom Check-Definitionen auch an andere Avantra-Benutzer weitergeben.

Procedure: Exportieren einer benutzerdefinierten Prüfung

  1. Wählen Sie im Top-Level-Menü Configuration  Custom Checks und wählen Sie die Custom Checks, die Sie exportieren möchten, aus der Liste aus. Sie können die Strg- und/oder Umschalttaste Ihrer Tastatur verwenden, um mehrere Custom Check-Listeneinträge gleichzeitig zum Exportieren auszuwählen.

  2. Klicken Sie entweder mit der rechten Maustaste auf einen der ausgewählten Einträge und wählen Sie Export Custom Checks oder wählen Sie More und denselben Menüpunkt.

  3. Geben Sie im folgenden Dialogfeld einen passenden Namen für die Exportdatei ein oder bestätigen Sie den Standardnamen, indem Sie die Schaltfläche Export drücken.

  4. Bestätigen Sie die Informationsmeldung, dass die ZIP-Datei mit den Custom Check-Definitionen in den Download-Bereich Ihres Browsers exportiert wurde.

Wenn ein RUN_PROG Custom Check mit einem zu installierenden Programm konfiguriert ist, wird dieses Programm in die Custom Check-Exportdatei aufgenommen.

Wenn die Definition der benutzerdefinierten Prüfung einen Pre-Defined System Selector verwendet, wird der Name dieses Systemselektors in die Exportdatei der benutzerdefinierten Prüfung aufgenommen. Beim Import überprüft die Avantra-Benutzeroberfläche, ob ein Selektor mit demselben Namen im Zielsystem vorhanden ist, und weist diesen Selektor der importierten Definition der benutzerdefinierten Prüfung zu.

'Ad-Hoc' Custom Selection wird nicht exportiert.
Procedure: Importieren einer benutzerdefinierten Prüfung

  1. Wählen Sie im Top-Level-Menü Configuration  Custom Checks.

  2. Wählen Sie More und wählen Sie Import Custom Checks.

  3. Ein Dialogfeld Import Custom Checks - Select Custom Check Package wird angezeigt. Drücken Sie die Schaltfläche Upload, um eine Exportdatei der Custom Check-Definition hochzuladen. Sobald das Paket angezeigt wird, drücken Sie Next, um fortzufahren.

  4. Die in der Exportdatei gefundenen Custom Check-Definitionen werden angezeigt. Wählen Sie die zu importierenden aus, indem Sie die entsprechenden Schaltflächen drücken, um die Elemente aus dem linken Bereich in den rechten Bereich des Dialogschritts Select Custom Checks zu verschieben, und drücken Sie Next, um fortzufahren.

  5. Der Dialogschritt Import Settings wird angezeigt. Wenn bereits ein Custom Check mit demselben Namen im Zielsystem existiert, wird dieser rot markiert. Sie können entweder einen neuen mit einem anderen Namen erstellen oder das vorhandene aktualisieren. Drücken Sie Next, um fortzufahren.

  6. Der letzte Dialogschritt wird angezeigt, um Ihre Einstellungen zu bestätigen. Drücken Sie entweder Import, um den Import durchzuführen, Back, um Ihre Einstellungen zu ändern, oder Cancel, um den Importvorgang vollständig abzubrechen.

Die neu importierten Custom Checks sind immer inaktiv und müssen aktiviert werden, bevor sie tatsächlich angewendet werden.

Wenn die exportierte Custom Check-Definition einen Pre-Defined System Selector-Namen enthielt, weist der Import der Custom Check-Definition einen System Selector mit demselben Namen zu. 'Ad-Hoc' Custom Selection wird weder exportiert noch importiert. In diesem Fall ist der Abschnitt Systems leer und muss konfiguriert werden, bevor der Custom Check aktiv gemacht wird.

Definieren benutzerdefinierter Überwachungsparameter

Es kann Fälle geben, in denen Sie bestimmte Informationen an die Custom Check-Definition übergeben müssen, die beispielsweise zwischen den Systems, auf die der Custom Check angewendet wird, variieren. Sie können Custom Monitoring Parameters genau für diesen Zweck verwenden.

Um einen neuen Custom Monitoring Parameter zu definieren, gehen Sie wie folgt vor:

  1. Öffnen Sie das Menü Administration  Settings und wechseln Sie zum Tab Custom Monitoring Parameters.

  2. Drücken Sie die Schaltfläche New und geben Sie einen Name ein. Der Name muss mit dem Präfix cust. beginnen.

  3. Wählen Sie einen System Type, eine Unit, und drücken Sie die Schaltfläche Create.

  4. Öffnen Sie den neu erstellten Eintrag und füllen Sie optional einen Default Value und eine Description aus. Drücken Sie die Schaltfläche Apply, falls Sie Änderungen vorgenommen haben.

Dieser Parameter und der eventuell definierte Standardwert sind allen Avantra Agents automatisch bekannt. Sie können Werte auf einer per-System-Ebene definieren, wie in Adding, Modifying & Deleting Monitoring Parameters beschrieben, oder in einem Parameter Set, wie in Maintaining Parameter Sets beschrieben.

Verwenden benutzerdefinierter Überwachungsparameter in benutzerdefinierten Prüfungen

Sie können Custom Monitoring Parameters überall referenzieren, wo Sie Custom Check Macros verwenden können. Wenn Sie einen Parameter cust.MyMonitoringParameter definiert haben, können Sie ihn mit ${moniparams.cust.MyMonitoringParameter} referenzieren.

Die auf JavaScript basierenden Custom Checks SQL_QUERY und RUN_JS bieten einen neuen API-Aufruf, um auf alle Überwachungsparameter, einschließlich der benutzerdefinierten, zuzugreifen. Die Syntax lautet monitoredSystem.getMoniParam("cust.MyMonitoringParameter").

Definieren eigener Log-Adapter für den Log-Adapter Custom Check

Log Adapters werden in den DB2_DIAGLOG- und ORA_ALERTLOG-Prüfungen sowie im LOG_ADAPTER Custom Check verwendet, um den Inhalt einer Logdatei zu überwachen, entweder eines Windows Event Log oder einer normalen Textdatei.

Die Aufgabe der Protokollüberwachung wird in zwei Schritte unterteilt: Zuerst extrahieren Log Adapters die Einträge eines Protokolleintrags und transformieren die Daten in eine Reihe von Schlüssel-Wert-Paaren (sogenannte Macros), die den Protokolleintrag in Avantra darstellen. Anschließend wird eine Reihe von Regeln definiert, um diese Schlüssel-Wert-Paare zu bewerten und festzustellen, ob eine Warnung ausgelöst werden muss.

Dieser Abschnitt behandelt den ersten Schritt der Verarbeitung. Für die Einrichtung eines LOG_ADAPTER Custom Check, siehe Defining Custom Checks.

Siehe auch das folgende Bild:

log adapter overview

Es gibt eine Reihe von vordefinierten Log Adapters: Wählen Sie Configuration  Log Adapters aus dem Top-Level-Menü.

Definieren eines Windows Event Log Adapters

Avantra bietet standardmäßige Log-Adapter für die Windows-Ereignisprotokolltypen Application und System. Windows-Ereignisprotokoll-Adapter bieten festgelegte Schlüssel-Wert-(Makro-)Paare für die weitere Verarbeitung entsprechend den verfügbaren Windows-Ereignisprotokollfeldern. Sie können die Makronamen der Felder für Windows-Ereignisprotokoll-Adapter nicht ändern.

Um einen Windows Event Log Adapter zu erstellen, gehen Sie wie folgt vor:

  1. Wählen Sie Configuration  Log Adapters aus dem Top-Level-Menü. Eine Liste aller vorhandenen Log Adapters wird angezeigt.

  2. Drücken Sie die Schaltfläche New.

  3. Wählen Sie Windows Event Log als Log Adapter-Typ und geben Sie einen Namen für den Log Adapter ein.

  4. Drücken Sie New. Öffnen Sie den neu erstellten Eintrag aus der Liste.

  5. Geben Sie den gewünschten Windows Windows Event Log Name für den Log Adapter ein.

  6. Drücken Sie Apply.

Definieren eines dateibasierten Log-Adapters

Die Einrichtung eines dateibasierten Log Adapter ist etwas komplexer, da Sie Avantra über die Struktur der Einträge in der Protokolldatei und über die Daten informieren müssen, die Sie daraus extrahieren möchten.

Ein dateibasierter Log Adapter besteht aus einem oder mehreren sogenannten Token-Parsers, von denen jeder eine bestimmte Anzahl von Zeichen aus einem einzelnen Protokolleintrag extrahiert. Alle definierten Token-Parsers sollen zusammen den gesamten Protokolleintrag lesen.

Jeder Token-Parser hat die folgenden Elemente:

Type

Definiert den Typ des Token-Parsers, d. h. wie das Ziel-Token interpretiert werden soll (z. B. ein Zeitstempel, Textblock usw.).

Identifier

Definiert den Namen des Macros für den Token-Wert zur Verwendung in Ausdrücken im LOG_ADAPTER Custom Check. Wenn nicht definiert, wird das Token analysiert, aber nicht ausgewertet und ist daher im Custom Check nicht zugänglich.

Description

Definiert eine Beschreibung für Anzeigezwecke. Diese Beschreibung erscheint als Tooltip (bei Mouseover), wenn das Token als Macro im LOG_ADAPTER Custom Check verwendet wird.

Parameters, Parameter Values

Typabhängige Parameter wie Terminatoren, Formatzeichenfolgen usw.

Opt

Gibt an, ob das Token optional ist. Dies ermöglicht das Modellieren variabler Protokolldateiformate. Wenn Sie ein Token als optional definieren, indem Sie das Kontrollkästchen Opt. aktivieren, muss das Token nicht vorhanden sein, um eine Übereinstimmung mit dem entsprechenden Protokolleintrag zu erzielen; Protokolleinträge, die kein entsprechendes Token enthalten, werden dennoch abgeglichen. Wenn ein Token nicht optional ist, wird ein Protokolleintrag, der das Token nicht enthält, nicht abgeglichen und somit weggelassen.

Dieses Element ist nicht für alle Typen verfügbar.

Verfügbare Token-Parser-Typen sind in der folgenden Tabelle aufgeführt:

Table 1. Token Parser Types

Token Parser

Parameter

Beispiele

Type

Zweck

Name

Werte

 
KEYVALUE

Tokens, die ein Schlüssel-Wert-Paar darstellen. Analysiert Tokens, die mit dem angegebenen Schlüssel beginnen, gefolgt von null oder mehr Leerzeichen und einem optionalen Trennzeichen, gefolgt von beliebigem Text bis zu einem spezifizierbaren Terminator. Überspringt alle vorangehenden Zeichen bis zum ersten Auftreten des Schlüssels.

 
KEYS

Liste von Schlüsselwörtern. Wenn mehr als eins, getrennt durch | (Pipe)

PID = 364738; FUNCTION : DB2 UDB, Automatic Table Maintenance, AtmTable::runstats, probe:900; ORA-27041 : unable to open file

 
DELIMITERS

Liste von Trennzeichen. Wenn mehr als eins, getrennt durch | (Pipe)

 
TERMINATORS

Liste von Terminatoren für das Wertefeld. Wenn mehr als einer, getrennt durch | (Pipe).

 
NUMBER

Tokens, die einen numerischen Wert darstellen. Dieser Token-Parser-Typ umfasst ganze Zahlen und Gleitkommazahlen mit oder ohne Exponentialdarstellung. Überspringt vorangehende Leerzeichen.

42; -3.14159; 6.23e-23

 
PATTERN

Tokens mit spezifischer Formatierung. Überspringt vorangehende Leerzeichen.

 
FORMAT

Eine Formatzeichenfolge, die das Format des Tokens abgleicht.

127.0.0.1:9050; 4052 BASEL; 492d1ab9.1c87

 
TEXTBLOCK

Tokens, die eine beliebige Textsequenz darstellen. Analysiert alle Zeichen bis zu einem angegebenen Terminator oder bis zum Ende des Protokolleintrags. Überspringt vorangehende Leerzeichen.

 
TERMINATORS

Liste von Terminatoren, die das Ende des Textblocks definieren. Wenn mehr als einer, getrennt durch | (Pipe).

Could not establish connection to 'localhost:9050'; Found performance data file(s): perfdata_0_2008.tmp

 
TIMESTAMP

Tokens, die einen Zeitstempel darstellen.

 
FORMAT

Eine Formatzeichenfolge, die das Format des Zeitstempels abgleicht.

2008-05-19­09.04.53.966725­+120; Sun Oct 18 12:47:50 2008; 1194030895484 (ctime Zeitstempel)

 
UNWRAP

Tokens, die durch ein Präfix und ein Suffix umschlossen sind. Dieser Token-Parser-Typ gibt den Text zwischen Präfix und Suffix zurück. Überspringt vorangehende Leerzeichen.

 
PREFIX

Liste von Präfixen, wenn mehr als eins, getrennt durch | (Pipe).

{`WARNING}`; <date>`Sun Oct 18 12:47:50 2008</date>`

 
SUFFIX

Liste von Suffixen, wenn mehr als eins, getrennt durch | (Pipe).

Wenn Sie einen DELIMITER angeben, entspricht der Wert des Tokens dem Text hinter dem Trennzeichen bis zum Terminator. Leerzeichen zwischen Schlüssel und Trennzeichen werden ignoriert. Wenn Sie keinen DELIMITER angeben, ist der Schlüssel im Tokenwert enthalten (siehe das letzte Beispiel der entsprechenden Zeile).

Siehe auch das folgende Bild:

ui log adapter definition

Jeder der Token-Parser-Parameterwerte kann Metazeichen enthalten, auch als Muster bekannt, die auf der Seite Edit Token Parser in Avantra WebUI erklärt werden und nicht mit dem PATTERN-Token-Parser selbst verwechselt werden dürfen. Siehe auch Schritt 8b des Procedure: Creating a File-based Log Adapter.

Es gibt einige wichtige Konventionen und Regeln, die Sie beim Erstellen eines dateibasierten Log Adapter beachten sollten:

  1. Der erste Token-Parser einer Log Adapter-Definition dient dazu, die Protokolldatei in einzelne Protokolleinträge zu unterteilen.

    Nach Konvention beginnt ein Protokolleintrag in einer neuen Zeile. Wann immer der Log Adapter-Parser ein Token erkennt, das durch den ersten Token-Parser einer Log Adapter-Definition in einer neuen Zeile übereinstimmt, betrachtet er alle Zeichen bis zum nächsten Übereinstimmen des Token-Parsers als zu diesem einzelnen Protokolleintrag gehörend.

    Erst nach dem Aufteilen der Protokolldatei in einzelne Protokolleinträge werden die verbleibenden Token-Parser der Log Adapter-Definition auf die Protokolleinträge angewendet.

    Um die besondere Bedeutung des ersten Token-Parsers anzuzeigen, wird er in Avantra WebUI blau eingefärbt.

    Normalerweise ist das erste Token eines Protokolleintrags eine Art Zeitstempel, der ein hervorragender Marker für einen dateibasierten Log Adapter ist, um die Protokolleinträge zu trennen. Sie können jedoch das erste Token auf jeden verfügbaren Typ festlegen. Beachten Sie jedoch, dass ein nachlässig definierter TEXTBLOCK-Token-Parser die gesamte Protokolldatei als einen einzigen Protokolleintrag interpretieren könnte. Je nach Größe der Datei könnte dies eine sehr hohe Belastung für den Avantra Agent darstellen.

  2. Die Log Adapter-Definition muss nicht genau mit einem Protokolleintrag bis zum Ende übereinstimmen; solange die Token-Parser den Anfang eines Protokolleintrags korrekt erkennen, können die verbleibenden Zeichen des Eintrags ignoriert werden.

  3. Wenn Sie einen optionalen KEYVALUE-Token-Parser definieren, beachten Sie, dass er jeglichen Text vor dem ersten Auftreten seines Schlüssels überspringen wird.

    In solchen Situationen muss der Wert für KEYS des Token-Parsers sehr sorgfältig definiert werden.

    Betrachten Sie folgendes Beispiel:

    Der Token-Parser sucht nach KEYS name gefolgt von DELIMITERS :. Der aktuelle Protokolleintrag enthält das Token nicht (es ist schließlich optional), aber er enthält eine Fehlermeldung, zum Beispiel WARNING couldn’t resolve hostname: jabba. Der Token-Parser würde alles bis zu name: jabba überspringen, wo er übereinstimmt und den Wert ` jabba` zurückgibt, wobei die WARNUNG-Nachricht vollständig übersprungen würde und wahrscheinlich verhindert, dass der gesamte Log Adapter diesen bestimmten Protokolleintrag abgleicht.

  4. Seien Sie vorsichtig bei der Definition von TEXTBLOCK-, KEYVALUE- oder UNWRAP-Token-Parsern ohne Angabe von TERMINATORS in Kombination mit optional Tokens.

    Ein Token-Parser ohne TERMINATORS versucht, so viele Zeichen wie möglich abzugleichen (auch als gierig bekannt). Dies kann verhindern, dass nachfolgende optionale Token-Parser übereinstimmen, selbst wenn ein entsprechendes Token vorhanden ist.

    Betrachten Sie folgendes Beispiel:

    Ein optionaler KEYVALUE-Token-Parser ohne TERMINATORS sucht nach KEYS MESSAGE. Ein nachfolgender optionaler KEYVALUE-Token-Parser sucht nach dem Schlüssel KEYS DATA. Wenn der erste Token-Parser übereinstimmt, wird der zweite Token-Parser niemals übereinstimmen, da jedes nachfolgende DATA-Token vom ersten unbestimmten Token-Parser konsumiert wird.

Um tatsächlich einen dateibasierten Log Adapter zu erstellen, gehen Sie wie folgt vor:

Procedure: Erstellen eines dateibasierten Log Adapters

  1. Holen Sie sich einen vernünftigen Auszug aus einer Beispielprotokolldatei, die die interessanten Protokolleinträge enthält, und kopieren Sie ihn in Ihre Zwischenablage.

  2. Wählen Sie Configuration  Log Adapters aus dem obersten Menü aus. Eine Liste aller vorhandenen Log Adapters wird angezeigt.

  3. Drücken Sie die New-Schaltfläche.

  4. Wählen Sie File Adapter als Log Adapter-Typ und geben Sie einen Namen für den Log Adapter ein.

  5. Drücken Sie New. Öffnen Sie den neu erstellten Eintrag aus der Liste.

  6. Geben Sie eine Beschreibung für Ihren Log Adapter auf der Seite Edit Log Adapter ein.

  7. Wechseln Sie zur Registerkarte Parser Definition.

  8. Für jeden Token-Parser führen Sie Folgendes durch:

    1. Drücken Sie die Add Token Parser-Schaltfläche. Wählen Sie einen geeigneten Token-Parser aus der Dropdown-Liste in der Spalte Type aus, geben Sie eine Identifier ein, um den extrahierten Token in einem LOG_ADAPTER Custom Check zu verwenden, und eine Description.

    2. Füllen Sie gegebenenfalls die entsprechenden Parameter Values aus. Sie können die verfügbaren Muster in den Feldern Parameter Values anzeigen, indem Sie auf das Symbol klicken.

    3. Wechseln Sie zur Registerkarte Test Parser und drücken Sie die Parse-Schaltfläche. Wenn Sie den Token-Parser korrekt definiert haben, sollte der übereinstimmende Eintrag im Textfeld hervorgehoben werden.

    4. Drücken Sie die Parser Definition-Schaltfläche.

      Um einen weiteren Token-Parser hinzuzufügen, drücken Sie die Add Token Parser-Schaltfläche und wiederholen Sie ab Schritt a.

      Wenn Sie einen weiteren Token-Parser zwischen zwei bestehenden hinzufügen müssen, müssen Sie einen neuen Token-Parser am Ende hinzufügen und anschließend mithilfe der Symbole und an die richtige Stelle verschieben.

      Um einen Token-Parser zu entfernen, drücken Sie auf das Symbol .

      ACHTUNG: Beachten Sie, dass der erste definierte Token-Parser verwendet wird, um die Protokolldatei in Protokolleinträge zu unterteilen. Wenn Ihre Protokolldatei einen Zeitstempel enthält, wird dringend empfohlen, einen TIMESTAMP als ersten Token-Parser zu verwenden.

  9. Drücken Sie die Apply-Schaltfläche, um die Änderungen zu speichern.

  10. Wechseln Sie zur Registerkarte Test Parser. Drücken Sie die Enter log file sample-Schaltfläche und fügen Sie die zuvor in Log Adapter Definition kopierten Echtdaten ein.

Duplizieren von Log-Adaptern

Anstatt einen Log Adapter von Grund auf neu zu erstellen, kann es einfacher sein, auf einer vorhandenen Definition aufzubauen.

Führen Sie die folgenden Schritte aus, um einen Log Adapter zu duplizieren:

  1. Wählen Sie Configuration  Log Adapters aus dem obersten Menü. Eine Liste aller vorhandenen Log Adapters wird angezeigt.

  2. Wählen Sie einen geeigneten Log Adapter aus der Liste aus.

  3. Drücken Sie die Copy-Schaltfläche.

  4. Fahren Sie fort wie ab Schritt 8 von Procedure: Creating a File-based Log Adapter beschrieben.

Das Duplizieren eines bestehenden Log Adapter und dessen Modifikation ist die bevorzugte Methode gegenüber der einfachen Modifikation eines bestehenden. Log Adapters können nur in sehr einfacher Weise geändert werden, sobald sie in einem LOG_ADAPTER Custom Check verwendet werden.

Löschen von Log-Adaptern

Sie können nur Log Adapter löschen, die in keinem LOG_ADAPTER Custom Check verwendet werden.

Führen Sie die folgenden Schritte aus, um einen Log Adapter zu löschen:

  1. Wählen Sie Configuration  Log Adapters aus dem obersten Menü. Eine Liste aller vorhandenen Log Adapters wird angezeigt.

  2. Wählen Sie die entsprechenden Listeneinträge aus.

  3. Drücken Sie die Delete-Schaltfläche.

Exportieren und Importieren von Log-Adaptern

Führen Sie die folgenden Schritte aus, um einen Log Adapter zu exportieren:

  1. Wählen Sie Configuration  Log Adapters aus dem Hauptmenü. Eine Liste aller vorhandenen Log-Adapter wird angezeigt.

  2. Wählen Sie einen geeigneten Log Adapter aus der Liste aus.

  3. Drücken Sie die Export Taste, um die Datei herunterzuladen.

Führen Sie die folgenden Schritte aus, um einen Log Adapter zu importieren:

  1. Wählen Sie Configuration  Log Adapters aus dem Hauptmenü. Eine Liste aller vorhandenen Log-Adapter wird angezeigt.

  2. Drücken Sie die Import Taste und wählen Sie eine geeignete .lga Datei aus.

  3. Drücken Sie die Upload Taste.

  4. Fahren Sie fort wie in Schritt 8 von Procedure: Creating a File-based Log Adapter beschrieben.

Konfigurieren von SAP CCMS mit Avantra

Avantra ist in der Lage, Konfigurationselemente in CCMS zu schreiben, mittels des CCMS Custom Check.

Wenn Sie planen, CCMS mit Avantra zu konfigurieren, müssen Sie die CCMS Architektur und das Konzept verstehen.

Sie müssen mit den folgenden CCMS Begriffen vertraut sein:

  • Überwachungsobjekte & Überwachungsbaum-Elemente (MTEs)

  • MTE-Klassen und Attributgruppen

  • Attributtypen (Leistung, Status, Protokoll, Text) und ihre Eigenschaften

  • Eigenschaftsvarianten

Wir empfehlen dringend, dass Sie mindestens die Abschnitte "Konzept der Überwachungsarchitektur", "Betrieb des Alarmmonitors" und "Anpassung des Alarmmonitors" im Kapitel "Der Alarmmonitor" der SAP Library studieren.

Zusätzlich müssen Sie mit den SAP-Transaktionen RZ20 und RZ21 vertraut sein.

CCMS Konfigurationsvariante

Standardmäßig wird Avantra keine bestehenden CCMS Einstellungen in Ihrem SAP System ändern.

Alle von Avantra angewendeten Einstellungen werden in einer neuen "Eigenschaftsvariante" namens SYSLINK gespeichert. Diese neue Variante wird jedoch standardmäßig automatisch aktiviert, d.h. die durch Avantra konfigurierten Einstellungen werden tatsächlich verwendet. Eine "Eigenschaftsvariante" kann als eine Gruppe von Änderungen an CCMS Eigenschaften betrachtet werden.

Sie können die aktuell aktive Variante mit der Transaktion RZ21 herausfinden. Wenn Einstellungen erfolgreich durch Avantra definiert wurden, wird SYSLINK als aktive Variante angezeigt, wie im folgenden Bild gezeigt:

sapgui ccms properties variants

Im Tab Additional info des konfigurierten MTE-Eigenschaften-Bildschirms finden Sie die angezeigten Werte, die für die Variante SYSLINK gültig sind. Siehe folgendes Bild:

sapgui ccms mte additional info

Sie können sich leicht einen Überblick über alle CCMS Konfigurationen verschaffen, die auf Ihr SAP System durch Avantra angewendet wurden. Führen Sie einfach eine Abfrage für Eigenschaften in der Transaktion RZ21 durch.

CCMS Konfiguration für einzelne MTE

Standardmäßig ändern die von Avantra angewendeten CCMS Konfigurationseinstellungen die Eigenschaften der zugrunde liegenden Klasse oder der Customizing-Gruppe des MTE. Die geänderten Eigenschaften werden dann auf alle MTEs angewendet, die zu dieser Klasse oder zu allen Attributen einer Customizing-Gruppe gehören. Dies ist die von SAP empfohlene Vorgehensweise.

Das bedeutet, wenn Sie ein SAP System mit mehreren SAP Instances haben und die "Leistungseigenschaften" des MTE Dialog\ResponseTime ändern, werden alle SAP Instances des SAP System die neuen Eigenschaften übernehmen. Standardmäßig werden die Eigenschaften in der Customizing-Gruppe R3DialogResponseTime gespeichert, die wiederum standardmäßig allen Dialog\ResponseTime MTEs zugewiesen ist. Siehe das Bild unten:

sapgui ccms perf attrib
Figure 1. CCMS MTE mit Leistungsattribut

Sie können Avantra so konfigurieren, dass die Einstellungen individuell auf ein MTE angewendet werden. Dies kann beispielsweise nützlich sein, wenn Sie SAP Instances haben, die unterschiedliche Zwecke erfüllen, und Sie die Antwortzeiteinstellungen auf einer SAP Instance-Ebene überwachen möchten.

Die Verwendung von CCMS Einstellungen für MTEs einzeln ist eine Entscheidung, die nur manuell rückgängig gemacht werden kann. Sie müssen die Klasse/Gruppe für jedes einzelne SAP System mit der Transaktion RZ20 neu zuweisen.

Wenn Sie die Konfiguration eines einzelnen MTE in einem CCMS Custom Check gewählt haben und diese Änderung im Custom Check rückgängig machen, erhalten Sie die folgende Fehlermeldung im Check Result im RealTime Monitoring angezeigt:

XAL Schnittstellenfehler: Keine Daten für MTE-Klasse des MTE verfügbar

Um die Ursache dieses Fehlers zu beheben, führen Sie die folgenden Schritte für jedes betroffene SAP System durch:

  1. Melden Sie sich am SAP System an und gehen Sie zur Transaktion RZ20.

  2. Bearbeiten Sie die Eigenschaften des entsprechenden MTE.

  3. Wählen Sie im Menü:Edit[Properties > Use from MTE class/group].

    sapgui ccms assign class group to mte 1

  4. Weisen Sie dem MTE die richtige Klasse/Gruppe zu.

    sapgui ccms assign class group to mte 2

SAP CCMS mit einem CCMS Custom Check in Avantra konfigurieren

Bitte stellen Sie sicher, dass die folgenden Voraussetzungen erfüllt sind:

  • Sie haben einen CCMS Custom Check definiert (wie in Check beschrieben) und dieser läuft ordnungsgemäß, die MTE-Werte werden im RealTime Monitoring korrekt angezeigt.

  • Sie haben die CCMS Einstellungen ermittelt, die Sie konfigurieren möchten. Sie haben die Einstellungen des entsprechenden MTEs mindestens auf einer SAP Instance oder einem SAP System mit der SAP-Transaktion RZ20 getestet. Der Eigenschaftsdialog in RZ20 führt Konsistenzprüfungen durch, Avantra tut dies jedoch nicht.

  • Sie haben CCMS Configuration Variant gelesen und verstanden.

  • Sie haben die in CCMS Configuration for individual MTE beschriebenen Implikationen gelesen und verstanden.

Führen Sie die folgenden Schritte aus:

  1. Wählen Sie im Menü:Configuration[Custom Checks] aus dem Hauptmenü. Wählen Sie den gewünschten Custom Check aus der Liste und drücken Sie die Schaltfläche Open.

  2. Wechseln Sie zur Registerkarte CCMS Configuration und drücken Sie die Schaltfläche Create.

  3. Füllen Sie die Einstellungen aus, die Sie in CCMS schreiben möchten.

    HINWEIS: Wir empfehlen dringend, nur die Einstellungen auszufüllen, die Sie ändern möchten! Wenn Sie alle anderen Felder leer lassen, bleiben die ursprünglichen Einstellungen in CCMS unberührt.

    Sie müssen mindestens eine Einstellung eingeben, entweder für die General Properties oder für eine der Attribute Properties.

    Wenn Sie einen Attributtyp konfigurieren möchten, stellen Sie bitte sicher, dass Ihr MTE tatsächlich ein Attribut enthält und dass Sie den richtigen Typ gewählt haben. Andernfalls wird die folgende Fehlermeldung als Check Result angezeigt:

    XAL Schnittstellenfehler: Ungültige CCMS-Konfiguration:
Protokollattribut-Einstellungen können nicht auf die tatsächliche MTE-Klasse 'Leistungsattribut' angewendet werden.

    MTE-Attribute werden im zweiten Reiter des MTE-Eigenschaftsbildschirms in RZ20 angezeigt. Siehe auch Image: CCMS MTE with performance attribute

    Bitte beachten Sie, dass es MTEs ohne Attribut gibt, wie "Überwachungsobjekte" und "Zusammenfassungsknoten". Für diese Arten von MTEs können Sie dennoch die General Properties konfigurieren. Einstellungen für Attribute Properties bei MTEs ohne Attributtyp werden einfach ignoriert.

  4. Falls gewünscht, aktivieren Sie das Kontrollkästchen Use for individual MTE. Siehe auch CCMS Configuration for individual MTE.

  5. Drücken Sie die Schaltfläche Update Custom Check, um Ihre Einstellungen zu speichern.

Überprüfen Sie, ob die konfigurierten CCMS-Einstellungen korrekt auf Ihr SAP System angewendet wurden. Bei Problemen konsultieren Sie zuerst die check message im RealTime Monitoring. Wenn Sie eine Fehlermeldung finden:

XAL Schnittstellenfehler: Keine weiteren Informationen verfügbar
(Funktion BAPI_SYSTEM_MTE…)

oder keine Fehlermeldung finden, die Einstellungen aber nicht in CCMS gespeichert wurden, müssen Sie möglicherweise Hotfixes oder die neuesten Support-Pakete auf Ihr SAP System anwenden. Siehe auch SAP-Hinweis 798941 BAPI XAL funktioniert nach Hinweis 778056 nicht vollständig.

Erweiterung durch Business Services und Composite Checks

Einführung in Business Services und Composite Checks

HINWEIS: Diese Funktion ist nur in den Editionen Avantra Observability, Cloud und Enterprise verfügbar. Weitere Informationen zu den Editionen finden Sie in der Avantra Editions Matrix.

Composite Checks und Business Services sind Werkzeuge, mit denen Sie neue RealTime Monitoring Checks basierend auf vorhandenen integrierten Checks, Custom Checks oder sogar anderen Composite Checks oder Business Services erstellen können.

Jeder Composite Check und jeder Business Service besteht aus einem oder mehreren eingehenden Checks und einer Bewertungsregel, die ein ausgehendes Check Result basierend auf dem eingehenden check status liefert.

Die eingehenden Checks können beliebige vorhandene RealTime Monitoring Check oder ein System Status sein. Sie können mit einer konfigurierbaren Verzögerung verschoben werden.

Unterschiede zwischen Business Services und Composite Checks

Die Unterschiede zwischen diesen beiden Kategorien sind:

Bausteine für Business Services und Composite Checks

Allgemeine Eigenschaften

Composite Checks und Business Services haben die folgenden allgemeinen Eigenschaften:

Name

Ein eindeutiger Name für den Composite Check oder Business Service.

Beschreibung

Eine aussagekräftige Beschreibung des Composite Check oder Business Service.

Service Name

Sie können die Service Availability für den Check aufzeichnen und einen aussagekräftigen Namen angeben. Sie können auch entscheiden, ob ein ausgehender check status Warning als Up betrachtet wird.

Input Scope

Dieser Customer definiert den Geltungsbereich für den Composite Check oder Business Service. Nur Systems, die zu diesem Customer gehören, können in diesem Composite Check oder Business Service verwendet werden. Und nur Benutzer, die Permissions für diesen Customer haben, dürfen diesen Composite Check oder Business Service anzeigen oder bearbeiten.

Beachten Sie, dass eine Customer-Hierarchie bei der Auswahl von Systems für den Composite Check oder Business Service berücksichtigt wird.

Ein User muss die Permission View Composite Checks and Business Services / Edit Composite Checks and Business Services für den benannten Customer haben, um den Composite Check oder Business Service anzeigen oder bearbeiten zu können.

Rolle (Business Service nur)

Ein Rollenname mit derselben Bedeutung wie System Role.

Zuweisung an Kunde (Business Service nur)

Das Prüfergebnis des Business Service wird diesem Customer zugewiesen. Der Ergebnisstatus des Business Service ist im RealTime Monitoring sichtbar.

Systembereich

(nur Composite Checks)

Sie können eine Dynamic Group oder Static Group von Systems definieren, für die der Composite Check ausgeführt wird.

Der System Scope ist auf die Systems und Checks der definierten Customers beschränkt, oder auf alle Customers, wenn kein Customer definiert ist (Composite Check) oder wenn das All Customers-Flag gesetzt ist (Business Service).

Die Definition des Systembereichs erfolgt mithilfe von System Selectors (siehe Defining a System Selector).

Funktionen

Funktionen definieren die Regel, wie ein Composite Check oder ein Business Service eingehende check status in einen ausgehenden check status auswertet. Es gibt vier Funktionstypen, die verschachtelt werden können.

All OK

Gibt Ok zurück, wenn alle eingehenden check statuse Ok sind (ansonsten Critical).

One OK

Gibt Ok zurück, wenn mindestens ein eingehender check status Ok ist (ansonsten Critical).

Worst

Gibt Critical zurück, wenn mindestens ein Eingang Critical ist, Warning - wenn mindestens ein Eingang Warning ist, Unknown - wenn mindestens ein Eingang Unknown ist (ansonsten Ok).

Expresso

Vereinfacht gesagt, gibt die Expresso-Funktion {Ok}, wenn _n von m eingehenden check statusen Ok sind. Genauer gesagt bietet sie die Möglichkeit, eine Wenn-Dann-Konstrukt zu erstellen, das den ausgehenden check status anhand von Vergleichsoperatoren und Grenzen für den eingehenden check status berechnet.

Script

Ermöglicht es, nahezu jede Bedingung zu definieren, um den ausgehenden check status basierend auf dem eingehenden check status zu berechnen.

Delay

Ermöglicht es Ihnen, den eingehenden Check Result nur für eine definierte Zeit zu verzögern.

Alle Funktionen bieten die folgenden gemeinsamen Attribute:

Name

Ein eindeutiger Name (innerhalb des Composite Check oder Business Service), um die Funktion zu identifizieren.

Beschreibung

Eine aussagekräftige Beschreibung der Funktion.

Verzögerung

Eingehende check status können verzögert werden, zum Beispiel kann ein eingehender Critical als Ok betrachtet werden, es sei denn, er bleibt länger als 10 Minuten Critical.

Ergebnismeldung

Standardmäßig werden die check messages der eingehenden Checks für die ausgehende check message verwendet. Sie können jedoch die Weitergabe der eingehenden check messages unterdrücken oder eine eigene check message für die Funktion definieren.

Selektoren

System Selectors bieten die Möglichkeit, eingehende Systems und die entsprechenden Checks dynamisch für die Verwendung in Funktionen auszuwählen. Um einen eingehenden System Status zu verwenden, wählen Sie ein oder mehrere Systems aus. Für eingehende check status wählen Sie ein oder mehrere Checks aus.

Jeder Selektor besteht aus einem Namen und einer Beschreibung, um ihn im Kontext des Composite Check oder Business Service zu identifizieren. Es ermöglicht Ihnen, verschachtelte Suchkriterien zu definieren und die Option, das System mit deaktiviertem Monitoring einzubeziehen oder nicht.

Wenn Sie (eingehende) RealTime Monitoring Checks anstelle des System Status verwenden möchten, können Sie diese ebenfalls auswählen.

System Selectors sind auf den System Scope oder den Input Scope beschränkt.

Direkte Eingabe von Checks oder Systemen

Anstatt die eingehenden Checks dynamisch mit System Selectors zu definieren, können Sie auch Checks oder Systems als direkte Eingabe für eine Funktion hinzufügen.

Checks oder Systems sind auf den System Scope oder den Input Scope beschränkt.

Entwerfen, Testen, Überprüfen, Evaluieren, Aktivieren

Es gibt ein Design-Fenster, in dem Sie alle Dinge zusammenfügen und die erforderlichen Eigenschaften bearbeiten können. Für die System Selectors gibt es eine Test-Funktion, die das Ergebnis einer dynamischen Suche anzeigt. Sobald Sie alle Elemente zusammengefügt haben, können Sie den gesamten Composite Check oder Business Service überprüfen. Dies ist in erster Linie eine Integritätsprüfung, um Sie auf fehlende oder inkonsistente Setups hinzuweisen.

Anschließend haben Sie die Möglichkeit, den Composite Check oder Business Service zu evaluieren, d. h. den Check mit allen aktuellen eingehenden check status auszuführen.

Schließlich müssen Sie den gesamten Check aktivieren, um ihn regelmäßig zu bewerten.

Definieren von Business Services

Führen Sie die folgenden Schritte aus, um einen neuen Business Service zu definieren:

Procedure: Definieren eines Business Services

  1. Wählen Sie Configuration  Business Services aus dem obersten Menü und drücken Sie New Business Service.

  2. Geben Sie einen Namen für den Business Service ein, wählen Sie einen Customer aus und drücken Sie die Create-Taste.

  3. Wählen Sie den neu erstellten Eintrag aus der Liste und wählen Sie Open. Der Reiter Properties öffnet sich.

    Wählen Sie eine System Role aus den Dropdown-Listen.

    Der Wert des Customer definiert nur, welchem Check der entsprechende Business Service zugeordnet ist. Es schränkt auch die Auswahl der eingehenden Checks auf diesen Customer ein, es sei denn, das All Customers-Flag ist ebenfalls gesetzt.

  4. Wenn Sie Service Availability-Daten für diesen Business Service aufzeichnen möchten, setzen Sie ein Häkchen neben Enter Service Name to record Availabilities.

    Standardmäßig ist der Servicename derselbe wie der Name des Business Service, aber Sie haben die Möglichkeit, ihn zu ändern.

    Setzen Sie das Häkchen bei Report Warning as Available, wenn ein Warning Business Service als Up betrachtet werden soll.

  5. Geben Sie eine Description ein.

  6. Wenn Sie Systems und Checks aus anderen Customer als dem ausgewählten einbeziehen möchten, setzen Sie das Häkchen bei All Customers.

    Nur die Users, die über die Permission View Composite Checks and Business Services / Edit Composite Checks and Business Services für alle in diesem Feld aufgeführten Customers verfügen, können den Business Service anzeigen/bearbeiten.

  7. Drücken Sie Save. Ignorieren Sie das Pop-up, setzen Sie den Business Service noch nicht aktiv.

  8. Wählen Sie den Reiter Design.

  9. Wählen Sie eine der Functions aus und ziehen Sie sie in das Feld mit der Bezeichnung Business Service: <business_service_name>. Ein neues Feld mit dem Funktionstyp erscheint. Wählen Sie das neue Feld aus. Das Paneel Properties erscheint.

  10. Füllen Sie die Funktionseigenschaften aus:

    1. Geben Sie einen Name und eine Description im Abschnitt Function Details des Paneels Properties ein.

    2. Wenn Sie die Weitergabe von check status verzögern möchten, setzen Sie das Häkchen bei Activate Deferral im Abschnitt Deferral des Paneels Properties.

      Die Verzögerungsregeln werden angewendet, nachdem die Funktion ausgewertet wurde. Für jeden check status können Sie definieren, wie lange er als ein anderer check status betrachtet werden soll.

      Wählen Sie einen Wert aus der Liste Deferral Value (d. h. der bewertete check status), den Sie verzögern möchten, geben Sie einen Wert (in Minuten) in During ein und wählen Sie einen Wert aus der Liste To. Verwenden Sie die Schaltflächen und , um Verzögerungsregeln hinzuzufügen oder zu entfernen.

    3. Sie können eine Result Message für die Funktion definieren. Standardmäßig wird keine Ergebnismeldung weitergegeben. Sie können wählen, ob eine generierte Ergebnismeldung als check message weitergegeben werden soll. Oder Sie definieren Ihre eigenen Nachrichten für jeden möglichen check status.

      Wenn Sie keine Ergebnismeldung weitergeben möchten, deaktivieren Sie das Häkchen neben Send Result Message to Parent.

    4. Drücken Sie die Apply-Taste oben im Paneel Properties.

  11. Wenn Sie eine weitere Funktion als eingehend für die gerade erstellte Funktion hinzufügen möchten, ziehen Sie den entsprechenden Typ auf die neu erstellte Funktion und wiederholen Sie Schritt 10.

  12. Fügen Sie eingehende Checks entweder mithilfe von Check Selectors, System Selectors (d. h. verwenden Sie den System Status), oder direkt hinzu. Natürlich können Sie auch diese Methoden mischen:

    Using Check Selectors

    1. Ziehen Sie den entsprechenden Check Selector (d. h. RTM, Daily Check Detail oder Daily Check) auf die Funktion, für die Sie den eingehenden System Status definieren möchten. Ein neues Feld mit der Bezeichnung des Selectortyps erscheint. Wählen Sie das neue Feld aus. Das Selector-Paneel erscheint.

    2. Füllen Sie einen Name und eine Description im Selector-Paneel aus.

    3. Setzen Sie das Häkchen neben 'Check' search criteria, um die Suchkriterien zu definieren.

      Wählen Sie ein Kriterium aus der Dropdown-Liste aus. Wählen Sie oder füllen Sie die entsprechenden Werte aus.

      Sie können weitere Kriterien hinzufügen, indem Sie sie einfach aus der Liste auswählen. Alle ausgewählten Kriterien werden mit logischem UND kombiniert, d. h. nur diejenigen Checks, die alle Kriterien erfüllen, werden vom Check Selector zurückgegeben.

    4. Wenn Sie den Check Selector mit einem System Selector kombinieren möchten, aktivieren Sie die Option Define systems to select check from und definieren Sie einen System Selector (siehe unten).

    5. Sie können auch wählen, eine generierte Ergebnismeldung an die übergeordnete Funktion weiterzugeben.

    6. Drücken Sie die Apply-Taste. Anschließend können Sie die Test-Taste drücken, um Ihren Check Selector zu überprüfen.

    Using System Selectors

    1. Ziehen Sie die entsprechenden Selectors auf die Funktion, für die Sie den eingehenden System Status definieren möchten. Ein neues Feld mit der Bezeichnung des Selectortyps erscheint. Wählen Sie das neue Feld aus. Das Selector-Paneel erscheint.

    2. Füllen Sie einen Name und eine Description im Selector-Paneel aus.

    3. Setzen Sie das Häkchen neben '<system_type>' search criteria, um dynamische Suchkriterien zu definieren.

      Wählen Sie ein Kriterium aus der Dropdown-Liste aus. Wählen Sie oder füllen Sie die entsprechenden Werte aus.

      Sie können weitere Kriterien hinzufügen, indem Sie sie einfach aus der Liste auswählen. Alle ausgewählten Kriterien werden mit logischem UND kombiniert, d. h. nur diejenigen Systems, die alle Kriterien erfüllen, werden von den Selectors zurückgegeben.

    4. Wenn Sie verschachtelte Kriterien hinzufügen möchten, setzen Sie das Häkchen neben '<nested_system_type>' search criteria und wiederholen Sie den vorherigen Schritt.

    5. Standardmäßig umfassen die System Selectors nur Systems, bei denen das Monitoring aktiviert ist. Wenn Sie auch Systems mit deaktiviertem Monitoring einbeziehen möchten, setzen Sie das Häkchen bei Include Systems with Monitoring turned off.

    6. Verwenden Sie die Option Select Checks nicht mehr. Sie ist veraltet und wurde durch Check Selectors ersetzt. Die Option ist nur noch aus Kompatibilitätsgründen verfügbar und könnte in zukünftigen Versionen entfernt werden.

    7. Sie können auch wählen, eine generierte Ergebnismeldung an die übergeordnete Funktion weiterzugeben.

    8. Drücken Sie die Apply-Taste. Anschließend können Sie die Test-Taste drücken, um Ihre Selectors zu überprüfen.

    Direct Input

    1. Ziehen Sie das entsprechende System (für einen eingehenden System Status) oder einen Check aus dem Baum Input Systems/Checks auf die Funktion, für die Sie den eingehenden check status definieren möchten. Ein neues Feld mit der Bezeichnung des System und Check erscheint. Wählen Sie das neue Feld aus. Das Properties-Paneel erscheint. Sie können das Suchfeld über der Baumansicht verwenden, um einen Check schneller zu finden.

    2. Geben Sie einen Name für die Server Details oder Check Details ein.

    3. Sie können eine Result Message definieren. Standardmäßig wird keine Ergebnismeldung weitergegeben. Sie können wählen, die eingehende check message weiterzugeben. Oder Sie definieren Ihre eigenen Nachrichten für jeden möglichen check status.

    4. Drücken Sie die Apply-Taste.

  13. Wiederholen Sie die vorherigen Schritte, bis Sie alle Funktionen, System Selectors oder direkten Checks hinzugefügt haben.

  14. Drücken Sie die Verify-Taste, um den Business Service auf Konsistenz und Vollständigkeit zu überprüfen. Die Überprüfungsergebnisanzeige erscheint am unteren Rand und enthält eine Liste von Problemen, von denen jedes eine Schweregradstufe (OK, WARNING oder ERROR) und eine Show-Taste aufweist. Stellen Sie sicher, dass Sie zumindest die Probleme mit dem Schweregrad WARNING und ERROR beheben.

  15. Drücken Sie die Evaluate-Taste, um den Business Service mit Echtzeitdaten zu bewerten. Das Ergebnis sieht wie im folgenden Bild aus:

    bs evaluation design

    Sie können auf das Dreieck klicken, um weitere Details anzuzeigen. Sie können sogar die berechneten Werte (in den Value-Feldern) für Debugging-Zwecke überschreiben und erneut bewerten.

    Es gibt auch detailliertere Informationen im Verification Results-Paneel am unteren Rand der Seite.

  16. Drücken Sie die Save-Taste. Ein Pop-up fragt Sie, ob Sie den Business Service jetzt aktivieren möchten. Wenn ja, setzen Sie das Häkchen bei Set Business Service to active und drücken Sie die OK-Taste. Andernfalls drücken Sie nur die OK-Taste.

    Sobald der Business Service aktiviert ist, wird er regelmäßig bewertet und im RealTime Monitoring angezeigt.

Sie benötigen die Permission View Composite Checks and Business Services, um einen Business Service anzuzeigen, und die Permission Edit Composite Checks and Business Services, um einen Business Service zu ändern oder zu löschen.

Defining Composite Checks

Führen Sie die folgenden Schritte aus, um einen neuen Composite Check zu definieren:

  1. Wählen Sie Configuration  Composite Checks aus dem Hauptmenü.

  2. Drücken Sie die Taste New Composite Check und geben Sie einen Namen für den Composite Check ein.

  3. Wählen Sie einen Customer.

Nur Systems dieses Customer (und seine Nachkommen, falls eine Customer-Hierarchie verwendet wird) werden berücksichtigt. Ein User benötigt die Permission View Composite Checks and Business Services / Edit Composite Checks and Business Services für den angegebenen Customer, um den Composite Check anzuzeigen oder zu ändern.

Wenn Sie den Kunden auf den Root-Kunden setzen, werden Systems aller Customers berücksichtigt.

  1. Wählen Sie einen System Type. Drücken Sie die Create-Taste.

  2. Wählen Sie den neu erstellten Eintrag aus der Liste und wählen Sie Open. Die Properties-Registerkarte wird geöffnet.

  3. Wenn Sie Service Availability-Daten für diesen Composite Check erfassen möchten, setzen Sie ein Häkchen neben Enter Service Name to record Availabilities.

    Standardmäßig ist der Service Name derselbe wie der Composite Check Name, aber Sie haben die Möglichkeit, ihn zu ändern. Setzen Sie das Häkchen bei Report Warning as Available, wenn ein Warning Composite Check als Up betrachtet werden soll.

  4. Füllen Sie eine Description aus.

  5. Drücken Sie Save. Ignorieren Sie das Pop-up, setzen Sie den Composite Check noch nicht aktiv.

  6. Wählen Sie die Registerkarte Scope, um die Gruppe von Systems zu definieren, auf denen der Composite Check ausgeführt werden soll.

  7. Setzen Sie das Häkchen neben '<system_type>' search criteria, um dynamische Suchkriterien zu definieren.

    Wählen Sie ein Kriterium aus der Dropdown-Liste aus. Wählen Sie oder füllen Sie die entsprechenden Werte aus.

    Sie können weitere Kriterien hinzufügen, indem Sie sie einfach aus der Liste auswählen. Alle ausgewählten Kriterien werden mit logischem UND kombiniert, d. h. nur diejenigen Systems, die alle Kriterien erfüllen, werden von den Selectors zurückgegeben.

Wenn Sie verschachtelte Kriterien hinzufügen möchten, setzen Sie das Häkchen neben '<nested_system_type>' search criteria und wiederholen Sie den vorherigen Schritt.

  1. Drücken Sie die Test-Taste, um Ihre Scope-Auswahl zu überprüfen.

  2. Drücken Sie Save. Ignorieren Sie das Pop-up, setzen Sie den Composite Check noch nicht aktiv.

  3. Wählen Sie die Registerkarte Design und fahren Sie wie ab Schritt 9 des Procedure: Defining a Business Service beschrieben fort.

Sie benötigen die Permission View Composite Checks and Business Services, um einen Composite Check anzuzeigen, und die Permission Edit Composite Checks and Business Services, um einen Composite Check zu ändern oder zu löschen.

Erweiterung durch extern verwaltete Checks

HINWEIS: Diese Funktion ist nur in den Editionen Avantra Observability, Cloud und Enterprise verfügbar. Weitere Informationen zu den Editionen finden Sie in der Avantra Editions Matrix.

Extern verwaltete Checks sind eine Alternative zu Custom Checks, um benutzerdefinierte Check-Daten in Avantra zu übermitteln. Sie unterscheiden sich von Custom Checks wie im folgenden Abschnitt beschrieben.

Unterschied zwischen benutzerdefinierten Checks und extern verwalteten Checks

Benutzerdefinierte Checks werden vom Avantra Agent ausgeführt, während extern verwaltete Checks von einem externen Auslöser in Avantra übermittelt werden. Benutzerdefinierte Checks arbeiten mit einem Pull-Konzept, d. h. der Avantra Agent ruft aktiv das Check Result ab.

Custom Checks können als Daily Checks ausgeführt werden, während extern verwaltete Checks nur in RealTime Monitoring übermittelt werden können.

Es gibt viele verschiedene Arten von benutzerdefinierten Checks; sie können als Werkzeugkasten betrachtet werden. Es gibt jedoch nur zwei Arten von extern verwalteten Checks: External Status und External Event. Diese werden unten beschrieben.

Aus Netzwerksicht können extern verwaltete Checks von jedem Netzwerkstandort, der Zugang zu Avantra WebUI hat, übermittelt werden, entweder direkt über den Web Service von Avantra WebUI oder über die Befehlszeilenausführungsdatei, die für den Zugriff auf den Web Service bereitgestellt wird.

Die externe Quelle muss sicherstellen, dass die Namen der extern verwalteten Checks innerhalb der Avantra-Installation eindeutig sind. Es kann sinnvoll sein, eine Art Namenskonvention zu verwenden.

Arten von extern verwalteten Checks

Es gibt zwei Arten von extern verwalteten Checks, External Status und External Event. Beide Typen haben einen check status und eine check message; Letztere kann entweder reiner Text oder HTML sein. Der Typ External Status wird auf die gleiche Weise wie andere Checks in Avantra behandelt: Er bleibt in seinem check status, bis sich der Status ändert. Wenn der check status aktualisiert wird, werden der vorherige check status und die Nachricht in die RealTime Monitoring-Historie geschrieben. Der externe Auslöser ist allein verantwortlich dafür, dass der Check aktualisiert wird.

Ein Event Status Check wird auf Unknown gesetzt, wenn innerhalb von 90 Minuten keine Aktualisierung erfolgt. Dies verhindert, dass ein Check einen Status widerspiegelt, der nicht mehr aktuell ist.

Der External Event hat ebenfalls einen check status und eine check message, die bei der Erstellung angegeben werden müssen. Ein External Event Check kann jedoch nicht mehr aktualisiert werden und es wird keine Historie geführt. Er wird nach 60 Minuten oder nach einem bei der Erstellung festgelegten Zeitraum automatisch gelöscht.

Um sicherzustellen, dass ein External Event vom Notification-Management verarbeitet werden kann, beträgt die minimale Ablaufzeit 5 Minuten, auch wenn kleinere Werte definiert werden.

Verwendung von Avantra CLI zum Übermitteln von extern verwalteten Checks

Avantra CLI ist ein Programm zur Interaktion mit dem Avantra Web Service. Es enthält einen Befehl zum Übermitteln von extern verwalteten Checks. Siehe auch How to use the Avantra Web Service by Command Line Executable.

Siehe unten Beispiele, wie avantra aufgerufen werden kann, um extern verwaltete Checks zu übermitteln.

Um das System eindeutig zu identifizieren, das die externen Checks erhält, wird die Avantra System-ID benötigt. Diese kann im Detailbereich des Systems in Avantra WebUI eingesehen oder mit dem Befehl avantra ls -l [system-type] abgerufen werden.
Übermitteln eines externen Status Check Result mit dem Check-Status OK
avantra extern-status -id 42 -status OK -name "My External Check"
-message "See how I can push results to Xandria RTM"
Übermitteln eines externen Status-Check-Ergebnisses mit dem Check-Status Warning und HTML-Check-Nachricht
avantra extern-status -id 42 -status WARNING -name "My External Check" -message "<html><body><h1>See the Result as Heading</h1></body></html>"
Übermitteln eines externen Event-Check-Ergebnisses mit dem Check-Status Critical und einer Ablaufzeit von 30 Minuten
avantra extern-event -id 42 -status 1 -expiry-time 30 -name "My External Event" -message "This event based check will be automatically deleted after 30 min"

Sie benötigen die Permission Edit Systems, um extern verwaltete Checks zu erstellen und zu aktualisieren.