On peut faire ça en NRPE mais généralement la machine se contente de faire des checks sur elle-même quand le serveur de monitoring lui demande.
L’avantage de NRPE c’est que tu peux vraiment faire tout ce qui est imaginable comme vérification (donc un serveur qui en vérifie d’autre : oui) car il te suffit d’avoir un programme, qui de préférence « parle NRPE » (code retour, formatage de la sortie standard, arguments acceptés pour les seuils...), et déclarer une commande dans ta conf’ NRPE qui va l’utiliser.
Par contre, il faut le signaler, le fait d’autoriser NRPE a accepter des arguments dans les commandes qu’il définit est un potentiel trou de sécurité (il y a déjà eu pas mal d’exploit de cela...). C’est bien plus rigide mais en toute rigueur il faudrait définir les commandes NRPE avec des argument en dur... ce qui nécessite de re-déployer si on veut changer, par exemple, un seuil.
L’aspect « parentalité » est géré plus haut, au niveau du moteur de supervision (centreon-engine dans mon cas), on définit les parentalités directement entre les statuts des checks, sans s’occuper du type de check. C’est un aspect assez simple à gérer pour des éléments réseaux, qui l’est déjà nettement moins au niveau middleware et applicatif.
[^] # Re: mode deconnecté ?
Posté par Marotte ⛧ . En réponse au journal SNMP vs NRPE. Évalué à 3.
On peut faire ça en NRPE mais généralement la machine se contente de faire des checks sur elle-même quand le serveur de monitoring lui demande.
L’avantage de NRPE c’est que tu peux vraiment faire tout ce qui est imaginable comme vérification (donc un serveur qui en vérifie d’autre : oui) car il te suffit d’avoir un programme, qui de préférence « parle NRPE » (code retour, formatage de la sortie standard, arguments acceptés pour les seuils...), et déclarer une commande dans ta conf’ NRPE qui va l’utiliser.
Par contre, il faut le signaler, le fait d’autoriser NRPE a accepter des arguments dans les commandes qu’il définit est un potentiel trou de sécurité (il y a déjà eu pas mal d’exploit de cela...). C’est bien plus rigide mais en toute rigueur il faudrait définir les commandes NRPE avec des argument en dur... ce qui nécessite de re-déployer si on veut changer, par exemple, un seuil.
L’aspect « parentalité » est géré plus haut, au niveau du moteur de supervision (centreon-engine dans mon cas), on définit les parentalités directement entre les statuts des checks, sans s’occuper du type de check. C’est un aspect assez simple à gérer pour des éléments réseaux, qui l’est déjà nettement moins au niveau middleware et applicatif.