Supervision avec des agents logiciels

Retour à l'index de documentation du Pandora FMS

Les agents logiciels sont en exécution dans les systèmes d'exploitation dont ils recueillent des informations. Chaque des vérifications qu'ils font sur le système, telle que l'utilisation de l'UCT, la memoire libre ou l'espace disque, corresponde à un module. Donc, pour chaque module une seule donnée est recueillie para chaque exécution.

Les directives propres de l'agent logiciel servent à recueillir certaines données directement du système d'exploitation (exemple, l'utilisation de l'UCT, la memoire, les événements, etc.), exécutant commands propres du système d'exploitation en suivant les instructions des scripts prédéfinis. Il est aussi possible d'exécuter ces commandes directement telle que tout autre logiciel à condition qu'ils retournent des données de manière estandarisée.

Le Dataserver Pandora FMS traite et stocke dans la base de données toute l'information générée par les agents logiciels, qui envoient leurs données dans un fichier XML.

Squéma logique d'un agent /agent physique.

Toute la configuration et les paramètres de surveillance des agents software se trouvent dans le fichier de configuration pandora_agent.conf. Ce dernier est stocké localement dans la machine où est installé l’agent software, où toute modification que nous souhaiterions apporter à l’agent devra se refléter dans ce fichier. Sa description détaillée de tous les tokens de configuration de l’agent est dans le chapitre « Configuration des agents de Pandora FMS » où nous nous concentrons sur les usages avancés de certains d’entre eux.

Le fichier de configuration de l'agent logiciel, les modules sont définis avec le structure se base de texte suivante:

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

Exemple 1

module_begin 
module_name Files in var spool
module_type generic_data
module_exec ls /var/spool | wc -l
module_description Number of files incoming dir
module_end

Dans l'environnement *nix, la commande ls liste des fichiers d'un directoire et est exécuté avec la ligne module_exec pour retourner le valeur à la commande wc qui comptera le nombre de mots reçues pour le même nombre de fichiers. La valeur retournée par cette dernière exécution sera la donnée obtenue par la module et sera affichée dans la supervision.

Exemple 2

module_exec vmstat 1 2 | tail -1 | awk '{ print $13 }'

La commande vmstat rapporte des statistiques de la mémoire virtuelle, dans cet exemple, ce sont deux las commandes additionnelles pour « affiner » l'information souhaitée. Nous vous recommandons de lancer la commande manuellement au début et d'analyser la sortie.

$> vmstat 1 2 | tail -1 | awk '{ print $13 }'

Si le résultat satisfait la demande, vous pouvez l'ajouter au fichier de configuration; après la valeur retournée par l'exécution par le biais de l'agent logiciel sera stockée dans le XML sous forme de donnée de module.

Exemple 3

Toute commande ou tout logiciel peut être exécuté grâce à module_exec à condition que la sortie soit compatible avec les valeurs acceptées par Pandora FMS (numérique, alphanumérique, ou booléen), donc il est possible d'indiquer des scripts personnalisés:

module_exec myScript.pl --h 127.0.0.1 -v cpu

À nouveau l'agent exécutera la commande dans la shell et recueillera le résultat, de même que s'il était exécuté par un operateur:

$> myScript.pl --h 127.0.0.1 -v cpu

Dans la version Enterprise, il est possible de gérer à distance les fichiers des agents software depuis la console. Ceci permet l’administration centralisée de tous nos agents software sans avoir besoin d’accéder physiquement aux systèmes où ils sont installés.

La configuration de chaque agent est conservé dans le serveur de Pandora FMS dans deux fichiers : <md5>.conf y <md5>.md5, <md5> étant le hash du nom de l’agent. Ces fichiers sont conservés respectivement dans /var/spool/pandora/data_in/conf et /var/spool/pandora/data_in/md5. Ces fichiers conservés dans le serveur sont modifiés par la propre console de Pandora FMS quand la configuration à distance des agents est éditée.

Pour permettre la configuration à distance, il ne faut, tout d’abord, qu’activer le paramètre correspondant dans le fichier de configuration local de l’agent. A partir de ce moment, tous les changements devront se faire depuis la console Pandora FMS :

remote_config 1

Custom fields

Les champs personnalisés permettent d'ajouter des informations additionnels à l'agent. Vous pouvez créer des champs personnalisées dans Resources > Custom fields.

De manière prédéterminée les champs Display up front et Enabled combo sont désactivés :

• Lors de l'activation du champ Display up front l'information du champ personnalisé sera affiché dans la vue général de l'agent. En outre, il sera nécessaire d'activer ce token pour envoyer les informations des Custom Fields à la Métaconsole et pouver l'afficher dans la vue de la Métaconsole et travailler dans Custom Field View avec ces données :

• Enabled combo : Une fois activé, dans la fenêtre de configuration de custom field correspondante il apparaitra un nouveau champ pour ajouter les valeurs du combo séparés par virgules. Ce paramètre permet d'activer la configuration de paramètres sélectionnables depuis un déroulant.

Les custom fields peut être aussi déplacés depuis le fichier de configuration de l'agent, en utilisant le token de configuration suivant, par exemple :

 custom_field1_name Model
 custom_field1_vale i386

