Supervision à distance

Points pertinents dans ce sujet :

• Supervision par ICMP.
• Supervision par TCP.
• Supervision selon SNMP.
• Supervision de routes.
• Supervision via API.

La supervision web classique est traitée dans un sujet à part.

Le Network server exécute les tâches qui lui sont assignées via un système de files d'attente multiprocessus et peut fonctionner avec d'autres serveurs réseau (mode HA).

Il est nécessaire d'avoir une visibilité complète (adresses IP et ports) sur lesquels les tests seront effectués. Ce chapitre couvre également le Heavy Server.

1. Tests ICMP : Ce sont des tests réseau de base qui permettent de savoir si un hôte ou host est en ligne et accessible, ainsi que le temps nécessaire pour atteindre ledit dispositif à travers le réseau.
2. Tests TCP : De manière distante, il est vérifié qu'un système a ouvert le numéro de port TCP spécifié dans la définition du module.
3. Tests SNMP : Il est possible de lancer des requêtes SNMP (SNMP Polling) aux systèmes ayant ledit service activé pour obtenir des données telles que l'état des interfaces, la consommation réseau par interface, etc.

Pour superviser à distance un équipement ou un service d'un équipement (FTP, SSH, etc.), il faut d'abord créer l'agent correspondant. On y accède par le menu Management → Resources → Manage agents → Create agent. Remplissez les données pour votre nouvel agent (nom, adresse IP, groupe d'agents) et appuyez sur le bouton Create.

Une fois l'agent créé, cliquez sur l'onglet supérieur des modules (Modules). Là, sélectionnez la création d'un nouveau module réseau en appuyant sur le bouton Create module. Dans le formulaire suivant, sélectionnez Network TCP module ou Network ICMP module et lorsque le menu déroulant de droite se charge, sélectionnez la vérification souhaitée.

Ce sont les vérifications les plus basiques qui donnent une information importante et exacte.

• icmp_proc : Vérification en ligne (ping) qui permet de savoir si une adresse IP répond ou non.
• icmp_data : Vérification de latence qui indique le temps en millisecondes pour répondre à une requête ICMP de base.

TCP est orienté connexion, donc à un envoi TCP Send correspondra une réponse TCP Receive qui indique l'état d'un port ou d'un service à superviser. Optionnellement, on peut envoyer une chaîne de texte et attendre de recevoir une réponse qui sera traitée directement par Pandora FMS comme une donnée.

• TCP Send : Champ pour configurer les paramètres à envoyer au port TCP. Pour envoyer plusieurs chaînes en séquence envoi/réponse, il faut les séparer par le caractère | ; accepte la chaîne ^M pour la remplacer par l'envoi d'un retour chariot.
• TCP receive : Champ pour configurer les chaînes de texte qui doivent être comparées aux réponses reçues de la connexion TCP. Si elles sont envoyées/reçues en plusieurs étapes, chaque étape doit être séparée par le caractère |.

Cas fréquents :

TCP Send

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

TCP Receive

250|250|250

Pour pouvoir utiliser ces modules avec succès, les identifiants de connexion de l'agent à superviser sont nécessaires. Par conséquent, tout cela doit être enregistré dans le magasin sécurisé d'identifiants. Les instructions pour la configuration générique d'un module sont répétées en sélectionnant l'un des suivants :

• remote_execution_data : numérique.
• remote_execution proc : booléen (0 FAUX, différent de zéro VRAI).
• remote_execution_data_string : alphanumérique (chaîne).
• remote_execution_data_inc : incrémental (ratio).

De plus, les paramètres suivants doivent être définis :

