Über den MySQL-Router haben wir hier bereits an mehreren Stellen berichtet. Er spielt bei MySQL-Hochverfügbarkeits-Lösungen (z. B. dem InnoDB-Cluster) eine zentrale Rolle. Seit der Version MySQL 8.0.17 wurde der Router um eine REST API erweitert. Über diese Schnittstelle lässt sich der Zustand und die ordnungsgemäße Funktionsweise überprüfen. In diesem Beitrag stellen wir ihnen den Funktionsumfang der jetzt aktuellen Version 8.0.29 vor.

Mehr unter: blog.ordix.de

In meinem letztem Projekt habe ich mal wieder nach einem (Performance)Monitoring Tool gesucht und mit Prometheus sogar fündig geworden. Prometheus kann weit mehr als eine MySQL Instanz ‘monitoren’. Dabei ist die Grundidee von Prometheus Metriken einzusammeln.

Hier ein einfaches Beispiel einer Konfiguration von Prometheus:

global: 
  scrape_interval: 1m
  scrape_timeout: 10s
  evaluation_interval: 1m

scrape_configs:
  - job_name: mysql
    scheme: http
    target_groups:
    - targets: 
        - '10.17.148.31:9104'
      labels:
        zone: mysql

Das ist eigentlich eine langweilige Config. Der Witz von Prometheus ist viele Quellen zu aggregieren und damit auch korrellieren zu können. Sprich viele Jobs und massig Targets. Damit ist Prometheus die zentrale Performancedatenbank, welche die Metriken aller Targets sammelt und speichert.

Bleiben wir …

Ich habe heute an dem Problem weiter geforscht und wir haben etabliert, dass die Ursache nicht der Quelltext des betreffenden Diamond-Collectors sein kann.

Auf allen betroffenen Kisten habe ich dann gesehen, daß die entsprechenden Queries gegen Performance-Schema ein

CODE:mysql> select * from performance_schema.threads;

Empty set (0.01 sec)

zurück liefern.

Weitere Untersuchung stellt heraus: P_S ist aber an. Jedoch:

CODE:mysql> select * from performance_schema.setup_instruments;

Empty set (0.03 sec)

mysql> select * from performance_schema.setup_timers;

Empty set (0.01 sec)

mysql> select * from performance_schema.setup_consumers;

Empty set (0.02 sec)

…

Monitoring MySQL - für welche Nutzer, was aufzeichnen, welche Tools verwenden? Ich bin gestern abend glücklich, aber müde auf der Open Source Monitoring Conference in Nürnberg angekommen und dann fast sofort ins Bett gefallen. Heute morgen war ich gleich als Erster dran, mit einem Vortrag über "Monitoring MySQL". Da ich dieses Mal nur mit einem Vortrag dabei bin, habe ich nun also frei und kann die Konferenz genießen.

Meine Slides stehen schon zum Download bereit. Der Vortrag selbst ist außerdem vom Linux Magazin gestreamed und aufgezeichnet worden. Die Aufbereitung wird noch ein wenig dauern, da das Linux Magazin Slides und Bild getrennt aufzeichnet und dann synchron anzeigt …

Vortragsfolien "Monitoring MySQL" Ich war faul. Die Vortragsfolien zu "Monitoring MySQL" hätten schon lange online sein sollen. Wie dem auch sei: Wie versprochen sind sie hier nun...

Auf Sourceforge findet man Plug-in development guidelines für den Nagios Netzwerkmonitor. Demnach ist es trivial, Nagios-Plugins zu entwickeln: Der Check ist ein externes Programm, das den Returncode 0, 1 oder 2 zurück gibt und eine einzeilige Nachricht auf stdout druckt.

Tun wir das doch mal für MySQL: Wir wollen die Anzahl der Threads_connected überwachen und den Replikationsstatus: SQL-Thread und IO-Thread müssen laufen und der Slave-Lag darf nicht zu groß sein.

Wir schreiben das Plugin in C, damit wir zugleich mal lernen, die MYSQL Client-API in C zu verwenden - Shellscripte, die sich das abbrechen gibt es ja schon genug.

Der gesamte Quelltext aus diesem Beispiel kann hier runtergeladen werden: check_mysql.c
…

Heute habe ich Das Böse gesehen. Und überlebt. Lest meinen Tagebucheintrag während ich dem Trunke verfalle um das Vergessen zu suchen:

Kris vs. Net SNMP, Runde 1 - Das Perl-Match.