ADC

Benutzermonitore verstehen

Benutzermonitore erweitern den Umfang von benutzerdefinierten Monitoren. Sie können Benutzermonitore erstellen, um den Zustand benutzerdefinierter Anwendungen und Protokolle zu verfolgen, die die NetScaler-Appliance nicht unterstützt. Das folgende Diagramm zeigt, wie ein Benutzermonitor funktioniert.

Abbildung 1. Benutzer-Monitore

User-monitor

Für einen Benutzermonitor sind die folgenden Komponenten erforderlich.

Dispatcher. Ein Prozess auf der Appliance, der Überwachungsanfragen abhört. Ein Dispatcher kann sich auf der Loopback-IP-Adresse (127.0.0.1) und Port 3013 befinden. Dispatcher werden auch als interne Dispatcher bezeichnet. Ein Dispatcher kann auch ein Webserver sein, der das Common Gateway Interface (CGI) unterstützt. Solche Dispatcher werden auch als externe Dispatcher bezeichnet. Sie werden für benutzerdefinierte Skripts verwendet, die nicht in der FreeBSD-Umgebung ausgeführt werden, z. B.

Hinweis:

Sie können den Monitor und den Dispatcher für die Verwendung von HTTPS anstelle von HTTP konfigurieren, indem Sie die Option “sicher” auf dem Monitor aktivieren und als externen Dispatcher konfigurieren. Ein interner Dispatcher versteht jedoch nur HTTP und kann HTTPS nicht verwenden.

In einem HA-Setup wird der Dispatcher sowohl auf den primären als auch auf den sekundären NetScaler-Appliances ausgeführt. Der Dispatcher bleibt auf dem sekundären Gerät inaktiv.

Script. Das Skript ist ein Programm, das benutzerdefinierte Prüfpunkte an den Server mit Lastausgleich sendet und den Antwortcode an den Dispatcher zurückgibt. Das Skript kann einen beliebigen Wert an den Dispatcher zurückgeben, aber wenn eine Prüfung erfolgreich ist, muss das Skript einen Wert von Null (0) zurückgeben. Der Dispatcher betrachtet jeden anderen Wert als Sondenausfall.

Die NetScaler-Appliance ist mit Beispielskripten für häufig verwendete Protokolle gebündelt. Die Skripts sind im Verzeichnis /nsconfig/monitors vorhanden. Wenn Sie ein Script hinzufügen möchten, fügen Sie es dort hinzu. Um ein vorhandenes Skript anzupassen, erstellen Sie eine Kopie mit einem neuen Namen und ändern Sie es.

Wichtig:

  • Ab NetScaler Release 13.0 Build 41.20 können Sie das Skript nsntlm-lwp.pl verwenden, um einen Monitor zur Überwachung eines sicheren NTLM-Servers zu erstellen.

  • Ab Version 10.1 Build 122.17 befinden sich die Skriptdateien für Benutzermonitore an einem neuen Speicherort.

    Wenn Sie eine virtuelle MPX- oder VPX-Appliance auf Version 10.1 Build 122.17 oder höher aktualisieren, lauten die Änderungen wie folgt:

    • Ein neues Verzeichnis namens conflicts wird in /nsconfig/monitors/ erstellt und alle integrierten Skripts der vorherigen Builds werden in dieses Verzeichnis verschoben.
    • Alle neuen integrierten Skripts sind im Verzeichnis /netscaler/monitors/ verfügbar. Alle benutzerdefinierten Skripts sind im Verzeichnis /nsconfig/monitors/ verfügbar.
    • Speichern Sie ein neues benutzerdefiniertes Skript im Verzeichnis /nsconfig/monitors/.
    • Wenn nach Abschluss des Upgrades ein benutzerdefiniertes Skript erstellt und im Verzeichnis /nsconfig/monitors/ gespeichert wird, mit demselben Namen wie das integrierte Skript, hat das Skript im Verzeichnis /netscaler/monitors/ Vorrang. Das benutzerdefinierte Skript wird nicht ausgeführt.

    Wenn Sie eine virtuelle Appliance mit Version 10.1 Build 122.17 oder höher bereitstellen, lauten die Änderungen wie folgt:

    • Alle integrierten Skripts sind im Verzeichnis /netscaler/monitors/ verfügbar.
    • Das Verzeichnis /nsconfig/monitors/ ist leer.
    • Wenn Sie ein benutzerdefiniertes Skript erstellen, müssen Sie es im Verzeichnis /nsconfig/monitors/ speichern.

