VPlex 5.3p2 : toujours des problèmes de snmp

Je vous en avait parlé lors de notre upgrade en VPlex 5.2 l’année dernière, déjà à l’époque le démon snmp était victime d’un bug (fuite mémoire d’après le support) le rendant instable et nous interdisant donc de faire de la supervision de nos engines via ce module.

Depuis le passage à la 5.3p2 de nos clusters, évidemment, nous avons relancé ce processus de récolte de données d’activité (CPU, mémoire, latences), mais nous rencontrons encore des soucis, différent de la 5.2, mais toujours aussi ennuyeux au quotidien. D’une part, modulo une semaine, les démons SNMP s’arrêtent sans raison apparante et d’autre part, les données de latence récoltées semblent plus ou moins fiables.

Avant d’aller plus loin, sachez qu’il vous faut l’accès root aux management stations pour réaliser les corrections présentées plus loin. Contactez vos locaux EMC ou à défaut, discutez avec la hotline pour obtenir ces modifications.

Problèmes de redémarrage des démons SNMP :

Sur cet aspect et malgré mon appel au support EMC, cela n’a pas beaucoup avancé durant ces dernières semaines. Du coup, j’ai pris la décision d’investiguer personnellement la chose en regardant un peu les logs des management stations. Il se trouve que le problème se situe au niveau de la tâche de “logrotate”. Les administrateurs Linux connaissent bien cette opération de maintenance régulière de la plupart des distributions qui consiste à archiver les logs suivant certains critères et générer dans la foulée de nouvelles enveloppes vierges, prêtes à recevoir les nombreux messages système. Plus précisément, les démons snmp sont arrêtés suite à ce logrotate spécifique mais ne sont pas redémarrés correctement.

La commande utilisée au sein du logrotate, /etc/init.d/snmpd try-restart n’arrive pas à tuer le démon assez vite et du coup, ne le redémarre pas. Si on fait l’essai en ligne de commande directe, on se rend compte que le process smnp met entre 3 et 5 secondes à s’arrêter, ce qui est visiblement trop long pour le script de relance.

Du coup, en changeant les directives initiales logrotate :

… par celles-ci :

… cela laisse le temps au process de s’arrêter correctement et être redémarré ensuite dans de bonnes conditions. Evidement, c’est un contournement un peu “dur” mais il a le mérite de fonctionner !

A propos de la fiabilité des latences remontées via snmp

Une fois le snmp “fiabilisé”, nous avons donc relancé nos moniteurs CPU, Mémoire et Latences. On s’est rendu compte que les indicateurs de latence ne fonctionnaient pas durant de longues périodes, comme le montre ces graphiques :


En inspectant les logs snmp, on se rend compte que le démon rencontre des problèmes réguliers dans la récupération des valeurs correspondantes :

Pour le coup, ici, mes compétences atteingent leurs limites et j’ai donc créé un nouveau SR au sujet de ces dysfonctionnements réguliers.

Je ne manquerais pas de vous faire un retour dès que j’aurais reçu plus d’information à ce sujet. Le fait est qu’EMC a donc encore des problèmes avec la fiabilisation des démons SNMP de VPlex. Je sais que ce n’est sans doute pas une fonction très utilisée, mais elle existe, elle est documentée, donc elle se doit d’être fonctionnelle.