Au lieu de Jabber-RPC (XEP-0009), peut-être plutôt les commandes ad-hoc (XEP-0050, [http://xmpp.org/extensions/xep-0050.html]). Alors que le premier demande un client spécifique pour envoyer les commandes XML-RPC qui vont bien, le second utilise un système de formalisation de "menus" qui le rend d'emblée utilisable avec tout client gérant les commandes ad-hoc. Sinon ça voudrait dire qu'il faut fournir à chaque fois une implémentation de l'émetteur XML-RPC en même temps que le récepteur. C'est dit un peu autrement dans [http://xmpp.org/extensions/xep-0050.html#prerequisites].
Sinon ça fait plaisir de voir que quelqu'un a pensé à ça au lieu des traditionnelles alertes utilisant simplement Jabber au lieu du mail. J'avais eu la même envie en 2005 alors que je faisais plein de surveillance Nagios, mais j'ai toujours eu la flemme de me lancer dans le code. Dans ce que tu dis, je pense que le point-clé est l'association entre les états de présence Jabber et les états de disponibilité d'un service donné.
Pour éviter les ajouts au roster, on peut même imaginer une solution sous forme de MUC (salon de discussion) où seraient présents les différents services + les personnes chargées de leur supervision. Pour des gros parcs, il peut y avoir plusieurs salons suivant comment on veut grouper les services à surveiller. L'état de présence de chaque service y serait encore visible, et en plus ces derniers pourraient diffuser des infos textuelles intéressantes. Si on veut plus générique et plus formel que les MUC, on peut peut-être même imaginer des profils PEP [http://xmpp.org/extensions/xep-0163.html] pour avoir une information plus complète, ou quelque chose de plus complet/complexe via PubSub.
Ça fait très longtemps que je n'ai plus fait de Nagios donc j'ai oublié comment c'est structuré, mais si les informations d'état des services sont centralisées sur le serveur Nagios, peut-être qu'au lieu de bots c'est possible d'avoir un unique transport (genre monitoring.ma-boite.com) qui fait ce boulot, qui tire ces informations au niveau du serveur Nagios directement, et qui fournit un JID distinct pour chaque machine/service qu'on veut surveiller, ce qui évite de faire tourner n fois le même bout de code.
# Quelques points de réflexion sur des structures possibles
Posté par davux . En réponse au journal Supervision et XMPP, why not ?. Évalué à 2.
Sinon ça fait plaisir de voir que quelqu'un a pensé à ça au lieu des traditionnelles alertes utilisant simplement Jabber au lieu du mail. J'avais eu la même envie en 2005 alors que je faisais plein de surveillance Nagios, mais j'ai toujours eu la flemme de me lancer dans le code. Dans ce que tu dis, je pense que le point-clé est l'association entre les états de présence Jabber et les états de disponibilité d'un service donné.
Pour éviter les ajouts au roster, on peut même imaginer une solution sous forme de MUC (salon de discussion) où seraient présents les différents services + les personnes chargées de leur supervision. Pour des gros parcs, il peut y avoir plusieurs salons suivant comment on veut grouper les services à surveiller. L'état de présence de chaque service y serait encore visible, et en plus ces derniers pourraient diffuser des infos textuelles intéressantes. Si on veut plus générique et plus formel que les MUC, on peut peut-être même imaginer des profils PEP [http://xmpp.org/extensions/xep-0163.html] pour avoir une information plus complète, ou quelque chose de plus complet/complexe via PubSub.
Ça fait très longtemps que je n'ai plus fait de Nagios donc j'ai oublié comment c'est structuré, mais si les informations d'état des services sont centralisées sur le serveur Nagios, peut-être qu'au lieu de bots c'est possible d'avoir un unique transport (genre monitoring.ma-boite.com) qui fait ce boulot, qui tire ces informations au niveau du serveur Nagios directement, et qui fournit un JID distinct pour chaque machine/service qu'on veut surveiller, ce qui évite de faire tourner n fois le même bout de code.