Pandora: Documentation fr: Supervision distance

From Pandora FMS Wiki
Jump to: navigation, search

Revenir à l’Index de Documentacion Pandora FMS

1 Surveillance à distance

1.1 Introduction

Le serveur de réseau de Pandora FMS est un élément clé puisqu’il permet d’exécuter des tests à distance et centralisés. Contrairement au serveur de données, le serveur réseau exécute les tâches qui lui sont assignées au moyen de files multi-thread. De plus, un serveur réseau peut travailler avec d’autres serveurs réseaux en équilibrant le chargement et en agissant comme soutien si d’autres serveurs cesse d’exécuter, en effectuant les tâches du serveur défaillant. Pour en savoir plus, vous pouvez consulter le chapitre correspondant.

Le serveur réseau ne travaille qu’avec ces modules réseaux qui lui sont assignés. Bien évidemment, s’il s’agit de test réseau, le serveur réseau doit avoir une visibilité complète (adresses IP et ports) sur les éléments sur lesquels il va réaliser les tests. Cela n’a aucun sens d’en réaliser sur un système dont les ports ne peuvent se voir ou les chemins d’accès. L’existence de pare-feu ou de chemin d’accès réseau n’a rien à voir avec Pandora FMS et les problèmes générés pour ces raisons n’ont rien à voir non plus avec une configuration de Pandora FMS.

En plus du network server (serveur réseau), il existe bien d’autres sous-genres de serveurs de Pandora FMS qui exécutent des tests à distance. Dans ce chapitre, nous verrons les serveurs réseau, les serveurs de plugin à distances et les serveurs qui lancent des tests à distance sur des machines Windows (WMI Server). D’autres serveurs qui réalisent également des tests à distance, comme le serveur de tests WEB (WEB Server ou Goliat server), ont leurs chapitres particuliers.

Remote-monitoring.jpg

1.2 Surveillance de base du réseau

Les modules réseaux de base de Pandora FMS exécutent des tâches de surveillance à distance. Les tâches d’exécution peuvent se résumer en trois blocs.

Tests ICMP

Ce sont des tests de base du réseau qui permettent de savoir si un host est accessible et opérationnel et le temps qu’il faut pour arriver à ce dispositif par le réseau.

Tests TCP

À distance, il est possible de vérifier qu’un système a bien son port TCP d’ouvert, qui est précisé dans la définition du module. De plus, il est possible d’envoyer une chaîne de texte et d’attendre de recevoir une réponse pour vérifier que la communication est correcte. Ceci permet d’implémenter des vérifications simples du protocole, en plus de vérifier si l’autre extrémité répond ou non.

Par exemple, nous pourrions vérifier si un serveur HTTP est opérationnel en envoyant la chaîne «GET / HTTP/1.0» dans l’attente de recevoir la chaîne «200 OK».

Tests SNMP

À distance, il est possible de lancer des requêtes SNMP (SNMP Polling) vers des systèmes qui ont leur service SNMP d’activé et accessible pour obtenir des données comme l’état des interfaces, la consommation de réseau par interface, etc. Il existe une section dédiée à SNMP avec Pandora FMS (voir plus bas dans le document).

Pandora 1.3 Network&DataServer Arch.png

En résumé, on peut conclure que le serveur réseau est celui qui exécute les différents tests attribués à chaque agent. Chacun est assigné à un serveur réseau et c’est ce dernier qui se charge de son exécution, en insérant les résultats dans la base de données du système de Pandora FMS.

1.2.1 Configuration générique d’un module pour la surveillance réseau

Pour surveiller un équipement ou un service d’équipement (FTP, SSH, etc.) à distance, il faudra tout d’abord créer l’agent correspondant pour surveiller le service. Pour cela, il faudra commencer de la façon suivante :

Info.png

Quand il s’agit de créer un agent, cela ne signifie pas d’installer un agent software dans la machine destinée à le recevoir mais de créer un agent dans l’interface de Pandora FMS

 


Dans la section d’administration de la console de Pandora FMS, cliquez sur Resources > Manage agents:

CapturaMR1.JPG

Sur l’écran suivant, appuyez sur le bouton Create agent :

Bibi.jpg

Remplissez les données de votre nouvel agent et appuyez sur le boutonCreate :

Raro.jpg

Une fois l’agent créé, appuyez sur le volet au-dessus des modules (Modules). Sélectionnez créer un nouveau module réseau et appuyez sur le bouton Create :

Sasa.jpg

Sur le formulaire suivant, sélectionnez un module de composant réseau. Lorsque le menu déployable à droite sera chargé, cherchez la vérification test qui vous intéresse. Dans cet exemple, Host Alive sera choisi, qui représente un ping pour la machine, une simple vérification pour savoir si la machine est connectée à Internet ou non.

Alive.jpg

Nous laissons les options avancées de côté pour le moment. Notez que le module a reçu l’adresse IP de l’agent. Si vous le souhaitez, elle peut être différente. Une fois que vous avez fini de définir le module, appuyez sur Create.

Sur l’écran suivant, les modules pour l’agent seront affichés : le pré-déterminé Keepalive qui se crée avec l’agent et le module ajouté Host Alive :

Kiji.jpg

Comme on peut le remarquer, un avertissement sur les modules apparaît. Cela signifie qu’aucune donnée n’a été reçue sur le module et qu’ils viennent d’être ajoutés. Une fois que les données commenceront à être reçues, l’avertissement disparaîtra.

Pour voir les données du module récemment créé, appuyez sur le volet View et allez en bas de la partie, où seront affichées les données une fois qu’elles commenceront à être reçues.

Keso.jpg

Pour ajouter d’autres types de vérifications réseau, faites comme précédemment mais en sélectionnant cette fois d’autres types de modules.

1.2.2 Surveillance ICMP

L’exemple précédent est un exemple de surveillance ICMP. Ce sont les vérifications les plus basiques et simples qui nous fournissent des informations importantes et exactes. Il existe deux types de vérifications ICMP :

  • icmp_proc, ou vérification d’host (ping), qui permet de savoir si une adresse IP répond ou non.
  • icmp_data ou vérification de latence. Il nous informe du temps en millisecondes qu’il faut pour l’adresse IP afin de répondre à une consultation de base de ICMP.

1.2.3 Surveillance TCP

Les tests TCP permettent de vérifier l’état d’un port ou d’un service TCP.

Les champs fondamentaux de ce type de modules sont les port de destination, l’adresse et l’envoi et réception de données (TCP Send y TCP Receive).

