root/traduc/trunk/slony/monitoring.xml

<?xml version="1.0" encoding="UTF-8"?>
<!-- DerniÚre modification
     le       $Date$
     par      $Author$
     révision $Revision$ -->

<sect1 id="monitoring">
<title>Surveillance</title>

<indexterm><primary>Surveiller &slony1;</primary></indexterm>

<sect2> <title> Tester la replication avec &nagios; </title>

<indexterm><primary>&nagios; pour surveiller la réplication</primary></indexterm>

<para> Le script <command> psql_replication_check.pl </command>  qui se trouve 
  dans le répertoire <filename>tools</filename> regroupe les meilleures
  tentatives de construire de création de tests utilisables par le systÚme 
  de surveillance <ulink url="http://www.nagios.org/"> &nagios;</ulink>.</para>

<para> Un script antérieur, nommé <filename>
test_slony_replication.pl</filename>, utilisait une approche <quote>intelligente</quote>
: un <quote>script de test</quote> est exécuté périodiquement et se déploie à travers les configurations
&slony1; 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 :</para>
<itemizedlist>

<listitem><para> En cas de problÚme de connectique impactant le noeud qui jouait ce test
    c'est l'ensemble de réplication qui semblait détruite. De plus, cette stratégie de
    surveillance est trÚs fragile et dépend de nombreuses conditions d'erreurs.</para>
</listitem>

<listitem><para> &nagios; n'a pas la possibilité de profiter de 
<quote>l'intelligence</quote> d'une exploration automatique d'un ensemble de noeuds.
Vous devez mettre en place des rÚgles de surveillance &nagios; pour chaque noeud.
</para> </listitem>
</itemizedlist>

<para> Le nouveau script, <command>psql_replication_check.pl</command>,
utilise une approche minimaliste qui suppose que le systÚme est une 
systÚme en ligne recevant un <quote>trafic</quote> régulier, et vous 
permet de définir une vue spécifique pour le test de replication appelée
<envar>replication_status</envar> qui doit contenir des mises à jour
réguliÚres. Cette vue regarde simplement la derniÚre 
<quote>transaction</quote> sur le noeud, et liste son timestamp, son âge,
ainsi que quelques informations sur l'application qui peuvent être utiles.
</para>

<itemizedlist>

<listitem><para>Pour un systÚme d'inventaire, cela pourrait être
    le numéro de l'ordre effectué le plus récemment. </para> </listitem>

<listitem><para>Pour un serveur de nom de domaines, cela peut être le nom 
    du dernier domaine crée.</para> </listitem>

</itemizedlist>

<para> Une instance du script doit être lancée sur chaque noeud surveillé; 
  c'est ainsi que &nagios; fonctionne.</para>

</sect2>

<sect2 id="slonymrtg"> <title> Surveiller &slony1; avec MRTG </title>

<indexterm><primary>Utiliser MRTG pour surveiller la réplication</primary></indexterm>

<para> Un utilisateur a expliqué sur la liste de discussion de &slony1; comment
  configurer <ulink url="http://people.ee.ethz.ch/~oetiker/webtools/mrtg/">
<application> mrtg ( Multi Router Traffic Grapher )</application>
</ulink> pour surveiller une réplication &slony1;.</para>

<para> ... Puisque j'utilise <application>mrtg</application> pour visualiser
  les données depuis plusieurs serveurs, j'utilise SNMP 
  (<application>net-snmp</application> pour être exact).*
  Pour un serveur de base de données, j'ai ajouté la ligne suivante à la configuration
 <application>snmpd</application> :</para>

<programlisting>
exec replicationLagTime  /cvs/scripts/snmpReplicationLagTime.sh 2
avec <filename> /cvs/scripts/snmpReplicationLagTime.sh</filename> contenant ceci :
</programlisting>


<programlisting>
#!/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"
</programlisting>

<para> Ensuite, dans la configuration de mrtg, ajouter la cible suivante :</para>
<programlisting>
Target[db_replication_lagtime]:extOutput.3&amp;extOutput.3:public at db::30:::
MaxBytes[db_replication_lagtime]: 400000000
Title[db_replication_lagtime]: db: replication lag time
PageTop[db_replication_lagtime]: &lt;H1&gt;db: replication lag time&lt;/H1&gt;
Options[db_replication_lagtime]: gauge,nopercent,growright
</programlisting>


<para> De son coté, Ismail Yenigul propose une méthode pour surveiller
  &slony1; en utilisant <application>MRTG</application> sans installer 
<application>SNMPD</application>.</para>

<para>Voici sa configuration MRTG :</para>

<programlisting>
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]: &lt;H1&gt;db: replication lag time&lt;/H1&gt;
Options[db_replication_lagtime]: gauge,nopercent,growright
</programlisting>

<para> et voici sa version modifiée du script :</para>

<programlisting>
# 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#
</programlisting>


<note><para> MRTG attend quatre lignes en provenance du script. Puisque le script n'en fournit
    que deux, la sortie doit être prolongée de deux lignes.
 </para> </note>

</sect2>

<sect2 id="testslonystate"> <title> test_slony_state</title>

<indexterm><primary>script test_slony_state pour tester l'état de la réplication</primary></indexterm>

<para> Ce script effectue différents analyses sur l'état d'un cluster 
&slony1;.</para>

