Pandora: Documentation fr: Operation

From Pandora FMS Wiki
Jump to: navigation, search

Revenir à l’Index de Documentation Pandora FMS

Contents

1 Surveillance avec agents software

1.1 Nom des agents

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

Dans les versions précédentes, il n’existait que le “nom” de la machine.Le système antérieur est totalement compatible avec les versions plus modernes de Pandora. Cependant, si sur une même installation de Pandora, le logiciel rencontre deux agents avec le même identificateur (ou noms), les données de ces derniers se mélangeront et/ou seront écrasées. C’est donc pour cela que nous avons mis au place, depuis la version 7, la possibilité que des agents avec différents noms puissent avoir des pseudos identiques.

Pour modifier ce comportement, on utilise les token de configuration suivants :

pandora_agent
pandora_alias

Par défaut, le fichier de configuration n’utilise aucun des deux, de sorte à ce qu’il obtienne le hostname de la machine comme pseudo et un grand nombre hexadécimal aléatoire comme nom ou identificateur. Le nom de l’agent n’est plus visible (sauf dans la vue détaillée de l’agent) et NE peut se changer. Le pseudo de l’agent peut être modifié à tout moment, sans avoir à se soucier de la configuration de l’agent software, puisque ce qui permet d’identifier de façon unique l’agent est le “nom” de ce dernier.

1.2 Configuration des agents

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.

1.2.1 Configuration à distance

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

Sw-agent.png


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

Info.png

Une fois que la configuration à distance de l’agent est activé, tout changement qui se fera localement dans le fichier de configuration sera écrasé par la configuration conservée dans la console. Si vous souhaitez éviter cela, arrêtez l’agent, modifiez le fichier de configuration et désactivez la configuration à distance. Enfin, relancez l’agent de nouveau.

 


1.3 Paramètres de configuration communs

Dans la partie agents logiciels de Pandora FMS, il est possible de trouver une explication plus détaillée de la configuration de l’agent. Dans cet aparté, nous allons préciser les paramètres les plus importants pour la configuration basique de l’agent.

Les paramètres les plus utilisés sont :

  • 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.
  • debug : activez (1) le mode debug pour sauvegarder les fichiers de données XML en local et pouvoir les analyser. Lorsqu’il est activé, il n’envoie pas les XMLs au serveur et stoppe son exécution, pour pouvoir analyser le XML généré.
  • agent_name : nom de l’agent. Par défaut, il prend celui de l’hostname.
  • remote_config : activation de la configuration à distance. Par défaut, 0 (désactivée). Uniquement pour version Enterprise.

Un exemple des paramètres généraux depuis une configuration Unix 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 des paramètres généraux depuis une configuration 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

1.4 Custom fields

Les champs personnalisés permettent d’ajouter une information additionnelle à l’agent. Vous pouvez les créer dans Resources > Custom fields.


Customfields1.JPG


Custom fields2.png


Info.png

Des liens pourront être inclus dans les custom fields en utilisant les étiquettes [url]lien[/url] ou [url=lien]Nom web[/url].

 


Au moment de créer des custom fields propres, les paramètres suivants pourront être spécifiés :

  • Name : nom du champs personnalisé.
  • Password type : les champs avec ce paramètre activé apparaîtront sous forme d’astérisques.
  • Display on front : avec ce paramètre activé, l’information du champs personnalisable sera renseigné dans la vue générale de l’agent, comme ci-dessous :


Customfields3.JPG


  • Enabled combo: ce paramètre permet d’activer la configuration de paramètres à sélectionner depuis un menu déroulant. Une fois activé, un nouveau champs apparaîtra dans la fenêtre de configuration du custom field correspondant afin d’ajouter les valeurs de la combinaison, séparés par des virgules.

Template warning.png

Si le paramètre “Enabled combo” s’active, “Password type” restera désactivé.

 



Customfields2.JPG


Ces custom fields peuvent aussi être donné depuis le fichier de configuration de l’agent, en utilisant le token suivant de configuration :

custom_field1_name Model
custom_field1_vale i386

Cet exemple permet d’utiliser un champs personnalisé d’agent défini dans le .conf de l’agent.

1.5 Surveillance avec agent software

Les agents software sont exécutés dans les mêmes systèmes que ceux récoltant des informations. “Chaque checklist” qu’ils font sur le système, comme l’usage de CPU, la mémoire libre ou l’espace sur le disque dur, correspond à un “module”. Par conséquent, chacun de ces modules rassemble une unique donnée à chaque exécution.

