Pandora: Documentation fr: Glossaire termes

From Pandora FMS Wiki
Jump to: navigation, search

1 Glossaire des termes de Pandora FMS

Lorsque vous commencez à travailler avec Pandora FMS, il est important de définir clairement certains termes traités. Étant donné que différents systèmes de surveillance utilisent leurs propres termes pour faire référence à des concepts similaires, il est important que chacun d'eux soit clair afin d'éviter toute confusion ultérieure. Le présent glossaire vise à unifier et à définir en détail toutes les définitions des termes couramment utilisés dans Pandora FMS.

1.1 Agent

Un agent dans Pandora FMS est une entité organisationnelle, qui est généralement une machine, un système ou un hôte (un équipement), qui contient des informations provenant de différentes vérifications appelées modules et qui appartient à un seul groupe. Il peut être lié à d'autres agents par le biais d'une relation de parenté (père-fils).

1.2 Agent logiciel

Il fait référence au service installé sur les ordinateurs pour collecter des informations locales. Il peut être installé sur tous les types de systèmes : Windows, UNIX, etc. Il continue de fonctionner dans le système sur lequel il est installé pour collecter et envoyer de temps en temps (appelé intervalle ) des informations. L'agent logiciel génère un fichier de données au format XML qui est envoyé au serveur Pandora FMS via le réseau, généralement à l'aide du protocole Tentacle.

1.3 Module

Un module est une entité d'information atomique qui stocke des valeurs numériques ou alphanumériques ou de texte. Chaque module ne stocke que les données d'un contrôle individuel (UCT, RAM, trafic ...). Les modules sont contenus dans les agents et toujours associés à un seul agent. Un agent peut contenir plusieurs modules.

1.4 Serveur distant

Serveur mis en réseau et qui n'est pas le serveur local.

1.5 Serveur

Le serveur Pandora FMS est celui qui traite les informations, collectées de différentes manières. Il exécute également des alertes, applique des stratégies et envoie des informations à la base de données. Le serveur Pandora FMS contient également différents composants qui remplissent leurs propres fonctions. certains d'entre eux sont le serveur réseau, le serveur SNMP, le serveur de données ... Tous ces composants font partie du serveur Pandora FMS et peuvent être activés ou désactivés en fonction des besoins.

1.6 Console

La console Web ou console Pandora FMS est l’interface qui permet de gérer Pandora FMS via le navigateur.

1.7 Métaconsole

La Métaconsole est un portail Web sur lequel vous pouvez visualiser, synchroniser et gérer de manière unifiée différents systèmes de surveillance Pandora FMS. De cette manière, la gestion des données provenant de différents environnements de surveillance sera effectuée de manière centralisée à partir de ce point hiérarchiquement supérieur.

1.8 Groupe

Ensembles contenant des agents, utilisés pour filtrer et contrôler la visibilité et les autorisations. Ils travaillent en étroite collaboration avec les profils utilisateur et, en se combinant, ils créent des règles qui déterminent quels éléments de la console un utilisateur peut voir ou non. Les groupes peuvent contenir d'autres groupes.

1.9 Profil

Il définit les autorisations sur les différentes opérations possibles dans Pandora FMS : voir un agent, modifier un agent, allouer des alertes, définir des rapports, gérer la base de données, etc. Ils sont associés aux utilisateurs de certains groupes.

1.10 ACL

ACL est l'acronyme anglais de "Access Control List" ou "Listes de contrôle d'accès", qui, dans Pandora FMS, sont définis en attribuant à un utilisateur un profil sur un groupe. Ils déterminent les autorisations des utilisateurs.

1.11 Moniteur

Module avec un état alloué.

1.12 Fichiers de données / XML de données