<para>Vous devez spécifier les arguments tels que <option>la base de données</option>,
<option>l'hÃŽte</option>, <option>l'utilisateur</option>,
<option>le cluster</option>, <option>le mot de passe</option>, et 
<option>le port</option> afin de se connecter à n'importe quel
noeud du cluster. Vous devez également préciser une commande 
 <option>mailprog</option> ( qui doit être un commande équivalente 
à la commande <productname>Unix</productname>
<application>mailx</application>) et une destination pour le courrier. </para>

<para> Par ailleurs vous spécifier les paramÚtres de connexion aux bases de données
  via les variables d'environnement utilisées par 
<application>libpq</application>, <emphasis>par exemple :</emphasis> - utiliser
<envar>PGPORT</envar>, <envar>PGDATABASE</envar>,
<envar>PGUSER</envar>, <envar>PGSERVICE</envar>, et ainsi de suite.</para>

<para>Le script se promÚne à travers <xref linkend="table.sl-path"/>
pour trouver tous les noeuds du cluster, et dans les DSNs qui lui 
permettront de se connecter à chaque noeud.</para>

<para> Pour chaque noeud, le script examine l'état des données suivantes :

<itemizedlist>
<listitem><para> Vérification de <xref linkend="table.sl-listen"/> 
    à la recherche de problÚmes
<quote>déterminés analytiquement</quote>. Cela liste les voies de communication
qui ne sont pas couvertes.</para></listitem>

<listitem><para> Effectuer un résumé des événements sur le noeud d'origine</para>

<para> Si un noeud n'a pas soumis un événement depuis longtemps, il y a certainement
  un problÚme.</para></listitem>

<listitem><para> Vérification de <quote>l'âge</quote> de la table <xref
linkend="table.sl-confirm"/> </para>

<para> Si un ou plusieurs noeuds du cluster n'ont pas envoyé de rapport récemment
  alors cela peut conduire à l'absence de nettoyage dans certaines tables comme 
  <xref linkend="table.sl-log-1"/> et <xref linkend="table.sl-seqlog"/></para></listitem>

<listitem><para> Vérifications des transactions longues</para>

<para> Ceci ne fonctionne correctement que si le collecteur de statistique 
  est configuré pour collecter les requêtes, c'est à dire l'option   
 <option> stats_command_string = true</option> est présente dans <filename>
postgresql.conf </filename>.</para>

<para> Si des bugs applicatifs conservent des connexions ouvertes, ce script devrait les trouver
.</para>

<para> Si des bugs applicatifs conservent des connexions ouvertes, 
  plusieurs effets négatifs sont à prévoir  
  tels que <link
linkend="longtxnsareevil">ceux décrits dans la FAQ 
</link>.</para></listitem>

</itemizedlist></para>

<para> Ce script fait des diagnostiques basé sur des paramÚtres défini dans le script
  ; si vous n'aimez pas les valeurs par défaut, modifiez-les !</para>

</sect2>

<sect2 id="search-logs"> <title> <command>search-logs.sh</command> </title>

<indexterm><primary> Chercher les logs  &slony1; avec search-logs.sh </primary></indexterm>

<para> Ce script est construit pour chercher les fichiers de trace &slony1;
  dans un emplacement donné (<envar>LOGHOME</envar>), en se basant à la fois
  sur les conventions de nommage utilisées par les systÚmes 
  <xref linkend="launchclusters"/> et <xref linkend="slonwatchdog"/> lors du démarrage 
  des processus &lslon;.</para>

<para> Si des erreurs sont trouvées, elles sont listées pour chaque fichiers 
  et transmises par courriel à un utilisateur spécifié  (<envar>LOGRECIPIENT</envar>);
  si aucune adresse courriel n'est spécifiée, le résultat est affiché sur la sortie standard
  . </para>

<para> <envar>LOGTIMESTAMP</envar> permet de surcharger quelle heure doit être évaluée
  (plutÎt que la derniÚre heure). </para>

<para> Un administrateur peut exécuter ce script une fois par heure 
  pour surveiller les problÚmes de réplication. 
</para>
</sect2>

<sect2 id="wikigen"> <title>Produire un rapport de surveillance au format MediaWiki</title>

<indexterm><primary> générer la documentation Wiki d'un cluster </primary></indexterm>

<para>Le script <filename>mkmediawiki.pl </filename>, situé dans 
  <filename>tools</filename>, peut être utilisé pour générer un rapport de
  surveillance du cluster compatible avec le logiciel populaire 
  <ulink url="http://www.mediawiki.org/">MediaWiki </ulink>.
  Notons que l'option <option>--categories</option> 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 une série de clusters &slony1;
  passer l'option <option>--categories=slony1</option> entraînera la création
  d'une page catégorie répertoriant l'ensemble des clusters &slony1;. </para>

<para>On pourra utiliser le commande ainsi: </para>

<screen>
~/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
</screen>

<para> Notons que <command>mvs</command> est un client Mediawiki écrit en Perl;
sur <ulink url="http://www.debian.org/"> Debian GNU/Linux</ulink>, le paquet
associé est nommé
<application>libwww-mediawiki-client-perl</application>; d'autres systÚmes
dispose probablement d'une version packagée sous un nom similaire. </para>

</sect2>
</sect1>