Table des matières

Metaconsole dans les versions antérieures à la NG 756

Comparaison

Si vous connaissiez déjà Pandora FMS avant la version 5.0, vous saurez que le concept de Métaconsole existait déjà.

Dans cette section, nous analyserons les différences de la Métaconsole actuelle avec l'ancienne, les problèmes résolus et les améliorations proposées.

Avant la version 5.0

Avant la version 5.0, une installation normale (Console + Serveur) de Pandora FMS pouvait agir, en même temps comme Métaconsole.

Communication

La communication entre la Métaconsole et les instances était à sens unique. La Métaconsole est connectée aux bases de données des instances et gérait toutes les données en mémoire.

Il ne stockait presque rien dans sa propre base de données.

Synchronisation

La synchronisation était effectuée entre les instances.

Par exemple :

Supposez que vous vouliez configurer des modèles d'alerte pour que toutes les instances en aient.

Vous devez choisir l'une des instances, la configurer, revenir à la Métaconsole et synchroniser les modèles de cette instance avec les autres.

Problèmes

La Métaconsole était très inefficace en raison de son architecture non centralisée. De nombreuses connexions ont été établies avec différentes bases de données et l'expérience utilisateur était trop pauvre.

Les options disponibles étaient insuffisantes pour obtenir le contrôle souhaité des environnements des Instances sans quitter la Métaconsole.

En résumé, la Métaconsole était lente dès qu'elle avait un peu de charge et l'utilisateur était très limité par ses options.

À partir de la version 5.0

La Métaconsole à partir de la version 5.0 est un environnement spécial complètement indépendant et incompatible avec la console.

Communication

La communication entre la Métaconsole et les Instances était bidirectionnel. La Métaconsole se connecte aux bases de données des Instances et les Instances répliquent une partie de leurs données vers la base de données de la Métaconsole.

Autres données telles que les groupes, les modèles d'alerte, les étiquettes, etc. Ils sont stockés dans la Métaconsole.

Synchronisation

La synchronisation est effectuée unidirectionnellement : de la Métaconsole aux Instances.

Par exemple :

Supposez que vous vouliez configurer des modèles d'alerte pour que quelques ou toutes les instances en aient.

Sans quitter la Métaconsole, vous pouvez configurer les modèles et les synchroniser avec les Instances que vous voulez.

Améliorations

La Métaconsole à partir de la version 5.0 est un outil plus centralisé, plus rapide et beaucoup plus flexible que son prédécesseur.

Il comprend de nombreuses autres vues et utilitaires, ainsi que des améliorations de celles qui existaient déjà.

Il ne gère pas toutes les données en mémoire, stockant une partie des informations, améliorant ainsi l'expérience utilisateur.

Tableau résumé

Le tableau suivant montre les différences entre les fonctionnalités anciennes et nouvelles de la Métaconsole :

Avant la version 5.0 Depuis la version 5.0
La Métaconsole peut agir comme une instance
Synchronisation Décentralisé Centralisé
Communication Unidirectionnelle Bidirectionnelle
Configuration d'instances
Panneau utilisateur
Vue tactique Par instances Général et événements de la dernière heure
Recherche d'agent
Vue de groupes
Visualiseur d'événements
(Données dans Instances)

(Données dans Métaconsole)
Vue arborescente
Affichage des alertes
Vue des modules
Carte réseau
Supervision du trafic (Netflow)
Outils de synchronisation Utilisateurs / Profils
Composants
Politiques
Alertes
Système d'exploitation
Groupes de modules
Utilisateurs / Profils
Groupes
Composants
Alertes
Étiquettes
Déplacer des agents entre des instances
Modèles de rapports
Éditeurs Rapports
Console visuelle
Utilisateurs / Profils
Groupes
Composants
Rapports
Console visuelle
Alertes
Étiquettes
Catégories
Appliquer / File d'attente de politiques
Affichage des moniteurs
Affichage des champs personnalisés
Assistant
Visualiseur de console visuelle
Configuration de cronjobs

Synchronisation

La Métaconsole dispose d'outils de synchronisation d'éléments, tels que la synchronisation des utilisateurs et des groupes, qui sont essentiels pour la bonne gestion des instances. La synchronisation est basée sur la transmission de toutes les informations créées dans la Métaconsole aux différentes instances pour gérer depuis la Métaconsole toutes les informations possibles de chacune d'entre elles.

Par exemple, un utilisateur créé dans une instance, mais pas dans la Métaconsole, ne peut pas être géré à partir de la Métaconsole. En revanche, si vous avez un utilisateur créé dans la Métaconsole et que vous synchronisez les utilisateurs, cet utilisateur se trouvera dans les instances et vous pouvez le gérer depuis la Métaconsole.

Propagation

La Métaconsole dispose d'outils de propagation d'éléments, tels que la propagation de composants ou le transfert d'agents entre des Instances (ou nœuds). Contrairement à la synchronisation, ce n'est pas un outil fondamental pour le fonctionnement optimal de la Métaconsole. Cela facilite uniquement la disponibilité des données dans les instances, ce qui est nécessaire si, par exemple, vous utilisez des politiques qui s'appliquent dans différentes instances (ou nœuds).

Par exemple, vous pouvez vouloir déplacer un agent de l'instance A vers l'instance B pour équilibrer la charge d'instances. Grâce à l'ensemble de ces outils, vous pourriez y parvenir très facilement.

Installation

Les installations des Instances et la Métaconsole ont en tant que exigence d'être stockées dans des serveurs qui soyent communiqués dans les deux directions.

Donc il faut s'assurer que :

  • La Métaconsole peut contacter les instances.
  • Les Instances peuvent contacter la Métaconsola

Les Instances n'ont pas besoin d'être communiquées parmis elles à aucun moment.

Pour comprendre mieux cette exigence jetez un coup d'oeil à l'Architecture de la Métaconsole.

La configuration horaire doit être la même. Le plus synchronisés les horloges des Instances et Métaconsole, plus exactes seront les données visualisées.

Par exemple, si une Instance a 5 minutes de différence par rapport à la Métaconsole, la visualisation du temps écoulé depuis que les événements ont été générés, lorsque les données sont montrées dans la Métaconsole, sera fausse.

Instances

Une Instance ou noeud est une installation typique de Pandora FMS Enterprise, composée par un serveur et une console web

Pour savoir en détail en tant qu'installer une instance vous pouvez voir le lien suivant.

Métaconsole

Une Métaconsole est une installation de Pandora FMS Enterprise avec une licence de Métaconsole.

La console de Pandora FMS et la Métaconsole ne peuvent pas être utilisés.

Il est nécessaire d'avoir un serveur actif pour faire de différentes opérations réferentes à la Métaconsole, comme la “ migration ”, “ autoprovisionnement ”, exécution de services, etc.

Activation de la licence

Après l'installation de la version Enterprise de la console de Pandora FMS, qu'il soit le méthode d'installation vous devrez accéder à la console Pandora FMS (http://IP/pandora_console/) et il vous affichera un écran de bienvenue pour accepter la licence.

Pour en savoir plus sur l'activation de la licence, visitez ce lien.

Pour activer la Métaconsole, vous avez besoin d'une licence de Métaconsole. Si vous activez la licence de noeud vous verrez la console normale.

Métalicence

Depuis la version 7.0NG de Pandora FMS, nous avons une licence unique pour un environnement avec Métaconsole. Vous pouvez créer autant d'instances que vous le souhaitez, tant que le nombre total d'agents dans la Métaconsole n'est pas dépassé.

