MySQL NDB Cluster mit Icinga überwachen

Diesen Beitrag schrieb ich 9 Jahre und 6 Monate zuvor; die nachfolgenden Ausführungen müssen heute weder genau so nach wie vor funktionieren, noch meiner heutigen Meinung entsprechen. Behalte das beim Lesen (und vor allem: beim Nachmachen!) bitte stets im Hinterkopf.

Geschätzte Lesezeit: 2 Minuten

Weitere Beiträge der Artikelserie „MySQL NDB Cluster“ findest du an dieser Stelle.

Um die Knoten überwachen zu können, wird auf allen nagios-nrpe-server und das Paket mit den nagios-plugins installiert; der Host webserver ist der, auf dem mein Icinga läuft und der die Daten einsammeln wird.

$ apt-get install nagios-plugins-contrib nagios-nrpe-server

Die erste „dumme“ Überprüfung schaut, ob auf den Cluster-Knoten jeweils die benötigten Dienste laufen; zusammengefasst sind das

  • 4x ndbd und 1x mysqld jeweils auf beiden Data Nodes sowie
  • 1x ndb_mgmd und 2x mysql-proxy jeweils auf beiden Management Nodes und
  • die RAM-Auslastung (nicht nur, aber besonders) auf den Data Nodes.

Allerdings fängt das nicht auf, wenn zwar alle Dienste laufen, aber nicht sauber miteinander verbunden sind, ist also nur bedingt sinnvoll; deshalb wird das Setup noch erweitert – und zwar um die Abfrage, ob alle Nodes korrekt miteinander verbunden sind. Auf den Data Nodes können die relevanten Teile der nrpe.cfg beispielsweise so aussehen (das gesamte File ist als nrpe.cfg-DATANODE verfügbar):

command[check_ndbd]=/usr/lib/nagios/plugins/check_procs -w 4:4 -c 1:5 -C ndbd
command[check_memory]=/usr/lib/nagios/plugins/check_linux_memory -f -w 20 -c 10 -d G

Und auf den Management Nodes können die relevanten Teile der nrpe.cfg beispielsweise so aussehen (das gesamte File ist als nrpe.cfg-MANAGEMENT verfügbar):

command[check_ndb_mgmd]=/usr/lib/nagios/plugins/check_procs -w 1:1 -c 0:2 -C ndb_mgmd
command[check_ndb_health]=/usr/lib/nagios/plugins/check_mysql_health --mode cluster-ndbd-running
command[check_memory]=/usr/lib/nagios/plugins/check_linux_memory -f -w 20 -c 10 -d G

Jetzt kann auf datanode1 mal ein ndbd geschossen werden; ich habe mich für NodeId=12 entschieden und ihn sauber über die Management-Konsole getrennt. Icinga meldet umgehend, dass auf datanode1 nicht mehr die korrekte Zahl an ndbd-Prozessen läuft, und beide Management Nodes melden, dass zu NodeId=12 keine Verbindung mehr besteht.

ndb_mgm> 12 stop
Node 12: Node shutdown initiated
Node 12: Node shutdown completed.
Node 12 has shutdown.

Da ich sowieso gerade Updates installiert hatte entschied ich mich, datanode1 mal vollständig herunterzufahren. Erwartungsgemäß wird in Icinga der gesamte Host ROT, und beide Management Nodes melden den Verlust zu Node 10, zu Node 12 und zum mysqld, der als Node 20 konfiguriert ist.

[1432385728] SERVICE ALERT: management1;MySQL NDB Health;CRITICAL;SOFT;1;CRITICAL - ndb node 10 is not connected, ndb node 12 is not connected, api node 20 is not connected
[1432385788] SERVICE ALERT: management2;MySQL NDB Health;CRITICAL;SOFT;2;CRITICAL - ndb node 10 is not connected, ndb node 12 is not connected, api node 20 is not connected

Schließlich wird datanode1 wieder hochgefahren, beide ndbd und auch der mysqld laufen an, und schließlich meldet Icinga, dass auch MySQL NDB Cluster wieder vollständig up&running ist – der Dienst MySQL NDB Health springt wieder auf GRÜN:

[1432385128] SERVICE ALERT: management1;MySQL NDB Health;OK;SOFT;4;OK - all ndb nodes are connected, all api nodes are connected
[1432385128] SERVICE ALERT: management2;MySQL NDB Health;OK;SOFT;4;OK - all ndb nodes are connected, all api nodes are connected
Alle Bilder dieser Seite: © Marianne Spiller – Alle Rechte vorbehalten
Hintergrundbild: Bild genauer anschauen – © Marianne Spiller – Alle Rechte vorbehalten

Eure Gedanken zu „MySQL NDB Cluster mit Icinga überwachen“

Ich freue mich über jeden Kommentar, es sei denn, er ist blöd. Deshalb behalte ich mir auch vor, die richtig blöden kurzerhand wieder zu löschen. Die Kommentarfunktion ist über GitHub realisiert, weshalb ihr euch zunächst dort einloggen und „utterances“ bestätigen müsst. Die Kommentare selbst werden im Issue-Tracker und mit dem Label „✨💬✨ comment“ erfasst – jeder Blogartikel ist ein eigenes Issue. Über GitHub könnt ihr eure Kommentare somit jederzeit bearbeiten oder löschen.