1. Target IP : Optionnellement l'adresse IP de la cible (sinon l'adresse IP de l'agent sera utilisée).
2. Port : Optionnellement le numéro de port auquel se connecter (22 sous Linux® ; indifférent sous MS Windows® et le firewall doit être configuré pour autoriser les vérifications à distance).
3. Command : La commande à exécuter pour effectuer la supervision.
4. Credential identifier : Le jeu d'identifiants à utiliser pour se connecter.
5. Connection method : Optionnellement la méthode de connexion de la cible (ou celle de l'Agent sera utilisée).

Pour que les modules d'exécution à distance sous MS Windows® s'exécutent correctement, plusieurs règles du Firewall doivent être activées sur les ordinateurs à superviser :

• File and Printer Sharing (SMB-In).
• File and Printer Sharing (Spooler Service - RPC-EPMAP) :
  
• Windows Management Instrumentation (WMI-In) :
  

• Custom ID (onglet Categorization) : Permet de stocker un identifiant d'une application externe pour faciliter l'intégration de Pandora FMS avec des applications tierces, telles qu'une Configuration Management DataBase (CMDB).
• Interval (onglet Intervals) : Intervalle d'exécution du module, lequel peut être personnalisé (token Interval values) par un utilisateur Administrateur de manière prédéfinie puis être utilisé par les utilisateurs standards.
• Post process (onglet Data) : Pour le post-traitement du module (multiplier la valeur retournée), comme lorsque des octets sont obtenus et qu'il est nécessaire d'afficher la valeur en Mégaoctets.
• Min. Value et Max. Value (onglet Data) : Toute valeur inférieure au minimum ou supérieure au maximum sera considérée comme invalide et sera écartée.
• Export target (onglet Data) : Uniquement disponible avec Export Server.
• Category (onglet Categorization) : Uniquement utilisé conjointement avec la Métaconsole (Command Center).
• Si Cron from est activé (onglet Intervals), le module s'exécutera une fois lorsque la date et l'heure actuelles correspondent à la date et à l'heure configurées dans Cron from, ignorant l'intervalle propre du module.
• Target IP : Adresse IP du dispositif à superviser. On peut utiliser la macro _agentname_ ou _agentalias_ tant que le nom de l'agent ou son alias possède une adresse IP valide.

• Polling SNMP : S'effectue périodiquement de manière active et implique d'ordonner à Pandora FMS d'exécuter une commande get contre un dispositif SNMP.
• Trap SNMP : Survient lors de changements ou d'événements sur le dispositif, qui peuvent arriver à tout moment ou non. Il est nécessaire d'activer la console de SNMP Traps dans Pandora FMS, où seront affichés ceux reçus de n'importe quel dispositif. Des alertes peuvent être définies via des règles de filtrage de SNMP Traps par n'importe lequel de ses champs.

Pandora FMS travaille avec SNMP en manipulant des Identifiants d'Objets ou Object IDentifier (OID) individuels, ainsi chaque OID est un module réseau.

Étapes nécessaires pour travailler avec SNMP

• Activer la gestion SNMP du dispositif pour que des requêtes SNMP puissent être faites depuis le serveur réseau.
• Connaître l'adresse IP et la communauté SNMP du dispositif distant.
• Connaître l'OID concret du dispositif distant (ou utiliser l'un des multiples assistants dont dispose Pandora FMS ou son explorateur d'OID SNMP).
• Savoir comment gérer la donnée retournée par le dispositif. Les dispositifs SNMP retournent des données sous différents formats. Pandora FMS peut traiter presque tous. Les données de type compteur sont celles que Pandora FMS gère comme remote_snmp_inc et sont d'une importance particulière, car étant des compteurs, elles ne peuvent être traitées comme des données numériques mais comme un 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 l'on souhaite superviser de manière adéquate.

Pour pouvoir superviser tout autre élément par SNMP, sa communauté SNMP doit être connue. Lors de la création du module, vous devez sélectionner Manual setup. Dans le champ Type, il existe trois options pour SNMP, en sélectionnant l'une d'elles, le formulaire s'étendra en affichant les champs additionnels pour SNMP.

• SNMP community : C'est comme une identification d'utilisateur ou un mot de passe qui permet l'accès aux statistiques d'un routeur ou d'un autre dispositif (versions SNMPv1 et SNMPv2c puisque SNMPv3 utilise l'authentification par identifiants). Par défaut, les dispositifs possèdent la communauté publique (public) en lecture seule et généralement chaque administrateur réseau change toutes les chaînes de la communauté pour des valeurs personnalisées dans la configuration du dispositif.
• SNMP OID : Identifiant OID à superviser, lequel consiste en une chaîne de chiffres et de points. Ces chaînes sont automatiquement traduites par des chaînes alphanumériques plus descriptives si les MIB correspondantes sont installées sur le système.
• Target IP : Adresse IP du dispositif à superviser. On peut utiliser la macro _agentname_ ou _agentalias_ tant que le nom de l'agent ou son alias possède une adresse IP valide.