Les vérifications TCP par défaut ne montrent que si le port de destination est ouvert ou non. De façon facultative, vous pouvez lui envoyer une chaîne de caractères et attendre de recevoir quelque chose, qui sera directement traité par Pandora FMS comme donnée, grâce aux champs TCP Send et TCP Receive.

Une chaîne de caractère peut être envoyée (en utilisant la chaîne «^M» pour remplacer le retour de chariot) et une sous-chaîne de réponse peut être attendue pour vérifier que la communication est correcte. Ceci permet d’implémenter des vérifications simples du protocole. Par exemple, nous pourrions vérifier si un serveur est opérationnel en envoyant la chaîne.

 GET / HTTP/1.0^M^M 

Dans l’attente de recevoir la chaîne :

200 OK

Ceci se codifie dans les champs TCP Send et TCP receive.

TCP send

Un champ pour configurer les paramètres à envoyer au port TCP. Il admet la chaîne ^M pour la remplacer par l’envoi d’un retour de charriot. Pour envoyer différentes chaînes en séquence envoi/réponse, il faut les séparer avec le caractère |

TCP receive

Champ pour configurer les chaînes de texte qui attendent de recevoir la connexion TCP. S’ils s’envoient/reçoivent en différentes étapes, chacune se séparent par ce caractère |

Grâce aux vérifications TCP de Pandora FMS, il est possible de voir plus qu’un simple port ouvert ou d’attendre une réponse face à une requête simple. Il est possible d’envoyer des données, d’attendre de recevoir quelque chose et ce jusqu’à l’étape que nous souhaitons. Seulement si le processus est correct, nous pouvons valider le résultat.

Pour utiliser le système de vérifications dialogue/réponse de Pandora FMS, vous pouvez séparer les différentes requêtes avec le caractère |

Voyons un exemple d’une conversation SNMP :

R: 220 mail.supersmtp.com Blah blah blah
S: HELO myhostname.com
R: 250 myhostname.com
S: MAIL FROM: 
R: 250 OK
S: RCPT TO: 
R: 250 OK
S: DATA
R: 354 Start mail input; end with .
S: .......your mail here........
S: .
R: 250 OK
S: QUIT
R: 221 mail.supersmtp.com Service closing blah blah blah

Si vous souhaitez tester les premiers points du protocole, les champs nécessaires pour reproduire cette conversation seraient :

TCP Send

HELO myhostname.com^M|MAIL FROM: ^M| RCPT TO: ^M

TCP Receive

250|250|250

Si les trois premières étapes sont OK (code 250), alors le serveur SMTP est ok. Il n’est pas nécessaire d’envoyer un mail complet (bien que cela serait possible). Cela permet de réaliser des vérifications TCP basées sur le protocole, qui peuvent s’utiliser pour n’importe quel protocole qui utilise des conversations en texte brut.

1.2.4 Surveillance SNMP

1.2.4.1 Introduction à la surveillance SNMP

Lorsqu’il s’agit de surveillance SNMP, le plus important au début est de séparer les concepts de polling et les traps. Le test ou polling SNMP implique d’ordonner à Pandora FMS d’exécuter une commande «get» sur un dispositif SNMP, comme un router ou un switch. Ceci est une opération “synchrone” (qui se réalise activement tous les certains temps). Au contraire, recevoir un trap SNMP est une opération asynchrone (basée sur des changement ou des événements qui peuvent ne pas se produire). Elle est souvent utilisée pour recevoir des avertissements provenants du dispositif, comme par exemple, lorsqu’un switch fait tomber un port ou que son ventilateur surchauffe.

Les tests SNMP type polling se réalisent en créant des modules réseau sur Pandora FMS de façon habituelle.

Utiliser les Traps SNMP est complètement différent. On peut recevoir des traps de n’importe quel dispositif. Il faudra juste activer la console de traps SNMP dans Pandora FMS sur laquelle les traps seront reçus depuis n’importe quel dispositif. Des alertes peuvent être définies grâce aux règles de filtrage de traps pour tout champ.

Pandora FMS travaille avec SNMP en gérant des OIDs individuels. Pour Pandora FMS, chaque OID est un module réseau. C’est-à-dire que si nous souhaitons surveiller un switch Cisco Catalyst de 24 ports et connaître l’état opérationnel de chaque port tel que le trafic d’entrée et de sortie, nous devons définir un total de 72 modules (24x3).

Pour travailler avec des dispositifs SNMP, il faut :

  • Savoir ce qu’est le protocole SNMP et comment il fonctionne. Ceci est davantage approfondi dans le RFC3411 publié par IETF.
  • Connaître l’IP et la communauté SNMP du dispositif à distance.
  • Activer la gestion SNMP du dipositif pour qu’à partir du serveur réseau, il soit possible de faire des consultations SNMP. Ce serveur réseau doit être celui assigné par l’agent sur lequel nous allons définir les modules réseau. Il faut également prendre en compte que si nous souhaitons que d’autres serveurs réseau fassent des consultations en cas d’interruption du serveur assigné, ils feront les consultations avec une autre adresse IP.
  • Connaître l’OID du dispositif à distance que nous souhaitons consulter (ou utiliser l’un des divers “wizards” dont dispose Pandora FMS ou son explorateur de OIDs SNMP).
  • Savoir comment gérer les données que renvoie le dispositif. Les SNMP renvoient des données dans différents formats. Pandora FMS peut presque tous les traités. Celles de type compteur sont celles que Pandora FMS gère comme remote_snmp_inc et sont d’une importance capitale puisqu’en étant compteurs, elles ne peuvent être traitées comme données numériques mais comment taux d’éléments par seconde. La majorité des données statistiques SNMP sont de type compteur et doivent être configurées comme remote_snmp_inc si vous souhaitez les surveiller correctement.

1.2.4.2 Surveillance avec modules réseau type SNMP

Pour pouvoir surveiller n’importe quel élément par SNMP, nous devrons au moins savoir votre IP et votre communauté SNMP. Il serait aussi intéressant de savoir l’OID à surveiller, même s’il est possible de l’obtenir au moyen d’un SNMP Walk ou de l’exploratuer SNMP intégré dans Pandora FMS, du moment que l’on sait à quoi appartient chaque OID, ce qui n’est pas toujours évident.

Pour surveiller un élément par SNMP, il faudra d’abord créer un agent. Si vous en disposez déjà d’un, un nouveau module réseau lui sera alors ajouté en suivant les indications précédentes.

Une fois le module créé, il faut sélectionner un type de données SNMP dans le formulaire de configuration du module. Voir ci-dessous :

Cap5 snmp 1.png