Cette licence est appliquée dans la Métaconsole et peut être synchronisée dans autant d'Instances que souhaité, permettant ainsi une gestion centralisée des différents agents qui seront déployés dans lesdites Instances.

Avec cette licence, si vous démarrez une installation à partir de zéro, vous devez d'abord installer la Métaconsole en validant sa métalicence. Une fois validée, enregistrez chacune des Instances souhaitées (expliqué dans les sections suivantes), en synchronisant ensuite la métalicence afin que vous puissiez travailler sur chacune d'entre elles.

Outre les pannes de réseau occasionnelles, les nœuds Pandora FMS doivent être en mesure de contacter à tout moment la Métaconsole Pandora FMS. Si vous devez prendre en charge des nœuds qui peuvent rester déconnectés pendant des périodes arbitrairement longues, contactez Ártica à mailto:[email protected].

Configuration

Pour que les Instances se communiquent avec la Métaconsole et vice versa, les deux côtés doivent être configurés correctement.

Version NG 755 ou précédentes : configurez l’utilisation du centre de commande , vous disposez de toutes les informations pertinentes pour cela.

Métaconsole

Enregistrement et configuration de l’instance

Dans la section Metasetup, les instances avec lesquelles la Métaconsole sera liée peuvent être enregistrées et configurées.

Pour enregistrer une nouvelle instance, vous devez connaître une série de paramètres concernant l'instance que vous voulez gérer. S'il s'agit de l'enregistrement d'une Instance qui n'a pas encore été enregistrée avec une licence, les données par défaut sont :

  • Server name : localhost.localdomain
  • Auth token : vide
  • API password : vide
  • DB host : IP de la base de données
  • DB name : pandora
  • DB user : pandora
  • DB password : pandora
  • DB port : 3306
  • Control user : admin
  • Console password : pandora

Champs avancés

Pour garantir la connectivité entre le nœud et la Métaconsole, vous pouvez configurer manuellement les données de connexion.

  • Metaconsole DB host : IP de la base de données
  • Metaconsole DB name : pandora
  • Metaconsole DB user : pandora
  • Metaconsole DB name : pandora
  • Metaconsole DB port : 3306

Ces champs indiquent la configuration de la connexion que le nœud établira par rapport à la Métaconsole.

Dans le cas d'une installation Pandora FMS où vous avez déjà inclus une licence valide dans l'instance, vous devrez obtenir ces données à partir de la configuration de l'Instance et de sa base de données.

Dans la vue des Instances configurées, vous verrez que les Instances peuvent être modifiées, désactivées et supprimées. Il existe des indicateurs qui vérifient certaines informations sur la configuration de chaque Instance. Ces vérifications sont effectuées lors du chargement de cette vue, mais elles peuvent également être effectuées individuellement en cliquant dessus.

Les indicateurs sont les suivants :

  • Base de données : Si vous avez mal configuré la base de données de l'Instance ou si vous n'avez pas les autorisations nécessaires, l'indicateur sera rouge et vous donnera des informations sur le problème.
  • API : Cet indicateur testera l'API de l'Instance. S’il échoue, il vous donnera des informations sur l’échec.
  • Compatibilité : Cet indicateur vérifie certaines exigences entre l'Instance et la Métaconsole. Le nom du serveur de l'Instance, par exemple, doit correspondre au nom donné dans sa configuration dans la Métaconsole.
  • Réplication d’événements : Cet indicateur indique si la réplication d’événements est activée sur l’instance et si des événements ont déjà été reçus de l’instance il y a combien de temps la dernière réplication a eu lieu.
  • Cache de l’agent : Cet indicateur montre que les derniers états des agents et modules du nœud ont été correctement enregistrés dans la base de données de la Métaconsole. Lorsqu'une modification est générée, seule cette modification sera modifiée dans la base de données.
  • Synchronisation : Cet indicateur fait référence à la possibilité de pouvoir synchroniser les différents éléments de la Métaconsole aux instances.

Les trois premiers indicateurs doivent être verts pour que l'Instance soit correctement liée et vous commencez à voir ses données. En revanche, l'indicateur de réplication des événements ne vous donne que des informations sur cette caractéristique.

Une instance peut être bien configurée, mais sans répliquer ses événements.

Une fois qu’il a été choisi de répliquer les événements, toute la gestion de ceux-ci sera effectuée à partir de la Métaconsole, laissant les événements de l’Instance comme purement informatifs.

En cas d’activation du cryptage de base de données, tous les nœuds et la Métaconsole doivent avoir les mêmes paramètres de encryption_passphrase.

Mise à l’échelle de l’index

Version NG 755 ou précédentes : configurez l’utilisation du centre de commande, vous disposez de toutes les informations pertinentes pour cela.

La plupart de la synchronisation entre la Métaconsole et les Instances est effectuée par nom, quel que soit l'ID interne des éléments, à l'exception des groupes, étiquettes, alertes, systèmes d'exploitation et groupes de modules, dont les ID, il est important qu'ils soient synchronisés.

Pour vous assurer que les ID des groupes, balises, alertes, systèmes d’exploitation et groupes de modules synchronisés à partir de la Métaconsole n’existent pas dans les instances, augmentez sensiblement la valeur AUTO_INCREMENT des tables tgrupo, ttag, talert_templates, talert_actions, talert_commands, tconfig_os et tmodule_group. De cette façon, vous donnerez une large marge au cas où des éléments seraient créés dans les Instances pour des raisons au-delà de la Métaconsole.

Pour ce faire, exécutez la requête suivante dans la base de données de la Métaconsole :

 ALTER TABLE tgrupo AUTO_INCREMENT = 3000;
 ALTER TABLE ttag AUTO_INCREMENT = 3000;
 ALTER TABLE talert_templates AUTO_INCREMENT = 3000;
 ALTER TABLE talert_actions AUTO_INCREMENT = 3000;
 ALTER TABLE talert_commands AUTO_INCREMENT = 3000;
 ALTER TABLE tconfig_os AUTO_INCREMENT = 3000;
 ALTER TABLE tmodule_group AUTO_INCREMENT = 3000;

S’il est soupçonné que le nombre d’éléments dans une instance créée en dehors de la Métaconsole peut dépasser 3000, une valeur plus élevée peut être configurée.

Pour améliorer les performances des événements dans la Métaconsole dans les grands environnements, il est conseillé d’ajouter les index suivants dans la base de données :

ALTER TABLE tmetaconsole_agent_secondary_group ADD INDEX id_tagente (id_tagente);

ALTER TABLE tmetaconsole_event ADD INDEX server_id (server_id);

Planification des rapports

Version NG 755 ou précédentes : configurez l’utilisation du centre de commande, vous disposez de toutes les informations pertinentes pour cela.

Les packages de serveur (Open et Enterprise) doivent être installés sur le système sur lequel la Métaconsole est installé afin de lancer le script de maintenance de base de données (pandora_db). Vous devez vous assurer qu’il est correctement programmé pour l’exécution dans le cron toutes les heures (comme détaillé dans le lien suivant.).

Si vous prévoyez d'utiliser des rapports à la demande (envoyés par e-mail), planifiez l'exécution de l'extension cron pour qu'elle s'exécute comme sur une console Enterprise standard. Généralement, cela se fait en entrant la ligne suivante dans le cron, en ajustant les chemins locaux correspondants :

Pour les versions antérieures à 747, le chemin sera : /var/www/pandora_console/pandora_console.log.

Enfin, pour configurer le SMTP pour l’envoi d’e-mails, vous devez modifier les paramètres correspondants dans la section configuration de la messagerie, qui ont par défaut les valeurs suivantes :

Instances