Il existe également quelques “directives” propres à l’agent qui permettent de rassembler certaines données directement depuis le système opératif (ex : utilisation de CPU, mémoire, évènements…). Avec ces directives propres à l’agent, il n’est pas nécessaire d’exécuter des commandes. Consultez la documentation de configuration de l’agent pour plus de détails.


Agent-monitoring.png


Les agents software de Pandora FMS utilisent les commandes propres au système opératif dans lequel ils sont installés pour obtenir l’information pour chacun de ses modules. Le serveur de données (dataserver) de Pandora FMS traite et conserve dans la base de données toute l’information générée par les agents software, permettant ainsi aux données d’arriver dans un fichier XML.

Esquema-3.png
Schéma logique d’un agent/ agent physique


Dans l’archive de configuration de l’agent, les modules sont définis selon la structure basique de texte suivante :

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

Un cas concret :

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

La ligne module_exec contient la commande qui s’exécutera pour collecter l’information. La valeur en retour de cette exécution sera la donnée qu’obtiendra le module et sera montré dans la surveillance. Une autre commande pour obtenir une information via module_exec serait :

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

Pour collecter l’information, l’agent exécutera la commande dans l’interface système de la même façon que le ferait un opérateur. C’est pourquoi en cas de doute, il est toujours conseillé de lancer la commande manuellement et d’analyser la sortie :

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

La valeur en retour obtenue par l’exécution sera conservée dans le XML comme donnée du module. Il est possible d’indiquer n’importe quelle chose dans la ligne “module_exec tant que la sortie est compatible avec les valeurs acceptées par Pandora (numérique, alphanumérique ou booléenne). C’est pourquoi il est possible d’indiquer des scripts personnalisés :

module_exec myScript.pl --h 127.0.0.1 -v cpu

A nouveau, l’agent exécuterait la commande dans l’interface système et collecterait le résultat comme l’écrirait un opérateur dans l’interface système :

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

Quand un agent software démarre et s’exécute pour la première fois, il envoie son fichier XML au serveur de Pandora FMS, qui crée automatiquement le nouvel agent avec tous ses modules.

1.5.1 Types de modules

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.
  • Modulo de imagen : 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 conservées.

L’agent software est configuré au préalable pour envoyer certaines données du système dans lequel il est installé. En général, ces dernières sont (varient selon la version) :

  • CPU du système.
  • Espace libre sur disque.
  • Mémoire libre.
  • Moniteur de l’état des programmes et/ou des services.

1.5.2 Intervalles dans les modules locaux

Les modules locaux (ou d’agent software) ont tous comme “base” l’intervalle de son agent. C’est-à-dire que si un agent a un intervalle de 5 minutes (300 secondes), tous les modules auront par défaut un intervalle de 5 minutes. Vous pourrez permettre qu’un module ait un intervalle supérieur mais vous ne pourrez en aucun cas en établir un qui soit inférieur à l’intervalle de base de l’agent. En effet, l’intervalle d’un module se définit comme un multiplicateur de l’intervalle de l’agent. Si un agent a un intervalle de 300 et qu’un module de cet agent a la configuration suivante :

module_interval 2

Le module de l’intervalle sera de 300x2. Le paramètre module_interval n’admet uniquement que valeurs entières supérieures à zéro.

1.5.3 Interface de création de modules

(Uniquement Enterprise)

Dans le version Enterprise, il est possible de créer et de gérer des modules locaux des agents software s’ils ont le paramètre “remote_config 1”. Dans le cas où vous ne disposez pas de la version Enterprise, toutes ces opérations devront se faire directement sur le fichier de configuration de l’agent software, de façon locale dans le système où l’agent est installé.

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.

Création d’un module avec le remote config de l’agent activé :



Local module editor.png



“Deux boutons” sont joints à cette boîte de texte. L’un pour “créer une structure basique” de configuration et l’autre pour “vérifier que les données de configuration sont correctes”. Cette vérification concerne les paramètres basiques, contrôlant qu’ils commencent bien par module_begin et qu’ils se terminent par module_end, mais qu’ils aient aussi un type valide et un nom. D’autres paramètres pourraient être configurés par erreur et ne seraient alors pas détectés.

Le champs nom et la combinaison type sont liés aux paramètres module_name et module_type des données de configuration. C’est pourquoi, en changeant le nom du module dans le champs nom, ce dernier se changera automatiquement dans la configuration et vice-versa. De même qu’en sélectionnant un type de combinaison, le type de données de configuration se changera et lorsqu’un type s’écrira correctement dans la boîte de configuration, la même combinaison sera alors sélectionnée.

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