N’importe quel type des données SNMP parmi les trois sont valides. Sélectionnez celui qui coïncide avec le type de données que vous souhaitez surveiller.

Une fois le type de données SNMP choisi, le formulaire montrant les champs supplémentaires pour SNMP s’étendra :

Cap5 snmp 2.png


Les champs seront détaillés ci-dessous :

SNMP community

Communauté SNMP. Nécessaire pour pouvoir surveiller l’élément. Agit comme un mot de passe.

SNMP version

Version du protocole SNMP du dispositif. Ce peut être 1, 2, 2c et 3. La dernière incorpore chiffrage et authentification de sécurité dans la communication ce qui complique la configuration et empire la perfomance du “polling” des serveurs réseau de Pandora FMS.

SNMP OID

Identificateur OID à surveiller. Il consiste en une chaîne de numéros et de points. Ces chaînes sont automatiquement traduites par des chaînes alphanumériques plus descriptives si les MIB correspondants se trouvent installés dans le système. Les MIB sont des bibliothèques des fabricants qui permettent de traduire ces OIDS dans des chaînes plus descriptives.

Un OID alphanumérique peut prendre divers aspects :

   iso.org.dod.internet.private.transition.products.chassis.card.slotCps.cpsSlotSummary.cpsModuleTable.cpsModuleEntry.cpsModuleModel.3562.3

L’équivalent numérique serait :

1.3.6.1.4.868.2.4.1.2.1.1.1.3.3562.3

Pandora FMS inclut quelques OID dans sa base de données, qui peut être utilisée directement. Par exemple, au moment de créer le module, sélectionnez le composant Cisco MIBs pour montrer une liste de tests avec des OID traduits et disponibles pour Cisco :

Cap5 snmp 4.png

Une fois ce composant sélectionné, vous pouvez choisir parmi les OID disponible :

Cap5 snmp 5.png

En le faisant, les champs avec les informations nécessaires se rempliront.

Il existe plus de MIB inclus dans Pandora FMS et avec la version Enterprise, des paquets MIB sont inclus pour différents dispositifs.

Une fois les données insérées, appuyez sur Create.

Pour voir les données du module récemment créé, appuyez sur le volet du dessus, View, et allez en bas de la partie, sur laquelle seront affichées les données une fois qu’elles commenceront à être reçues. Avec ces dernières, on pourra observer un graphique SNMP en temps réel.

SNMP nueva.png


1.2.4.3 Surveiller SNMP à partir des agents

Les agents software Windows servent à obtenir les informations SNMP. Elles sont généralement disponibles dans les agents Unix/Linux snmpget et peuvent être appelées depuis la ligne module_exec.

Nous avons inclu dans l’agent “par défaut de Windows l’utilitaire snmpget.exe (une partie du projet net-snmp, avec licence BSD) et nous avons ajouté les MBI de base et un wrapper pour encapsuler l’appel à l’utilitaire snmpget.exe.

En utilisant cet appel, nous pouvons surveiller le SNMP depuis un agent, en obtenant des informations depuis tout équipement à distance auquel l’agent a accès, en fonctionnant comme un “agent satellite” ou “agent proxy” (selon documentation).

Sous Windows, la syntaxe de l’exécution est :

module_exec getsnmp.bat <communauté_SNMP> <IP de destination> <OID>

Quelques exemples de modules SNMP exécutés par des agents Windows :

module_begin
module_name SNMP_if3_in
module_type generic_data_inc
module_exec getsnmp.bat public 192.168.55.1 .1.3.6.1.2.1.2.2.1.10.3
module_end
module_begin
module_name SNMP_if3_desc
module_type generic_data_string
module_exec getsnmp.bat public 192.168.55.1 IF-MIB::ifDescr.3
module_end
module_begin
module_name SNMP_Sysup
module_type generic_data
module_exec getsnmp.bat public 192.168.55.1 DISMAN-EVENT-MIB::sysUpTimeInstance
module_end

Les mêmes exemples exécutés à partir des agents Unix :

module_begin
module_name SNMP_if3_in
module_type generic_data_inc
module_exec snmpget -v 1 -c public 192.168.55.1 .1.3.6.1.2.1.2.2.1.10.3
module_end
module_begin
module_name SNMP_Sysup
module_type generic_data
module_exec snmpget -v 1 -c public 192.168.55.1 DISMAN-EVENT-MIB::sysUpTimeInstance
module_end

Il convient de noter que seuls les OIDs de bases sont transcriptibles par leur équivelant numérique et qu’il est recommandé de toujours utiliser des OIDs numériques puisqu’on ignore si l’outil sera capable de traduire ou non. Dans tous les cas, les MIBs sont toujours enregistrés dans le répertoire /util/mibs sur Windows o /usr/share/snmp/mibs sur Linux.

1.2.5 Navigateur SNMP de Pandora FMS

Nous pouvons accéder à l’explorateur SNMP via le menu Monitoring > SNMP > SNMP Browser.

Ce qu’il faut tout d’abord comprendre, c’est que Pandora FMS fait une collecte entière de l’arbre du dispositif. C’est pourquoi, si ce dernier est grand (comme un switch), cette opération peut prendre plusieurs minutes. Nous pouvons aussi choisir d’explorer seulement une sous-branche, ce qui nous fera gagner du temps.

Par exemple, pour n’obtenir que des informations de Cisco, vous pourriez explorer votre sous_mib enterprise de Cisco, qui commence par :

 .1.3.6.1.4.1.9

L’explorateur s’utilise pour “naviguer”, c’est-à-dire déployer les branches et en obtenant les valeurs, appuyer sur l’icône de l’oeil. Le système demandera cette information au système et montrera, par ailleurs, les informations de l’OID sollicité. S’il n’en existe aucune sur l’OID du dispositif, elle ne s’affichera qu’en format numérique. L’information descriptive des OIDs se conservent via les MIBs [1]. Si vous ne disposez pas de MIB pour le dispositif que vous souhaitez explorer, vous devrez sûrement aller chercher “des morceaux d’informations” dans les informations visualisées par Pandora FMS, ce qui est complexe et long.

L’explorateur SNMP de Pandora FMS permet de chercher une chaîne de texte aussi bien dans les valeurs d’OIDs obtenues que dans celles traduites des OID’s eux-mêmes (si disponibles). Ceci est particulièrement utile pour chercher des chaînes connues et localiser votre OID. Si vous localisez plusieurs entrées, cela nous permettra d’aller d’une occurrence à une autre et de les afficher surlignées en jaune.

Snmp browser module creator.png

À partir de l’explorateur SNMP, il est possible de créer un composant de réseau pour l’utiliser ensuite.