Dans les Instances, il existe une série de paramètres pour garantir l'accès à vos données avec la Métaconsole.

Donner accès à la Métaconsole

Version NG 755 ou précédentes : configurez l’utilisation du centre de commande, vous disposez de toutes les informations pertinentes pour cela.

La Métaconsole accède à une instance de deux manières :

  • Accès à distance à la base de données pour afficher et modifier les données stockées dans les instances.
  • Accès à l’API pour certaines actions telles que la modification des fichiers de configuration ou la supervision NetFlow.

L’instance doit être configurée pour garantir les deux accès à la Métaconsole.

Base de données

Comme nous l’avons dit précédemment, vous devez connaître les identifiants de la base de données pour configurer l’instance sur la Métaconsole. (Hôte, Base de données, Utilisateur et Mot de passe).

En outre, un autre point important consiste à accorder à l’utilisateur des autorisations pour accéder à distance à la base de données. Cela se fait avec la commande MySQL GRANT :

GRANT ALL PRIVILEGES on .* to @ IDENTIFIED BY ;

Par exemple :

GRANT ALL PRIVILEGES on `PandoraMetaBase.*` to `[email protected]` IDENTIFIED BY `pandora`;

API

L’accès à l’API d’instance sera garanti avec les paramètres suivants :

  • Utilisateur et mot de passe : Un utilisateur et un mot de passe valides doivent être connus dans l’instance.
  • Mot de passe API :
  • Vous devez connaître le mot de passe pour accéder à l'API configurée dans l'Instance.
  • Liste des adresses IP avec accès API : Dans la configuration d'Instance, il existe une liste d'IPs pouvant accéder à l'API. Vous pouvez utiliser '*' en tant que caractère générique pour donner accès à toutes les IPs ou à un sous-réseau.

Auto-authentification

Dans certaines parties de la Métaconsole, il y a des accès à la console Web de l’instance ; par exemple, dans l’visualiseur d’événements, lorsque vous cliquez sur l’agent associé à un événement (le cas échéant), cela vous amène à la vue de cet agent dans la console de l’instance à laquelle il appartient. L’authentification automatique est utilisée pour cet accès. Cette authentification se fait avec un hachage pour lequel une chaîne configurée dans l’instance est nécessaire : le mot de passe d’auto-identification. Nous plaçons ce mot de passe dans le champ « Jeton d’authentification » de la configuration de l’instance sur la Métaconsole.

Cette configuration n’est pas nécessaire pour configurer l’instance dans la Métaconsole, mais sans elle, lorsque vous cliquez sur l’un des liens qui vous mènent à l’Instance, vous devrez vous authentifier.

Réplication d’événements

Version NG 755 ou précédentes : configurez l’utilisation du centre de commande, vous disposez de toutes les informations pertinentes pour cela.

Pour que les instances soient visibles dans la Métaconsole, elles doivent avoir accès à la base de données de la Métaconsole.

Les instances répliqueront leurs événements de temps en temps en stockant la date et l’heure de la dernière réplication pour continuer à partir de là la prochaine fois.

En plus de répliquer les événements, ils rendront effective l’auto-validation dans la Métaconsole. Autrement dit, pour les événements associés à un module, lorsqu'ils répliquent l'événement sur la Métaconsole, ils valideront tous les événements précédents attribués au même module.

Pour configurer la réplication d'événements, dans la section Configuration Enterprise d'Instance, activez la Réplication d'événement.

Il sera configuré :

  • Intervalle : Toutes les quelques secondes, le serveur réplique les événements générés depuis la dernière réplication dans la base de données de la Métaconsole.

Si vous avez configuré, par exemple, 60 secondes, la première réplication aura lieu 60 secondes après le démarrage du serveur.

  • Mode de réplication : Il indique si tous les événements seront répliqués ou uniquement ceux validés.
  • Afficher la liste des événements dans la console locale (lecture seule) : Lorsque la réplication d'événements est activée, la gestion des événements se fait dans la Métaconsole et n'est pas accessible depuis l'instance. Avec cette option, vous aurez accès à une vue des événements en mode lecture seule.
  • Identifiants de la base de données de la Métaconsole : Hôte, base de données, utilisateur, mot de passe et port (si le port n'est pas indiqué, le port par défaut sera utilisé).

Version NG 755 ou précédentes : configurez l’utilisation du centre de commande, vous disposez de toutes les informations pertinentes pour cela.

La réplication des événements est effectuée par le serveur. Un jeton doit être activé dans le fichier de configuration :

Toute modification de configuration apportée à la réplication d’événements nécessitera un redémarrage du serveur.

Si vous ajoutez un nœud qui contient déjà de nombreux événements à une Métaconsole, il prendra beaucoup de temps à copier tous les événements qu’il a sur la Métaconsole.

Si vous souhaitez modifier manuellement la date à partir de laquelle le nœud synchronisera les événements avec la Métaconsole (par exemple, pour le forcer à répliquer les événements de la date actuelle), vous devrez lancer la requête suivante sur la base de données du nœud pour les versions de Pandora FMS antérieures à 5.1SP3 :

UPDATE tconfig SET `value` = UNIX_TIMESTAMP() WHERE `token` = "replication_copy_last_utimestamp"

Pour les versions ultérieures à 5.1SP3, exécutez la requête suivante :

UPDATE tconfig SET `value` = (SELECT MAX(id_evento) FROM tevento) WHERE `token` = "replication_copy_last_id";

Si la sécurité SELinux est activée sur les nœuds enfants, la réplication peut ne pas fonctionner ; veuillez l’éteindre.

Auto-approvisionnement à partir de la Métaconsole

Version NG 755 ou précédentes : configurez l’utilisation du centre de commande, vous disposez de toutes les informations pertinentes pour cela.

Depuis Pandora FMS 7, vous pouvez trouver dans la configuration de la Métaconsole l'option d'enregistrer le nœud dans la Métaconsole.

De plus, vous pouvez vérifier si vous arrivez via API à la Métaconsole et si le nœud y est enregistré.

Il est nécessaire d'indiquer les identifiants appropriées pour la connexion avec le nœud, la base de données et l'API.

La première fois que vous effectuez cette configuration, vous pouvez indiquer un mot de passe pour l'API. En cas de mise à jour, le mot de passe du nœud sera conservé.

La configuration qui se trouve dans “options avancées” sera celle qui sera envoyée au nœud pour sa connexion à la base de données.

Configuration supplémentaire de la Métaconsole

Version NG 755 ou précédentes : configurez l’utilisation du centre de commande, vous disposez de toutes les informations pertinentes pour cela.

La Métaconsole, si la réplication d'événement de noeud a été activée, elle héberge les données d'événement dans sa propre base de données. Pour sa maintenance, ces données peuvent être supprimées et / ou déplacées vers la base de données d'historique des événements de la Métaconsole. Cela se fait, comme dans une Instance Pandora FMS, par l'exécution du script de maintenance de base de données trouvé dans /usr/share/pandora_server/util/pandora_db.pl. En règle générale, pour le lancer, le fichier serveur est utilisé, mais étant une Métaconsole, il ne doit pas nécessairement y avoir de serveur. Pour ce faire, prenez une copie du fichier /etc/pandora/pandora_server.conf de l'un des nœuds, modifiez-le et modifiez les données concernant la base de données (nom d'hôte, nom de la base de données, utilisateur et mot de passe) et gardez le fichier, pour exemple comme :

/etc/pandora/pandora_meta.conf

Créez un script dans /etc/cron.daily/pandora_meta_db avec le contenu suivant :

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

Et modifiez les permissions de celui-ci via chmod :