1.5.4 Surveillance conditionnée

1.5.4.1 Postconditions

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

Grâce au paramètre module_condition, nous indiquerons 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 :

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

De multiples conditions peuvent être spécifiées pour un même module. Par exemple :

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

Exemples :

Exécution quand la valeur du module est inférieure à 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

Dans l’exemple précédent, supposons que le script get_cpu_usage.pl renvoie 18. Dans ce cas, l’agent software exécuterait le script add_proceses.sh.

Exécution avec deux postconditions :

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

Supposons que la donnée soit 15. Dans ce cas, l’agent exécuterait uniquement le script add_processes.sh. Si la valeur de la donnée était 6, alors l’agent exécuterait les deux scripts start_new_server.sh et add_processes.sh

1.5.4.2 Préconditions

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. La définition dans l’archive de configuration est :

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

De multiples préconditions peuvent être spécifiées pour un même module :

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 l’exemple ci-dessus, nous avons deux préconditions. Pour que le module s’exécute, toutes les préconditions doivent être réunies. Dans le cas inverse, le module ne s’exécutera que lorsque le script number_active_processes.sh renverra un nombre supérieur à 10 et que le script important_service_enabled.sh renverra 1.

Exécution du module seulement lorsque la précondition est supérieure à 10 :

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

Dans l’exemple précédent, le script 'number_active_processes.sh' va s’exécuter si la valeur de renvoi est supérieure à 10. Dans ce cas, le script du module s’exécutera.

1.5.5 Surveillance intensive

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.

Au niveau du module, le paramètre module_intensive_condition sera utilisé pour déterminer sous quelle condition l’état du module sera notifié pendant le temps défini par l’intervalle intensif dans intensive_interval.

  • 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é.

Dans l’exemple suivant, nous présentons la configuration d’un agent pour ceux qui souhaitent être prévenu en 10 secondes si le processus sshd a cessé de fonctionner :

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, de façon normal.

1.5.6 Surveillance programmée

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

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

Dans cet exemple, le module s’exécute tous les lundis entre midi et 15h.

Si, par exemple, nous souhaitons exécuter le module chaque heure et dix minutes, la définition du module sera :

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

Info.png

Il faut prendre en compte que si nous utilisons un intervalle qui fasse que le module ne renvoie pas de données, ce dernier se mettra en état “inconnu”. Utilisez des modules asynchrones dans ces cas.

 


1.6 Surveillance spécifique pour Windows

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.

1.6.1 Surveillance de processus et watchdog de processus

1.6.1.1 Surveillance de processus

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 le nom du processus contient des espaces blancs ne pas utilisez «" "». Le nom du processus doit être identique à celui que montre l’Administrateur de Tâches (taskmngr) de Windows comprenant l’extension .exe. Il est important de “respecter les majuscules et les minuscules”.

Si nous voulons que l’agent software de Windows nous avertisse immédiatement lorsqu’un processus cesse de fonctionner, nous devons ajouter le paramètre module_async yes. La définition du module serait ainsi :

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

1.6.1.2 Watchdog sur les processus

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. Le Watchdog “ne fonctionne que si le module est asynchrone”. La définition d’un module avec Watchdog serait semblable à cela :

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

Dans l’exemple précédent, le watchdog s’activera chaque fois que le processus notepad.exe sera désactivé et la commande c:\windows\notepad.exe s’exécutera. De plus, si nous voyons les autres paramètres de configuration du watchdog, nous verrons qu’il tentera 5 fois de réactiver le processus, avec un temps d’attente initial de trois secondes et de deux secondes entre chaque tentative. Dans cet exemple, le processus notepad.exe se lancera dans la session de l’utilisateur.

1.6.2 Surveillance de services et watchdog de services

1.6.2.1 Surveillance de services

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 le nom du service contient des espaces blancs, n’utilisez pas «" "». Pour trouver le nom du service, vous pouvez regarder celui qui apparaît comme Service Name dans le gestionnaire de services de Windows. Il est important de “respecter les majuscules et minuscules” De même qu’avec les processus, si nous souhaitons que l’agent software de Pandora nous prévienne lorsqu’un service chute, nous devons ajouter le paramètremodule_async yes/ La définition du module serait alors :

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

1.6.2.2 Watchdog de services

De même que pour les processus, il existe pour les services un mode watchdog qui permet de relancer un service quand il chute. Un exemple de définition de module avec watchdog pour services serait :

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.

