EMC Clariion Überwachung (check_emc_clariion.pl)

Im Rahmen eines Kundenprojektes bei der Firma iSC GmbH in Landau haben wir ein Plugin für die Überwachung der EMC Clariion SAN Komponenten entwickelt.

Das Plugin bedient sich hierzu des EMC eigenen und als Linux Version verfügbaren Administrationstools navicli, hierdurch ist es möglich den Hardware Status der einzelnen Storageprozessoren (Netzteile, Lüfter, usw.) abzufragen. Die Überwachung der Festplatten innerhalb der DAE`s ist ebenfalls möglich, im Fehlerfall wird ausgegeben, welche Platte(n) in welchem Enclosure defekt ist.

Um die Verfügbarkeit des SAN`s zu gewährleisten können die Ports auf den SP`s und die Pfade zu den HBA`s ebenfalls überwacht werden.

Das Plugin ist wie von uns gewohnt auf NagiosExchange unter check_emc_clariion.pl abrufbar.

Share/Save/Bookmark

Weiterführende Artikel

2 Responses to “EMC Clariion Überwachung (check_emc_clariion.pl)”


  1. 1 darkfader

    Hi,

    ich habe das Plugin voller Begeisterung bei uns eingerichtet, da es leider absolut unmoeglich war, bei EMC^2 das ndu-Package mit dem SNMP-Subagent fuer die Clariion zu bekommen, da weiss keiner mehr, dass es existiert ;)

    Ich kann leider so gut wie garkein Perl, insofern schreibe ich Euch mal noch hierher, was mir so auffiel, ansonsten haette ich nen Patch geliefert.

    –node –paths sollte -w und -c kennen, je nach Environment kann ein ausgefallener Pfad auch mal nur ein Warning sein. (Bei uns gehen im Endausbau aus OS-sicht 10 Pfade zum Storage, real sind es immernoch 2 SAN Fabrics und 1 iSCSI ausserhalb der Fabric. Wenn da einer ausfaellt, wuerde mir ein Warning ausreichen, bzw. eventuell sollte ich da eher etwas in Richtung check_multi denken?

    Ausserdem hab ich die WWN aus dem Output geworfen, da er mir abgeschnitten wurde, und ich glaube generell ist das einfach zu viel. Als Status wuerde mir da wesentlich weniger reichen, denn so sehe ich den eh nicht - der Text ist zu lang fuer Nagios.

    Dann nochwas - navicli kann recht langsam sein, bzw. Probleme ausloesen, insofern frag’ ich mich, ob es besser waere, ein ‘Master’Plugin zu haben, mit dem der Output geholt wird, den die Checks dann auslesen. Zur Erlaeuterung: Unter Volllast kann man mit navicli getall einen “SP unmananged” provozieren. Wenn man dicke Finger hat, macht man das zweimal und hat danach ein bisschen weniger Daten, die man sichern muss, auch bekannt als unowned Luns. (Ich nicht, aber es geht)

    Eine -tresspass Option waere noch interessant (getlog -1000 und nach “shutdown for tresspass” zaehlen und ueber die letzten 60 Min suchen und dann critical, wenn es ueber 100 waren)

    -t disks hat noch einen Schwachpunkt: Wenn Platten in ‘transitioning’ (z.B. beim Lun bind) sind, gibt es ein Critical - das ist ne eiskalte Falschmeldung, schwierig, wenn man ne groessere Erweiterung bekommt, und dann 8h lang Luns gebunden werden. Ausserdem wird einem hier auch wieder der Text abgeschnitten *g*

    Generell: einer der tollsten Plugins fuer Nagios ueberhaupt. Ich hatte den jahrelang auf der Todo-liste und nie etwas draus gemacht - einfach nur super, dass ihr den gebaut habt!!!!

  2. 2 Julian

    Wow, danke für das Feedback. Ich geb die Infos mal an die Kollegen, vielleicht können wir da was umsetzen. Gruß, Julian

Leave a Reply