Insight: Die kontinuierliche Evolution von smartlearn → Jetzt lesen

Systemüberwachung

von | 13. Dez. 2023

smartlearn lässt sich mittels einer HTTP-Schnittstelle und über das CLI überwachen, um mögliche Probleme frühzeitig festzustellen. Zudem können aus der gleichen Schnittstelle Metriken über die Verwendung des Systems ausgelesen werden.

Grundlegende Funktion

Über folgende URL lässt sich das smartlearn-Monitoring aufrufen. Dazu muss ein HTTP Header X-Auth-Token mit einem 32 Zeichen langem Schlüssel mitgegeben werden. Der Zugriffsschlüssel kann über den smartlearn-Support angefragt werden.

Ein Aufruf mittels curl sieht wie folgt aus:

curl -H "X-Auth-Token: ABCDEF0123456789ABCDEF0123456789" https://smartlearn.meine-institution.ch/api/health

Die HTTP Schnittstelle liefert einen HTTP Status-Code 200, sollte das System in einem stabilen Zustand sein. Bei einem instabilen Zustand liefert die Schnittstelle einen HTTP Status-Code 503. Sollte der Zugriffsschlüssel ungültig sein, wird ein HTTP Status-Code 401 zurückgegeben.

Wir erwarten zudem, dass das abfragende System einen verständlichen User-Agent mitliefert (in curl beispielsweise mit der Option -A), um die Quellen der Abfragen identifizieren und bei Problemen wie der Generierung von hoher Last die entsprechenden Kontaktpersonen ausfindig machen zu können (z.B. Icinga-wwd).

Rückmeldung

Die HTTP-Schnittstelle sendet einen JSON Response zurück. Diese ist wie folgt aufgebaut:

  • metric:
    • Metriken sind System-Kennzahlen über dessen Verwendung.
    • Jede Metrik hat einen sprechenden Namen (name) sowie einen Wert (value).
    • Jede Metrik ist mit einem Status (state) versehen. Diese können ok, warning oder critical sein (Source-Code). Die meisten Metriken werden mit ok ausgegeben, da das System keine fixe Grenze hat. Es werden nur warnings oder critical ausgegeben, sollte der Wert negative Auswirkungen auf smartlearn haben (z.B. Systemlimits von ESXi sind bei 80 % oder ähnliches).
    • Metriken sind kategorisiert nach:
      • exam
        • Rund um Lernumgebungen („long running“) und Prüfungen („short running“)
      • messenger
        • Aktuelle Anzahl Hintergrund-Arbeiten, welche das System abarbeitet. Es erscheint eine Warnung, sollten Jobs feststecken und davon ausgegangen werden muss, dass dies Auswirkungen auf die Systemnutzung hat.
      • user
        • Anzahl Benutzer-Accounts in smartlearn
      • virtualization
        • Statistiken zu Anzahl VM’s und Umgebungen
      • vsphere
        • Metriken rund um smartlearn, z.B. prozentuale Verwendung des verfügbaren Speicherplatzes, RAM- und CPU-Verwendung usw.
  • sensor
    • Sensoren sind effektive Verfügbarkeits-Abfragen von internen Komponenten und Drittsystemen.
    • Jeder Sensor hat einen sprechenden Namen (name) sowie Details (details). In den Details werden unter anderem die angefragten Dienste aufgeführt oder weitere Informationen bei einem negativen Status zurückgegeben.
    • Jeder Sensor ist mit einem Status (state) versehen. Diese können success, warning oder critical sein (Source-Code).
    • Sensoren sind kategorisiert nach:
      • ldap
        • Prüft, ob Verbindung zu den benötigten LDAP Servern möglich sind
      • vsphere
        • Prüft Verbindungen zu vSphere und ESXi Server sowie der Hardware- und Software-Status der ESXi Server.
      • database
        • Prüft die Verbindung und Konsistenz der Datenbank
      • service
        • Prüft diverse, weitere Komponenten von smartlearn, welche zum reibungslosen Betrieb von smartlearn notwendig sind.

Best Practices

  • Wir empfehlen, maximal ein Request pro Minute an den Endpoint zu senden, bevorzugt alle 5 Minuten. Der Endpoint ruft die Metriken zum Zeitpunkt der Anfrage ab und es werden Drittsysteme wie das VMware vSphere oder ESXi-Hosts abgefragt, welche Ressourcen verwenden.
  • Zur Entwicklung von Statistik-Dashboards o.ä. empfehlen wir die Verwendung einer Time-Series Datenbank und einem Dashboard wie z.B. Prometheus und die Daten in einem 15-Minuten-Intervall abzufragen.
  • Die Namen der Metriken und Sensoren sind derzeit nicht als stabil anzusehen und können in zukünftigen Releases ändern. Als Alarmierung bei Problemen empfehlen wir deshalb unbedingt den HTTP Status-Code zu verwenden, nicht einzelne Metriken oder Sensoren.

Verwendung im CLI

Auf dem smartlearn Server können Sie denselben Check und dieselben Daten mittels dem Befehl smartlearn smartlearn:check abrufen. Die Daten werden in einer CLI-Tabelle dargestellt.