LSI MegaRAID Monitoring via Nagios

LSI MegaRAID Monitoring via Nagios

Vor mir steht ein Dell Server mit Linux darauf welcher ins Monitoring aufgenommen werden soll. Die üblichen Verdächtigen wie CPU, Arbeitsspeicher, Netzwerk-, Platten- und Systemlast habe ich. Die laufenden Dienste sowieso. Mir fehlt nur noch der Status vom RAID. Also bin ich auf die Suche gegangen. Mit vier Schritten zum Erfolg:

1. Verbaute Hardware ermitteln

Ein lspci verrät schon mal die erste Richtung was hier verbaut sein soll:

00:00.0 Host bridge: Intel Corporation Skylake Host Bridge/DRAM Registers (rev 07)
00:01.0 PCI bridge: Intel Corporation Skylake PCIe Controller (x16) (rev 07)
00:01.1 PCI bridge: Intel Corporation Skylake PCIe Controller (x8) (rev 07)
00:14.0 USB controller: Intel Corporation Sunrise Point-H USB 3.0 xHCI Controller (rev 31)
00:14.2 Signal processing controller: Intel Corporation Sunrise Point-H Thermal subsystem (rev 31)
00:16.0 Communication controller: Intel Corporation Sunrise Point-H CSME HECI #1 (rev 31)
00:16.1 Communication controller: Intel Corporation Sunrise Point-H CSME HECI #2 (rev 31)
00:17.0 SATA controller: Intel Corporation Sunrise Point-H SATA controller [AHCI mode] (rev 31)
00:1d.0 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #9 (rev f1)
00:1d.2 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #11 (rev f1)
00:1f.0 ISA bridge: Intel Corporation Sunrise Point-H LPC Controller (rev 31)
00:1f.2 Memory controller: Intel Corporation Sunrise Point-H PMC (rev 31)
00:1f.4 SMBus: Intel Corporation Sunrise Point-H SMBus (rev 31)
02:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS-3 3108 [Invader] (rev 02)
03:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5720 Gigabit Ethernet PCIe
03:00.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5720 Gigabit Ethernet PCIe
04:00.0 PCI bridge: Renesas Technology Corp. SH7758 PCIe Switch [PS]
05:00.0 PCI bridge: Renesas Technology Corp. SH7758 PCIe Switch [PS]
06:00.0 PCI bridge: Renesas Technology Corp. SH7758 PCIe-PCI Bridge [PPB]
07:00.0 VGA compatible controller: Matrox Electronics Systems Ltd. G200eR2 (rev 01)

Aha, ein LSI MegaRAID. Also mal wieder die Suchmaschine des Vertrauens bemüht und nachgeschaut ob es irgendwas gibt zum Thema "Nagios MegaRAID". Da war nichts dabei was wirklich gefallen hätte. Meist tausende Abhängigkeiten oder dieser Controller fehlte schlichtweg in der Liste der unterstützen Modelle. Jedoch bin auf der Suche nach einem passenden Check der LSI MegaRAID Storcli begegnet: https://www.broadcom.com/products/storage/raid-controllers/megaraid-sas-9271-8i#downloads. Das klang doch mal spannend. Fix installiert und aufgerufen mittels /opt/MegaRAID/MegaCli/MegaCli64 -CfgDsply -aALL -nolog (gekürzte Ausgabe):

# /opt/MegaRAID/MegaCli/MegaCli64 -CfgDsply -aALL -nolog
                                     
==============================================================================
Adapter: 0
Product Name: PERC H730 Adapter
Memory: 1024MB
BBU: Present
Serial No: 1234567
==============================================================================
Number of DISK GROUPS: 1

DISK GROUP: 0
Number of Spans: 1
SPAN: 0
Span Reference: 0x00
Number of PDs: 2
Number of VDs: 1
Number of dedicated Hotspares: 0
Virtual Drive Information:
Virtual Drive: 0 (Target Id: 0)
Name                :
RAID Level          : Primary-1, Secondary-0, RAID Level Qualifier-0
Size                : 931.0 GB
Sector Size         : 512
Is VD emulated      : No
Mirror Data         : 931.0 GB
State               : Optimal
Strip Size          : 64 KB
Number Of Drives    : 2
**snip**

