NSS

Notifications de bureau (Web Push)

DnC — 2020-12-11T08:31:20Z

Sur certaines configuration de système et de navigateur, la page d'accueil et les pages AutoPanel génèrent des Notifications de bureau (Web Push).

Notification de bureau [1]

Une notification de bureau est générée par la page d'accueil et les pages Autopanel à chaque alerte de niveau 6 et 7.

La présentation des notifications varie selon les plateformes. Voici par exemple comment une notification apparait sur Windows 7 :

Conditions pour le fonctionnement des notifications de bureau

Pour que les notifications de bureau fonctionnent, il est nécessaire que la page d'accueil ou une page autopanel soit ouverte dans un onglet de navigateur. Il n'est pas nécessaire que cet onglet soit actif ni qu'il soit visible, et la fenêtre du navigateur peut être réduite dans la barre des tâches (voir le cas particulier de la page Autopanel:fullscreen).

Les Notifications de bureau sont une fonctionnalité nouvelle que tous les navigateurs ne prennent pas encore en charge.

Afficher la page de synthèse
Au clic sur la notification, la page à l'origine de l'alerte est redirigé vers la page de synthèse de la tâche concernée.

Cas particulier : page Autopanel:full screen

Par défaut, la page Autopanel:full screen ne génère pas de notification lorsqu'elle est visible. En effet, cette page est destinée à être affichée en hauteur comme un panneau de synthèse visible de façon permanente. Il ne parait pas opportun de la rediriger.

Toutefois, ce comportement peut être configuré à la rubrique Gérer l'application -> Gérer les notifications -> Notification de bureau (Web Push) : Toujours activer les notifications de bureau émanant de la page AutoPanel:fullscreen.

[1] Les dénominations "Notification Web", "Web Push", "Push Notification", "Web Push Notification" sont également usitée.

Règles de surveillance HTTP

DnC — 2020-11-27T08:30:00Z

NSS permet d'émettre régulièrement une requête HTTP, attend une réponse et l'interprète en appliquant des règles. Si une situation d'erreur est détectée, NSS génère une alerte.

Les règles de surveillance HTTP offertes par NSS Lite vous permettent de vérifier non seulement qu'un site web fonctionne et n'a pas été détourné, mais aussi de contrôler la réponse de tout dispositif HTTP : DNS, Proxy, Web service etc.

NSS Lite permet notamment de tester une réponse au format JSON ou les valeurs data-xxx de HTML5.

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 :

https://buy.dnc.global/-Nos-produits-.html
 https://www.ossec.dnc.global/web/spip.php?article1

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 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 :

CONTAINS ns102.ovh.net
 CONTAINS dns102.ovh.net
 CONTAINS 51.178.18.44

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 :

SRCIP=NNN.NNN;NNN;NNN
 LENGTH>10000:6
 CONTAINS LeTitreDeLaPageParExemple:6
 NOT CONTAINS MySQL error
 NOT CONTAINS forbidden
 TIME<1000:2
 TIME<3000:3
 TIME<10000:4

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 :

TIME<2000:2
 TIME<5000:3"
 TIME<10000:4

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.

[1] Il est bien plus efficace de surveiller les DNS à l'aide d'une requête dns ://. Voyez : Règles de surveillance DNS.

AutoPanel : Panneaux à rafraîchissement automatique

DnC — 2020-09-23T08:47:13Z

NSS offre trois panneaux de synthèse dont les données sont rafraîchies périodiquement de façon automatique.
En plus de ces panneaux présentant des informations de toutes les tâches, il existe une page de synthèse permettant de suivre une tâche donnée.

Accéder aux panneaux

On accède aux panneaux par les boutons "Boxes", "Fullscreen" et "Lines" présents dans la page de sommaire et en tête des pages de suivi :

Rafraîchissement automatique

Le rafraîchissement automatique prend deux formes :
– La couleur de fond des boîtes et des graphes est mise à jour toutes les minutes pour répercuter l'état de l'alerte (priorité). Ceci ne met pas à jour les données, et en particulier, pas les graphiques.
– La page entière est remise à jour toutes les 10 minutes. Ceci met à jour les données et les graphiques. Cette deuxième forme est limité aux seuls onglets actifs (ayant le focus).

Avertissement : du fait de la charge de calcul induite par le rafraîchissement automatique, les périodicité indiquées et la disponibilité des différentes fonctionnalités décrites dans cette page sont sujettes à limitations selon les abonnements et/ou l'usage qui en est fait.

