Passge whheezy -> jessie , problème nrpe

Support Debian
#1

Hello,

La nouvelle version stable étant arrivé, et ayant un peu de temps, je me suis dit que j’allais testé le passage à cette nouvelle version.
Pour la mise à jour en soit pas de problème. Tout est ok.

Par contre le module nrpe (nagios-nrpe-server 2.15-1) ne semble pas fonctionner correctement

Pour les requêtes sans arguments, c’est ok.

Quand j’envoie une requête avec des arguments, j’ai , dans les logs en debug : Error : request contained command arguments!
et du coté monitoring (opsview) : CHECK_NRPE: Received 0 bytes from daemon.

dont_blame_nrpe=1 est bien spécifié

Je ne vois pas pourquoi car tout est ok : les chemins sont ok, les droits ok, les scripts marchent en local, et nrpe stop/start normalement.

Je ne vois donc pas pourquoi ça ne fonctionne pas.
des idées ?

#2

Je viens de voir dans mes mails, un message du système.
Il explique ce qui se passe …

Étonnant … !!! plus personne ne peut utiliser d’arguments si on ne recompile pas à la main le paquet ?? :119

#3

La tuile -_- je ne vois pas ou est la faille si par défaut l’option est désactivée… Déployant mes NRPE par Puppet, l’option compiler me complique vraiment la vie… Revoir ma supervision pour ne plus utiliser les arguments et donc multiplier les commandes dans la conf des NRPE…

tof > Comment as tu géré ça de ton coté ?

Bref :unamused:

#4

Vu que la seule façon de passer outre est de recompiler le truc, et même par là j’ai trouvé des topics disant que ça marche pas top …
Je tente de trouver des plugins/modules/scripts en snmp.

J’ai casi fini, il manque le monitoring de l’interface réseau. Mais la je bloque.
Tout est up, opsview détecte bien ma carte mais le script répond que eth0 n’existe pas (je n’ai qu’une interface sur mon serveur de test est c’est eth0). En ligne de commande il dit pareil.

J’ai aussi pensé mettre tout les arguments dans le fichier nrpe.cfg et juste appeler la commande, mais je trouve ça sale!!

Donc obligé de bricoler.
Et toi comment va tu faire ?

#5

Tu connais check_mk ?

#6

Non je connaissais pas.
Sur le papier ça semble pas mal. Mais est-ce que ça marche bien ? ça consomme pas trop de mémoire ?

#7

Ça fonctionne super bien, et ça consommes beaucoup moins que les checks habituels

Le principe de fonctionnement, plutôt que de faire plein de checks qui vont chacun se connecter à la cible, récupérer les données, et sortir un status, tu as une seule probe active qui se connecte à la cible.
Cette probe récupére plein d’info, et nourrit l’ensemble des probes passives.

Tu as beaucoup moins de fork, le load de ton serveur sera plus bas, c’est plus facile à configurer, je te le conseille vivement
(et j’oubliais : il est aisé d’étendre en ajoutant tes propres sondes au système, pour peut qu’un peu de python ne te fasses pas peur)

#8

ça semble pas mal.
Je vais tester ça …
Le python, je connais pas (encore?), on verra.

Je vais étudier son installation client/serveur et son fonctionnement.

#9

peut-il être intégré a un nagios (opsview) existant ?

#10

Il est dans les dépots Wheezy et unstable (mais pas Jessie):

30% [albert:~]apt-cache policy check-mk-agent check-mk-agent: Installé : (aucun) Candidat : 1.2.2p3-1 Table de version : 1.2.2p3-1 0 500 http://ftp.fr.debian.org/debian/ sid/main amd64 Packages 500 http://ftp.fr.debian.org/debian/ unstable/main amd64 Packages 1.1.12p7-1 0 500 http://ftp.fr.debian.org/debian/ oldstable/main amd64 Packages 32% [albert:~]apt-cache policy check-mk-server check-mk-server: Installé : (aucun) Candidat : 1.2.2p3-1 Table de version : 1.2.2p3-1 0 500 http://ftp.fr.debian.org/debian/ sid/main amd64 Packages 500 http://ftp.fr.debian.org/debian/ unstable/main amd64 Packages 1.1.12p7-1 0 500 http://ftp.fr.debian.org/debian/ oldstable/main amd64 Packages

#11

Evidement je voulais le tester sur une jessie …

#12

Ajoute les dépots unstable
Et n’oublies pas de configurer apt :

2% [haleth:~]cat /etc/apt/apt.conf
APT::Default-Release "jessie";

Ainsi, tu peux installer un paquet unstable sans mettre à jour l’ensemble de ta machine
Note que tu peux faire la même chose avec les dépots Wheezy, si tu préfères

#13

Pas bête, je vais faire ça avec la wheezy, je préfére.

#14

Je vais moi aussi finir par maquetter Mk Livestatus mais dans l’optique de Centreon avec son propre broker je trouve ca un peu bizarre d’en rajouter encore un :confused: De plus Mk Livestatus n’a pas les mêmes fonctions que NRPE, par exemple si je veux exécuter mon propre plugin Perl via Mk livestatus c’est impossible ?

#15

nrpe n’utilise pas le même concept que check_mk.

nrpe : tu définis des probes sur ta machine, avec la configuration qui te permet d’utiliser les probes. Sur le serveur, tu définis les checks à base de check_nrpe_1arg.
Lors de l’interrogation des checks, le serveur considère qu’ils sont tous séparés.
C’est des sondes actives.

check_mk: tu installes le paquet, tu rajoutes des probes sur le client si tu le souhaites. Sur le serveur, tu actives le check pour cet hôte. L’autoconfiguration te permet de générer les checks quand tu le souhaites, en se basant sur ce qui est disponible côté client (= les probes de bases, + les probes que tu as rajoutés).
Il n’y a pas de configuration par probe, il n’y a qu’une configuration par host.
Lors de l’interrogation des checks, le serveur considère qu’il n’y en as qu’un seul.
C’est des sondes passives.

Les différences pour toi, utilisateur :

  • si une probe check_mk n’est pas sur la machine, tu ne le sauras pas. L’autoconfiguration te dit ce qui existe, pas ce qui n’existe pas. Donc, si tu veux tester un serveur web par exemple, utiliser plutôt nrpe (ou check_http dans ce cas présent, m’enfin). Si tu veux tester l’espace disque, utilise plutôt check_mk.
  • check_mk est beaucoup plus économes que de multiples check_nrpe (ou autres checks actifs) : nagios ne lance qu’un seul processus, plutôt que beaucoup (et cela se ressent sur la machine, vraiment)
  • check_mk permet l’autoconfiguration : si une nouvelle probe apparait sur le client, il va te le dire. Très pratique lorsque tu rajoutes un disque par exemple.
  • check_mk te fourni une grande quantité de check pour plein de trucs de base (j’ai cité l’espace disque, il y a aussi les erreurs sur les interfaces réseaux) : autant de trucs qui sont utiles d’avoir à l’oeil, et auquel on ne pense pas. La configuration est plus simple, puisqu’elle est par hôte et non par service. Elle est donc beaucoup plus exhaustive.
  • nrpe te permet de forcer le check via ton interface web (sonde active), check_mk ne te le permet pas (la plupart des sondes sont passives, et sont mis à jour par l’unique probe active).

Bref, j’utilise les deux :

  • check_mk pour tout les trucs qu’il y a partout
  • nrpe pour ce que je veux être sur qu’il existe