1.6.3 Surveillance de ressources basiques

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

1.6.3.1 Surveillant la CPU

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

1.6.3.2 Surveillant la mémoire

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

1.6.3.3 En surveillant le disque

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 «":"».

Un module qui utilise le paramètre module_freedisk est défini tel que :

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 est défini tel que :

module_begin
module_name FreePercentDisk
module_type generic_data
module_freepercentdisk C:
module_end

1.6.3.4 Consultations WMI

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, nous pouvons 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

En utilisant WMI, nous pouvons aussi obtenir la charge actuelle de CPU :

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

1.7 Tests à distance avec l’agent software

Les tests à distance réalisés avec l’agent software facilitent la surveillance de réseaux complexes et avec des conditions spéciales, par exemple en lien avec la sécurité.

Cette façon de travailler s’utilise habituellement quand on souhaite lancer des tests à distances sur des systèmes sur lesquels le serveur principal de Pandora FMS n’a pas accès, pour lequel nous pouvons installer un agent software, exécuter à partir de là des tests à distance et les distribuer en “agents broker”.

Cette section explique comment utiliser cette caractéristique des agents software.

1.7.1 Tests ICMP

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 l’agent Linux, nous pouvons utiliser les commandes du système pour créer un module qui réalise des tests ping. La définition du module serait :

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

Dans cet exemple, nous réalisons un ping à l’host 192.168.100.54. Si nous souhaitons vérifier d’autres hosts, nous n’avons qu’à changer l’adresse IP.

Windows L’agent software pour Windows supporte des paramètres de configuration spécifiques pour configurer le test ping, comme ci-dessous :

  • module_ping_count x : nombre de paquets ECHO_REQUEST à envoyer (1 par défaut).
  • module_ping_timeout x : timeout d’attente en secondes pour chaque réponse (1 par défaut).
  • module_advanced_options : option avancées pour ping.exe.

Un exemple de configuration de module pourrait être :

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

Dans cet exemple, nous réalisons le même test qu’avant maus à partir de l’agent software pour Windows.

1.7.2 Tests TCP

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

Unix

Avec l’agent software pour Unix, nous pourrions réaliser un test TCP en utilisant le module suivant :

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

Avec ce module, nous vérifions que le port 80 de l’host 192.168.100.54 soit ouvert ouvert ou fermé. Windows

Avec l’agent software pour Windows, nous disposons de paramètres pour configurer le module. Les paramètres sont :

  • module_tcpcheck : Host que nous souhaitons vérifier
  • module_port : Port que nous souhaitons vérifier
  • module_timeout : Timeout pour le test

Un exemple de définition du module serait :

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

Ce module serait l’équivalent à l’agent software de Windows pour réaliser la vérification du port 80 sur l’host 192.168.100.54.

1.7.3 Tests SNMP

Les tests SNMP sont très communs dans la surveillance de dispositifs de réseaux pour vérifier l’état des interfaces, bytes d’entrée et sortie, etc.

Unix

Si nous utilisons l’agent software pour Unix, nous pouvons créer un module qui utilise 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.

Windows

Pour l’agent software de Windows, nous disposons des paramètres suivants :

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

Un module d’exemple pourrait être :

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

Este módulo sería el equivalente Windows para el chequeo anterior realizado con el agente software para Unix.

1.8 Mode Proxy

Template warning.png

Pour utiliser le mode proxy de l’agent de Pandora FMS sur Linux/Unix il ne peut être exécuté par l’utilisateur root. Pour cela, il faut une installation spéciale de l’agent de Pandora FMS. Vous pouvez voir comment installer l’agent de façon personnalisée dans la section installation personnalisée de l'agent.

 


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

Proxy-mode.png


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.

En plus de l’envoi des données en XML, le Mode Proxy supporte les caractérisitiques de “Configuration à distance” et “Collectes de Fichiers”

Avec toutes ces fonctionnalités, le Mode Proxy offre un fonctionnement transparent des agents software sur des réseaux avec une connectivité limitée. Pour activer le Mode Proxy dans un agent software, il faut configurer les 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.

Un exemple de configuration pourrait être :

server_ip 192.168.100.230
proxy_mode 1
proxy_max_connection 20
proxy_timeout 3

Pour rediriger la connection d’un agent software, nous n’aurons qu’à mettre comme adresse de serveur de Pandora FMS celle de l’agent avec le Mode Proxy activé. Par exemple : Notre agent en Mode Proxy a l’IP : 192.168.100.24

