5. Surveillance

Ce script indispensable réalise différentes sortes d'analyse de l'état d'un cluster Slony-I™. Les Section 1, « Bonnes Pratiques avec Slony-I » de Slony-I™ recommendent l'exécution de ces scripts fréquemment (toutes les heures est une bonne idée) pour découvrir les problèmes aussi rapidement que possible.

Vous pouvez spécifier les arguments en incluant database, host, user, cluster, password et port pour vous connecter à un nœud du cluster. Vous pouvez aussi indiquer une commande mailprog (qui doit être un équivalent de l'application Unix™ mailx) et un destinataire des messages.

Autrement, vous pouvez spécifier les paramètres de connexion à la base de données via les variables d'environnement utilisées par libpq, c'est-à-dire en utilisant PGPORT, PGDATABASE, PGUSER, PGSERVICE et ainsi de suite.

Le script parcourt sl_path pour trouver tous les nœuds du cluster et les DSN pour lui permettre de se connecter à chacun d'entre eux.

Pour chaque nœ, the script examine l'état de différents éléments, dont :

Le script réalise un travail de diagnostique se basant sur les paramètres du script ; si vous n'aimez pas les valeurs par défaut, n'hésitez pas à les modifier !

Le script psql_replication_check.pl, qui se trouve dans le répertoire tools, regroupe les meilleures tentatives de de tests utilisables par le système de surveillance Nagios™.

Un script antérieur, nommé test_slony_replication.pl, utilisait une approche « intelligente » : un « script de test » est exécuté périodiquement et se déploie à travers les configurations Slony-I™ pour trouver l'origine et les abonnés, injecte un changement et observe sa propagation à travers le système. Il présentait deux problèmes :

Le nouveau script, psql_replication_check.pl, utilise une approche minimaliste qui suppose que le système est un système en ligne recevant un « trafic » régulier, et vous permet de définir une vue spécifique pour le test de réplication appelée replication_status qui doit contenir des mises à jour régulières. Cette vue regarde simplement la dernière « transaction » sur le nœud, et liste son horodatage, son âge ainsi que quelques informations sur l'application qui peuvent être utiles.

Une instance du script doit être exécutée sur chaque nœud surveillé ; c'est ainsi que Nagios™ fonctionne.

Un utilisateur a expliqué sur la liste de discussion de Slony-I™ comment configurer MRTG (acronyme de « Multi Router Traffic Grapher ») pour surveiller une réplication Slony-I™.

[...] puisque j'utilise MRTG pour visualiser les données depuis plusieurs serveurs, j'utilise SNMP (net-snmp pour être exact). Pour un serveur de bases de données, j'ai ajouté la ligne suivante à la configuration de snmpd :

exec replicationLagTime  /cvs/scripts/snmpReplicationLagTime.sh 2

avec /cvs/scripts/snmpReplicationLagTime.sh contenant ceci :

#!/bin/bash
/home/pgdba/work/bin/psql -U pgdba -h 127.0.0.1 -p 5800 -d _DBNAME_ -qAt -c
"select cast(extract(epoch from st_lag_time) as int8) FROM _irr.sl_status
WHERE st_received = $1"

Ensuite, dans la configuration de mrtg, j'ai ajouté la cible suivante :

Target[db_replication_lagtime]:extOutput.3&extOutput.3:public at db::30:::
MaxBytes[db_replication_lagtime]: 400000000
Title[db_replication_lagtime]: db: replication lag time
PageTop[db_replication_lagtime]: <H1>db: replication lag time</H1>
Options[db_replication_lagtime]: gauge,nopercent,growright

De son coté, Ismail Yenigul propose une méthode pour surveiller Slony-I™ en utilisant MRTG sans installer SNMPD.

Voici sa configuration MRTG :

Target[db_replication_lagtime]:`/bin/snmpReplicationLagTime.sh 2`
MaxBytes[db_replication_lagtime]: 400000000
Title[db_replication_lagtime]: db: replication lag time
PageTop[db_replication_lagtime]: <H1>db: replication lag time</H1>
Options[db_replication_lagtime]: gauge,nopercent,growright

Et voici sa version modifiée du script :

# cat /bin/snmpReplicationLagTime.sh
#!/bin/bash

output=`/usr/bin/psql -U slony -h 192.168.1.1 -d endersysecm -qAt -c
"select cast(extract(epoch from st_lag_time) as int8) FROM _mycluster.sl_status WHERE st_received = $1"`
echo $output
echo $output
echo 
echo
# end of script#

Autrement, Ismail Yenigul indique comment il a géré la surveillance de Slony en utilisant MRTG sans installer SNMPD.

Voici la configuration de mrtg :

Target[db_replication_lagtime]:`/bin/snmpReplicationLagTime.sh 2`
MaxBytes[db_replication_lagtime]: 400000000
Title[db_replication_lagtime]: db: replication lag time
PageTop[db_replication_lagtime]: <H1>db: replication lag time</H1>
Options[db_replication_lagtime]: gauge,nopercent,growright

et voici une version modifiée du script :

# cat /bin/snmpReplicationLagTime.sh
#!/bin/bash

output=`/usr/bin/psql -U slony -h 192.168.1.1 -d endersysecm -qAt -c
"select cast(extract(epoch from st_lag_time) as int8) FROM _mycluster.sl_status WHERE st_received = $1"`
echo $output
echo $output
echo 
echo
# end of script#

Ce script est construit pour chercher dans les journaux applicatifs Slony-I™, à un emplacement donné (LOGHOME), en se basant à la fois sur les conventions de nommage utilisées par les systèmes Section 21.4, « launch_clusters.sh » et Section 21.1.21, « slon_watchdog » lors du démarrage des processus slon(1).

Si des erreurs sont trouvées, elles sont listées pour chaque fichier et transmises par courriel à un utilisateur spécifié (LOGRECIPIENT) ; si aucun courriel n'est spécifié, le résultat est affiché sur la sortie standard.

LOGTIMESTAMP permet de rechercher à partir de cette (plutôt sur la dernière heure).

Un administrateur peut exécuter ce script une fois par heure pour surveiller les problèmes de réplication.

Le script mkmediawiki.pl , situé dans tools, peut être utilisé pour générer un rapport de surveillance du cluster compatible avec le populaire logiciel MediaWiki. Notons que l'option --categories permet à l'utilisateur de préciser un ensemble de catégories (séparées par une virgule) qui seront associées aux résultats. Si vous avez passer l'option --categories=slony1 à une série de clusters Slony-I™, cela entraînera la création d'une page catégorie répertoriant l'ensemble des clusters Slony-I™.

On pourra utiliser le commande ainsi :

~/logtail.en>         mvs login -d mywiki.example.info -u "Chris Browne" -p `cat ~/.wikipass` -w wiki/index.php                     
Doing login with host: logtail and lang: en
~/logtail.en> perl $SLONYHOME/tools/mkmediawiki.pl --host localhost --database slonyregress1 --cluster slony_regress1 --categories=Slony-I  > Slony_replication.wiki
~/logtail.en> mvs commit -m "More sophisticated generated Slony-I cluster docs" Slony_replication.wiki
Doing commit Slony_replication.wiki with host: logtail and lang: en

Notons que mvs est un client Mediawiki écrit en Perl ; sur Debian GNU/Linux, le paquet associé est nommé libwww-mediawiki-client-perl ; d'autres systèmes disposent probablement d'une version packagée sous un nom similaire.

Ce qui suit est un extrait du log slon(1) (version 2.0) pour le nœud #2 dans une exécution de « test1 » à partir de Section 25, « Banc d'essai Slony-I ».

DEBUG2 remoteWorkerThread_1: SYNC 19 processing
INFO   about to monitor_subscriber_query - pulling big actionid list 134885072
INFO   remoteWorkerThread_1: syncing set 1 with 4 table(s) from provider 1
DEBUG2  ssy_action_list length: 0
DEBUG2 remoteWorkerThread_1: current local log_status is 0
DEBUG2 remoteWorkerThread_1_1: current remote log_status = 0
DEBUG1 remoteHelperThread_1_1: 0.028 seconds delay for first row
DEBUG1 remoteHelperThread_1_1: 0.978 seconds until close cursor
INFO   remoteHelperThread_1_1: inserts=144 updates=1084 deletes=0
INFO   remoteWorkerThread_1: sync_helper timing:  pqexec (s/count)- provider 0.063/6 - subscriber 0.000/6
INFO   remoteWorkerThread_1: sync_helper timing:  large tuples 0.315/288
DEBUG2 remoteWorkerThread_1: cleanup
INFO   remoteWorkerThread_1: SYNC 19 done in 1.272 seconds
INFO   remoteWorkerThread_1: SYNC 19 sync_event timing:  pqexec (s/count)- provider 0.001/1 - subscriber 0.004/1 - IUD 0.972/248

Voici quelques notes pour interpréter cet affichage :