Zentrales Monitoring heterogener Dienste im EDU-Umfeld

Eine zentrale Monitoring-Plattform mit modularer Architektur, in die Angehörige neue Dienste selbstständig integrieren können und die SAML-/OIDC-geschützte Dienste im EDU-Umfeld dank automatisierter Authentifizierung fortlaufend überwachen und tiefergehende Funktionalitäten prüfen kann.

Messdaten aus dem im Monitoring eingesetzten Greybox-Exporter

Ausgangslage

Die HSI führte im Frühlingssemester 2026 ein neues Modell ein, das nicht mehr auf Fachvertiefungen, sondern auf Studienrichtungen basiert. Die neue Studienrichtung Security, Platforms und DevOps ist dabei auf diverse neuralgische Dienste wie GitLab, Studenthub und Modulplaner angewiesen und hat das Ziel, den Aufbau und den Betrieb von Plattformen und Software "erlebbar" zu machen. Eine zentrale Monitoring-Plattform soll dafür den Betrieb dieser Dienste für Studierende und Angehörige transparenter machen, aufbauend auf dem bewährten Stack aus Prometheus, Grafana und OCI-Containern. Neue Dienste sollen sich einheitlich und kontrolliert integrieren lassen, sodass auch Angehörige der HSI eigenständig mitwirken können.

Geschützte Dienste im EDU-Umfeld stehen ausschliesslich authentifizierten Angehörigen der Organisation zur Verfügung. Sie liegen hinter einem externen Identity Provider (IdP) und gewähren von aussen keinen oder nur sehr eingeschränkten Einblick in ihren internen Zustand. Eine zentrale Überwachung solcher heterogenen Dienste muss deshalb nicht nur die Erreichbarkeit erfassen, sondern sich auch automatisiert gegenüber des IdP authentifizieren, um die Funktionalität hinter diesem zu prüfen. Diese Arbeit entwickelt dafür Konzepte und setzt sie in einer produktionsreifen Monitoring-Plattform um.

Zielsetzung

Das Ziel dieser Arbeit ist die Entwicklung von Konzepten, mit denen sich solche Dienste kontinuierlich und zentral überwachen lassen. Diese Konzepte werden in der bestehenden Plattform umgesetzt, die dafür produktionsreif ausgebaut und an exemplarisch integrierten Diensten unter realen Bedingungen validiert wird. Daraus ergeben sich folgende Projektziele:

• Möglichkeiten zur Überwachung SAML-/OIDC-geschützter Dienste sind evaluiert.
• Konzepte für Blackbox- und Whitebox-Monitoring sind implementiert.
• Die Plattform ist als Configuration as Code (CaC) auf einer Multi-Stage-Infrastruktur ausrollbar.
• Mindestqualitätsstandards sind vor Integration und Deployment durch Quality Gates erzwungen.
• Ein Schutzkonzept ist umgesetzt, das Änderungen durch Dritte kontrolliert, nachvollziehbar macht und unzulässige Eingriffe verhindert.
• Default-Dashboard-Templates stehen bereit.
• Dienste hinter einem Identity Provider sind überwachbar.
• Authentifizierungs-Flows sind überwachbar, und der entstehende Overhead ist ausgewiesen.
• Die tatsächliche Verfügbarkeit der Dienste ist kontinuierlich erfasst, nicht nur die Erreichbarkeit des Webservers.
• Die Performance der Dienste ist kontinuierlich messbar.

Ergebnisse

Die resultierende Plattform ist modular aufgebaut: Sie trennt dienstspezifische Konfiguration konsequent von geteilter Konfiguration, sodass jeder Dienst durch eine einzelne Service-Definition beschrieben wird und sich neue Dienste trotz ihrer Eigenheiten einheitlich und kontrolliert integrieren lassen. Provisioniert als Configuration as Code auf einer baugleichen Multi-Stage-Infrastruktur und ist abgesichert durch Quality Gates. Automatisiert kann sich das Monitoring über einen instrumentierten Browser mittels Passkey über WebAuthn authentisieren und durchläuft die mehrstufigen SAML-/OIDC-Redirects protokollunabhängig. Der neu entwickelte Greybox-Exporter, welcher als Scrape-Target für Prometheus Metriken bereitstellt, wendet diesen Mechanismus an und misst die Dienste aus der Perspektive der Endnutzenden: Er erfasst detaillierte Netzwerkinformationen, auch aggregiert pro Domain, misst Web Vitals sowie Browser-Engine-Timings und ergänzt jede Messung um einen Trace der Netzwerk-Requests.

