Et oui me direz-vous ! pourquoi ce titre aussi débile ?
SNMP est un protocole ad-hoc.
- standard, cross-plateforme (IETF inside)
- implémenté, de base +extensible, par presque n’importe quel hôte…
- en tant que protocole purement IP, pas forcément priorisé sur les flux TCP/IP ou UDP/IP en cas d’engorgement…
NRPE est un protocole laxiste mais puissant.
déjà il demande le lancement d’un service pas si « standard » que SNMP…, qui est implémenté Linux/Windows mais sur un router ou un switch tu vas pouvoir te brosser… alors que le router ou le switch (ou le frigo) en question parle déjà SNMP en fait…
son fichier de configuration inclue une directive expressément nommé dont_blame_nrpe dans le code, qu’à mon avis tous les décideurs avides de fonctionnalités, de modularité… font… le choix d’activer. C’est pourtant une porte ouverte à toute les tentatives d’abus… Alors qu’avec cette directive à "Off" l’exposition est incomensurablement moins étendue…
L’adoption très grande de ce protocole fait qu’on peut coder un « Check Nagios » absolument n’importe comment, tout le monde est d’accord sur des conventions de sortie standard et de code de retour…
NRPE implique des déploiements réguliers à chaque évolution (ajout, modification d’une commande…), évolutions spécialisées (windwos, linux, …). Là où, SNMP a le mérite d’être panOS…
Pour ma part je pense que ces deux protocoles sont complémentaires. Ayant bien envie de connaître votre avis j’ai écrit ce journal dans ce but.
# mode deconnecté ?
Posté par NeoX . Évalué à 2.
je ne sais pas, j'ai pas testé, mais il se passe quoi quand le routeur d'un site tombe ?
en SNMP, ton outil de montoring ne voit plus personne et remonte que tout le monde est DOWN
alors que seul le routeur l'est.
en NRPE ? c'est pas une machine local au site qui fait les checks, voit que tout le monde est UP sauf le routeur,
puis envoie le resultat au monitor principal ?
pour un peu qu'il y ait un buffer et quand le routeur revient tu vois bien que tes equipeements etaient UP pendant la panne du routeur.
[^] # Re: mode deconnecté ?
Posté par Marotte ⛧ . É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.
[^] # Re: mode deconnecté ?
Posté par Psychofox (Mastodon) . Évalué à 2.
Franchement en 2016, j'ose imaginer que tout sysadmin qui se respecte utilise un gestionnaire de configuration centralisé.
Je crois n'avoir jamais utilisé l'option don't blame nrpe.
[^] # Re: mode deconnecté ?
Posté par tontonrico . Évalué à 1.
Oui mais c'est un peu simpliste, il faut utiliser de la corrélation, que ce soit avec SNMP ou NRPE.
[^] # Re: mode deconnecté ?
Posté par tetsuo44 . Évalué à 1.
Oui mais non. Quand tu utilises des check passifs (pas que snmp, il y a nsca ou le pendant plus récent), nagios utilise le concept de freshness pour ce type de contrôle. globalement si nagios ne reçoit pas de notification depuis plus de x unités de temps, il va lancer un contrôle actif pour vérifier si l'agent est vivant (ou pas). De plus la gestion de la topologie fait que (si tu le configure correctement) si le parent (le routeur) tombe alors ce n'est que ce routeur qui sera notifié (ce qui est derrière le routeur passe en UNKNOWN).
# ... vs Icinga 2
Posté par peikk0 . Évalué à 4.
Icinga 2 a un mode client qui remplace avantageusement NRPE. Il est plus secure que ce dernier, a une authentification TLS, communique via une API REST (master vers client, ou client vers master, ou les 2 à la fois, au choix), peut fonctionner soit en mode passif (il reçoit des commandes du master et les exécute, comme NRPE) ou actif (il fait ses checks de façon autonome et envoie les résultats au master), et peut optionnellement recevoir sa configuration depuis le master. C'est que du bonheur à configurer et utiliser. Par contre forcément c'est pour Icinga 2 uniquement, pas pour Nagios, Icinga 1 etc.
[^] # Re: ... vs Icinga 2
Posté par Marotte ⛧ . Évalué à 2.
Merci pour ces précisions. J’ai testé Icinga (et Shinken) il y a quelques temps et j’avais trouvé ça prometteur effectivement.
[^] # Re: ... vs Icinga 2
Posté par peikk0 . Évalué à 1.
Note bien que Icinga 2 n'a quasi rien à voir avec Icinga 1, c'est une réécriture from scratch.
[^] # Re: ... vs Icinga 2
Posté par Marotte ⛧ . Évalué à 2.
Oui j’avais vu ça. Icinga 1 est iso-fonctionnel à Nagios alors qu’Icinga 2 casse la compatibilité. Ce qui ne semble pas déconnant, Nagios ça commence à dater un peu.
# Et de plus, sur Debian...
Posté par redo_fr . Évalué à 5.
Le mainteneur de nrpe a décidé que le 'dont_blame_nrpe' était trop dangereux et a retiré l'option sans prévenir (bon il a pas décidé vraiment tout seul, c'est une consigne de sécurité Debian)…
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756479
Les discussions ont été très vives, à ce sujet (avec des réponses du mainteneur du genre : "Si t'es pas content, maintiens le toi-même" [traduction libre])…
Conclusion : Lors d'une mise à jour, "tu" perds d'un coup toutes tes sondes paramétrées, à moins de recompiler toi même… :-(
Celui qui pose une question est bête cinq minutes, celui qui n'en pose pas le reste toute sa vie.
[^] # Re: Et de plus, sur Debian...
Posté par redo_fr . Évalué à 1.
(Mince, je me suis fait "avoir" par le timeout de modification :-) )
Pour en revenir à la question initiale, d'expérience personnelle, je dirais que les deux sont complémentaires, il y a des indicateurs qui sont beaucoup plus complexes à obtenir avec SNMP (le protocole "datant" un peu, la config ressemble un peu aux abominables "rulesets" de sendmail :-) )
Je ne suis pas d'accord avec le fait qu'activer le paramétrage de NRPE (plutôt que de les avoir "en dur") est un risque, Comme tout protocole accessible par le réseau ayant potentiellement des droits élevés, il faut être prudent, mais c'est le cas de tout sysadmin qui se respecte, non? ;-)
Celui qui pose une question est bête cinq minutes, celui qui n'en pose pas le reste toute sa vie.
[^] # Re: Et de plus, sur Debian...
Posté par Jean Gabes (site web personnel) . Évalué à 2.
Non là le soucis c'ets qu'en gros quelqu'un va pouvoir envoyer des arguments à tes commandes. Genre potentiellement des ">/dev/null;echo "myssh" >> .ssh/authorized_keys2". Et là…..
En plus, nrpe est vraiment limité en terme de protocole, surtout sur la taille du buffer récupéré ( à une époque c'était 1024o compilé en hard, ça a peu être changé mais purée ce que c'était petit…).
Bon je passe sur le fait que le "SSL" dedans n'est pas le meilleur en soit (genre tu peux oublier avoir une véritable sécurité en fait…).
Bref, nrpe, c'est pas la joie, mais snmp… non plus ^
[^] # Re: Et de plus, sur Debian...
Posté par claudex . Évalué à 6.
Quelqu'un qui vient d'allowed_hosts, pas n'importe qui. (Et on peu supposé, mais ça dépend bien sûr des parcs) que quelqu'un qui a accès à cette machine peut faire plus qu'envoyer des commandes via nrpe. D'ailleurs SNMP permet aussi d'envoyer des commandes.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et de plus, sur Debian...
Posté par Marotte ⛧ . Évalué à 2.
La sécurité m’y semble mieux prise en compte, on peut par exemple distinguer une communauté en lecture seule et une autre autorisé à l’écriture, la version 3 permet même de chiffrer les flux je crois…
Mais j’avoue ne pas m’être (encore) penché sur le côté commande de SNMP.
[^] # Re: Et de plus, sur Debian...
Posté par claudex . Évalué à 3.
Net-SNMP permet de faire du DTLS et de l'authentification client par certificat, il faut encore que je test.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et de plus, sur Debian...
Posté par mh-cbon . Évalué à -4.
En même temps j'ai envie de dire que la gestion des paquets est foireuse..
Soit, le mainteneur n'a pas incrémenter le numéro de version majeur (pour breaking change).
Soit, l'admin n'a pas bien locké sa dépendance (il à fait depend
*.*.*, au lien de2.*.*, où 2 est un hypothétique numéro majeur)Soit c'est le système de gestion de paquet chez debian qui est foireux en ne permettant pas cela, ce qui va m'attirer des foudres :=)
Ceci dit, comme, en tant que simple utilisateur, je n'ai eu l'occasion de locker une dépendance sur sa version mineure / patch. je ne sais pas si cela est possible, et j'en viens donc à penser, qu'en fait, la gestion des paquets est foireuse… Mais il est fort possible que je me trompe. Ceci dit bis, pour ce que cela vaut, j'ai lu ceci http://askubuntu.com/questions/18654/how-to-prevent-updating-of-a-specific-package et /bof/.
PS: des barres, le minimum maximum de karma à changé à -62, et j'y suis déjà :D
[^] # Re: Et de plus, sur Debian...
Posté par Marotte ⛧ . Évalué à 4.
D’après ce que j’ai lu ça ne protège que basiquement car un attaquant expérimenté peut forger une requête avec une adresse factice… C’est d’ailleurs directement dans le fichier de configuration que j’ai lu ça :/
# Profitons de ce fornal (forum + journal) pour parler de la supervision
Posté par Christophe B. (site web personnel) . Évalué à 3.
Il y a qq années / mois j'avais mis en place de la supervision avec ZABBIX, auparavant
j'avais testé Nagios et même Shinken que j'avais trouvé un peu lourd, n'ayant pas de millier de serveurs à gérer.
Peut être n'étais je pas tombé sur le tuto ki tue, comme on dit au pays de soleil levant.
Pour ZABBIX j'étais passé par une image VMWARE toute faite, mais bon Suse c'est pas ma tasse de thé
elle fonctionne bien et j'ai même pu faire ce que je voulais, à savoir vérifier la température de la salle serveur et envoyer des SMS au cas ou cela dépasse certains seuils.
problème : l'électronique bricolée ne résiste pas longtemps si elle est malmenée et depuis on m'a repris la carte SIM du modem bref …
J'ai pu aussi suivre (via ssh) la conso mémoire/CPU de l'ERP qui me fait vivre et j'en ai tiré beaucoup de renseignement utile
Mais c'est resté du bricolage et d'ailleurs j'ai vite arrêtée les alertes par mails vu qu'un truc comme ZABBIX nécessite de re calibrer toutes les alertes par défaut.
J'aimerais quelques bon conseils ou site ou livre (si cela existe encore :) ) sur la supervision
Si vous connaissez un site, une solution bref un truc du style "la supervision pour les nuls" je vous prie de bien vouloir me le communiquer.
Merci d'avance
[^] # Re: Profitons de ce fornal (forum + journal) pour parler de la supervision
Posté par Jean Gabes (site web personnel) . Évalué à 4.
Pour Shinken oui c'est plutôt orienté sur les gros parc en effet ^
Tu as regardé du côté de Sensu? c'est plutôt light? (enfin surtout côté feature de mon point de vue, mais étant l'auteur de Shinken disons que mon point de vue sur les feature minimale d'un outil n'est pas forcément le même que d'autres ).
Sinon je pense qu'on peux aussi détourner un Consul de son rôle premier, mais là c'est peu être moins pratique. A voir.
[^] # Re: Profitons de ce fornal (forum + journal) pour parler de la supervision
Posté par Christophe B. (site web personnel) . Évalué à 5.
Je n'en espérais pas tant :) une réponse de Jean Gabes himself …
J'en profites pour te transmettre tout mon respect sur ton travail sur Shinken et sur tes écrits sur Python qui m'ont beaucoup appris.
Sensu à l'air pas mal, je vais me pencher sur la question
Cela ressemble a ce que je cherche, des fonctionnalités simples, efficaces et rapide à mettre en place. cela permet de débuter dans la supervision.
Mais Shinken m'a toujours attiré, et à mon avis il pourrait faire plus que de la supervision, et devenir un Ordonnanceur comme CONTROL-M ou Dollar Universe, cela manque dans le monde du libre.
[^] # Re: Profitons de ce fornal (forum + journal) pour parler de la supervision
Posté par Jean Gabes (site web personnel) . Évalué à 2.
Heu, merci ^
J'y ais pensé à une époque à étendre le scope, genre booster les temps d’exécutions, permettre des retours plus larges et complexes (log etc etc) car on a une grosse partie du scope.
Mais bon je pense que ce qui pèche en général sur les outils d'ordonnancements c'est pas trop l'éxécution, mais bien la gestion finae du workflow de tes actions (genre éviter de passer par des fichier plat pour gérer les flags d'éxécutions à la minimine dans les scripts ).
Or là je peux pas apporter grand chose sur ce point, et j'avais pas fait le tour de la supervision (j'ai toujours pas fini d'en faire le tour d'ailleurs ).
Mais je ne serai pas étonné que quelqu'un un jour fork Shinken pour en faire un outil d'ordonnacement. Ca serait même bien :) Reste que il faudra lui donner un UI de configuration des jobs qui sera à la hauteur, et c'est là que ça va devenir complexe. D'expérience, faire un moteur c'est facile, mais une UI intuitive et qui aide les utilisateurs, là c'est une autre paire de manche :D
[^] # Re: Profitons de ce fornal (forum + journal) pour parler de la supervision
Posté par Christophe B. (site web personnel) . Évalué à 3. Dernière modification le 14 avril 2016 à 17:13.
Une UI intuitive Universelle qui fonctionne de partout => vi
Sincerement :
des fichiers textes avec des commentaires
git pour la sauvegarde / cp ls mv etc pour le reste / vi pour l'édition
ya que ça de vrai
[^] # Re: Profitons de ce fornal (forum + journal) pour parler de la supervision
Posté par Marotte ⛧ . Évalué à 2.
vi intuitif ?!
C’est malin… tu as cassé mon trollomètre :(
[^] # Re: Profitons de ce fornal (forum + journal) pour parler de la supervision
Posté par ghusson (site web personnel) . Évalué à 3.
Personnellement j'utilise zabbix depuis 2009. J'ai développé des scipts d’auto-découverte pour linux qui me permettent de déployer très vite la supervision des nouveaux serveurs (voir ici : https://share.zabbix.com/operating-systems/linux-autodiscovery-disks-proces-tcp-udp-service).
Zabbix a mis en place un site (béta) d'échange : https://share.zabbix.com/ ce qui est bien bien pratique.
De plus la V3 va permettre les communications chiffrées, ce qui va me permettre d'enfin utiliser les commandes à distance (ex : prendre un ps, iotop, atop de la machine en cas de dépassement de métriques).
Sur le sujet du monitoring, j'ai découvert récemment une communauté : http://www.monitoring-fr.org/
Pour un tour d'horizon des solutions, voir ici : http://wiki.monitoring-fr.org/supervision/links
Mes 2 cents.
[^] # Re: Profitons de ce fornal (forum + journal) pour parler de la supervision
Posté par Christophe B. (site web personnel) . Évalué à 2.
C'est Noël !!
Merci, ceci dit ZABBIX + autossh cela marche très bien aussi
Bon bah reste plus qu'a lire :)
Merci Beaucoup
[^] # Re: Profitons de ce fornal (forum + journal) pour parler de la supervision
Posté par NeoX . Évalué à 3.
tant qu'à etre dans les cadeaux, tu as essayé POM ?
http://www.pom-monitoring.com
configuration : à la decideur pressé : via un tableau excel qui ressemble (vite fait) à ca :
SITE;MACHINE;IP;TYPE
mondc;machine1;IP1;linux
mondc;machine2;ip2;linux
mondc;machine3;ip3;windows
deposer le fichier excel dans le dossier,
l'outil execute alors le parsing et configure le tout.
demo du resultat ?
demo.pom-monitoring.com
pour des points de montoring speciaux en dehors des "modeles" linux/windows/firewall X
on fait pareil avec des services, exemple :
MACHINE;TEMPLATE;version;mode;
machine3;exchange;2013;CAS
et hop, ca te met tous les indicateurs exchange de la machine3 qui a le role CAS dans l'infra
[^] # Re: Profitons de ce fornal (forum + journal) pour parler de la supervision
Posté par ghusson (site web personnel) . Évalué à 1.
J'avais déjà vu passer POM. Mais c'est pas libre d'après ce que j'ai vu rapidement sur leur site ?
[^] # Re: Profitons de ce fornal (forum + journal) pour parler de la supervision
Posté par NeoX . Évalué à 3.
j'ai pas demandé la licence, mais une fois que tu as le produit, ca reste du linux, des scripts shell et un ordonnanceur (nagios ou naemon) et un service web pour l'interface graphique.
donc rien que du tres classique,
il n'y a, à ma connaissance, pas de 'binaire' donc tu en as les sources.
[^] # Re: Profitons de ce fornal (forum + journal) pour parler de la supervision
Posté par Antoine . Évalué à 2.
POM n'est effectivement pas libre. C'est la solution qu'on est en train de déployer au boulot (CHU de Nantes) pour remplacer notre vieux nagios v3.
Leur force est le simplicité de configuration (fichier(s) excel) et les possibilités de dashboard sympa pour consolider les indicateurs par domaines fonctionnels et des rapports détaillés très séduisants pour les dirigeants qui veulent des taux de disponibilité des applications critiques.
Ils ne fournissent pas les sources, l'installation se fait par une ISO qui embarque un CentOS et des dépôts à eux qui contient leurs binaires.
[^] # Re: Profitons de ce fornal (forum + journal) pour parler de la supervision
Posté par ghusson (site web personnel) . Évalué à 1.
OK. Et pour info pourquoi avec choisi POM plutôt que Zabbix ? Simplicité de déploiement ?
[^] # Re: Profitons de ce fornal (forum + journal) pour parler de la supervision
Posté par NeoX . Évalué à 2. Dernière modification le 10 avril 2016 à 22:48.
je ne connais pas zabbix, mais :
exemple est-il capable de faire un indicateur qui est la combinaison des indicateurs suivants :
- 2 serveurs apache
- 2 serveurs mysql
un service utilisateur utilise ces 4 serveurs en cluster, on a donc
Service utilisateur = (apache1 ou apache2) ET (mysql1 ou mysql2)
et ensuite de calculer le taux de disponibilité de ce "service utilisateur" afin de faire un rapport à ton decideur affichant que le "service" a été disponible à 98% du mois dernier malgré le fait que mysql2 a été down 2 semaines le temps de le remplacer ?
donc que le service utilisateur a été rendu malgré la panne.
bref un petit tour sur demo.pom-monitoring.com permet de voir ce que fait nativement le produit.
il n'y a guere que les cartes manuelles à faire en plus du fichier excel de configuration
[^] # Re: Profitons de ce fornal (forum + journal) pour parler de la supervision
Posté par ghusson (site web personnel) . Évalué à 1. Dernière modification le 11 avril 2016 à 01:29.
[^] # Re: Profitons de ce fornal (forum + journal) pour parler de la supervision
Posté par tetsuo44 . Évalué à 0.
pour les cartes : ce n'est pas une feature développé par pom mais une feature de nagvis (qui a été rebrandé dans pom) et franchement ce n'est pas convainquant du tout pour avoir joué avec (a peu prés autant que la map dans les cgi nagios). j'avais fait la même chose a une époque avec centreon et j'avais du y passer 2/3 jours de code.
pour la "corrélation": c'est un vieux check nagios ça (business process addon de mémoire) et presque toutes les solutions basées sur nagios peuvent l'embarquer. (au passage shinken le fait mais en plus avancé et totalement intégré: bp_rules)
POM est un agréga rebrandé de solutions oss existantes avec une jolie glue autour. Le seul dev vraiment intéressant concerne les rapports qui est le point faible de beaucoup de solutions de supervision (même centreon bi a cause de sa complexité)
[^] # Re: Profitons de ce fornal (forum + journal) pour parler de la supervision
Posté par tetsuo44 . Évalué à 0.
Bon comment dire, POM n'est pas oss (mais massivement basé sur de l'oss). Il est cher (même par rapport aux versionx enterprise de centreon et shinken). Je me souviens d'un devis de POM a 100000 euros pour 8000 hosts supervisés …. et ce n'était que les licenses. Je ne suis pas contre les versions enterprises loin de la (j'en vend) mais il faut trouver un juste prix et franchement le rapport prix/fonctionnalités n'était pas à la hauteur. De plus gérer de la configuration dans un fichier excell, comment dire … ce n'est ni propre, ni sur. Versionner une conf de supervision est un minimum (quand c'est possible).
[^] # Re: Profitons de ce fornal (forum + journal) pour parler de la supervision
Posté par Marotte ⛧ . Évalué à 2.
Un serveur Sharepoint et hop, tu peux versionner ton fichier Excel !
===>[]
[^] # Re: Profitons de ce fornal (forum + journal) pour parler de la supervision
Posté par ghusson (site web personnel) . Évalué à 2.
Bon ben quitte à être dans les cadeaux, je vous met à dispo mes scripts autossh pour zabbix :-)
https://linuxfr.org/users/ghusson/journaux/zabbix-autossh-systemd
# My 2 cents
Posté par Antoine . Évalué à 2.
Salut,
Au taf supervise pas mal de choses (environ 1300 hosts pour 13000 points de supervision).
Dans la mesure du possible on fait du SNMP pour sa facilité d'installation et paramétrage sur les différents OS, parce que c'est supporté sur tous les matériels dont on ne maitrise pas l'OS (notamment les équipements réseau).
On utilise en dernier recours le NRPE, sur les machines windows qui nécessite du développement spécifique pour leur supervision (typiquement un script à exécuter sur le serveur dont le résultat remonte dans l'outil de supervision). Pour les linux on reste avec du SNMP et une directive exec.
Ah, et j'oubliais, pour les vieux AIX dont l'implémentation du SNMP est foireuse et sur lesquels on a pas les outils pour compiler un client NRPE on supervise en ssh (oui, beurk), l'outil de supervision se log, passe des commandes système pour vérifier l'état du bouzin.
# SNMP au dessus de UDP
Posté par TilK . Évalué à 6.
Juste par diptérophilie, je tiens à souligner que SNMP est basé au dessus de UDP, avec tous les avantages et inconvénients associés.
[^] # Re: SNMP au dessus de UDP
Posté par Marotte ⛧ . Évalué à 2.
Intéressant ! Je comprends mieux maintenant… je pensais bêtement que c’était basé directement sur IP :/
[^] # Re: SNMP au dessus de UDP
Posté par mh-cbon . Évalué à -7.
j'ai pas compris,
https://tools.ietf.org/html/rfc768
[^] # Re: SNMP au dessus de UDP
Posté par Marotte ⛧ . Évalué à 2.
SNMP se repose sur UDP, qui se repose lui-même sur IP.
SNMP décrit des "protocol data units" qui ont cette tronche :
IP header | UDP header | version community | PDU-type | request-id | error-status | error-index | variable bindings
https://en.wikipedia.org/wiki/Simple_Network_Management_Protocol#Protocol_details
Le schéma que tu donnes correspond à la partie "UDP header".
[^] # Re: SNMP au dessus de UDP
Posté par mh-cbon . Évalué à -6.
c'est une réponse intéressante aussi, merci, mais je ne comprends toujours pas ton commentaire précédent, c'était cela que je voulais comprendre :x
[^] # Re: SNMP au dessus de UDP
Posté par Marotte ⛧ . Évalué à 2. Dernière modification le 10 avril 2016 à 14:32.
Je pensais que SNMP était un protocole au dessus d’IP, au même titre que UDP, TCP ou ICMP, pas un protocole applicatif, d’un niveau supérieur dans le modèle OSI…
Donc le problème de lenteur que j’observe (disons que ça va deux fois moins vite que NRPE) c’est probablement lié que le réseau sur lequel je me trouve privilégie le trafic TCP par rapport à UDP en cas de congestion…
[^] # Re: SNMP au dessus de UDP
Posté par mh-cbon . Évalué à -5.
OK, j'ai compris maintenant : ) Je pensais que j'avais loupé un truc au sujet d'udp, d'où mon insistance.
[^] # Re: SNMP au dessus de UDP
Posté par claudex . Évalué à 4.
Test snmp en TCP, tu verras bien si c'est ça.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: SNMP au dessus de UDP
Posté par Marotte ⛧ . Évalué à 2.
Je pourrais faire quelques tests malheureusement de ce que je comprends il faut configurer snmpd pour qu’il fasse du TCP… Je me vois mal demander de modifier la configuration de snmpd sur tout le parc :)
[^] # Re: SNMP au dessus de UDP
Posté par claudex . Évalué à 3.
Tu peux faire du TCP avec SNMP (sauf pour les trap).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Mon avis : NRPE == Nagios
Posté par Cédric Temple (site web personnel, Mastodon) . Évalué à 3.
NRPE signifie Nagios Remote Plugin Executor : ce logiciel a été écrit pour Nagios en premier. Le fait que Nagios ai connu de nombreux forks (Centreon-Engine, Icinga, Naemon) ou ré-implémentation (Shinken) fait que NRPE est compatible avec ces outils par simple voie de conséquence. Zabbix, extérieur au "monde Nagios" a lui implémenté une passerelle uniquement pour pouvoir hériter de la forte communauté des développeurs de plugins Nagios mais son agent est beaucoup plus avancé que NRPE. NRPE n'est pas un standard (comme l'est SNMP) et n'est pas la voie royale pour les outils de supervision, de part ses défauts :
1. adapté au "monde Nagios" et uniquement lui
2. limité en terme de fonctionnalités
3. non sécurisé (SSL et don't blame NRPE comme mentionné)
4. limite de la sortie standard (le message affiché à l'écran)
5. aucune nouvelle sortie depuis 2013 et les dernières versions sont plutôt des correctifs qu'autre chose
Ce n'est pas NRPE qui a défini les conventions de sortie standard et de code de retour mais Nagios lui-même.
Tout à fait, mais uniquement dans le monde Nagios. Dans le cas d'autres outils de supervision libre (comme Zabbix, openNMS, ZenOSS, Ganglia, Cacti), ce n'est pas vrai.
Pour résumé :
1. NRPE est limité au monde Nagios et uniquement lui.
2. le monde Nagios manque d'un agent plus moderne.
# SNMP with NRPE
Posté par Romuald Delavergne . Évalué à 3.
NRPE (Nagios Remote Plugin Executor) a été développé pour Nagios.
NRPE n'a rien de puissant. C'est un simple protocole pour pouvoir exécuter du code à distance et récupérer le résultat, comme telnet, rlogin ou ssh.
NRPE est en effet complémentaire à SNMP car il permet de récupérer des informations très spécifiques que SNMP peut ne pas fournir.
NRPE n'est pas sécurisé d'ou l'option 'dont_blame_nrpe' que l'ont activer en n'en connaisant les risques.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.