Command Center

Command Center

À partir de la version 756 de Pandora FMS les système de synchronisation a été conçu de zéro pour des environnements avec le mode centralisé, en le rendant plus rapide et efficace, puisque les changements seront répliqués aux nœuds automatiquement sans besoin de synchronisation manuelle, comme avant.

Ce changement laisse le système précédent en désuétude, donc dans les environnements où il était actif, il faudra passer par le système de fusion automatique précédent (merge) pour utiliser le nouveau système de centralisation et pouvoir garantir l'intégrité des données.

Lors de la mise à jour, tous les environnements Métaconsole déjà centralisés seront obligés de passer par le nouveau Command Center pour pouvoir être à nouveau centralisés correctement.

Le Command Center va mélanger les différents éléments des bases de données des nœuds et de la Métaconsole (de ceux qui doivent être gérés depuis la Métaconsole) de la manière suivante: Un ordre de priorité sera établi entre les nœuds et la Métaconsole, plaçant les éléments les plus prioritaires en haut de la liste et en bas les moins prioritaires.

Par exemple :


Seulement les nœuds configurés dans la Métaconsole qui ne sont pas désactivés sont tenus sur compte pour le processus de mélange.

Cette liste de priorité est utilisée pour les cas où le même élément existe dans les différents nœuds mais a des configurations différentes. Par exemple, que les 2 nœuds et la Métaconsole ont le groupe « Bases de données ». Avec cet ordre de priorité, la configuration de l'élément le plus prioritaire sera prise pour tous, dans l'exemple de la Métaconsole.

Dans un autre cas, si par exemple seuls les nœuds 1 et 2 avaient une politique appelée « Windows », pour tous les nœuds et la Métaconsole, la configuration de cette politique serait celle du nœud 1 (on saute la Métaconsole car elle ne l'a pas).


Uniquement pour les propres paramètres de la politique (groupe, description,…). Les modules, alertes et autres éléments de la politique sont considérés comme des éléments distincts indépendants de la politique et sont donc également fusionnés.


Dans le cas des politiques il serait l'élément le plus particulier de tous les éléments synchronisés par son mode de configuration, suique chaque plugin, module et alerte… sont traités comme des éléments independantes et pas comme une partie de la configuration de la politique. C'est à dire, dans l'example précédent de la politique et le regardant seulement avec des modules, si nous avons :

La sortie du centre de commande serait:

Cela permet au résultat d'avoir autant de configurations différentes que possible afin que vous puissiez maintenant les gérer depuis la Métaconsole.

Éléments centralisés par le Command Center

Les éléments suivants sont ceux qui sont centralisés depuis le nouveau Command Center:

  • Utilisateurs : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Command Center ceux qui on le même ID seront considérés comme le même utilisateur (suivant les règles de priorité décrites avant).
  • Profils d'utilisateur : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Command Center ceux qui on le même nom seront considérés comme le même profil (suivant les règles de priorité décrites avant)..
  • Groupes d'agents : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Command Center ceux qui on le même nom seront considérés comme le même group (suivant les règles de priorité décrites avant).

Vérifiez que vous ajustez le paramètre autocreate_group des fichiers de configuration des serveurs pandora_server.conf par un ID de groupe valide après avoir unifié depuis le Command Center.

  • Collections de fichiers : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Command Center ceux qui on le même nom court seront considérés comme la même collection (suivant les règles de priorité décrites avant).
  • Modèles d'alerte : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Command Center ceux qui on le même nom seront considérés comme le même modèle (suivant les règles de priorité décrites avant).
  • Commande d'alerte : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Command Center ceux qui on le même nom seront considérés comme la même commande (suivant les règles de priorité décrites avant).
  • Actions d'alerte : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Command Center ceux qui on le même nom seront considérés comme la même action (suivant les règles de priorité décrites avant).
  • Plugins de serveur : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Command Center ceux qui on le même nom et exécution seront considérés comme le même plugin (suivant les règles de priorité décrites avant).
  • Système d'exploitation : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Command Center ceux qui on le même no seront considérés comme le même système d'exploitation (suivant les règles de priorité décrites avant).
  • Étiquettes de modules : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Command Center ceux qui on le même nom seront considérés comme la même étiquette (suivant les règles de priorité décrites avant)..
  • Catégories de modules : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Command Center ceux qui on le même nom seront considérés comme la même catégorie (suivant les règles de priorité décrites avant).
  • Groupes de modules : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Command Center ceux qui on le même nom seront considérés comme le même groupe (suivant les règles de priorité décrites avant).
  • Groupes de composants : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Command Center ceux qui on le même nom seront considérés comme le même groupe (suivant les règles de priorité décrites avant).
  • Composants réseau : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Command Center ceux qui on le même nom et système d'exploitation seront considérés comme le même composant (suivant les règles de priorité décrites avant).
  • Composants locales : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Command Center ceux qui on le même nom et système d'exploitation seront considérés comme le même composant (suivant les règles de priorité décrites avant).
  • Modèles de composants : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Command Center ceux qui on le même nom seront considérés comme le même modèle (suivant les règles de priorité décrites avant).
  • Module d'inventaire : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Command Center ceux qui on le même nom et système d'exploitation seront considérés comme le même module (suivant les règles de priorité décrites avant).
  • Politiques de supervision : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Command Center ceux qui on le même nom seront considérés comme la même politique (suivant les règles de priorité décrites avant).
  • Modules de politiques : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Command Center ceux qui on le même nom dans un politique avec le même nom seront considérés comme le même module (suivant les règles de priorité décrites avant).
  • Modules d'inventaire de politiques : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Command Center ceux qui on le même nom et système d'exploitation dans une politique avec le même nom seront considérés comme le même module (suivant les règles de priorité décrites avant).
  • Plugins de politiques : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Command Center ceux qui on la même exécution dans un politique avec le même nom seront considérés comme le même plugin (suivant les règles de priorité décrites avant).
  • Collections de politiques : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Command Center ceux qui on le même nom court dans une politique avec le même nom seront considérés comme la même collection (suivant les règles de priorité décrites avant).
  • Alertes et alertes externes de polítiques : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Command Center ceux qui on le même modèle sur le même nom de module dans une politique avec le même nom seront considérés comme la même alerte (suivant les règles de priorité décrites avant).
  • Actions sur des alertes et alertes externes de politiques : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Command Center ceux qui on le même nom sur le modèle sur le même nom de module dans un politique avec le même nom seront considérés comme la même action (suivant les règles de priorité décrites avant).
  • Agents dans les politiques : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Command Center ceux qui sont dans des politiques avec le mÊme nom seront considérés comme agents dans une même politique. Les journaux d'agents dans les politiques de la Métaconsole seront écartés et seulement les journaux des nœuds teront tenus sur compte (où l'application est effective).
  • Agents : Les agents peuvent être gérés dans le nœud, à exception de sa élimination qui doit se faire dans la Métaconsole.