AutoPanel Boxes

AutoPanel Lines

AutoPanel Fullscreen

Ce panneau est conçu pour être affiché de façon permanente et être visible de loin, par exemple sur un écran séparé bien visible dans un espace ouvert [1].

Cliquez sur le titre de la tâche pour accéder à la page de synthèse.

Synthèse pour une tâche

C'est le panneau le plus utile pour suivre l'évolution d'une une tâche rapportant des erreurs.
Il permet de voir le détail des deux dernières alertes (1), le graphe des temps de réponse, et de naviguer vers les autres vues (2) et (3).

Notification de bureau (Web Push)

Sur certaines configuration de système et de navigateur, les pages AutoPanel génèrent des Notifications de bureau (Web Push).

[1] Le panneau est d'abord ouvert sur toute la surface de la fenêtre du navigateur. Actionnez la touche F11 pour passer en mode plein écran.

Règles de surveillance DNS

DnC — 2020-09-03T13:54:37Z

NSS permet d'émettre régulièrement une requête DNS, attend une réponse et l'interprète en appliquant des règles. Si une situation d'erreur est détectée, NSS génère une alerte.

Les règles de surveillance DNS offertes par NSS Lite vous permettent de vérifier tous les aspects de la configuration DNS du domaine considéré, en plus de la vérification du temps de réponse.

Requête DNS

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

dns:[//[:]/][?]

où :

– server : (facultatif) URL d'un serveur DNS particulier.
– domain (obligatoire) : le domaine de l'enregistrement dans la zone DNS.
– type : (facultatif, A) le type d'enregistrement dans la zone DNS du domaine : A, AAAA, CNAME, MX, NS, SOA, SPF, TXT. Si ce paramètre n'est pas compris, une erreur sera générée.

exemples :

dns:buy.dnc.global
 dns:dnc.global?NS
 dns://dns102.ovh.net/buy.dnc.global
 dns:degoy.com?A
 dns:degoy.com?AAAA
 dns://dns200.anycast.me/degoy.com?AAAA
 dns:degoy.com?MX
 dns://ns-219-a.gandi.net/www.spip.net
 dns://1.1.1.1/dnc.global /* Cloudflare resolver */
 dns://8.8.8.8/dnc.global /* Google resolver */
 dns://213.186.33.99/dnc.global?AAAA /* OVH resolver France*/
 dns://5.196.123.133/dnc.global?AAAA /* OVH resolver, Spain */
 dns://193.252.10.2/dnc.global /* Orange, Aubervilliers, France */

NSS émet la requête DNS sous la forme d'une commande Unix/Linux DIG de la forme suivante :
dig [ ][@server[:port] ]

Par exemple la réponse à la requête dns:degoy.com?MX sera traduite en :
dig MX degoy.com.

Dans la plupart des cas, il vous suffira d'inscrire une requête DNS dans le champ "Requête" de la tâche comme indiqué ci-dessus. Ne lisez la suite que si vous souhaitez analyser la réponse du DNS au-delà des règles par défaut.

Réponse

Si la requête réussit, NSS analyse la réponse retournée par DIG.
Voici par exemple la réponse à la requête dns:degoy.com ?MX (traduite en dig MX degoy.com) :

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.68.rc1.el6_10.7 <<>> MX degoy.com
 ;; global options: +cmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36151
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0
 
 ;; QUESTION SECTION:
 ;degoy.com. IN MX
 
 ;; ANSWER SECTION:
 degoy.com. 600 IN MX 5 mx1.mail.ovh.net.
 degoy.com. 600 IN MX 100 mx3.mail.ovh.net.
 degoy.com. 600 IN MX 1 mx0.mail.ovh.net.
 degoy.com. 600 IN MX 200 mail.rollernet.us.
 degoy.com. 600 IN MX 200 mail2.rollernet.us.
 degoy.com. 600 IN MX 50 mx2.mail.ovh.net.
 
 ;; Query time: 11 msec
 ;; SERVER: 213.186.33.99#53(213.186.33.99)
 ;; WHEN: Tue Sep 1 17:22:07 2020
 ;; MSG SIZE rcvd: 174

En cas d'échec, NSS enregistrera une erreur.

Règles implicites et par défaut

La réponse attendue par NSS à la suite d'une requête DNS figure dans le champ "Règles" de la tâche. Ce champ est facultatif. Qu'il soit renseigné ou non, des règles implicites s'appliquent :

status : NOERROR : NSS vérifie que la réponse du DNS comporte "status : NOERROR". Dans le cas contraire, une alerte de niveau 5 au moins est générée.

Temps de réponse : NSS surveille toujours le temps de réponse par rapport au délai moyen constaté pour la tâche.
Une alerte est générée avec un niveau égal à 2, 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.

Règles par défaut : de plus, si le champ règle n'est pas renseigné, NSS applique les règles suivantes, supposant une réponse attendue dans un délai inférieur à 50 ms :

TIME<50:3
 TIME<100:4
 TIME<500:5

Ces règles permettent déjà d'effectuer une surveillance efficace sans avoir à attribuer des règles à la tâche. Ainsi la simple requête :

dns://ns-219-a.gandi.net/www.spip.net

permet de surveiller la résolution du nom de domaine www.spip.net par un de ses serveurs DNS faisant autorité.

Règles applicables à la requête DNS

– 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.

– IPV4= NNN.NNN.NNN.NNN : la règle la plus essentielle, permettant de vérifier que le nom de domaine indiqué dans la requête DNS est résolu et égal à l'adresse IPv4 indiquée.

– QUERY TIME< nombre de ms : temps de réponse du serveur DNS.

Note : les règles TIME et MEAN prennent en compte le temps de réponse total de la requête, y compris les temps de transmission, que le DNS réponde ou non) alors que QUERY TIME porte sur le temps figurant dans la réponse du DNS.

