Supervision Web

Dans Pandora FMS, le Web Server fonctionne sur un serveur indépendant, le Network Server. Ce système fonctionne selon le principe de transaction web, où chaque transaction complète vers une ou plusieurs pages WEB est définie par une ou plusieurs étapes consécutives, qui doivent se terminer de manière satisfaisante pour considérer que la transaction a réussi.

Le Network Server est actif par défaut. En fonction du nombre de requêtes, il peut être nécessaire d'augmenter le nombre de threads et le timeout par défaut :

network_threads 4
web_timeout 60

Chaque module peut également utiliser un délai d'attente différent.

/etc/pandora/pandora_server.conf

# Uncomment to perform web checks with LWP instead of CURL.
#web_engine lwp

Au redémarrage de Pandora FMS Server, LWP sera utilisé pour effectuer les vérifications web au lieu du binaire Curl.

Après avoir donné un nom au module, on doit choisir le type de module à utiliser :

1. Remote HTTP module to check latency : Obtient le temps de charge total qui s'écoule depuis la première requête jusqu'à la vérification de la dernière.
   
   
2. Remote HTTP module to check server response : Ce type de module fonctionne de manière similaire au précédent, à la seule différence qu'il n'a pas de seuils. Les seules valeurs qu'il obtient sont 1 pour l'état normal et 0 pour l'état critique.
   
   
3. Remote HTTP module to retrieve numeric data : En utilisant une expression régulière, ce module l'applique sur la réponse HTTP pour obtenir une valeur numérique.
   
   
4. Remote HTTP module to retrieve string data : En utilisant une expression régulière, ce module la compare sur la réponse HTTP pour obtenir une valeur textuelle.
   
   
5. Remote HTTP module to check server status code : La vérification de base d'une page web consiste à obtenir rapidement son code d'état et à savoir à l'avance si d'autres vérifications peuvent être effectuées.
   
   

Cette zone de texte est accompagnée de trois boutons pratiques :

• Bouton Load basic.

Place toujours le code suivant peu importe s'il fonctionne ou s'il est compatible avec le type de module sélectionné :

task_begin
get https://demoweb.com/page/
check_string text string or HTML code to search (regexp)
task_end

Le code précédent est purement illustratif, chaque type de module web a ses instructions spécifiques et/ou appropriées.

• Bouton Check.

En appuyant dessus, la syntaxe des commandes insérées sera vérifiée pour voir si elles sont valides, sinon une icône jaune apparaîtra avec un message contextuel en plaçant le pointeur dessus. Essentiellement, il s'assure que l'on commence par task_begin et qu'au moins une balise task_end apparaisse (celle-ci doit toujours apparaître en dernier). On devra vérifier, selon le type de module, les paramètres appropriés pour chaque requête web.

• Bouton Debug.

Souvent, il est nécessaire de déterminer en détail si la requête web reçoit la réponse attendue. Pour pouvoir l'utiliser, le module doit être dans un état autre que l'état inconnu. On devra également enregistrer le module à chaque fois avant d'utiliser ce bouton.

Avec ce bouton, la première chose vérifiée est si l'on reçoit une réponse différente de HTTP 200. Cela est réalisé via le paramètre suivant de curl pour le paramètre get :

-w '%{http_code}'

Dans le cas bénin des redirections HTTP 3xx, il suffira de placer l'adresse finale après la redirection. La commande curl peut utiliser le paramètre --location pour suivre la redirection reçue.
Tenez compte du fait qu'en utilisant --location-trusted cela obligera à fournir toutes les informations établies à l'URL redirigée.

Recevoir un code HTTP 200 ne signifie pas nécessairement que la page est réellement disponible, car elle peut ensuite être redirigée via JavaScript.

Si l'on retire les paramètres -s, -o et -w (et leurs valeurs), en ne laissant que l'URL, on pourra analyser le code HTML lui-même, ce qui peut être utile pour écarter une redirection par JavaScript, un CAPTCHA de protection pour déterminer si c'est un humain qui consulte, etc.

--user-agent 'Mozilla/5.0 \ 
(Windows NT 10.0; Win64; x64) \ 
AppleWebKit/537.36 \
(KHTML, like Gecko) \ 
Chrome/99.0.4844.84 \ 
Safari/537.36' 'https://pandorafms.com/en/'

Avec l'option header, on peut modifier des champs de l'en-tête HTTP ou créer des champs personnalisés. Pour changer le champ Host de l'en-tête HTTP :

