Pour superviser ton parc de serveur avec Nagios, tu fais comment ? tu prends un serveur et tu installe/configure ton système de supervision dessus.
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 Frédéric . En réponse au journal Supervision et XMPP, why not ?. É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.