Docs

Testen Sie eine beliebige RFC-URL (HTTP, HTTPS usw.)

Antwortcode, Verbindungszeit, Übertragungszeit, Inhaltsübereinstimmungen, gültiges Zertifikat

URL

RFC-URL (HTTP, HTTPS usw.)

Nutzername

Geben Sie einen Benutzernamen ein, falls die URL eine Authentifizierung erfordert. Um zu testen, ob eine Webseite den Benutzernamen und das Passwort akzeptiert, wie sie in den spezifischen Feldern der SKOOR Engine sind, geben Sie die URL wie folgt ein:

http:// : @URL

Passwort

Geben Sie ein Passwort ein, falls die URL eine Authentifizierung erfordert.

Methode

Wählen Sie eine der folgenden Anfragemethoden aus:

ERHALTEN (Standard)
PUT (aktualisieren)
POST
LÖSCHEN

Wenn entweder PUT oder POST ausgewählt ist, wird ein zusätzliches Datentextfeld aktiviert.

Daten

Nur sichtbar, wenn entweder PUT- oder POST- Methode ausgewählt ist. Ermöglicht die Eingabe des Hauptteils der PUT/POST-Anforderung.

Authentifizierung

Wählen Sie einen der folgenden Authentifizierungstypen aus:

Beliebig (von libcurl ausgewählt) (Standard)
Alle außer Basic
Basic
Verdauen
Verdau mit IE-Geschmack
Verhandeln (SPNEGO)
NTLM

Proxy-Adresse

Es ist möglich, eine URL über einen Proxy zu testen. Wenn dieses Feld verwendet wird, geht die Anfrage über den Proxy. Anders als bei normalen HTTP-Requests geht in diese Messung der Zeitpunkt des Verbindungsaufbaus zum Proxy ein. Die Gesamtzeit einschließlich Website-Download ist schneller, wenn sie auf dem Proxy zwischengespeichert wird.

Proxy-Port

Proxy-Portnummer

Proxy-Benutzername

Geben Sie den Proxy-Benutzernamen ein

Proxy-Passwort

Geben Sie das Proxy-Passwort ein

Proxy-Authentifizierung

Wählen Sie den Authentifizierungstyp für den Proxy aus. Siehe Authentifizierungsparameter oben.

Auszeit

Timeout in Sekunden (Standard ist 120 s), bevor mit einem Warnstatus geantwortet wird, dass die Webseite nicht verfügbar ist

Inhaltsprüfung

Überprüfen Sie den Textinhalt im heruntergeladenen Dokument. Reguläre Ausdrücke werden unterstützt.

Weiterleitungen folgen

Aktivieren Sie dieses Kontrollkästchen, wenn Weiterleitungen gefolgt werden sollen (bis zu 50 Weiterleitungen)

Ablauf des Zertifikats anzeigen

Aktivieren Sie dieses Kontrollkästchen, um den Ablauf des SSL-Zertifikats zu überprüfen. Dies ermöglicht die Konfiguration von Alarmgrenzen für eine bestimmte Anzahl von Tagen, bevor Zertifikate ablaufen.

Verbindungszeit unterdrücken
Übertragungszeit unterdrücken

Wenn eines dieser Kontrollkästchen aktiviert ist, wird die Verbindungszeit und/oder Übertragungszeit jeder Überprüfung nicht in der Datenbank gespeichert und ihre Werte sind nicht mehr im Wertebereich sichtbar. Ihr Wert steht auch nicht mehr zur Verwendung in Alarm Limit zur Verfügung.

SSL/TLS-Version

Wählen Sie aus einer der folgenden Implementierungen:

Standard
TLSv1
SSLV2
SSLV3

Die Standardeinstellung hängt von der Konfiguration des Betriebssystems ab.

Peer überprüfen

Bei HTTPS-Verbindungen kann das Server -Zertifikat mit einer auf dem Kollektor gespeicherten Zertifikatsdatei verglichen werden. Aktivieren Sie diese Option, um zu überprüfen, ob das SSL-Zertifikat des Server authentisch ist, dh ob man darauf vertrauen kann, dass der Server der ist, für den das Zertifikat steht. Wenn dieses Feld aktiviert ist, muss die korrekte Zertifikatsdatei des Server auf der SKOOR Engine gespeichert werden (siehe nächster Parameter Zertifikatsdatei ). Das gespeicherte Zertifikat wird mit dem vom Server ausgestellten Zertifikat verglichen, wenn der HTTP-Job ausgeführt wird.

Zertifikatsdatei

Nur sichtbar, wenn der obige Parameter Verify peer auf Certificate must be authentic gesetzt ist. Geben Sie den Namen der Zertifikatsdatei (z. B. host.crt ) ein, mit der das Zertifikat des Server verglichen wird. Zertifikatsdateien müssen zuerst in das Verzeichnis /opt/eranger/ Kollektor /certificates der SKOOR Engine kopiert werden. Der Pfad kann geändert werden, indem die Variable http_cert_path in der Datei Kollektor -Kollektor.cfg bearbeitet wird.

