Détails d'ingénierie Pandora FMS

Dans la section suivante, certains des principes de conception et des particularités de Pandora FMS seront expliqués.

Les premières versions de Pandora FMS, de 0.83 à 1.1, étaient basées sur une idée très simple : un donnée, une insertion de la base de données. Cela a permis au logiciel d'effectuer rapidement des recherches faciles, des insertions et d'autres opérations

Outre tous les avantages de ce développement, il y avait un inconvénient : l'extensibilité. Ce système a une limite définie sur le nombre maximal de modules qu'il peut prendre en charge, et avec une certaine quantité de données (> 5 millions d'éléments), les performances etaient affectées.

Les solutions basées sur un cluster MySQL, en revanche, ne sont pas faciles : bien qu'elles permettent de gérer une charge plus importante, elles entraînent des problèmes et des difficultés supplémentaires, et n'offrent pas non plus de solution à long terme au problème de performances avec une grande quantité de données.

Actuellement, Pandora FMS implémente un compactage des données en temps réel pour chaque insert, en plus d'effectuer une compression des données basée sur l'interpolation. D'autre part, la tâche de maintenance vous permet d'effacer automatiquement les données qui dépassent un certain âge.

Le système de traitement Pandora FMS ne stocke que les données « nouveaux » : si une valeur en double pénètre dans le système, elle ne sera pas stockée dans la base de données. C'est très utile pour garder la base de données réduite, et cela fonctionne pour tous les types de module Pandora FMS (numérique, incrémental, booléen et chaîne de texte). Par exemple, dans les données de type * booléen *, l'indice de compactage est très élevé car ceux sont des données qui ne changent guère. Cependant, les éléments « index » sont stockés toutes les 24 heures, de sorte qu'il existe un minimum d'informations qui servent de référence lors du compactage des informations.

Ce mécanisme résout une partie du problème d'extensibilité, réduisant considérablement l'utilisation de la base de données (entre 40 et 70 pour cent), mais il existe d'autres moyens d'augmenter l'extensibilité.

Pandora FMS permet la désintégration totale des composants, de sorte que la charge de traitement des fichiers de données et l'exécution des modules réseau sur différents serveurs puissent être équilibrées. Il est possible d'avoir plusieurs serveurs Pandora FMS (réseau, serveurs de données ou SNMP), des consoles Web Pandora FMS, ainsi qu'une base de données ou un grappe d'hautes performances (avec MySQL5), tout sur des serveurs indépendants.

Les changements impliquent des changements majeurs lors de la lecture et de l'interprétation des données. Dans les dernières versions de Pandora FMS, le moteur graphique a été entièrement repensé pour pouvoir représenter rapidement les données avec le nouveau modèle de stockage de données.

Les mécanismes de compactage ont certaines implications lors de la lecture et de l'interprétation graphique des données. Imaginez qu'un agent ne puisse pas communiquer avec Pandora FMS, donc le serveur Pandora FMS ne reçoit pas de données de celui-ci, et il y aura une période pendant laquelle le serveur ne disposera pas d'informations sur les modules de cet agent. Si vous accédez au graphique de l'un de ces modules, l'intervalle « sans données » sera représenté comme s'il n'y avait pas de changement, une ligne horizontale. Pandora FMS, s'il ne reçoit pas de nouvelles valeurs, supposera qu'il n'y en a pas, et tout apparaîtra tel qu'il était dans la dernière notification.

Pour voir un exemple graphique, cette image montre les changements pour chaque donnée, reçue toutes les 180 secondes.

Ce serait le graphique équivalent pour les mêmes données, à l'exception d'un échec de connexion, de 05h55 à 15h29 environ.

Dans Pandora FMS 1.3, un nouveau graphique général a été introduit pour l'agent qui montre sa connectivité et qui reflète le taux d'accès des modules à l'agent. Ce graphique complète les autres qui ont montré quand l'agent avait une activité et recevait des données.

Si vous avez des pics (faibles) dans ce graphique, vous pouvez avoir des problèmes ou des connexions lentes dans la connectivité de l'agent Pandora FMS au serveur Pandora FMS, ou des problèmes de connectivité du serveur réseau.

Dans la version 5 du SGF Pandora, il a été introduit la possibilité de croiser les données des événements de type « module inconnu » avec les graphiques a été introduite, pour montrer sur le graphique la partie de la série de données qui est dans une condition inconnue, complétant le graphique pour une meilleure interprétation, par exemple :

Dans la version 7 NG 759 il y avait un menu de configuration graphique qui permetait d'ajouter des percentils, des données en temps réel, lorsqu'il y avait des événements et/ou alertes, outre d'autres options.

Tout au long des mises à jour logicielles, des améliorations ont été apportées au modèle relationnel de la base de données Pandora FMS. L'un des changements introduits a été l'indexation des informations sur la base de différents types de modules. De cette façon, Pandora FMS peut accéder aux informations beaucoup plus rapidement, car elles sont réparties dans différentes graphiques.

Il est possible de partitionner les tables (par horodatage) pour améliorer encore les performances d'accès aux historiques de données.

De plus, des facteurs tels que la représentation numérique des horodatages (en _timestamp_ au format UNIX), accélèrent les recherches de plages de dates, leur comparaison, etc. Ce travail a permis une amélioration considérable des temps de recherche et des insertions.

Vous trouverez ci-dessous un diagramme ER et une description détaillée des principaux tableaux de la base de données Pandora FMS.

• taddress : Il contient des adresses d'agent supplémentaires.
• taddress_agent : Adresses associées à un agent (rel. taddress/tagent).
• tagent : Il contient les informations des agents Pandora FMS.
  • id_agent : Identifiant unique de l'agent.
  • nom : Nom de l'agent (sensible à la casse).
  • adresse : Adresse de l'agent. Des adresses supplémentaires peuvent être attribuées via la table des adresses.
  • commentaires: Texte libre.
  • id_groupe : Identifiant du groupe auquel appartient l'agent (réf. tgroupe).
  • dernier_contacte : Date du dernier contact avec l'agent, via un agent logiciel ou un module distant.
  • mode : Mode de l'agent en exécution, 0 normal, 1 apprentissage.
  • intervalle : Intervalle d'exécution de l'agent. En fonction de cet intervalle, l'agent sera marqué hors limites.
  • id_os: Identifiant du système d'exploitation de l'agent (réf. tconfig_os).
  • os_version: Version du système d'exploitation (texte libre).
  • agent_version: Version de l'agent (texte libre). Mis à jour par les agents logiciels.
  • dernier_contact_distant: Dernière date de contact reçue de l'agent. Dans le cas des agents logiciels et contrairement à dernier_contact, la date est envoyée par l'agent lui-même.
  • disabled: État de l'agent, activé (0) ou désactivé (1).
  • remote: Agents avec (1) ou sans configuration à distance (0).
  • id_parent: Identifiant du parent de l'agent (réf. tagent).
  • custom_id: Identificateur d'agent personnalisé. Utile pour interagir avec d'autres outils.
  • server_name: Nom du serveur auquel l'agent est affecté.
  • cascade_protection: Protection en cascade. Désactivé à 0. Étant 1 empêche le déclenchement des alertes associées à l'agent si une alerte critique du parent de l'agent a été déclenchée. Pour plus d'informations, consultez le chapitre d'alertes.
  • safe_mode_module: ID du module (du même agent) qui utilise le safe operation mode (tous les autres modules de l'agent sont désactivés si ce module est dans un état critique).
• tagent_données: Données reçues de chaque module. Si pour le même module, la dernière donnée reçue est égale à la précédente, elle n'est pas insérée (mais tagente_estado est mis à jour). Les données de type incrémentiel et de chaîne sont enregistrées dans différentes tables.
• tagent_données_inc: Données de type incrémentiel.
• tagent_données_chaîne: Données de type chaîne.
• tagent_état: Informations sur l'état actuel de chaque module.
  • id_agent_état: Identificateur.
  • id_agent_module: Identifiant du module (ref. tagent_module).
  • données: Valeur des dernières données reçues.
  • timestamp: Date des dernières données reçues (peut provenir de l'agent).
  • état: État du module: 0 NORMAL, 1 CRITICAL, 2 WARNING, 3 UNKNOWN.
  • id_agent: Identifiant de l'agent associé au module (ref. tagent).
  • last_try: Date de la dernière exécution réussie du module.
  • utimestamp: Date de la dernière exécution du module au format UNIX.
  • current_interval: Intervalle d'exécution du module en secondes.
  • running_by: Nom du serveur qui a exécuté le module.
  • last_execution_try: Date de la dernière tentative d'exécution du module. L'exécution peut échouer.
  • status_changes: Nombre de changements d'état survenus. Il est utilisé pour éviter des changements d'état continus. Pour en savoir plus, accédez au Operación.
  • last_status: État précédent du module.
• tagent_module: Configuration des modules.
  • id_agent_module: Identifiant unique du module.
  • id_agent: Identifiant de l'agent associé au module (ref. tagent).
  • id_type_module: Type de module (réf. type_module).
  • description: Texte libre.
  • nom : Nom du module.
  • max: Valeur maximale du module. Les données supérieures à cette valeur seront considérées comme non valides.
  • min: Valeur minimum du module. Les données inferieures à cette valeur seront considérées comme non valides.
  • module_interval: Intervalle d'exécution du module en secondes.
  • tcp_port: Port TCP de destination dans les modules réseau et le plugin. Nom de la colonne à lire dans les modules WMI.
  • tcp_send: Données à envoyer dans les modules réseau. Namespace dans les modules WMI.
  • tcp_rcv: Réponse attendue dans les modules réseau.
  • snmp_community: Communauté SNMP dans les modules réseau. Filtrer dans les modules WMI.
  • snmp_oid: OID dans les modules réseau. Query WQL dans les modules WMI.
  • ip_target: Adresse de destination dans les modules réseau, plugin et WMI.
  • id_module_group: Identifiant du groupe auquel appartient le module (ref. tmodule_group).
  • flag: Flag de l'exécution forcée. En étant 1 le module est exécuté même s'il ne correspond pas par intervalle.
  • id_module: Identifiant des modules qui ne peuvent pas être reconnus par leur module_type_id. 6 pour les modules WMI, 7 pour les modules WEB.
  • disabled: État du module, activé (0) ou désactivé (1).
  • id_export: Identifiant du serveur d'exportation associé au module (ref. tserver).
  • plugin_user: Nom d'utilisateur dans les modules plugin et WMI, user-agent dans les modules Web.
  • plugin_pass: Mot de passe dans les modules plugin et WMI, nombre de tentatives dans les modules Web.
  • plugin_parameter: Paramètres supplémentaires dans les modules plugin, configuration de la tâche Goliath dans les modules Web.
  • id_plugin: Identifiant du plugin associé au module dans les modules plugins (ref. tplugin).
  • post_process: Valeur par laquelle les données du module seront multipliées avant d'être enregistrées.
  • prediction_module: 1 s'il s'agit d'un module de prédiction, 2 s'il est de service, 3 s'il est synthétique, 0 dans tous les autres cas.
  • max_timeout: Temps d'attente en secondes dans les modules plugin.
  • custom_id: Identifiant personnalisé du module. Utile pour interagir avec d'autres outils.
  • history_data: S'il est égal à 0, aucune donnée de module n'est enregistrée dans tagent_données*, seul tagent_état est mis à jour.
  • min_warning: Valeur minimale qui active l'état WARNING.
  • max_warning: Valeur maximale qui active l'état WARNING.
  • min_critical: Valeur minimale qui active l'état CRITICAL.
  • max_critical: Valeur maximale qui active l'état CRITICAL.
  • min_ff_event: Nombre de fois qu'une condition de changement d'état doit se produire avant qu'un tel changement n'ait lieu. Il est lié à tagent_état.status_changes .
  • delete_pending: S'il vaut 1, le module sera supprimé par le script de maintenance de la base de données pandora_db.pl dans la version Community et pandora_db dans la version Enterprise.
  • custom_integer_1: Lorsque prediction_module = 1 ce champ a l'id du module à partir duquel les données à prédire sont prises. Lorsque prediction_module = 2 ce champ aura l'ID de service affecté au module
  • custom_integer_2: Utilisé par le serveur de prédiction.
  • custom_string_1: Utilisé par le serveur de prédiction.
  • custom_string_2: Utilisé par le serveur de prédiction.
  • custom_string_3: Utilisé par le serveur de prédiction.
• tagent_access: Une nouvelle entrée est insérée chaque fois qu'un agent arrive sur l'un des serveurs, mais jamais plus d'une par minute pour éviter de surcharger la base de données. Il peut être désactivé en définissant agentaccess sur 0 dans le fichier de configuration pandora_server.conf.
• talert_snmp: Configuration des alertes SNMP.
• talert_commands: Commandes pouvant être exécutées à partir d'actions associées à une alerte (par exemple, envoyer du courrier).
• talert_actions: Instance d'une commande associée à une alerte (ex: envoyer un mail à l'administrateur).
• talert_templates: Modèles d'alerte.
  • id: Identificateur unique du modèle.
  • name: Nom du modèle.
  • description: Description.
  • id_alert_action: Identifiant de l'action par défaut associée au modèle.
  • field1: Champ personnalisé 1 (texte libre).
  • field2: Champ personnalisé 2 (texte libre).
  • field3: Champ personnalisé 3 (texte libre).
  • type: Type d'alerte en fonction de la condition de déclenchement ('regex', 'max_min', 'max', 'min', 'equal', 'not_equal', 'warning', 'critical').
  • value: Valeur pour les alertes de type regex (texte libre).
  • matches_value: À 1, il inverse la logique de la condition de déclenchement.
  • max_value: Valeur maximale pour les alertes max_min et max.
  • min_value: Valeur minimale pour les alertes max_min et min.
  • time_threshold: Intervalle de l'alerte.
  • max_alerts: Nombre maximal de fois qu'une alerte sera déclenchée pendant un intervalle.
  • min_alerts: Nombre minimal de fois où la condition de déclenchement doit se produire pendant un intervalle pour que l'alerte se déclenche.
  • time_from: Temps après lequel l'alerte est active.
  • time_to: Temps jusqu'auquel l'alerte est active.
  • monday: À 1, l'alerte est active le lundi.
  • tuesday: À 1, l'alerte est active le mardi.
  • wednesday: À 1, l'alerte est active le mercredi.
  • thursday: À 1, l'alerte est active le jeudi.
  • friday: À 1, l'alerte est active le vendredi.
  • saturday: À 1, l'alerte est active le samedi.
  • sunday: À 1, l'alerte est active le dimanche.
  • recovery_notify: À 1, il active la récupération d'alertes.
  • field2_recovery: Champ personnalisé 2 pour la récupération des alertes (texte libre).
  • field3_recovery: Champ personnalisé 3 pour la récupération des alertes (texte libre).
  • priority: Priorité de l'alerte: 0 Maintenance, 1 Informational, 2 Normal, 3 Warning, 4 Critical.
  • id_group: Identifiant du groupe auquel appartient le modèle (ref. tgroupe).
• talert_template_modules: Instance d'un modèle d'alerte associé à un module.
  • id: Identifiant unique de l'alerte.
  • id_agent_module: Identifiant du modèle associé à l'alerte (ref. tagent_module).
  • id_alert_template: Identifiant du modèle associé à l'alerte (ref. talert_templates).
  • internal_counter: Nombre de fois où la condition de déclenchement d'alerte s'est produite.
  • last_fired: Dernière fois que l'alerte a été déclenchée (heure UNIX).
  • last_reference: Début de l'intervalle en cours (heure UNIX).
  • times_fired: Nombre de fois que l'alerte a été déclenchée (elle peut être différente de internal_counter).
  • disabled: À 1, l'alerte est désactivée.
  • priority: Priorité de l'alerte: 0 Maintenance, 1 Informational, 2 Normal, 3 Warning, 4 Critical.
  • force_execution: À 1, il exécutera l'action d'alerte même si elle n'a pas été déclenchée. Il est utilisé pour l'exécution manuelle des alertes.
• talert_template_module_actions: Instance d'une action associée à une alerte (réf. talert_template_modules).
• talert_compound: Alertes composites, les colonnes sont similaires à celles de talert_templates.
• talert_compound_elements: Alertes simples associées à une alerte composite, chacune avec son opération logique correspondante (réf. talert_template_modules).
• talert_compound_actions: Actions associées à une alerte composite (ref. talert_compound).
• tattachment: Pièces jointes associées à un incident.
• tconfig: Configuration de la console.
• tconfig_os: Systèmes d'exploitation reconnus dans Pandora FMS.
• tévénement: Entrées d'événements. Les valeurs de criticité sont les mêmes que pour les alertes.
• tgroupe: Groupes définis dans Pandora FMS.
• tincidence: Entrées d'incidences.
• tlanguage: Langues reconnues dans Pandora FMS.
• tlink: Liens affichés en bas du menu de la console.
• tnetwork_component: Composants réseau. Ce sont des modules associés à un profil réseau utilisé par le Recon Server. Plus tard, ils mèneront à une entrée dans tagent_module, afin que les colonnes des deux tables soient similaires.
• tnetwork_component_group: Groupes pour classer les composants réseau.
• tnetwork_profile: Profil réseau. Regroupement des composants réseau qui seront affectés aux tâches de reconnaissance du Recon Server. Les composants réseau associés au profil entraîneront des modules dans les agents créés.
• tnetwork_profile_component: Composants réseau associés à un profil réseau (rel. tnetwork_component/tnetwork_profile).
• tnote: Notes associées à un incidence.
• tsource: Origines possibles d'un incidence.
• tprofil: Profils utilisateur définis dans la console.
• trecon_task: Tâches de reconnaissance du Recon Server.
• tserver: Serveurs enregistrés
• tsession: Informations sur les actions effectuées pendant la session d'un utilisateur pour les journaux d'administration et de statistiques.
• ttype_module: Types de modules selon leur origine et type de données.
• ttrap: Déroutements SNMP reçues par la console SNMP.
• tutilisateur: Utilisateurs enregistrés dans la console.
• tutilisateur_profil: Profils associés à un utilisateur (rel. tutilisateur/tprofil).
• tnews: Nouvelles affichées sur la console.
• tgraph: Graphiques personnalisés créés dans la console.
• tgraph_source: Modules associés à un graphe (rel. tgraph/tagent_module).
• treport: Rapports personnalisés créés dans la console.
• treport_content: Éléments associés à un rapport.
• treport_content_sla_combined: Composants d'un élément SLA associé à un rapport.
• treport_content_sla_combined: Composants d'un élément SLA associé à un rapport.
• tlayout: Cartes personnalisés créés dans la console.
• tlayout_data: Éléments associés à une carte.
• tplugin: Définitions des plugins pour le Plugin Server.
• tmodule: Types de modules (Réseau, Plugin, WMI …).
• tserver_export: Destinations configurées pour Export Server.
• tserver_export_data: Données à exporter, associées à une destination.
• tplanned_downtime: Arrêts programmés.
• tplanned_downtime_agents: Agents associés à un arrêt programmé (rel. tplanned_downtime/tagent).

Comme indiqué ci-dessus, pour éviter de surcharger la base de données, le serveur effectue une compression simple au moment de l'insertion. Une donnée n'est pas stockée dans la base de données sauf si elle est différente de la précédente ou s'il y a une différence de 24 heures entre elles.

Par exemple, en supposant un intervalle d'environ 1 heure, la séquence 0,1,0,0,0,0,0,0,0,1,1,0,0 est stockée dans la base de données sous la forme 0,1,0,1,0. Aucun autre 0 consécutif ne sera enregistré à moins que 24 heures ne se soient écoulées.

Le graphique ci-dessous est tiré des données de l'exemple précédent. Seules les données marquées en rouge ont été insérées dans la base de données.

La compression affecte considérablement les algorithmes de traitement des données, à la fois les mesures et les graphiques, et il est important de garder à l'esprit que les lacunes causées par la compression doivent être comblées.

Compte tenu de tout ce qui précède, pour effectuer des calculs avec les données d'un module avec un intervalle et une date initiale, les étapes suivantes doivent être suivies:

• Recherchez les données précédentes, en dehors de l'intervalle et de la date donnés. S'il existe, il doit être amené au début de l'intervalle. S'il n'existait pas auparavant, il n'y aurait pas de données.

• Recherchez les données suivantes, en dehors de la plage et de la date données jusqu'à un maximum égal à l'intervalle du module. S'il existe, il doit être amené à la fin de l'intervalle. S'il n'existe pas, la dernière valeur disponible doit être étendue jusqu'à la fin de l'intervalle.

• Toutes les données sont parcourues, en tenant compte du fait qu'une donnée est valide jusqu'à ce qu'une autre donnée soit reçue.

Pandora FMS a inclus un système pour compacter les informations dans la base de données. Ce système est orienté vers des scénarios de petite / moyenne taille (250 à 500 agents, <100 000 modules) qui souhaitent disposer d'une information historique complète mais perdent la détails.

La maintenance de la base de données Pandora FMS qui s'exécute toutes les heures, et entre autres tâches de nettoyage, permet le compactage des anciennes données. Ce compactage utilise une interpolation simple et linéaire, ce qui signifie que si, par exemple, vous recevez de 10 000 données en une journée, le processus réduira ces 10 000 points de 1 000 points.

Étant une interpolation, cela entraîne la perte de détails dans ces informations, mais restera suffisamment informatif pour la génération de rapports et de graphiques mensuels et annuels, etc.

Dans les grandes bases de données, ce comportement peut être assez coûteux en termes de performances et doit être désactivé; à la place, il est recommandé d'opter pour le modèle de base de données historique.

La base de données historique est une fonctionnalité Enterprise, utilisée pour stocker toutes les informations passées, qui n'est pas utilisée dans les vues « quotidiennes », telles que les données datant de plus d'un mois. Ces données sont automatiquement migrées vers une base de données différente, qui doit se trouver sur un serveur différent avec un stockage (disque) différent de la base de données principale.

Lorsqu'un graphique ou un rapport contenant d'anciennes données s'affiche, Pandora FMS recherche les premiers jours dans la base de données principale et lorsqu'il atteint le point où ils sont migrés vers la base de données historique, il le recherche. Grâce à cela, les performances sont maximisées même en accumulant une grande quantité d'informations dans le système.

Pour configurer cela, une base de données historique doit être installée manuellement sur un autre serveur (en y important le schéma Pandora FMS, sans données), en plus des autorisations d'installation pour lui permettre d'y accéder depuis le serveur Pandora FMS principal.

Allez dans Setup → Setup → History database et configurez les paramètres pour y accéder à la base de données historique.

La configuration par défaut de Pandora FMS ne transfère pas les données de type chaîne vers la base de données historique. Cependant si cette configuration a été modifiée et que la base de données historique reçoit ce type d'informations, il est essentiel que votre purge soit configurée, sinon elle finira par occuper trop, causant des problèmes majeurs et obtenant un impact négatif sur les performances.

Pour configurer ce paramètre, une requête doit être exécutée directement dans la base de données pour déterminer les jours après lesquels ces informations seront purgées. La table en question est tconfig et le champ string_purge. Si, par exemple, vous vouliez établir 30 jours pour la purge de ce type d'informations, la requête suivante serait exécutée directement sur la base de données historique:

UPDATE tconfig SET value = 30 WHERE token = "string_purge";

La base de données est maintenue par un script nommé pandora_db.pl :

Un bon moyen de vérifier que la maintenance de la base de données s'exécute correctement consiste à exécuter le script de maintenance manuellement :

/usr/share/pandora_server/util/pandora_db.pl /etc/pandora/pandora_server.conf

Ça ne doit signaler aucune erreur. Si une autre instance utilise la base de données, vous pouvez utiliser l'option -f qui force l'exécution ; avec le paramètre -p vous n'effectuez pas de compactage des données. Ceci est particulièrement utile dans les environnements de haute disponibilité (HA) avec une base de données historique, car le script s'assure d'exécuter dans un ordre correct et en mode les étapes nécessaires pour ces composants.

Dans Pandora FMS, les modules peuvent avoir différents états : Inconnu, Normal, Avertissement, Critique ou avec des Alertes déclenchées.

• D'une part, chaque module a dans sa configuration des seuils de Avertissement (WARNING) et Critique (CRITICAL).
  • Ces seuils définissent les valeurs de vos données pour lesquelles ces états seront activés.
  • Si le module fournit des données en dehors de ces seuils, il est considéré comme étant à l'état Normal (NORMAL).
• Chaque module dispose également d'un intervalle de temps qui établira la fréquence à laquelle il obtiendra les données.
  • Cet intervalle sera pris en compte par la console pour collecter les données.
  • Au bout de deux fois l'intervalle du module sans collecter de données, il est considéré que ce module est à l'état Inconnu (UNKNOWN).
• Enfin, si le module a des alertes configurées et que l'une d'entre elles a été déclenchée et n'a pas été validée, le module aura l'état correspondant d' Alerte déclenchée.

Au sein de l'organisation Pandora FMS, certains éléments dépendent d'autres, comme les modules d'un agent ou les agents d'un groupe. Cela peut également être appliqué dans le cas des stratégies Pandora FMS Enterprise, qui ont associés certains agents et certains modules qui sont considérés comme associés à chaque agent.

Cette structure est particulièrement utile pour évaluer les états des modules à l'œil nu. Ceci est réalisé en étendant les états vers le haut dans cette organisation, accordant ainsi d'état aux agents, groupes et politiques.

Un agent sera affiché avec l'état le plus grave de ses modules. À son tour, un groupe aura le pire des états des agents qui lui appartiennent, et c'est le même pour les politiques, qui auront l'état le plus grave de leurs agents affectés.

Ainsi, en voyant un groupe avec un état critique, par exemple, on saura qu'au moins un de ses agents a ce même état. Pour le localiser, un autre niveau doit être abaissé, à celui des agents, pour rétrécir la clôture et trouver le ou les modules provoquant la propagation de cet état critique.

Lorsque nous parlons de l'état le plus grave qui se répand, il faut avoir à l'esprit quels états sont prioritaires par rapport aux autres. Par conséquent, il y a une liste de priorités, étant le premier état qui y apparaît, celui qui a la priorité la plus élevée sur les autres et le dernier celui qui a le moins, n'apparaissant que lorsque tous les éléments l'ont.

1. Alertes déclenchées.
2. État critique.
3. État d'avertissement.
4. État inconnu.
5. État normal.

Nous voyons que lorsqu'un module a des alertes déclenchées, son état est prioritaire sur tout le reste et l'agent auquel il appartient aura cet état et le groupe auquel cet agent appartient à son tour également.

Par contre, pour qu'un groupe, par exemple, ait un état normal, tous ses agents doivent avoir cet état. Ce qui signifie qu'à son tour, tous les modules de ces groupes auront un état normal.

Chacun des états commentés a une couleur assignée pour voir d'un coup d'œil quand un élément ne fonctionne pas sur les cartes du réseau.

État des alertes déclenchées

État critique

État d'avertissement

État inconnu

État normal

Les graphiques sont l'une des implémentations les plus complexes de Pandora FMS, ils extraient des données en temps réel de la base de données et aucun système externe n'est utilisé (comme RRDtool ou similaire).

Il existe plusieurs comportements des graphiques en fonction du type de données source :

• Modules asynchrones. On suppose qu'il n'y a pas de compactage des données. Les données de la base de données sont toutes les échantillons réels des données, il n'y a pas de compactage. Il produit des graphiques beaucoup plus « précis » sans malentendu possible.
• Modules de type chaîne de texte. Ils montrent des graphiques avec le débit de données au fil du temps.
• Modules de données numériques. La plupart des modules signalent ce type de données.
• Modules de données booléens. Ils correspondent à des données numériques sur les moniteurs *PROC: par exemple, vérifications Ping, état de l'interface, etc. La valeur 0 correspond à l'état Critique et la valeur 1 à l'état “ Normal ”.

La compression affecte la façon dont les graphiques sont représentés. Lorsque deux données de la même valeur sont reçues, Pandora FMS n'enregistre pas la dernière. De plus, dans le cas où lors de la representation d'un graphique, il n'a pas de valeur de référence, Pandora FMS recherchera jusqu'à 48 heures dans le temps pour trouver la dernière valeur connue, qu'il prendra comme référence. Si il ne trouvais aucune donnée, le graphique commencerait à 0.

Pour ceux qui sont asynchrones, bien qu'il n'y ait pas de compression, le mécanisme de recherche en arrière se comporterait de la même manière.

Lors de la composition d'un graphique, 50xN échantillons sont prélevés, N étant le facteur de résolution des graphiques (ce paramètre peut être configuré dans la configuration, et par défaut, il est de 3). Par exemple, un moniteur qui renvoie des données toutes les 300 secondes (5 minutes) générera 12 échantillons par heure, 288 (12*24) pendant une journée. Dans le cas d'un graphique d'une journée, les 288 points ne seraient pas vraiment “imprimés”, mais plutôt “compressés” en utilisant seulement 150 (50*3 ) échantillons.

Cela implique qu'une certaine résolution est “perdue”, et plus nous avons d'échantillons, plus elle sera perdue, mais cela peut être évité en créant le graphique avec un intervalle ou un zoom différent.

Dans les graphes normaux, l'interpolation est implémentée de manière simple: si dans un intervalle il y a deux échantillons (ex: dans l'intervalle B de l'exemple), la moyenne sera faite et sa valeur sera representée.

Dans les Graphes booléens, si plusieurs données sont disponibles dans un échantillon (dans ce cas, seuls 0 et 1 peuvent être disponibles), 0 sera affiché. Cela aide visuellement à voir un cas d'échec dans un intervalle, en priorisant le problème sur la situation actuelle.

Dans les deux cas, s'il n'y a pas de données dans un échantillon (parce qu'il est compressé ou parce qu'il manque), la dernière valeur connue de l'intervalle précédent sera utilisée pour l'afficher, comme dans l'intervalle E de l'exemple ci-dessus.

Les graphiques par défaut indiquent la valeur moyenne, maximale et minimale. Puisqu'il peut y avoir plusieurs données dans un échantillon, les données pour une valeur moyenne (avg), maximale ou minimale seront affichées. Plus vous devez interpoler un graphique (plus la période d'affichage est longue et plus il y a de données), plus le degré d'interpolation sera grand et donc il y aura plus de différences entre les valeurs max, min et avg .

Plus la plage du graphique est petite (par exemple, les graphiques d'une heure), il n'y aura pas d'interpolation ou il sera très léger, de sorte que les données seront représentées avec leur résolution “ réelle ” et les trois séries seront identiques.

Retour à l'index de documentation du Pandora FMS