Monitorisation avec des EndPoints

Les EndPoints sont installés et sont en cours d'exécution sur les systèmes d'exploitation dont ils collectent les informations, effectuant une vérification pour chaque module.

Les directives propres à l'EndPoint servent à collecter certaines données directement du système d'exploitation (telles que l'utilisation du processeur, la mémoire, les événements, etc.), en exécutant des commandes propres au système d'exploitation selon les instructions de scripts prédéfinis.

Le Dataserver Pandora FMS traite et stocke dans la base de données toutes les informations générées et envoyées dans un fichier XML par les EndPoints.

Toute la configuration et les paramètres sont stockés dans le fichier pandora_agent.conf, lequel est également installé localement avec son EndPoint. La configuration de base est traitée dans "Configuration des EndPoints Pandora FMS" et, pour la monitorisation WUX, dans la section d' exécution manuelle en tant que plugin. La configuration avancée est présentée ci-dessous.

Dans le fichier de configuration de l'EndPoint, les modules sont définis avec la structure de texte de base suivante :

module_begin
module_name <your module name>
module_type generic_data
module_exec <your command>
module_description <your description>
module_end

Il est possible de gérer à distance les fichiers des EndPoints depuis la Console Web de Pandora FMS. La configuration de chaque EndPoint est stockée sur le serveur de Pandora FMS dans deux fichiers : <md5>.conf et <md5>.md5, où <md5> est le hash du nom de l'EndPoint. Ces fichiers sont stockés respectivement dans :

/var/spool/pandora/data_in/conf

et

/var/spool/pandora/data_in/md5

Les champs personnalisés permettent d'ajouter des informations supplémentaires à l'EndPoint. Des champs personnalisés peuvent être créés avec l'API 1.0 PFMS et la commande set create_custom_field ou via la Console Web dans le menu Management → Resources → Custom fields → Create field.

• Les options Enabled combo, Password type et Link type sont mutuellement exclusives, c'est-à-dire qu'une seule d'entre elles pourra être utilisée (ou aucune, valeur par défaut).
• En activant le champ Display up front, l'information du champ personnalisé sera affichée, si une valeur a été établie, dans la vue générale de l'EndPoint. Si aucun champ personnalisé marqué n'a de valeur, la boîte des champs personnalisés restera masquée.

  De plus, il sera nécessaire d'activer ce token pour envoyer les informations des Custom Fields au Command Center.

• Enabled combo : Ce paramètre permet d'activer la configuration de paramètres sélectionnables depuis un menu déroulant. Une fois activé, dans la fenêtre de configuration du custom field correspondant, un nouveau champ apparaîtra pour saisir les valeurs du combo séparées par des virgules.
• Password type : La valeur du champ (mot de passe) sera affichée au moyen d'astérisques dans la Console Web.
• Link type : Permet d'ajouter un champ personnalisé qui contiendra un lien web à remplir par la Console Web ou dans un XML reçu par un EndPoint. Il est possible d'inclure des liens dans les custom fields d'un XML au format JSON incrustés avec des instructions CDATA <![CDATA[…]]>. Si le format JSON du lien est :

["Web name","https://example.com"]

Le XML aurait cette syntaxe :

<custom_fields>
  <name>![CDATA[web]]</name>
  <value>![CDATA[["Web name","https://example.com"|]]]</value>
</custom_fields>

Consultez “Validation de XML”, l' Architecture de Sécurité pour le protocole Tentacle (mécanisme chargé de livrer les données au format XML au Data server PFMS) et l' Architecture de Sécurité pour le Data server PFMS (limiter l'autocréation d'EndPoint et établir un mot de passe pour le groupe d'EndPoints auquel chaque EndPoint appartient).

Les custom fields peuvent également être transmis depuis le fichier de configuration de l'EndPoint, en utilisant les tokens  custom_fieldx_name et custom_fieldx_value :

custom_field1_name Serial Number
custom_field1_value 56446456KS7000

Le champ personnalisé nommé Serial Number est créé par défaut lors de l'installation de PFMS. On peut créer autant de champs personnalisés que nécessaire et de chaque type différent (valeur simple, lien web, type mot de passe et type liste d'options). L'ordre de l'identifiant numérique de chaque champ personnalisé est indifférent, il faut seulement s'assurer que le nom soit exactement le même :

custom_field11_name Simple custom field name
custom_field11_value Simple custom field value

custom_field12_name Custom field Link type
custom_field12_value ["Pandora FMS web site","https://pandorafms.com"]

custom_field13_name Custom field Password type
custom_field13_value My;Password;

custom_field14_name Custom field Combo type
custom_field14_value Two

Dans les champs personnalisés Combo type, la valeur envoyée par l'EndPoint doit correspondre exactement à l'un de ses éléments, sinon la valeur ne sera pas modifiée.

Paramètres les plus importants pour la configuration de base des EndPoints :

• server_ip : Adresse IP du serveur Pandora FMS.
• server_path : Chemin du dossier d'entrée incoming du serveur Pandora FMS, par défaut

  /var/spool/pandora/data_in

• temporal : Dossier, par défaut /tmp.
• interval : Intervalle d'exécution de l'EndPoint, par défaut 300 secondes.
• logfile : Fichier de log de l'EndPoint, par défaut :

  /var/log/pandora/pandora_agent.log

Il est possible de configurer un mot de passe (sans espaces ni symboles) pour un groupe ; de cette manière, un EndPoint ne sera pas ajouté à un groupe à moins que le mot de passe correct n'ait été spécifié dans le fichier de configuration de l'EndPoint.

Pour ajouter un nouvel EndPoint à ce groupe, modifiez son fichier de configuration, ajoutez l'option de configuration suivante group_password et redémarrez l'EndPoint.

Selon la donnée renvoyée :

• generic_data : Numérique.
• generic_data_inc : Incrémental.
• generic_data_inc_abs : Incrémental absolu.
• generic_proc : Booléen.
• generic_data_string : Alphanumérique.
• async_data : Numérique asynchrone.
• async_string : Alphanumérique asynchrone.
• async_proc : Booléen asynchrone.
• Module d'image : Ils utilisent comme base un module de type chaîne de texte (generic_data_string ou async_string). Si la donnée que contient le module est une image encodée en base64 (en-tête data:image), celle-ci sera identifiée comme une image et activera dans les vues un lien vers une fenêtre pour récupérer l'image. De plus, un contenu des différentes images composant les chaînes stockées sera affiché dans leur historique respectif.

Les modules locaux (ou d'EndPoint) ont tous comme “base” l'intervalle de leur EndPoint. Cependant, ils peuvent prendre des valeurs multiples de cette base si vous modifiez le paramètre module_interval avec un multiplicateur entier supérieur à zéro.

La création de modules locaux dans la Console Web se fait au moyen d'un formulaire où, en plus de la configuration commune de tout module (seuils, type, groupe, etc.), on dispose d'une boîte de texte où sont spécifiées les données à établir dans le fichier de configuration de l'EndPoint.

• En cliquant sur le bouton Load basic, le contenu de Data configuration sera effacé et remplacé par un modèle de base qui doit être modifié selon les besoins de monitorisation.
• Une fois modifié, en cliquant sur Check, on vérifiera que la syntaxe du modèle est toujours correcte (cependant, le reste des commandes ne sera pas vérifié).

L'EndPoint supporte l'exécution de commandes et de scripts en mode post-conditions. Cela signifie que l'on peut effectuer des actions en fonction de la valeur obtenue lors de l'exécution du module. Le paramètre module_condition est utilisé à cet effet.

Le paramètre module_precondition permet d'évaluer une condition avant l'exécution du module et de décider avec le résultat si le module doit être exécuté ou non.

Il existe certains modules qui ont une importance particulière, tels que des processus ou des services critiques en cours d'exécution. Pour pouvoir avoir une monitorisation plus contrôlée de ces cas, il existe la monitorisation intensive.

Elle consiste à avertir dans un intervalle plus court qu'un problème sérieux est apparu sans avoir besoin de réduire l'intervalle général de l'EndPoint.

Configuration dans l'EndPoint :

• interval : Obligatoire, temps d'échantillonnage de l'EndPoint en secondes, c'est l'intervalle général pour tous les modules locaux.
• intensive_interval : Temps durant lequel il avertira s'il y a un problème, et il s'exécutera toujours pendant cette période ; si cela coïncide avec la condition, la notification se fera pendant cette période de temps (sinon, les données seront envoyées lors de l' interval).

Configuration dans le module :

• module_intensive_condition = <value> : Si le module obtient comme résultat la valeur indiquée dans ce paramètre, il notifiera dans l'intervalle intensif défini précédemment.
• Les autres opérateurs pouvant être utilisés sont : <, >, !=, une plage de valeurs (m,n) et =~.

Le service sshd est très important car il est utilisé pour se connecter via shell à distance et son fonctionnement doit être monitoré.

Fichier de configuration de l'EndPoint :

interval 300
intensive_interval 10

Module :

module_begin
module_name SSH Daemon
module_type generic_data
module exec ps aux | grep sshd | grep -v grep | wc -l
module_intensive_condition = 0
module_end

Si le service est absent, il sera notifié dans les 10 secondes suivantes, s'il fonctionne, il notifiera toutes les 5 minutes (intervalle normal, 300 secondes).

L'EndPoint supporte la définition de modules programmés qui s'exécutent aux instants définis. La syntaxe utilisée est la même que celle du fichier crontab.

Un EndPoint est capable d'effectuer des vérifications à distance, remplaçant le serveur principal PFMS et même de les distribuer dans des agents broker.

Les vérifications ICMP ou ping sont très utiles pour savoir si une machine est connectée ou non à un réseau.

Unix :

module_exec ping -c 1 dir_IP> /dev/null 2>&1; if [ $? -eq 0 ]; then echo 1; else echo 0; fi

MS Windows® :

module_ping dir_IP

Note : module_advanced_options permet des options avancées pour ping.exe.

Les vérifications TCP sont utiles pour vérifier que les ports d'une machine restent ouverts et permettent de savoir si une application se connecte ou non au réseau.

Unix :

Avec la commande nmap et ses paramètres de configuration sur la ligne de commande, on vérifie si le port 80 est ouvert pour une adresse IP (temps d'attente de réponse de 5 secondes) :

module_begin
module_name PortOpen
module_type generic_proc
module_exec nmap 192.168.100.54 -p 80 | grep open > /dev/null 2>&1; echo $?; if [ $? == 0 ]; then echo 1; else echo 0; fi
module_timeout 5
module_end

MS Windows® :

Les paramètres doivent être spécifiés dans :

• module_tcpcheck : Adresse IP du dispositif.
• module_port : Numéro de port.
• module_timeout : Temps d'attente pour la réponse, il doit être situé entre module_begin et module_end.

Cas donné :

module_begin
module_name TcpCheck
module_type generic_proc
module_tcpcheck 192.168.100.54
module_port 80
module_timeout 5
module_end

Les vérifications SNMP sont courantes dans la monitorisation des dispositifs réseau pour vérifier l'état des interfaces, les octets d'entrée/sortie, etc.

Unix® :

module_exec snmpget dir_IP -v 1 -c public .1.3.6.1.2.1.2.2.1.1.148 | awk '{print $4}'

MS Windows® :

module_snmpget
module_snmpversion 1
module_snmp_community public
module_snmp_agent 192.168.100.54
module_snmp_oid .1.3.6.1.2.1.2.2.1.1.148
module_end

Ce mode permet de rediriger les fichiers de données générés par d'autres EndPoints vers le serveur de Pandora FMS. L'EndPoint qui agit en Mode Proxy peut également effectuer des tâches de monitorisation.

Configuration des paramètres :

• server_ip : Adresse IP du serveur Pandora FMS.
• proxy_mode : Activé (1) ou désactivé (0).
• proxy_max_connection : Nombre de connexions simultanées du proxy, par défaut 10.
• proxy_timeout : Temps d'attente de réponse pour le proxy, par défaut 1 seconde.
• proxy_address : Adresse IP sur laquelle le proxy écoute.
• proxy_port : Numéro de port sur lequel le proxy écoute.

Le Mode Broker des EndPoints permet à un seul EndPoint d'effectuer des vérifications et de gérer la configuration comme s'il s'agissait de plusieurs EndPoints distincts.

Lorsque le Mode Broker est activé dans un EndPoint, un nouveau fichier de configuration est créé. À partir de ce moment, l'EndPoint original et le nouveau Broker seront gérés séparément avec leurs fichiers de configuration indépendants, comme s'ils étaient deux EndPoints totalement séparés sur la même machine.

Pour créer un Broker, on ajoute une ou plusieurs lignes avec le paramètre broker_agent <broker_name>  (une ligne pour chaque Broker).

Dans la Console Web de Pandora FMS, les Brokers sont vus et gérés comme des EndPoints indépendants.

Pour plus d'informations, visitez la section Inventaire local avec EndPoints.

Pour plus d'informations, visitez le sujet Collecte et monitorisation de logs.

Un EndPoint est capable de recevoir des requêtes à distance et d'exécuter des ordres.

Pour permettre au serveur PFMS d'envoyer des ordres aux EndPoints sous sa responsabilité, il faut configurer :

• udp_server : Zéro 0 par défaut, valeur à un 1 pour activer cette fonctionnalité.
• udp_server_port : Numéro de port d'écoute sur l'EndPoint.
• udp_server_auth_address : Adresse IP du serveur Pandora FMS.

L'EndPoint doit être redémarré pour que les changements s'appliquent.

Le script situé à l'emplacement suivant doit être utilisé :

/usr/share/pandora_server/util/udp_client.pl

Il peut être exécuté depuis la ligne de commande ou bien utilisé dans une alerte, via la commande qui est préconfigurée dans la console Remote agent control.

En plus de l'action de redémarrage du service d'EndPoint, des actions personnalisées de type suivant peuvent être spécifiées :

process_<order_name>_start command

À la différence des plugins de serveur, exécutés par le serveur Pandora FMS, les plugins d'EndPoint rapportent un ou plusieurs modules à la fois.

Sous MS Windows®, les plugins enregistrés par défaut sont programmés en VBScript, pour les exécuter on utilise l'interpréteur cscript.exe.

À partir de la version 776, on dispose de module_exec_powershell qui permet d'introduire des commandes plus complexes dans PowerShell® avec des caractères spéciaux et des instructions complexes (une instruction délivre des résultats à la suivante) qui sont impossibles via le module module_exec.

# Example of Powershell execution module
module_begin
module_name Powershell
module_type generic_data_string
module_exec_powershell <command_1> | <command_2> | … | <command_N>
module_end

Les commandes sont introduites telles quelles, sans avoir besoin de guillemets pour être traitées par l'EndPoint PFMS (les commandes PowerShell, en revanche, peuvent nécessiter des guillemets).

Si la commande n'est pas valide, une erreur est ajoutée au journal de l'EndPoint (fichier pandora_agent.log).

Les plugins Unix sont situés par défaut dans le répertoire de l'EndPoint :

/usr/share/pandora_agent/plugins

Il est possible d'ajouter un token dans la configuration des plugins d'EndPoint qui, lorsqu'il est activé, permet l'option d'“encapsuler” les définitions de plugins à l'intérieur des balises module_begin et module_end.

Ce token activé permet d'insérer des blocs de configuration comme module_interval ou module_crontab, entre autres.

Les plugins peuvent être créés dans n'importe quel langage de programmation. Il faut seulement tenir compte des règles générales et des règles spécifiques pour leur développement.

Nagios possède un grand nombre de plugins qui peuvent être utilisés avec Pandora FMS. Une façon de le faire est d'utiliser les plugins distants avec le Heavy Server, en utilisant la compatibilité de Nagios.

Un module singulier dans Pandora FMS est le type appelé keep_alive, utilisé pour alerter si un EndPoint a cessé d'envoyer des informations.

Il faut aller dans le menu d'administration des agents dans Management → Resources → Manage agents et cliquer sur Modules d'un agent.

Une fois que la liste des modules de l'agent sélectionné est visible, il faut appuyer sur le bouton Create module et sélectionner Endpoint module dans la liste Select module type et appuyer sur Create. Le module doit être créé de la manière suivante :

Les commandes qui présentent des sorties étendues, comme top ou netstat -n, peuvent être capturées entièrement par un module et reproduites telles quelles. Le module doit être configuré comme type texte dans la configuration à distance d'une manière similaire au code suivant :

module_begin
module_name process_table
module_type generic_data_string
module_exec ps aux
module_description Command snapshot of running processes
module_group System
module_end

Dans la vue principale d'édition de l'agent, section inférieure des modules, la colonne Data présentera une icône avec la description Command Snapshot view où, en cliquant, une nouvelle fenêtre s'ouvrira :

Cette méthode permet de définir des modules de type chaîne (generic_data_string ou async_string) contenant des images au format texte avec un encodage base64, pouvant afficher ladite image au lieu d'un résultat concret.

On crée un fichier script tel que :

#!/bin/bash
echo "<module>"
echo "<name>Actual leader</name>"
echo "<type>async_string</type>"
echo "<data><![CDATA[data:image/jpeg;base64,/9j/4AAQSkZ....]]></data>"
echo "</module>"

On enregistre ce contenu dans un fichier sur l'EndPoint (ou distribuez-le par collections) et on l'exécute ainsi :

module_plugin <complete_path_to_the_file>

Le paramètre module_proc vérifie si un nom de processus déterminé fonctionne sur cette machine. Il doit être configuré de manière similaire :

module_begin
module_name CMDProcess
module_type generic_proc
module_proc cmd.exe
module_description Process Command line
module_end

Le paramètre module_async yes doit être ajouté :

module_begin
module_name CMDProcess
module_type generic_proc
module_proc cmd.exe
module_async yes
module_description Process Command line
module_end

La fonctionnalité de Watchdog pour MS Windows® permet de redémarrer un processus interrompu.

Dans le code suivant, on configure le programme Bloc-notes pour qu'il s'exécute de manière persistante via l'EndPoint installé :

module_begin
module_name Notepad
module_type generic_data
module_proc notepad.exe
module_description Notepad
module_async yes
module_watchdog yes
module_user_session yes
module_start_command "%SystemRoot%\notepad.exe"
module_startdelay 3000
module_retrydelay 2000
module_retries 5
module_end

Le paramètre module_service vérifie si un service déterminé est en cours d'exécution sur la machine. La définition d'un module utilisant ce paramètre serait :

module_begin
module_name Service_Dhcp
module_type generic_proc
module_service Dhcp
module_description Service DHCP Client
module_end

Le paramètre module_async yes doit être ajouté pour qu'il avertisse immédiatement lorsqu'un processus cesse de fonctionner :

module_begin
module_name Service_Dhcp
module_type generic_proc
module_service Dhcp
module_description Service DHCP Client
module_async yes
module_end

Fonctionne de manière similaire au Watchdog de processus :

module_begin
module_name ServiceSched
module_type generic_proc
module_service Schedule
module_description Service Task scheduler
module_async yes
module_watchdog yes
module_end

Certains modules sont déjà actifs et d'autres doivent être activés par la Remote Configuration (ou en éditant localement le fichier .conf de l'EndPoint).

← Retour à l'index de la documentation de Pandora FMS