Migration Centreon 19.10 → 24.10 : retours d’expérience et compatibilité NSClient++ / SNMP ?

Bonjour, je vais pouvoir vous faire des retours sur ce sujet.

Spécifiquement nous avons organisé une migration de Centreon 19.04 vers la Centreon 23.10.
Cette migration ne pouvais pas se faire sur le même OS ce qui a impliqué une migration risquée:
Migrer a la fois une version majeure de Centreon et migrer l’OS de CentOS 7 vers RHEL 9.

Cela n’est pas supportée par les processus officiels mais était nécessaire dans notre cas d’usage.

Par ailleurs nous n’avions pas de remote server, que des centraux et des pollers.

Cela a impliqué beaucoup de tests et de préparation afin d’assurer le fonctionnement.

Pour cela nous avons appliqué tout le process via Ansible.

Mettre en place une nouvelle machine avec Centreon 23 a ce moment la est simple, vous suivez le processus officiel et tout se met en place correctement.

Les problèmes arrivent lors de la migration de données. Etant donné que les deux bases de données ont des structures différentes, on ne peut pas directement importer l’ancienne sur le serveur.
La solution a été de récupérer tout les scripts de migration de base de donnée intermédiaire, et de les appliquer a la base de donnée du serveur précédent avant de faire un export.

Par ailleurs les autres dossiers centreon ont du être migrés pour assurer la continuité (comme les fichiers rdd) et pour que les graphes puissent être reconstruits.

Un piège que nous avons rencontrés est le switch vers l’usage de ZMQ sur les communications de pollers. En CentOS nous utilisions SSH et donc il faut également penser a migrer les configurations ssh des utilisateurs centreon-engine pour ne pas casser les communications entre les pollers.

Par ailleurs il peut être compliqué de s’assurer de la migration de tout les scripts de commandes entre l’ancienne et la nouvelle machine, donc nous avions migré tout le dossier /usr/lib64/nagios/plugins, et forcé la réinstallation des packages sur la nouvelle machine pour les avoir a jour.

Une fois tout migré, un risque a considérer est la gestion des permissions linux. En effet nous avions fait cette migration via du scp entre la machine 1 et 2, et il était possible d’avoir des problématiques de droits sur les dossiers entre les machines. Donc il faut garder un oeil la dessus.

Une fois tout migré, les exports de configuration doivent être fonctionnels et tout dois s’être bien passé. De notre coté cette préparation et migration a mis quelques mois avec des productions pilotes pour vérifier que tout se passait bien.

Ce sont les aspects principaux qui me viennent en tête concernant cette migration complexe.

Pour ce qui est du monitoring cible, nous n’avons pas eut de problème, nous avons pu continuer a utiliser du NSClient ou du NRPE en v2c.

Nous avons eut quelques complications sur certaines très vielles machines car les nouvelles versions du check_nrpe demandaient un certain niveau de sécurité. Voir ce post pour quelques détails NRPE - v3 Enhanced Security

je n’ai pas de retours sur l’usage de SNMP en tout cas pour ce qui est de l’usage des traps, ni pour l’usage de CMA.

En espérant que ce retour vous aidera.

Merci pour ton retour très clair ! Juste une question parce que je suis en open-source et que presque tous mes modèles Windows sont créés manuellement meme les firewalls et les switchs (OS-Windows-NRPE-custom + plein de customs faits à la main) : Après migration big bang 19.10 → 25.10, est-ce que mes anciens modèles NRPE restent fonctionnels tels quels, ou je suis obligé de tout recréer avec les nouveaux modèles CMA le même jour ?

J’ai 298 hosts  en prod avec beaucoup de clients, donc je préfère ne rien casser d’un coup. Merci d’avance !

Si vous migrez tel quel, vos commandes et services devraient fonctionner sans problème.
La limitation que je mentionne est sur les outils cli que vous pourriez utiliser comme par example le check_nrpe qui en version a jour peut bloquer pour des raisons de sécurité.

Je vous recommanderais dans un premier temps de faire votre migration dans un premier temps en conservant vos services et templates tels quels. Dans un second temps vous pourrez étudier l’intégration de CMA dans vos services mais faire ça progressivement.

L’objectif est d’éviter de tout casser et d’avoir trops de couches de changements en une seule fois.