An produktiv integrierten Diensten durchlaufen die Probes den vollständigen Login-Flow und erfassen damit die tatsächliche Funktionalität, statt nur die Erreichbarkeit des Webservers. Der Anteil des Identity Providers an der Gesamtdauer fällt über verschiedene Dienste hinweg praktisch identisch aus und lässt sich herausrechnen, sodass Applikations- und Authentifizierungsperformance getrennt ausgewiesen werden können. Lasttests belegen zudem, dass der Ansatz planbar skaliert: Wie viele Dienste eine Exporter-Instanz überwachen kann, ergibt sich aus dem Zusammenspiel von Browser-Kernen, Probe-Dauer und Scrape-Intervall und lässt sich über diese Grössen gezielt dimensionieren.

Links

• Greybox-Exporter auf GitHub
• Monitoring-Plattform im FHNW GitLab (nur für Angehörige der HSI zugänglich)
• Produktivumgebung der Monitoring-Plattform (Anmeldeinformationen im Monitoring-Plattform Repository)

Technische Schlüsselbegriffe

• Blackbox-/Whitebox-MonitoringBlackbox betrachtet ein System von aussen und berücksichtigt nur die für Benutzer sichtbaren Ausgaben. Es erkennt Symptome, nicht deren Auslöser. Whitebox greift über dedizierte Endpunkte auf Daten aus dem Inneren zu und macht auch die Auslöser nachvollziehbar.
• Greybox-MonitoringVerbindet beide Sichten: Gemessen wird von aussen, die Probe dringt aber durch die Authentifizierung bis in den Dienst vor und macht das Laden der Web-Artefakte und die seiteninternen Requests messbar.
• Synthetic MonitoringSynthetisches Monitoring baut einen aktiven Monitoring-Mechanismus auf, indem es das Verhalten von Benutzern mithilfe vordefinierter Abläufe simuliert. Die dabei künstlich erzeugten Anfragen ermöglichen es, Verfügbarkeit und Antwortverhalten einer Applikation kontinuierlich aus der Benutzerperspektive zu prüfen, ohne auf echte Benutzerinteraktionen angewiesen zu sein.
• PrometheusToolkit zur Systemüberwachung und Alarmierung, das Metriken als Zeitreihen speichert. Nach dem Pull-Prinzip ruft es in konfigurierbaren Intervallen die Endpunkte seiner Ziele ab, was als Scraping bezeichnet wird. Abgefragt werden die Zeitreihen über die Abfragesprache PromQL.
• Greybox-ExporterDer in dieser Arbeit entwickelte Exporter in Go. Er folgt dem Probe-Muster des Blackbox-Exporters: Prometheus übergibt das zu prüfende Target als Parameter, worauf jede Probe einen vollständigen Browser steuert und das Ergebnis als Metriken zurückliefert.
• SAML / OIDCProtokolle, mit denen eine Applikation die Authentifizierung an einen externen Identity Provider delegiert: SAML als XML-basiertes Framework, OIDC als Identitätsschicht über OAuth 2.0. Der Browser durchläuft dabei eine Kette von Redirects zwischen Applikation und Provider.
• WebAuthn / PasskeyVom W3C standardisierte Browser-Schnittstelle für die Public-Key-basierte Authentifizierung mittels Passkeys, die dienstunabhängig über dieselbe API angesprochen wird. Das Monitoring nutzt sie für den automatisierten Login am Identity Provider.
• Virtual AuthenticatorRein softwareseitiger Authenticator, den der instrumentierte Browser über das Chrome DevTools Protocol registriert. Ihm wird der gespeicherte Passkey als Credential hinzugefügt, wodurch sich der WebAuthn-Login skripten lässt.
• Web VitalsMetriken aus Googles Web-Vitals-Programm wie TTFB, FCP, LCP und CLS, die erfassen, wie schnell und stabil sich eine Seite für den Nutzer anfühlt. Die Probe misst sie direkt aus der Target-Seite heraus.

Team