Depuis que j'utilise Nagios j'ai toujours pensé que la meilleure chose à faire pour son évolution était de le réécrire entièrement à la mode Unix avec un programme pour chaque fonction mais que le fait bien avec des interfaces de communication bien définies. Ca facilite l'extensibilité (aussi bien en terme de fonctionnalités que de performances). Nagios a un historique énorme qui le rend désormais très difficile à faire évoluer. C'est fondamentalement une simple ordonnanceur de checks mais il mélange beaucoup trop de chose à ce rôle qui devraient être des addons. Il faut le modulariser, profiter de l'état de l'art en termes de programmation réseau asynchrone.
Le fait de conserver la compatibilité avec Nagios pour la configuration et les checks n'est pas optimal (la configuration mériterait d'avoir une syntaxe plus claire, de pouvoir être générée à partir d'autres sources comme des inventaires sous forme d'annuaire ou de base de données ; certains checks mériteraient d'être intégrés au moins pour les cas de figure les plus communs comme le SNMP, un peu à la manière de Cacti) mais c'est le choix gagnant vu la base installée.
En plus en Python ! Si tu persistes, j'aurai très envie d'y contribuer.
# Enfin !
Posté par vjm . En réponse au journal Nagios va-t-il quitter le C pour le Python?. Évalué à 2.
Le fait de conserver la compatibilité avec Nagios pour la configuration et les checks n'est pas optimal (la configuration mériterait d'avoir une syntaxe plus claire, de pouvoir être générée à partir d'autres sources comme des inventaires sous forme d'annuaire ou de base de données ; certains checks mériteraient d'être intégrés au moins pour les cas de figure les plus communs comme le SNMP, un peu à la manière de Cacti) mais c'est le choix gagnant vu la base installée.
En plus en Python ! Si tu persistes, j'aurai très envie d'y contribuer.