Requête HTTP

NSS Lite accepte une requête HTTP limitée aux composants scheme, host, path, query et fragment.

Une requête HTTP est inscrite dans le champ "Requête" de la tâche sous le format :

Exemples :

Champ "Règles" vide

La réponse attendue par NSS à la suite d’une requête HTTP figure dans le champ "Règles" de la tâche. Ce champ est facultatif.

Lorsque le champ "Règles" n’est pas renseigné, NSS prend en compte le code HTTP retourné dans l’en-tête de la réponse, sans considération de la charge utile de la réponse :

– Lorsque le code HTTP de la réponse est 500 ou plus (erreur du serveur), un événement est créé avec un niveau égal à 6 ( Alerte ).

– Lorsque le code HTTP de la réponse est 400 ou plus et inférieur à 500 (erreur du client web), un événement est créé avec un niveau égal à 5 ( Critique ).

– Lorsque le code HTTP de la réponse est 300 ou plus et inférieur à 400 (redirection), NSS tente de suivre la redirection. En cas de succès, le code HTTP est 200.

– Lorsque le process s’est terminé sans erreur (code HTTP < 400), NSS applique un jeu de règles standard (voir plus loin).

Champ "Règles" non vide

Analyse de la réponse

Une réponse HTTP comprend une "entête" (response header) et une "charge utile" (response payload) aussi désigné par "corps" (body) de la réponse.

NSS traite d’abord la réponse HTTP comme indiqué ci-dessus. Lorsque le process s’est terminé sans erreur (code HTTP < 400), NSS traite la réponse en appliquant les règles indiquées dans le champ "Règles" de la tâche.

Si le test échoue, un événement est créé avec un niveau égal à 4, ou le niveau indiqué dans la définition de la tâche.

Il y a deux types de règles : les "règles générales" qui ne tiennent pas compte de la charge utile de la réponse, et celles qui s’appliquent à cette charge utile.

Règles générales

– TIME< nombre de ms : Vérifie que le serveur retourne la réponse dans un délai inférieur à la valeur indiquée en ms.

– MEAN< nombre de ms : Vérifie que le serveur retourne la réponse dans un délai moyen inférieur à la valeur indiquée en ms.

– SAME LOCATION : Contrôle que l’URL de la réponse est identique à la requête (il n’y a pas eu de redirection).

– SRCIP=nnn.nnn.nnn.nnn : Contrôle que l’hôte de la réponse réelle a bien pour IPv4 l’adresse indiquée (IP source). Permet notamment de vérifier qu’une redirection ne sort pas de la machine ciblée par la requête.

– SAME HOST : contrôle que le domaine de la réponse est identique à celui de la requête. Permet notamment de vérifier qu’une redirection ne sort pas du domaine initial.

– HTTP=nnn : le code HTTP de la réponse doit avoir la valeur indiquée.

Règles d’analyse de la charge utile de la réponse

– NULL : le corps de la réponse doit avoir une longueur nulle.

Notes :

• NSS Lite ne charge pas plus que 20 000 octets du corps de la réponse. Il faut en tenir compte pour les règles qui suivent.
• Attention : si l’affichage correct de la page requiert que l’utilisateur soit connecté, ou que des choix antérieurs aient été faits par l’utilisateur, il est possible que les données attendues ne figurent pas dans la réponse. Une solution peut être de préciser certains paramètres dans la requête.

– LENGTH>nombre entier : le corps de la réponse doit avoir une longueur supérieure ou égale à la valeur indiquée. Bien noter qu’il s’agit de la réponse HTML, et non de la section body de la page HTML.

– STRING=chaîne de caractères : le corps de la réponse doit être égal à la chaîne indiquée.

– CONTAINS chaîne de caractères : le corps de la réponse doit contenir la chaîne indiquée.

Notes :

• Dans le cas d’un site Web dont le contenu est complété après le chargement initial de la page (par un script ou au moyen d’un Web Socket), NSS ne prendra en compte que le contenu initial qui peut être incomplet voire vide.

– MATCH chaîne de caractères : cette règle permet de vérifier la présence d’une chaîne quelconque dans la réponse. La chaîne de caractère peut être une expression régulière, il est donc possible d’effectuer n’importe quelle vérification dans la réponse.

– JSON tableau[’a’][’b’]...=value, JSON tableau[’a’][’b’]...>value : La réponse doit être un tableau associatif au format JSON. La règle teste la valeur de l’élément tableau [’a’][’b’]...
Le nombre de dimensions de l’index (profondeur de récursion) est limité à 10.
Contrairement aux autres règles, les noms du tableau et des index sont sensibles à la casse.

– DATA-XXX=value, DATA-XXX>value : La réponse doit contenir l’attribut HTML5 data-xxx. NSS compare la valeur de l’attribut à la valeur indiquée dans la règle. Notez que si la réponse comporte plusieurs data-xxx, seule la première occurrence sera testée.

Inversion de la règle