Les sections où ces éléments sont gérés de manière centralisée seulement peuvent se gérer depuis la Métaconsole. Dans le cas d'accèder à ces éléments depuis les nœuds, vous ne pouvez que les lister, et vous ne trouverez pas les options d'édition et de création. Vous verrez un avis qui vous indiquera que l'énvironement Test sous mode centralisé, avec un lien à l'administrateur à la section de ña Métaconsole correspondante pour la configuration de ces éléments.

Prérequis pour lancer la fusion de la base de données Command Center

  • La Métaconsole doit pouvoir se connecter à toutes les bases de données et à toutes les API de nœuds. Assurez-vous que la configuration « Consoles setup » est correcte et que les indicateurs sont verts.

  • Les consoles des nœuds doivent pouvoir se connecter à la base de données de la Métaconsole. Normalement, ce ne sera pas un problème, à moins que vous n'ayez les consoles sur des ordinateurs autres que les serveurs Pandora FMS. Assurez-vous que les paramètres de configuration SetupEnterprise pour la Métaconsole sur les nœuds sont corrects.

  • Les serveurs de tous les nœuds doivent pouvoir de connecter à l'API de la Métaconsole. On recommande de configurer l'URL de la politique dans la Métaconsole

  • Les serveurs de tous les nœuds doivent avoir leur configuration API correcte dans “pandora_server.conf” ou leur configuration de URL publique dans le Setup de la conosle. Si vous ne l'avez pas configuré, les serveurs doivent s'héberger dans les mêmes machines dans lesquelles votres consoles se trouvent.
