Introduction à la Supervision

Introduction à la supervision

Toute l'interaction de l'utilisateur avec Pandora FMS se fait via la console web. La console permet l'accès via un navigateur, sans avoir besoin d'installer des applications lourdes, permettant la gestion depuis n'importe quel ordinateur avec un navigateur si le logiciel est compatible avec HTML5.

La supervision est l'exécution de processus sur tous les types de systèmes pour collecter et stocker des informations, effectuer des actions et prendre des décisions sur la base de ces données.

Pandora FMS est un système de surveillance évolutif qui dispose d'une multitude de fonctionnalités permettant d'étendre la portée et le volume des informations collectées, pratiquement sans limites.

Agents logiques sur Pandora FMS

La surveillance effectuée par Pandora FMS est classée dans la catégorie agents. Un agent appartient toujours à un groupe. Ces agents vont être équivalents à chacun des différents équipements, dispositifs, webs ou applications que nous surveillons.

Les agents définis dans la console Pandora FMS peuvent présenter des informations locales collectées par l'intermédiaire d'un agent logiciel, des informations à distance collectées par le biais de vérifications réseau, ou les deux. Par conséquent, il est important de souligner la différence entre les agents en tant qu'unité organisationnelle dans la console Pandora FMS, et les agents logiciels en tant que services de collecte de données locales.

Surveillance basée sur des agents software vs. surveillance à distance

Nous pourrions diviser la surveillance en deux grands groupes, selon la façon dont l'information est recueillie :

  • La surveillance par agent consiste en l'installation d'un petit logiciel qui reste actif dans le système et en l'obtention d'informations « localement », par l'exécution de commandes et de scripts.
  • La supervision à distance consiste à utiliser le réseau pour effectuer des contrôles à distance vers les systèmes, sans qu'il soit nécessaire d'installer un composant supplémentaire dans l'équipement à surveiller.

Comme on peut l'apprécier, la surveillance basée sur des agents logiciels obtiendra l'information par le biais de contrôles locaux, tandis que la supervision à distance obtiendra l'information par le biais de contrôles réseau du serveur Pandora FMS.

Les deux types d'agents partagent la même configuration générale et la même visualisation des données ; la surveillance peut être d'une manière ou d'une autre et aussi combinée, produisant une surveillance mixte.

Configuration de l’agent logique dans la console

Interface d'édition dans la vue normale

  • Alias : Pour un fonctionnement correct de toutes les fonctions que Pandora FMS exécute avec ses agents/modules, il est recommandé de ne pas utiliser des caractères comme /, \, |, %, #, & et $ dans le nom d'agent. Lorsque vous traitez avec ces agents, ils peuvent créer une confusion avec l'utilisation des chemins du système ou l'exécution d'autres commandes, causant des erreurs dans le serveur.
  • Serveur : Serveur qui va exécuter les contrôles configurés dans la surveillance des agents, paramètre spécial en cas de configuration HA dans son installation.

Interface d'édition dans la vue avancée

vue avancée

  • Groupes secondaires : Paramètre facultatif permettant à un agent d'appartenir à plus d'un groupe.
  • Protection en cascade : Paramètre permettant d'éviter une avalanche d'alertes. Vous pouvez choisir un agent ou un module d'agent. Dans le premier cas, lorsque l'agent choisi est en situation critique, il ne génère pas d'alertes. Dans le second cas, seulement lorsque le module spécifié est en situation critique, l'agent ne générera pas d'alertes.
  • Définition des modules : Trois modes de travail peuvent être sélectionnés.
    • Mode d'apprentissage : Si XML arrive avec de nouveaux modules, ils seront créés automatiquement (par défaut).
    • Mode Normal : Si un XML arrive avec de nouveaux modules, ils ne seront créés que s'ils sont déjà déclarés dans la console précédemment.
    • Mode Auto-désactivé : Identique au mode d'apprentissage, mais si tous les modules passent en mode inconnu, l'agent sera désactivé jusqu'à ce que les informations arrivent à nouveau.