– CONTAINS chaîne de caractères : cette règle permet de vérifier la présence d'une chaîne dans la réponse brute.

– 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 brute. La chaîne de caractère peut être une expression régulière standard, il est donc possible d'effectuer n'importe quelle vérification dans la réponse. Cependant, l'utilisation de la règle ARRAY sera le plus souvent préférable.

– ARRAY[index]= chaîne de caractères : Vérifie que la chaîne de caractères se trouve dans la valeur du tableau à l'indice A. Notons qu'il s'agit d'une inclusion et non d'une égalité, la règle se comportant comme CONTAINS. L'index peut être multidimensionnel.

– ARRAY[index]> nombre : Vérifie que la valeur du tableau à l'indice A est supérieure au nombre indiqué. L'index peut être multidimensionnel.

En savoir plus sur la règle ARRAY...

La règle ARRAY... complète le jeu de règles pour tester n'importe quelle information retournée par la requête DNS.

Comment NSS traduit les réponses

Pour effectuer une requête, NSS fait appel à DIG puis décompose la réponse dans un tableau associatif. Les règles portent sur les éléments de ce tableau.
En règle générale, vous n'aurez pas à vous occuper de ce tableau. Cependant, la formulation d'une règle ARRAY suppose de bien connaître la structure de ce tableau.

Voici comment, en interne, NSS traduit en tableau la requête précédente :

