Montag, 4. November 2013
Wer seine MySQL-Installation mit Cacti überwachen möchte, sei Perconas Monitoring Plugins empfohlen. Die Datei (zum Zeitpunkt des Verfassens dieses Artikels war 1.0.5 aktuell) lädt man sich im Download-Bereich des Anbieters herunter.
$ cd /tmp
$ wget http://www.percona.com/redir/downloads/percona-monitoring-plugins/LATEST/percona-monitoring-plugins-1.0.5.tar.gz
Anschliessend entpackt man das Archiv:
$ tar xvzf percona-monitoring-plugins-1.0.5.tar.gz
Danach wechselt man in das cacti-Unterverzeichnis …
$ cd /tmp/percona-monitoring-plugins-1.0.5/cacti
… wo man folgenden Befehl ausführt:
cp -R . /var/www/cacti/
Dies kopiert alle nötigen Dateien (sprich: das ss_get_mysql_stats.php-Script) in das cacti-Root.
Anschliessend erstellt man sich unter MySQL einen Benutzer, welchen das Percona-Script verwenden wird, um die Parameter auszulesen:
GRANT SUPER, PROCESS ON *.* TO 'mysqlmon'@'localhost' IDENTIFIED BY "sikrit";
FLUSH PRIVILEGES;
Die Zugangsdaten erfasst man nun auch noch im Script ss_get_mysql_stats.php.
Anschliessend importiert man das XML-Template mit dem Namen cacti_host_template_percona_mysql_server_ht_0.8.6i-sver1.0.5.xml in cacti — dies geschieht über den Menupunkt Import Templates.
Zu guter letzt richte man sich einen neuen Host ein, gibt in das Adressfeld localhost ein und weist dem Host den Typ Percona MySQL Server HT zu. Anschliessend kann man die Graphen generieren.
Debugging
Bei Problemen hilft es, im Script folgende Zeile anzupassen …
...
$debug = TRUE;
...
… und die Kommandozeile, wie sie im cacti-Log auftaucht, in einer interaktiven Shell auszuführen.
ERROR 2013 (HY000): Lost connection to MySQL server at ‚reading initial communication packet‘, system error: 0
Diesem Fehler stand ich zu Beginn gegenüber. Folgende drei Massnahmen lösten das Problem schlussendlich:
- In /etc/mysql/my.cnf muss die Zeile mit bind-address = ... auskommentiert und der MySQL-Server neu gestartet werden.
- Dem MySQL-Benutzer mysqlmon muss in der Tabelle user in der Datenbank im Feld Host localhost eingetragen werden.
- MySQL muss über localhost und nicht über 127.0.0.1 angesprochen werden.
RRD-Dateien werden nicht aktualisiert …
… obwohl das cacti-Log aufzeigt, dass das PHP-Script Werte zurückliefert? Nach einem Debug-Spagat hatte ich die Lösung gefunden. Im cacti-Log las ich etwas in der Form:
...
/usr/bin/rrdtool update /var/www/cacti/rra/mysql_sort_rows_999.rrd --template Sort_merge_passes:Sort_range:Sort_rows:Sort_scan 1383591127:0:522:13426:951
...
Ich führte den Befehl auf der Kommandozeile aus und sah mich mit folgender Fehlermeldung konfrontiert:
ERROR: /var/www/cacti/rra/mysql_sort_rows_999.rrd: illegal attempt to update using time 1383591127 when last update time is 1383594548 (minimum one second step)
Den Unix-Timestamp 1383590086 konvertierte ich mit Bordmitteln in ein lesbares Kalenderdatum und stellte fest, dass die Uhrzeit eine Stunde zurück lag. Ich hatte es also mit einem ganz klassischen Zeitzonen-Problem zu tun!
Um sicher zu gehen, startete ich in eine interaktive PHP-Session:
$ php -a
Interactive mode enabled
php > date_default_timezone_get();
PHP Warning: date_default_timezone_get(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in php shell code on line 1
PHP Stack trace:
PHP 1. {main}() php shell code:0
PHP 2. date_default_timezone_get() php shell code:1
php >
Voila! Nachdem ich in der Datei /etc/php5/cli/php.ini folgende Information eingefügt hatte …
...
date.timezone = Europe/Zurich
...
… klappte es plötzlich mit den Updates.