console_api_url http://localhost/pandora_console/include/api.php
console_api_pass pandora

  • Chaque nœud doit pouvoir se connecter à son propre base de données d'historique.

  • Tous les nœuds et la Métaconsole doivent être dans la même version.
  • Tous les nœuds et la Métaconsole doivent être dans le même MR (mise à jour du schéma de la base de données).

  • Tous les nœuds et la Métaconsole doivent avoir la même taille de collection maximale configurée dans le Setup.

  • Pour éviter les erreurs, les nœuds et la Métaconsole doivent avoir le paramètre memory_limit de fichier de configuration php.ini mis à -1, c'est-à-dire sans limite, mais uniquement pour le processus de fusion. Après l'avoir terminé, il est recommandé de le remettre à la valeur précédente. C'est le cas, puisque beaucoup de mémoire est utilisée pour fusionner les nœuds, et dans un très grand environnement (avec de nombreux éléments différents) une grande quantité de mémoire peut être utilisée, de cette façon vous vous assurez que le système peut utiliser toute la mémoire disponible. Si les éléments à fusionner dépassent la valeur de la mémoire physique disponible sur le serveur, le Command Center échouera en raison d'une erreur inattendue, et dans les journaux de la console/Apache, vous verrez la ligne indiquant l'excès de mémoire atteint.
  • Tous les nœuds doivent avoir une valeur pour le paramètre post_max_size de fichier de configuration php.ini supérieure ou égale par rapport à la taille des collections configurées pour le même paramètre dans la Métaconsole. La valeur doit être aussi grand que la taille de la collection de fichiers plus grande que vous avez.
  • Tous les nœuds et la Métaconsole doivent avoir une valeur pour le paramètre upload_max_filesize du fichier de configuration php.ini supérieure ou égale à la valeur de upload_max_file_size de php.ini.
  • Tous les nœuds et la Métaconsole doivent avoir space suffisant dans le disque qui hebérge son directoire “attachment” pour pouvoir faire les backups (sauvegardes) de la base de données et collections.

  • Tous les nœud et la Métaconsole doivent avoir la date et l'heure de l'ordinateur correctement configuré (on recommande l'utilisation des serveurs NTP).


Si toutes ces exigences ne sont pas remplies, la fusion de nœuds ne sera pas effectué et une erreur sera générée. Si vous consultez les erreurs du résultat, cela vous donnera un message des exigences encore en suspens.

Il est important une fois l'unification de la base de données effectuée que la valeur correspondante du memory_limit de fichier de configuration php.ini soit remise (rappelez-vous que pour que la modification prenne effet, le service apache httpd doit être redémarré)

Recommandations avant le lancement du Command Center

Bien qu'ils ne sont pas des exigénces pour le processus d'unification des bases de données con récommande fortement de faire ces actions :

  • Arrêter les serveurs de tous les nœuds et la Métaconsole pendant la durée du processus. Comme les éléments fondamentaux tels que les groupes vont être modifiés, leurs identifiants peuvent être modifiés et il n'est pas recommandé que le processus serveur inclue de nouvelles références à l'environnement tant qu'il dure. Cependant, le serveur en cours d'exécution ne devrait pas être un problème dans la plupart des cas.
  • Désactivez temporairement le processus cron pandora_db pour la durée du processus, pour les mêmes raisons que le serveur.


Lorsque le processus de fusion démarre, les nœuds et la Métaconsole passent en mode maintenance. Le but de ceci est le même que la recommandation d'arrêter les serveurs et lepandora_db, pour empêcher un utilisateur de modifier des éléments au cours du processus, ce qui peut provoquer des erreurs ou des incohérences.

Exécution du processus d'unification

Le processus d'unification a 2 étapes différentes, une première étape pour synchroniser les différents éléments gérables depuis la Métaconsole et une seconde étape pour mettre à jour les réferences dans les événements à ces éléments centralisés. Ce processus se fait de cette manière pour permettre que la console soit accesible encore un fois aussi tôt que possible, puique la mise à jour des éléments est la partie du processus qui peut prendre lus de temps car elle a habituellement la plus grande quantité d'information. Les deux étapes sont divisés en deux sous-étapes diférenciées en deux barres de progrès.

Phase 1 éléments

Dans cette étape les éléments trouvés dans les bases de données de tos les nœuds gérables depuis la Métaconsole sont synchronisés. Il s'agit du processus d'unification et est sous divisé en deux étapes, chacune avec sa barre de progrès :

  • Initialize: Il vérifie toutes les exigences précédentes, génère les sauvegardes correspondantes (si les exigences sont remplies) en cas d'échec d'une partie du processus et génère en mémoire le résultat de la fusion des bases de données. Si ce processus échoue pour une raison quelconque, les bases de données n'auront pas encore été modifiées, il ne sera donc pas nécessaire de restaurer les sauvegardes. Les sauvegardes sont stockées dans chaque nœud/Métaconsole dans le répertoire: pandora_console/attachment/merge_backups
  • Apply: Si la phase d'initialisation précédente a réussi, le résultat de l'unification commencera à être appliqué à tous les nœuds et à la Métaconsole. Ce processus est séquentiel par ordre de priorité, donc lorsque il termine avec un, il commencera par le suivant.

Si des erreurs surviennent au cours de ce processus (par exemple, perte de connexion avec une base de données), le processus lui-même tentera de restaurer les sauvegardes générées (une troisième barre de progression rouge apparaîtra qui marquera la progression de la restauration).


Si la raison de l'échec empêche la récupération des sauvegardes, la récupération doit être effectuée manuellement.



PArfois vous pouvez trouver des erreurs, par exemple la perte de connexion momentané entre la Métaconsole et la base de données d'un nœud ou l'imposibilité de créer une sauvegarde car vous n'avez pas d'espace dans le disque, donc il est possible que le message d'erreur montrè soit générique. Si c'est le cas, veuillez contacter l'équipe de support Pandora FMS pour recevoir de l'assistance.

Phase 2 événements

Dans cette étape les références existantes dans les événements aux différents éléments synchronisés seront mis à jour (par exemple à groupes). L'étape est sous divisé en la mise à jour des événements de la base de données principale et la mise à jour des événements de la base de données historique et seulement affectera les événements qui existent avant de lancer le processus d'unification. Les nouveaux événements générées après avoir centralisé l'environnement auront toutes les références correctement et ne será pas nécessaire de les mettre à jour.

  • Base de données principale: Comme les événements sont un grand volume d'informations qui sont également affectées, ce processus de mise à jour se fait en parallèle avec le fonctionnement normal de l'environnement déjà fusionné. À ce stade, le serveur et pandora_db peuvent être redémarrés normalement et les utilisateurs standard peuvent à nouveau accéder à la console. Bien sûr, vous verrez dans la vue des événements la barre de processus de mise à jour pour tous les événements, donc pour cette partie vous pouvez encore avoir des incohérences (en ce qui concerne les filtres par exemple) uniquement pour les événements qu'il y avait avant la fusion. De nouveaux événements seraient générés normalement. Cette phase et ce processus sont lancés par chacun des nœuds, via une tâche spécifique dans le cron de la console. En raison du volume d'informations, la tâche peut être lourde et longue. Dans la mesure du possible, moins l'environnement est chargé à ce moment-là, mieux c'est (essayez de le lancer en dehors des heures les plus chargées sur Pandora FMS).
  • Base de données historique : Ce serait la continuation du point précédent, mettant à jour les événements dans la base de données historique sous les mêmes caractéristiques déjà indiquées.

Environnement déjà centralisé par le biais du command Center

Une fois la phase 1 terminée, l'environnement sera considéré comme centralisé, et à partir de là vous pourrez tout gérer depuis la Métaconsole. La synchronisation des éléments a également été modifiée, désormais le processus pandora_ha de chaque nœud est en charge de synchroniser sa base de données avec celle de la Métaconsole.

Lorsque nous apportons une modification à la Métaconsole (par exemple, créer un utilisateur), cela met en file d'attente les requêtes nécessaires dans la base de données pour les nœuds (INSERTS, UPDATES, etc.) que pandora_ha lit de manière ordonnée et exécute dans chaque server_threshold. Cela garantit que si un serveur est en panne pendant un certain temps, lorsqu'il est redémarré, il peut reprendre sa vitesse correctement.

Cette liste de requêtes en attente peut être consultée à partir de la Métaconsole dans la section Consoles setup. Si pour une raison quelconque une requête échoue, le nœud ne continuera pas avec les autres, nous verrons une erreur dans Consoles setup et il sera nécessaire de la traiter manuellement par un administrateur. Dans la plupart des cas, vous devriez pouvoir le résoudre en lançant à nouveau le processus de fusion dans le Command Center.

Inclusion de nouveaux nœuds

Si, dans un environnement déjà centralisé, vous ajoutez un nouveau nœud, en éditez un ou réhabilitez un existant qui a été laissé de côté, il sera nécessaire de passer à nouveau par le Command Center.

Un message s'affichera pour conseiller à l'administrateur d'effectuer cette tâche, tandis que le nœud restera verrouillé et inaccessible, dans un état en attente de fusion. Les changements ne seront pas réalisés ni vous aurez accès à la console jusqu'au processus d'unification.


Si une modification est requise dans la console pour corriger un bogue dans le processus de fusion (comme l'application d'un oum), l'élément peut être supprimé de la liste des nœuds pour le déverrouiller temporairement.

Retour à l'index de documentation de Pandora FMS