: array =
RAW: string = " ; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> www.spip.net\n;; global options: +cmd\n;; Got answer:\n;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 594\n;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3\n\n;; OPT PSEUDOSECTION:\n; EDNS: version: 0, flags:; udp: 4096\n; COOKIE: f182cd5130c105c8056d4eed5f50bf97a6b668e584c7b2e7 (good)\n;; QUESTION SECTION:\n;www.spip.net.\t\t\tIN\tA\n\n;; ANSWER SECTION:\nwww.spip.net.\t\t1979\tIN\tA\t151.80.20.125\n\n;; AUTHORITY SECTION:\nspip.net.\t\t34795\tIN\tNS\tns-145-c.gandi.net.\nspip.net.\t\t34795\tIN\tNS\tns-77-b.gandi.net.\nspip.net.\t\t34795\tIN\tNS\tns-219-a.gandi.net.\n\n;; ADDITIONAL SECTION:\nns-219-a.gandi.net.\t34795\tIN\tA\t173.246.100.220\nns-219-a.gandi.net.\t34795\tIN\tAAAA\t2001:4b98:aaaa::dc\n\n;; Query time: 0 msec\n;; SERVER: 127.0.0.1#53(127.0.0.1)\n;; WHEN: Thu Sep 03 10:04:07 UTC 2020\n;; MSG SIZE rcvd: 203\n"
; <<>> DIG 9.11.5-P4-5.1+DEB10U2-DEBIAN <<>> WWW.SPIP.NET: string = ""
GLOBAL OPTIONS: string = " +cmd "
GOT ANSWER: string = " "
HEADER: array =
opcode: string = " QUERY"
status: string = " NOERROR"
id: string = " 594 "
flags: string = " qr rd ra"
QUERY: string = " 1"
ANSWER: string = " 1"
AUTHORITY: string = " 3"
ADDITIONAL: string = " 3 "
OPT PSEUDOSECTION: string = " ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: f182cd5130c105c8056d4eed5f50bf97a6b668e584c7b2e7 (good) "
QUESTION SECTION: string = "www.spip.net. IN A "
QUERY TIME: string = " 0 msec "
SERVER: string = " 127.0.0.1#53(127.0.0.1) "
WHEN: string= "Thu Sep 03 10:04:07 UTC 2020"
MSG SIZE RCVD: string = " 203 "
ANSWER SECTION: array =
0: array =
host: string = "www.spip.net"
class: string = "IN"
ttl: long = 1974
type: string = "A"
ip: string = "151.80.20.125"
AUTHORITY SECTION: array =
0: array =
host: string = "spip.net"
class: string = "IN"
ttl: long = 34790
type: string = "NS"
target: string = "ns-145-c.gandi.net"
1: array =
host: string = "spip.net"
class: string = "IN"
ttl: long = 34790
type: string = "NS"
target: string = "ns-77-b.gandi.net"
2: array =
host: string = "spip.net"
class: string = "IN"
ttl: long = 34790
type: string = "NS"
target: string = "ns-219-a.gandi.net"
3: array =
host: string = "spip.net"
class: string = "IN"
ttl: long = 34790
type: string = "NS"
target: string = "ns-77-b.gandi.net"
4: array =
host: string = "spip.net"
class: string = "IN"
ttl: long = 34790
type: string = "NS"
target: string = "ns-145-c.gandi.net"
5: array =
host: string = "spip.net"
class: string = "IN"
ttl: long = 34790
type: string = "NS"
target: string = "ns-219-a.gandi.net"
ADDITIONAL SECTION: array =
0: array =
host: string = "ns-219-a.gandi.net"
class: string = "IN"
ttl: long = 34790
type: string = "A"
ip: string = "173.246.100.220"
1: array =
host: string = "ns-219-a.gandi.net"
class: string = "IN"
ttl: long = 34790
type: string = "AAAA"
ipv6: string = "2001:4b98:aaaa::dc"
2: array =
host: string = "ns-219-a.gandi.net"
class: string = "IN"
ttl: long = 34790
type: string = "A"
ip: string = "173.246.100.220"
3: array =
host: string = "ns-219-a.gandi.net"
class: string = "IN"
ttl: long = 34790
type: string = "AAAA"
ipv6: string = "2001:4b98:aaaa::dc"
IPV4: string = "151.80.20.125"

Télécharger

Exemples de règles ARRAY

ARRAY[HEADER][AUTHORITY]= 2 /* vérifier qu'il y a deux serveurs faisant autorité */
 ARRAY[HEADER][ADDITIONAL]> 0 /* vérifier qu'il y a au moins un serveur additionnel */
 ARRAY[RAW]=EDNS /* vérifie la prise en charge d'EDNS */
 ARRAY[AUTHORITY SECTION][0][target]=ns-145-c.gandi.net

Le dernier exemple montre une difficulté : s'il y a plusieurs serveurs faisant autorité, quel est le rang de celui dont on veut vérifier la présence ? Le signe '*' dans la règle ARRAY[]= permet de tester tous les index :

ARRAY[AUTHORITY SECTION][*][target]=ns-145-c.gandi.net

Inversion, combinaison, niveau d'alerte

L'inversion des règles par NOT est possible pour les règles TIME, MEAN et CONTAINS.

La combinaison des règles et la définition du niveau d'alerte se font de la même manière que dans le cas des Règles de surveillance HTTP.

Quel serveur DNS répond ?

Une requête DNS précise le serveur à interroger en fournissant le paramètre @ comme dans les exemples suivants :

dns://ns-219-a.gandi.net/www.spip.net
 dns://2001:4b98:aaaa::dc/www.spip.net