chmod 755 /etc/cron.daily/pandora_meta_db

Pour pouvoir l'exécuter, vous devez avoir installé les packages nécessaires pour exécuter (même si ce n'est pas le cas) le serveur Pandora FMS et sa version Enterprise.

Exécutez-le manuellement pour vérifier qu'il fonctionne et ne donne pas d'erreurs :

/etc/cron.daily/pandora_meta_db

Synchronisation de Métalicence

Ci-dessous, nous allons voir un exemple de la façon de synchroniser la Métalicence entre une Métaconsole et une Instance.

Tout d'abord, nous avons une instance avec sa propre clé générée et validée correctement :

metalicencia1.jpg

Une fois que vous avez le nœud généré et validé correctement, configurez-le dans la Métaconsole pour pouvoir synchroniser la licence ultérieurement :

Lorsque vous aurez ces étapes, allez vers la licence de la Métaconsole et cliquez “ Validate ” pour synchroniser la Métalicence avec l'Instance.

metalicencia1.jpg

Le résultat sera que vous aurez la Métalicence dans l'instance.

Autorisations utilisateur

Il existe plusieurs systèmes d'autorisation qui restreignent ce qu'un utilisateur peut afficher ou gérer.

ACL

Le système ACL contrôle les éléments qu'un utilisateur peut afficher ou gérer en fonction du groupe auquel ils appartiennent.

Par exemple :

  • Un utilisateur peut avoir des autorisations de lecture sur les modèles d'alertes du groupe Applications et administration sur ceux du groupe Serveurs.
  • Vous pourrez visualiser et attribuer les modèles des deux groupes, mais vous n'aurez que la possibilité de modifier ou de supprimer ceux du groupe Servers.

Pour en savoir plus sur les ACL, cliquez sur ce lien.

Étiquettes

Un « Tag » est une étiquette qui peut être attribuée à un module.

Un utilisateur peut avoir les ACL d'un certain groupe restreintes par des étiquettes. Si tel est le cas, seules ces ACL seront appliquées aux modules contenant ces étiquettes.

Par exemple :

  • Un utilisateur peut avoir une autorisation de lecture ou d'administration dans le groupe Serveurs restreinte à l'étiquette ou « Tag » « Systèmes ».
  • Vous n'aurez que ces permissions sur les modules, qui même appartenant à un agent du groupe Serveurs, ont l'étiquette Systèmes assignée.

Pour en savoir plus sur les étiquettes, cliquez sur ce lien.

Contrôle d'accès à l'assistant

Les utilisateurs ont un niveau d'accès attribué par rapport à l'assistant de la Métaconsole. Ce niveau peut être « Basique » ou « Avancé ». À leur tour, les modèles d'alertes et les composants de modules (locaux et réseau) auront également ce niveau d'accès.

Visibilité

Accès de base

Les utilisateurs ayant accès de base ne pourront voir dans l'assistant que les alertes correspondant aux modèles d'alertes de niveau de base et les modules créés à partir des composants de niveau de base.

Accès avancé

Les utilisateurs ayant accès à « avancé » verront des alertes et des modules au niveau « de base » et « avancé » dans l'assistant.

Configuration

Outre la visibilité, le niveau d'accès affecte également la configuration des modules et leurs alertes.

La section « Operation (assistant de supervision) » explique en détail la différence entre la configuration d'un moniteur de base et avancé.

Administration

La section Avancé contient les options d'administration de la Métaconsole, notamment :

  • La synchronisation des données entre la Métaconsole et les Instances
  • La gestion des données de la Métaconsole
  • La gestion de la licence de la Métaconsole
  • Le Metasetup où ils se trouvent :
    • La configuration des instances
    • Les options de configuration de la Métaconsole

Dans cette section, nous allons parler du Metasetup, dans la section suivante, nous expliquerons en détail la synchronisation et la gestion des données à partir de la Métaconsole.

Vous pouvez trouver des informations détaillées sur la licence ici : Licences sur Métaconsole

Configuration des instances

Dans la section Metasetup, en plus de toutes les options de configuration de la console, il y a un onglet de Configuration des consoles.

Dans cet onglet, nous allons gérer les instances. Tout le processus de configuration se trouve dans la section Installer et configurer la Métaconsole du manuel

Configuration de la Métaconsole

Dans la section Metasetup, vous trouverez des onglets avec les différentes options de configuration de la Métaconsole.

Configuration générale

Cette section contient des données générales de la Métaconsole telles que la langue, les paramètres de date/heure ou la personnalisation de certaines sections, entre autres.

Ils peuvent être personnalisés si vous souhaitez activer ou désactiver les sections Netflow, la vue arborescente classée par tags, la console visuelle ou la possibilité de créer des contrôles Web à partir de l'Assistant.

metapublicurl.jpg

Les paramètres qui nécessitent une explication sont :

  • Gestion centralisée : Cette option vous permet de gérer de manière centralisée depuis la Métaconsole les politiques et les événements, sans pouvoir ensuite les gérer depuis les nœuds.
  • Force use Public URL : Il force l'utilisation d'une URL publique. Si cette zone est active, quel que soit le système implémenté, les liens et les références seront toujours construits sur la base de public_url.
  • Public URL host exclusions : Les hôtes ajoutés dans ce champ ignoreront le champ précédent.
  • Enable update manager : Cette option vous permet d'activer à la fois le “ Offline update manager ” et le “ Online update manager ”, qui vous permettent de mettre à jour la Métaconsole dans cette configuration.
  • Enable log viewer : Cette option vous permet d'activer l'onglet de la visionneuse de logs pour modifier les paramètres du serveur Elasticsearch.

Politique de mots de passe

Une politique de mot de passe peut être définie avec des limitations sur le nombre de caractères des mots de passe, l'expiration, le blocage temporaire d'un utilisateur. Pour en savoir plus sur la politique de mot de passe, consultez la section Politique de mot de passe du manuel.

Log Viewer

À partir de la version 747 de Pandora FMS, les paramètres d'accès au serveur ElasticSearch sont intégrés, le nombre maximal d'entrées de journal à afficher dans la section Monitoring > Log Viewer et l'état du serveur ElasticSearch configuré.

Authentification

Pour en savoir plus sur l'authentification, consultez la section Authentification du manuel.

Configuration visuelle

Toute la configuration relative à la représentation des données. Couleurs et résolution des graphiques, nombre d'éléments dans la pagination des vues, etc. Vous trouverez plus d'informations sur les paramètres visuels dans ce lien.

Rendement

Options d'affichage, d'historique, de purge d'événements et de taille de bloc maximale lors de la migration de données.

Gestionnaire de fichiers

Gestionnaire de fichiers où vous pouvez télécharger et supprimer les fichiers du dossier d'images de l'installation de la Métaconsole.

Le code de la Métaconsole réutilise certaines images du code de la console normale. Ces images ne seront pas accessibles depuis ce gestionnaire et il sera nécessaire d'accéder à l'installation manuellement pour les gérer.

Traduction de chaînes

Avec l'utilitaire de traduction de chaînes, vous pouvez personnaliser les traductions.

Recherchez la chaîne souhaitée dans la langue que vous voulez personnaliser. Vous verrez la chaîne originale, la traduction dans cette langue et une troisième colonne pour mettre la traduction personnalisée.

E-mail

Avec l'utilitaire de messagerie, vous pouvez personnaliser l'envoi de courriels depuis la Métaconsole, où vous devrez configurer le compte de messagerie avec lequel vous voulez envoyer, par exemple, les rapports générés.

Options Update Manager