Host überprüfen

Nur sichtbar, wenn der obige Parameter Verify peer auf Certificate must be authentic gesetzt ist. Wählen Sie Überprüfung muss erfolgreich sein , um zu überprüfen, ob der im Zertifikat des Server angegebene allgemeine Name (CN) mit der URL des Server übereinstimmt.

HTTP-Header

Geben Sie alle HTTP-Header ein, die SKOOR Engine mit der Anfrage senden soll. Dies ist vor allem nützlich, um die angeforderte Sprache der Webseite zu ändern oder den Benutzeragenten zu ändern, mit dem sich Agent SKOOR Engine beim Server identifiziert. Der Standardbenutzer- Agent ist: „ SKOOR Engine Monitoring Agent “, wenn dieser Header nicht definiert ist. Der Wikipedia -Link direkt neben dem Header-Textfeld führt zur Wikipedia-Seite, die alle verfügbaren HTTP-Header beschreibt.

Inhalt in Datei speichern

Definieren Sie einen Dateinamen, in den die Ausgabe der Anfrage geschrieben wird.

Tags können verwendet werden, zum Beispiel $DEVICE_ADDRESS$. Abhängig von der Endung des Dateinamens (.txt oder .html) stellt der Browser die Seite beim Klicken auf den Dateilink unterschiedlich dar. Die Angabe eines wohldefinierten Dateinamens ist praktisch, wenn die Ausgabe von einem folgenden Parsefile-Job analysiert wird. Eine Ausgabedatei mit dem Namen wird erstellt, wenn dieses Feld leer gelassen wird, wobei N ganze Zahlen sind, die bei der anfänglichen Joberstellung zufällig generiert werden. Geben Sie nur den Dateinamen ohne Dateipfadkomponente an. Standardmäßig wird es unten gespeichert /var/opt/run/eranger/ Kollektor /tmp .

Antwortcode

Verwenden Sie den Antwortcode des Webservers als Alarm Limit . Normal akzeptierte Rückgabecodes sind:

200 OK und 302 Gefunden

Aber jeder andere Wert kann überprüft werden.

Hier ist eine Liste der am häufigsten verwendeten Antwortcodes:

100 Weiter

Das bedeutet, dass der Server die Anforderungsheader erhalten hat und dass der Client mit dem Senden des Anforderungshauptteils fortfahren sollte (im Fall einer Anforderung, für die ein Hauptteil gesendet werden muss, z. B. eine POST-Anforderung). Wenn der Anforderungstext groß ist, ist es ineffizient, ihn an einen Server zu senden, wenn eine Anforderung bereits aufgrund ungeeigneter Header zurückgewiesen wurde. Damit ein Server prüft, ob die Anfrage allein auf der Grundlage der Header der Anfrage angenommen werden konnte, muss ein Client in seiner ursprünglichen Anfrage als Header Expect: 100-continue senden und prüfen, ob als Antwort ein 100 Continue-Statuscode empfangen wird, bevor er fortfährt (oder 417 Expectation Failed erhalten und nicht fortfahren).

200 OK

Standardantwort auf erfolgreiche HTTP-Anforderungen.

201 erstellt

Die Anforderung wurde erfüllt und führte zur Erstellung einer neuen Ressource.

202 Akzeptiert

Die Anfrage wurde zur Bearbeitung akzeptiert, aber die Bearbeitung wurde noch nicht abgeschlossen. Auf die Anfrage kann schließlich reagiert werden oder nicht, da sie möglicherweise nicht zugelassen wird, wenn die Verarbeitung tatsächlich stattfindet.

301 Dauerhaft umgezogen

Diese und alle zukünftigen Anfragen sollten an die angegebene URL gerichtet werden

302 gefunden

Dies ist der beliebteste Umleitungscode, aber auch ein Beispiel für industrielle Praxis, die dem Standard widerspricht. Die HTTP/1.0-Spezifikation erforderte, dass der Client eine temporäre Umleitung durchführte (der ursprüngliche beschreibende Ausdruck war „Moved Temporarily“), aber gängige Browser implementierten dies als 303 See Other. Daher fügte HTTP/1.1 die Statuscodes 303 und 307 hinzu, um zwischen den beiden Verhaltensweisen eindeutig zu unterscheiden. Die meisten Webanwendungen und Frameworks verwenden jedoch immer noch den Statuscode 302, als wäre es der 303.

305 Proxy verwenden (seit HTTP/1.1)

Viele HTTP-Clients (wie Mozilla und IE) verarbeiten Antworten mit diesem Statuscode nicht korrekt, hauptsächlich aus Sicherheitsgründen.

307 Temporäre Umleitung