Un EndPoint est généralement utilisé pour obtenir des données locales, cependant, une supervision SNMP peut également y être effectuée.

Sous Linux®

snmpget est généralement installé par défaut, il peut donc être appelé depuis la ligne module_exec :

module_exec snmpget -v <version> -c <community> <IP_address> <numeric_OID>

Il convient de souligner que seuls les OID “basiques” sont traduisibles par leur équivalent numérique et qu'il est recommandé de toujours utiliser des OID numériques, car on ne sait pas si l'outil saura les traduire ou non. En tout cas, les MIB peuvent toujours être chargées dans le répertoire :

/usr/share/snmp/mibs

Sous MS Windows®

snmpget.exe (qui fait partie du projet net-snmp, sous licence BSD) est ajouté à l'EndPoint avec les MIB de base, en plus d'un empaqueteur ou script (wrapper ou script) pour encapsuler l'appel. De la même manière que sous Linux®, les MIB peuvent être chargées dans le répertoire :

/util/mibs.

Pandora FMS utilise par défaut les MIB qui sont hébergées par le système d'exploitation dans :

/usr/share/snmp/mibs

De nouvelles MIB peuvent être incorporées (et gérées ensuite) via le menu Operation → Monitoring → SNMP → MIB uploader. Ces MIB sont uniquement utilisées par Pandora FMS et sont stockées dans le chemin :

…/pandora_console/attachment/mibs/

Le système fera une exploration avec les paramètres spécifiés dans les champs de la section Filters et affichera en plus (si disponible) l'information de l'OID demandé et obtenu. S'il n'existe pas d'information sur l'OID du dispositif, celle-ci sera affichée uniquement au format numérique. En cas d'échec de l'exploration, le message The server did not return any response sera obtenu.

L'explorateur SNMP permet également de rechercher une chaîne de texte tant dans les valeurs d'OID obtenues que dans les valeurs traduites des propres OID (si disponibles). C'est particulièrement utile pour rechercher des chaînes connues concrètes et localiser leur OID. S'il localise plusieurs entrées, il permettra de sauter d'une occurrence à l'autre et les affichera surlignées en jaune.

Il est possible de sélectionner plusieurs OID et de les ajouter à un ou plusieurs agents en sélectionnant Create agent modules dans la liste Actions et en appuyant ensuite sur le bouton Create :

Avec les OID sélectionnés, ils peuvent également être ajoutés à une politique de supervision existante ou même créer un composant réseau avec ceux-ci.

Vue d'administration d'un agent :

L'adresse IP de destination doit être définie (le champ Target IP ne peut pas utiliser la macro _agentname_ ni _agentalias_), la communauté et d'autres paramètres optionnels (SNMP v3 est supporté) pour faire un Walk SNMP à la cible. Une fois l'information reçue correctement, un formulaire apparaîtra pour la création de modules tels que Devices, Processes, Free space on disk, Temperature sensors, Processes.

On sélectionne le type de module et on les ajoute à la liste de création, quand ce processus se termine, on pourra cliquer sur le bouton Create Modules.

Cet assistant créera deux types de modules :

• Modules SNMP pour les requêtes avec OID statique : Capteurs, Mémoire, CPU, etc.
• Modules Plugin pour les requêtes avec OID dynamique ou les données calculées : Processus, Espace disque, Mémoire utilisée exprimée en pourcentage, etc.

Pour que l'assistant SNMP puisse obtenir des données d'un dispositif SNMP grâce aux composants distants, il est nécessaire de remplir deux conditions :

• Avoir enregistré dans Pandora FMS le Private Enterprise Number (PEN) du fabricant du dispositif.
• Avoir enregistré et activé dans Pandora FMS les composants de l'assistant SNMP pour le fabricant du dispositif.