Damit die Skripts korrekt funktionieren:

  • Die maximale Anzahl von Zeichen im Namen des Skripts darf 63 nicht überschreiten.
  • Die maximale Anzahl von Script-Argumenten, die einem Script zur Verfügung gestellt werden können, darf 512 nicht überschreiten.
  • Die maximale Anzahl von Zeichen, die in den Argumenten des Parameterskripts angegeben werden können, darf 639 nicht überschreiten.

Um das Skript zu debuggen, müssen Sie es mithilfe des nsumon-debug.pl-Skripts von der CLI ausführen. Sie verwenden den Skriptnamen (mit seinen Argumenten), die IP-Adresse und den Port als Argumente des nsumon-debug.pl-Skripts. Benutzer müssen den Skriptnamen, die IP-Adresse, den Port, das Timeout und die Skript-Argumente für das nsumon-debug.pl-Skript verwenden.

Geben Sie bei der CLI Folgendes ein:

nsumon-debug.pl <scriptname> <IP> <port> <timeout> <partitionID> [scriptarguments][is_secure]
<!--NeedCopy-->

Wichtig: Ab Version 10.5 Build 57.x unterstützen die 11.0-Skriptdateien für Benutzermonitore IPv6-Adressen und beinhalten die folgenden Änderungen:

  • Für die folgenden Protokolle wurden neue pm files für die IPv6-Unterstützung aufgenommen.

    • RADIUS
    • NNTP
    • POP3
    • SMTP
  • Die folgenden Beispielskripte in /netscaler/monitors/ wurden für die IPv6-Unterstützung aktualisiert:

    • nsbmradius.pl

    • nsldap.pl

    • nsnntp.pl

    • nspop3 nssf.pl

    • nssnmp.pl

    • nswi.pl

    • nstftp.pl

    • nssmtp.pl

    • nsrdp.pl

    • nsntlm-lwp.pl

    • nsftp.pl

    • nsappc.pl

    Stellen Sie nach dem Upgrade auf Version 10.5 Build 57.x oder 11.0 sicher, dass Sie die vorhandenen benutzerdefinierten Skripts mit IPv6-Diensten verwenden möchten, die vorhandenen benutzerdefinierten Skripts mit den Änderungen in den aktualisierten Beispielskripten in /netscaler/monitors/aktualisieren.

Hinweis:

Das Beispielskript nsmysql.pl unterstützt die IPv6-Adresse nicht. Wenn ein IPv6-Dienst an einen Benutzermonitor gebunden ist, der nsmysql.pl verwendet, schlägt der Test fehl.

  • Die folgenden LB-Monitortypen wurden aktualisiert, um IPv6-Adressen zu unterstützen:

    • USER

    • SMTP

    • NNTP

    • LDAP

    • SNMP

    • POP3

    • FTP_EXTENDED

    • StoreFront

    • APPC

    • CITRIX_WI_EXTENDED

    Wenn Sie ein benutzerdefiniertes Skript erstellen, das einen dieser LB-Monitortypen verwendet, stellen Sie sicher, dass Sie IPv6-Unterstützung in das benutzerdefinierte Skript aufnehmen. Beziehen Sie sich auf das zugehörige Beispielskript in /netscaler/monitors/ für die Änderungen, die Sie im benutzerdefinierten Skript für die IPv6-Unterstützung vornehmen müssen.

Um den Status des Servers zu verfolgen, sendet der Monitor eine HTTP-POST-Anforderung an den konfigurierten Dispatcher. Diese POST-Anfrage enthält die IP-Adresse und den Port des Servers sowie das Skript, das ausgeführt werden muss. Der Dispatcher führt das Skript als untergeordneten Prozess mit benutzerdefinierten Parametern (falls vorhanden) aus. Anschließend sendet das Skript einen Prüfpunkt an den Server. Das Skript sendet den Status der Sonde (Antwortcode) an den Dispatcher. Der Dispatcher wandelt den Antwortcode in eine HTTP-Antwort um und sendet ihn an den Monitor. Basierend auf der HTTP-Antwort markiert der Monitor den Dienst als hoch oder unten.

Die NetScaler-Appliance protokolliert die Fehlermeldungen in der Datei /var/nslog/nsumond.log, wenn die Prüfungen der Benutzerüberwachung fehlschlagen. Diese detaillierten Fehlermeldungen werden in der GUI und in der CLI für die Befehle show service/service group angezeigt.

In der folgenden Tabelle sind die Benutzermonitore und die möglichen Gründe für einen Fehler aufgeführt.

Typ des Benutzermonitors Gründe für Sondenausfall
SMTP Monitor stellt keine Verbindung zum Server her.
NNTP Monitor stellt keine Verbindung zum Server her.
  Fehlende oder ungültige Skriptargumente, die eine ungültige Anzahl von Argumenten oder Argumentformat enthalten können.
  Monitor findet die NNTP-Gruppe nicht.
