Retour d'expérience sur SNMP

[claneys]

Bonjour,

J'aurais voulu connaître vos retours d'expérience sur l'utilisation de SNMP pour la supervision. J'ai actuellement une supervision basée sur SSH avec Nagios. Je prépare la suite et j'envisage sérieusement de tous basculer sous SNMP et m'orienter sur du Shinken en remplaçant de Nagios.

Mais je ne sais pas si avec plusieurs agents SNMP sur une même machine comment se comporte le tout si jamais plusieurs manager tapent sur ces agents etc. J'ai peur d'effet de bord entre la supervision que je fait et la supervision éventuelles présentes chez nos clients. Je cherche à savoir si d'éventuelles dégât collatéraux sont monnaies courantes ?

Merci.

[surcouf]

Bonjour,

J'aurais voulu connaître vos retours d'expérience sur l'utilisation de SNMP pour la supervision. J'ai actuellement une supervision basée sur SSH avec Nagios. Je prépare la suite et j'envisage sérieusement de tous basculer sous SNMP et m'orienter sur du Shinken en remplaçant de Nagios.

Mais je ne sais pas si avec plusieurs agents SNMP sur une même machine comment se comporte le tout si jamais plusieurs manager tapent sur ces agents etc. J'ai peur d'effet de bord entre la supervision que je fait et la supervision éventuelles présentes chez nos clients. Je cherche à savoir si d'éventuelles dégât collatéraux sont monnaies courantes ?

D'expérience, peu de dégâts collatéraux s'agissant des agents fournis avec les systèmes cibles, de même avec les agents matériels spécifiques (IBM Director, Dell OMSA, SUN MASF, etc.). Il ne peut y avoir qu'un seul agent SNMP répondant sur le port UDP 161. Cela étant, il existe plusieurs méthodes et protocoles (SMUX, AgentX, DPI, etc.) pour permettre à plusieurs agents de dialoguer avec l'agent principal ou maître. C'est par exemple le cas sous AIX où il y existe plusieurs démons fournis avec le système. Et c'est ainsi que les agents spécifiques communiquent avec les agents systèmes.

L'intérêt de l'utilisation du protocole SNMP est de permettre d'avoir un protocole commun aux différents systèmes et équipements réseaux, d'éviter d'installer des agents (en plus des agents SNMP déjà fournis par le système, s'entend) et ainsi d'être indépendant de ta solution de supervision (Nagios, Zabbix, etc.).

[claneys]

Merci, pour le retour.

Qu'entends tu par "peu de dégât collatéraux" ? cela pourrait presque être inquiétant, tu as rencontré quel genre de souci ?

Sur le fait d'avoir plusieurs agents SNMP qui se causent entre eux, je suis pas vraiment fan de ce mode. Cela veut dire que si l'on a l'agent principal qui tombe on perds tous les indicateurs d'un coup. Si on surveille plusieurs agents séparément, on a au moins les survivants. Le seul problème étant les clients ayant des restrictions au niveau des ports ouverts sur leur réseau.
Je vais quand même regarder d'un peu plus près, si ça se trouve je dis des bêtises.

[surcouf]

Merci, pour le retour.

Qu'entends tu par "peu de dégât collatéraux" ? cela pourrait presque être inquiétant, tu as rencontré quel genre de souci ?