Si la requête ne précise pas le serveur, ce sera le resolver local de NSS à l'adresse 127.0.0.1 qui répondra. Bien que ce soit approprié dans certains cas, ce n'est pas la meilleure façon de s'assurer du bon fonctionnement des DNS d'un domaine, car le resolver n'effectuera pas de récursion avant que le SOA ait expiré.

De plus, quand le résolver local répond, il le fait en Query time : 0 msec. Ce n'est pas très intéressant à savoir !

Quel serveur DNS faut-il interroger ?

Pour vous assurer du bon fonctionnement des DNS, il faut s'adresser à un serveur autorité du domaine (domain authoritative nameserver). Dans l'exemple précédent, nous avons interrogé un des trois serveurs autorité pour le domaine www.spip.net.

On peut connaître la liste des serveurs autorité pour le domaine en émettant la commande suivante en mode de commande :

dig www.spip.net
 
 qui retourne :
 
 ; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> www.spip.net
 ;; global options: +cmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3800
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 7
 
 ;; OPT PSEUDOSECTION:
 ; EDNS: version: 0, flags:; udp: 4096
 ; COOKIE: 798ddf1f8a880829b2ae2fae5f4f590bd9ae0131be4067c2 (good)
 ;; QUESTION SECTION:
 ;www.spip.net. IN A
 
 ;; ANSWER SECTION:
 www.spip.net. 1427 IN A 151.80.20.125
 
 ;; AUTHORITY SECTION:
 spip.net. 126583 IN NS ns-219-a.gandi.net.
 spip.net. 126583 IN NS ns-77-b.gandi.net.
 spip.net. 126583 IN NS ns-145-c.gandi.net.
 
 ;; ADDITIONAL SECTION:
 ns-77-b.gandi.net. 590 IN A 213.167.230.78
 ns-145-c.gandi.net. 545 IN A 217.70.187.146
 ns-219-a.gandi.net. 126583 IN A 173.246.100.220
 ns-77-b.gandi.net. 590 IN AAAA 2001:4b98:aaab::4e
 ns-145-c.gandi.net. 545 IN AAAA 2604:3400:aaac::92
 ns-219-a.gandi.net. 126583 IN AAAA 2001:4b98:aaaa::dc
 
 ;; Query time: 0 msec
 ;; SERVER: 127.0.0.1#53(127.0.0.1)
 ;; WHEN: Wed Sep 02 08:34:19 UTC 2020
 ;; MSG SIZE rcvd: 291


Une bonne requête serait donc :
dns://ns-219-a.gandi.net/www.spip.net
Les resolvers publics sont également intéressants, par exemple :
dns://1.1.1.1/www.spip.net /* Cloudflare resolver */
 dns://8.8.8.8/www.spip.net /* Google resolver */
Alerte
...
Note à propos des codes HTTP
...



Caractéristiques et Limitations
DnC — 2020-07-13T07:14:14Z
Périodicité
Lorsque NSS Lite doit télécharger le corps de la réponse (body) pour analyser les réponses attendues, la période de répétition des requêtes est de 10 minutes. 

Lorsque les requêtes n'ont besoin que de l'en-tête de la réponse (header) la période de répétition est une minute.
Requête HTTP
La requête est limitée aux arguments scheme (http ou https), host, path, query et fragment comme dans :

scheme://host/path?query#fragment

Les arguments scheme et host sont obligatoires.

Les arguments path, query et fragment sont facultatifs.
Exemple d'URL HTTP valide :

https://oa.dnc.global/web/-Decouvrir-.html#saasetoidcunmariagereussigraceaoauthsd
L'URL doit être libellé en ASCII, les noms de domaine internationalisés (contenant des caractères non ASCII) échoueront.
NSS Pro permet d'utiliser des URLs plus étendues.
Méthode HTTP de la requête
NSS Lite émet une requête HTTP avec la méthode GET si le corps de la réponse est nécessaire. Sinon, la méthode est HEAD.
Dans l'état actuel du développement, NSS ne traite pas les méthodes POST, PUT, DELETE, TRACE et CONNECT.
Limitation du téléchargement
Lorsque le corps de la réponse est nécessaire, NSS Lite ne télécharge que les 20 000 premiers caractères. Il s'agit de la longueur avant décompression, la longueur des données obtenues peut être significativement plus importante.
Il faut tenir compte de cette limitation pour les règles nécessitant le corps de la réponse, tels que CONTAINS.
Il faut noter que la présence d'un fragment dans l'URL ne change rien au fait que les données sont chargées à partir du début de la page. La présence de l'ancre du fragment et de texte à la suite n'est donc pas garantie.
Analyse de la réponse
Si la réponse est une liste ou un tableau JSON (le type Mime de la réponse est "application/json"), NSS Lite décode le tableau dont le contenu peut être analysé avec les règles JSON_xxx.
Dans tous les autres cas, NSS Lite analyse le corps de la réponse comme une simple chaîne.
Le codage attendu est UTF-8.


