Dans un précédent journal, on parlait de Nagios, notamment le fait que celui-ci soit susceptible d'effectuer un nombre conséquent de vérifications à interval régulier sur des machines.
Si on prend uniquement le cas de la supervision de serveurs et non pas les équipements réseaux via SNMP avec les switchs/routeurs. Pourquoi alors ne pas utiliser XMPP ?
Imaginons l'hypothèse suivante : on déploie un agent sur chaque machine qui est en fait un simple bot XMPP.
Grâce à toutes les XEP disponibles ont peut facilement faire un système de supervision "temps réel". Chaque agent utilise un JID différent, avec la présence on connaît l'état de chaque machine.
Avec la XEP-0009 (XML-RPC), on peut passer n'importe quel commande à un agent...
On a du publish/subscribe, on peut faire du push, bref pas besoin de perdre sont temps à checker à interval régulier un service...
On peut même imaginer faire une sorte de SSH over XMPP...
XML c'est extensible, on peut y rajouter tout ce que l'on veut.
On peut gérer des milliers de machines sans aucun problème. C'est décentralisé... bref un vrai botnet :)
Après on peut faire une console d'administration pour smartphone, un client lourd pour les desktops, un client web avec BOSH, etc... Cette console d'administration serait elle-même un simple bot XMPP qui peut se situer n'importe où.
D'ailleurs on est même pas obliger de se restreindre à superviser un seul réseau local, mais des machines situées dans des réseaux totalement distinct.
En googlant un peu, je n'ai pas trouvé tant de chose que ça, seulement EngineYard qui a développé vertebra pour gérer sa plateforme de cloud computing. (http://www.engineyard.com/vertebra/about )
Alors, pensez-vous que XMPP peut être intéressant pour superviser un parc de machine, plutôt qu'une usine a gaz gérée de manière centralisée qui va passer son temps à faire du polling ?
Journal Supervision et XMPP, why not ?
13
déc.
2009
# gestion de parc
Posté par BAud (site web personnel) . Évalué à 6.
http://linuxfr.org//2008/06/21/24241.html Spacewalk : Red Hat Network Satellite devenu libre
Il utilise XMPP pour dialoguer.
Cela permet de gérer tout un parc de serveurs et leurs mises à jours de logiciels.
[^] # Re: gestion de parc
Posté par Frédéric . Évalué à 2.
[^] # Re: gestion de parc
Posté par zebra3 . Évalué à 2.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
# xmpp adapté ?
Posté par Psychofox (Mastodon) . Évalué à 1.
Alors, pensez-vous que XMPP peut être intéressant pour superviser un parc de machine, plutôt qu'une usine a gaz gérée de manière centralisée qui va passer son temps à faire du polling ?
Je ne vois pas vraiment en quoi l'utilisation de xmpp enlève en quoi que ce soit le côté usine à gaz d'un outil de supervision. Nagios peut fonctionner autant de manière active que passive. Au bout du compte, il y'a toujours un moment ou tu dois rafraichir les informations de status des différents services à surveiller.
[^] # Re: xmpp adapté ?
Posté par Psychofox (Mastodon) . Évalué à 0.
[^] # Re: xmpp adapté ?
Posté par Frédéric . Évalué à 2.
Si tu veux checker un certains nombre de services sur un certains nombres de serveurs, tu fais quoi, tu as un script/plugins qui va aller vérifier à intervale régulier que par exemple ton service est toujours ok.
Au final, tu va te retrouver avec plein de scripts qui vont pinger, vérifier que tel ou tel port est ouvert, etc, à interval régulier le tout en parallèle.
Ici dans mon hypothèse, tu as un agent sur le serveur, qui va t'avertir que tel service est down en poussant sur le réseau cette info. Sur ta console d'administration si ton serveur est déconnecté du réseau, tu le sait immédiatemment.
Après, pour vérifier que tel service fonctionne correctement, il existe surrement des trucs moderne dans nos kernels basé sur les évènements qui te dis automatiquement que le port 80 n'est pas plus en écoute sur telle interface ou que le processus avec le pid 845 vient de se terminer, etc... A l'époque de djbdns daemontools était bien capable de superviser des services. On a bien inotify qui permet de monitorer les changements sur le système de fichiers de manière évènementiel.
En gros, il suffit de programmer le système de manière évènementiel, à chaque fois qu'un évènement se déclenche une alerte est poussée via XMPP... et toi dans la milliseconde tu recoit un beau message sur iphone que te dis que ton serveur est down.
Après, au final ça se trouve ça utilise moins de bande passante que du snmp, du ping ou autre car ça cause sur réseau uniquement en cas d'évènement et pas toutes les 5 minutes.
Ensuite XMPP, c'est décentralisé, tu peut aussi monitorer des serveurs qui ne sont pas sur le même réseau que ton serveur nagios.
[^] # Re: xmpp adapté ?
Posté par cleek . Évalué à 2.
Si tu veux checker un certains nombre de services sur un certains nombres de serveurs, tu fais quoi, tu as un script/plugins qui va aller vérifier à intervale régulier que par exemple ton service est toujours ok.
Au final, tu va te retrouver avec plein de scripts qui vont pinger, vérifier que tel ou tel port est ouvert, etc, à interval régulier le tout en parallèle.
En pratique, tu en as souvent un par type de service et il est utilisé pour toutes les machines. Donc il y en a pas tant que ça. S'il y a des subtilités pour l'invoquer, tu définis éventuellement plusieurs commandes dans nagios qui vont utiliser ce script de telle ou telle manière.
Ici dans mon hypothèse, tu as un agent sur le serveur, qui va t'avertir que tel service est down en poussant sur le réseau cette info. Sur ta console d'administration si ton serveur est déconnecté du réseau, tu le sait immédiatemment.
On a les checks passifs sur Nagios qui font exactement ça. Le soucis avec ce type de choses c'est que t'oublies tout ce qui est graphe.
Par ailleurs, on peut très bien envoyer des alertes depuis Nagios via XMPP, on délègue juste tout ce qui est ordonnancement and co à Nagios lui-même.
[^] # Re: xmpp adapté ?
Posté par bubar🦥 (site web personnel) . Évalué à 2.
;-)
# Peu importe le protocole
Posté par Etienne Bagnoud (site web personnel) . Évalué à 1.
Pourquoi alors ne pas utiliser XMPP ?
Pour de la supervision le XML me semble déjà très lourd (entendre verbeux, ici).
Grâce à toutes les XEP disponibles ont peut facilement faire un système de supervision "temps réel".
XEP va automagiquement supprimer toutes les latences des tests, augmenter les bandes passantes des réseaux et utiliser la téléportation ?
on peut faire du push
Oui je vois assez 20k services envoyer leur état en temps réel à une machine avec du XML ... C'est claire que ça va alléger la charge de décoder 20k messages XML en temps réel. Le push peut-être intéressant en supervision dans certains cas et est disponible sur nagios, mais ce n'est pas _la_ solution pour alléger le tout.
Alors, pensez-vous que XMPP peut être intéressant pour superviser un parc de machine, plutôt qu'une usine a gaz gérée de manière centralisée qui va passer son temps à faire du polling ?
XMPP est un protocole de communication. On pourrait faire la même chose avec du HTTP, du FTP, ... peu importe. C'est pas un protocole qui va changer amener de la vitesse (bien qu'il peut changer). XMPP va rencontrer le même problème que n'importe quel autre protocole.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Peu importe le protocole
Posté par Frédéric . Évalué à 3.
Oui je vois assez 20k services envoyer leur état en temps réel à une machine avec du XML ... C'est claire que ça va alléger la charge de décoder 20k messages XML en temps réel. Le push peut-être intéressant en supervision dans certains cas et est disponible sur nagios, mais ce n'est pas _la_ solution pour alléger le tout.
Pourtant à l'origine XMPP à été développé pour faire de la messagerie instantanée, et donc le fait de pouvoir gérer un nombre important de chose simultanement est pris en compte dès le départ dans la définition du protocole. Pourquoi tous les serveurs XMPP se vantent alors de pouvoir gérer plusieurs milliers/millions d'utilisateurs ?
Après je ne pensais pas forcement du côté des performances, c'est certain que balancer des paquets icmp ou udp prendera moins de bande passante que d'envoyer des données en XML.
En XMPP je voyais plutôt le côté extensiblité et nouvelles possiblités par rapport à Nagios ou autre.
[^] # Re: Peu importe le protocole
Posté par Psychofox (Mastodon) . Évalué à 2.
comme ?
[^] # Re: Peu importe le protocole
Posté par Frédéric . Évalué à 3.
Imagine, qu'en plus d'avoir un système de supervision, tu peux avoir un système de controle a distance de tes machines, un système de déploiements de logiciels, etc, pas seulement sur tes serveurs mais aussi sur ton parc de postes clients...
Bon ok ça existe déjà :)
[^] # Re: Peu importe le protocole
Posté par Prae . Évalué à 1.
on appelle cela du marketing.
[^] # Re: Peu importe le protocole
Posté par vg . Évalué à 6.
À coté de ça le protocole est extensible, sécurisé et standard, il existe une pléthore de serveur qui tiennent très bien la charge (et décodent 20k de messages XML en une fraction de secondes) sans compter les bibliothèques coté client.
Et bien sur que si l'utilisation d'un protocole peut améliorer la vitesse, XMPP sera beaucoup beaucoup plus lent que HTTP pour le transfert de gros fichiers binaires, mais sera plus rapide pour l'envoie de petites requêtes espacées dans le temps (sans parlé du push).
[^] # Re: Peu importe le protocole
Posté par Etienne Bagnoud (site web personnel) . Évalué à -1.
Non mais la taille standard d'un paquet XMPP compressé est de 34ko (chiffre aussi sorti de mon chapeau, alors pas besoin de références).
les plus courantes sont les requêtes de présence qui sont pour la plupart inutile pour la supervision (genre indiqué quel musique l'utilisateur écoute, ou si il est en train de taper au clavier).
Non, pas besoin de savoir si un service est fonctionnel ou pas. C'est justement ça qui est important, il me semble, dans la supervision. Alors oui on peut imaginer que ce soit la machine qui envoie un message quand il y a un problème. Cool, je coupe tous les câbles réseau et il n'y a plus de problèmes ... pas de message, pas de problème.
Non, il faut que régulièrement on ait un "hello, je suis vivant", sinon comment peut-on savoir que le système fonctionne ou pas. Donc indication de présences
(et décodent 20k de messages XML en une fraction de secondes)
Dans mon chapeau j'ai tiré 10h de décodage ... C'est beaucoup ça, je retire. Ah 36.34s pour 20k messages sur une machine bi-Xeon octo-core et 64G de Ram dédiée au décodage uniquement.
Et bien sur que si l'utilisation d'un protocole peut améliorer la vitesse, XMPP sera beaucoup beaucoup plus lent que HTTP pour le transfert de gros fichiers binaires, mais sera plus rapide pour l'envoie de petites requêtes espacées dans le temps (sans parlé du push).
Bien entendu qu'un protocole peut apporter des améliorations de vitesses, mais de l'ordre du détail dans beaucoup de cas et plus important dans certain cas. Mais dans ce cas là, je penses pas que ce soit pertinent de vouloir mettre du XMPP là.
XMPP arrive ici parce qu'actuellement c'est un protocole "hype", "in", "cool", ... C'est juste la mode de mettre XMPP partout dès que possible, mais c'est pas un protocole qui solutionne tous les maux de la planète. Actuellement la supervision fonctionne sans XMPP, il n'y a pas besoin de le mettre.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Peu importe le protocole
Posté par vg . Évalué à 5.
Pour les requêtes de présence tu interprète mal, j'ai précisé que 'la plupart' était inutiles notamment les plus verbeuses, et non pas la peine d'envoyer un 'hello je suis vivant' régulièrement, t'as juste à le faire si tu change d'état et si la connexion se coupe le serveur prévient les autres clients.
Si tu veux des benchs sur les parseurs XML (au passage Ejabberd utilise C-expat) :
http://www.xml.com/lpt/a/36
Bien sûr je considère des tailles de paquets habituellement manipulés par un serveur XMPP.
XMPP n'est pas que 'hype', 'in' et 'cool' (c'est tout à son honneur) ... mais aussi standard[1], techniquement mature et complet[2] et disposent de nombreuses implémentations[3].
[1] : http://www.ietf.org/rfc/rfc3920.txt
[2] : http://xmpp.org/extensions/
[3] : http://xmpp.org/software/servers.shtml
[^] # Re: Peu importe le protocole
Posté par Etienne Bagnoud (site web personnel) . Évalué à 4.
Références, références ... Si XMPP va aussi vite que ça et prend aussi peu de place, on devrait trouver plein de document expliquant ceci.
Pour les requêtes de présence tu interprète mal, j'ai précisé que 'la plupart' était inutiles notamment les plus verbeuses, et non pas la peine d'envoyer un 'hello je suis vivant' régulièrement, t'as juste à le faire si tu change d'état et si la connexion se coupe le serveur prévient les autres clients.
Il faut que tu m'expliques. L'idée de base présentée ici c'est que les serveurs surveillées envoient eux même un message quand il y a un problème. Si tu appliques cette solution, tu dois envoyer régulièrement un message pour dire que "je suis vivant". Sinon tu reviens à l'idée d'un serveur qui "poll" les clients et ça élimine une partie des raisons d'utiliser XMPP.
Donc soit tu fais les présences, soit tu fais du poll commen actuellement (à noter que le "push" existe aussi sur nagios).
XMPP n'est pas que 'hype', 'in' et 'cool' (c'est tout à son honneur) ... mais aussi standard[1], techniquement mature et complet[2] et disposent de nombreuses implémentations[3].
[1] Il y a pleins de protocoles standards aujourd'hui, XMPP est un parmi tant d'autres.
[2] Complet et mature ? Bon 5 ans d'âge, c'est mature, mais juste. Complet, ça veut dire que plus il y a de trucs différents c'est complet ... Perso j'aime bien la citation suivante : "La perfection est atteinte, non pas lorsqu'il n'y a plus rien à ajouter, mais lorsqu'il n'y a plus rien à retirer" - Antoine de Saint-Exupéry
[3] Des implémentations pour des messages, pas de la surveillance ...
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Peu importe le protocole
Posté par vg . Évalué à 1.
Je parle d'expérience, mais si tu insiste chaque XEP comprend des exemples de requêtes si tu veux te faire une idée.
Il faut que tu m'expliques. L'idée de base présentée ici c'est que les serveurs surveillées envoient eux même un message quand il y a un problème. Si tu appliques cette solution, tu dois envoyer régulièrement un message pour dire que je suis vivant. Sinon tu reviens à l'idée d'un serveur qui poll les clients et ça élimine une partie des raisons d'utiliser XMPP.
Bah tu envois un message que quand il y a un problème (plus précisément quand tu change d'état), si tout va bien à l'instant N pas besoin de le répéter à l'instant N+1, le serveur garde en mémoire l'état de chaque client.
La perfection est atteinte, non pas lorsqu'il n'y a plus rien à ajouter, mais lorsqu'il n'y a plus rien à retirer - Antoine de Saint-Exupéry
XMPP c'est 3 balises : , et et tu fait tout avec ça. Le but des XEP c'est de se mettre d'accord sur les payloads pour pas avoir 42 implémentations différentes pour les même fonctionnalités.
Des implémentations pour des messages, pas de la surveillance ...
Bah si justement, le serveur n'intervient absolument pas dans le contenue échangé entre les clients, il se fout que ça soit pour de la supervision ou pour du chat tout ce qu'il fait c'est router ces messages.
[^] # Re: Peu importe le protocole
Posté par vg . Évalué à 1.
[^] # Re: Peu importe le protocole
Posté par Victor . Évalué à 3.
Il faut que tu m'expliques. L'idée de base présentée ici c'est que les serveurs surveillées envoient eux même un message quand il y a un problème. Si tu appliques cette solution, tu dois envoyer régulièrement un message pour dire que je suis vivant. Sinon tu reviens à l'idée d'un serveur qui poll les clients et ça élimine une partie des raisons d'utiliser XMPP.
Bah tu envois un message que quand il y a un problème (plus précisément quand tu change d'état), si tout va bien à l'instant N pas besoin de le répéter à l'instant N+1, le serveur garde en mémoire l'état de chaque client.
Ce qu'il dit c'est que si le serveur qui est censé envoyé un message pour dire que rien ne va plus a été déconnecté du réseau, alors il ne pourra pas envoyer ce fameux message, d'où l'intérêt d'un "ping" !
[^] # Re: Peu importe le protocole
Posté par vg . Évalué à 1.
[^] # Re: Peu importe le protocole
Posté par Etienne Bagnoud (site web personnel) . Évalué à 1.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Peu importe le protocole
Posté par vg . Évalué à 4.
Quand tu ferme ferme ton navigateur au milieu d'un téléchargement de fichier par HTTP le serveur le sait très bien et annule la requête ... bah la c'est pareil, si un client XMPP se déconnecte le serveur le sait et envoie un message de présence aux autres clients de sa liste de contact pour les prévenir.
[^] # Re: Peu importe le protocole
Posté par Victor . Évalué à 3.
Donc en fait, on repose sur le "ping" de xmpp au final :)
[^] # Re: Peu importe le protocole
Posté par vg . Évalué à 1.
En pratique ça se fait plutôt bien avec Ejabberd, si un des noeud du cluster lâche les clients peuvent se connecter sur un autre noeud et la faute est remonté dans les logs d'Ejabberd qui peuvent être monitoré par un client XMPP.
[^] # Re: Peu importe le protocole
Posté par Frédéric . Évalué à 1.
Pour Nagios et compagnie c'est pareil, si le serveur de supervision tombe ben....
Tiens question pour les pros Nagios, ça existe un système de haute-disponiblité pour Nagios ?
Je parle d'un truc simple, pas une usine a gaz avec un fichier de config de 10000 lignes de perl :)
[^] # Re: Peu importe le protocole
Posté par Psychofox (Mastodon) . Évalué à 2.
Sinon tu peux facilement faire un système de failover en ayant 2 serveurs nagios. Tu synchronises les configs et en temps normal le second serveur. n'a qu'un service à monitorer : le serveur master nagios. Si celui-ci tombe, ton script de check relance automatiquement le failover avec les config du master. Je l'ai fais et ça marche très bien, et tu n'as besoin que d'un tout petit script.
[^] # Re: Peu importe le protocole
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
De plus XMPP est prévu pour ne pas fonctionner sur TCP uniquement, donc dans les autres cas tu n'as pas ce mécanisme d'ouverture/fermeture de port (UDP) ...
Donc le client envoies, dans le cas d'un système de surveillance, un "je suis en vie" toutes les 2 minutes ...
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Peu importe le protocole
Posté par vg . Évalué à 2.
Bah autant configurer ça au niveau de TCP et pas une couche au dessus.
De plus XMPP est prévu pour ne pas fonctionner sur TCP uniquement, donc dans les autres cas tu n'as pas ce mécanisme d'ouverture/fermeture de port (UDP) ...
L'UDP ne concerne absolument pas la partie Core de XMPP, c'est juste utilisé pour la vidéo et la voix.
[^] # Re: Peu importe le protocole
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
Une coupure réseau et un fonctionnement normal ont le même état dans ton histoire. Comment les distinguer ? Le serveur de surveillance "ping" régulièrement le client, ou alors le client envoie son état régulièrement. Mais se dire que rien == ok, c'est pas possible.
Bah si justement, le serveur n'intervient absolument pas dans le contenue échangé entre les clients, il se fout que ça soit pour de la supervision ou pour du chat tout ce qu'il fait c'est router ces messages.
??? Et comment il récupère les données de performances, comment il fait les statistiques de disponibilité ? Comment on peut dire confirmer un problème pour travailler dessus ? Comment on prévoit les temps d'interruptions d'un service/serveur ? La gestion des états (soft/hard) ?
C'est le plus gros du travail ça, la communication est la pointe de l'iceberg ...
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Peu importe le protocole
Posté par vg . Évalué à 2.
Imagine-toi que chaque machine est un ami dans ta liste de contact sur ton client d'IM, tu peux connaitre leurs états (et si la connexion se coupe pour l'un des contacts, le serveur te prévient), tu peux leur envoyer des commandes, il peuvent t'envoyer des stats, etc.
[^] # Re: Peu importe le protocole
Posté par Etienne Bagnoud (site web personnel) . Évalué à 3.
Non il doit y a avoir un endroit où tous les états sont centralisés et les actions entreprises avec. Une micro-interruption et hop tout le monde est réveillé ...
C'est pas possible, on veut être réveillé quand la panne est sérieuse.
Il peut arriver qu'un machine fonctionnel ait un contrôle qui fonctionne pas une fois (parce qu'une mouche est passée dans le ventilo du processeur et ça a produit une petite variation de tension qui a fait que la valeur de retour du contrôle est 255 au lieu de 0). Un incident comme ça ne doit pas faire gueuler tous les comptes XMPP des admins qui font leur sieste habituelle (celle de 8h à 18h).
Ensuite quand le problème est sérieux, il faut qu'on ait un rappelle de temps à autre (au cas où on a pas réussi à se réveiller, ça arrive).
Ensuite si un d'entre nous intervient, il doit pouvoir stopper les alarmes uniquement pour ce service.
Ensuite si on a une intervention planifiée, il faut que l'on indique au système de surveillance qu'on va la faire de 12h à 13h, donc de pas crier si le serveur est en panne durant ce temps.
Et encore plein d'autres choses. XMPP ne résout rien. Il faut faire un logiciel de surveillance qui introduit certainement un nouveau dialecte XML dans XMPP, un serveur Jabber XMPP qui s'interface avec notre logiciel de surveillance, et finalement notre logiciel de surveillance enverra les alarmes à qui de droit. Donc le serveur XMPP est juste un service qui fait passer les messages entre le serveur de surveillance et les machines puis entre le serveur de surveillance et les administrateurs.
Donc soit on réimplante XMPP dans un système de surveillance, soit on ajoute un service dans le système d'alarme avec tous les risques de pannes qu'un processus ajoute ...
Finalement tu m'expliquera comment le serveur XMPP fait pour savoir si un client est connecté ou pas ?
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Peu importe le protocole
Posté par vg . Évalué à 1.
C'était un exemple pour expliquer l'architecture. Tu peux écrire un client XMPP qui conserve toutes les stats dans une base de données, remonte les stats les plus importantes et filtres les trucs inutiles. Tu peux aussi faire en sorte que tes sondes cessent d'envoyer des messages pour un laps de temps.
Si on simplifie pas mal, XMPP sert surtout à :
- identifier les messages,
- s'assurer du format de ces messages,
- les router jusqu'à destination (quitte à les stocker en cas de soucis).
Il faut faire un logiciel de surveillance qui introduit certainement un nouveau dialecte XML dans XMPP
C'est justement ce que XMPP permet et encourage dans une certaine mesure. Les XEP sont là pour que ces extensions soit propres et bien documentées.
Je dis pas qu'il faut tout changer et tout passer en XMPP (surtout quand il y a déjà une solution qui marche) mais juste que ce protocole est plutôt bien adapté à la supervision.
[^] # Re: Peu importe le protocole
Posté par Frank-N-Furter . Évalué à 2.
Je dis pas qu'il faut tout changer et tout passer en XMPP (surtout quand il y a déjà une solution qui marche) mais juste que ce protocole est plutôt bien adapté à la supervision.
Une fois que tu as réécrit tous tes applis qui fonctionnent déjà, pour le prendre en charge, peanuts.
Depending on the time of day, the French go either way.
[^] # Re: Peu importe le protocole
Posté par vg . Évalué à 1.
Si une solution existante marche déjà très bien, bah super, ça ne rend pas XMPP plus ou moins adapté. La question n'a jamais été 'faut-il changer l'existant pour mettre du XMPP à la place ?'
[^] # Re: Peu importe le protocole
Posté par Frank-N-Furter . Évalué à 3.
C'est quoi la différence avec le snmp alors?
Il n'y aurait pas certains linuxaiferiens qui ce seraient spécialisés dans xmpp, et qui essayent de se créer des heures de consulting en le collant a toutes les sauces?
En fait, ça serait plus rassurant que l'autre possibilité. Que leur affection pour le protocole les aveugle au point qu'à chaque fois qu'ils entendent le mot communication, leurs petits jabberd se mettent à frétiller, sans réellement s'interroger sur l'intérêt réel de xmpp dans le contexte en question (je ne pense pas à l'auteur du journal)
Depending on the time of day, the French go either way.
[^] # Re: Peu importe le protocole
Posté par Etienne Bagnoud (site web personnel) . Évalué à 0.
XMPP c'est le protocole utilisé par le Dieu Google, c'est hype, c'est beau, c'est nouveau : c'est le Bien.
Il faut donc le mettre partout ...
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Peu importe le protocole
Posté par Frank-N-Furter . Évalué à -1.
Il faut donc le mettre partout ...
Tu es sûr de ça ? Parceque Google own my ass, et j'ai pas un début d'amorce de frémissement dans le bas du ventre.
Pour moi, ça reste le protocole défendu par quelques pleureuses qui la ramène dans les sujets qui ne les concernent pas. En plus, ils essayent de vendre les manques de leur bébé comme des qualités, parce qu’en fait il n'implémente que les choses vraiment utiles, et que tout ce qui n'est pas pris en charge, n'est que fadaises fourguées par les gens du marketing, à des utilisateurs légèrement d’efficients mentalement.
Depending on the time of day, the French go either way.
[^] # Re: Peu importe le protocole
Posté par Etienne Bagnoud (site web personnel) . Évalué à 3.
Moi je penses qu'Intel devrai implémenter XMPP sur les bus processeurs ... Ce serait vraiment une évolution.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Peu importe le protocole
Posté par Frank-N-Furter . Évalué à -1.
Depending on the time of day, the French go either way.
[^] # Re: Peu importe le protocole
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 3.
Je crois que beaucoup de gens ne connaissent pas XMPP et son intérêt (XMPP n'est pas un protocole de kikoo-lol-msn-like entre utilisateurs finaux même s'il y est parfaitement adapté). C'est juste un protocole de messagerie instantanée (messagerie instantanée != messagerie humaine) évolutif.
(en plus d'être nouveau c'est avec du XML, donc forcément c'est bien).
Je crois que beaucoup de gens disent du mal de certaines technologies juste parce qu'elles utilisent XML.
[^] # Re: Peu importe le protocole
Posté par Frank-N-Furter . Évalué à 1.
En plus, ils essayent de vendre les manques de leur bébé comme des qualités, parce qu’en fait il n'implémente que les choses vraiment utiles, et que tout ce qui n'est pas pris en charge, n'est que fadaises fourguées par les gens du marketing, à des utilisateurs légèrement d’efficients mentalement.
Que je vais me permettre de mettre en // avec ton:
Je crois que beaucoup de gens ne connaissent pas XMPP et son intérêt (XMPP n'est pas un protocole de kikoo-lol-msn-like entre utilisateurs finaux même s'il y est parfaitement adapté).
And the mind blowing part: C'est juste un protocole de messagerie instantanée (messagerie instantanée != messagerie humaine) évolutif.
wtf? Tu pourrais développer ?
Depending on the time of day, the French go either way.
[^] # Re: Peu importe le protocole
Posté par Frank-N-Furter . Évalué à 1.
Depending on the time of day, the French go either way.
[^] # Re: Peu importe le protocole
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
wtf? Tu pourrais développer ?
XMPP est un protocole qui est destiné à échanger des messages en pseudo-temps-réel, ce qu'on peut expliquer en le mettant en opposition avec un protocole comme SMTP. En supposant que ton infrastructure soit hyper performante, tu peux récupérer tes mails en "presque temps réel". Sauf que pour ça, il faut que ton client fasse des requêtes régulièrement au serveur. Ton client mail fait du "pull" sur le serveur POP3 ou IMAP. En comparaison, un message XMPP qui arrive sur ton serveur est "pushé" (poussé dans la langue de molière) vers ton client de messagerie instantanée (si celui-ci est connecté). Il y a un aspect "serveur" dans ton client, à savoir qu'il écoute ce qu'on lui dit (un client mail n'écoute rien).
Pour la seconde partie, ie messagerie humaine vs messagerie instantanée, bah c'est simplement que si bob envoies un messages à rick, c'est en réalité bob_client_xmpp envoie un message à rick_client_xmpp. Le client XMPP de bob peut être aussi bien un client de messagerie humaine type pidgin qu'un démon connecté à un capteur de température. Dans ce cas, toutes les 5 secondes, bob_client_xmpp enverra un message contenant simplement "37°C - tout va bien" et rick_client_xmpp stockera les données où il veut.
Là où XMPP devient très puissant, c'est que son schéma XML est évolutif et que donc tu peux l'étendre en définissant toi-même le format (XML ou texte) des messages.
Par exemple bob_client_xmpp enverra quelque chose comme :
<mesures datetime="20091214170319">
<temperature name="front" server="www" value="17"/>
<temperature name="back" server="www" value="42"/>
</mesures>
Et rick_client_xmpp aura automatiquement des données structurées qu'il pourra s'empresser de stocker et de tracer sur un graphique dispo en "presque temps réel via une interface web par exemple".
Je sais pas si j'ai répondu à ta question...
[^] # Re: Peu importe le protocole
Posté par Larry Cow . Évalué à 4.
Euh, non, pas exactement. Mais ça n'enlève rien aux qualités d'XMPP. Mais l'extension IDLE d'IMAP permet exactement ceci : conserver une connexion ouverte par laquelle tu seras prévenu de l'arrivée de nouveaux messages. Pas besoin de poller régulièrement.
[^] # Re: Peu importe le protocole
Posté par Octabrain . Évalué à 2.
[^] # Re: Peu importe le protocole
Posté par Frédéric . Évalué à 2.
La question ici, c'est : est-ce que XMPP peut-être intéressant à être utilisé dans un système de supervision comme protocole de communication ?
Selon toi non, Nagios c'est le top et XML c'est oversize pour faire ça, bon ben pas la peine d'en faire un fromage.
Après ce qui est intéressant c'est de voir des avis différents, par exemple plus haut, on nous dis que redhat à sortie un truc en rapport avec ça... Peut-être alors que c'est pas si nul que ça...
[^] # Re: Peu importe le protocole
Posté par Frank-N-Furter . Évalué à -1.
Depending on the time of day, the French go either way.
[^] # Re: Peu importe le protocole
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
Dans un précédent journal, on parlait de Nagios, notamment le fait que celui-ci soit susceptible d'effectuer un nombre conséquent de vérifications à interval régulier sur des machines.
Si on prend uniquement le cas de la supervision de serveurs et non pas les équipements réseaux via SNMP avec les switchs/routeurs. Pourquoi alors ne pas utiliser XMPP ?
L'idée proposée est d'envoyer un message quand ça va mal. Bien je soulignais que le problème venait lorsqu'on a une coupure de réseau on se retrouvait dans le cas suivant : pas de message donc pas de problème.
La solution pour ça a été de faire comme les navigateurs quand ils téléchargent un fichier et que l'on interrompt le téléchargement. Je réplique que l'on ne peut pas garder une communication ouverte sans rien dire indéfiniment (les serveurs peuvent fonctionner des mois sans problèmes).
C'est là où est le problème. Qu'on utilise XMPP ou n'importe quoi d'autres, on aura toujours besoin d'avoir le serveur qui va demander aux client "ça va ?" ou alors le client devra toujours dire "je vais bien ?".
Donc ce point n'est pas automagiquement résolu par XMPP.
Il y a aussi SSH over XMPP. C'est vrai pourquoi utiliser SSH alors qu'on pourrait encapsuler ça dans du XMPP. C'est clairement un abus de l'utilisation de XMPP.
Ensuite quand je vois ça :
Alors, pensez-vous que XMPP peut être intéressant pour superviser un parc de machine, plutôt qu'une usine a gaz gérée de manière centralisée qui va passer son temps à faire du polling ?
Je me dis que c'est vachement agressif, je suis pas certain qu'un serveur jabber soit moins gourmand qu'un Nagios. C'est un appel au troll.
Ils me semblent que tu vois la surveillance comme suit :
- Il y a une erreur, un message est envoyé à l'administrateur.
Le fait est qu'il y a d'autres choses à gérer (j'ai cité plus haut, je vais éviter de me répéter). Et XMPP tout seul ne le fait pas. Donc on doit intégrer le protocole XMPP dans le serveur de supervision ou alors avoir deux services pour la supervision, dont un uniquement pour l'échange de message.
Finalement la solution RedHat me semble ne pas être un système de surveillance, mais une outil pour lancer des tâches récurrentes, une sorte de cron centralisé, utilisant XMPP comme protocole de communication. Donc pas vraiment prévu pour faire de la surveillance.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Peu importe le protocole
Posté par Victor . Évalué à 4.
L'idée proposée est d'envoyer un message quand ça va mal. Bien je soulignais que le problème venait lorsqu'on a une coupure de réseau on se retrouvait dans le cas suivant : pas de message donc pas de problème.
La solution pour ça a été de faire comme les navigateurs quand ils téléchargent un fichier et que l'on interrompt le téléchargement. Je réplique que l'on ne peut pas garder une communication ouverte sans rien dire indéfiniment (les serveurs peuvent fonctionner des mois sans problèmes).
C'est là où est le problème. Qu'on utilise XMPP ou n'importe quoi d'autres, on aura toujours besoin d'avoir le serveur qui va demander aux client "ça va ?" ou alors le client devra toujours dire "je vais bien ?".
Donc ce point n'est pas automagiquement résolu par XMPP.
Ce qu'il dit, c'est que si justement c'est résolu par XMPP car le protocole XMPP inclus déjà le fait qu'on check qu'une compte (une machine ici donc) est connecté ou pas.
En gros, si une machine = un user connecté, alors les autres users (le moniteur) savent si il est connecté ou pas.
En gros ce qu'il dit c'est qu'on pourrait utiliser XMPP et son modèle décentralisé comme couche transport pour se concentrer sur le contenu des messages sans qu'on ait à mélanger la gestion de la messagerie (push/pull, contenu structuré, etc) et l'utilisation qu'on en fait.
Et ça rejoint l'autre commentaire qui demandait ce que signifiait la différence entre messagerie instantanée et messagerie humaine : il n'y a pas que les humains qui utilisent les messages pour communiquer, NAGIOS lui-même le fait, sauf qu'ils ont tout réinventé pour le faire tandis que XMPP se concentre QUE sur ça !
[^] # Re: Peu importe le protocole
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
En gros, si une machine = un user connecté, alors les autres users (le moniteur) savent si il est connecté ou pas.
Oui mais ça revient à faire un _contrôle régulier_, soit en pull, soit en push. Il me semble que XMPP ping[1] est d'ailleurs là pour ça.
Mais je restes persuadé qu'un ping ICMP est plus léger qu'un ping XMPP pour savoir si la communication entre le serveur de surveillance et la machine surveillée est toujours vivante.
En gros ce qu'il dit c'est qu'on pourrait utiliser XMPP et son modèle décentralisé comme couche transport pour se concentrer sur le contenu des messages sans qu'on ait à mélanger la gestion de la messagerie (push/pull, contenu structuré, etc) et l'utilisation qu'on en fait.
Non le journal propose d'utiliser XMPP pour ne plus avoir besoin faire des contrôles réguliers sur les machines. XMPP ne résoud pas se problème particulièrement :
- notamment le fait que celui-ci soit susceptible d'effectuer un nombre conséquent de vérifications à interval régulier sur des machines.
- On a du publish/subscribe, on peut faire du push, bref pas besoin de perdre sont temps à checker à interval régulier un service...
Le reste parle d'utiliser XMPP pour lancer des commandes sur les machines et, là encore, pourquoi rajouter un service supplémentaire alors qu'ssh est généralement installé sur les serveurs.
Ensuite utiliser XMPP pour communiquer, c'est un autre sujet, mais pas abordé dans le journal.
NAGIOS lui-même le fait, sauf qu'ils ont tout réinventé pour le faire tandis que XMPP se concentre QUE sur ça !
Hormis le fait que Nagios (1999) existait avant XMPP (2000 et 2004 pour le standard), donc ils n'ont pas réinventé en fait.
Maintenant les notifications via XMPP sont déjà disponibles dans Nagios[2]
[1] http://xmpp.org/extensions/xep-0199.html
[2] http://www.gridpp.ac.uk/wiki/Nagios_jabber_notification
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Peu importe le protocole
Posté par Victor . Évalué à 2.
Oui mais ça revient à faire un _contrôle régulier_, soit en pull, soit en push. Il me semble que XMPP ping[1] est d'ailleurs là pour ça.
Mais je restes persuadé qu'un ping ICMP est plus léger qu'un ping XMPP pour savoir si la communication entre le serveur de surveillance et la machine surveillée est toujours vivante.
Là dessus je veux bien te croire, mais l'argument en réponse à ça pourrait être qu'à notre époque, en échange d'aisance de développement et d'utilisation (voir la suite de ma réponse), on pourrait sacrifier un peu de BP.
Ensuite utiliser XMPP pour communiquer, c'est un autre sujet, mais pas abordé dans le journal.
J'ai plutôt le sentiment que c'est le sujet maitre du journal en fait : XMPP propose tout les services nécessaire au fonctionnement d'un outil comme Nagios.
Même si l'auteur du journal ne l'a pas mis en exergue, je pense que c'est là dessus que le débat devrait se concentrer au final (voir encore la suite de ma réponse pour plus de précision).
Hormis le fait que Nagios (1999) existait avant XMPP (2000 et 2004 pour le standard), donc ils n'ont pas réinventé en fait.
Faudrait pas non plus me prendre pour un imbécile hein (en même temps je l'ai un peu cherché par mon choix de vocabulaire :)
Bien sûr que Nagios était là avant, mais ça n'empêche qu'au lieu de se concentrer sur le quoi de leur boulot, les devs de Nagios doivent aussi s'embêter à développer le comment alors qu'il y a des outils qui se concentrent déjà la dessus et le font pas mal.
C'est aussi une histoire de réutilisabilité, bien sûr Nagios sait le faire, mais si il le fait, c'est pour s'en servir pour faire son boulot, pas le proposer à d'autre !
J'ai une petite déformation professionnel, je fais du génie log et j'ai tendance à tout voir sous forme de réutilisation et de composabilité :)
[^] # Re: Peu importe le protocole
Posté par Frank-N-Furter . Évalué à 1.
Se concentrer sur le contenu des messages, après avoir ré écrit les sondes pour qu'elles supportent xmpp, en lieu et place de leurs vieux protocoles tout pourris, et éprouves.
Et nagios ne réinvente rien, il utilise ce qui existe déjà (snmp, etc)!
Bien sûr que les machines communiquent, mais le contenu de leurs échanges n'est pas équivalent à ce que des humains se racontent (dommage qu'il n'ait pas perce dans ce domaine)
Depending on the time of day, the French go either way.
[^] # Re: Peu importe le protocole
Posté par Victor . Évalué à 1.
Oui, mais ce que le monsieur d'en haut te dit c'est que xmpp, ne détecte pas par magie la déconnexion d'un équipement, il ne fait rien de moins que ce que font les outils de monitoring actuels.
Bin si justement, c'est ça qui est cool ! Si on considère un équipement comme un user XMPP, alors XMPP gère tout ça et on peut effectivement se concentrer sur l'information qu'on passe plutôt de comment on la passe et si l"équipement en face est effectivement connecté.
Et nagios ne réinvente rien, il utilise ce qui existe déjà (snmp, etc)!
Là dessus je suis d'accord, c'est une erreur de ma part alors, mais ça ne supprime pas le débat sur "XMPP est-il adapté pour faire ça ?" !
Bien sûr que les machines communiquent, mais le contenu de leurs échanges n'est pas équivalent à ce que des humains se racontent (dommage qu'il n'ait pas perce dans ce domaine)
Oui, et ? XMPP est fait aussi pour ce genre d'échange à lire ce qu'écrive les autres...
[^] # Re: Peu importe le protocole
Posté par Octabrain . Évalué à 6.
Moi je sais : vu que XMPP en tant que protocole de messagerie n'a pas le succès et la popularité attendus, il faut bien lui trouver une autre utilité.
[^] # Re: Peu importe le protocole
Posté par bubar🦥 (site web personnel) . Évalué à 2.
# XMPP en simple supervision, est-ce le bon segment de marché ?
Posté par porki . Évalué à 3.
S'il est question de superviser l'état d'un système, SNMP est très bien car il fait l'essentiel :
- possibilité de faire du polling ;
- possibilité de faire du push (trap) ;
- possibilité de relever des informations d'état comme des compteurs ;
- possibilité d'extension (MIB entreprise) ;
- faible empreinte réseau (utilisation d'un dictionnaire -MIB- et protocole binaire) ;
- standard ;
- répandu.
Selon moi, on doit pouvoir faire de la simple supervision avec XMPP mais ses inconvénients (peu répandu, surtout sur autre chose que les serveurs/PC, verbosité plus importante) ne sont pas compensés par la présence de fonctionnalités supplémentaires _utiles_ (par rapport à SNMP) pour une simple supervision.
# Quelques points de réflexion sur des structures possibles
Posté par davux (site web personnel) . É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.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.