MySQL NDB Cluster mit Icinga überwachen
Diesen Beitrag schrieb ich 9 Jahre und 4 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.
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
ndbdund 1xmysqldjeweils auf beiden Data Nodes sowie - 1x
ndb_mgmdund 2xmysql-proxyjeweils 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
Hintergrundbild: Bild genauer anschauen – © Marianne Spiller – Alle Rechte vorbehalten