Dans cette section, vous pouvez modifier les options à utiliser pour Update Manager. Par défaut, il est déjà configuré pour effectuer la mise à jour en ligne. Cette section ne sera visible que si vous avez activé “ Enable update manager ”.

Offline Update Manager

Dans cette section, vous pouvez mettre à jour la Métaconsole sans avoir à vous connecter à un autre endroit. Nous n'aurons qu'à télécharger les fichiers “ RPM ” dans l'ordre jusqu'à la version que vous voulez mettre à jour, car ce ne sont pas des versions cumulatives. Cette section ne sera visible que si vous avez activé “ Enable update manager ”.

Online Update Manager

Dans cette section, vous pouvez mettre à jour la Métaconsole automatiquement, vous n'aurez qu'à posséder une licence valide de Métaconsole et un accès Internet. Cette section ne sera visible que si vous avez activé “ Enable update manager ”.

Outils de synchronisation

La Métaconsole dispose d'outils de synchronisation des éléments, qui sont essentiels à la bonne gestion des instances. La synchronisation est basée sur la transmission de toutes les informations créées dans la Métaconsole aux différentes instances pour gérer depuis la Métaconsole toutes les informations possibles de chacune d'entre elles.

Par exemple, si vous avez 20 instances (nœuds) différentes dans votre entreprise, et que vous voulez qu'un même utilisateur ait les mêmes autorisations d'accès sur ces 20, vous pourrez créer un utilisateur avec les profils souhaités et vous synchroniserez cet utilisateur pour l'avoir sur les 20 instances (nœuds) afin de ne pas avoir à le créer individuellement sur chaque instance.

Un autre exemple, vous devez surveiller différents clients qui sont répartis sur vos instances, de sorte que certains clients sont également répétés dans différentes instances. Vous pourrez créer les différents groupes auxquels les agents des différentes instances appartiendront, puis synchroniser chaque groupe correspondant avec leur instance.

Ensuite, vous allez voir en détail les différentes synchronisations que la Métaconsole vous permettent de réaliser.

Synchronisation des utilisateurs

Cette option permet à l'utilisateur de synchroniser les utilisateurs de la Métaconsole et leurs profils sur les instances.

Dans cette synchronisation, vous pouvez trouver deux options différentes :

  • Copier les profils configurés à l'utilisateur

  • Donner de nouveaux profils à l'utilisateur créé.

Dans les deux cas, vous avez la possibilité de créer les groupes associés aux profils s'ils n'existent pas dans l'instance (nœud).

Avant d'utiliser cette synchronisation, il est recommandé de prendre en compte les utilisateurs qui vont être créés dans les instances, en raison d'éventuels conflits dans l'ID utilisateur. Il est conseillé de ne pas avoir d'utilisateurs créés sur les instances et de les créer tous à partir de la Métaconsole afin d'avoir les mêmes utilisateurs sur celle-ci et sur les instances.

Dans les deux cas, les profils qui n'existent pas sur l'instance seront créés.

Si vous vous demandez laquelle de ces deux options doit être utilisée, copiez les profils de l'utilisateur.

Synchronisation de groupes

Cette option permet à l'utilisateur de synchroniser les groupes de la Métaconsole avec les instances.

Il est conseillé de ne pas avoir d'utilisateurs créés sur les instances et de les créer tous à partir de la Métaconsole afin d'avoir les mêmes utilisateurs sur celle-ci et sur les instances.

Une fois les groupes synchronisés, les noms des groupes ne doivent pas être modifiés, ni dans la Métaconsole, ni dans le nœud. Si cela est fait, vous devrez les modifier sur les deux sites afin qu'ils ne posent pas de problèmes car la synchronisation est basée sur l'ID, mais certaines opérations utilisent le nom. La synchronisation dans la version actuelle synchronise le nom la première fois, mais s'il y a des changements de nom ultérieurs dans les groupes, ils ne sont pas synchronisés

Synchronisation d'alertes

Cette option permet à l'utilisateur de synchroniser les alertes de la Métaconsole avec les instances.

Il est conseillé de ne pas avoir d'utilisateurs créés sur les instances et de les créer tous à partir de la Métaconsole afin d'avoir les mêmes utilisateurs sur celle-ci et sur les instances.

Synchronisation des composants

Cette option permet à l'utilisateur de synchroniser les groupes de la Métaconsole avec les instances.

Il est conseillé de ne pas avoir d'utilisateurs créés sur les instances et de les créer tous à partir de la Métaconsole afin d'avoir les mêmes utilisateurs sur celle-ci et sur les instances.

Synchronisation de tags

Cette option permet à l'utilisateur de synchroniser les groupes de la Métaconsole avec les instances.

Il est conseillé de ne pas avoir d'utilisateurs créés sur les instances et de les créer tous à partir de la Métaconsole afin d'avoir les mêmes utilisateurs sur celle-ci et sur les instances.

Synchronisation d'OS

Cette option permet à l'utilisateur de synchroniser les systèmes d'exploitation de la Métaconsole avec les instances.

Il est conseillé de ne pas avoir des systèmes d'exploitation créés sur les instances et de les créer tous à partir de la Métaconsole afin d'avoir les mêmes systèmes sur celle-ci et sur les instances.

Synchronisation de groupes de modules

Cette option permet à l'utilisateur de synchroniser les groupes de modules opérationnels de la Métaconsole avec les instances.

Il est conseillé de ne pas avoir des groupes de modules créés sur les instances et de les créer tous à partir de la Métaconsole afin d'avoir les mêmes groupes de modules sur celle-ci et sur les instances.

Outils de propagation

La Métaconsole dispose d'outils de propagation d'éléments. Contrairement à la synchronisation, ce n'est pas un outil fondamental pour le fonctionnement optimal de la Métaconsole. Cela facilite uniquement la disponibilité des données dans les instances, ce qui est nécessaire si, par exemple, vous utilisez des politiques qui s'appliquent dans différentes instances (ou nœuds).

Il est recommandé de synchroniser les instances avec la Métaconsole après la création des différents éléments dans l'outil de propagation.

Ensuite, vous allez voir en détail les différentes propagations ou gestion de données que la Métaconsole vous permettent de réaliser.

Gestion des utilisateurs

Dans cette section, vous pouvez effectuer les actions suivantes :

  • Gestion des utilisateurs
  • Gestion des profils
  • Modifier mon utilisateur

Par exemple, supposons que vous avez 10 instances dans votre Métaconsole, où vous voulez qu'un utilisateur disposant d'autorisations spéciales opère dans 3 d'entre elles. Tout d'abord, allez à la gestion des profils où vous créeriez un profil spécial avec les autorisations que vous voulez. Ensuite, créez l'utilisateur que vous voulez gérer les trois instances, en lui attribuant l'autorisation que vous avez créée. Enfin, synchronisez cet utilisateur et les profils avec les instances pour l'avoir déjà dans les trois. Après un certain temps, l'utilisateur est devenu obsolète, mais au lieu d'effacer l'utilisateur, désactivez-le au cas où vous voudriez le réutiliser à l'avenir, allez vers la gestion des utilisateurs et utilisez le symbole de l'ampoule pour le désactiver jusqu'à nouvel ordre.

Gestion des utilisateurs

Dans cette section, vous pouvez voir la liste des utilisateurs déjà créés, modifier leurs paramètres, les supprimer, les désactiver ou créer de nouveaux utilisateurs.

Créer un nouvel utilisateur

Pour ajouter un utilisateur, cliquez sur le bouton « Create User », où le formulaire suivant que vous devrez remplir apparaîtra :

