Supervision VPlex via Cacti : les détails

J’ai eu de nombreuses réactions depuis la publication il y a quelques mois de mon billet sur la supervision “long terme” de VPlex. Notamment, les principales questions qui reviennent concernent le détail de l’intégration Cacti des metrics des clusters via SNMP. Du coup, plutôt que de répondre à chacun séparément, je vous propose de revenir plus techniquement sur cet aspect spécifique.

Je ne vais pas revenir en détail sur le fonctionnement et les concepts de l’outil Open Source Cacti, bien connu de nombreux ingénieurs et techniciens informatiques, je pense. Dans tous les cas, si vous faite partie des personnes qui n’ont jamais entendu parler de ce génial framework RRDTool, rendez-vous tout de suite et avant toute chose sur son site dédié.

Concernant spécifiquement notre intégration VPlex à Cacti, donc, nous avons créé des templates (data / graphs) relativement simples pour récolter et présenter les données. Celles-ci sont directement issues d’interrogations SNMP. La mib SNMP des VPlex est directement disponible dans le répertoire /opt/emc/VPlex/mibs de chaque management console de vos clusters :

Dans le détail, voici les OID que nous avons utilisé et les graphiques qui en découlent :

CPU des directeurs 1-1-A et 1-1-B :
.1.3.6.1.4.1.1139.21.2.2.3.1.1.128.221.252.35
.1.3.6.1.4.1.1139.21.2.2.3.1.1.128.221.252.36
Vous noterez (et ce sera confirmé dans la suite de ce billet) que les OID se terminent tout simplement par les IP internes des directeurs.

CPU des directeurs 2-1-A et 2-1-B :
.1.3.6.1.4.1.1139.21.2.2.3.1.1.128.221.252.67
.1.3.6.1.4.1.1139.21.2.2.3.1.1.128.221.252.68
Très logiquement, les OIDs son suffixés par les IP de ces directeurs du cluster-2.

Latence en lecture sur les ports front-end des directeurs (1-1-A, 1-1-B, 2-1-A, 2-1-B) :
.1.3.6.1.4.1.1139.21.2.2.4.1.5.128.221.252.35
.1.3.6.1.4.1.1139.21.2.2.4.1.5.128.221.252.36
.1.3.6.1.4.1.1139.21.2.2.4.1.5.128.221.252.67
.1.3.6.1.4.1.1139.21.2.2.4.1.5.128.221.252.68
Latence en écriture sur les ports front-end des directeurs (1-1-A, 1-1-B, 2-1-A, 2-1-B) :
.1.3.6.1.4.1.1139.21.2.2.4.1.6.128.221.252.35
.1.3.6.1.4.1.1139.21.2.2.4.1.6.128.221.252.36
.1.3.6.1.4.1.1139.21.2.2.4.1.6.128.221.252.67
.1.3.6.1.4.1.1139.21.2.2.4.1.6.128.221.252.68

Pour les ports back-end, même logique, dans l’ordre : lecture, écriture :
.1.3.6.1.4.1.1139.21.2.2.6.1.5.128.221.252.35
.1.3.6.1.4.1.1139.21.2.2.6.1.5.128.221.252.36
.1.3.6.1.4.1.1139.21.2.2.6.1.5.128.221.252.67
.1.3.6.1.4.1.1139.21.2.2.6.1.5.128.221.252.68
.1.3.6.1.4.1.1139.21.2.2.6.1.6.128.221.252.35
.1.3.6.1.4.1.1139.21.2.2.6.1.6.128.221.252.36
.1.3.6.1.4.1.1139.21.2.2.6.1.6.128.221.252.67
.1.3.6.1.4.1.1139.21.2.2.6.1.6.128.221.252.68

Au passage, vous remarquerez que la plupart des graphiques sont assez “discontinus”, dans le sens ou il existe des trous de supervision. Cela est du uniquement à l’instabilité chronique de l’agent SNMP en Geosynchrony 5.2 et 5.3 au moins. J’en ai parlé à plusieurs reprises sur ce blog (voir ici par exemple). Certes, ce n’est pas crucial pour la production, mais je trouve cela un peu cavalier de la part d’EMC de ne pas avoir stabilisé une fonction aussi basique depuis plus de 18 mois maintenant. Mon dernier appel au support d’il y a quelques mois sur ce sujet n’a pas permis de résoudre le problème. Tout juste ai-je pu suggérer moi-même des procédures palliatives (relance régulière du démon via cron) qui ont été acceptées par la hotline. Pas génial …

Enfin, sachez que certains OID pourtant présents dans la mib VPlex ne renvoient aucune données exploitable. C’est le cas par exemple des metrics de type “Bytes Read/Write”, comme celui-ci :

Si on interroge le démon via un snmpwalk/snmpget, on obtient aucun résultat. Le metric est tout simplement absent. J’ai tenté d’avoir une explication via mes contacts EMC, mais il n’ont pas su me répondre. Curieux.

J’espère que ce petit billet technique aura répondu à toutes vos questions ;)

Sources :
Un document sur la supervision VPlex chez EMC : ICI.
Cacti : ICI.