On peut faire précéder les règles d’analyse de la charge utile par NOT pour tester la condition inverse (c’est souvent plus intéressant), sont ainsi valides les règles : NOT NULL, NOT HTTP=, NOT LENGTH=, NOT STRING=, NOT CONTAINS etc..
Cependant, MATCH ne peut être inversée.

Exemples de règles

SRCIP= 52.128.11.2 Vérifie que la réponse provient bien de l’IP indiquée.

CONTAINS <body> vérifie que le document retourné comporte bien un corps (sans préjuger de son contenu).

LENGTH>10000 vérifie que la réponse a une longueur > 10000. Permet de détecter une erreur de génération de la page si son contenu (header compris) est normalement supérieur à la valeur indiquée.

NOT CONTAINS tep stop La réponse ne doit pas contenir la chaîne ’tep stop’ (qui est une erreur fatale retournée par osCommerce).

NOT JSON Valeurs['temperature']['sortie']>55 La réponse doit être un tableau JSON ’Valeurs’ dont l’élément [’temperature’][’sortie’] doit être inférieur ou égal à 55.

DATA-price>50 Le prix indiqué dans le champ data-price doit être supérieur à 50.

Combinaison de plusieurs règles pour une même tâche

Plusieurs règles peuvent être indiquées dans le champ "Règles" à raison d’une par ligne.
Elles sont combinées avec l’opérateur logique AND, c’est à dire que la tâche est en erreur si une des règles est vérifiée.

Le nombre de règles n’est limité que par la longueur totale du champ "Règles", limité à 1024 caractères.

Voici un exemple de surveillance des DNS d’un domaine [1], dans lequel les règles sont appliquées à la réponse d’un site de test de DNS tel que testdns.fr :

Cet autre exemple montre comment vérifier qu’une page est non-vide, n’affiche pas une erreur MySQL, n’a pas été détournée, n’a pas été rejettée par un firewall et comment suivre le temps de réponse :

Bien noter que des règles telles que ’NOT CONTAINS MySQL error’ ou ’NOT CONTAINS forbidden’, ne sont pas universelles : elles dépendent de l’application ou du firewall.

Jeu de règles standard appliqué par défaut

Quand la champ règles est vide, NSS applique le jeu de règles standard (ne nécessitant pas le chargement du corps de la réponse) suivant :

Temps de réponse

Si aucune règle n’a généré d’erreur ( dont les règles TIME et MEAN décrites précédemment ), NSS applique une règle implicite qui compare le temps de réponse par rapport au temps de réponse moyen constaté pour la tâche. Une alerte est générée avec un niveau égal à 2 ( Notice ), ou le niveau indiqué dans la définition de la tâche, si le temps de réponse excède 4 fois le délai moyen.

Pour plus de détails sur ce sujet, voyez : Surveillance du temps de réponse.

Niveau d’alerte

Définition

NSS classe les événements selon leur gravité en 8 niveaux, décrits dans le tableau suivant :

Niveau	Sévérité	Elévation
7	Urgence : le système est inutilisable	NA
6	Alerte : une action doit être entreprise immédiatement	7 si nombre dépasse 5
5	Condition critique	6 si nombre dépasse 5
4	Erreur	5 si nombre dépasse 60
3	Attention	NA
2	Information significative	3 si nombre dépasse 60
1	Information	NA
0	Information de débogage	NA

Attribution du niveau d’alerte

En cas d’erreur, NSS attribue par défaut un niveau d’alerte de 4.

Ce niveau d’alerte peut être modifié pour une tâche donnée en entrant une valeur différente dans le champ "Niveau de l’erreur" du formulaire de création/édition de la tâche. Ainsi défini, le niveau d’erreur s’applique quelle que soit la règle en erreur.
Il est possible de définir un niveau d’erreur particulier pour la règle en la faisant suivre de ’:N’ où N est le niveau désiré, comme dans l’exemple suivant :
LENGTH>10000:6

Bien entendu, les niveaux d’erreur définis doivent l’être en cohérence avec le "Niveau d’alerte minimum pour l’envoi" défini pour les notifications (voir plus loin).

Compactage des événements

Lorsque des événements identiques se succèdent, NSS ne génère pas une alerte à chaque fois, mais comptabilise le nombre de répétition. Une seule ligne apparaît dans la table Alertes.
Comme indiqué dans la colonne "Elévation", le niveau d’alerte est levé d’une unité quand la même erreur se répète.
Ainsi, la table Alertes reste synthétique, et la cadence des notifications raisonnable.

Notification

Le formulaire Gérer les notifications permet de définir les adresses de destination et le niveau minimal déclenchant une notification.

Par défaut, le niveau d’alerte est 5 (envoyer "conditions critiques" et au-dessus).
On peut modifier ce niveau dans le champ "Niveau d’alerte minimum pour l’envoi", en indiquant un chiffre de 0 (envoyer toutes les alertes) à 7 (envoyer seulement "système inutilisable").

NSS émet un message de notification au début d’une série d’alerte et en cas d’élévation du niveau.