Dans l’agent software qui ne peut se connecter directement au serveur de Pandora, nous configurons le paramètre server_ip tel que :

server_ip 192.168.100.24

Avec cette configuration, l’agent software, avec une communication limitée, utilisera l’agent software en Mode Proxy pour communiquer avec le serveur de Pandora en maintenant toutes les fonctionnalités telles que la configuration à distance, les politiques ou encores les collectes de fichiers.

1.9 Mode Broker

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.


Modo-broker.png


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. NOTE : les modules qui sauvegardent des données en mémoire entre des exécutions (module_logevent et module_regexp en Windows) ne fonctionnent pas lorsqu’un agent broker est configuré.

1.9.1 Exemple d’usage du mode Broker

1.9.1.1 Surveiller une base données locale en tant qu’autre agent

Dans une machine, nous souhaitons surveiller les paramètres basiques (CPU, mémoire et disque). De plus nous avons une base de données installée que nous voulons surveiller de façon indépendante. Pour réaliser la surveillance, nous utiliserons la structure suivante :

  • Agent software installé : surveillance de CPU, mémoire et disque.
  • Broker base de données : surveillance de l’état interne de la base de données.

Pour cela, nous installons un agent software dans la machine qui surveillera les paramètres de CPU, de mémoire et de de disque. 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 les modules pour réaliser les tests dans la base de données.

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

Avec cet exemple, deux agents apparaîtraient dans la console de Pandora : 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.

1.9.1.2 Surveiller des dispositifs à distance en utilisant des brokers

Pour cet exemple, nous avons installé un agent software dans une machine Windows en surveillance (CPU, mémoire et disque) et nous devons surveiller un router IP 192.168.100.54 sans y installer un agent dedans. Pour résoudre le problème, nous pouvons utiliser les brokers.

Nous créons un broker avec le paramètre :

broker_agent routerFloor5

Grâce à ce dernier, nous créons l’agent broker ayant pour nom routerFloor5 et comme nous avons un agent software installé sur une machine Windows, nous pouvons surveiller le router en utilisant les modules de ping et snmp disponibles. Pour cela, nous modifierons l’archive routerFloor5 avec les lignes suivantes :

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

Dans cet exemple, 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.

1.9.1.3 Surveillance à distance de réseaux inaccessibles

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

Broker example no access.png


Dans cet exemple, nous devons surveiller à distance les dispositifs de l’un des sièges de notre entreprise depuis le siège central. Le serveur de Pandora FMS se trouve au siège central, connecté au moyen de VPN au reste des sièges. En raison de plusieurs restrictions, le serveur de Pandora FMS ne peut accéder aux machines à distance. Pour pouvoir surveiller les sièges, nous utiliserons le Mode Broker qui permet à l’agent software d’envoyer des XMLs au serveur de Pandora FMS, comme s’il était plusieurs dispositifs distincts. Dans l’archive de configuration de l’agent software, nous ajouterons autant de brokers que de dispositifs à surveiller. Un exemple de configuration serait :

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 dispositif en accédant aux archives de configuration de chaque broker. Par exemple, la configuration pour la machine Windows ayant device_1 pour nom est :

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 CPU_Load
module_type generic_data
module_wmiquery SELECT LoadPercentage FROM Win32_Processor
module_wmicolumn LoadPercentage
module_end

module_begin
module_name Mem_Free
module_type generic_data
module_wmiquery SELECT LoadPercentage FROM Win32_Memory
module_wmicolumn FreeMemory
module_end

module_begin
module_name Disk_Free
module_type generic_data
module_wmiquery SELECT LoadPercentage FROM Win32_Disk
module_wmicolumn FreeSpace
module_end

Avec cette configuration, nous parvenons à réaliser une configuration à distance et à envoyer les fichiers au serveur de Pandora FMS, malgré les restrictions de communication entre les sièges de l’entreprise.

1.9.1.4 Répartir la charge de surveillance avec des brokers

Le Mode Broker est aussi très utile pour répartir la charge de surveillance entre plusieurs points du réseau.

Broker scalation example.png


Dans cet exemple, notre architecture se compose de plusieurs réseaux avec des noms de A à Z avec 1000 dispositifs chacun. La capacité du Serveur à Distance de Pandora FMS est de l’ordre de 2000 agents. Nous décidons ainsi d’utiliser des agents software en Mode Broker pour répartir la charge de surveillance. Ces agents software en Mode Broker surveillent à distance tous les dispositifs du réseau et envoient les données en format XML au serveur central de Pandora FMS. Dans chacun des réseaux, nous avons un agent avec le Mode Broker activé, dans lequel nous créerons autant de brokers que nous avons de dispositifs à 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. Par exemple, le broker “device_1”, qui est un router, aurait ces modules :

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