Snmp browser from module creation.jpg

À partir de l’éditeur de modules SNMP, lorsque nous créerons ou éditerons un module réseau, nous pourrons lancer le navigateur SNMP en cliquant sur le bouton “Navigateur SNMP”, qui sera ouvert dans une fenêtre flottante. Une fois que l’OID souhaité est choisi, en cliquant sur l’icône de la main avec le doigt pointant vers le bas, nous choisirons cet OID et nous le passerons au champ correspondant à la définition du module, automatiquement, pour l’utiliser avec Pandora FMS.

1.2.6 Gestionnaire de MIBS

Grâce à Pandora FMS, nous pouvons mettre et gérer les MIBs pour en intégrer de nouvelles ou effacer celles qui ne nous intéressent pas. Ces MIBs ne seront utilisées que par Pandora FMS, qui utilisera aussi celles du système d’exploitation (dans /usr/share/snmp/mibs). Pandora FMS utlisera le chemin {PANDORA_CONSOLE}/attachment/mibs pour conserver les MIBs.

CapturaMR2.JPG

Il est important de noter que le gestionnaire de MIBs de Pandora FMS ne gère que les MIBs de “polling” et n’a rien à voir avec celles des traps SNMP. Pour cette fonctionnalité, il existe d’autres gestionnaires, seulement en version Enterprise de Pandora FMS.

1.2.7 Wizard SNMP de Pandora FMS

Dans la vue administration d’un agent, il existe un ensemble d’outils pour créer des modules en nombre conséquent : les wizard d’agent.

Agent wizard.png

1.2.7.1 Wizard SNMP

Agent wizard snmp wizard.png

Vous devrez définir l’IP de destination, la communauté et d’autres paramètres (SNMP v3 est supporté) pour faire un “Walk” à la machine.

Snmp wizard form.png

Une fois l’information reçue, un formulaire apparaîtra pour la création de modules :

Snmp wizard module creator.png

Avec le Wizard SNMP, il est possible de créer des modules de divers types de données SNMP :

  • Dispositifs
  • Processus
  • Espace libre sur disque
  • Capteurs de température
  • Autres données SNMP

Sélectionnez le type de modules et passez les éléments que vous souhaitez du menu de gauche à celui de droite. Une fois terminé, cliquez sur Créer modules.

Ce wizard créera deux types de modules :

  • Modules SNMP pour les consultations avec OID statique (Capteurs, Mémoire, CPU, etc.)
  • Modules Plugin pour les consultations avec OID dynamique ou les données calculées (Processus, Espace sur le disque, Mémoire utilisée exprimée en pourcentage, etc).


Template warning.png

Pour les modules de type plugin, nous utiliserons le plugin de SNMP. C’est pourquoi, si le plugin n’est pas installé dans le système, ces caractéristiques resteront désactivées. Le plugin devra avoir le nom "snmp_remote.pl". La localisation où il de sa conservation importera peu.

 


1.2.7.2 SNMP Interfaces wizard

Agent wizard snmp interfaces wizard.png

Dans le Wizard de l’agent, il existe un Wizard SNMP créé spécialement pour la navigation de Interface. Ce Wizard navigue par la branche de SNMP IF-MIB::interfaces, en offrant la possibilité de créer de multiples modules de différentes interfaces avec la sélection multiple.

Comme pour le Wizard SNMP, après avoir sélectionné l’IP de destination, de communauté, etc,. le système fera une consultation SNMP sur la machine de destination et remplira le formulaire pour la création de modules.

En l’utilisant, vous pourrez sélectionner une ou plusieurs interfaces du menu de gauche. Ensuite, dans celui de droite, les éléments communs à ce dernier apparaîtront (Description, Vitesse, Trafic entrant/sortant…). Vous pourrez sélectionner un ou plusieurs éléments du menu et cliquer sur Créer modules pour pour créer ceux sélectionnés pour chaque interface choisie dans le menu de gauche.

Agent wizard snmp interfaces creation.png

1.2.8 Propriétés avancées communes des modules réseau

L’écran suivant montre les propriétés avancées pour la configuration des modules réseau :

Cap5 snmp 8.png

Description

Description du module. Il existe déjà une description pré-établie qui peut être modifiée.

Custom ID

Identificateur personnalisé nécessaire si vous souhaitez que le serveur envoie des messages multicast avec des informations sur les agents ou bien utiliser ce champs pour intégrer les données de Pandora FMS dans un système externe d’information, comme une CMDB.

Interval

Intervalle ou exécution du module. Il peut être différent à l’agent, comme dans l’exemple.

Les valeurs montrées dépendent de celles configurées dans la section "Configuration> Styles visuels", dans la catégorie "Valeurs de l’intervalle".

Tandis que pour un utilisateur Administrateur, il aura la possibilité de définir un intervalle personnalisé au moment de créer ou modifier un module, les usagers standards pourront définir seulement des intervalles au préalable, montrant les valeurs par défaut en cas de non définition des “Styles visuels”.

Post process

Post processus du modèle. Il sert pour multiplier ou diviser la valeur renvoyée, comme par exemple lorsqu’ils obtiennent des bytes et qu’il faut montrer la valeur en Megabytes.

Min. Value

Valeur minimale du module. Toute valeur inférieure sera considérée comme invalide et sera ignorée.

Max. Value

Valeur maximale du module. Toute valeur au-dessus se considérée comme invalide et sera ignorée.

Export target

Sert pour exporter les valeurs renvoyées par le module vers un serveur d’exportation. Cela n’est disponible qu’en version Enterprise de Pandora FMS et si un serveur d’exportation a été configurée. Vous pouvez consulter la section en référence au serveur d’exportation pour obtenir plus de détails.

Module advanced.png

Cron

Si Cron from est activé, le module s’exécutera lorsque la date et l’heure coïncideront avec la date et l’heure configurées dans “Cron from”, en ignorant l’intervalle du module. Par exemple, la configuration suivante ferait que le module s’exécute chaque lundi à 6h30.

Cron from ex1.png

Si Cron from ainsi que Cron to sont activés, le module s’exécutera une fois que la date et l’heure actuelles seront comprises entre la date et l’heure configurées dans “Cron from”, et la date et l’heure configurées dans “Cron to”, ignorant le l’intervalle même du module. Par exemple, la configuration suivante permettrait qu’un module s’exécute tous les jours entre 6 et 7 heures :

Cron from ex2.png

Pour les modules locaux, la ligne module_crontab est ajoutée au fichier correspondant de configuration de l’agent.

Timeout