task_begin
get http://192.168.1.5/index.php
header Host 192.168.1.1
task_end

Dans chacun des types de module de vérification web, onglet Basic, apparaîtront les champs suivants nécessaires à l'utilisation d'un proxy :

On peut superviser des API de type REST, à l'exception des types d'API plus complexes basés sur des protocoles tels que SOAP ou XMLRPC.

En vérifiant la sortie avec une expression régulière et en utilisant un module web pour obtenir des réponses textuelles, on peut vérifier que tout est correct :

task_begin
get http://127.0.0.1/pandora_console/include/api.php?info=version
get_content 786
debug /tmp/api
task_end

Pour le cas précédent de l'API 1.0 PFMS, on s'attend à ce qu'elle renvoie la version 786 et pour qu'elle soit rapportée comme état critique, on doit placer cette valeur dans le seuil Critical threshold (Min / Max), en cochant Inverse interval (toute valeur différente de 786 fera passer à l'état critique).

Pour des réponses plus complexes, on doit utiliser d'autres expressions régulières et le token get_content_advanced.

Dans le cas suivant avec une réponse au format JSON, on cherche le champ license_mode puis on extrait son contenu avec une expression régulière :

task_begin
get http://127.0.0.1/pandora_console/include/api.php?op=get&op2=license&return_type=json&apipass=1234&user=admin&pass=pandora
get_content_advanced "license_mode":"([A-Za-z ]+)"
debug /tmp/api_license
task_end

Pour ce qui précède, on s'attend à ce que la réponse soit Perpetual dans le seuil critique avec l'intervalle inverse activé : Tout autre type de licence fera changer l'état du module.

Par défaut, les vérifications web dans PFMS Server sont effectuées sans aucune autorisation d'utilisateur (Anyauth dans le champ Check type). Certaines pages peuvent nécessiter une authentification simple HTTP (ou d'autres méthodes historiquement normalisées). Elle est généralement utilisée comme une vérification rapide, une salutation de sécurité minimale qui permet d'accéder à des vérifications de sécurité plus avancées (chiffrement, persistance des données, etc.).

Considérons le fichier suivant avec du code PHP hébergé à la racine d'un serveur web nommé https://example.com/ :

your_file_name.php

<?php
# BASIC authentication
if (!isset($_SERVER['PHP_AUTH_USER'])) {
    header('WWW-Authenticate: Basic realm="My Realm"');
    header('HTTP/1.0 401 Unauthorized');
    exit;
} else {
    echo "<p>Hello {$_SERVER['PHP_AUTH_USER']}.</p>";
    echo "<p>You entered {$_SERVER['PHP_AUTH_PW']} as your password.</p>";
}
?>

1. Le code HTML est le minimum pour le test.
2. Aucune vérification d'identité n'est effectuée. On s'attend simplement à ce qu'un nom d'utilisateur et un mot de passe soient fournis selon la norme d'authentification BASIC.
3. Dans le PFMS Server, on ajoutera à un agent un module Remote HTTP module to check server response (vérifier que ce type de module a été choisi) de cette manière :

task_begin
# BASIC authentication
get https://example.com/your_file_name.php
check_string Pandor4!
task_end

• Dans le champ Check type, on doit sélectionner BASIC.
• Dans le champ HTTP auth (login), placer n'importe quel utilisateur.
• Dans le champ HTTP auth (password), placer Pandor4!.
• Enregistrer le module et forcer la vérification.

La commande check_string vérifiera que les mots de passe fictifs de test correspondent et placera le module en état normal. Pour tester et vérifier l'état critique, changez le champ HTTP auth (password) par n'importe quelle autre valeur et répétez la procédure.

De manière similaire, on peut changer le fichier PHP de test avec d'autres normes d'authentification.

• DIGEST :

your_file_name.php

