Service Monitor

basiert auf den Funktionen des xPactor Frameworks

was ist das?

In der Vergangenheit war das IT-Monitoring in die klassischen (und meist unabhängigen) Einzeldisziplinen wie dem Netzwerk-Monitoring, dem System-Monitoring seine Applikations- und Datenbank-Monitoring aufgeteilt. Schwerpunkt war meist das systemeorientierte Infrastruktur-Monitoring und der möglichst umfassenden und detaillierten Überwachung der einzelner Komponenten. Was in den meisten Fällen jedoch vergessen wird, bzw. durch die vorhandene Überwachungsinfrastruktur funktional nicht abgedeckt wird, ist das Erkennen der Auswirkungen von Störungen und Beeinträchtigungen innerhalb der Leistungserbringung es Service-Providers oder Service-Nutzers. Diese Auswirkungen müssen sich dabei immer an den vertraglichen Verpflichtungen der Service-Nutzung orientieren. Erschwerend kommt hinzu, dass der heutige Service-Kunden selten noch Infrastruktur-Services konsumiert, sondern auf SaaS- oder PaaS-Lösungen  seine Wertschöpfung stützt.

Unser Ansatz ist es mit dem Service-Monitor Wirkketten zu modellieren, Regeln für jedes Element zu definieren, Aktionen Regeln zuzuordnen und durch Events aus dem IT-Monitoring zu stimulieren. Die Auswirkungen (der Impact) werden zur leichteren Erkennung der Auswirkungen intelligent visualisiert.

  • Es braucht eine durchgängige Sicht vom Vertrag (der Kundenverpflichtung) bis zu den Komponenten/Ressourcen, die die Leistung erbringen
  • Die Leistungserbringung sind sehr vielfältig strukturiert und nicht immer gleich steuerbar
    • Netzwerke, Server, Datenbanken, etc.
    • Personen und Skills
    • Lizenzen und RechteProzesse, Rollen und Verantwortungen
  • Der Markt ist verunsichert und weiß nicht, wie er die Herausforderungen meistern soll
    • Cloud-Welt macht ihm Angst -> viele businesskritischen Fragen sind nicht geklärt (Sicherheit, Kontinuität, Verantwortung, etc.)
    • Best Practise Ansätze brauchen viel Zeit, bis sie wirksam werden
    • Toolanbieter versprechen viel und können vieles auch nicht halten
  • Wie verbinde ich beide Welten?
  • Megatrends zwingen zu einer anderen Ausrichtung in der Steuerung der Leistungserbringung
    • die Cloud und Virtualisierung zwingen zu einer Trennung von Nutzen und Infrastruktur
    • Infrastruktur aufbauen und betreiben bedingen einen hohen Kapitalaufwand
    • Steuerbarkeit muss kontinuierlich gegeben sein
  • Trennung in Infrastruktur Management und Service Management
    • Service Management garantiert den Nutzen
    • Infrastruktur Management garantiert die Funktion
  • Prozesse verbinden / verlinken diese beiden Welten
    • Über Firmen/Abteilungsgrenzen hinweg / Verantwortungsübergänge
    • Störungsbehebung
  • Prozesse trennen die beiden Welten
  • Verfügbare Tools basieren meistens auf Technologien und Basisprodukten aus dem Infrastruktur-Monitoring
    • Folgen dem Buttom-Up-Ansatz
    • Komplizierte Regeldefinition und Zuordnung
    • Teuer und schwerfällig
    • Zeigen immer eine Technologie-Sicht
    • Schwierigkeiten virtuelle Welten abzubilden
  • Fehlende Funktionalitäten
    • Abbildung verschiedenster Sichten auf einzelne Infrastruktur-Elemente (z.B. Lokationssicht, Vertragssicht, Produktmanagementsicht, SLA-Sicht, etc.)
    • Top Down-Ansatz (vom Kunden zur Infrastruktur)
    • Kombination/Korrelation verschiedener Informationsinhalte (z.B. Events von Probes mit aktuellem SLA-Status)

Links:

ServiceMonitor@xPactor

Kritische Erfolgsfaktoren für das Service-Monitoring

Als Service-Erbringer müssen sie immer in der Lage sein folgende Fragen zu beantworten:

WER braucht und WER nutzt WAS?
Service Konfigurationen, Benutzer- und Kundeninformationen
WIE ist der aktuelle (Service-)Zustand?
Infrastruktur- und Service-Monitoring /Lifecycle Management
WAS ist vereinbart ?
Verträge, Business-Service, Service, Service Asset, CIs ( Geräte, Systeme, Subsysteme, … ) und deren Verpflichtungen
WO wird der Service übergeben?
Wo ist der Service Access Point (Geographie, Adresse, Gebäude, Stockwerk, Raum, Rack, …)?
WIE ist der Service konfiguriert?
die vereinbarten Parameter sind: Profile, Bandbreiten, IP-Adressen, Kompatibilitäten, …
WER bezahlt WAS?
Service-Preise und Infrastruktur-Kosten
WER tut gerade WAS?
aktueller Status von Incidents, Changes, Service Requests sowie Workorders

Lösung muss Robust sein

  • Kein Verlust von Informationen
  • Geringe Ausfallzeiten
  • Datensicherheit

Lösung muss performant sein

  • Schnelles Laden von Modellen: im kleinen Minutenbereich für Modelle mit 50.000 Elementen
  • Aggregation in großen Modellen muss „nearrealtime fähig“ sein: Aggregation und Propagation im Sekundenbereich für große Modelle

Lösung muss einfach zu bedienen sein

  • Nur wenige Klicks bis zur gewünschten Information
  • Ergebnisse müssen transparent nachvollziehbar sein
1

Lösung muss skalierbar sein

  • Für kleine und große Bäume und Datenraten

Lösung braucht offene Interfaces

  • Nutzung von Kommunikationsstandards
  • Reduktion auf wenige Interfaces

Funktionsmerkmale des Service Monitors

SMON@xPactor® Prototyp (aktuell implementiert)

  • Kernfunktionalität modelliert und protoypen-mässig umgesetzt
  • Propagation von Zustandsänderungen in einem Baum (immer von den Blättern zur Wurzel – Propagationsregeln: AND, OR, ORYELLOW)
  • REST-Interface zur Stimulation eines Elements (Service Assets)
  • Statusänderungen auf ROT, ORANGE oder GREEN
  • Arbeitsbildschirme zur Erklärung der Kernfunktionalität und zur Steuerung der Funktionen
  • Alarmkonsole (Infrastruktur Events über REST), Service Alarme
  • Bird View: Visualisierung des kompletten Waldes (neutrale Farbe = Alles OK, Einfärbung = Alarme oder Events sind vorhanden)
  • Drill down in den Baum und die Elemente
  • Triggern einer Aktion über ein externes Interface
  • Integration mit einem Enterprise Service Bus
  • Voll integriert und online präsentierbar
SMON@xPactor® Version 1.0 -> Geplant Q1/2015

  • Umgang mit großen Datenmengen (Anzahl Events und Elemente)
  • Update und Laden neuer Strukturen als Masterplan/Servicemodell
  • Abbilden „externer Services“ und sharedComponents inkl. Verlinkung von Bäumen
  • manuelles/automatisiertes Triggern von Aktivitäten
  • Ticket eröffnen
  • Twittern / RSS
  • Verändern des Elementverhaltens
  • Blacklist/Test
  • Aktiv / Inaktiv setzen einzelner Elemente
  • User- und Rollenmanagement
  • Anwendung in der Applikation
  • Anwendung auf Datenelemente
  • Zusätzliche Interfaces
  • Zusätzliche Dashboard
  • Zusätzliche Propagations- und Rechenregeln
  • Verallgemeinerung der Architektur zur Abbildung universeller Regeln
  • Bearbeitung und Visualisierung von Multistatusinformationen (Alarmstatus und SLA-Status)
  • Individuelles Branding
  • Installierbarkeit des Systems
SMON@xPactor® Version 2.0 -> Geplant Q4/2015

  • Zusätzliche Rechenfunktionen auf jedem Element
  • Berücksichtigung von Servicezeiten
  • Korrelation mit Changes
  • Translation Table zum Mappen externer Events auf internes Modell
  • Verwenden von Broadcast Events
  • zielgerichtete Stimulation von Elementen innerhalb eines Baums sowie zu anderen Bäumen
  • Klammerfunktionen zur Wichtung und Gruppierung von Eingangssignalen
  • Erweiterte Reportingfunktionalität
  • Personalisierung von Dashboards
  • erweiterte DB-Schnittstelle
  • Oberfläche zur Bearbeitung geladener Bäume
SMON@xPactor®  Roadmap

  • 2 Versionen pro Jahr – ein Haupt-Release und ein Update-Release
  • 1 User Konferenz pro Jahr
  • Einrichten eines Advisory Boards
  • vierteljährliches Webcasts

Screenshots des Service Monitors

Management View

Zusammenfassung aller Ereignisse

Alarm View

zeigt in einer Listendarstellung alle Ereignisse

Impact View

Zeigt den Impact eines Einzelereignisses

Impact Tree

zeigt Auswirkungen grafisch im Baum dar