Ok, bei Dell heißt der wohl PERC H730 Adapter. Soll auch recht sein 😉 Aber mit der Ausgabe lässt sich doch mal was anfragen. Der Status vom RAID wird etwas weiter unten als "Optimal" angegeben. Ich hab nur einen RAID-Verbund, also fix diese Ausgabe durch grep gejagt und mit einer kurzen, passenden Statusmeldung versehen.

2. NRPE command erstellen

Da dieser Server via NRPE geprüft wird also fix die nrpe.cfg um folgende Zeile erweitert:

command[check_megaraid]=[ $(echo $(sudo /opt/MegaRAID/MegaCli/MegaCli64 -CfgDsply -aALL -nolog | grep "^State" | cut -d: -f2)) == "Optimal" ] && (echo "RAID Status Optimal"; exit 0) || (echo "RAID Problem"; exit 2)

3. Via sudo die passenden Rechte geben

NRPE läuft bei mir unter der User-Kennung nagios. MegaCLI lässt sich aber nur via root wirklich sinnig aufrufen Also per sudo aufrufen und dazu noch via visudo folgende Zeile eingefügt:

nagios ALL=(ALL) NOPASSWD: /opt/MegaRAID/MegaCli/MegaCli64 -CfgDsply -aALL -nolog

4. Testen, einbauen und fertig

Ein erster Check via Konsole vom Monitoring-Server aus:

# /usr/lib/nagios/plugins/check_nrpe -H 10.16.23.61 -c check_megaraid
RAID Status Optimal

Sieht gut aus! Also noch fix ins eigentliche Monitoring eingebaut - hier ist es egal ob Nagios, Icinga, Shinken oder was auch immer verwendet wird: Solange es Naigos-Checks via NRPE prüfen kann sollte sich die Prüfung des LSI MegaRAIDs leicht einfügen lassen. So sieht es dann final bei mir in Icinga2 aus:

Nagios Check LSI MegaRAID

Nagios Check LSI MegaRAID

Einfach, schlicht, funktionell. Für meine Zwecke völlig ausreichend. Wie dieses Beispiel zeigt geht es oftmals auch ohne extra CheckCommand welches noch vorher in bash, Python oder was auch immer erstellt hätte werden müssen. Das spart Zeit.

Und morgen ist noch der IPMI dran um den allgemeinen Systemstatus zu ermitteln.

Nextcloud Update Check

Nextcloud Update Check

Nextcloud zeigt einem in der Verwaltung an ob es Updates gibt. Nur mag ich hier nicht immer nachsehen müssen, zumal ich viele Nextcloud-Instanzen zu verwalten habe. Die Logik dahinter müsste man doch für einen Monitoring-Check verwenden können. Alternativen? Bisher habe ich keine gefunden deren Funktionsweise mich überzeugt oder der über einen längeren Zeitraum problemlos funktioniert hätte. Es muss also eine eigene Lösung her!

Prolog

Nextcloud auf verfügbare Updates prüfen

Ich würde jetzt einfach mal vermuten, dass jeder der diesen Artikel tatsächlich liest Nextcloud kennt. Oder zumindest ownCloud. Sicherheitshalber nochmal nachschauen? Bitte, das geht hier https://nextcloud.com/ bzw. hier https://owncloud.org/. Da ich selbst inzwischen nur noch wenig mit ownCloud zu tun habe und fast alle Installation mit Nextcloud betreibe beziehe ich mich in diesem Blogbeitrag ausschließlich auf Nextcloud.

