Flowmon
automatisiertes SLA Reporting
- Import der Daten aus Monitor-Plattformen oder Ticket-Systemen
- Errechnung der SLA Überschreitungen mit variablen Methoden
- Berücksichtigung der Wartungs-bzw. Nicht-Betriebszeiten
- Darstellung der SLAs in Dashboards
- Auflistung der Hauptursache für SLA Incidents
- Erstellung und Versand der fertigen Reports
SLA Metriken – Aggregierung
Deshalb werden die SLA-relevanten Daten aus vielen Datenquellen und in unterschiedlichen Formaten bereitgestellt – und müssen dann im Reporting oft manuell aggregiert werden – um die finale Aussage über die Service-Qualität zu treffen.
SLIC kann diesen Prozess vollständig automatisieren, indem die Logik des SLA einmal erfasst wird, die Schnittstellen zu unterschiedlichen Tools eingerichtet, die Daten periodisch importiert, Incidents berechnet und in SLA Metriken berechnet werden. SLIC berücksichtigt Betriebszeiten, Wartungsfenster und außerordentliche Störungen, die aus den Reports rausgerechnet werden.
Verfügbarkeit & Performance im SLA Report
SLIC kann die Roh-Daten aus Monitoring-Systemen importieren und über eigene Data-Adapter die SLA -Metriken errechnen. Diese Roh-Daten werden in SLIC bewertet, gegen zugeordnete Schwellwerte verglichen und Überschreitungen als Incidents reportet.
Service-orientierte Dashboards mit klaren Workflows
• SLA Time Line /Bar-Chart Dashboard, Darstellung der SLA-Metrik-Verlauf auf einer Zeitachse – pro Service Gruppe oder Service
• SLA Status Dashboard, Darstellung der Services mit den exakten Werten der Incident-Time und den Budget-Werten bis zur Erreichung des SLA Schwellwert auf einen Monat bezogen
SLA Dashboard
Performance und Verfügbarkeit werden für eine ausgewählte Periode für Dienste oder Dienst-Gruppen ausgewiesen.
Verschiedene Technologien können gemeinsam dargestellt und miteinander korreliert werden.
Application Incident Heat Chart
Revisions-fähige Service Level Reports
• System / Server aus SNMP
• Application Daten aus Monitoring Lösungen wie Steelcentral® und
• Transaktionsdaten aus synthetischen Click-Strecken.
Die erzeugten Reports sind korrekt formatiert, als PDF und HTML verfügbar.
Kommentar-Funktionen innerhalb der Reports und Dashboards ermöglichen, Ausfälle oder Abweichungen in den Reports zu kommentieren und sichtbar zu machen.
Slic erlaubt die Berücksichtigung von Wartungszeiten, Businesshours und außerplanmäßigen Off-Zeiten.
Service Discovery
Die Kenntnis der Service Architektur ist die Voraussetzung für einer Service-Bewertung.
Exisitieren Kommunikations-Daten zwischen Servern im Backend, können diese in SLIC verwendet werden, um eine tägliche automatisierte Service Discovery durchzuführen.
Die Front-End- sowie Backend Server-Systeme werden aufgelistet bzw. in einem Architektur-Chart dargestellt.
Da die Service Discovery täglich durchgeführt wird, sind die Architektur Charts immer aktuell.
Änderungen innerhalb einer Service Kette, z.B. neue Server, werden erfasst und ausgewiesen.
Service Bewertung
Abhängig von den vorliegenden Daten können Auswertungen vorgenommen werden.
Liege zB. für Web-Anwendungen Informationen vor wie Seiten-Lade-Zeiten, können Schwankungen oder Service-Level-Überschreitungen erkannt werden – und zusätzlich, ob im Backend ebenfalls Schwankungen vorlagen, die einen Zusammenhang erkennen lassen.
Für die Bewertung von Anwendungen wurde ein flexibles “Baseline”-Modul entwickelt, um Standard-Abweichungen festzustellen und diese für die Bewertung zu verwenden.
All-Data Import
SLIC Data Adapter errechnen aus den Roh-Daten die Werte für Verfügbarkeit und Performance und stellen diese in Reports bereit.
Capturing
In SLIC können High-Performance-Capture –Appliances (iPAC) integriert werden.
Der Workflow erlaubt es, direkt aus den Incident-Reports heraus Filter im BPF-Format zu erstellen und die Paket-Daten zu laden.
Die kostengünstigen „iPAC PacketStore“- Systeme capturen Pakete bis zu 40 Gbps dropless – auf bis zu 650 TB Speicher – pro Stack.
iPAC-Stacks können geclustert werden, so dass mehrere IPAC – Stacks als ein System administriert werden kann.
Werden die Traces erzeugt und gespeichert , werden diese automatisch auf bekannte Fehler-Symptome analysiert, und ihr Zustand farblich markiert.
Mehr Infos dazu unter iTM >
Triggered Capture
Dabei können Filter nicht nur für die betroffenen, sondern auch für die verbundenen Systeme definiert werden.
Erlebt z.B. ein Server eine hohe Reset Rate zu einem anderem System, wird als Tracefilter die beidseitige Kommunikation verwendet – und nicht nur die IP Adresse des Incident- auslösenden Systems.
Durch die Korrelation mit Fremd-Daten können unterschiedliche Service-Ebenen miteinander korreliert werden, was die Transparenz der Business-Services erheblich verbessert.