<?php
# DIGEST authentication
<?php
if (!isset($_SERVER['PHP_AUTH_DIGEST'])) {
    header('HTTP/1.1 401 Unauthorized');
    header('WWW-Authenticate: Digest realm="My Realm",
           qop="auth", nonce="' . uniqid() . '",
           opaque="' . md5('My Realm') . '"');
    exit;
}

// Process the digest authentication
echo $_SERVER['PHP_AUTH_DIGEST'];
?>

task_begin
# DIGEST authentication
get https://example.com/your_file_name.php
check_string admin
task_end

Une vérification de formulaire est beaucoup plus complexe que la simple vérification d'un texte sur une page web. Pour pouvoir effectuer ce type de vérifications (POST), on doit disposer des identifiants et/ou variables nécessaires. De plus, il est nécessaire d'aller sur la page et d'obtenir le code HTML pour récupérer les noms des variables, et ensuite il faut avoir des connaissances minimales en HTML pour introduire la requête pour le Network Server.

Considérons le fichier suivant avec du code PHP hébergé à la racine d'un serveur web appelé https://example.com/ :

your_file_name.php

<?php
   if( $_POST["name"] || $_POST["age"] ) {
      echo "Welcome <b>". $_POST['name']. "</b><br />";
      echo "You are <i>". $_POST['age']. "</i> years old.<br />";
      echo 'Now: '.time();
      exit();
   }
?>
<form action = "<?php $_PHP_SELF ?>" method = "POST">
   Name: <input type = "text" name = "name" />
   Age: <input type = "text" name = "age" />
   <input type = "submit" />
</form>

1. Pour des raisons didactiques, le code HTML strict est omis.
2. La première visite montre un simple formulaire pour indiquer le nom et l'âge, et au moins l'un d'eux doit être renseigné. Lors de l'envoi des données via POST, un message s'affichera montrant ladite ou lesdites valeurs saisies.
3. La commande $_PHP_SELF permet d'utiliser n'importe quel nom de fichier valide.
4. La commande time() (temps UNIX) sera utilisée dans les fichiers (journaux) de débogage dans une fenêtre de terminal séparée.

Dans le PFMS Server, on choisira un agent pour ajouter un module Remote HTTP module to check server response avec le script suivant :

task_begin
debug /tmp/post_variable
variable_name name
variable_value JIMMY
variable_name age
variable_value 99
post https://example.com/your_file_name.php
# Verify if exists "<b>Jimmy<b>":
check_string \<b\>Jimmy\<\/b\>
task_end

La commande post se charge d'effectuer la requête web. Notez que la commande check_string vérifie ensuite les majuscules ou minuscules de manière indifférente. Si elle trouve la variable avec le nom, elle signalera un état normal, sinon le module passera en état critique. On peut tester et vérifier cela en effectuant le changement suivant et en forçant ensuite la vérification sur l'agent :

variable_name name
variable_value Kevin

Dans les modules de vérification web, la Console web inclut les champs Requests (onglet Basic) et Retries (onglet Data).

Pandora FMS répétera la vérification le nombre de fois indiqué dans ce paramètre. Si l'une des vérifications échoue, la vérification sera considérée comme erronée.
Selon la quantité de vérifications dans le module, un nombre déterminé de pages sera obtenu. Il est important de prendre cela en compte pour calculer le temps total que mettra le module pour terminer les opérations.

Le nombre de fois qu'il effectue une Request jusqu'à obtenir un résultat réussi.

Champ Agent browser ID (onglet Basic) : Identifiant de navigateur web à utiliser, car certaines pages n'acceptent que certains navigateurs web (plus d'informations).

Le timeout est défini par défaut dans le token web_timeout à 60 secondes.

Si un délai d'attente différent est nécessaire pour un module spécifique, on peut le configurer dans le champ Timeout de l'onglet Data.

Marque le début d'un bloc de code qui doit se terminer par task_end.

Chaque module web devra contenir au moins un bloc de code, avec au moins une instruction à exécuter :

task_begin
head https:/example.com/
task_end

On pourra ajouter plusieurs blocs de code lorsqu'il est nécessaire de vérifier des formulaires ou, de manière générale, lorsqu'il faut effectuer plusieurs étapes supplémentaires pour arriver à un résultat concret :

• Le cas le plus courant est la vérification de formulaires, que ce soit pour des processus d'authentification d'utilisateurs ou pour remplir une enquête avec un ou plusieurs champs à renseigner.
• Un autre cas serait de consulter une page web précise et, selon sa réponse, de continuer et d'effectuer une seconde consultation. Dans ce scénario, le résultat du premier et du second bloc de code doivent être réussis pour que la vérification complète soit considérée comme positive et passer à la comparaison avec les seuils du module afin de déterminer s'il doit changer d'état.

Spécifie (resource 1) si, dans un bloc de code, les éléments multimédias tels que les images, le son, etc., seront téléchargés.

Si cette commande n'apparaît pas dans un bloc de code, resource 0 est implicitement utilisé.