Wie in einem anderen Blogbeitrag beschrieben mag ich keine Mails welche mich auf verfügbare Updates hinweisen (Statusmails? Nein Danke!). Das wären schlichtweg zu viele Systeme die sich da innerhalb kürzester Zeit melden würden. Ebenso, auch wenn das für eine Plattform reichen täte, bin ich kein Fan davon in Nextcloud nachzusehen. Wenn es für die erste installierte Plattform Updates gibt, dann auch für alle anderen. Unterm Strich viel zu mühsam. Zumal wir auch Kunden haben die Ihre Cloud-Installation selbst betreuen. Hier könnte der Check als Hinweis für den Kunden dienen. Oder für mich als Serverbetreiber Grund genug sein mal wieder den Telefonhörer in die Hand zu nehmen und den Kunden gefühlvoll mit dem notwendigen Nachdruck davon zu überzeugen doch bitte Updates zu installieren. Sicherheit und so. Klappt richtig gut 😉

status.php Ausgabe von Nextcloud.

Bleibt die Frage wie prüfen. Ein paar Checks habe ich gefunden welche die lokale Version ermitteln in dem Sie die version.php-Datei im Dateisystem direkt auslesen oder einfach https://<deine.nextcloud>/status.php aufrufen. In diesem JSON-String findet sich die Versionsnummer. Eine aufbereitete Fassung der JSON-Daten siehst Du links im Screenshot. So oder so, der Teil mit der lokalen Versionsnummer ist leicht. Bleibt noch die Frage wie man heraus findet ob es überhaupt Updates gibt. Hierfür habe ich einige verschiedene Ansätze gefunden:

  1. 1Einer zum Beispiel war die Releases auf dem Nextcloud-Server auszuwerten https://download.nextcloud.com/server/releases/. Klar, das mag funktionieren. Aber richtig warm werde ich mit dieser Lösung nicht. Also weiter suchen.
  2. 2Sehr interessant fand ich die Variante wie unter https://github.com/janvonde/check_nextcloud beschrieben. Hierfür wird der Nextcloud Security Scan verwendet: https://scan.nextcloud.com/. Neben der Update-Prüfung erhält man hier gleich noch ein Sicherheitsrating oben drauf mit dazu. Super Grundgedanke. Jetzt das aber dabei, dass sich wie folgt auf der zugehörigen GitHub Seite liest: "Please don't run this check too often. There is an API limit at the scan.nextcloud.com server at the /api/queue endpoint with arround 250 POST requests a day. I personally run it every 24h". Eine Update-Prüfung einmal am Tag reicht mir absolut aus, jedoch habe ich wohl zu viele verschiedene Instanzen hier am laufen - die Meldung welche auf die Limitüberschreitung hinwies hat nur wenige Tage auf sich warten lassen. Das ist schade. Weil vom Ansatz her war der Check richtig super.
  3. 3Also musste eine andere Lösung her. Nextcloud selbst weiß doch auch ob es gerade ein Update gibt. Also habe ich mich hier auf die Suche begeben. Unter updater/index.php bin ich fündig geworden.
