Systemübergreifende Infrastrukturanalyse
Nicht noch mehr Monitoringdaten. Sondern mehr Erkenntnis aus den vorhandenen Daten.
Unternehmen haben häufig nicht zu wenig Monitoringdaten. Sie haben viele wertvolle Informationen, die getrennt voneinander betrachtet werden. BEC Infrastructure Intelligence soll diese Daten entlang der technischen Wirkungskette miteinander in Beziehung setzen.
Diagnostic Packs und Diagnostic Design · Diagnostic Engine als Entwicklungskonzept
Produktdefinition
BEC Infrastructure Intelligence verbindet vorhandene Daten aus Citrix Virtual Apps and Desktops, Microsoft RDS, Windows, Active Directory, DNS, Gruppenrichtlinien, FSLogix, VMware, Storage und Netzwerk.
Dadurch sollen Abhängigkeiten, Auffälligkeiten und wahrscheinliche Ursachen sichtbar werden, die bei einer getrennten Betrachtung einzelner Systeme häufig verborgen bleiben. Die Lösung ergänzt bestehende Monitoringplattformen und nimmt keine selbstständigen Änderungen an der Infrastruktur vor.
Kein weiteres Monitoring-Tool
Citrix, uberAgent, Splunk, Windows, Active Directory, Netzwerk und Storage liefern jeweils wertvolle Informationen. BEC Infrastructure Intelligence soll diese Werkzeuge nicht nachbauen oder ersetzen, sondern relevante Signale zeitlich und technisch entlang einer gemeinsamen Wirkungskette auswertbar machen.
Drei aufeinander aufbauende Bausteine
Gezielte SPL-Abfragen, Diagnose-Regeln und Korrelationen für typische Fehlerbilder aus Citrix-, Windows-, AD-, FSLogix- und angrenzenden Infrastrukturen.
Gemeinsam wird festgelegt, welche Daten für belastbare Ursachenanalysen wirklich benötigt werden und wie sie strukturiert erfasst und ausgewertet werden sollen.
Eine geplante herstellerübergreifende Diagnoseebene, die Informationen aus verschiedenen Systemen über ein Dependency Model und eine Cross-System Correlation Engine zusammenführt.
Der konkrete Funktionsumfang wird im Scoping beziehungsweise Pilotprojekt festgelegt. Die BEC Diagnostic Engine befindet sich in der Konzept- und Entwicklungsphase.
Beispiel für eine Diagnosekette
Das Ziel ist nicht, aus einem einzelnen Messwert sofort eine Ursache abzuleiten. Erst zeitlich und technisch passende Signale bilden eine überprüfbare Ursachenhypothese.
Citrix Logon langsam
→ FSLogix Attach auffällig
→ SMB-Latenz erhöht
→ Authentifizierung auffällig
→ Storage-Pfad untersuchen
Die Kette priorisiert die technische Prüfung. Sie ist noch kein automatischer Beweis für die endgültige Ursache.
Wenn Splunk und uberAgent bereits vorhanden sind, können gezielte SPL-Auswertungen beispielsweise Logon-Phasen, VDA- und Benutzersicht, FSLogix-Zeiten sowie VDA-seitige SMB-Werte nach Share, Zeitfenster und betroffenem System zusammenführen. Interne Storage-Metriken müssen als eigene Datenquelle verfügbar sein, wenn der Storage selbst bewertet werden soll.
Die geplante technische Kern-IP
Eine technische Abhängigkeitslandkarte beschreibt, welche Dienste, Systeme und Verbindungen an Login, Sitzung, Profil und Anwendungsstart beteiligt sind.
Fachwissen wird in prüfbare Regeln übersetzt: Welche Kombinationen sind relevant, welche Messwerte passen zeitlich zusammen und welche Alternativerklärungen müssen geprüft werden?
Die Engine verbindet normalisierte Ereignisse über Zeitfenster, Benutzer, Sitzung, Ressource und technische Abhängigkeiten zu priorisierten Ursachenhypothesen.
Erst nach Normalisierung, Regeln und Korrelation unterstützt ein lokales Sprachmodell bei Einordnung, verständlicher Begründung und Dokumentation – nicht als unkontrollierte Black Box.
Beispiel einer Korrelation
„Die erhöhte Citrix Logon Duration korreliert im selben Zeitfenster mit einer steigenden FSLogix Profile Attach Time. Gleichzeitig treten erhöhte SMB-Latenzen und zusätzliche Authentifizierungsvorgänge gegen die Domain Controller auf.“
Diese Aussage ist zunächst eine Analysehypothese. Erst die Prüfung der zugrunde liegenden Messwerte, Ereignisse und Alternativerklärungen macht daraus einen belastbaren technischen Befund.
Optionale lokale Betriebsform
Die Appliance ist ein optionaler lokaler Analyse- und KI-Knoten im kontrollierten Kundennetz – nicht das eigentliche Produkt. Die Lösung kann auf einer geeigneten BEC-Plattform, einem GPU-System des Kunden oder einer abgestimmten lokalen Serverplattform betrieben werden.
Pilotprojekt
In einem unverbindlichen Erstgespräch klären wir Problemstellung, verfügbare Datenquellen, technische Rahmenbedingungen und einen sinnvoll abgegrenzten Pilotumfang.
Bernd.Eckert@BecVirtual.de