Temps d’attente de l’agent pour l’exécution du module, en secondes.

Category

Cette catégorisation n’a pas d’effet depuis l’interface de l’utilisateur normal. Elle est pensée pour être utilisée avec la Métaconsole.

1.3 Surveillance de Windows à distance avec WMI

WMI est un système de Microsoft pour obtenir des informations des équipements à distance, fonctionnant avec S.O. Windows. Il est disponible depuis la version Windows XP jusqu’aux versions actuelles. WMI permet d’obtenir tous types d’informations du S.O., les applications et même le hardware. Les consultations de WMI peuvent être réalisées localement (de ce fait, l’agent de Pandora FMS le fait en interne, en appelant l’API du système d’exploitation et en demandant au sous-système WMI) ou à distance. Dans quelques systèmes, l’accès à distance au WMI n’est pas activé et il faut l’activer pour le consulter depuis l’extérieur.

Pandora FMS permet la surveillance à distance des équipements Windows grâce aux consultations WMI. Pour cela, il faudra activer le composant wmiserver dans le fichier de configuration du serveur de Pandora FMS.

 # wmiserver : 1 or 0. Set to 1 to activate WMI server with this setup
 # DISABLED BY DEFAULT
   wmiserver 1

Les consultations se font sur WQL, une sorte de langage SQL spécifique de Microsoft pour des consultations internes au système d’exploitation. Toute consultation peut être réalisée si elle paraît dans la base de données du système WMI.

Pour commencer à surveiller par WMI, il faudra tout d’abord commencer par créer l’agent correspondant et une fois prêt, appuyez sur le volet au dessus des modules (Modules). Sélectionnez créer un nouveau module WMI et appuyez sur Create :

Feo.jpg

Quelques champs sont spécifiques à WMI et requièrent une petite explication :

Namespace

Espace des noms WMI. Dans quelques consultations, ce champ est différent de chaîne vide (par défaut), selon le fournisseur d’informations de l’application que est surveillée.

Username

Nom de l’utilisateur administrateur ou d’un autre utilistateur qui a des droits d’exécutions des consultations WMI à distance.

Password

Mot de passe pour l’utilisateur administrateur ou l’utilisateur fourni.

WMI Query

Consultation WMI, similaire à une déclaration en SQL. Voici quelques exemples :

SELECT LoadPercentage from Win32_Processor WHERE DeviceID = "CPU0"
SELECT SerialNumber FROM Win32_OperatingSystem
SELECT AvailableBytes from Win32_PerfRawData_PerfOS_Memory
SELECT DiskWriteBytesPersec from Win32_PerfRawData_PerfDisk_PhysicalDisk WHERE name = "_Total"

Key string

Facultatif, champ pour comparer la chaîne renvoyée par la requête et si le module existe, il renvoie 1 ou 0, au lieu de la chaîne elle-même.

Field number

Le nombre de champ renvoyé en commençant de 0 (les requêtes WMI peuvent renvoyer plus d’un champ). Dans la majorité des cas, c’est soit 0 soit 1.

Campos.jpg

Si vous ignorez les paramètres exacts, vous pouvez sélectionner l’un des pré-définis inclus dans la base de données de Pandora FMS. Pour cela, sélectionnez le composant du module WMI :

Galleta.jpg

Sélectionnez ensuite une vérification WMI parmi celles possibles :

Galletita.jpg

L’information nécessaire se remplit automatiquement, sauf l’utilisateur et le mot de passe. Notez qu’il faut indiquer un utilisateur avec des droits d’administration et votre mot de passe. Sinon, le module ne pourra renvoyer aucune valeur :

Otro.jpg

La version Enterprise de Pandora FMS dispose de plus de 400 modules de surveillance à distance WMI pour Windows, couvrant les technologies :

  • Active Directory
  • BIOS
  • Information du système
  • Information de Windows
  • Imprimante
  • MSTDC
  • IIS
  • LDAP
  • Microsoft Exchange

1.4 Wizard WMI

Dans le Wizard de l’agent (onglet dans la vue d’administration d’un agent), il existe un Wizard WMI, utilisé pour naviguer et créer des modules avec des requêtes WMI pour un agent en particulier.

Agent wizard wmi wizard.png

Il faudra spécifier l’utilisateur et le mot de passe de l’administrateur (ou d’un utilisateur avec des droits pour réaliser des requêtes WMI) dans le serveur de destination pour faire les premières requêtes WMI. Ces informations seront utilisées pour la création de modules.

Wmi wizard module creator.png

Avec le Wizard WMI, il est possible de créer des modules de différents types d’informations WMI :

  • Service : des moniteurs booléens seront créés en état normal si le service est exécuté et est critique lorsqu’il se trouvera arrêté.
  • Processus : les moniteurs de processus recevront des informations uniquement lorsque le processus est activé. Sinon, il sera en état inconnu.
  • Espace libre sur le disque
  • Composants WMI : dans ce cas, vous choisirez entre les composants WMI enregistrés dans le système (Administration -> Gérer les modules -> Composants réseau).

1.5 Surveillance avec plugins de serveur à distance

Ce genre de surveillance consiste à exécuter des plugins à distance depuis le serveur de Pandora FMS sur d’autres systèmes. Les installations apportent, par défaut, plusieurs plugins de serveurs prêt à l’emploi et l’utilisateur peut toujours ajouter ceux dont il a besoin.

Un plugin à distance est un script ou exécutable qui admet des paramètres et renvoie une valeur. Via un plugin, vous pouvez implémenter vous même tout type d’opération, et grâce à des paramètres d’entrées, vous pourrez personnaliser comment vous souhaitez que se comporte l’application que vous avez développée. Cela vous permettra, par exemple, de passer l’adresse IP de destination du test en tant que paramètre. LE résultat pourrait être un numéro, une valeur booléenne (0 error, >0 OK) ou une chaîne de caractères. La seule limite qu’ont les plugins à distance est qu’ils ne peuvent renvoyer qu’une seule valeur.

Pour enregistrer un plugin sur Pandora FMS, nous irons dans la section administration de la console et nous cliquerons sur Manage servers, puis “Manage plugins” :

Verdecito1.jpg

Verdecito2.jpg

À partir de cet écran, vous pourrez voir vous avez déjà quelques plugins d’enregistrés. Vous pouvez également y enregistrer votre plugin manuellement. Pour expliquer son fonctionnement, nous verrons un plugin déjà enregistré. Faites un clic sur celui qui se nomme “UDP Plugin”, qui permet de faire un test de connectivité UDP sur une machine à distance.

Plugin create 1.jpg