Si le dispositif exploré remplit ces conditions, tous les modules pour lesquels des données ont pu être obtenues seront affichés (il affichera une icône informative pour noter qu'il existe des modules sélectionnés) afin de donner l'opportunité de sélectionner lequel créer et lequel non.

Une fois le bouton Create modules pressé, une liste récapitulative des modules choisis avec leur configuration sera affichée. Dans cette liste, on verra les modules qui ne peuvent pas être créés, soit parce qu'ils existent déjà sur l'agent, soit parce que deux ou plusieurs modules ont été configurés avec le même nom dans l'assistant lui-même.

Avant qu'ils ne soient ajoutés à l'agent, il y aura une dernière occasion de confirmer la création de ces modules ou de l'annuler et de continuer à modifier le résultat de l'assistant.

Cet assistant navigue dans la branche SNMP IF-MIB::interfaces, offrant la possibilité de créer de multiples modules de plusieurs interfaces avec la sélection multiple. Après avoir sélectionné l'adresse IP de destination (le champ Target IP ne peut pas utiliser la macro _agentname_ ni _agentalias_) et les autres champs nécessaires, le système fera une requête SNMP à la machine cible et remplira le formulaire pour la création de modules.

Une fois la création des modules confirmée, ils seront à nouveau évalués un par un pour voir s'ils peuvent être créés ou non, afin d'éviter des modules en double au cas où, dans le laps de temps de la confirmation, les mêmes modules auraient été créés par un autre moyen.

Il sera notifié si le processus a pu être complété avec succès ou si, au contraire, il y a eu un module qui n'a pas pu être créé.

WMI est une technologie employée dans le système d'exploitation de Microsoft® pour obtenir des informations distantes d'équipements fonctionnant sous Windows® ; elle est disponible de la version Windows XP® jusqu'aux versions les plus actuelles. WMI permet d'obtenir tout type d'informations du système d'exploitation, des applications et même du matériel. Les requêtes WMI peuvent être effectuées localement avec l'EndPoint (en appelant l'API du système d'exploitation) ou de manière distante.

Les requêtes se font en WQL, une sorte de langage SQL spécifique à Microsoft®, pour tout objet apparaissant dans la base de données du système WMI.

Pour commencer la supervision par WMI, il faudra d'abord créer l'agent correspondant, puis cliquer sur l'onglet supérieur des modules (Modules). Une fois là, on sélectionne Create module, on sélectionne WMI module et on appuie sur le bouton Create.

Champs spécifiques WMI :

• Namespace : Espace de noms WMI. Dans certaines requêtes, ce champ est différent d'une chaîne vide (par défaut), selon le fournisseur d'informations de l'application à superviser.
• Key string : Optionnel, champ pour comparer avec la chaîne retournée par la requête. S'il existe, le module retourne 1 ou 0, au lieu de la chaîne elle-même.
• Field number : Le numéro du champ retourné en commençant par 0 (les requêtes WMI peuvent retourner plus d'un champ). La plupart du temps, c'est 0 ou 1.
• WMI Query : Requête WMI en WQL, similaire à une instruction SQL.

Utilisé pour naviguer et créer des modules avec des requêtes WMI vers un agent spécifique. Dans l'assistant de l'agent (onglet dans la vue d'administration d'un agent) :

Le nom d'utilisateur et le mot de passe ayant les permissions pour effectuer des requêtes WMI (ou à défaut les identifiants d'Administrateur) sur l'ordinateur cible doivent être spécifiés pour effectuer les premières requêtes WMI. Cette information sera utilisée pour la création de modules.

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

• Services : Des moniteurs booléens seront créés en état normal si le service fonctionne et en état critique lorsqu'il est arrêté.
• Processus : Les moniteurs de processus recevront des informations uniquement lorsque le processus est actif. Sinon, ils tomberont en état inconnu.
• Espace libre sur disque.
• Composants WMI : Dans ce cas, vous choisirez parmi les composants WMI enregistrés dans le système.

Ces modules seront affichés organisés en blocs basés sur le groupe auquel appartient le composant du wizard qui les a générés :

Tous les blocs seront affichés compressés dans un premier temps pour faciliter la visualisation et pourront être étendus pour modifier les éléments sélectionnés ou les données. De plus, dans chaque bloc où des modules ont été marqués pour leur création, une icône informative apparaîtra indiquant les modules sélectionnés.

Si nous déployons un bloc, il sera possible de choisir les modules qui seront ajoutés et ceux qui ne le seront pas, ainsi que l'option de modifier le nom, la description ou les seuils de chaque module individuellement.

Une fois le bouton Create modules pressé, une liste avec un résumé des modules choisis avec leur configuration sera affichée. Dans cette liste, on verra les modules qui ne peuvent pas être créés, soit parce qu'ils existent déjà sur l'agent, soit parce que deux ou plusieurs modules ont été configurés avec le même nom dans le même assistant.

Malgré toutes les modifications effectuées, il y aura une dernière occasion de confirmer la création de ces modules ou d'annuler et de continuer à modifier le résultat de l'assistant.

Une fois la création des modules confirmée, ils seront à nouveau évalués un par un pour voir s'ils peuvent être créés ou non, afin d'éviter des modules en double au cas où, dans le laps de temps de la confirmation, les mêmes modules auraient été créés par un autre moyen.

L'assistant notifiera si le processus a pu être complété avec succès ou si, au contraire, il y a eu un module qui n'a pas pu être créé.

Un plugin distant est un script ou un fichier exécutable qui accepte des paramètres et retourne une unique valeur. Le résultat pourrait être un nombre, une valeur booléenne (0 = error, OK <> 0) ou une chaîne de texte.

Un plugin distant permet généralement des paramètres d'entrée. Par défaut, plusieurs plugins de serveur sont installés et prêts à être utilisés et l'utilisateur peut toujours ajouter ceux dont il a besoin.

Il existe deux classes de plugin distant : standard et type Nagios®. La différence réside principalement dans le fait que ceux de type Nagios répondent avec un type d'erreurs (error level) et en plus, de manière optionnelle, avec une chaîne descriptive.

Lors de l'édition d'un plugin :

• Plug-in type : Permet d'établir s'il est de type standard ou type Nagios.
• Max. timeout : Pour fixer le temps d'attente pour son exécution, une attention particulière doit être portée à cette valeur car elle doit couvrir assez de temps pour l'exécution, sinon aucune valeur ne sera obtenue.
• Le champ de la description est important car il sera vu dans l'interface d'utilisation du plugin par l'utilisateur, choisissez une légende courte et explicative.

D'une manière similaire aux alertes, on peut également utiliser des macros internes dans la configuration des plugins. Les macros supportées sont les suivantes :

• _agent_ ou _agentalias_ : Alias 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_ : Étiquettes (tags) associés au module.
• _id_agent_ : ID de l'agent, utile pour construire directement l'URL ou rediriger vers la Console web de Pandora FMS.
• _id_module_ : ID du module.
• _policy_ : Nom de la politique à laquelle appartient le module si l'une d'elles est établie.
• _interval_ : Intervalle d'exécution du module.
• _target_ip_ : Adresse IP de la cible du module.
• _target_port_ : Port de la cible du module.
• _plugin_parameters_ : Paramètres de plugin du module.
• _email_tag_ : E-mails associés aux tags de modules.

Les macros de champs personnalisés permettent d'utiliser les champs personnalisés d'agents comme macros pour certaines options de configuration de modules.

Les macros de champs personnalisés fonctionnent avec les modules de type SNMP, WMI, plug-in et inventaire. Elles peuvent être utilisées dans des modules indépendants, des composants réseau et dans des modules de politique.

On y accède par Management → Resources → Custom fields → Create field, dans ce nouveau champ personnalisé sera stockée la chaîne de communauté SNMP. Notez son ID, car plus tard il fera partie de la macro, et remplissez la chaîne de communauté avec la valeur adéquate dans vos agents SNMP.

Ensuite, un composant réseau SNMP doit être créé dans lequel il faut introduire _agentcustomfield_<n>_ comme chaîne dans SNMP community, où n est l'ID du champ personnalisé créé.

Cette fonctionnalité permet d'exécuter certaines actions sur des serveurs distants Pandora FMS depuis la Console web de Pandora FMS.

Avec un Exec server configuré, on pourra choisir depuis :

• Le SNMP browser dans la section SNMP.
• Dans les Event responses dans la section des événements.
• Dans les wizards SNMP d'agent.
• Dans les wizards de WMI d'agent.
• Dans les wizards d'interfaces SNMP d'agent (sauf pour les Satellite Servers).

Selon le serveur sélectionné au moment de lancer chaque assistant, des modules adaptés pour le serveur ou le Satellite Server seront créés. Dans ce dernier cas, les modules seront écrits dans le fichier de configuration distante pour qu'ils puissent être exécutés par le serveur.

Ils fonctionnent en interne à travers l'exécution de commandes distantes SSH depuis la console de Pandora FMS vers les serveurs activés, appelés Exec Server. Ceux-ci peuvent être des Network Servers ou Satellite Servers de Pandora FMS.

Le processus de configuration nécessitera le concours de la personne chargée de l'administration réseau pour configurer tant les PFMS Servers que les ordinateurs cibles et le trafic de connexions et de données, entre autres aspects comme les pare-feux et les VLAN pour augmenter la sécurité.

• On doit disposer d'un agent logique configuré avec la configuration distante activée.

• Sur le serveur qui exécute la Console web PFMS, un utilisateur doit être créé au niveau du système d'exploitation avec un accès dû à son propre répertoire et qui permet d'exécuter un shell valide pour les tâches à confier.
• Dans la Console web PFMS, il faudra se connecter en tant qu'utilisateur superadmin ou Pandora Administrator.

Consultez l'annexe technique pour plus d'informations.

Pandora FMS offre par défaut la supervision de routes complètes entre deux points du réseau, indiquant visuellement le chemin suivi à tout moment pour communiquer entre ces deux points. L'analyseur de routes de Pandora FMS utilise un plugin d'agent pour tracer une carte de la route.

Pour utiliser ce système, il est nécessaire d'avoir :

• Un EndPoint au point d'origine de la route à analyser.
• Une portée via ICMP depuis le point d'origine.

Accédez à l'onglet de configuration des plugins dans l'agent et ajoutez la ligne suivante :

/usr/share/pandora_agent/plugins/route_parser -t <target_address>

Enfin, l'exécution du plugin doit être activée.

• API retrieve module : Peut recevoir trois types de données de la requête API effectuée, numérique, vrai ou faux (bool) et alphanumérique.

• API custom module : Possède uniquement un type bool lequel sera normal si toutes les conditions sont remplies ou si le code de réponse de l'API ne correspond à aucun de ceux spécifiés (un code 200 est attendu en réponse). Par défaut, les codes de comparaison avec la réponse sont 500, 404, 403 et autant que nécessaire peuvent être ajoutés, toujours séparés par des virgules. Si l'un de ces codes est reçu en réponse, le module passera en état critique (0).

Dans les deux cas, les champs suivants doivent être configurés :

1. Timeout : Temps maximum d'attente de réponse de l'appel API, 10 secondes par défaut.
2. URL : L'adresse web de l'endpoint API chargé de recevoir la requête.
3. Method : Peut être GET (valeur par défaut), POST, PUT, GET et DELETE.
4. Ignore certificate : Si activé (non recommandé), ignorera les certificats.
5. Headers : On spécifie les en-têtes HTTP de la requête, ce qui permet d'établir des paires de valeurs convenues. Par défaut, Content-Type application/json est établi pour recevoir une réponse au format JSON et un en-tête supplémentaire pourra être ajouté.
6. Body : Pour spécifier le contenu de la requête, la requête elle-même (particulièrement utile avec PUT et POST).

Pour API custom module, on dispose de JSON path query, bouton sur la première ligne, lequel ouvre une fenêtre contextuelle effectuant une requête préalable, affichant les résultats pour spécifier le champ JSON avec lequel la comparaison sera faite. Une fois la cible sélectionnée, le type de donnée attendu, la condition et la valeur de comparaison devant être satisfaite doivent être spécifiés pour introduire les réponses bool dans le module. On pourra ajouter autant de conditions que nécessaire, toutes doivent être remplies pour que le module soit en état normal (1).

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