Docs

Testen Sie jede 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 Benutzernamen und Passwort akzeptiert, wie in den spezifischen Feldern der SKOOR Engine festgelegt, 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:

GET (Standard)
PUT (Update)
POST
LÖSCHEN

Wenn entweder PUT oder POST ausgewählt wird, 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-Anfrage.

Authentifizierung

Wählen Sie einen der folgenden Authentifizierungstypen:

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

Proxy-Adresse

Es ist möglich, eine URL über einen Proxy zu testen. Wenn dieses Feld verwendet wird, läuft die Anfrage über den Proxy. Anders als bei normalen HTTP-Anfragen fließt in diese Messung die Zeit des Verbindungsaufbaus zum Proxy ein. Die Gesamtzeit einschließlich des Website-Downloads 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 gegenüber dem Proxy. Siehe Authentifizierungsparameter oben.

Auszeit

Zeitüberschreitung in Sekunden (Standard ist 120 s), bevor mit einer Warnung reagiert 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.

Folgen Sie Weiterleitungen

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

Ablaufdatum 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 vor Ablauf der Zertifikate.

Verbindungszeit unterdrücken
Übertragungszeit unterdrücken

Wenn eines dieser Kontrollkästchen aktiviert ist, wird die Verbindungszeit und/oder Übertragungszeit jeder Prüfung nicht in der Datenbank gespeichert und ihre Werte sind im Wertebereich nicht mehr sichtbar. Ihr Wert steht auch nicht mehr für die 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 prüfen, ob das SSL-Zertifikat des Server authentisch ist, dh ob man darauf vertrauen kann, dass der Server derjenige ist, der im Zertifikat angegeben ist. Wenn dieses Feld aktiviert ist, muss die korrekte Zertifikatsdatei des Server auf SKOOR Engine gespeichert sein (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 Parameter „Peer überprüfen“ oben auf „Zertifikat muss authentisch sein“ eingestellt ist. Geben Sie den Namen der Zertifikatsdatei (z. B. host.crt ) ein, mit der das Server verglichen wird. Zertifikatsdateien müssen zunächst in das Verzeichnis /opt/eranger/ Kollektor /certificates der SKOOR Engine kopiert werden. Der Pfad kann durch Bearbeiten der Variablen http_cert_path in der Datei eranger- Kollektor geändert werden.

Host überprüfen

Nur sichtbar, wenn der Parameter „Peer überprüfen“ oben auf „Zertifikat muss authentisch sein“ eingestellt ist. Wählen Sie „Verifizierung muss erfolgreich sein“ aus, 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 zum Ändern der angeforderten Sprache der Webseite oder zum Ändern des Agent nützlich, mit dem sich SKOOR Engine beim Server identifiziert. Der 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.

Inhalte in einer Datei speichern

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

Es können Tags verwendet werden, zum Beispiel $DEVICE_ADDRESS$. Abhängig vom Suffix des Dateinamens (.txt oder .html) stellt der Browser die Seite beim Klicken auf den Dateilink unterschiedlich dar. Die Angabe eines klar definierten Dateinamens ist praktisch, wenn die Ausgabe von einem folgenden Parsefile-Job analysiert werden soll. Eine Ausgabedatei mit dem Namen wird erstellt, wenn dieses Feld leer bleibt, wobei N Ganzzahlen sind, die bei der ersten 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 . Üblicherweise akzeptierte Rückgabecodes sind:

200 OK und 302 Gefunden

Es kann aber auch jeder andere Wert überprüft werden.

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

100 Weiter

Dies 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-Anfrage). Wenn der Anfragetext groß ist, ist es ineffizient, ihn an einen Server zu senden, wenn eine Anfrage aufgrund ungeeigneter Header bereits abgelehnt wurde. Damit ein Server allein anhand der Header der Anfrage prüft, ob die Anfrage akzeptiert werden kann, muss ein Client „Expect: 100-continue“ als Header in seiner ersten Anfrage senden und prüfen, ob als Antwort ein Statuscode „100 Continue“ empfangen wird, bevor er fortfährt (bzw erhalten Sie 417 Expectation Failed und fahren Sie nicht fort).

200 OK

Standardantwort auf erfolgreiche HTTP-Anfragen.

201 erstellt

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

202 Akzeptiert

Die Anfrage wurde zur Bearbeitung angenommen, die Bearbeitung wurde jedoch noch nicht abgeschlossen. Es kann sein, dass auf die Anfrage letztendlich reagiert wird oder auch nicht, da sie möglicherweise abgelehnt wird, wenn die Verarbeitung tatsächlich stattfindet.

301 Dauerhaft verschoben

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

302 gefunden

Dies ist der beliebteste Weiterleitungscode, aber auch ein Beispiel dafür, dass die Industriepraxis dem Standard widerspricht. Die HTTP/1.0-Spezifikation erforderte, dass der Client eine temporäre Umleitung durchführte (der ursprüngliche beschreibende Ausdruck lautete „Temporarily verschoben“), gängige Browser implementierten dies jedoch als 303 See Other. Daher hat HTTP/1.1 die Statuscodes 303 und 307 hinzugefügt, um zwischen den beiden Verhaltensweisen zu unterscheiden. Allerdings verwenden die meisten Webanwendungen und Frameworks 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 Weiterleitung

In diesem Fall sollte die Anfrage mit einem anderen URI wiederholt werden, zukünftige Anfragen können jedoch weiterhin 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-Anfrage mit einer anderen POST-Anfrage wiederholt werden.

400 Ungültige Anfrage

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

401 nicht Autorisiert

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

403 Verboten

Bei der Anfrage handelte es sich um eine rechtliche Anfrage, der Server weigert sich jedoch, 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

Es wurde eine Anforderung an eine Ressource mit einer Anforderungsmethode gestellt, die von dieser Ressource nicht unterstützt wird. Verwenden Sie beispielsweise GET für ein Formular, das die Bereitstellung von Daten per POST erfordert, oder verwenden Sie PUT für eine schreibgeschützte 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 lediglich bedeutet, dass der Benutzer das Videofenster geschlossen oder zu einem anderen Video gewechselt hat.

409 Konflikt

410 Weg

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

411 Länge erforderlich

412 Vorbedingung fehlgeschlagen

413 Anforderungsentität 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 (z. B. wenn der Client einen Teil der Datei angefordert hat, der hinter dem Ende der Datei liegt).

417 Erwartung fehlgeschlagen

421 Es gibt zu viele Verbindungen von Ihrer Internetadresse

422 Nicht verarbeitbare Entität

Die Anfrage war wohlformuliert, konnte jedoch aufgrund semantischer Fehler nicht befolgt werden.

423 Gesperrt (WebDAV)

Die Ressource, auf die zugegriffen wird, ist gesperrt

424 Fehler bei der 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 im „Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol“.

426 Upgrade erforderlich

Der Client sollte zu wechseln.

449 Wiederholen mit

Eine Microsoft-Erweiterung: Die Anfrage 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 nicht unterstützt

506-Variante verhandelt auch

507 Nicht genügend Speicherplatz

509 Bandbreitenlimit überschritten

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

510 Nicht verlängert

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)

Inhaltsübereinstimmungen

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

Zertifikat gültig

Die Anzahl der Tage, bis das Remote-SSL-Zertifikat abläuft.

Fehlercode

Allgemeiner Job-Fehlercode (siehe Abschnitt Job-Fehlercodes )

http://$DEVICE_ADDRESS$

Ermöglichen