Plugin type

Il existe deux types de plugins : standard (standard) et ceux de type NAgios. Les compléments standards sont des scripts qui exécutent des actions et admettent des paramètres. Les compléments de NAgios sont, comme leur nom l’indique, compléments de Nagios qui peuvent être utilisés avec Pandora FMS. La différence réside principalement sur le renvoi d’un error level des plugins de Nagios, pour indiquer si le test a été un succès ou non et une chaîne descriptive supplémentaire. Cette description n’est pas une valeur numérique qui peut être utilisée comme valeur d’un module. Ainsi, dans ce cas, nous l’utiliserons pour mettre à jour la description d’un module.

Dans ce cas, (pour le plugin d’exemple, UDP port check) nous sélectionnerons Standard, puisqu’il ne s’agit pas d’un plugin de Nagios.

Max. timeout

C’est le temps d’expiration du complément. S’il ne reçoit pas de réponse pendant ce temps, son exécution s’arrêtera. Ceci est un élément très important au moment d’implémenter la surveillance avec plugins, puisque si le temps passait à exécuter le plugin est supérieur à ce nombre, nous ne pourrons jamais obtenir de valeur avec lui (il ne se lancera même pas). Cette valeur doit toujours être supérieure au temps que le script/exécutable, utilisé comme plugin, passe normalement pour renvoyer une valeur. Si rien n’est indiqué, la valeur indiquée dans la configuration comme “plugin_timeout” sera utilisée.

Info.png

Lors de l’exécution d’un plugin, il existe trois timeouts : celui serveur, du plugin, et du module. Tenez compte que celui du serveur prévaut sur les autres, puis en deuxième place, celui du plugin. C’est-à-dire que si vous avez un serveur avec un timeout de 10 secondes et un plugin avec un timeout de 20 et un module qui utilise ce plugin avec un timeout de 30, le temps maximum pour l’exécution de ce module sera de 10 secondes.

 


Dans notre cas, nous sélectionnons 15.

Description

Description du complément. Ecrivez une description brève, comme : Check a remote UDP port (by using NMAP). Use IP address and Port options. La description n’est pas anodine puisqu’elle sera vue dans l’interface d’utilisation du plugin par l’utilisateur. Assurez-vous que l’utilité du plugin soit bien expliquée.

Plugin create 2.jpg

Plug-in command

Chemin d’accès jusqu’à l’exécutable des plugins. De façon pré-définie, si l’installation a été standard, il faut suivre le répertoire suivant /usr/share/pandora_server/util/plugin/. Bien que le chemin puisse être différent. Dans ce cas, écrivez /usr/share/pandora_server/util/plugin/udp_nmap_plugin.sh dans le champ. Si vous utilisez vos propres plugins, assurez-vous de bien connaître le chemin d’accès pour les retrouver et que vous ayez les droits d’exécutions. (chmod 755).

Plug-in parameters

Une chaîne avec les paramètres des plugins qui se placeront après la commande et un espace blanc. Ce champ accepte des macros tales comme _field1_ _field2_ ... _fieldN_. Ceci est la partie la plus complexe du fonctionnement d’un plugin. Rassurez-vous, nous le verrons avec un exemple.

Parameters macros

Il est possible d’ajouter des macros illimités pour les utiliser dans le champ des paramètres du plugin. Ces macros apparaîtront sous forme de champs de caractères dans la configuration du module pour que l’utilisateur fasse abstraction de la complexité de l’usage d’un module type plugin. Il s’agit de permettre à l’utilisateur d’utiliser un plugin comme si c’était un module “de bibliothèque” dans lequel des champs y sont remplis, sans avoir besoin de connaître son fonctionnement. La définition de macros permet que l’utilisateur remplisse les paramètres d’appel au script sans savoir comme cela fonctionne, aussi bien le script que la façon de l’appeler.

Chaque champ a trois champs :

  • Description : une chaîne descriptive de la macro. Ce sera l’étiquette qui apparaîtra avec le champ dans le formulaire.
  • Valeur par défaut : valeur attribuée au champ par défaut.
  • Aide : un texte explicatif de la macro, pour montrer quelques exemples d’utilisation ou expliquer à quoi sert ce ce champ.

Exemple de la configuration de macros :

Macro configuration.png

Exemple de cette macro dans l’éditeur de module :

Macro editor2.jpg

1.5.1 Macros internes

De la même façon que les alertes, il est également possible d’utiliser des macros internes dans la configuration de plugins.