Fichiers de données générés par les agents logiciels Pandora FMS. Outre les informations sur les modules de l'agent, il contient des informations sur l'agent lui-même (version, système d'exploitation, etc.).

1.13 Évènement

Un événement est tout événement qui se produit dans les systèmes supervisés. Il affiche des informations allant de tout changement d'état d'un module, des alertes envoyées ou récupérées, aux redémarrages du système ou aux événements personnalisés.

1.14 Alerte

Exécution automatique en fonction des circonstances. Il peut avoir différentes actions associées et deux états possibles: déclenché ou non. Les alertes dans Pandora FMS sont responsables de l'exécution automatique d'actions telles que l'envoi d'un e-mail de notification ou d'un SMS. Il consiste en un modèle + action + commande.

1.15 Modèle d'alerte

C'est l'un des trois composants des alertes. Spécifie les conditions de déclenchement de l'alerte, qui peuvent dépendre de la valeur ou de l'état d'un module, ainsi que d'autres détails, tels que le nombre maximal de déclenchements dans un intervalle donné ou une plage horaire de fonctionnement.

1.16 Action

Exécution qui a lieu lorsqu'une alerte est déclenchée. Ils sont paramétrables via une série de champs, y compris des informations spécifiques sur les circonstances dans lesquelles l'alerte a été déclenchée. Il est possible d'exécuter plusieurs actions pour une seule alerte.

1.17 Commande

Exécution au niveau du système effectuée par le serveur lorsqu'une alerte est déclenchée. Des commandes externes ou des scripts personnalisés peuvent être utilisés pour développer les possibilités existantes.

1.18 Shell ou ligne de commande

Interface qui permet d’introduire des commandes sur une machine à l’aide du clavier.

1.19 Paquet

Un paquet contient un programme ou un ensemble de programmes empaquetés dans un certain format, prêt à être installé dans un système d'exploitation et une version donnés. Par exemple, un package RPM pour OpenSUSE Linux.

1.20 Tarball

Comme un paquet, il contient un programme ou un ensemble de programmes empaquetés au format TAR, mais contrairement à ce qu’il contient, il ne contient aucune information sur la manière de l’installer et ne sont en principe pas spécifiques à un système d’exploitation spécifique.

1.21 SVN / Subversion / Référentiel de code

C'est un système de contrôle de version qui stocke un référentiel avec les différentes versions des fichiers qui composent un projet tout au long de sa vie. L'ensemble de fichiers à un moment donné s'appelle révision, de sorte que deux personnes ayant la même révision du projet auront deux copies identiques des mêmes fichiers.

1.22 Base de données

C'est un ensemble de données appartenant au même contexte et systématiquement stockées pour une utilisation ultérieure. Pandora FMS utilise des bases de données relationnelles, dans lesquelles l'emplacement et la manière dont les données sont stockées sont sans pertinence et sont accessibles via un langage structuré de requêtes standard (SQL).

1.23 Schéma de base de données

Il décrit la structure d'une base de données dans un langage formel. C'est une base de données relationnelle, le schéma définit les tables, les champs de chaque table et les relations entre les champs et les tables.

1.24 Tentacle

C'est le protocole de transfert de données utilisé par les agents logiciels et le « serveur satellite » pour envoyer des données au serveur Pandora FMS. Tentacle est multi-plateforme et est conçu pour être un protocole sécurisé et facile à utiliser. Il utilise le port 41121 par défaut (alloué par IANA).

1.25 État

Normalement, il s'agit de l'état d'un module. Il vous donne des informations sur le module à l'heure actuelle. L'état d'un agent est donné par l'état le plus sévère parmi ses modules dans son ensemble. Si vous avez 5 modules et qu'un est en mode CRITICAL, deux en WARNING et deux en NORMAL, l'état du module sera CRITICAL. La même chose s'applique à l'état d'un groupe.

1.26 État CRITICAL, WARNING

NORMAL, WARNING et CRITICAL sont les trois états possibles d’un module. Les états WARNING et CRITICAL indiquent généralement des conditions d'erreur de gravité différente. Pandora FMS permet de définir indépendamment différents seuils pour les états WARNING et CRITICAL de chaque module.

1.27 État UNKNOWN

Nous disons qu'un module est dans un état inconnu ou UNKNOWN s'il ne reçoit pas de données pendant plus du double de son intervalle. C'est-à-dire qu'un module qui envoie des données toutes les 5 minutes est marqué comme inconnu après 10 minutes sans recevoir de données.

1.28 Seuil d'alerte (Alert threshold)

Il s'agit de l'intervalle de temps pendant lequel les restrictions définies lors de la configuration du modèle d'alerte s'appliquent. Par exemple, un modèle d'alerte qui définit un seuil de 10 minutes et un nombre maximal d'alertes de 5 garantit que, dans un intervalle de 10 minutes, l'alerte ne se déclenchera pas plus de cinq fois. De plus, à moins que la récupération ne soit configurée, l'alerte restera déclenchée jusqu'à l'expiration de cet intervalle de temps.

1.29 Faux positif / négatif

Quand une vérification renvoie une erreur et qu'elle ne s'est pas produite, on parle de faux positif. Lorsque cela ne renvoie aucune erreur et que cela s'est produit, nous parlons d'un faux négatif.

Par exemple, nous avons un module qui renvoie 1 lorsque le serveur est disponible. Nous aurions un faux négatif lorsque le serveur n'est pas disponible et que le module renvoie 1; et nous aurions un faux positif lorsque le serveur est disponible et que le module renvoie 0.

1.30 Protection Flip / Flop

La protection flip flop d'un module indique le nombre de fois que la condition de changement d'état doit être spécifiée pour que le changement d'état se produise. Cela permet de protéger un module contre les faux positifs / négatifs. Par exemple, si vous savez qu'un module renvoie des faux positifs mais qu'il n'y a jamais plus de deux suivis, vous pouvez définir la protection de flip flop sur trois pour empêcher les faux positifs de produire des modifications d'état.

1.31 Surveillance synchrone

Nous disons qu'un module est synchrone lorsqu'il renvoie des données à intervalles réguliers. Par exemple, une mesure de température toutes les 5 minutes.

1.32 Surveillance asynchrone

Nous disons qu'un module est asynchrone lorsqu'il renvoie des données en fonction de modifications ou d'événements susceptibles de se produire ou non. Par exemple, recherchez une chaîne dans un fichier journal. Si la chaîne n'est pas trouvée, le module ne renvoie pas de données. Un autre exemple - très fréquent - est celui des déroutements SNMP, qui ne sont générées que lorsqu'une erreur survient (par exemple, une panne d'alimentation).

Retour à l'index de documentation du Pandora FMS