Visualisation de l'agent

Dans cet écran vous pouvez voir une grande quantité d'informations sur l'agent, et nous offre la possibilité de forcer l'exécution de contrôles à distance et de rafraîchir les données qui arrivent.

Dans la partie supérieure nous pouvons voir un résumé avec une multitude de données de l'agent, telles que :

  • Total des modules et leur état.
  • Événements des dernières 24 heures.
  • Information de l'agent.
    • Nom.
    • Version.
    • Accessibilité de l'agent.
    • Groupe.

Liste de modules (Module name) initiés qui appartiennent à l'agent et ses respectives états (Status).

Enfin, vous verrez les événements générés par l'agent.

Modules

Les modules sont des unités d'information stockées dans un agent. Il s'agit des éléments de surveillance avec lesquels l'information est extraite de l'appareil ou du serveur vers lequel l'agent pointe.

Chaque module ne peut stocker qu'un seul type de métrique. Dans un même agent il ne peut pas y avoir deux modules avec le même nom.

Dans le même agent, il ne peut pas y avoir deux modules portant le même nom. Tous les modules ont un état associé, qui peut être :

  • Non inité : Où aucune donnée n'a encore été reçue.
  • Normal : Il reçoit des données dont les valeurs se situent en dehors des seuils d'avertissement ou des seuils critiques.
  • Avertissement : Il reçoit des données dont les valeurs se situent à l'intérieur du seuil d'avertissement.
  • Critique : Les données sont reçues avec des valeurs inférieures au seuil critique.
  • Inconnu : Le module a fonctionné et a cessé de recevoir des informations pendant un certain temps.

Les modules disposent de différents types de données, telles que booléennes, numériques ou alphanumériques entre autres.

Types de modules

Il existe plusieurs types de modules dans Pandora FMS.

  • Module de données : est un type de module de surveillance local avec lequel des contrôles sont effectués sur le système dans lequel se trouve l'agent, comme par exemple l'utilisation du CPU de l'appareil ou de sa mémoire libre.
  • Module réseau : est un type de module de surveillance à distance avec lequel on vérifie la connexion avec le périphérique ou le serveur vers lequel pointe l'agent, comme par exemple s'il fonctionne ou s'il a un port particulier ouvert.
  • Plugin Module : est un type de module de surveillance locale ou à distance avec lequel vous pouvez effectuer des contrôles personnalisés par la création de scripts. Avec eux, des contrôles plus poussés et plus poussés que ceux proposés directement via la console Pandora FMS peuvent être effectués.
  • Module WMI : est un type de module de monitoring local avec lequel il est possible de vérifier le système Windows via le protocole WMI, comme par exemple pour obtenir la liste des services installés ou la charge courante du CPU.
  • Module de prédiction :est un type de module de surveillance prédictive avec lequel différentes opérations arithmétiques sont effectuées par la consultation de données provenant d'autres modules « de base », comme l'utilisation moyenne du CPU des serveurs surveillés ou la somme des latences de connexion.
  • Module Serveur Web : est un type de surveillance Web avec lequel on vérifie l'état d'un site Web et on obtient des données de celui-ci, comme par exemple voir si un site Web est en panne ou s'il contient un mot spécifique.
  • Module d'analyse Web : est un type de surveillance Web avec lequel des simulations de la navigation Web d'un utilisateur sont effectuées, comme la navigation vers un site Web, l'introduction d'informations d'identification ou l'exécution de formulaires.

Surveillance des états

Lorsque nous surveillons, nous obtenons des valeurs d'un système, qu'il s'agisse de la mémoire, du CPU, de la température du châssis, du nombre d'utilisateurs connectés, des commandes dans un WEB e-commerce ou de toute autre valeur numérique. Parfois nous ne nous intéressons qu'aux données, mais en général nous voulons associer un ETAT à ces valeurs, de sorte que lorsque nous surmontons un « SEUIL », l'état change pour savoir si quelque chose est bon ou mauvais. C'est pourquoi, lorsque nous parlons de contrôle, nous devons introduire le concept d'ETAT.