Un autre exemple serait le broker device_2 qui surveille une machine Windows avec les modules suivants :

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 CPU_Load
module_type generic_data
module_wmiquery SELECT LoadPercentage FROM Win32_Processor
module_wmicolumn LoadPercentage
module_end

module_begin
module_name Mem_Free
module_type generic_data
module_wmiquery SELECT LoadPercentage FROM Win32_Memory
module_wmicolumn FreeMemory
module_end

module_begin
module_name Disk_Free
module_type generic_data
module_wmiquery SELECT LoadPercentage FROM Win32_Disk
module_wmicolumn FreeSpace
module_end

En utilisant les agents software en Mode Broker, nous pouvons répartir la charge de surveillance et ainsi rassembler aisément les données de milliers de dispositifs.

1.10 Inventaire avec un agent software

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. Nous pouvons trouver plus d’informations dans la section inventaire local avec des agents logiciels.

1.11 Actions à distance par UDP

1.11.1 Comment solliciter une information sur demande à l’agent  ?

L’agent software de Pandora FMS inclut la fonctionnalité “Serveur UDP”, qui permet d’indiquer des actions à un agent à distance, comme se redémarrer ou exécuter une commande.

Les paramètres basiques de configuration du Serveur UDP dans les agents software sont :

  • udp_server: active (1) ou désactive (0) cette fonction.
  • udp_server_port: port d’écoute du serveur UDP dans l’agent software.
  • udp_server_auth_address: adresse IP dans laquelle le serveur UDP accepte des requêtes. Il peut s’établir à 0.0.0.0 pour qu’il les accepte depuis toutes provenances.

Exemples de configuration :

udp_server 1
udp_server_port 41122
udp_server_auth_address 0.0.0.0

A présent, pour forcer la réinitialisation de l’agent, 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 qui vient préconfigurée dans la console "Remote agent control".

Il existe aussi une action d’alerte par défaut appelé Restart agent, qui utilise ce script. Il emploie l’action REFRESH AGENT sur le script udp_client.pl pour relancer l’agent si ce dernier a le serveur UDP en écoute.

Agent restart action.png


Le pas à pas pour permettre l’option de rafraîchissement à distance de l’agent software est :

1. Configurer les options dans le fichier de configuration pour l’agent software (Unix ou Windows). Faites attention à l’adresse IP autorisée (est-ce le serveur de Pandora FMS sous un NAT ?), ou mettez 0.0.0.0. pour permettre que n’importe quelle adresse IP force à rafraîchir l’agent.

2. Relancez l’agent software pour que les changements s’appliquent.

3. Associer l’alerte Restart agent au module de quelque agent (il faut que cet agent ait l’adresse IP correctement configurée).

4. Forcer l’exécution de l’alerte ou bien forcer un état incorrect du module pour que l’alerte se lance.

A présent, grâce à cette action, il est possible de forcer l’alerte manuellement à n’importe quel moment, pour rafraîchir l’agent software à distance et obtenir l’information rapidement.

1.11.2 Actions personnalisées à distance

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 :

Udp process.JPG


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.

Info.png

Des ordres peuvent aussi se créer qui appellent des scripts. Cela permet de réaliser une grande quantité d’actions à distance dans un agent, en appuyant seulement sur un bouton.

 


1.12 Plugins dans des agents software

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.

1.12.1 Exécution dans des systèmes Windows

Sur 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. Voici quelques exemples sur la manière d’utiliser les plugins par défaut, inclus dans l’agent Windows :

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.

1.12.2 Exécutions dans des systèmes Unix

Par défaut, les plugins de Unix se cherchent dans le répertoire "/plugin" du répertoire de l’agent, dans /etc/pandora/plugins. C’est pourquoi il ne serait pas nécessaire de recourir au chemin d’accès lors de son exécution dans le cas où ils se trouvent dans ce répertoire. Voici quelques exemples d’utilisation des plugins :

 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.

1.12.3 Exemples d’utilisation de plugins

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. Avec la ligne suivante, nous exécutons le plugin :

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 :

<module>
    <name><![CDATA[IEXPLORE.EXE]]></name>
    <description><![CDATA[Process IEXPLORE.EXE status]]></description>
    <![CDATA[1]]>
</module>

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"