Je dis peu pour ne pas dire aucun. Le seul cas où un agent a eu une incidence sur la charge d'un système, c'était à cause d'un script qu'il devait exécuter mais du point de vue du client, ça revenait au même. Ce script devait surveiller régulièrement un fichier de log pour en extraire des statistiques (d'où la gageure de ce type de méthode avec des log).
En dehors des scripts, il n'y a que peu de risques même si tu n'es jamais à l'abri d'un bogue, mais cela est valable avec n'importe quel logiciel. Et des effets de bord à cause de scripts exécutés par SSH, il peut également y en avoir, sans doute davantage car le code n'aura pas été relu ni exécuté par d'autres personnes (donc peu de support).
En fait, tout ce que j'ai pu entendre à propos des impacts que le protocole ou les agents SNMP pouvaient induire sur le SI restent, pour moi, de la légende urbaine.
Quant, aux agents spécifiques, ils ont d'avantages d'impacts et demandent précisément des ports TCP non standards quand ce n'est pas carrément des dizaines de ports dynamiques via IPC (suffit de voir les produits de CA...).

Sur le fait d'avoir plusieurs agents SNMP qui se causent entre eux, je suis pas vraiment fan de ce mode. Cela veut dire que si l'on a l'agent principal qui tombe on perds tous les indicateurs d'un coup. Si on surveille plusieurs agents séparément, on a au moins les survivants. Le seul problème étant les clients ayant des restrictions au niveau des ports ouverts sur leur réseau.
Je vais quand même regarder d'un peu plus près, si ça se trouve je dis des bêtises.

Si l'agent principal venait à tomber, tu le saurais immédiatement dans la mesure où il fournit lui-même des indicateurs, notamment les indicateurs standards, type occupation des partitions, statistiques et états des interfaces réseaux, etc..

[naparuba]

J'avoue ne pas être un grand grand fan du SNMP (plus rude à adapter pour faire du spécifique à mon goût) mais une chose que l'on ne peux pas lui reprocher c'est la stabilité. Là où j'en ais vu, je n'ai jamais vu de soucis (et je l'utilise de toute manière pour tout ce qui est monitoring hardware).

Au pire pour être rassuré tu peux mettre une règle de dépendance entre tes X checks et un check qui vérifie juste la connexion avec l'agent, comme ça en cas de soucis, tu sauras directement d'où vient le problème(et dans une UI comme celle de Shinken tu n'auras qu'un indicateur de présenté et non pas X ).

[surcouf]

J'avoue ne pas être un grand grand fan du SNMP (plus rude à adapter pour faire du spécifique à mon goût) mais une chose que l'on ne peux pas lui reprocher c'est la stabilité. Là où j'en ais vu, je n'ai jamais vu de soucis (et je l'utilise de toute manière pour tout ce qui est monitoring hardware).

Tout dépend de ce qui est considéré comme spécifique. Combien de fois peut-on voir des MIB propriétaires ré-inventer ce que permettent déjà les MIB standards ? Cela étant, implémenter les OID fournis par une MIB demande un peu plus de développement qu'un simple script exécuté par SSH, oui.

[claneys]

D'après le tour d'horizon effectué pour les produits déjà monitorer, les MIB standard n'implémente pas d'OID permettant la surveillance d'un cluster, ou d'un Listener de base de données.

Quant au développement en reprenant les plugins perl déjà existant pour l'espace de stockage par exemple, il est tout de même relativement aisé de se faire très vite un plugin fonctionnel pur surveiller ce que l'on veut.

@surcouf : qu'appelles tu "implémenter les OID fournis par une MIB" ? Pour l'instant j'agis de manière empirique et très brute pour débroussailler le terrain de SNMP, n'ayant que peu  de connaissance en la matière. Je scan complétement l'arbre SNMP d'un agent avec snmpwalk, en ayant au préalable pris les MIB concernées, puis je regarde quels OID sont pertinents pour notre monitoring et je les utilise dans des plugins.

Merci.

[surcouf]

D'après le tour d'horizon effectué pour les produits déjà monitorer, les MIB standard n'implémente pas d'OID permettant la surveillance d'un cluster, ou d'un Listener de base de données.

En effet, mais pour la majorité des moteurs SQL, il existe des agents spécifiques implémentant les MIB propriétaires des différents éditeurs.

@surcouf : qu'appelles tu "implémenter les OID fournis par une MIB" ? Pour l'instant j'agis de manière empirique et très brute pour débroussailler le terrain de SNMP, n'ayant que peu  de connaissance en la matière. Je scan complétement l'arbre SNMP d'un agent avec snmpwalk, en ayant au préalable pris les MIB concernées, puis je regarde quels OID sont pertinents pour notre monitoring et je les utilise dans des plugins.

Implémenter les OID décrits par une MIB sous-entend fournir une intelligence logicielle capable de traduire la valeur brute en valeur définie par la MIB en question. J'insiste et lourdement sur cette notion car je lis trop souvent la confusion entre le fait d'avoir une MIB et d'obtenir les OID en interrogeant l'agent SNMP. Les OID renvoyés par l'agent nécessitent de la programmation, de l'intelligence logicielle : les MIB ne sont, en quelque sorte, que les spécifications techniques d'un agent SNMP.

[claneys]