Pandora FMS permet de définir seuils pour définir l'état qu'aura un contrôle en fonction des données qu'il affiche. Les trois états possibles sont : NORMAL, WARNING et CRITICAL. Un seuil est une valeur à partir de laquelle on passe d'un état à un autre. L'état que les modules vont acquérir dépendra de ces seuils, qui sont spécifiés au moyen des paramètres suivants présents dans la configuration de chaque module :

threshold1.jpg

  • Warning status - Min. Max. : Limites inférieure et supérieure de l'état d'avertissement. Si la valeur numérique du module se trouve dans cette plage, le module passe en état d'avertissement. Si aucune limite supérieure n'est spécifiée, elle sera infinie (toute valeur supérieure à la limite inférieure).
  • Critical status - Min. Max. : De même que le point précédent mais pour l'état critical.
  • Inverse interval : Présent à la fois pour le seuil warning et le seuil critical. S'il est activé, le module change d'état lorsque ses valeurs sont en dehors de l'intervalle spécifié dans les seuils. Il fonctionne également pour les modules alphanumériques (chaîne de caractères) ; si les chaînes de texte ne coïncident PAS avec ce qui est spécifié dans Warning status - Str. ou Critical status - Str., le module change d'état; voir l'image suivant :

threshold2.jpg

  • Warning status - Str. : Expression régulière pour les modules alphanumériques (string). Si des coïncidences sont trouvées, le module passe en état d'avertissement.
  • Critical status - Str. : expression régulière pour les modules alphanumériques (chaîne). Si des coïncidences sont trouvées, le module passera à l'état critique.

Si les seuils warning et critical coïncident dans une plage quelconque, le seuil critical prévaudra toujours.

Seuils numériques - Cas pratique 1

Lorsque un module est créé, ses seuils ond par défaut valeur 0. Pour superviser le pourcentage d'utilisation de l'UCT , il faut que son état devienne warning (jaune) lorsque le 70 % d'utilisation est atteint et critical (rouge) lorsque le 90 % est atteint ; il sera nécessaire d'établir les valeurs suivants :

threshold3.jpg

Ainsi, lorsque la métrique de cet ordinateur est reçue, si la donnée est sous 70 % (normal), alors qu'entre 70 % et 89.99 % il apparaîtra en jaune (WARNING), et au-dessous de 90 %, rouge CRITICAL. En raison du fonctionnement des seuils, il n'est pas nécessaire, dans de tels cas, de fixer des limites supérieures. En effet, si seul le seuil inférieur est fixé, le seuil supérieur sera pris en compte comme « aucune limite », de sorte que toute valeur supérieure au seuil inférieur sera prise en compte comme faisant partie du seuil. De plus, si les seuils sont dépassés, le seuil CRITICAL prévaudra sur WARNING.

Seuils de texte - Cas d'étude 2

Un module peut retourner comme donnée recueillie quelque de ces chaines de caractères (string) :

  • OK.
  • ERROR connection fail.
  • BUSY too many devices.

En utilisant des expressions régulières dans le champs Str. des paramètres Warning Status et Critical Status, comme dans l'image, vous pouvez définir des seuils d'alerte.

threshold4.jpg

Faisiez attention aux expressions régulières parce qu'il différencient entre minuscules et majuscules, elles sont case sensitive.

Avec cette configuration, le module aura le statut WARNING lorsque les données contiennent la chaîne « BUSY » et son statut sera CRITICAL lorsque les données contiennent la chaîne « ERROR ».

Supervision dynamique (seuils automatiques)

La supervision dynamique consiste en l'ajustement dynamique et automatique des seuils d'état des modules de manière intelligente et prédictive. La méthode de travail consiste à collecter les valeurs d'une période donnée et à calculer une moyenne et un écart-type, qui sont utilisés pour établir les seuils correspondants au niveau du module.

Paramètres possibles