Spécifie (cookie 1) si, dans un bloc de code, les cookies obtenus seront stockés pour une utilisation ultérieure dans d'autres blocs de code.

Si cette commande n'apparaît pas dans un bloc de code, cookie 0 est implicitement utilisé.

Commande qui, en utilisant variable_name et variable_value, spécifie l'URL de la vérification web. Si elle est utilisée plus d'une fois dans un bloc de code, l'URL à examiner sera celle spécifiée lors de sa dernière apparition.

Commande qui spécifie l'URL de la vérification web. Si elle est utilisée plus d'une fois dans un bloc de code, toutes les URL seront examinées, mais l'URL spécifiée lors de sa dernière apparition sera celle qui fournira les données pour la vérification.

Commande spéciale qui renvoie la réponse du code spécifique de l'en-tête HTTP dans une vérification web.

Le format de réponse est HTTP/V XXX où V est la version et XXX le code. Quelques réponses pouvant être obtenues : HTTP/2 403, HTTP/1.1 200, HTTP/1 302, etc.

Généralement utilisé comme seule commande dans un seul bloc de code, voir “Vérification du code d'état du serveur” pour plus d'informations.

Vérifie que, dans la vérification web en cours, il existe une chaîne de texte spécifique. Le résultat renvoyé est une variable booléenne (0 faux, n'importe quelle autre valeur est vrai) et doit être stocké dans un type de module de vérification de réponse serveur (type web_proc).

Les arguments que prend la syntaxe de check_string ne sont pas des chaînes de texte normales, ce sont des expressions régulières. Tout caractère qui n'est pas une lettre ou un chiffre devra être échappé avec \:

task_begin
get https://apache.org/
# Comment: Search "/images/oakleaf.svg" (including quotation marks)
check_string \"\/images\/oakleaf\.svg\"
debug /tmp/apache
task_end

Le code “propre” suivant est également valide bien que l'ordre d'apparition de la commande get ait été modifié (et bien que le bouton Check indique qu'il y a une erreur) dans un même bloc de code task_begin…task_end :

task_begin
check_string \"\/images\/oakleaf.svg\"
get https://apache.org/
task_end

Vérifie que la vérification web en cours ne contient pas une chaîne de texte spécifique. Pour le reste de son fonctionnement, il est identique à check_string.

Déclare une variable dont la valeur sera établie par l'instruction suivante variable_value. Pour une meilleure clarté du code, il est recommandé de l'utiliser par paires ordonnées de lignes contiguës.

Cette paire (ou ces paires) d'instructions doit (doivent) être accompagnée(s) d'une commande post. Dans la requête web, l'ordre d'apparition des variables sera d'abord la dernière déclarée, puis l'avant-dernière déclarée, et ainsi de suite.

Établit la valeur d'une variable déclarée avec variable_name.

Pour une meilleure clarté du code (et pour faciliter les tâches de débogage, le cas échéant), il est recommandé de l'utiliser par paires ordonnées de lignes contiguës, d'abord variable_name puis variable_value.

Bien que l'on puisse placer ces instructions dans n'importe quel ordre, cela peut occasionner des résultats imprévisibles si, par erreur, des commandes impaires ou orphelines sont établies.

À la différence des commandes check_string et check_not_string, lesquelles renvoient seulement un résultat vrai ou faux, la commande get_content est utilisée lorsqu'il est nécessaire d'obtenir une valeur numérique ou une chaîne de texte précise.

De manière similaire, ces trois commandes emploient des expressions régulières pour effectuer leur travail avec la différence fondamentale que get_content fournit intégralement le résultat de sa recherche.

Pour obtenir une valeur numérique d'une requête de type API, on peut employer le code suivant
get_content \d+ dans un bloc de code task_begin … task_end :

task_begin
get http://127.0.0.1/pandora_console/include/api.php?apipass=1234&user=admin&pass=pandora&op=get&op2=total_modules&id=0
get_content \d+
debug /tmp/num_of_modules
task_end

Permet d'extraire une chaîne de texte dans un élément HTML. On pourra également extraire des valeurs “numériques”, selon l'expression régulière utilisée. Syntaxe :

task_begin
get <URL>
get_content_advanced <html_code>(regex)</html_code>
task_end

Il doit être utilisé conjointement avec get pour établir l'URL à vérifier. Une fois son contenu HTML obtenu, toute la page sera parcourue jusqu'à obtenir une correspondance d'élément HTML et il en renverra le contenu. Voir “Obtention de données textuelles d'une page web”.

Permet d'ajouter des en-têtes HTTP à la requête web.

Par défaut, Curl est utilisé pour effectuer les vérifications web et deux éléments sont toujours inclus :

1. -H 'Pragma: no-cache': Utilisé pour ignorer le cache des CDN. Pragma est compatible avec HTTP 1.0 (les versions HTTP les plus utilisées actuellement sont 1.1 et 2.0).
2. -H 'Accept: text/html': Indique que l'on demande le code HTML comme première réponse.

Avec header inclus dans un bloc task_begin…task_end, on peut spécifier des paires de valeurs additionnelles. Dans une requête API 1.0 PFMS, cela s'avère très utile lorsque l'on effectue une authentification au moyen du Bearer token privé d'un utilisateur, puis que l'on vérifie une valeur de réponse attendue avec check_string :

task_begin
header Authorization Bearer 05c43863bf76c54456837ea7c3008e56
get http://127.0.0.1/pandora_console/include/api.php?op=get&op2=test
debug /tmp/api
check_string 786
task_end

Cela pourrait aussi être utile pour demander explicitement que l'on réponde dans une langue spécifique :
header Accept-Language fr-FR.

• La langue header Accept-Language es-ES se consulte ainsi avec Curl :
  -H 'Accept-Language:es-ES'
• Le référent (indique la page web visitée précédemment) header Referer pandorafms.com :
  -H 'Referer:pandorafms.com'
• Si le serveur web consulté nécessite des en-têtes particuliers, ceux-ci doivent commencer par -X…. Ils sont souvent accompagnés ensuite d'un ou plusieurs tirets et, bien sûr, du nom et de la valeur de l'en-tête lui-même.
  Prenons le cas de l'envoi de l'identifiant d'un client header X-Customer-ID “Ñ123”, on consulte :
  -H 'X-Customer-ID:"Ñ123"' (notez l'utilisation de guillemets doubles pour envelopper Ñ123).

Voir aussi :

• Identifiant de navigateur web.
• cookie.

On peut déboguer les vérifications web en ajoutant l'option debug <path>/<file_name>.
Deux fichiers <path><file_name>.req et <path><file_name>.res seront créés avec les contenus de la requête HTTP et de la réponse, respectivement :

task_begin
get http://192.168.1.5/index.php
debug /tmp/debug_file
task_end

En forçant les vérifications pour accélérer le travail de débogage, on devra toujours attendre la réponse du serveur ou du dispositif qui est supervisé. Il existe au moins une manière de voir via la ligne de commande le contenu desdits fichiers en temps réel :

tail -f <path><file_name>.res --retry

Marque la fin d'un bloc de codes. Voir task_begin.

Pour vérifier le temps de réponse en secondes (latence) d'une page web, on sélectionne le type de module Remote HTTP module to check latency.

Dans un test WEB, il peut exister une ou plusieurs requêtes intermédiaires qui complètent la transaction. De cette manière, on obtient le temps total qui s'écoule depuis la première requête jusqu'à la vérification de la dernière.

task_begin
get https://pandorafms.com
task_end

• Si dans la définition de la vérification, il a été défini que la transaction soit effectuée plus d'une fois (commande get), la moyenne du temps de chaque requête sera utilisée.
• Les seuils pour les états d'avertissement et de criticité doivent être établis par l'utilisateur.
• Pour que le temps de téléchargement inclue toutes les ressources (JavaScript, CSS, images, etc.), on doit ajouter resource 1 sur une ligne avant task_end.
• Les vérifications web supportent aussi l'utilisation de serveurs mandataires (proxies), pour cela, on doit remplir les champs dénommés Proxy nécessaires.
• Le paramètre debug est utilisé pour tenir un registre accumulé dans deux fichiers distincts tant de la requête que de la réponse de chaque vérification.

Avec un module de type Remote HTTP module to check server response, on obtient un 1 (OK) ou un 0 (CRITICAL) comme résultat de la vérification de toute la transaction.

S'il existe plusieurs tentatives mais qu'au moins l'une d'elles échoue, on considère que le test dans son ensemble échoue également. Précisément, le nombre de tentatives est parfois utilisé pour éviter les faux positifs, pour cela utilisez le champ Requests dans les options avancées.

Dans sa syntaxe de base, il suffit d'ajouter dans le cadre Web Checks :

task_begin
get <URL>
task_end

À la différence de la vérification d'état HTTP, la vérification précédente ramène tout le code HTML, ce qui peut être exploité pour des utilisations supplémentaires comme vérifier qu'il existe une chaîne de texte sur ledit site avec check_string :

task_begin
get <URL>
check_string <texte>
task_end

• Si la chaîne de texte demandée existe, il passera à l'état normal, sinon il passera à l'état critique.
• On peut utiliser check_not_string <texte> pour le cas contraire : s'il ne trouve pas le texte indiqué, il passera à l'état normal, sinon il passera à l'état critique.
• Bien que l'on puisse utiliser d'autres paramètres comme resource pour télécharger toutes les ressources (images, etc.), cela ne fera que surcharger de travail inutile le PFMS Server.
  Il faut bien soupeser l'ajout d'autres paramètres, seuls ceux réellement nécessaires doivent être utilisés, surtout s'il s'agit d'une consultation simple.
• De même, cela s'applique pour le téléchargement et l'enregistrement des cookies, à moins que d'autres étapes de vérifications web ne soient effectuées, on peut déclarer explicitement de les ignorer :

task_begin
get https://apache.org/
# No save cookie
cookie 0
# Do not download images, etc
resource 0
check_string Jimmy
debug /tmp/apache
task_end

Pour vérifier qu'une page web répond avec une valeur numérique, ou contient une valeur spécifique, on utilise le type de module Remote HTTP module to retrieve numeric data.

Pour cela, on peut utiliser la requête de base get_content \d+ (l'expression régulière ajoutée filtre seulement les chiffres). Le mécanisme consiste à analyser toute la réponse HTTP depuis le début et à commencer à comparer jusqu'à ce qu'elle coïncide avec l'expression régulière donnée.

• Les seuils pour les états d'avertissement et de criticité doivent être établis par l'utilisateur. Par défaut, ces seuils sont à zéro, donc toute vérification numérique valide obtenue sera classée comme état normal.
• Des serveurs mandataires peuvent être utilisés en remplissant les champs dénommés Proxy nécessaires.
• En ajoutant l'instruction debug, on conserve les requêtes et réponses dans deux fichiers pour être déboguées ultérieurement.
• Pour obliger à consulter de manière directe avec Curl le serveur web (omettant ainsi le cache des CDN), PFMS inclut par défaut l'ordre header Pragma: no-cache.
  On a choisi Pragma au lieu de Cache-Control pour maintenir la compatibilité avec HTTP 1.0 (les versions les plus utilisées actuellement sont 1.1 et 2.0).
• Pour une consultation avancée et extraire une valeur numérique de n'importe quel élément HTML de la page, comme un titre de niveau 3 ou le premier paragraphe qui apparaît avec un Attribut CSS spécifique, voir le paramètre get_content_advanced.

Le type de module Remote HTTP module to retrieve string data fonctionne de manière similaire à sa contrepartie numérique sans le processus de filtrage gênant pour garantir uniquement des chiffres.

task_begin
get https://academy.pandorafms.com/
get_content_advanced <h3 class="h2-b">(.*)</h3>
task_end

Ici, get_content_advanced est le paramètre clé qui permet de choisir un élément HTML (dans ce cas un titre de niveau trois h3, classe ha2-b) puis, selon une expression régulière (.*), d'extraire la chaîne de caractères qui s'y trouve.

Comme pour la condition normale on ne peut pas comparer de valeurs, on utilise le seuil d'avertissement ou le seuil de criticité avec l'intervalle inverse établi avec le texte attendu :

Terms & Important Notes (notez l'utilisation des entities dans le code HTML reçu).

Pour vérifier le code d'état d'une page web, on sélectionne le type de module Remote HTTP module to check server status code (type web_server_status_code_string) avec le bloc de code suivant task_begin … task_end :

task_begin
head https://pandorafms.com
task_end

• Dans la configuration du serveur, on doit utiliser Curl.
• Il est important d'utiliser le paramètre head pour obtenir le code d'état.
• Pour configurer le seuil critique, on peut placer HTTP/X 200 OK (où X est la version du protocole) et cocher l'intervalle inverse :

De cette manière, en recevant n'importe quelle réponse différente, le module passera à l'état critique :

En plus de la fonctionnalité offerte par Web server PFMS, il existe d'autres manières de réaliser une supervision transactionnelle : la Supervision de l'Expérience Utilisateur WEB (WUX).

Revenir à l'index de la documentation de Pandora FMS