private function getUpdateServerResponse() {
        $this->silentLog('[info] getUpdateServerResponse()');

        $updaterServer = $this->getConfigOption('updater.server.url');
        if($updaterServer === null) {
                // FIXME: used deployed URL
                $updaterServer = 'https://updates.nextcloud.org/updater_server/';
        }
        $this->silentLog('[info] updaterServer: ' . $updaterServer);

        $releaseChannel = $this->getCurrentReleaseChannel();
        $this->silentLog('[info] releaseChannel: ' . $releaseChannel);
        $this->silentLog('[info] internal version: ' . $this->getConfigOption('version'));

        $updateURL = $updaterServer . '?version='. str_replace('.', 'x', $this->getConfigOption('version')) .'xxx'.$releaseChannel.'xx'.urlencode($this->buildTime).'x'.PHP_MAJOR_VERSION.'x'.PHP_MINOR_VERSION.'x'.PHP_RELEASE_VERSION;
        $this->silentLog('[info] updateURL: ' . $updateURL);

        // Download update response
        $curl = curl_init();
        curl_setopt_array($curl, [
                CURLOPT_RETURNTRANSFER => 1,
                CURLOPT_URL => $updateURL,
                CURLOPT_USERAGENT => 'Nextcloud Updater',
        ]);

 

In Zeile 7 ist der Update-Server angegeben und in Zeile 15 findet sich der Aufbau der URL. Einige dieser Bestandteile finden sich in der bereits angesprochenen version.php, der Rest sind Versionsnummern der lokal verwendeten PHP-Installation. Dies wird mit reichlich "x" getrennt zu einer langen URL zusammen gesetzt welche z.B. so aussieht:

https://updates.nextcloud.org/updater_server/?version=14x0x4x2xxxstablexx2018-11-22T13%3A16%3A37%2B00%3A00+d25e8a774a30f78017acdc366a79460cebbb552fx7x2x10

Diese Adresse geöffnet ergibt folgende Antwort:

<?xml version="1.0" encoding="UTF-8"?>
<nextcloud>
 <version>15.0.0.10</version>
 <versionstring>Nextcloud 15.0.0</versionstring>
 <url>https://download.nextcloud.com/server/releases/nextcloud-15.0.0.zip</url>
 <web>https://docs.nextcloud.com/server/15/admin_manual/maintenance/upgrade.html</web>
 <changes>https://updates.nextcloud.com/changelog_server/?version=15.0.0</changes>
 <autoupdater>1</autoupdater>
 <eol>0</eol>
 <signature>c4llfwhYTKaEiTWVivJ1NgTIS5q2mxJVJkyew0nd/setTzpXt2H9zXKGQLmjUcy7
fSeW5+wkUfGD2J3XrcLKifGZMjxrhtAW97L1g/o8gp84ZO1WbrOKfneTLDXWkmwg
nztf/5z0F0nppOyUX6HR84UhwDbhET7U8JV/1Ik7OO6D361U4sxELUhvg6GyQbdS
oJ/t4MvMe1Fs+F5Q7dZzczivxu5oB0n2cVu9WMh8VnV6MiYcKV4/w7poibHMO16k
4IHl6E2hTF3un0obMKy7SRY4xXJ0Ohmj5Ne/8iDRjM7oop5Tzpnf1nPLEJJOZPSN
fq4UospVzAmRe4UGPTUiqQ==</signature>
</nextcloud>

 

In diesem Beispiel ist die Version 15.0.0.10 als aktuellere Version zur angefragten 14.0.4.2 verfügbar. Falls keine xml-Datei ausgeliefert wird ist die Nextcloud Installation auf aktuellem Stand.

Das war es mit dem Verfahren zur Prüfung ob es Updates gibt. Bleibt noch die Umsetzung über. Obwohl dies sehr einfach in PHP selbst zu realisieren wäre ist bei mir die Wahl auf Python3 gefallen. Ich wollte schon längst mal wieder was in Python machen um meine angestaubten Python-Kenntnisse aufzufrischen und vor allem zu vertiefen. Also wurde die Sprache der Wahl die aktuelle Version von Python3. Die versions.php ist eine relativ einfach PHP-Datei welche sich gut auslesen lassen sollte. Fehlen noch die benötigten PHP-Versionsnummern. Ein an dieser Stelle gern genommener Trick ist in der vermeintlichen anderen Sprache die benötigten Daten in ein Array zu packen und dieses per JSON auszugeben. Die so umgewandelten Daten lassen sich dann super weiterverarbeiten:

ncVersion = json.loads(subprocess.check_output([
    args.php, '-r',
    'include \'' + args.file + '\';' + '''
    $g = array();
    foreach($GLOBALS as $key => $val) {
      if(preg_match('/^OC_/', $key)) {
        $g[$key] = $val;
      }
    }
    echo json_encode(
      array(
        'pv'   => PHP_VERSION,
        'pmav' => PHP_MAJOR_VERSION,
        'pmiv' => PHP_MINOR_VERSION,
        'prv'  => PHP_RELEASE_VERSION,
        'g'    => $g
      )
    );
    '''
]))

 

Noch ein kleiner Tipp für alle die PHP an der Stelle nicht so gut kennen: Man könnte einfach das Array $GLOBALS ausgeben, da wären alle Werte drin. Nur gibt es in $GLOABLS eine Referenz auf sich selbst da ja auch $GLOBALS eine globale Variable ist. Und an genau der Stelle steigt json_encode() aus da diese Funktion mit Referenzen nicht umgehen kann. In der versions.php fangen aber alle interessanten Variablen mit "OC_" an und lassen sich somit super filtern ;-).