dynamic1.jpg

  • Dynamic Threshold Interval : Intervalle de temps qui sera considéré pour effectuer le calcul des seuils. Si nous choisissons 1 mois, le système prendra toutes les données existantes du dernier mois et construira les seuils en fonction de ces données et des seuils avec des valuers au dessus de la moyenne seront établies.
  • Dynamic Threshold Max. : Valeur maximale du seuil dynamique critique, si vous décidez d'établir un pourcentage pour ça. Par exemple : si les valeurs moyennes sont autour de 60 et que le seuil critique a été établi à partir de la valeur 80, si nous établissons la valeur Dynamic threshold Max : 10, nous allons augmenter ce seuil critique de 10%, le laissant à 88.
  • Dynamic Threshold Two Tailed : (désactivé par défaut), ils sont des intervalles de seuils dynamiques, si cette option est activé, le système de seuils dynamiques aussi établira les seuils sous la moyenne.
  • Dynamic Threshold Min. : Il permet de réduire la limite inférieure du pourcentage que nous indiquons. Par exemple, si les valeurs moyennes sont autour de 60 et que le seuil critique inférieur a été fixé à 40, si nous fixons la valeur Dynamic Threshold Min: 10, nous réduirons ce seuil critique de 10%, le laissant à 36.
Cas pratique

Dans l'exemple suivant, la valeur moyenne calculée est à la hauteur de la ligne rouge (environ 30) :

thresh1.jpg

Lors de l'activation des seuils dynamiques, le seuil supérieur (env. 45 et plus) a été réglé de cette manière :

thresh2.jpg

Nous avons activé le paramètre Dynamic Threshold Two Tailed, de sorte qu'un seuil critique a également été fixé en dessous des valeurs moyennes (environ 15 et en dessous) :

thresh3.jpg

Nous avons maintenant réglé les paramètres Dynamic Threshold Min. et Dynamic Threshold Max. sur 20 et 30 respectivement, de sorte que les seuils ont été ouverts, étant légèrement plus permissifs :

thresh4.jpg

Cas pratique 2

Nous partons d'un module de latence web. La configuration de base que nous avons utilisée tient compte d'un intervalle d'une semaine :

dynamic1.jpg

Lors de l'enregistrement des modifications, après avoir lancé pandora_db, les seuils ont été définis de cette façon :

dynamic2.jpg

Le module passe donc à l'état warning lorsque la latence est supérieure à 0'33 secondes, et à l'état critical lorsqu'elle est supérieure à 0'37 secondes. Le graphique le montre comme suit :

dynamic3.jpg

Il a été considéré que le seuil est quelque peu permissif, c'est pourquoi il a été décidé d'utiliser le paramètre Dynamic Threshold Min. pour réduire les seuils minimaux. Comme dans ce cas, le seuil n'a pas de valeurs maximales car toute valeur supérieure à une certaine valeur sera considérée comme incorrecte, nous n'utiliserons pas Dynamic Threshold Max.. La modification apportée est la suivante :

dynamic4.jpg

Après l'application des changements et l'exécution de pandora_db, les seuils sont fixés comme suit :

dynamic5.jpg

Et le graphique ressemblera à ceci :

dynamic6.jpg

Cas pratique 3

Dans cet exemple nous supervisons la temperature d'un salle de contrôle ou un CPD. La graphique représente les valeurs avec peu de variation :

dynamic7.jpg

Dans cette situation, il est fondamentale que la température soit estable dans un intervalle précis, donc on utilisera le paramètre Dynamic Threshold Two Tailed pour délimiter les seuils sous et au dessus. La configuration est la suivante :

dynamic8.jpg

Les seuils générés automatiquement sont les suivants :

dynamic9.jpg

Las graphique les montre ainsi :

dynamic10.jpg

DeAinsi ils seront considérés normales tous les valeurs entre 23'10 et 26'0, puisque c'est la température acceptable dans l'environnement à superviser. Si vous en avez besoin, vous pourriez utiliser les paramètres Dynamic Threshold Min. et Dynamic Threshold Max. une autre fois pour établir les seuils.

Paramètres de configuration additionnels