Surveillance du temps de réponse
DnC — 2020-07-05T08:37:35Z

		NSS surveille le temps de réponse d'une tâche et génère des alertes. 

Selon le principe de plus grande simplicité, le traitement par défaut (sans avoir à préciser de règle) est suffisant pour s'assurer du bon fonctionnement d'un site Web.
Il est cependant possible de définir de façon fine la surveillance des temps de réponse et la génération des alertes correspondantes.
		Traitements par défaut
Temps de réponse anormal
Une règle implicite fait que NSS surveille en permanence 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, ou le niveau indiqué dans la définition de la tâche, si le temps de réponse excède 4 fois le temps de réponse moyen.
Les règles TIME et MEAN décrites ci-après complètent ce test sans le modifier.
Absence de réponse ( Request Timeout )
En cas d'absence de réponse, NSS génère un code HTTP 408 ( Request Timeout ) et une erreur de niveau 6 ( Alerte ).
Règles de surveillance du temps de réponse
Le champ "Règles" de la définition de la tâche peut recevoir une ou plusieurs règles relatives au temps de réponse :
– 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.
Exemple pour une page web dont on attend une réponse généralement inférieure à 1s :

TIME>3000
La règle inverse NOT TIME peut être utile pour détecter un défaut de calcul de la page, ou une redirection sur une page de faible contenu ou toute erreur se traduisant par un temps de réponse anormalement faible. Exemple :

NOT TIME>100
– 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.
NSS entretient pour chaque tâche une valeur moyenne du temps de réponse constaté sous la forme d'une moyenne mobile calculée sur les 10 dernières réponses sans autre erreur. Il s'agit du délai moyen évoqué précédemment.
Exemple pour une page web dont on attend une réponse généralement inférieure à 1s :

MEAN<1500
Cette règle est bien adaptée à la génération d'une notification à bon escient en y associant un niveau d'alerte adéquat, comme expliqué au paragraphe suivant :

MEAN<2000:5
Dans le même esprit, la règle inverse NOT MEAN peut être utile pour alerter sur une réponse anormalement et durablement brève.
Conseils pour bien configurer la surveillance du temps de réponse
Le travers des systèmes de surveillance et d'alerte consiste à trop alerter. Les temps de réponse d'une page Web dépendent de nombreux facteurs et sont très variables.
Vous voudrez être averti qu'une page web présente un temps de réponse excessif de façon durable, et non à chaque dépassement. Pour cela :
– si vous comptez sur la surveillance par défaut (vous n'avez pas fixé de règle TIME ou MEAN, ni fixé de niveau d'alerte pour la tâche, ni fixé de niveau d'alerte minimum pour l'envoi des notifications), tout va bien : vous ne serez averti qu'en cas de défaut durable.
– si vous avez fixé un niveau d'alerte pour la tâche, veillez à ce que ce niveau soit inférieur d'une unité au niveau de notification. Le mécanisme d'élévation du niveau en cas de répétition vous permettra d'être averti en cas de défaut durable.
– si vous définissez des règles TIME ou MEAN, fondez-vous plutôt sur une règle MEAN ou faites en sorte qu'une règle TIME ne provoque une notification qu'en cas de temps de réponse très élevé de façon durable.
Voici un exemple de trois règles pour une page dont on attend un temps de réponse généralement inférieur à 1s. Les commentaires supposent un niveau d'alerte de la tâche de 4 et un niveau d'alerte minimum pour l'envoi des notifications de 5 (ce sont les valeurs par défaut) :
MEAN<2000:5 Une notification sera générée si le temps de réponse moyen dépasse 2s.
TIME<10000:4 Une notification sera générée si le nombre de réponses présentant un délai supérieur à 10s est supérieur à 60 dans la même suite d'événements (élévation du niveau de 4 à 5).
TIME<1000:3 Un avertissement est inscrit dans les Alertes.
Par ailleurs, si on estime que la réponse n'a aucune raison d'être générée en moins de 30ms, on peut ajouter :