Den kompletten Check, eine Makro gestützte Beispiel-Konfig für Icinga2 sowie eine kurze Anleitung findet Ihr in meinem GitLab-Account: https://gitlab.com/Gehirn-Mag.net/icinga-and-nagios-plugins/. Bis jetzt liegt da nur der Nextcloud-Update-Check drin, weitere werden aber folgen.

Und so sieht das dann im icingaweb2 aus:

check_nextcloud.py Ausgabe in icingaweb2

Was jetzt noch fehlt ist die Prüfung der Addons auf Aktualität. Auch hierfür sollte sich der passende Anfragestring irgendwo im Quellcode von Nextcloud finden lassen. Mir reicht jedoch vorerst die Prüfung von Nextcloud selbst. Ich bin also vorerst zufrieden. Wer weiß, ggf. reiche ich in ein paar Wochen die Erweiterung für die Addons nach.

Viel Spaß beim benutzen. Feedback und Anregungen gerne via Mail oder hier in den Kommentaren hinterlassen.

Achtung:

Nachtrag

An dieser Stelle sind alle Dinge gesammelt die sich seit der Erstellung des Checks und des obigen Beitrages geändert haben. Sollte es zu viel werden wird dieser Beitrag als veraltet markiert und ein neuer verfasst. Bis dahin gilt diese Übersicht.

Geänderter Update Channel

Es ist möglich den Update Channel in Nextcloud zu ändern. Diese Einstellung findet sich jedoch nicht in der versions.php sondern in der config/config.php. Sollte dort der Channel definiert sein wird dieser verwendet, ansonsten der aus der versions.php. Das hat jedoch zur Folge, dass via -c jetzt noch zusätzlich die config.php mit angegeben werden muss.

Anmerkung zur Icinga Config: Die config.php darf vermutlich vom Benutzer welcher Icinga ausführt nicht gelesen werden. Deswegen ist im CheckCommand ein Aufruf von sudo mit enthalten.

Python vor 3.6

Bei Python Versionen bis 3.5.x erscheint die Fehlermeldung "CRITICAL Cannot parse file /var/www/nextcloud/version.php". Ab Version 3.6 ist dieses Problem behoben.

Falls kein Update auf Pyhton 3.6.x möglich ist kann der Check wie folgt angepasst werden:

// Die import Liste um chardet erweitern - muss ggf. vorher noch installiert werden
import chardet

// Den ersten try: Block wie folgt bearbeiten
try:
    jsonResponse = subprocess.check_output([
        args.php, '-r',
        'include \'' + args.file + '\';include \'' + args.config + '\';' + '''
        $g = array();
        foreach($GLOBALS as $key => $val) {
          if(preg_match('/^(OC_|CONFIG$)/', $key)) {
            $g[$key] = $val;
          }
        }
        echo json_encode(
          array(
            'pv'   => PHP_VERSION,
            'pmav' => PHP_MAJOR_VERSION,
            'pmiv' => PHP_MINOR_VERSION,
            'prv'  => PHP_RELEASE_VERSION,
            'g'    => $g
          )
        );
        '''
    ])
    print(jsonResponse)
    ncVersion = json.loads(jsonResponse.decode(chardet.detect(jsonResponse)['encoding']))
Statusmails? Nein Danke!

Statusmails? Nein Danke!

Prolog

Das Problem

Ich mag keine Emails. Also in so manchen Momenten zumindest. Ein Beispiel: Ein von mir verwaltetes Emailsystem umfasst mehrere Server die in sogenannte Postoffices unterteilt sind. Das tägliche Backup eines jeden Postoffices generierte bei erfolgreichem Backup eine Email mit einem ausführlichen Bericht und schickte diese an das Sammelpostfach der Systemadministratoren. Soweit so gut, könnte man meinen.