Il y a aussi plusieurs paramètres de configuration supplémentaires dans le fichier pandora_server.conf.

  • dynamic_updates : Ce paramètre détermine combien de fois les seuils sont recalculés pendant la période définie dans Intervalle seuil dynamique. Si nous configurons l'intervalle de seuil dynamique avec une valeur de 1 semaine, par défaut les données sont collectées à partir d'une semaine en arrière et le calcul est fait une seule fois, en répétant le processus après une semaine. Si nous modifions le paramètre dynamic_updates nous pourrions augmenter cette fréquence. Par exemple, si vous configurez le paramètre avec une valeur de 3, les seuils seront recalculés jusqu'à trois fois au cours d'une semaine (ou la période que nous avons configurée dans Dynamic Threshold Interval) Sa valeur par défaut est 5.
  • Dynamic_warning : différence entre le seuils warning et critical, en pourcentage. Sa valeur par défaut est 25.
  • dynamic_constant : détermine l'écart de la moyenne qui sera utilisée pour établir les seuils ; des valeurs plus élevées éloignent les seuils des valeurs moyennes. Sa valeur par défaut est 10.

Paramètres communs

  • Using module component : Lors de l'utilisation d'un composant de module, les paramètres nécessaires seront remplis automatiquement pour effectuer la surveillance. Ce token apparaît dans tous les types de modules, à l'exception des modules de prédiction.
  • Dynamic threshold interval : Token de supervision dynamique qui sera expliqué dans une section ultérieure.
  • Warning/Critical status : token pour la surveillance de l'état qui sera expliqué dans une section ultérieure.

  • Seuil Flip-Flop : connu sous le nom de Flip-Flop (FF), il est un phénomène courant dans la supervision, quand une valeur oscille fréquemment entre des valeurs alternatives (MAL/BIEN), ce qui la rend difficile à interpréter. Dans ce cas, on utilise généralement un « seuil », de sorte que pour considérer que quelque chose a changé d'état, il doit « rester » plus de X intervalles consécutifs dans un état non modifié. FF Threshold est utilisé pour « filtrer » les changements continués d'état dans la génération d'événements / états : ainsi Pandora FMS « sait » qu'un état n'est pas considéré comme changé jusqu'à ce que l'élément soit au moins X fois sur le même état après avoir changé son état original.

Intervalles communes avancées

  • Intervalle : Période dans laquelle le module doit renvoyer les données. Si un module passe plus de deux intervalles sans recevoir de données, il entrera dans un état inconnu.
    • Dans le cas des modules distants : Il s'agit de la période pendant laquelle le contrôle à distance est effectué.
    • Dans le cas des modules de données: Il s'agit d'une valeur numérique qui représente X fois l'intervalle d'agent défini, effectuant le contrôle local pendant cette période.
  • Unit : Election de l'unité des données reçues par le module, par défaut désactivé (none). Valeurs disponibles :
    • Timeticks.
    • Bytes.
    • Entries.
    • Files.
    • Hits.
    • Sessions.
    • Users.
    • ºC.
    • ºF.
  • Post process : Paramètre par lequel les données reçues par le module peuvent être converties. Par défaut, il est désactivé avec la valeur 0. Valeurs disponibles :
    • Secondes à mois
    • Secondes à semaines
    • Secondes à jours
    • Secondes à minutes
    • Octets à Gigaoctets
    • Octets à Mégaoctets
    • Octets à Kilo-octets
    • Durée en semaines
    • Timeticks à jours
  • FF Interval : Si le seuil FlipFlop est activé et qu'il y a un changement d'état, l'intervalle du module sera modifié pour la prochaine exécution.
  • FlipFlop timeout : Temps d'attente pour les modules asynchrones. Pour qu'un changement d'état par bascule soit efficace, des données consécutives égales doivent être reçues dans l'intervalle spécifié.
  • Silent : Le module continuera à recevoir des informations, mais aucun type d'événement ou d'alerte ne sera généré.
  • Cascade Protection Services : Paramètre par lequel la génération d'événements et d'alertes passerait au service auquel il appartient, si cette fonctionnalité est activée.