LDAP Monitor stellt keine Verbindung zum Server her.
  Fehlende oder ungültige Skriptargumente, die eine ungültige Anzahl von Argumenten oder Argumentformat enthalten können.
  Monitor bindet nicht an den LDAP-Server.
  Monitor findet keinen Eintrag für die Zielentität im LDAP-Server.
FTP Die Verbindung zum Server ist ab.
  Fehlende oder ungültige Skriptargumente, die eine ungültige Anzahl von Argumenten oder Argumentformat enthalten können.
  Anmeldung fehlgeschlagen.
  Monitor findet die Datei nicht auf dem Server.
POP3 Monitor stellt keine Verbindung zur Datenbank her.
  Fehlende oder ungültige Skriptargumente, die eine ungültige Anzahl von Argumenten oder Argumentformat enthalten können.
  Anmeldung fehlgeschlagen.
  Die Vorbereitung der SQL-Abfrage schlägt fehl.
  Die Ausführung der SQL-Abfrage schlägt fehl.
SNMP Monitor stellt keine Verbindung zur Datenbank her.
  Fehlende oder ungültige Skriptargumente, die eine ungültige Anzahl von Argumenten oder Argumentformat enthalten können.
  Anmeldung fehlgeschlagen.
  Monitor kann die SNMP-Sitzung nicht erstellen.
  Monitor findet den Objektbezeichner nicht.
  Die Einstellung des Monitorschwellenwerts ist größer oder gleich dem tatsächlichen Schwellenwert des Monitors.
RDP (Windows Terminalserver) Fehlende oder ungültige Skriptargumente, die eine ungültige Anzahl von Argumenten oder Argumentformat enthalten können.
  Monitor kann keinen Socket erstellen.
  In Versionen stimmt nicht überein.
  Der Monitor kann die Verbindung nicht bestätigen.

Sie können die Protokolldatei über die CLI anzeigen, indem Sie die folgenden Befehle verwenden:

> shell
root@ns# cat /var/nslog/nsumond.log
root@ns# exit
>
<!--NeedCopy-->

Der Befehl öffnet eine BSD-Shell, zeigt die Protokolldatei auf dem Bildschirm an, schließt die BSD-Shell und bringt Sie zur CLI zurück.

Vor NetScaler Version 13.0 Build 52.X zeigte der Befehl show service/service group eine generische Fehlermeldung an, die besagte, dass “Probe fehlgeschlagen” als Ursache für den Fehler des Benutzermonitorprüfens war.

Beispiel:

show service ftp

Monitor Name: mon2
State: UNKNOWN  Weight: 1   Passive: 0
Probes: 3    Failed [Total: 0 Current: 0]
Last response: Failure - Probe failed.
Response Time: 1071.838 millisec
<!--NeedCopy-->

Ab NetScaler Version 13.0 Build 52.X zeigt der Befehl show service/service group die tatsächliche Ursache für den Fehler des Benutzermonitorprüfens an.

Beispiel:

show service ftp

Monitor Name: mon2
State: DOWN   Weight: 1   Passive: 0
Probes: 729   Failed [Total: 726 Current: 726]
Last response: Failure - Login failed.
Response Time: 8000.0 millisec
<!--NeedCopy-->

Benutzermonitore haben auch einen Timeout-Wert und eine Anzahl von Wiederholungsversuchen für Sondenausfälle. Sie können Benutzermonitore mit Nicht-Benutzermonitoren verwenden. Bei hoher CPU-Auslastung ermöglicht ein Nicht-Benutzermonitor eine schnellere Erkennung eines Serverausfalls.

Wenn der Prüfpunkt des Benutzermonitors bei hoher CPU-Auslastung eine Zeitdauer aufweist, bleibt der Status des Dienstes unverändert.

Example1:

add lb monitor <name> USER –scriptname <script-name> -resptimeout 5 seconds
<!--NeedCopy-->

Hinweis

Für skriptfähige Monitore muss das Antwort-Timeout auf einen Wert konfiguriert werden, der dem erwarteten Timeout entspricht + 1 Sekunde. Wenn Sie beispielsweise erwarten, dass das Timeout 4 Sekunden beträgt, konfigurieren Sie das Antwort-Timeout auf 5 Sekunden.

Example2:

add lb monitor <name> USER –scriptname <script-name> -scriptargs <Arguments> -secureargs <Arguments>
<!--NeedCopy-->

Hinweis:

Wir empfehlen, den secureargs Parameter anstelle des scriptargs Parameters für alle sensiblen Daten zu verwenden, die sich auf die Skripts beziehen.

Benutzermonitore verstehen

In diesem Artikel