Die V12 ist inzwischen schon ein paar Monate alt und nach meiner Zusammenfassung und der ausführlichen Beschreibung der V12 Analytics und des Zero Downtime Upgrades möchte ich Ihnen in diesem Artikel ein weiteres neues Feature vorstellen: den Service Level Manager und den dazugehörigen Objekttyp SLO (Service Level Objective).
Kennen Sie bereits den Automic Service Orchestrator? Dann ist der SLM nichts besonders Neues für Sie. Denn beide machen ungefähr das Gleiche. Aber der SLM ist direkt in Automic integriert und muss nicht gesondert lizenziert werden. Der Service Level Orchestrator dagegen war nur als Add-On verfügbar.
Wozu brauchen Sie SLM?
Beim SLM geht es um die zentrale Überwachung von ausführbaren Objekten. Es ist eine zusätzliche Möglichkeit, Tasks zu überwachen und auf Ereignisse wie Fehlschläge und zu lange Laufzeiten zu reagieren.
Wie funktioniert der SLM?
SLM steht nur im AWI zur Verfügung. Zwei Komponenten machen den SLM aus:
- die Definition der Überwachung mit Hilfe des neuen Objekttyps SLO
(Service Level Objective) - die Überwachung von Services in der AWI-Perspektive Process Monitoring
Der neue Objekttyp SLO
Objekte vom Typ Service Level Objective dienen dazu, die Überwachung zu definieren.
Sie können so viele SLO Objekte anlegen, wie Sie wollen. Das geht über die Perspektive Process Assembly, also über den Explorer, oder wahlweise auch über die Perspektive Administration, in der es einen eigenen Abschnitt Service Level Objectives gibt.
Jedes SLO-Objekt besteht aus drei Teilen:
Teil 1: Die Überwachungseinstellung
Hier stellen Sie ein, ob dieses Service überhaupt überwacht werden soll – und wenn ja, wann.
Sie finden diese Einstellung unter Service Level Objective im SLO Objekt (siehe Screenshot).
Teil 2: Die Service-Auswahl
Hier definieren Sie, welche ausführbaren Objekte dieses Service ausmachen. Sie können also mehrere ausführbare Objekte zu einem Service gruppieren.
Dazu wählen Sie zwischen zwei Bereichen:
- Service Beneficiaries (Service Begünstigte)
- Service Selection (Service Auswahl)
Die Service Beneficiaries sind optional, Sie könnend diese auch leer lassen. Darauf komme ich aber später noch einmal zurück.
Bei der Service Selection können Sie viele Filter setzen und diese Filter gruppieren. Damit schränken Sie ein, welche ausführbaren Objekte zu dieser Service-Definition hinzugefügt werden.
In diesem Beispiel wähle ich alle Jobs und Filetransfers, die entweder “WIN” oder “FTP” im Namen haben.
Beachten Sie dabei: Wenn Sie das Monitoring in einem SLO-Objekt aktivieren, muss dieses zumindest einen Filter für Object Type oder einen Filter für Object Name haben.
Sollte das nicht der Fall sein, erhalten Sie beim Speichern des Objektes eine Fehlermeldung, die glücklicherweise sehr aussagekräftig ist und Ihnen genau sagt, was Sie falsch gemacht haben.
Der Grund dafür: Das SLM wird vom JWP abgearbeitet und der WP muss den JWP triggern, wenn ein relevantes Objekt (also ein Objekt, das Teil einer Service-Überwachung ist) startet und/oder endet. Die Definition, für welche Objekte der WP den JWP triggert, basiert auf Mandant, Objettyp-Filter und Objektname-Filter.
Bei den Service Beneficiaries handelt sich einfach nur um Custom Attributes. Sie können also Ihre ausführbaren Objekte auf die verwendeten Custom Attributes filtern.
Der Filter berücksichtigt nur Objekte mit Custom Attributes, wo Business Unit entweder Finance oder Human Ressources ist.
Teil 3: Das Erfüllungskriterium
Hierbei definieren Sie zwei Dinge:
Erstens, wann Ihr Service Level als erfüllt gilt. Sie definieren einen Zustand. Alle ausführbaren Objekte, auf die der Filter zutrifft, den Sie zuvor unter “Service Selection” definiert haben, sollen diesen Zustand erreichen.
Und zweitens, welche Aktion durchgeführt werden soll, wenn das Service Level erfüllt oder verletzt wird.
Bei der Definition des Soll-Zustandes können Sie Laufzeitkriterien, den Endstatus, die späteste Startzeit und die späteste Endzeit definieren. Jede Kombination dieser Kriterien ist möglich.
Für alle SLO-Objekte, bei denen Sie die Überwachung aktiviert haben, werden die Ereignisse erfüllt und verletzt im Abschnitt Services in der Process Monitoring Perspektive mitgeloggt.
Diese Ereignisse werden auch an V12 Analytics übertragen, d. h. Sie können diese Daten auch in Analytics Dashboards auswerten.
Fazit zum Service Level Manager
In meinen Augen ist die Integration des SLM in Automic V12 ein sehr guter Schritt. Damit wird Automic mittelfristig den Automic Service Orchestrator komplett ablösen.
Wenn Sie sich noch weiter zum SLM informieren wollen, schauen Sie sich doch das Video von Automic an und lesen Sie in der Dokumentation zur V12 genauer nach, wie es funktioniert.
Soll ich noch ein oder mehrere andere Feature der V12 vorstellen? Dann schreiben Sie mir dazu doch einfach einen Kommentar.