Dennoch gibt es zwei Dinge an diesem Konstrukt die mich grandios stören:

  1. 1Die Email wird bei erfolgreichem Backup verschickt. Das heißt fehlt die Email lief kein Backup. Nun sind es aber viele Postoffices: Die Wahrscheinlichkeit eines zu übersehen in den Unmengen von Mails im Sammelpostfach ist schlichtweg viel zu hoch.
  2. 2Mal ehrlich sein: Der Statusbericht des Backups des Emailsystems kommt per Email? Nee, oder? Nicht gerade eine beruhigende Kombination: Im Falle eines Totalausfalls des Postoffices wo das Sammelpostfach der Admins drin ist und man gerade auf ein erfolgreiches Backup der letzten Tage hofft. Das könnte die ein oder andere Schweißperle auf die Stirn treiben...

Da muss eine Lösung her, das kann so nicht blieben. Es sind viel zu viele Emails die täglich in das Admin-Postfach eintrudeln - kaum möglich diese wirklich alle mit der notwendigen Sorgfalt zu erfassen. Zumal man auch noch andere Dinge zu tun hat außer Emails auf Vollständigkeit zu prüfen. Und dann gibt es da noch dieses Gerät namens Telefon. Ein jeder Admin weiß was das bedeutet...

Die Lösung

Dabei ist die Lösung so einfach: Ein System in das jeder Admin mehrfach unterm Tag rein schaut. Gibt es zumindest bei uns. Monitoring heißt das Zauberwort. Freundlicherweise liefert das oben beschriebene Backup wenn man in der Doku sucht doch tatsächlich das passende Plugin bereits mit. Jetzt weiß das Monitoring ob die letzte Sicherung aktuell genug ist. Und falls nicht ist im Monitoring auch gleich noch der Link zum Protokoll vom Backup-Server hinterlegt. Besser kann es kaum werden. Und angenehm ist es auch:

  1. 1Die lästige Kontrolle der Emails fällt weg
  2. 2Das Postfach wird übersichtlicher da weniger Mails ankommen
  3. 3Die doppelte und unnötige Vorhaltung der Logs auf dem Backupserver und in einer Mail im Mailsystem entfällt. Das spart Plattenplatz und vor allem teuren Platz in der Emailumgebung.

Diese oder ähnliche Situationen begegnen mir regelmäßig bei der Arbeit. Irgendwelche genau genommen dumpfsinnigen Emails werden durch die Gegend geschickt die im Grundrauschen der Emailflut im Admin-Postfach viel zu schnell übersehen werden. Die Dienstqualität leidet durch das zu späte oder gar nicht richtige Erfassen von aufkommenden Problemen.

An dieser Stelle bin ich Befürworter der Grundthese, dass im Adminpostfach nur die notwendigsten Dinge ankommen sollten. Laufzeitberichte, Diagnosemails usw. gehören ins Monitoring. Dort sind diese viel besser aufgehoben und können bei Problemen kann ganz anders wahrgenommen und bearbeitet werden.

Die Grundidee, dass Monitoring so viel mehr bieten kann wie die nur teils verwendete einfache Dienstüberwachung ziehe ich an vielen Stellen durch: Papierfüllstände und Tonervorrat an die Azubis, Laufzeit-Infos zu Backupjobs an die Kollegen vom Backup, Accountinginformationen der Mailrelays an die Buchhaltung zur monatlichen Rechnungslegung und noch viel, viel mehr Abseits der einfachen Überwachung von ein paar einfachen Serverdiensten... Das kann Monitoring ebenfalls bieten.

Kombiniert mit der rechtzeitigen Erkennung von aufkommenden Problemen bevor Dienste ausfallen und Monitoring beginnt richtig Spaß zu machen. Weitere Blogbeiträge zu diesem Thema werden folgen 😉