Le plugin renvoie un module pour chaque disque trouvé. Le résultat serait :

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

1.12.4 Gestion de plugins d’agent depuis la console

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.



Plugin editor tab.png

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.



Plugin editor.png

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



Plugin editor conf.png

1.12.5 Comment créer des plugins d’agents propres

Les plugins peuvent être créés dans n’importe quelle langage de programmation, à condition de respecter ces restrictions :

  • Indépendamment de ce que l’on veut en faire, ils doivent être automatiques (sans interaction de l’utilisateur) et doivent être faits depuis la ligne de commande (interface système). Ils peuvent utilisés tout type de langage de scripting ou langage compilés, mais dans ce cas il faut également répartir, en plus de l’exécutable, toutes les librairies (ou DDL) qui sont nécessaires pour l’exécution du plugin.
  • Le plugin doit renvoyer l’information par la sortie standard (simplement en utilisant echo, printf ou l’équivalent dans le langage qui sera utilisé pour le plugin), et doit utiliser le format XML des agents de Pandora FMS pour renvoyer l’information.

Voici un exemple d’un module de type numérique en XML :

<module>
<name><![CDATA[Sample_Module]]></name>
<type><![CDATA[generic_data]]></type>
<![CDATA[47]]>
<description><![CDATA[47]]></description>
</module>

Les données enfermées dans les tags <![CDATA[xxx]]> s’utilisent pour protéger le XML de certaine information qui peut contenir des caractères “indigestes” pour le XML, comme <,>,& or %.

Avant d’essayer de créer un plugin, visitez la librairie de plugins Pandora FMS sur https://library.pandorafms.com. Si vous décidez ensuite de créer votre propre plugin, soumettez-le à la librairie publique, pour permettre à d’autres personnes de l’utiliser.

Template warning.png

Assurez-vous de terminer la sortie de votre plugin (si c’est un script) avec un errorlevel0, sinon l’agent interprètera que le plugin a eu une erreur et n’a pu s’exécuter.

 


1.12.5.1 Exemple de plugin sur Shellscript (Linux/Unix)

#!/bin/bash
# Detect if local Mysql is without password
# First, do we have a running MySQL?
CHECK_MYSQL=`netstat -an | grep LISTEN | grep ":3306 "`
if [ ! -z "$CHECK_MYSQL" ]
then

        CHECK_MYSQL_ROOT=`echo "select 1234" | mysql -u root 2> /dev/null | grep 1234`
        if [ -z "$CHECK_MYSQL_ROOT" ]
        then
        echo "<module>"
        echo "<type>generic_proc</type>"
        echo "<name>mysql_without_pass</name>"
        echo "<data>1</data>"
        echo "<description>MySQL have a password</description>"
        echo "</module>"
        else
        echo "<module>"
        echo "<type>generic_proc</type>"
        echo "<name>mysql_without_pass</name>"
        echo "<data>0</data>"
        echo "<description>MySQL do not have a password</description>"
        echo "</module>"
        fi
fi

exit 0

1.12.5.2 Exemple de plugin sur VBScript (Windows)

' df.vbs
' Returns free space for avaible drives.
' --------------------------------------

Option Explicit
On Error Resume Next

' Variables
Dim objWMIService, objItem, colItems, argc, argv, i

' Parse command line parameters
argc = Wscript.Arguments.Count
Set argv = CreateObject("Scripting.Dictionary")
For i = 0 To argc - 1
    argv.Add Wscript.Arguments(i), i
Next

' Get drive information
Set objWMIService = GetObject ("winmgmts:\\.\root\cimv2")
Set colItems = objWMIService.ExecQuery ("Select * from Win32_LogicalDisk")

For Each objItem in colItems
	If argc = 0 Or argv.Exists(objItem.Name) Then
		If objItem.FreeSpace <> "" Then
			Wscript.StdOut.WriteLine "<module>"
			Wscript.StdOut.WriteLine "    <name><![CDATA[" & objItem.Name & "]]></name>"
			Wscript.StdOut.WriteLine "    <description><![CDATA[Drive " & objItem.Name & " free space in MB]]></description>"
			Wscript.StdOut.WriteLine "    <data><![CDATA[" & Int(objItem.FreeSpace /1048576) & "]]></data>"
			Wscript.StdOut.WriteLine "</module>"
            Wscript.StdOut.flush
		End If
	End If
Next

1.12.6 En utilisant des plugins de Nagios à partir de l’agent

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 sur [1]).

Que fait le wrapper de plugins pour les plugins de Nagios ?