Les macros supportées sont les suivantes :

  • _agent_ ou _agentalias_: pseudo de l’agent auquel appartient le module.
  • _agentname_: nom de l’agent auquel appartient le module.
  • _agentdescription_: description de l’agent auquel appartient le module.
  • _agentstatus_ : état actuel de l’agent.
  • _address_: adresse de l’agent auquel appartient le module.
  • _module_ : nom du module.
  • _modulegroup_: nom du groupe du module
  • _moduledescription_: description du module.
  • _modulestatus_: état du module
  • _moduletags_: tags associés au module.
  • _id_agent_: ID de l’agent, utile pour construire directement l’URL ou rediriger vers la console de Pandora FMS.
  • _id_module_: ID du module.
  • _policy_: Nom de la politique à laquelle le module appartient (si de la política a la que pertenece el módulo (si c’est le cas).
  • _interval_: intervalle d’exécution du module.
  • _target_ip_: adresse IP de destination du module.
  • _target_port_: port de destination du module
  • _plugin_parameters_: paramètres du plugin du module.
  • _email_tag_: emails associés aux tags des modules.

1.5.2 Un plugin à distance à l’intérieur

Le code du plugin UP est très simple et nous permet d’expliquer comment fonctionne tout le processus :

#!/bin/bash
# This is called like -p xxx -t xxxx
HOST=$4
PORT=$2
nmap -T5 -p $PORT -sU $HOST | grep open | wc -l

Ce plugin pour Linux prend deux paramètres, le port UDP à tester et l’adresse de destination, avec les paramètres respectifs -p et -sU. En enregistrant le plugin, nous avons défini deux macros. Un pour le port et l’autre pour l’IP, de sorte que lorsque l’utilisateur va créer un module de type plugin, seul cela apparaît, rien de plus.

Une fois le plugin enregistré, pour l’utiliser dans un agent, il faudra créer un module de type “plugin server”. APpuyez sur le volet au dessus de modules (“Modules”). Sélectionnez créer un nouveau module réseau et appuyez sur “Create” :

Trescientos1.jpg

Dans le formulaire suivant, remplissez les champs vides, sélectionnez le type de module Generic module to adquire numeric data, indiquez l’adresse IP sur laquelle réaliser l’analyse et également le port sur lequel la faire :

Example1 edition module.png

Une fois terminé, cliquez sur “Create”.

Sur l’écran suivant, les modules de l’agent apparaîtront. Le module UDP Port check que nous venons de créer :

Udp port check demo.jpg

1.5.3 Ejemplo #1 : module de plugin à distance pour MySQL

Cet autre exemple -plus complexe- sur comment implémenter un plugin, dans ce cas un autre plugin par défaut qui vient avec Pandora FMS, le plugin de test de MYSQL.

Créez un module de complément (Administration -> Manage Servers -> Manage plugins) pour MySQL avec les données suivantes :

  • Nom : MySQL
  • Plugin type: Standard
  • Max. timeout: 10 seconds
  • Description : MySQL check plugin
  • Plugin command: /usr/share/pandora_server/util/plugin/mysql_plugin.sh
  • Plugin parameters: -s _field1_ -u _field2_ -p _field3_ -q _field4_
  • Macro _field1_:
    • Description : IP Address
    • Valeur par défaut : X.X.X.X
  • Macro _field1_:
    • Description : User
    • Valeur par défaut : User
  • Macro _field1_:
    • Description : Password
    • Valeur par défaut : Password
  • Macro _field1_:
    • Description : Check
    • Valeur par défaut : Connections
    • Aide : Possible values: Connections/Com_select/Com_update/Innodb_rows_read

Le plugin serait comme ci-dessous :

Plugin mysql1.png
Plugin mysql2.png
Plugin mysql3.png
Plugin mysql4.png

Ce plugin fournit quatre vérifications :

  • -q Connections : connexion
  • -q Com_select : nombre de test select depuis le début.
  • -q Com_update : nombre de tests update depuis le début.
  • -q Innodb_rows_read : lectures de lignes Innodb

Créez un module dans l’agent de l’équipement où Pandora FMS est installé. Attribuez-lui son nom, qui sera Mysql Connections, en utilisant "MySQL" comme plugin, ‘'localhost comme localhost, pandora comme utilisateur et le même mot de passe que celui utilisé pour la base de données de Pandora FMS. Enfin, le mot “Connections” comme test.

Le module pour créer sera comme ci-dessous :

Plugin mysql module.png
Mysql module2.png

Une fois créé, il apparaîtra dans la liste des modules, comme l’un de type plugin (dans ce cas-ci, en attente d’être lancé) :

Fosforo3.jpg

1.5.4 Exemple #2 : Module de plugin à distance pour serveur SMTP

Ce plugin envoie un mail en utilisant un serveur à distance. Il est possible d’indiquer l’IP du serveur, le port, l’utilisateur et le mot de passe et le schéma d’authentification, envía un correo utilizando un servidor remoto; se puede especificar IP del servidor, puerto, usuario y password y esquema de autenticación, ainsi que le mail de destination. Il renvoie 1 s’il fonctionne et 0 en cas d’échec. C’est-à-dire qu’il faudrait l’utiliser avec le type generic_proc.

Ceci est une capture de la configuration d’un module utilisant le plugin :

Pandora plugin SMTP5.png
Smtp module2.png

1.5.5 Exemple #3 : module de plugin à distance pour serveur DNS

Ce plugin vérifie que l’adresse IP d’un domaine donné (par exemple, artica.es) est une IP déterminée, en utilisant comme référence un DNS externe. De cette façon, nous pouvons valider si ce domaine renvoie l’IP correcte afin d’éviter des équilibrages inutiles, des attaques DNS, etc. Il renvoie 1 s’il fonctionne, 0 dans le cas contraire. Il faudrait l’utiliser avec le type generic_proc.

Voici une capture de la configuration d’un module utilisant le plugin :

Pandora plugin DNS5.png
Dns module2.png

1.6 Macros des champs personnalisés pour une surveillance à distance

Lorsque des modules à distance sont configurés, devoir mettre des informations relatives à un même agent plusieurs fois peut rapidement s’avérer monotone (par exemple, une chaîne de communauté SNMP). Les macros de champs personnalisés permettent d’utiliser les champs personnalisés des agents comme macros pour certaines options de configuration des modules.

Dans l’exemple suivant, nous créerons un composant réseau SNMP qui puisse être réutilisé entre des agents ayant des chaînes de communauté SNMP différents:

  • Pour commencer, allez sur Resources/Custom fields dans votre Console de Pandora FMS et définissez un nouveau champ personnalisé dans lequel la chaîne de communauté SNMP sera conservée. Indiquez son ID puisque plus tard, il fera partie de la macro, puis remplissez la chaîne de communauté avec la valeur adéquates dans vos agents SNMP.
CapturaMR3.JPG
  • Créez ensuite un composant réseau SNMP et mettez _agentcustomfield_n_ comme chaîne de communauté SNMP, où “n” est l’ID du champ personnalisé (dans notre exemple, _agentcustomfield_11_).
Custom field network component.png
  • Enfin, configurez un module en utilisant le composant réseau que vous venez de créer. Le module commencera automatiquement à fonctionner.

Les macros de champs personnalisés fonctionnent avec des modules de type SNMP, WMI, plugin et inventaire. Ils peuvent être utilisés dans des modules indépendants, des composants réseau et des modules de politique.

Pour un module de type WMI, deux nouveaux champs personnalisés pourraient être définis analogiquement afin de conserver le nom de l’utilisateur et le mot de passe et utiliser les macros correspondants dans la définition du module :

Wmi custom field.png

1.7 Exécution à distance de wizards et tests réseau (Exec Server)

Cette fonctionnalité permet qu’à partir de la console de Pandora FMS, quelques actions puissent être exécutées dans des serveurs à distance de Pandora FMS. Ainsi, vous pourrez utiliser les Wizards SNMP de l’agent, le navigateur de MIBs et les ‘event responses’ depuis un serveur à distance, e plus de pouvoir le faire depuis le serveur dans lequel se trouve la console.

En interne, cela fonctionne via l’exécution des commandes à distance SSH depuis la console de Pandora FMS aux serveurs habilités, que nous appelleront “Exec Server”. Ces derniers peuvent être des serveurs de Pandora FMS ou de Satellite Servers mais toujours sous Linux.

1.7.1 Configuration

Il est important de prendre en compte que, pour pouvoir utiliser correctement cette fonctionnalité, il faudra que l’agent sur lequel il travaille ait été créé au préalable par le serveur qui sera utilisé et que ce dernier ait la configuration à distance d’activée dans le cas d’un satellite server.

Template warning.png

Si la configuration à distance n’est pas activée, les modules de satellite ne se créeront pas à partir des wizards.

 


Pour configurer correctement l’Exec Server, il faudra configurer les systèmes en suivant une série d’étapes :

1. Dans la liste des serveurs Pandora FMS, on pourra accéder à l’édition du serveur à utiliser comme exec server :

Exec-server-111.JPG


2. L’IP du serveur sera éditée où se lanceront les commandes souhaitées et le check de “Exec Server” sera activé. Cette option pourra être configurée sur le Network Server et/ou sur Satellite Server.

3. Le test de configuration ne se réalisera pas puisque ce point n’a pas encore terminé de configurer le système et donnera une erreur.

Exec-server-222.JPG


4. Le serveur sur lequel la CONSOLE de Pandore s’exécute sera habilité pour que l’utilisateur “apache” ou un équivalent ait une shell d’exécution. Dans le fichier /etc/passwrd, il faudra modifier la ligne suivante pour que l’utilisateur ait une shell valide. Par exemple :

apache:x:48:48:Apache:/var/www:/bin/bash

5. Le répertoire sera créé “.ssh” en la ruta “/var/www/” et donnera des droits pour l’utilisateur “apache” :

mkdir /var/www/.ssh
chown apache /var/www/.ssh

6. Sera exécuté en tant que root :

son apache

7. Il faudra générer la clé SSH pour la connexion sur la machine à distance en exécutant la commande suivante :

ssh-keygen 

Les questions seront acceptées avec enter :

Exec-server-3.jpg


8. Avant d’accéder via SSH au “Exec server” (qui sera un serveur de Pandora FMS ou un satellite server sous Linux), un utilisateur sera créé dans cette machine, appelé “pandora_exec_proxy” et, en plus, le dossier "/home/pandora_exec_proxy/.ssh/":

sudo useradd pandora_exec_proxy -m
mkdir /home/pandora_exec_proxy/.ssh/

NOTE : L’utilisateur n’a pas de mot de passe, de sorte qu’il ne puisse se connecter à distance.


9. Le contenu de la clé publique sera copiée à partir de la console de Pandora FMS au serveur “exec server”, générée lors de l’étape précédente. Pour cela, il faudra copier le contenu du fichier /var/www/.ssh/id_rsa.pub en (en copiant collant le contenu) dans le fichier : /home/pandora_exec_proxy/.ssh/authorized_keys'' et les droits de ce fichiers seront modifiés :

chown -R pandora_exec_proxy /home/pandora_exec_proxy/.ssh/

10. Une fois l’utilisateur créé, à partir de la machine sur laquelle est exécutée la console et avec l’utilisateur “apache”, la commande suivante sera exécutée pour vérifier que vous pouvez entrer sans indiquer de mot de passe (en substituant l’IP par l’hostname/ip de Exec Server qui a été configuré lors des étapes précédentes) :

 ssh [email protected]_address

11. Après que toutes ces étapes soient correctes, il faudra revenir éditer (dans la console) le fichier /etc/pass pour remettre l’utilisateur apache comme il était incialement (sans shell local) :

apache:x:48:48:Apache:/var/www:/sbin/nologin

12. Enfin, il faudra tester la configuration dans la section édition du serveur proxy, dans la console de Pandora FMS. SI l’indicateur de test devient vert, cela signifiera qu’il est opérationnel et fonctionnel.

Exec-server-4.png

1.7.2 Utilisation de la fonctionnalité des exec servers

A partir de maintenant, dans l’explorateur MIB, dans les wizards SNMP de l’agent et dans les event responses, il sera possible de choisir à partir d’où nous souhaitons lancer la requêtes, depuis la console locale ou depuis le Exec server configuré :

Exec-server-555.JPG


De la même façon avec les Wizard WMI, celui des interfaces SNMP et le wizard de l’agent SNMP (non disponible pour des serveurs satellites) :

Exec-server-666.JPG


En fonction du serveur sélectionné, au moment de lancer le Wizard, les modules adaptés pour le serveur ou satellite server se créeront. Dans le cas du satellite server, les modules seront écrits dans le fichier de configuration à distance pour qu’ils puissent être exécutés par le serveur.

Pour les exécutions de “event response”, il faudra tout d’abord configurer un event response nouveau, qui utilise notre nouveau exec.server :

Exec-server-777.JPG


Puis ensuite, à partir d’un événement, le lancer :

Exec-server-8.JPG

1.8 Surveillance de chemin d’accès

Pandora FMS permet par défaut, de surveiller les chemins d’accès entre deux points du réseaux, en indiquant le chemin à suivre à tout moment pour communiquer entre ces deux points.

Pour utiliser ce systèmes, il faut :

  • Un agent software dans le point d’origine du chemin à analyser.
  • Pouvoir analyser via ICMP le point de destination à partir du point d’origine.

L’analyste des chemins de Pandora FMS utilise un plugin d’agent pour dresser une carte de ce chemin. Ce plugin d’agent utilise plusieurs méthodes pour coller les informations, en donnant les informations structurées au serveur de Pandora FMS.

Note : En option, si vous souhaitez faire des scans des chemins via Internet, nous recommandons de déployer l’application mtr dans l’équipement d’origine du chemin. Plus d’information sur :

https://en.wikipedia.org/wiki/MTR_%28software%29

http://www.bitwizard.nl/mtr/

1.8.1 Configuration

A partir de la version 7.0 OUM715, le plugin est inclu dans l’agent. Pour le configurer, vous devrez activer l’exécution du plugin depuis la console Pandora FMS, une fois la configuration à distance de l’agent activée.


Accédez à l’onglet de configuration des plugins dans votre agent et ajoutez la ligne suivante (si la version est antérieure à 7.0 715, ou que vous n’avez pas déployé le plugin dans le dossier, vous devrez indiquer le chemin d’accès complet au plugin pour son exécution) :

route_parser -t adresse_objectif


Où l’adresse objectif peut être une adresse IP v4 ou un nom de domaine FQDN.

Route conf2.png

1.8.2 Visualisation

Une fois que le système est configuré, un nouvel onglet apparaîtra dans la vue de l’agent avec le chemin d’accès que les communications ont suivies pour atteindre l’objectif :

Vue de l’exemple de chemin d’accès vers une machine dans un réseau différent de celui d’origine (connexions LAN) :

Route view1.png

Vue d’un exemple de chemin vers 8.8.8.8 (Google's DNS) (connexions WAN)

Route view2.png

Revenir à l’Index de Documentation Pandora FMS