In diesem Fall sollte die Anfrage mit einem anderen URI wiederholt werden, aber zukünftige Anfragen können immer noch den ursprünglichen URI verwenden. Im Gegensatz zu 303 sollte die Anfragemethode bei der erneuten Ausgabe der ursprünglichen Anfrage nicht geändert werden. Beispielsweise muss eine POST-Anforderung unter Verwendung einer anderen POST-Anforderung wiederholt werden.

400 Ungültige Anfrage

Die Anfrage enthält eine falsche Syntax oder kann nicht erfüllt werden.

401 nicht Autorisiert

Ähnlich wie 403 Forbidden , aber speziell für die Verwendung, wenn die Authentifizierung möglich ist, aber fehlgeschlagen ist oder noch nicht bereitgestellt wurde.

403 Verboten

Die Anfrage war eine legale Anfrage, aber der Server weigert sich, darauf zu antworten. Im Gegensatz zu einer nicht autorisierten 401- Antwort macht die Authentifizierung keinen Unterschied.

404 Nicht gefunden

Die angeforderte Ressource konnte nicht gefunden werden.

405-Methode nicht zulässig

Eine Ressource wurde mit einer Anfragemethode angefordert, die von dieser Ressource nicht unterstützt wird; B. die Verwendung von GET in einem Formular, bei dem Daten per POST präsentiert werden müssen, oder die Verwendung von PUT in einer schreibgeschützten Ressource.

406 Nicht akzeptabel

407 Proxy-Authentifizierung erforderlich

408 Anfrage timeout

Der Client konnte die Anfrage nicht fortsetzen – außer während der Wiedergabe von Adobe Flash-Videos, wo dies nur bedeutet, dass der Benutzer das Videofenster geschlossen oder zu einem anderen Video gewechselt ist.

409 Konflikt

410 Weg

Gibt an, dass die angeforderte Ressource nicht mehr verfügbar ist und nicht wieder verfügbar sein wird. Dies sollte verwendet werden, wenn eine Ressource absichtlich entfernt wurde; In der Praxis wird stattdessen jedoch häufig ein 404 Not Found ausgegeben.

411 Länge erforderlich

412 Vorbedingung fehlgeschlagen

413 Anfrageeinheit zu groß

414 Anfrage-URI zu lang

415 Nicht unterstützter Medientyp

416 Angeforderter Bereich nicht erfüllbar

Der Client hat einen Teil der Datei angefordert, aber der Server kann diesen Teil nicht bereitstellen (wenn der Client beispielsweise einen Teil der Datei angefordert hat, der hinter dem Ende der Datei liegt).

417 Erwartung fehlgeschlagen

421 Es bestehen zu viele Verbindungen von Ihrer Internetadresse

422 Nicht verarbeitbare Entität

Die Anfrage war wohlgeformt, konnte aber aufgrund von semantischen Fehlern nicht befolgt werden.

423 Gesperrt (WebDAV)

Die Ressource, auf die zugegriffen wird, ist gesperrt

424 Fehlerhafte Abhängigkeit (WebDAV)

Die Anfrage ist fehlgeschlagen, weil eine vorherige Anfrage (z. B. ein PROPPATCH) fehlgeschlagen ist.

425 Ungeordnete Sammlung

Definiert in Entwürfen von WebDav Advanced Collections, aber nicht vorhanden in "Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol".

426 Upgrade erforderlich

Der Client sollte auf wechseln.

449 Wiederholen mit

Eine Microsoft-Erweiterung: Die Anforderung sollte wiederholt werden, nachdem die entsprechende Aktion ausgeführt wurde.

500 Interner Server

501 Nicht implementiert

502 Bad Gateway

503 Dienst nicht verfügbar

504 Gateway-Zeitüberschreitung

505 HTTP-Version wird nicht unterstützt

506-Variante verhandelt auch

507 Unzureichender Speicherplatz

509 Bandbreitenlimit überschritten

Dieser Statuscode wird zwar von vielen Servern verwendet, ist aber kein offizieller HTTP-Statuscode.

510 Nicht erweitert

Verbindungszeit

Zeit bis zum Aufbau der TCP-Verbindung zum Server (in ms). SSL-Handshake wird nicht berechnet.

Transferzeit

Zeit, bis eine Webseite bereitgestellt und die Verbindung geschlossen wird (in ms)

Inhalt passt

Legen Sie Grenzen entsprechend der Häufigkeit fest, in der eine Zeichenfolge oder ein regulärer Ausdruck gefunden wird
den Inhalt der getesteten Webseite

Zertifikat gültig

Die Anzahl der Tage bis zum Ablauf des Remote-SSL-Zertifikats.

Fehlercode

Allgemeiner Job-Fehlercode (siehe Abschnitt Job-Fehlercodes )

http://$DEVICE_ADDRESS$

Ermöglichen