Sie kennen sicherlich die Problemstellungen komplexer Service-Umgebungen, deren Verwaltung und Überwachung. In der Praxis setzen sich Service-Umgebungen aus Hardware- und Softwarekomponenten zusammen, die miteinander interagieren und Dienste bereitstellen.
Durch die Vielzahl der Services und deren Verknüpfungen entsteht sehr schnell ein unübersichtliches Bild der Servicelandschaft in einem Unternehmen. Der Übergang von der Implementierung eines Services in den täglichen Betrieb gestaltet sich in der Praxis häufig langwierig und schwierig. Zudem werden Entwicklungsressourcen für die Installation und Überwachung von Services gebunden. Die Administratoren hingegen fühlen sich von den Programmierern alleine gelassen, weil unzureichende Installations- und Betriebsdokumente an das Betriebsteam übergeben werden, aus denen in der Regel nicht die Abhängigkeiten der Services hervorgehen.
Würde es nicht allen Beteiligten in der Service-Umsetzung und -Administration helfen, wenn ein graphischer Serviceplan mit den Softwarekomponenten und deren Verknüpfungen an den Betrieb zur Installation und Wartung der Services übergeben würde? Wäre es darüber hinaus nicht einfacher für die Administratoren, wenn die Services über eine graphische Benutzeroberfläche verwaltet und überwacht werden könnten?
Wären nicht alle Beteiligten entlastet und könnten sich um ihre eigentlichen Aufgaben kümmern. Der Programmierer könnte weiter seine Software erstellen ohne Unterbrechungen durch Probleme, die sich durch den produktiven Betrieb der Services ergeben. Der Administrator könnte seine Service-Landschaft pflegen ohne den Überblick zu verlieren. Im Fehlerfall ist durch die Analysemöglichkeiten des Service Managers eine qualifizierte Fehlerursachenermittlung möglich, sodass die Administratoren Fehlermeldungen gezielt melden und gegenüber der Entwicklungsabteilung darstellen können. Sind das nicht die optimalen Voraussetzungen für den reibungslosen Betrieb von Services in einem Unternehmen?
Welche Voraussetzungen müsste eine Servicemanagementsoftware zur Problemlösung erfüllen?
Sicherlich benötigt man einen interaktiven graphischen Editor zum Entwurf eines Servicenetzwerkes. Neben der Beschreibung des Netzwerkes benötigt man eine detaillierte nach Hardware- und Software-Services getrennte Dokumentation. Ein Reportmodul wäre hilfreich, um das Servicenetzwerk und Detailinformationen protokollieren und ausdrucken zu können. Die Integration der Skripte für die Installation und Deinstallation von Services mit der Möglichkeit per Knopfdruck einen Service zu installieren oder zu deinstallieren würde helfen. Die Anzeige von Fehlern zur Laufzeit eines Services ist nicht nur nützlich, sondern zwingend erforderlich, um auf Fehlersituationen im Betrieb schnell und qualifiziert reagieren zu können.
 |
| Serviceplanentwurf |
Der Service Manager 2.0 erfüllt die Anforderungen an eine moderne Servicemanagementanwendung und ist ein hilfreiches Werkzeug für die Konzeption und den Betrieb von Servicenetzwerken.
Mit dem Service Manager konzipiert man einen Serviceplan und stellt in Form eines Netzwerkes zunächst die Abhängigkeiten zwischen den einzelnen Services dar. In der Detailansicht eines Services trägt man die Serviceparameter ein. An dieser Stelle können auch weiterführende Informationen zum Personenkreis des administrativen Teams und der Alarmdelegierung per E-Mail und/oder SMS hinterlegt werden.
Alarme werden im Serviceplan gekennzeichnet und in der Servicedetailansicht angezeigt, sodass ein Alarm direkt einem Service zugeordnet werden kann. Das Überwachen von Services wird durch den Service Manager optimal unterstützt. Alarmmeldungen werden sofort durch die graphische Visualisierung erkannt, sodass sehr kurze Reaktionszeiten im Störfall möglich sind. Der Service-Überwacher setzt sich nach dem Lesen der Alarmmeldung mit dem Servicebetreiber in Verbindung und führt geeignete Maßnahmen zur Beseitigung des Störfalls durch. Alarmmeldungen werden über eine definierte Schnittstelle an die Servicemanagementanwendung übermittelt.
 |
| Serviceplanüberwachung |
Die Schnittstelle für die Übermittlung von Alarmen ist offen und erweiterbar gestaltet. Als Protokoll für die Alarmübermittlung wird das JMS Protokoll unterstützt. Mit Gateways können andere Protokolle (RMI, IIOP, etc.) in die Servicemanagementanwendung integriert werden. Ein Gateway für Log4J, in dem die Protokoll-Levels auf die Alarme des Servicemanagers abgebildet werden, liegt als Schablone für die Nutzung der Programmierschnittstelle des Service Managers bei. Die Integration von Anwendungen, die überwacht werden sollen und einen Framework zum Protokollieren verwenden, ist in kürzester Zeit möglich. In den zu überwachenden Anwendungen sind an zentraler Stelle nur wenige Zeilen Quellcode für die Alarmdelegierung an den Service Manager einzufügen.
Der Service Manager ist eine moderne, standardkonforme Java EE 6 Applikation, die auf den gängigen Applikationsservern betrieben werden kann. Die bevorzugte Laufzeitumgebung der serverseitigen Geschäftslogik ist der GlassFish v3 Applikationsserver und eine Oracle 10g Datenbank. Die für das Servicemanagement relevanten Daten werden über einen allgemeinen Datenbankservice in die Datenbank geschrieben. Die Datenanlieferung mit Hilfe eines Service Manager Gateways erfolgt für den Alarmfall queuebasiert. Die Verteilung der Daten des Service Manager Servers an die Servicemanagement-Klienten ist mit einem JMS Layer realisiert.
Der Service Manager Analyzer für Alarmanalysen ist in den Service Managers integriert, sodass eine gezielte Fehlersuche im Nachgang einer Alarmfolge erfolgen kann. Der Analyzer unterstützt die Navigation in einem zuvor definierten Zeitbereich und die Animation einer Alarmkette zur Bildung eines Alarmbildes für die gezielte Suche von Fehlerursachen. Der Analyzer erlaubt es erstmals im Team ein Alarmbild aufzubauen, zu animieren und in einer gemeinsamen Diskussion die Fehlerursache zu lokalisieren.
Die Filtermöglichkeiten im Analyzer reduzieren die Suchmenge der Alarme, um gezielt Alarmbilder aufbauen zu können. Die Benutzeroberfläche des Klienten der Servicemanagementanwendung unterstützt umfangreiche graphische Funktionen für den Entwurf und die Verwaltung von Serviceplänen. Die Benutzeroberfläche ist mit Java SE 6 (Java Swing) programmiert und unterstützt unterschiedliche Oberflächenprofile, sodass der Benutzer die Benutzerschnittstelle nach seinen eigenen Bedürfnissen anpassen kann.
 | |