Hum, je ne suis pas sûr de comprendre. Lorsque j'interroge un nouveau matériel sans MIB correspondante, je reçois un arbre d'OID avec des valeurs. Celles ci sont quasiment inexploitables en l'état. Le fait d'ajouter la MIB qui va bien pour ce matériel traduit ces valeurs en langage humain et compréhensible. Est ce cela dont tu parles ? dans ce cas, l'implémentation n'est que l'inclusion d'une MIB adéquate.

[surcouf]

Hum, je ne suis pas sûr de comprendre. Lorsque j'interroge un nouveau matériel sans MIB correspondante, je reçois un arbre d'OID avec des valeurs. Celles ci sont quasiment inexploitables en l'état. Le fait d'ajouter la MIB qui va bien pour ce matériel traduit ces valeurs en langage humain et compréhensible. Est ce cela dont tu parles ? dans ce cas, l'implémentation n'est que l'inclusion d'une MIB adéquate.

La MIB permet en effet de traduire les valeurs remontées. Mais, par exemple, les valeurs des OID relatifs aux interfaces réseaux sont le résultat d'une implémentation logicielle écrite dans l'agent SNMP. C'est de cela dont je veux parler. Il est nécessaire de disposer d'une partie logicielle, en C ou en Perl, minimale permettant de renvoyer les valeurs correspondantes aux OID interrogés (sans même parler de toute la mécanique nécessaire aux réponses et au protocole SNMP).

[claneys]

Ok, je vois un peu mieux. Tu parles d'implémenter des OID n'existant pas et d'écrire la MIB associée. Cela va être envisagé dans un futur assez proche je l'espère pour notre progiciel et peut être pour nos matériel robotique. Dans un premier temps, on utilisera les OID implémenter par les constructeurs tier pour les OS et matos standards.

[claneys]

Je continue mes investigations autour de SNMP. Je cherche des comparatifs et retour d'expérience sur l'impact perf sur des OS unix.

Évidemment, se pose le problème des plugins plus ou moins bien codés et du langage choisi pour les check par SSH, mais tant pis. C'est pour avoir un ordre d'idée. Ou sinon quelle méthode pour évaluer l'impact sur les perfs des deux méthodes ?
J'utilise personnellement l'accounting pour mesure l'impact de SSH en regardant le temps CPU consommé par un utilisateur dédié au lancement des checks et pour snmp, je regarde simplement le temps CPU consommé par un "ps -ef | grep snmp".

Et quelle fût ma surprise en constatant que snmp consommait plus que SSH. Donc je me demande si ma méthode est valide. Pour moi snmp devait être moins intrusif que des plugins écrit en perl ou bash.

[surcouf]

Je continue mes investigations autour de SNMP. Je cherche des comparatifs et retour d'expérience sur l'impact perf sur des OS unix.

Évidemment, se pose le problème des plugins plus ou moins bien codés et du langage choisi pour les check par SSH, mais tant pis. C'est pour avoir un ordre d'idée. Ou sinon quelle méthode pour évaluer l'impact sur les perfs des deux méthodes ?
J'utilise personnellement l'accounting pour mesure l'impact de SSH en regardant le temps CPU consommé par un utilisateur dédié au lancement des checks et pour snmp, je regarde simplement le temps CPU consommé par un "ps -ef | grep snmp".

Et quelle fût ma surprise en constatant que snmp consommait plus que SSH. Donc je me demande si ma méthode est valide. Pour moi snmp devait être moins intrusif que des plugins écrit en perl ou bash.

Peux-tu détailler tes méthodes ? Pour pouvoir faire une comparaison fiable, il faut absolument utiliser la même méthode de mesure dans les deux cas.
Sinon, tu devrais également regarder du côté du projet check_mk.

[claneys]

Pour mesure l'impact des checks SSH, j'utilise l'accounting. Je l'active ce qui génère les fichiers pacct dans /var/account et ensuite après une journée pleine, je fais un "sa -m pacct.1 | grep nagios" ( je prend pacct.1 pour avoir un jour révolu et plein). Et je regarde la colonne cp. Et pour snmpd je regarde TIME dans la sortie d'un ps -ef.

[CVAC]

Bonjour,

Ce sujet m'intéresse aussi. Les témoignages au-dessus sont très instructifs.

Y a t-il encore d'autres retours d'expérience?
claneys, as-tu choisi une solution?

Merci d'avance.