NOT MEAN>30:5
Graphe du temps de réponse
La page "Statistiques" présente un historique du temps de réponse ainsi que des statistiques :
La coloration du fond du graphique permet de repérer rapidement les alertes ( ici du jaune correspondant aux niveaux 2 et 3 ).
A propos, ce temps de réponse, c'est quoi ?
Pour comprendre ce qu'est ce temps de réponse, il faut considérer :
dans le cas d'une requête HTTP :
– qu'il ne s'agit pas du temps total de génération de la page par le navigateur (comprenant le chargement des images, du css, du code javascript et de leur interprétation), mais seulement le temps écoulé entre la demande et le chargement de la réponse. Dans le cas d'une page HTML, cela correspondrait au temps nécessaire pour le chargement du code HTML de la page, avant toute interprétation. Cela correspondrait généralement à l'instant 'start'.
– "correspondrait" car en réalité, dans le cas général, NSS ne charge qu'une partie du corps de la page. Vous pouvez connaître le nombre d'octets téléchargés en consultant le champ réponse de la table Alertes où figure par exemple : 'payload longueur = 20000'.

L'intérêt de limiter le téléchargement est de permettre de ne pas mesurer des temps dépendant du volume de la réponse.
On voit donc qu'il ne s'agit pas de la performance de la page.
dans le cas d'une requête DNS :
– qu'il s'agit de même du temps total comprenant le temps de réponse du DNS et les délais de transmission. Il ne s'agit donc pas du temps de réponse du DNS que l'on peut surveiller avec les règles QUERY TIME et MEAN QUERY TIME.
Le temps de réponse mesuré par NSS est représentatif de la charge du serveur et du réseau. Ses excès sont significatifs d'une surcharge.

N'utilisez pas un outil de mesure de la performance pour surveiller vos sites web !
De nombreux outils sont disponibles pour surveiller le temps de présentation d'une page Web, mais c'est une opération d'optimisation à effectuer en cours de développement. Après la recette de la version courante de l'application, cette performance ne dépend plus que du serveur hôte et de sa connexion au réseau. C'est à cela que s'attache NSS.
Répétons-le : utiliser un outil de suivi de la performance d'un site Web, c'est risquer de ne pas voir des quantités de défauts. Pour la plupart de ces outils en effet, une page en erreur est une page rapide !
Voyez par exemple ce que répond cet outil bien connu pour une redirection 301 erronée, débouchant sur une page vide :
Performance : 100% ; intéressant, n'est-ce pas ?


Démarrage rapide
DnC — 2020-07-03T06:31:29Z
-
Français


Présentation de NSS Lite
DnC — 2020-07-03T06:29:04Z
-
Français


NSS : Usages avancés
DnC — 2020-07-01T08:01:20Z
Test des DnS d'un domaine
Une tâche de surveillance d'un DNS peut être générée de la façon suivante :
Cette tâche appelle la page : https://testdns.fr/?ndd=buy.dnc.glo... qui teste les DNS du domaine buy.dnc.global. Voici les règles :
CONTAINS ns102.ovh.net
 CONTAINS dns102.ovh.net
 CONTAINS 51.38.250.74
 CONTAINS Parfait, vous obtenez des DNS valides
On vérifie que le DNS fournit bien les deux DNS du domaine et son IPv4. 

La dernière règle est peut-être superflue.
NSS Pro propose également des Règles de surveillance DNS.
Surveillance du fonctionnement d'un site Web
Lorsqu'un site web est défaillant, il y a de bonnes chances pour qu'il réponde avec un code HTTP > 200. NSS détecte ce genre de situation sans nécessité de préciser une réponse attendue (champ Règles vide).
Mais que se passe t-il si le code HTTP de la réponse est 200 (OK) et que la page est mal formée ? C'est par exemple le cas quand la base de données est en panne : la page affichera probablement un message d'erreur. La plupart des systèmes de surveillance ne détecteront pas cette situation. Pire encore : ceux des systèmes qui sont fondés sur la vitesse de réponse vont trouver que la page est particulièrement performante !
Il faut donc vérifier le corps de la réponse, par exemple comme ceci :
LENGTH>10000
 CONTAINS Cherbourg Maquettes
 NOT CONTAINS MySQL error