Les paramètres qui nécessitent une explication sont :

  • Interactive charts : Il permet à l’utilisateur de choisir s’il préfère visualiser les graphiques interactifs, ou au contraire utiliser la configuration générale de la Métaconsole.
  • Metaconsole access : Définissez les autorisations avec lesquelles l’utilisateur accédera à la Métaconsole. Ces autorisations peuvent être les suivantes :
  • Basique : Avec cet accès, l’utilisateur ne pourra utiliser dans l’Assistant que les composants dont le niveau de l’Assistant est Basic.
  • Tant que vous disposez d’autorisations ACL sur le groupe auquel elles appartiennent.
  • Avancé :
  • Avec cet accès, l’utilisateur pourra utiliser n’importe lequel des composants de l’Assistant, quel que soit son niveau d’Assistant. Tant que vous disposez d’autorisations ACL sur le groupe auquel elles appartiennent.
  • Search custom field view : Sélectionnez le filtre par défaut pour la vue « Champs personnalisés »
  • Not Login : Si cette option est sélectionnée, l’utilisateur pourra accéder à l’API
  • Enable agents management : Cette option permet d’activer la gestion des agents dans l’Assistant. S’il est désactivé, seuls les Assistants Module et Alerte seront disponibles.
  • Enable node access : Cette option permet d’activer l’accès aux instances. Si cette option est activée, les consoles d’instance seront accessibles via les noms des agents et des modules à de nombreux endroits. Par exemple, à partir de la carte réseau ou de la vue des événements.
Modifier/Désactiver/Supprimer un utilisateur

La liste des utilisateurs fournit des options pour :

  • Activer/Désactiver l’utilisateur
  • Modifier l'utilisateur
  • Supprimer l’utilisateur de la Métaconsole
  • Supprimer l’utilisateur de la Métaconsole et de toutes les Instances

Le formulaire de modification d’un utilisateur est identique au formulaire de création, mais inclut l’éditeur de profil.

Dans l’éditeur de profils, vous pouvez affecter les profils utilisateur dans certains groupes et limiter ces privilèges aux balises sélectionnées. Si les balises ne sont pas sélectionnées, l’utilisateur aura accès à tous les modules, qu’ils soient associés aux balises ou non.

Gestion des profils

Dans cette section, vous pouvez voir la liste des profils déjà créés, modifier leurs paramètres, les supprimer, les désactiver ou créer de nouveaux utilisateurs.

Il existe un certain nombre de FLAGS de listes de contrôle d’accès qui donneront accès aux différentes fonctionnalités de Pandora FMS. Pour savoir quelle fonction chaque FLAG des ACL des profils active, visitez la section Profils de Pandora FMS dans le manuel de l’utilisateur.

Créer un nouveau profil

Pour ajouter un profil, cliquez sur le bouton « Créer », où le formulaire suivant apparaîtra où vous devez remplir les autorisations que vous voulez accorder avec le profil :

Certains de ces bits n’ont pas de sens sur la Métaconsole. Cependant, vous pouvez utiliser la Métaconsole pour synchroniser les profils avec les instances, où ils pourraient être utiles.

Modifier/Supprimer un profil

La liste des profils fournit des options pour :

  • Modifier le profil
  • Supprimer le profil de la Métaconsole

Modifier mon profil

Dans cette section, vous pouvez configurer l’utilisateur authentifié dans la Métaconsole. Les profils attribués à l’utilisateur seront simplement informatifs. Dans le cas où l’utilisateur authentifié n’est pas un administrateur, ce sera la seule section qui peut être vue.

Gestion des agents

Dans cette section, vous pouvez effectuer les actions suivantes :

  • Migration d’agents entre instances
  • Auto-approvisionnement des agents
  • Gestion des groupes

Par exemple, vous prévoyez de gérer 15 instances dans la Métaconsole, et vous voulez que la distribution des agents soit organisée en fonction de la charge de chaque instance, en créant les agents de manière à ce qu’ils soient toujours générés dans l’instance avec la charge la plus faible. Pour ce faire, passez à l’auto-approvisionnement et activez l’option indiquée pour cela. Une fois cela fait, si par exemple, vous réalisez que certains agents doivent aller ensemble dans la même instance, allez vers la migration des agents entre les instances, où vous choisirez quels agents se déplacent vers quelles autres instances afin que vous n’ayez pas à supprimer et à créer les agents manuellement.

Migration de l’agent

Cette fonctionnalité nécessite un serveur Métaconsole démarré pour fonctionner.

Dans cette section, vous pouvez migrer des agents entre les instances connectées à votre Métaconsole.

Pour que les données historiques des agents à transférer ne soient pas transférées, vous devez activer la case « Discard history data ». Une fois que vous avez tout sélectionné et que vous avez cliqué sur le bouton « move », il commencera à effectuer les vérifications suivantes pour pouvoir effectuer la migration.

Les agents n’existent pas sur le serveur de destination

Il ne doit pas y avoir d’agent à migrer avec le même nom d’agent sur le serveur cible.

Les collections requises sont synchronisées avec le serveur de destination

Pour empêcher l’agent de tenter de télécharger des collections inexistantes après la migration, vérifiez que les collections existent sur les deux serveurs (source et destination).

Les définitions d’alerte requises sont synchronisées avec le serveur cible

Vérifiez que les modèles, actions et commandes définis sur le serveur source sont également définis sur le serveur de destination. Les relations sont établies via ID, de sorte que ces valeurs doivent également être identiques.

les fichiers de configuration des agents logiciels associés aux agents n’existent pas sur le serveur cible

Il ne doit pas y avoir de fichiers de configuration portant le même nom que ceux associés aux agents que vous allez migrer sur le serveur cible. Si c’est le cas, vous devez les éliminer du serveur de destination.

Les deux serveurs ont la même version

Vérifiez que les versions de Pandora FMS sont identiques sur les deux serveurs.

L’adresse du serveur de destination est configurée

Vérifiez que l’adresse IP de votre serveur de destination (Dataserver) est configurée, vous pouvez accéder à l’écran suivant via Serveurs > Gérer les serveurs de l’instance vers laquelle vous voulez déplacer les agents :

Les politiques requises sont synchronisées avec le serveur de destination

Vérifiez que les politiques du serveur source sont disponibles sur le serveur de destination. Les relations sont établies via ID, de sorte que ces valeurs doivent également être identiques.

Les groupes sont synchronisés avec le serveur de destination

Vérifiez que les groupes de serveurs sources sont définis sur le serveur de destination. Les relations sont établies via ID, de sorte que ces valeurs doivent également être identiques.

Les plugins distants sont synchronisés avec le serveur de destination

Vérifiez que les groupes de serveurs sources sont définis sur le serveur de destination. Les relations sont établies via ID, de sorte que ces valeurs doivent également être identiques.

Les plugins distants sont synchronisés avec le serveur de destination

Vérifiez que les groupes de serveurs sources sont définis sur le serveur de destination. Les relations sont établies via ID, de sorte que ces valeurs doivent également être identiques.

Une fois toutes les vérifications effectuées, cliquez sur le bouton « Next » pour poursuivre la migration, où un tableau apparaîtra avec l’état de la migration.

Pour éviter de bloquer la file d’attente de travail, l’agent à transférer sera toujours traité avec une priorité inférieure, ce qui empêche le système d’être bloqué en transférant un agent avec beaucoup de données, donnant la priorité à la migration de l’agent sur la migration des données.

Pour optimiser le processus, l’agent d’origine sera désactivé et le mode désactivé automatique sera établi. Par défaut, ce paramètre supprime l’agent d’origine dans les 30 jours.