| Serviceplananalyse |
Die Verwendung der Service Manager Gateway Programmierschnittstelle in eigenen Applikationen ist sehr einfach. Eine Applikation, die Log4J verwendet, spricht über das Service Manager Gateway die Service Manager Applikation im Monitormodus an. Alarmmeldungen können auf diese Weise an den Service Manager übermittelt werden. Es ist lediglich an zentraler Stelle der Service Manager Kontext zu initialisieren, damit alle Log4J-Meldungen zusätzlich zu den Log-Ausgaben in Dateien an den Service Manager gesendet und dort im Monitormodus visualisiert werden.
Integration der Gateway-Schnittstelle in eine Applikation:
import org.apache.log4j.Logger;
import com.service.manager.api.gateway.annotation.ServiceManagerGateway;
import com.service.manager.api.gateway.context.ServiceManagerGatewayContext;
@ServiceManagerGateway(
servicePlanId="SERVICEPLAN:12cdbde2b0e1363aae059842e3235b05409",
serviceNodeId="SERVICE:12cdbeb342f13634ebd8cf32e32351b66f82")
public class GatewayApplication {
static {
ServiceManagerGatewayContext.newContext(GatewayApplication.class);
}
private static Logger log = Logger.getLogger(GatewayApplication.class);
public static void main(String args[]) {
log.error("Der Datenbanklistener ist nicht verfügbar!");
log.fatal("Die Datenbankverbindung ist unterbrochen worden!");
}
}
private static Logger log = Logger.getLogger(GatewayApplication.class);
public static void main(String args[]) {
log.error("Der Datenbanklistener ist nicht verfügbar!");
log.fatal("Die Datenbankverbindung ist unterbrochen worden!");
}
}
Anmerkung zum Common Base Event Format:
Das Service Manager Gateway Software Development Kit (SDK) gestattet es, eigene Gateways zu programmieren, sodass die Integration weiterer Services (SMTP-Services, JMS-Services, etc.) mit geringem Programmieraufwand möglich ist.
Der integrierte Common Base Event Adapter des SDKs gestattet die Anbindung des Service Managers an eine Common Event Infrastructure (CEI-Umgebung), die in serviceorientierten Middleware Systemen (ESB, Message Broker) die Grundlage für die ereignisbasierte Informationsverarbeitung bildet. Optimal entfaltet sich die Service Manager API bei der Anwendung in ESB Mediatoren und in Java Business Integration (JBI) Komponenten.
Der integrierte Common Base Event Adapter des SDKs gestattet die Anbindung des Service Managers an eine Common Event Infrastructure (CEI-Umgebung), die in serviceorientierten Middleware Systemen (ESB, Message Broker) die Grundlage für die ereignisbasierte Informationsverarbeitung bildet. Optimal entfaltet sich die Service Manager API bei der Anwendung in ESB Mediatoren und in Java Business Integration (JBI) Komponenten.
Die Symbiose der offenen Gateway-Programmierschnittstelle und den Serviceplanansichten bildet die optimale Voraussetzung zur Planung von Servicenetzwerken, dem Erkennen von Störmeldungen und dem reibungslosen Betrieb von Service-Applikationen.
Anmerkung zum Common Base Event Format:
Das Common Base Event Format verbindet technische und fachliche Ereignisdaten, sodass neben der Überwachung und Analyse von Serviceplänen automatisierte Abläufe (Neustart von Services, Wartungsaufgaben, Redeployments, etc.) gestartet und verfolgt werden können. Skriptbasierte Abläufe sind mit Ant-Tasks und Maven in den Service Manager integrierbar. Die Integration der Skripte in den Service Manager 2.0 ist keine Kernfunktionalität und wird nur anforderungsspezifisch implementiert. Unterschiedliche Szenarien, bei denen Wartungsaufgaben manuell über die Benutzerschnittstelle ausgelöst werden, oder automatisch bei entsprechender Ereignisübermittlung (Meldung, Alarm) sind denkbar.
 | ||
| Administrator Konsole |
Die Service Manager 2.0 Administrator Konsole wird zur Verwaltung von Benutzerkonten, Stammdaten und Serviceplänen eingesetzt. Die Konsole ist ein leistungsfähiges Werkzeug für die Wartung des Service Managers und der im Betrieb anfallenden Datenmengen.
Service Manager 2.0 © 2008 - 2013 Blogbetreiber (alle Rechte vorbehalten)