De plus, on pourra vérifier que l'URL n'est pas détournée en ajoutant les règles suivantes :
SRCIP=37.187.62.111
 SAMELOCATION
Enfin, si l'on souhaite surveiller la vitesse de réponse du site, on pourra ajouter :
TIME<1000:3
 TIME<3000:4
 TIME<10000:5
 MEAN<2000:5
Les deux dernières règles provoqueront une notification d'alerte.
Tests selon les applications
En cas d'erreur fatale, la plupart des applications affichent une page comportant un message d'erreur qui permettra d'appliquer une règle simple. Exemples :
NOT CONTAINS fatal error:6 La plupart des sites ???
NOT CONTAINS mysql error:6 La plupart des sites utilisant MySQL
NOT CONTAINS tep stop:6 Site de vente osCommerce
Comment faire pour que l'analyse ne prenne pas en compte les hits de nss ?
Lorsque l'on utilise un outil d'analyse tel que Google Analytics ou Matomo (ex Piwik), on souhaite évidemment ne pas compter les interrogations de NSS.
L'user agent indiqué dans le header des requêtes issues de NSS contient la chaîne 'NSS'. Sachant cela, il est possible d'indiquer une règle pour éliminer ces requêtes.
Avec Matomo, par exemple, Il faut inscrire NSS dans la liste globale des agents utilisateurs à exclure.


Gérer : Voir / éditer les tâches
DnC — 2020-06-25T10:00:07Z
Voir la liste des tâches
Accédez à Gérer : Voir/éditer les tâches :
Le tableau présente 5 colonnes :
– N° : un numéro attribué à la tâche par le système, ne peut être changé.
– statut : une icône représentant le statut de la tâche :
 blanc : "en cours de rédaction" : la tâche n'est pas exécutée, elle est conservée en mémoire.
 vert : "publie" : la tâche est en cours d'exécution,
 noir : "à la poubelle" : la tâche sera détruite par le système.
– Date : la date de création de la tâche, non modifiable.
– Une colonne contenant deux liens :
 Voir/éditer : affiche le formulaire de présentation et/ou d'édition de la tâche,
 Supprimer : Effacer la tâche immédiatement. Contrairement au statut "à la poubelle", cette action provoque l'effacement de toutes les données relatives à la tâche.
Changer le statut d'une tâche
Placez la souris sur l'icône de statut et sélectionnez le statut désiré :
Seules les tâches de statut "publie" sont prises en compte pour la limitation du nombre maximum de tâches autorisées par l'abonnement. 

Vous pouvez donc mettre de côté une tâche en lui attribuant le statut "en cours de rédaction". Vous pouvez créer ainsi un nombre illimité de tâches.
Éditer une tâche
Lorsque vous cliquez sur le lien "Voir/éditer", le formulaire d'édition de la tâche apparaît ( il est identique au formulaire de création ) :
Titre : Un titre de votre choix. Inscrivez un titre court et explicite. Le titre est obligatoire et peut être changé à tout moment.
Requête : la requête émise. Dans une première approche, considérez qu'il s'agit de l'adresse d'un site ou d'une page hypertexte sur Internet (une URL). Vous devez indiquer le schéma d'URL ( http://, https://). Vous pouvez indiquer une URL complète, avec chemin et requête. 

Exemples d'URL valides :

https://oa.dnc.global/

https://oa.dnc.global/web/-OpenID-Connect-6-.html

https://buy.dnc.global/Network-Soft-Scanning-NSS-19.html?lang=de
Règles : Réponse attendue. Voyez : Règles de surveillance HTTP.

Par défaut, NSS applique un jeu de règles standard. Vous pouvez donc laisser ce champ vide, cela suffit dans la plupart des cas à s'assurer qu'un site Web fonctionne.
Niveau de l'erreur : Lorsque le niveau de l'erreur n'est pas défini par la règle, définit le niveau de l'erreur générée. Valeur de 0 à 7. défaut = 4. Le niveau de l'erreur conditionne l'émission d'une notification en cas d'erreur de la tâche. Voyez : Gérer les notifications.

Notez que le niveau d'erreur peut être défini règle par règle, le niveau assigné à la tâche étant alors la valeur par défaut.
Statut de la tâche : 

Sélectionnez le statut "publié en ligne" pour activer la tâche.