Les modules de prédiction définis peuvent perdre des fonctionnalités après la migration de l’agent. Révisez les définitions après la migration.

Auto-approvisionnement de l’agent

Lorsque vous déployez Pandora FMS dans des environnements vastes et complexes avec de nombreux nœuds Pandora FMS et environnement Métaconsole, vous trouvez le problème de décider comment déployer les agents : à quel serveur sont-ils affectés? comment équilibrer la charge de travail ?

Pour cela, le concept d'auto-approvisionnement des agents apparaît, ce qui permet d'assigner un agent à l'un des multiples serveurs de Pandora FMS que vous avez sur votre infrastructure.

Cette fonctionnalité nécessite un serveur Métaconsole avec ProvisioningServer démarré pour fonctionner.

Cette fonctionnalité est utilisée pour gérer l'affectation initiale des agents à un serveur donné. Lorsque vous installez vos agents pour la première fois, sélectionnez l'adresse IP de la Métaconsole en tant que server_ip.

Pour pouvoir utiliser cette fonctionnalité, configurez le serveur et la Métaconsole.

Configuration du serveur

Pour que le système d'auto-approvisionnement fonctionne, activez le ProvisioningServer dans /etc/pandora/pandora_server.conf :

 # Enables self-provisioning service
 provisioningserver 1

Vérifiez que l'adresse IP de vos serveurs de destination (Dataserver) est configurée sur chaque nœud, vous pouvez accéder à l'écran suivant via Serveurs > Gérer les serveurs

Configuration de la console

Dans cette section, vous pouvez choisir entre les trois types d'auto-approvisionnement, en activant celui que vous voulez à l'aide d'un interrupteur :

Round Robin

Utilisez la méthode de planification Round-robin pour distribuer de manière équitable et dans un ordre rationnel tous les nouveaux agents logiciels Pandora FMS qui arrivent sur la Métaconsole. La distribution des agents se fera de manière circulaire, en assignant le serveur correspondant à chaque nouvel agent.

Less Loaded

Les nouveaux agents seront affectés aux serveurs avec moins de charge dynamique.

Custom

Dans la classification personnalisée, vous pouvez définir vos propres règles de classification, en fonction de certains paramètres récupérés à partir des informations rapportées par l'agent (nom de l'agent et adresse IP.).

Si vous choisissez le cas de « Custom », cliquez sur le bouton « Create a custom entry » où apparaîtra le formulaire suivant :

Là où dans la configuration, vous devrez mettre le contenu à ajouter au fichier de configuration, c'est la personnalisation que vous utiliserez pour la classification de l'agent, par exemple :

  # Text contained here will be validated and inserted in the agent configuration
server_ip 192.168.80.164

Une fois créé, introduisez les règles que vous voulez que les agents respectent en cliquant sur le bouton « add ».

Vous pouvez spécifier les conditions de correspondance sous forme de règles en utilisant les champs suivants :

  • alias de l'agent
  • adresse de l’agent.

Vous pouvez spécifier les opérations en utilisant les champs suivants :

  • OR
  • AND

Autoconfiguration

Dans cette section, vous pouvez modifier les autoconfigurations des agents de manière centralisée à partir de la Métaconsole. Pour pouvoir réaliser cette modification, vous devez avoir activé le “ Centralized management ”.

Pour plus d'informations, veuillez visiter le lien.

Gestion de groupes

Dans cette section, vous pouvez gérer, supprimer et créer de nouveaux groupes dans la Métaconsole.

Création d'un groupe

Pour créer un nouveau groupe, cliquez sur le bouton “ create group ” et le formulaire suivant apparaîtra :

Les paramètres qui nécessitent une explication sont :

  • Parent : Combo où un autre groupe peut être défini comme parent du groupe en cours de création.
  • Propagate ACL : Il permet de propager les ACL aux sous-groupes enfants.
  • Custom ID : Les groupes ont un ID dans la base de données, dans ce champ, il est possible de mettre un autre ID personnalisé qui peut être utilisé par un programme externe pour effectuer une intégration.
Modifier/Supprimer un groupe

La liste des profils fournit des options pour :

  • Modifier le groupe
  • Supprimer le groupe de la Métaconsole

Tree group

Dans cette section, vous pouvez effectuer exactement les mêmes actions que dans la section précédente, en changeant le mode d'affichage :

Collections

Depuis Pandora FMS OUM729, la gestion des collections peut être centralisée depuis la Métaconsole.

La première fois que vous accéderez à la gestion des collections, la gestion centralisée étant activée, un processus interne de synchronisation des collections des nœuds vers la Métaconsole sera effectué :

À partir de ce moment, vous aurez les collections sur la Métaconsole. Pour éviter les conflits, vous devez copier manuellement les répertoires de collections des nœuds vers la Métaconsole :

Lieu d'origine (nœud) :

/var/www/html/pandora_console/attachment/collection/

Emplacement de destination (Métaconsole) :

/var/www/html/pandora_console/attachment/collection/

Remarque : N'oubliez pas d'attribuer les autorisations correctes aux fichiers transférés :