Paramètres les plus importants pour la configuration basique de l’agent (plus d'informations dans Agents logiciels de Pandora FMS):

• server_ip : Adresse IP du serveur de Pandora FMS.
• server_path : Emplacement du dossier incoming du serveur Pandora FMS. Par défaut /var/spool/pandora/data_in.
• temporal : Dossier temporaire de l’agent software. Par défaut /tmp.
• logfile : Archive de journal (ou « log ») de l’agent software. Par défaut /var/log/pandora/pandora_agent.log.
• interval : Intervalle d’exécution de l’agent en secondes. Par défaut 300.
• remote_config: Activation de la configuration à distance. Elle est désactivée par défaut (0). Seulement pour la version Enterprise.
• agent_name : Nom de l’agent. Par défaut, il prend celui de hostname.
• debug : Il active (1) le mode debug pour sauvegarder une copie du fichier de XML dans le répertoire temporaire pour son analyse et une autre est envoyée au serveur. En outre, dans les systèmes MS Windows®, un fichier .debug est créé dans le chemin de l'installation de l'agent avec un registre détaillé de l'exécution de chaque module. Dans la version Enterprise, le mode debug activé désactive la configuration à distance depuis la Console vers l'agent logiciel.

Un exemple dans l'environnement *nix serait :

server_ip       192.168.1.1 
server_path     /var/spool/pandora/data_in 
temporal        /tmp 
logfile         /var/log/pandora/pandora_agent.log 
interval        300 
debug           0 
agent_name      box01 
server_port     41121 
transfer_mode   tentacle 
remote_config    1 

Un exemple dans l'environnement MS Windows® serait :

server_ip       192.168.1.1 
server_path     /var/spool/pandora/data_in 
temporal        "C:\Program Files\pandora_agent\temp"
logfile         "C:\Program Files\pandora_agent\pandora_agent.log"
interval        300 
debug           0 
agent_name      box02
server_port     41121 
transfer_mode   tentacle 
remote_config   1

Par défaut, quand un agent envoie des données au serveur pour la première fois, il s’ajoute automatiquement au groupe dans lequel il s’est défini dans le fichier de configuration de l’agent. Ceci signifie que, en pratique, quiconque peut ajouter un agent à un groupe s’il connaît le nom de ce groupe. Ceci pourrait supposer un problème si plusieurs clients partagent leur instance de Pandora FMS ou si vous souhaitez contrôler ce qu’il y a dans chaque groupe.

Il est possible de configurer de façon optionnelle un mot de passe pour un groupe depuis la Console de Pandora FMS. Un agent ne s’ajoutera pas à un groupe à moins qu’il ait renseigné le mot de passe correct dans le fichier de configuration de l’agent.

Exemple

Pour configurer un mot de passe pour un groupe, naviguez dans l’éditeur de groupe et cliquez sur éditer. Renseignez le mot de passe et sauvegardez ces changements:

Pour ajouter un nouvel agent à ce groupe, éditez votre fichier de configuration et ajoutez l’option suivante de configuration:

group_password <password>

Les types de modules possibles dans des agents software en fonction du type de données rapportées sont détaillés ci-dessous :

• generic_data : Données numériques et de virgules flottantes.
• generic_data_inc : Type de données numériques croissantes. Il conserve la différence entre la donnée précédente et l’actuelle, divisée par le temps écoulé en secondes, montrant le taux par seconde. Ce type de données s’utilisent pour compter le « nº de fois par seconde » de quelque chose, comme par exemple des entrées dans un log/sec, bytes reçus/sec, connections entrantes/sec, etc.
• generic_data_inc_abs : Type de données numériques croissantes absolues. Il conserve la différence entre la donnée précédente et l’actuelle, sans réaliser la division entre les secondes écoulées. C’est pourquoi la valeur correspondra à l’augmentation totale entre les deux exécutions et non à l’augmentation par seconde. Ce type de données s’utilise pour compter le nombre de fois de quelque chose, comme par exemple, des entrées dans un log, bytes totaux reçus, le nombre de connections entrantes, etc.
• generic_proc : Type de données booléennes, où une valeur 0 signifie Faux ou incorrecte et des valeurs supérieures à zéro signifient Vrai ou correctes. Les types generic_proc amènent préconfigurés les états « critique (0) et correct (1 ou plus) ».
• generic_data_string : Type de données alphanumériques (texte).
• async_data : Type de données numériques asynchrones. De la même façon que generic_data mais pour des données asynchrones, qui ne se mettent à jour que lorsqu’il existe un changement. Les types de données asynchrones n’ont pas de fréquence définie pour obtenir des données.
• async_string : Type de données alphanumériques asynchrones. De la même façon que genric_string mais pour des données asynchrones, qui ne se mettent à jour que lors de changement. C’est le type de données que nous devrions utiliser pour surveiller des recherches dans les logs, ou afficheurs d’évènements, puisque nous pouvons avoir une donnée par seconde ou bien aucune pendant plusieurs jours
• async_proc : Type de données booléennes asynchrones. Semblable à generic_proc mais pour des données asynchrones, qui ne s’actualisent que lorsqu’il existe un changement.
• Module d'image : Ils utilisent comme base un module de type chaîne de caractères (generic_data_string o async_string). Si la donnée que contient le module est une image codifiée en base 64, autrement dit, si une partie de la chaîne de caractères a « data:image », elle sera identifiée comme une image et activera dans les vues qui lui seront listées, un lien à une fenêtre pour visualiser l’image, en plus de présenter dans leur historique respectif, un contenu historique des différentes images que formeraient les chaînes stockées.

Les modules locaux (ou d’agent software) ont tous comme « base » l’intervalle de son agent. Mais ils peuvent prendre des valeurs multiples de cette base si le paramètre moduel_interval est modifié en le multipliant avec un numéro entière plus élevé que zero, par exemple :

module_interval 2

Si l'agent a une intervalle de 300, le module de l’intervalle sera de 300×2.

La création de modules locaux dans la console se réalise au moyen d’un formulaire, sur lequel, en plus de la configuration commune de tout module (seuils, types, groupe…), une boîte de texte est disposée où sont spécifiées les données de configuration qui iront dans le fichier de configuration de l’agent software.

• En cliquant sur Load basic (template), le contenu de Data configuration sera éliminé avec un modèle de base que vous devez modifier selon vos besoins de supervision.
• Une fois modifié, cliquez sur Check (syntax) pour vérifier que le syntax du modèle soit correcte, mais le reste de composants ne seront pas vérifiés.

Quand un module est chargé depuis un composant local, il peut avoir des macros. S’il en a, la boîte de configuration sera alors cachée et un champs pour chaque macro apparaîtra. Cette caractéristique est expliquée plus en détails dans la section de modèles er composants

L’agent software de Pandora FMS supporte l’exécution de commandes et scripts sous forme de postconditions. Cela signifie que des actions pourraient être réalisées selon la valeur obtenue lors de l’exécution du module.

Exemple 1

Grâce au paramètre module_condition, vous indiquerez une valeur ou un rang de valeurs ainsi que l’exécution à réaliser dans le cas où le module prend l’une de ces valeurs (utilisation de l'UCT mineur que 20 %) :

 module_begin
 module_name CPU_Usage_Condition
 module_type generic_data
 module_exec get_cpu_usage.pl
 module_condition < 20 add_processes.sh
 module_end

Exemple 2

De multiples conditions peuvent être spécifiées pour un même module, dans un rang et avec un seuil minimal (mathématiquement quelque ou aucune des deux options est réalisée) :

module_begin
module_name CPU_Usage_Condition
module_type generic_data
module_exec get_cpu_usage.pl
module_condition (90, 100) remove_processes.sh
module_condition < 20 add_processes.sh
module_end

Exemple 3

Similaire à l'exemple précédent, mais il peut exécuter les deux conditions ou une d'entre les deux aussi qu'aucune (essayer avec les valeurs choisis : si c'est 5, 15 ou 30) :

module_begin
module_name CPU_Usage_Condition
module_type generic_data
module_exec get_cpu_usage.pl
module_condition < 10 start_new_server.sh
module_condition < 20 add_processes.sh
module_end

Le paramètre module_precondition permet d’évaluer une condition avant l’exécution du module et, en fonction du résultat, décider si le module doit s’exécuter ou non.

Exemple 1

Selon l'utilisation de l'UCT, s'il y a plus de dix processus actifs, obtenir le percentage d'utilisation de l'UCT et reporter au serveur Pandora FMS :

 module_begin
 module_name CPU_Usage
 module_type generic_data
 module_precondition> 10 number_active_processes.sh
 module_exec get_cpu_usage.pl
 module_end

Exemple 1

De multiples pré-conditions peuvent être spécifiées pour un même module et toutes doivent être remplies :

 module_begin
 module_name CPU_Usage
 module_type generic_data
 module_precondition> 10 number_active_processes.sh
 module_precondition> 1 important_service_enabled.sh
 module_exec get_cpu_usage.pl
 module_end

Dans ce cas, le module s'exécute seulement s'il y a plus de dix processus actives et si au moins l'un d'entre eux et un processus important.

Il existe certains modules qui ont une importance spéciale, comme des processus ou des services critiques en exécution. Pour pouvoir avoir une surveillance plus contrôlée de ces cas, il existe la surveillance intensive.

Cela consiste à prévenir, en un intervalle plus court, qu’un problème est apparu sans qu’il n’y ait besoin de réduire l’intervalle général de l’agent.

L’agent software présente deux paramètres de configuration :

• interval : temps de collecte de l’agent en secondes. C’est l’intervalle général pour tous les modules locaux. Paramètre obligatoire.
• intensive_interval : temps pendant lequel il nous avertit d’un problème survenu sur les modules particulièrement critiques. Paramètre optionnel.

Configuration du module :

• module_intensive_condition = 0: si le module obtient comme résultat la valeur indiquée dans ce paramètre (dans ce cas-ci, 0) l’intervalle intensif défini dans l’agent sera notifié.

Exemple

Le service sshd est très important car il est utilisé pour connecter par shell à distance, donc vous avez besoin de superviser son fonctionnement :

 intensive_interval 10
 interval 300

 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 présente une faille, une notification sera alors envoyée dans les 10 prochaines secondes. Si au contraire, il continue de fonctionner correctement, les notifications seront reçues toutes les 5 minutes (intervalle normal, 300 secondes).

L’agent software supporte la définition de modules programmés qui s’exécutent dans les moments définis. La syntaxe utilisée est la même que celle du fichier crontab. Un exemple de la définition du module pour être exécuté tous les lundis entre 12:00 et 15:00 heures serait :

 module_begin
 module_name crontab
 module_type generic_data
 module_exec script.sh
 module_crontab * 12-15 * * 1
 module_end

Pour l'exécuter le module dans le minute dix de chaque heure :

 module_begin
 module_name crontab
 module_type generic_data
 module_exec script.sh
 module_crontab 10 * * * *
 module_end

Lorsque le serveur principal de Pandora FMS n’a pas accès pour faire des vérifications à distance (généralement pour des raisons de sécurité), un agent logiciel prend sa place pour ces tâches et peut les distribuer en agents broker.

Les tests ICMP ou ping sont très utiles pour savoir si une machine est connectée ou non à un réseau. De cette manière, un seul agent software pourrait surveiller l’état de toutes les machines d’une simple façon.

Unix

En utilisant les commandes du système (tous les paramètres de la « ligne de commande » module_exec) :

module_begin
module_name Ping
module_type generic_proc
module_exec ping -c 1 192.168.100.54 >/dev/null 2>&1; if [ $? -eq 0 ]; then echo 1; else echo 0; fi
module_end

Note : Remplacez 192.168.100.54. par l'adresse IP à superviser.

MS Windows®

Les paramètres doivent être spécifiés dans module_ping_count (nombre de paquets 1 par défaut) et module-ping_timeout (limite de temps en secondes, 1 par défaut), par exemple :

module_begin 
module_name Ping
module_type generic_proc
module_ping 192.168.100.54
module_ping_count 2
module_ping_timeout 5
module_end

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

Les test TCP sont utiles pour vérifier que les ports d’une machine restent bien ouverts et permettent savoir si une application est connectée ou non à un réseau.

Unix

Avec la commande nmap et ses paramètres de configuration dans la ligne de commande, à une adresse IP vous vérifiez si le port 80 est ouvert (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 sont spécifiés dans :

• module_tcpcheck : Adresse IP de l'appareil.
• module_port : Numéro de port.
• module_timeout : Temps d'attente de réponse.

Exemple :

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

Les tests SNMP sont très communs dans la supervision d'appareils réseau pour vérifier l’état des interfaces, bytes d’entrée et sortie, etc.

Unix

En utilisant la commande snmpget comme dans l’exemple suivant :

module_begin
module_name SNMP get
module_type generic_data
module_exec snmpget 192.168.100.54 -v 1 -c public .1.3.6.1.2.1.2.2.1.1.148 | awk '{print $4}'
module_end

Ce module renvoie la valeur de l’OID .1.3.6.1.2.1.2.2.1.1.148 de l’host 192.168.100.54.

MS Windows®

Configuration des paramètres :

• module_snmpversion [1,2c,3] : version de SNMP (1 par défaut).
• module_snmp_community <community> : communauté SNMP (public par défaut).
• module_snmp_agent <host> : agent SNMP objectif.
• module_snmp_oid <oid> : OID objectif.
• module_advanced_options : Options avancées pour snmpget.exe.

Example qui fait le même que l'exemple précédent :

module_begin
module_name SNMP get
module_type generic_data
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

Les agents software de Pandora FMS ont un Mode Proxy qui leur permettent d’agir précisément comme un proxy d’autres agents software, en redirigeant les fichiers de données générées par d’autres agents software vers le serveur de Pandora FMS. L’agent software qui agit en Mode Proxy peut également réaliser des tâches de supervision.

Le scénario habituel d’usage du mode proxy, c’est lorsque nous nous retrouvons sur un réseau sur lequel seulement une machine est reliée au serveur de Pandora FMS et qu’il faut surveiller, avec des agents software, le reste des équipements de ce réseau. Les autres équipements seront reliés au proxy au lieu du serveur. Le Mode Proxy supporte les caractéristiques de Configuration à distance et Collections de Fichiers.

Configuration des paramètres :

• server_ip : IP du serveur de Pandora FMS.
• proxy_mode : Activé (1) o désactivé (0).
• proxy_max_connection : Nombre de connections simultanées du proxy, par défaut 10.
• proxy_timeout : Timeout pour le proxy, par défaut 1 seconde.
• proxy_address: Adresse dans laquelle le proxy écoute.
• proxy_port: Port dans lequel le proxy écoute.

Exemple :

 server_ip 192.168.100.230
 proxy_mode 1
 proxy_max_connection 20
 proxy_timeout 3

Pour rediriger la connection d’un agent software, vous n’aurez qu’à mettre comme adresse de serveur de Pandora FMS celle de l’agent avec le Mode Proxy activé.

Par exemple, l’agent logiciel en mode proxy a l'adresse IP 192.168.100.24, le reste des agents logiciels doivent être configurés avec :

server_ip 192.168.100.24

Le Mode Broker des agents software permet à un seul agent de réaliser des tests et de gérer la configuration comme il le ferait s’il y en existait plusieurs.

Quand s’active le mode broker dans un agent software, un nouveau fichier de configuration est créé. A partir de ce moment, l’agent software d’origine et le nouveau broker se gèrent de façon indépendante avec leurs fichiers de configuration respectifs, comme s’ils étaient deux agents software totalement séparés dans la même machine.

Les principales utilités du Mode Broker sont :

• Envoyer des données locales en tant qu’autre agent. Très utile pour surveiller des instances software en tant qu’agents indépendants.
• Envoyer à d’autres machines des données collectées des tests à distances, comme s’il y avait un agent software installé dans ces dernières.

Pour créer un broker, il n’y a qu’à ajouter une ligne avec le paramètre broker_agent <nombre_broker>. Il est possible de créer autant d’agents broker que vous le souhaitez, en ajoutant les lignes correspondantes « broker_agent », comme celles-ci :

 broker_agent dev_1
 broker_agent dev_2

Une fois créés, les brokers créeront leurs archives configuration dev_1.conf y dev_2.conf avec le même contenu que l’agent software d’origine, mais avec son nom correspondant. En ajoutant ou en enlevant des modules des archives de configuration dev_1.conf et dev_2.conf, nous pouvons personnaliser les tests réalisés par les brokers.

Dans la console de Pandora FMS, les brokers sont visibles et se gèrent comme des agents indépendants, de telle sorte que si nous avons un agent software installé avec deux brokers dans la console, nous verrons trois agents différents avec leurs modules, leurs configurations, etc.

NOTE : les instances du mode broker ne peuvent utiliser des collectes. Si vous désirez les utiliser, vous devez les distribuer et/ou les utiliser dans l’agent « réel » qui s’utilise comme base dans l’agent broker, et non dans une de ses instances.

Par exemple, il y a un agent logiciel dans la machine qui supervisera les paramètres de l'UCT, de mémoire et de de disque d'un ordinateur qui exécute une base de données aussi. De plus, dans la configuration de l’agent software, nous ajoutons la ligne :

broker_agent DBApp

Grâce à cela, nous créons l’agent broker avec pour nom DBApp et ainsi, l’archive de configuration dbapp.conf apparaîtra. Dans cet archive, nous ajoutons pour superviser la base de données (le nombre d'utilisateurs connectés et le nombre de consultes lentes) :

 module_begin
 module_name Num Users
 module_type generic_data
 module_exec get_db_users.pl
 module_end

 module_begin
 module_name Num slows queries
 module_type generic_data
 module_exec get_db_slows_queries.pl
 module_end

La console de Pandora FMS montrera l’un avec le nom de la machine et les modules de CPU, mémoire et disque et l’autre appelé DBApp avec les modules Num Users et Num slows queries.

Pour cet exemple, il y a un agent software dans une machine MS Windows® qui supervise l'UCT, mémoire et disque. Nous devons superviser un router IP 192.168.100.54 sans y installer un agent dedans. Pour résoudre le problème, nous pouvons utiliser un broker avec le paramètre :

broker_agent routerFloor5

Grâce à ce dernier, nous créons l’agent broker routerFloor5. Après, modifions le lignes du fichier routerFloor5 pour habiliter les modules disponibles de ping et snmp :

module_begin
module_name Ping
module_type generic_proc
module_ping 192.168.100.54
module_ping_count 2
module_ping_timeout 500
module_end

module_begin
module_name Eth 1 up
module_type generic_data
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.1
module_end

module_begin
module_name Eth 2 up
module_type generic_data
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.2
module_end

La console web de Pandora FMS montre deux agents, l’un est la machine Windows avec les modules CPU, mémoire et disque. L’autre est routerFloor5 avec les modules : Ping, Eth 1 up, Eth 2 up.

Dans certaines situations, il faut surveiller les dispositifs à distances, mais le Serveur à Distance de Pandora FMS ne peut y accéder directement.

L'agent logiciel en mode broker permet d'envoyer les XML au serveur de Pandora FMS come s'il s'agissait de différents appareils. Pour ça, ajoutez aussi brokers qu'appareils à superviser, par exemple :

 broker_agent device_1
 broker_agent device_2
 broker_agent device_3
 broker_agent device_4
 ...

Une fois les brokers créés, nous pouvons personnaliser la surveillance pour chaque appareil en accédant aux fichiers de configuration de chaque broker comme expliqué pour chaque agent logiciel en mode test à distance.

La capacité du Serveur à Distance de Pandora FMS est de l’ordre de 2 000 agents. En travaillant avec des agents broker on peut élever la chiffre à 3 000 et libérer le serveur principal de grande partie du travail. Dans le graphique, chaque réseau a un agent logiciel avec le mode broker activé, dans lequel nous créerons autant de brokers qu'appareils à surveiller. La configuration pour l’agent Broker_Agent_Net_A serait :

 broker_agent device_1
 broker_agent device_2
 broker_agent device_3
 broker_agent device_4
 ...

De plus, pour chacun des brokers, nous ajouterons les modules correspondants pour surveiller les dispositifs, comme expliqué déjà.

L’agent software de Pandora FMS supporte des fonctions d’inventaire aussi bien hardware que software. Le système d’inventaire permet de maintenir un historique de CPU, de cartes, Mémoire RAM, patchs, software, etc. utilisés dans les serveurs de l’entreprise. De plus, il est possible de générer des alertes face aux changements dans l’inventaire. Par exemple, un remplacement non autorisé de disque dur ou la désinstallation d’une application.

Vous pouvez trouver plus d’informations dans la section inventaire local avec des agents logiciels.

L’agent logiciel permet de recevoir des requêtes à distance ou exécuter une commande.

Pour permettre au serveur Pandora FMS d'envoyer des commandes aux agents logiciels dont il est chargée, configurez :

• udp_server: Fonction activé (1) ou désactive (0).
• udp_server_port: Port d’écoute du serveur UDP dans l’agent software.
• udp_server_auth_address: Adresse IP du serveur PAndora FMS.

Redémarrez l'agent logiciel pour appliquer les modifications.

Il faut utiliser le script udp_client.pl, présent dans le serveur de Pandora FMS et normalement placé dans /usr/share/pandora_server/util. Nous pouvons l’exécuter depuis la ligne de commande ou bien l’utiliser dans une alerte, au moyen de la commande préconfiguréedans la console « Remote agent control ».

Il existe aussi une action d’alerte par défaut appelé Restart agent, qui utilise ce script en utilisant l’action REFRESH AGENT.

Après vous pouvez forcer l'execution de l'alerte ou forcer un état incorrecte du module pour que l'alerte soit activé et ainsi vérifier la configuration.

En outre l'action de redémarrer le service d'agent logiciel, vous pouvez spécifier des actions personnalisées. À cette fin, il faut ajouter une ligne pour chaque commande à exécuter, avec la structure suivante :

process_<nomdelacommande>_start commande

Par example, si vous souhaitez une commande distante pour initier le service sshd :

process_sshd_start /etc/init.d/sshd start

Après, il faut créer une action d'alerte dans Pandora FMS Console pour chaque commande distante que vous ayez créé. La commande à utiliser sera « Remote agent control » (créé par défaut, elle est prêt à envoyer des commandes UDP) e ajouter dans le champ 1 « START PROCESS sshd » :

Puis créer une nouvelle alerte manuelle avec la nouvelle action dans l'agent dont vous souhaitez initier le service sshd ; lors que l'alerte soit forcée, l'ordre sera envoyée et l'agent logiciel démarrera le service.

En plus de l’action de rafraîchissement de l’agent, nous pouvons spécifier des actions personnalisées à réaliser sur les agents, au moyen des ordres UDP depuis le serveur de Pandora. Dans le cas de vouloir le faire, il faut faire une petite configuration extra dans l’archive pandora_agent.conf. en plus, bien sûr, d’activer le service UDP et de le configurer pour qu’il reçoive les ordres du serveur :

 udp_server 1
 udp_server_port 41122
 udp_server_auth_address <IP del servidor>

Nous devrons ajouter une ligne pour chaque commande que nous souhaitons exécuter, avec le schéma suivant :

process_nombredelaorden_start comando

Par exemple, si nous souhaitons un ordre à distance pour démarrer le service sshd :

process_sshd_start /etc/init.d/sshd start

Ci-dessous, nous devrons créer une action d’alerte sur Pandora Console pour chaque commande à distance que nous avons créée. La commande à utiliser sera « Remote agent control » (créée par défaut, elle est conçue pour envoyer des ordres UDP). Dans le champs 1, nous écrirons « START PROCESS sshd », comme sur la capture ci-dessous :

A présent, il n’y a plus qu’à créer une nouvelle alerte manuelle avec la nouvelle action dans l’agent dont nous souhaitons démarrer le service sshd. En forçant l’alerte, l’ordre se lancera et l’agent démarrera le service.

Les plugins dans des agents software permettent de réaliser des vérifications avancées et complexes depuis les agents software, en pouvant renvoyer comme résultat plusieurs modules au lieu d’une seule valeur. A la différence des plugins de serveur qui sont exécutés par le serveur de Pandora FMS, les plugins d’agent renvoient leurs données dans un XML, en faisant un rapport sur un ou plusieurs modules à la fois.

Sur MS Windows®, tous les plugins par défaut sont programmés sur VBScript. Pour les exécuter, il faut utiliser l'interprète adéquat en indiquant le chemin complet. Exemples :

module_plugin cscript.exe //B "%ProgramFiles%\Pandora_Agent\util\logevent_log4x.vbs" Aplicacion System 300
module_plugin cscript.exe //B "%ProgramFiles%\Pandora_Agent\util\df.vbs"
module_plugin cscript.exe //B "%ProgramFiles%\Pandora_Agent\util\ps.vbs" iexplore.exe myapp.exe

L’agent Windows amène divers plugins prêts à être utilisés.

Par défaut, les plugins de Unix se cherchent dans le répertoire /etc/pandora/plugins, ils sont invoquées et appress les paramètres nécessaires sont indiqués :

  module_plugin grep_log /var/log/syslog Syslog .
  module_plugin pandora_df tmpfs /dev/sda1

L’agent software Unix amène plusieurs plugins par défaut prêt à fonctionner.

Dans la version Enterprise, il est possible d’administrer les plugins des agents software depuis la console sans éditer directement le fichier de configuration. Si un agent a la configuration à distance activée, il disposera, dans sa vue d’administration, de l’onglet éditeur de plugins.

Cet aparté montre la liste des plugins actifs dans l’agent et permet de les éliminer, de les ajouter ou de les désactiver. Dans le cas de plugins de politique, il peut être judicieux de les désactiver. En effet, en réinitialisant la politique d’origine, il se maintiendront désactivés.

Les plugins administrés dans cet éditeur peuvent être, à leur tour, édités depuis le fichier de configuration de l’agent.

Les plugins pour l’agent software peut renvoyer une donnée ou tout un groupe. Un exemple de plugins qui renvoie une donnée peut être le plugin ps.vbs de Windows, qui vérifie simplement si un processus est en cours d’exécution.

module_plugin cscript.exe B “%ProgramFiles%\Pandora_Agent\util\ps.vbs” IEXPLORE.EXE Le résultat sera un module qui renvoie 0 si le processus n’est pas actif et 1 s’il l’est : <code> <module> <name><![CDATA[IEXPLORE.EXE]]></name> <description><![CDATA[Process IEXPLORE.EXE status]]></description> <![CDATA[1]]> </module> </code> === Exemple 2 === Un exemple de plugin qui renvoie plusieurs donnée peut être le plugin df.vbs de Windows. La ligne pour exécuter le plugin serait : module_plugin cscript.exe B “%ProgramFiles%\Pandora_Agent\util\df.vbs”

Résultat :

<module>
    <name><![CDATA[C:]]></name>
    <description><![CDATA[Drive C: free space in MB]]></description>
    <![CDATA[8050]]>
</module>

<module>
    <name><![CDATA[D:]]></name>
    <description><![CDATA[Drive D: free space in MB]]></description>
    <![CDATA[900]]>
</module>

Il est possible d'ajouter un token dans la configuration des plugins de l'agent qui lorsqu'il est habilité permet l'option d'encapsuler ls définitions des plugins dans les étiquettes module_begin et module_end.

Ce token habilité permet d'insérer des bloques de configurations tels que module_interval ou module_crontab, entre d'autres.

Pour habiliter ce token il faut juste de vous déplacer dans la gestion des agents à l'élément plugins d'agent et au dessus de la configuration vous le trouverez sous le nom Advanced.

Les plugins peuvent être créés dans n¡importe quel langage de programmation. Mais gardez à l'esprit les normes générales et les normes spécifiques pour son développement.

Nagios a un grand nombre de plugins qui peuvent s’utiliser avec Pandora FMS. Une façon de s’en servir est d’utiliser les plugins à distance avec le PluginServer, en utilisant la compatibilité de Nagios. Mais de cette manière, il n’obtiendra que ses états puisqu’il n’utilise pas le output descriptif que possèdent certains plugins pour Nagios.

Utiliser le wrapper pour se servir des plugins de Nagios dans l’agent software résoudra ce problème. Le wrapper vient par défaut avec l’agent de Unix 3.2. Un plugin équivalent pour les agents Windows de Pandora FMS peut se télécharger depuis la librairie de ressources de Pandora FMS.

Fonctionnement général

Le wrapper exécute le plugin de Nagios, en utilisant ses paramètres d’origines et en transformant le output en données utiles pour Pandora FMS. Il possède deux types d’information :

• Information proche du Status : NORMAL (1), CRITICAL (0), WARNING (2), UNKNOWN () et autres (4). Par défaut, ils utiliseront un module proc, selon les valeurs NORMAL et CRITICAL qui s’exécutent « par défaut ». Si vous désirez des informations proches de WARNING et autres valeurs, vous devrez configurer les seuils du module de façon manuelle.

• Information de type descriptif : en général sous forme d’information de chaînes, se situant dans le champs de description du module, par exemple :

<![CDATA["OK: successfully logged in"]]>

Il existe un module spécial, un genre unique appelé keep_alive, qui sert à donner une information face à l’absence de contact de l’agent (voir Actions distantes par UDP). Cette alerte se produit lorsque la date de son dernier contact n'est pas mis à jour depuis le double de son intervalle, en s'activant et marquant le moniteur en état Critical.

Création d'un nouveau module de type « KeepAlive »:

Fonctionnement en état « NORMAL » (vert), « NOT INITIALIZED » (bleu):

Si l’agent cesse d’envoyer des données (dans cet exemple, il avait un intervalle de 1 minute, alors il passera automatiquement en état CRITICAL (rouge). Pour afficher ce type de modules, vous pouvez aller dans le menu latéral gauche et sélectionner Monitoring → Views → Monitor detail (interface de Pandora FMS) et dans la boîte de dialogue du filtre, le champ Data type sélectionnez KeepAlive puis cliquez sur le Show:

Le module keepalive, par ailleurs, se comporte comme n’importe quel module. Il peut s’associer à une alerte et peut s’utiliser pour n’importe quel élément : rapports, cartes, etc.

Commandes qui présentent de vastes sorties, comme top ou netstat qui peuvent être capturées et montrées complètement par un module. Le module doit se configurer comme type texte.

Dans la console, activez l'option :

Cette méthode permet de définir des modules de type chaîne (generic_data_string ou async_string) qui contiennent des images en format texte avec une codification base64, pouvant montrer ladite image au lieu d’un résultat concret. Cette dernière se conserve comme information de texte et se visualise d’une forme différente, non pas comme simples données mais en reconstruisant une image en cliquant sur l'icône special pour captures d'image :

Pour capturer ces images, il suffit d’écrire un plugin qui envoie toutes les données, en générant les tags XML nécessaires et en exécutant le plugin comme tel, avec la directive module_plugin. Exemple:

#!/bin/bash
echo "<module>"
echo "<name>Líder actual de la liga</name>"
echo "<type>async_string</type>"
echo "<data><![CDATA[data:image/jpeg;base64,/9j/4AAQSkZ....]]></data>"

// La donnée précédente serait générée par un dispositif/application donnant des images en base64.

echo "</module>"

Enregistrez ce contenu dans une archive dans l’agent (ou répartissez-le avec des collectes de fichiers) et exécutez-le de la façon suivante :

module_plugin <path complet au fichier>

L’agent software pour des systèmes Windows a des fonctionnalités spécifiques pour cette plate-forme qui aident à réaliser la surveillance de manière plus simple. Nous expliquerons ci-dessous les fonctionnalités et appliquerons des exemples de ces dernières.

Le paramètre module_proc vérifie si un nom de processus déterminé est en cours d’exécution dans la machine. La définition du module serait :

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

Si vous voulez que l’agent software de Windows vous avertisse immédiatement lorsqu’un processus cesse de fonctionner, ajoutez le paramètre module_async yes (voir normes communes au début de la section Windows) :

 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 de l’agent software de Pandora FMS pour Windows permet d’agir immédiatement face à la chute d’un processus, pour le redémarrer à nouveau. Exemple :

 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 c:\windows\notepad.exe
 module_startdelay 3000
 module_retrydelay 2000
 module_retries 5
 module_end

Watchdog s’activera chaque fois que le processus notepad.exe sera désactivé et la commande c:\windows\notepad.exe s’exécutera (voir normes communes au début de la section Windows). Il essayera le redémarrage du processus 5 fois avec un temps d’attente initial de trois secondes et de deux secondes entre chaque tentative dans la session active de l’utilisateur.

Le paramètre module_service vérifie si un service déterminé est en cours d’exécution dans 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

Si vous souhaitez que l’agent logiciel de Pandora FMS vous prévienne lorsqu’un service chute, ajoutez le paramètremodule_async yes (voir normes communes au début de la section Windows) :

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

il fonctionne de manière similaire au watchdog de processus. Exemple :

 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

La définition du watchdog pour services ne requiert aucun paramètre additionnel comme celui des processus parce que cette information est déjà dans la définition du service.

Cet aparté montre comment surveiller les ressources basiques d’une machine Windows.

Le paramètre module_cpuusage renvoie le pourcentage de CPU en usage. Il est possible de surveiller les cpu par id avec la définition suivante de module :

 module_begin
 module_name CPU_1
 module_type generic_data
 module_cpuusage 1
 module_description CPU usage for CPU 1
 module_end

Il est possible de surveiller l’usage moyen de toutes les CPUs du système avec le module :

 module_begin
 module_name CPU Usage
 module_type generic_data
 module_cpuusage all
 module_description CPU Usage for all system
 module_end

Pour surveiller la mémoire, il existe deux paramètres : module_freememory qui renvoie la quantité de mémoire libre du système et module_freepercentmemory qui renvoie le pourcentage de mémoire libre du système.

Un module d’exemple utilisant module_freememory serait:

 module_begin
 module_name FreeMemory
 module_type generic_data
 module_freememory
 module_description Non-used memory on system
 module_end

Un module d’exemple utilisant module_freepercentmemory serait :

 module_begin
 module_name FreePercentMemory
 module_type generic_data
 module_freepercentmemory
 module_end

Pour surveiller le disque, nous disposons de deux paramètres : module_freedisk qui renvoie la quantité d’espace libre et module_freepercentdisk qui renvoie le pourcentage d’espace libre. Les deux modules nécessitent comme paramètre l’unité de disque à surveiller. Ne pas oublier le caractère :.

 module_begin
 module_name FreeDisk
 module_type generic_data
 module_freedisk C:
 module_end

Un exemple de module qui utilise le paramètre module_freepercentdisk :

 module_begin
 module_name FreePercentDisk
 module_type generic_data
 module_freepercentdisk C:
 module_end

L’agent software de Pandora permet d’extraire une information à travers des consultations WMI, qui est une source d’information largement utilisée pour obtenir une information du système ainsi qu’externe à ce dernier.

En utilisant le paramètre module_wmiquery, l’agent software permet d’exécuter localement n’importe quelle consultation WMI. Pour réaliser la consultation, la query WMI se définit dans le paramètre module_wmiquery et la colonne qui contient l’information à surveiller, avec le paramètre module_wmicolumn.

Par exemple, vous pouvez obtenir une liste des services installés :

 module_begin
 module_name Services
 module_type generic_data_string
 module_wmiquery Select Name from Win32_Service
 module_wmicolumn Name
 module_end

Oobtenir la charge actuelle de l'UCT :

 module_begin
 module_name CPU_Load
 module_type generic_data
 module_wmiquery SELECT LoadPercentage FROM Win32_Processor
 module_wmicolumn LoadPercentage
 module_end

À partir de la version 7 de Pandora FMS les agents ont un alias et un nom (ou identificateur unique). Un agent configuré par défaut générera un nom (ou identifiant) basé sur une chaîne hexadécimale pseudo-aléatoire et un alias (ou nom visible) basé sur le hostname de la machine.

Dans versions précédentes, il existait seulement le « nom » de la machine et la système précédent est totalement compatible avec les versions les plus modernes de Pandora FMS, mais si dans la même installation de Pandora FMS, vous trouvez des agents avec le même identifiant (ou noms) les données des deux agents seront combinés ou superposés. Pour ça, nous avons introduit à partir de la version 7 la possibilité des agents avec différent nom d'avoir le même alias.

Pour changer ce comportement, les token de configuration suivants sont utilisés :

 pandora_agent
 pandora_alias

Par défaut, le fichier de configuration n'utilise pas aucun d'entre eux, donc il obtient le hostname de la machine en tant qu'alias et un numéro hexadécimale aléatoire très longue en tant que nom ou identifiant. Le nom de l'agent n'est pas visible (except pour la vue détaillée de l'agent) et NE peut pas être changée. L'alias de l'agent peut être changée n'importe quand, sans avoir a vous inquiéter au sujet de la configuration de l'agent logiciel, car le « nom » de l'agent est utilisé pour identifier l'agent sans equivocation.

Retour à l'index de documentation du Pandora FMS