Supplément à l'article « Nouvelle gestion des journaux applicatifs sous PostgreSQL 8.3 »

L'article « Nouvelle gestion des journaux applicatifs sous PostgreSQL 8.3 », écrit par Guillaume Lelarge, a été publié dans le magazine GNU/Linux Magazine France, numéro 105 (Mai 2008). Il est disponible sur dalibo.org, sous licence Creative Commons. Malheureusement, un dernier ajout n'est pas arrivé à temps avant publication dans le magazine, donc le voici ici.


Une utilisation intéressante de la journalisation applicative

Un outil d'analyse des journaux applicatifs est apparu assez récemment. Il permet de trouver rapidement les requêtes les plus lentes ainsi que celles qui sont le plus fréquemment exécutées. C'est donc un outil essentiel à tout administrateur de bases de données. Cet outil nommé pgFouine, actuellement en version 1.0, est développé en PHP par Guillaume Smet. Le projet est disponible sur le site pgFoundry.

pgFouine lit un journal applicatif et récupère à partir de ce dernier la liste des requêtes exécutés ainsi que leur durée d'exécution. Un système d'analyse et de tri permet de récupérer et trier les requêtes pour réaliser un ou plusieurs rapports qui seront visualisables sur une page HTML.

Cela nécessite donc un paramétrage particulier de PostgreSQL. Il faut tracer toutes les requêtes et leur durée d'exécution. Le plus simple pour cela est d'initialiser log_min_duration_statement à 0. Assurez-vous que log_duration et log_statement sont tous les deux à false, pour ne pas tracer deux fois la même requête et sa durée. Préférez l'utilisation de syslog pour log_destination. Cela étant dit, vous pouvez passer par stderr mais le script ne pourra pas garantir la cohérence des requêtes SQL dans le cas où elles sont saisies sur plusieurs lignes. De plus, toujours dans le cas de l'utilisation de stderr, il vous faudra ajouter ou modifier le paramètre log_line_prefix pour que ce dernier indique précisément le format d'enregistrement de chaque ligne. Voici le format en question : '%t [%p]: [%l-1] ' ce qui correspond à l'horodatage, suivi du PID du processus et enfin du numéro de ligne de la session (pour les requêtes sur plusieurs lignes). Encore une fois, ne surtout pas oublier l'espace en fin du préfixe.

Attention : Tracer toutes les requêtes et leur durée d'exécution a un coût en terme de performances. Il est donc conseillé de mettre ce système en place un certain temps, puis de le désactiver. Ceci se fait sans avoir besoin de redémarrer PostgreSQL. Il suffit d'indiquer au système de recharger sa configuration (soit avec le script de démarrage, soit avec l'outil pg_ctl).

Une fois le journal applicatif récupéré, il peut être fourni immédiatement à pgFouine. La commande de base est très simple :

pgfouine.php -file /chemin/vers/le/journal_applicatif.log > votre_rapport.html

Le fichier récupéré est un fichier HTML décomposable en plusieurs parties : un en-tête permettant un accès rapide à chaque rapport généré, ainsi que des informations générales sur le journal applicatif (date et heure de génération, journal analysé, nombre de lignes, date de début et de fin du journal, etc.)

  • des statistiques générales (nombre de requêtes traitées, durée d'exécution totale, date/heure de la première et de la dernière requête, pique des requêtes)

  • rapport donnant le nombre de requêtes par type

  • rapport sur les requêtes les les plus lentes

  • rapport sur les requêtes les plus consommatrices

  • et plusieurs autres rapports

.

La ligne de commande montrée ci-dessus correspond à la façon la plus simple pour exécuter cet outil mais un grand nombre d'options sont possibles :

  • -onlyselect pour ne prendre en compte que les ordres SQL SELECT,
  • -reports pour sélectionner précisément les rapports souhaités,
  • -examples pour indiquer le nombre d'exemples à afficher,
  • -format pour préciser le format du rapport en sortie (texte, HTML ou HTML avec des graphes).
Afficher le texte source