Vous pouvez spécifier des périodes de temps dans lesquels le module sera exécuté ; il a la nomenclature : minute, heure, jour du mois, mois, jour de la semaine et il y a de différentes possibilités :

  • Cron from → Il n'y a aucune restriction de surveillance (par défaut), il a Any établi par défaut dans tous les champs.
  • Cron from → valeur spécifique et Cron to → tous dans Any : il sera exécuté seulement lorsqu'il coincide avec le numéro établi. Exemple : 15 20 * * *, fonctionnera tous les jours à 20:15
  • Cron from → valeur spécifique et Cron to → valeur spécifique : il sera exécuté pendant l'intervalle. Exemple : 5-10 * * * * , fonctionne toutes les heures entre les minutes 5 et 10.
  • Macros personnalisées : N'importe quel nombre de macros de module peut être défini. Le format recommandé pour les noms de macros est le suivant :
macronom_de_macronom

Par exemple :

     _technology_
    _modulepriority_
    _contactperson_

Ces macros peuvent être utilisées dans les alertes de module et son particulièrement utiles dans la supervision WUX et la supervision utilisateur. Si le module est un type d'analyse de module Web :

Les macros dynamiques auront un format spécial commençant par @ et auront ces substitutions possibles :

   @DATE_FORMAT (date/heure actuelle avec format défini par l'utilisateur)
   @DATE_FORMAT_nh (heures)
   @DATE_FORMAT_nm (minutes)
   @DATE_FORMAT_nd (jours)
   @DATE_FORMAT_ns (secondes)
   @DATE_FORMAT_nM (mois)
   @DATE_FORMAT_nY (années)

Où « n » peut être un nombre sans signe positif ou négatif.

Tags

Les tags sont des étiquettes associées à chaque module qui seront propagées aux événements générés par ce module et peuvent être utilisées dans les alertes d'événements de ce module. Les tags sont utiles car ils permettent de les utiliser comme filtres dans les rapports, les vues d'événements et même d'avoir des vues spécifiques pour eux. Les informations complémentaires du tag (URL, email, téléphone) peuvent être utilisées dans les alertes, car elles sont disponibles sous forme de macro.

Pour créer ou modifier un tag, cliquez sur Module tags :

Le tag permet de définir un nom, une description et éventuellement une URL complète, email ou téléphone associé à ce tag. Il est à noter que vous pouvez associer un ou plusieurs tags à chaque module. Pour ce faire, ils doivent d'abord être créés comme décrit ci-dessus. Une fois créés, ils seront disponibles pour être assignés à chaque module.

Dans les options avancées d'un module, les tags disponibles seront affichées dans la colonne de gauche et dans la colonne de droite les tags déjà associées au module :

Les tags peuvent également être utilisées pour accorder des permissions d'accès spécifiques à un module, de sorte qu'un utilisateur ne peut accéder qu'à un seul module de l'agent, sans avoir accès au reste des modules. Ceci peut être vu dans la section profil des utilisateurs dans gestion et administration.

Librairie de modules

Disponible à partir de la version 744. Pour y accéder depuis le menu, vous devrez avoir Agent Read (AR) permis.

Les neuf catégories les plus importantes sont affichées, si vous cliquez View all categories (voir toutes les catégories) vous y trouverez le reste :

Chaque catégorie contient les modules disponibles avec une petite description que vous pouvez élargir en cliquant More details (Plus de détails).

Note : Les liens de téléchargement des modules Enterprise de Pandora FMS seulement seront visibles dans ces cas :

  • L'utilisateur et le mot de pass que vous configurez dans le setup doivent coïncider avec celui du support d'Integria IMS.
  • La version de Pandora FMS est Enterprise.
  • L'utilisateur Pandora FMS a permis AW.

Pour plus d'informations sur comment accéder à la librairie, visitez la section de la Configuration de la console.

Retour à l'index de documentation du Pandora FMS