Il 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 et semblable à "OK: successfully logged in".

1.12.6.1 Exemple

Si vous avez un plugin pop3 (en /tmp/check_pop3_login) avec les droits d’exécution, (ce qui vérifie si le compte pop3 ne fonctionne qu’en se connectant avec un host à distance, en envoyant un utilisateur et un mot de passe et en visualisant que tout soit correct). Alors vous pouvez l’exécuter depuis la ligne de commandes :

/tmp/check_pop3_login  mail.artica.es [email protected] mypass

Il renverra un message semblable à :

OK: successfully logged in.

Dans le cas contraire, il vous renverra un message tel que celui-ci :

Critical: unable to log on

Utiliser le wrapper est facile. Il faut seulement mettre le wrapper et le nom que vous souhaitez au module avant d’exécuter l’appel :

/etc/pandora/plugins/nagios_plugin_wrapper sancho_test /tmp/check_pop3_login  mail.artica.es [email protected] mypass

Ceci générera un XML complet pour le plugin d’agent.

<module>
<name>sancho_test</name>
<type>generic_proc</type>
0
<description><![CDATA[Critical: unable to log on]]></description>
</module>

Ou :

<module>
<name>sancho_test</name>
<type>generic_proc</type>
1
<description><![CDATA[OK: successfully logged in.]]></description>
</module>

L’entrée complète dans le pandora_agent.conf sera semblable à :

module_plugin nagios_plugin_wrapper POP3_artica.es /tmp/check_pop3_login mail.artica.es [email protected] mypass

Ceci se verra de cette même manière dans le module (dans le fail event) :


Sample plugin wrapper.png

1.13 Surveillance avec KeepAlive

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. Il est utilisé aussi pour savoir quand un agent a cessé d’envoyer une information et nous en avertit.

Quand un module, qu’il soit à distance ou local, obtient une information de l’agent, la date du dernier “contact” avec l’agent se met à jour, de façon à ce qu’il y ait toujours des données. Même si ce n’est qu’un module du total, l’agent verra la date de dernier contact mis à jour, qui permet de savoir si l’agent “ne répond pas”. Concrètement, un agent est considéré comme “mort” quand il n’a pas actualisé sa date pendant le double du temps de son intervalle, c’est-à-dire que s’il a un intervalle de 5 minutes et que cela fait plus de 10 minutes qu’il n’y a aucune mise à jour, l’agent est considéré comme mort. C’est dans ce cas que le module keepalive entrerait en jeu, en se lançant et en marquant le moniteur en état Critical.

La configuration de ce type de modules est très simple, il suffit de créer un nouveau module de type "KeepAlive":

Keepalive.JPG


Une fois créé, si l’agent a des données, au cours de son intervalle, il restera en état “NORMAL” (vert) :

Keepalive1.png


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

Keepalive2.png


Il convient de souligner que si nous avons un module à distance, par exemple un Ping, en plus des données reportées par l’agent, le module keepalive ne changera jamais d’état, puisque nous mettons sans cesse à jour l’agent au moyen de Ping.

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.

Info.png

Le module ne peut se créer que depuis la console (même si nous avons la configuration à distance activée) et ne laisse aucune trace dans le fichier pandora_agent.conf

 


1.14 Surveillance de captures de commandes (Command snapshots)

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 capture d’écran suivante, le résultat d’un des modules est présenté, et dans ce cas-ci, la sortie de netstat -an:


Snapshot 1.png


Template warning.png

Pour que cela fonctionne ainsi, il faut configurer correctement, aussi bien la console Pandora (setup) que l’agent qui collecte cette information, en s’assurant que ce soit un texte sans modification.

 


Pour configurer correctement la console, il faut s’assurer que dans la section principale du setup, nous avons la propriété “Comand line snapshot” activée :

Command line snapshot setup.png

1.15 Surveillance et visualisation des images

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.

Voici comment se présente la sortie d’une chaîne de caractères avec le contenu "data:image" (imagen sur base64), capturé par Pandora FMS, en cliquant sur l’icône spécial pour les captures d’images :


Snapshot text 1.png


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. Voyons le plugin d’exemple suivant, qui génère la sortie d’une image, comme dans la capture précédente :

#!/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>

1.16 Groupes protégés par mot de passe

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.

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

Passgr1.JPG

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

 group_password <password>

N’oubliez pas de redémarrer l’agent pour rendre les changements effectifs. L’agent devrait alors se créer correctement dans la console de Pandora FMS.

Revenir à l’Index de Documentation Pandora FMS