chmod apache. -R  /var/www/html/pandora_console/attachment/collection/*

Une fois les fichiers transférés, vous pouvez recréer la collection pour forcer la synchronisation aux nœuds.

Pour plus d'informations sur les collections, s'il vous plaît visitez ce lien.

Gestion des modules

Dans cette section, vous pouvez effectuer les actions suivantes :

  • Gestion des groupes de composants
  • Gestion des composants locaux
  • Gestion des composants réseaux
  • Gestion des plugins

Avant de commencer, nous allons expliquer que c'est un composant : c'est un « module générique » qui peut être appliqué à plusieurs reprises sur un agent, étant une sorte de « copie maîtresse » d'un module. Ceci est très utile pour pouvoir surveiller de nouveaux agents avec les composants enregistrés dans la base de données.

Par exemple, vous avez 12 instances où vous voulez créer le même type de modules dans chacune : vous voulez créer 10 modules locaux, 5 modules réseau et 3 plugins personnalisés. Car grâce à la gestion dans la Métaconsole, vous pourrez créer ces composants, chacun dans sa section, et ensuite les synchroniser pour les avoir dans les différentes instances sans avoir à créer manuellement un à un les différents modules et plugins à utiliser.

Gestion de groupes de composants

Dans cette section, vous pouvez supprimer et créer de nouveaux groupes de composants.

Création d'un groupe

Pour créer un nouveau groupe, cliquez sur le bouton « Create ».

Supprimer le groupe

Gestion des composants locales

Dans cette section, vous pouvez supprimer, dupliquer et créer de nouveaux composants locaux. Un composant local est l'élaboration d'un module défini dans la configuration des agents logiciels, structuré en “morceaux” de texte qui peuvent être coupés et collés dans la configuration des agents.

Création d'un composant local

Afin de créer un composant local, cliquez sur le bouton « Créer » où le formulaire suivant apparaîtra :

Pour plus d'informations sur les paramètres de création d'un nouveau composant local, visitez le lien.

Dupliquer/Supprimer un composant local

Des options sont disponibles dans la liste des composants locaux pour :

  • Dupliquer un composant local
  • Supprimer un composant local de la Métaconsole

Gestion de composants réseaux

Dans cette section, vous pouvez supprimer, dupliquer et créer de nouveaux composants locaux. Un composant réseau regroupe tous les modules de type distant (wmi, tcp, snmp, icmp, plugin, web, etc.).

Dupliquer/Supprimer un composant réseau

Des options sont disponibles dans la liste des composants locaux pour :

  • Dupliquer un composant réseau
  • Supprimer un composant réseau de la Métaconsole

Gestion des plugins

Dans cette section, vous pouvez supprimer, modifier et créer de nouveaux plugins qui utiliseront des composants réseau de type plugin.

Création des plugins

Pour créer un plugin, cliquez sur le bouton “ Add ” et le formulaire suivant apparaîtra :

Les paramètres qui nécessitent une explication sont :

  • Plug-in command : Où vous allons mettre le PATH où se trouve le plugin
  • Plug-in parameters : Où vous allez mettre les paramètres que vous devez écrire pour que le plugin fonctionne correctement.

Modifier/Supprimer un plugin

La liste des plugins fournit des options pour :

  • Modifier un plugin
  • Supprimer un groupe de la Métaconsole

Certains plugins ont un cadenas devant l'option de modification, car ces plugins ne peuvent pas être modifiés ou supprimés.

Gestion des alertes

Dans cette section, vous pouvez effectuer les actions suivantes :

  • Gestion des commandes
  • Gestion des actions
  • Gestion des écrans

Par exemple, dans votre Métaconsole, vous avez 5 instances avec des clients différents et vous avez tous besoin de mesurer la température de l'UCT dans chaque agent. Avec cette information, vous avez besoin d'une alerte qui se déclenche lorsque l'UCT dépasse une certaine température, et ce que vous voulez est d'exécuter une commande qui fait que l'UCT supprime certains services pour ne pas être utilisé de manière excessive en provoquant la hausse de température. Il faut créer une alerte qui exécute cette commande, puis vous la synchronisez avec toutes vos instances afin de ne pas avoir à l'exécuter manuellement une à une.

Cette section ne traitera que de la gestion des modèles, en particulier des différences avec la gestion des alertes des instances. Pour en savoir plus sur son fonctionnement et sa configuration, vous pouvez consulter la section du manuel de Pandora FMS Système d'alerte.

Gestion des modèles

La seule différence avec la gestion des alertes d'instance réside dans la création d'un nouveau modèle. Lors de la création d'un modèle, une option appelée « Wizard level » apparaît.

Ce champ définit quels utilisateurs peuvent utiliser ce modèle pour créer des alertes à partir de l'Assistant.

  • No Wizard : Ce modèle ne sera pas disponible dans l'Assistant
  • Basique : Tout utilisateur ayant accès à l'Assistant peut utiliser ce modèle pour créer des alertes
  • Avancé :
  • Seuls les utilisateurs ayant un niveau d'accès avancé à la Métaconsole peuvent utiliser ce modèle (voir Créer un utilisateur).

Gestion d'alerte d'événements

Dans cette section, vous pouvez effectuer les actions suivantes :

  • Créer une alerte d'événement
  • Modifier/Supprimer/Désactiver/Couper les alertes d'événements

Par exemple, nous avons 4 instances où nous avons dans un agent la supervision du serveur apache de chacune des pages web situées dans les différentes instances. Nous créerons une alerte d'événement qui nous avertira lorsque cette supervision tombera en panne pour avertir l'administrateur que le service Apache doit être activé immédiatement, afin que vous ne deviez pas les créer manuellement une par une dans les agents des instances.

Pour en savoir plus sur son fonctionnement et sa configuration, vous pouvez consulter la section du manuel de Pandora FMS Système d'alerte.

Gestion de composants

Dans cette section, vous pouvez effectuer les actions suivantes :

  • Gestion des étiquettes
  • Gestion des groupes de modules
  • Gestion des systèmes d'exploitation

Gestion des étiquettes

Dans cette section, vous pouvez supprimer, modifier et créer de nouvelles étiquettes.

Création d'étiquettes

Pour créer une nouvelle balise, cliquez sur le bouton “ create tag ” et le formulaire suivant apparaîtra que vous devrez remplir :

Modifier/Supprimer les étiquettes

La liste des étiquettes fournit des options pour :

  • Modifier l'étiquette
  • Supprimer l'étiquette de la Métaconsole

Gestion des groupes de module

Dans cette section, vous pouvez supprimer et créer de nouveaux groupes de modules.

Création d'un groupe

Pour créer un nouveau groupe de modules, cliquez sur le bouton « Create module group » :

Effacer le groupe module

Gestion du système d'exploitation

Dans cette section, vous pouvez supprimer et créer de nouveaux systèmes d'exploitation du système.

Création du système d'exploitation

Pour créer un nouvel système d'exploitation, cliquez sur le bouton “ create OS ” et un formulaire apparaîtra que vous devrez remplir :

Supprimer système d'exploitation

Gestion des politiques

À partir de cette section, vous pouvez créer, modifier et supprimer des politiques.

Par exemple, vous avez 7 instances dans lesquelles 2 d'entre elles seront surveillées de la même manière, avec le même nom d'agents et de modules. Alors vous créez une politique qui vous permet de créer automatiquement des modules sur les agents, que vous synchronisez ensuite avec les différentes instances sans avoir à les créer une par une.

Création de politiques

Vous pouvez créer de nouvelles politiques en cliquant sur le bouton “ Create ”, qui affiche le formulaire suivant :

Pour une meilleure compréhension de la configuration des politiques, reportez-vous à la section Gestion des politiques.

Modifier/Supprimer les politiques

Dans la liste des politiques il y a des options permettant de modifier une politique et de la supprimer. Si une politique a des agents, le bouton de suppression est désactivé et un bouton pour supprimer tous ses agents apparaîtra à côté de celle-ci. Ce bouton entrera l’agent supprimé dans la file d’attente et, dès qu’il sera traité, le bouton de suppression de la politique sera à nouveau actif.

Gestion des catégories

Dans cette section, vous pouvez modifier, supprimer et créer de nouvelles catégories.

Création de catégories

Pour créer une nouvelle catégorie, cliquez sur le bouton « create category » :

Modifier/Supprimer des catégories

Dans la liste des catégories, des options sont disponibles pour :

  • Modifier la catégorie
  • Supprimer la catégorie de la Métaconsole

Gestion des serveurs

Dans cette section, vous pouvez supprimer les serveurs que vous avez installés dans la Métaconsole. Pour pouvoir exécuter toutes les fonctionnalités, les serveurs d’auto-approvisionnement et de migration doivent être activés.

Retour à l'index de documentation Pandora FMS

Synchronisation des composants

Cette option permet à l'utilisateur de synchroniser les groupes de la Métaconsole avec les instances.

Il est conseillé de ne pas avoir d'utilisateurs créés sur les instances et de les créer tous à partir de la Métaconsole afin d'avoir les mêmes utilisateurs sur celle-ci et sur les instances.

Synchronisation de tags

Cette option permet à l'utilisateur de synchroniser les groupes de la Métaconsole avec les instances.

Il est conseillé de ne pas avoir d'utilisateurs créés sur les instances et de les créer tous à partir de la Métaconsole afin d'avoir les mêmes utilisateurs sur celle-ci et sur les instances.

Synchronisation d'OS

Cette option permet à l'utilisateur de synchroniser les systèmes d'exploitation de la Métaconsole avec les instances.

Il est conseillé de ne pas avoir des systèmes d'exploitation créés sur les instances et de les créer tous à partir de la Métaconsole afin d'avoir les mêmes systèmes sur celle-ci et sur les instances.

Synchronisation de groupes de modules

Cette option permet à l'utilisateur de synchroniser les groupes de modules opérationnels de la Métaconsole avec les instances.

Il est conseillé de ne pas avoir des groupes de modules créés sur les instances et de les créer tous à partir de la Métaconsole afin d'avoir les mêmes groupes de modules sur celle-ci et sur les instances.

Retour à l'index de documentation Pandora FMS