pgbadgerp - En ligne dans le Cloud

PROGRAMME:

Nom

pgBadger - un rapport d'analyse de journal PostgreSQL rapide

SYNOPSIS

Utilisation : pgbadger [options] fichier journal [...]

Analyseur de journaux PostgreSQL avec des rapports et des graphiques entièrement détaillés.

Arguments:

logfile peut être un seul fichier journal, une liste de fichiers ou une commande shell
retour d'une liste de fichiers. Si vous souhaitez transmettre le contenu du journal de stdin
utiliser - comme nom de fichier. Notez que l'entrée de stdin ne fonctionnera pas avec csvlog.
Vous pouvez également utiliser un fichier contenant une liste de fichiers journaux à analyser, voir -L
commande option de ligne.

Options :

-a | --average minutes : nombre de minutes pour construire les graphiques moyens de
requêtes et connexions. Par défaut 5 minutes.
-A | --histo-avg minutes : nombre de minutes pour construire les graphiques d'histogramme
de requêtes. 60 minutes par défaut.
-b | --begin datetime : date/heure de début des données à analyser dans le journal.
-B | --bar-graph : utilise le graphique à barres au lieu de la ligne par défaut.
-c | --dbclient host : ne rapporte que les entrées pour l'hôte client donné.
-C | --nocomment : supprime les commentaires comme /* ... */ des requêtes.
-d | --dbname database : ne rapporte que les entrées de la base de données donnée.
-D | --dns-resolv : les adresses IP des clients sont remplacées par leur nom DNS.
Soyez averti que cela peut vraiment ralentir pgBadger.
-e | --end datetime : date/heure de fin pour les données à analyser dans le journal.
-f | --format logtype : valeurs possibles : syslog, syslog2, stderr et csv.
Par défaut : stderr.
-G | --nograph : désactive les graphiques sur la sortie HTML. Activé par défaut.
-h | --help : affiche ce message et quitte.
-i | --ident name : nom du programme utilisé comme identifiant syslog. Par défaut : postgres
-I | --incremental : utilise le mode incrémental, les rapports seront générés par
jours dans un répertoire séparé, --outdir doit être défini.
-j | --jobs number : nombre de jobs à exécuter en même temps. La valeur par défaut est 1,
exécuté en tant que processus unique.
-J | --Numéro de travaux : nombre de fichier journal à analyser en parallèle. Défaut
est 1, exécuté en tant que processus unique.
-l | --last-parsed file : autorise l'analyse incrémentielle du journal en enregistrant le
dernier datetime et ligne analysés. Utile si vous voulez
pour surveiller les erreurs depuis la dernière exécution ou si vous en voulez une
rapport par jour avec un journal tourné chaque semaine.
-L | logfile-list file : fichier contenant une liste de fichiers journaux à analyser.
-m | --maxlength size : longueur maximale d'une requête, elle sera limitée à
la taille donnée. Par défaut : pas de troncature
-M | --no-multiline : ne collecte pas l'instruction multiligne pour éviter les ordures
surtout sur les erreurs qui génèrent un énorme rapport.
-n | --nohighlight : désactive la mise en évidence du code SQL.
-N | --appname name : ne rapporte que les entrées pour le nom d'application donné
-o | --outfile filename : définit le nom de fichier pour la sortie. La valeur par défaut dépend
sur le format de sortie : out.html, out.txt, out.bin,
out.json ou out.tsung.
Avec le module JSON::XS installé, vous pouvez sortir le fichier
au format JSON non plus.
Pour vider la sortie sur stdout, utilisez - comme nom de fichier.
-O | --outdir path : répertoire où le fichier out doit être enregistré.
-p | --prefix string : la valeur de votre log_line_prefix personnalisé comme
défini dans votre postgresql.conf. Ne l'utilisez que si vous
n'utilisent pas l'un des préfixes standard spécifiés
dans la documentation de pgBadger, comme si votre
le préfixe inclut des variables supplémentaires comme l'adresse IP du client
ou le nom de l'application. Voir exemples ci-dessous.
-P | --no-prettify : désactiver les requêtes SQL prettify formateur.
-q | --quiet : n'affiche rien sur stdout, même pas une progression
bar.
-r | --remote-host ip : définit l'hôte sur lequel exécuter la commande cat
fichier journal distant pour analyser localement le fichier.
-R | --retention N : nombre de semaine à conserver en mode incrémental. Défaut
à 0, désactivé. Utilisé pour régler le nombre de weel à
conserver dans le répertoire de sortie. Semaines et jours plus anciens
répertoire sont automatiquement supprimés.
-s | --sample number : nombre d'échantillons de requête à stocker. Par défaut : 3.
-S | --select-only : ne rapporte que les requêtes SELECT.
-t | --top number : nombre de requêtes à stocker/afficher. Par défaut : 20.
-T | --title string : modifie le titre du rapport de la page HTML.
-u | --dbuser username : ne rapporte que les entrées pour l'utilisateur donné.
-U | --exclude-user username : exclure les entrées pour l'utilisateur spécifié de
signaler.
-v | --verbose : active le mode verbeux ou debug. Désactivé par défaut.
-V | --version : affiche la version de pgBadger et quitte.
-w | --watch-mode : ne rapporte que les erreurs comme pourrait le faire logwatch.
-x | --extension : format de sortie. Valeurs : text, html, bin, json ou
tsung. Par défaut : html
-X | --extra-files : en mode incremetal, permet à pgbadger d'écrire du CSS et
JS dans le répertoire de sortie en tant que fichiers séparés.
-z | --zcat exec_path : définit le chemin complet vers le programme zcat. Utilisez-le si
zcat ou bzcat ou unzip n'est pas sur votre chemin.
--pie-limit num : les données circulaires inférieures à num% afficheront une somme à la place.
--exclude-query regex : toute requête correspondant à la regex donnée sera exclue
du rapport. Par exemple : "^(VIDE|COMMIT)"
Vous pouvez utiliser cette option plusieurs fois.
--exclude-file filename : chemin du fichier qui contient toutes les regex vers
utiliser pour exclure des requêtes du rapport. Une expression régulière
par ligne.
--include-query regex : toute requête qui ne correspond pas à la regex donnée sera
être exclu du rapport. Vous pouvez utiliser ceci
option plusieurs fois. Par exemple : "(tbl1|tbl2)".
--include-file filename : chemin du fichier qui contient toutes les regex de
les requêtes à inclure dans le rapport. Une expression régulière
par ligne.
--disable-error : ne génère pas de rapport d'erreur.
--disable-hourly : ne génère pas de rapport horaire.
--disable-type : ne génère pas de rapport des requêtes par type, base de données
ou utilisateur.
--disable-query : ne génère pas de rapports de requête (le plus lent, le plus
fréquentes, requêtes par utilisateurs, par base de données, ...).
--disable-session : ne génère pas de rapport de session.
--disable-connection : ne génère pas de rapport de connexion.
--disable-lock : ne génère pas de rapport de verrouillage.
--disable-temporary : ne génère pas de rapport temporaire.
--disable-checkpoint : ne génère pas de rapport de point de contrôle/point de redémarrage.
--disable-autovacuum : ne génère pas de rapport d'autovacuum.
--charset : utilisé pour définir le jeu de caractères HTML à utiliser.
Par défaut : utf-8.
--csv-separator : utilisé pour définir le séparateur de champ CSV, par défaut : ,
--exclude-time regex : tout horodatage correspondant à l'expression régulière donnée sera
exclu du rapport. Exemple : "2013-04-12 .*"
Vous pouvez utiliser cette option plusieurs fois.
--exclude-appname name : exclure les entrées pour le nom d'application spécifié
du rapport. Exemple : "pg_dump".
--exclude-line regex : pgbadger commencera à exclure toute entrée de journal qui
correspondra à la regex donnée. Peut être utilisé plusieurs
le temps.
--anonymize : masque tous les littéraux dans les requêtes, utile pour masquer
données confidentielles.
--noreport : empêche pgbadger de créer des rapports en incrémentiel
.
--log-duration : force pgbadger à associer les entrées de journal générées
à la fois par log_duration = on et log_statement = 'all'
--enable-checksum : utilisé pour ajouter une somme md5 sous chaque rapport de requête.

pgBadger est capable d'analyser un fichier journal distant à l'aide d'une connexion ssh sans mot de passe. Utilisez le
-r ou --remote-host pour définir l'adresse IP ou le nom d'hôte de l'hôte. Il y a aussi quelques autres
options pour contrôler entièrement la connexion ssh.

--ssh-program chemin ssh vers le programme ssh à utiliser. Par défaut : ssh.
--ssh-user nom d'utilisateur nom de connexion de connexion. La valeur par défaut est l'utilisateur en cours d'exécution.
--ssh-identity chemin d'accès au fichier d'identité à utiliser.
--ssh-timeout deuxième délai d'attente pour l'échec de la connexion ssh. 10 secondes par défaut.
--ssh-options options liste des options -o à utiliser pour la connexion ssh.
Options toujours utilisées :
-o ConnectTimeout=$ssh_timeout
-o PreferredAuthentications=basé sur l'hôte,clé publique

Exemples :

pgbadger/var/log/postgresql.log
pgbadger /var/log/postgres.log.2.gz /var/log/postgres.log.1.gz
/var/log/postgres.log
pgbadger /var/log/postgresql/postgresql-2012-05-*
pgbadger --exclude-query="^(COPY|COMMIT)" /var/log/postgresql.log
pgbadger -b "2012-06-25 10:56:11" -e "2012-06-25 10:59:11"
/var/log/postgresql.log
chat /var/log/postgres.log | pgbadger -
# Préfixe de journal avec sortie de journal stderr
perl pgbadger --prefix '%t [%p]: [%l-1] user=%u,db=%d,app=%a,client=%h'
/pglog/postgresql-2012-08-21*
perl pgbadger --prefix '%m %u@%d %p %r %a : ' /pglog/postgresql.log
# Préfixe de ligne de journal avec sortie de journal syslog
perl pgbadger --prefix 'user=%u,db=%d,client=%h,app=%a'
/pglog/postgresql-2012-08-21*
# Utiliser mes 8 processeurs pour analyser mon fichier de 10 Go plus rapidement, beaucoup plus rapidement
perl pgbadger -j 8 /pglog/postgresql-9.1-main.log

Générez un fichier XML de sessions Tsung avec des requêtes sélectionnées uniquement :

perl pgbadger -S -o sessions.tsung --prefix '%t [%p]: [%l-1] user=%u,db=%d ' /pglog/postgresql-9.1.log

Signaler des erreurs chaque semaine par tâche cron :

30 23 * * 1 /usr/bin/pgbadger -q -w /var/log/postgresql.log -o /var/reports/pg_errors.html

Générez un rapport chaque semaine en utilisant un comportement incrémentiel :

0 4 * * 1 /usr/bin/pgbadger -q `trouver / var / log / -mtime -7 -name "postgresql.log*"`
-o /var/reports/pg_errors-`date +%F`.html -l /var/reports/pgbadger_incremental_file.dat

Cela suppose que votre fichier journal et votre rapport HTML changent également chaque semaine.

Ou mieux, utilisez les rapports incrémentiels générés automatiquement :

0 4 * * * /usr/bin/pgbadger -I -q /var/log/postgresql/postgresql.log.1
-O /var/www/pg_reports/

générera un rapport par jour et par semaine.

En mode incrémental, vous pouvez également spécifier le nombre de semaine à conserver dans les rapports :

/usr/bin/pgbadger --retention 2 -I -q /var/log/postgresql/postgresql.log.1
-O /var/www/pg_reports/

Si vous avez un pg_dump à 23h00 et 13h00 chaque jour pendant une demi-heure, vous pouvez utiliser
pgbadger comme suit pour exclure ces périodes du rapport :

pgbadger --exclude-time "2013-09-.* (23|13):.*" postgresql.log

Cela aidera à éviter d'avoir des instructions COPY, telles que générées par pg_dump, en haut de la liste
des requêtes les plus lentes. Vous pouvez également utiliser --exclude-appname "pg_dump" pour résoudre ce problème dans
une manière plus simple.

DESCRIPTION

pgBadger est un analyseur de journaux PostgreSQL conçu pour la vitesse avec des rapports entièrement détaillés de
votre fichier journal PostgreSQL. C'est un seul et petit script Perl qui surpasse tout autre
Analyseur de journaux PostgreSQL.

Il est écrit en langage Perl pur et utilise une bibliothèque javascript (flotr2) pour dessiner des graphiques
de sorte que vous n'avez pas besoin d'installer de modules Perl supplémentaires ou d'autres packages.
De plus, cette bibliothèque nous offre plus de fonctionnalités telles que le zoom. pgBadger utilise également le
La bibliothèque javascript Bootstrap et la police Web FontAwesome pour une meilleure conception. Tout est
embarqué.

pgBadger est capable de détecter automatiquement le format de votre fichier journal (syslog, stderr ou csvlog). Il est
conçu pour analyser d'énormes fichiers journaux ainsi que des fichiers compressés gzip. Voir la liste complète des
caractéristiques ci-dessous. Les formats compressés pris en charge sont gzip, bzip2 et xz. Pour le dernier tu
doit avoir une version xz supérieure à 5.05 qui prend en charge l'option --robot.

Tous les graphiques sont zoomables et peuvent être enregistrés sous forme d'images PNG.

Vous pouvez également limiter pgBadger pour signaler uniquement les erreurs ou supprimer une partie du rapport en utilisant
options de ligne de commande.

pgBadger prend en charge tout format personnalisé défini dans la directive log_line_prefix de votre
postgresql.conf tant qu'il spécifie au moins les modèles %t et %p.

pgBadger permet un traitement parallèle sur un seul fichier journal et plusieurs fichiers grâce à l'utilisation
de l'option -j et le nombre de CPU comme valeur.

Si vous souhaitez économiser les performances du système, vous pouvez également utiliser log_duration au lieu de
log_min_duration_statement pour avoir des rapports sur la durée et le nombre de requêtes uniquement.

CARACTÉRISTIQUES

pgBadger rapporte tout sur vos requêtes SQL :

Statistiques globales
Les requêtes en attente les plus fréquentes.
Les requêtes qui attendaient le plus.
Requêtes générant le plus de fichiers temporaires.
Requêtes générant les fichiers temporaires les plus volumineux.
Les requêtes les plus lentes.
Requêtes qui ont pris le plus de temps.
Les requêtes les plus fréquentes.
Les erreurs les plus fréquentes.
Histogramme des temps de requête.
Histogramme des heures des séances.
Utilisateurs impliqués dans les requêtes les plus fréquentes.
Applications impliquées dans les requêtes les plus fréquentes.
Requêtes générant le plus d'annulations.
Requêtes les plus annulées.

Les rapports suivants sont également disponibles avec des graphiques horaires divisés par périodes de cinq
minutes:

Statistiques des requêtes SQL.
Statistiques des fichiers temporaires.
Statistiques des points de contrôle.
Autovacuum et autoanalyse des statistiques.
Requêtes annulées.
Événements d'erreur (panique, fatal, erreur et avertissement).

Il existe également des rapports de distribution sur :

Verrouille les statistiques.
Requêtes par type (sélection/insertion/mise à jour/suppression).
Répartition des types de requêtes par base de données/application
Sessions par base de données/utilisateur/client/application.
Connexions par base de données/utilisateur/client/application.
Vide automatique et analyse automatique par table.
Requêtes par utilisateur et durée totale par utilisateur.

Tous les graphiques sont zoomables et peuvent être enregistrés sous forme d'images PNG. Les requêtes SQL signalées sont
mis en valeur et embelli automatiquement.

Vous pouvez également avoir des rapports incrémentiels avec un rapport par jour et un rapport cumulé par
la semaine. Deux modes multiprocessus sont disponibles pour accélérer l'analyse des journaux, un utilisant un cœur par
log, et le second pour utiliser plusieurs cœurs pour analyser un seul fichier. Les deux modes peuvent être
combiné.

La granularité de l'histogramme peut être ajustée à l'aide de l'option de ligne de commande -A. Par défaut, ils
rapportera la moyenne de chaque requête/erreur principale se produisant par heure, mais vous pouvez spécifier le
granularité à la minute près.

pgBadger peut également être utilisé dans un emplacement central pour analyser les fichiers journaux distants à l'aide d'un mot de passe
moins de connexion SSH. Ce mode peut être utilisé avec des fichiers compressés et en mode multiprocessus
par fichier (-J) mais ne peut pas être utilisé avec le format de journal CSV.

EXIGENCE

pgBadger se présente sous la forme d'un seul script Perl - vous n'avez besoin de rien d'autre qu'un Perl moderne
Distribution. Les graphiques sont rendus à l'aide d'une bibliothèque Javascript, vous n'avez donc besoin de rien.
Votre navigateur fera tout le travail.

Si vous envisagez d'analyser les fichiers journaux PostgreSQL CSV, vous aurez peut-être besoin de modules Perl :

Text::CSV_XS - pour analyser les fichiers journaux CSV PostgreSQL.

Ce module est facultatif, si vous n'avez pas de log PostgreSQL au format CSV, vous n'en avez pas besoin
pour l'installer.

Si vous souhaitez exporter des statistiques sous forme de fichier JSON, vous avez besoin d'un module Perl supplémentaire :

JSON::XS - Sérialisation/désérialisation JSON, effectuée correctement et rapidement

Ce module est facultatif, si vous ne sélectionnez pas le format de sortie json, vous n'avez pas besoin de
Installez-le.

Le format de fichier journal compressé est détecté automatiquement à partir de l'extension du fichier. Si pgBadger trouve un gz
extension, il utilisera l'utilitaire zcat, avec une extension bz2, il utilisera bzcat et si le
l'extension du fichier est zip ou xz, les utilitaires unzip ou xz seront utilisés.

Si ces utilitaires ne sont pas trouvés dans la variable d'environnement PATH, utilisez --zcat
option de ligne de commande pour modifier ce chemin. Par exemple:

--zcat="/usr/local/bin/gunzip -c" ou --zcat="/usr/local/bin/bzip2 -dc"
--zcat="C:\tools\unzip -p"

Par défaut pgBadger utilisera les utilitaires zcat, bzcat et unzip suivant le fichier
extension. Si vous utilisez le format de compression de détection automatique par défaut, vous pouvez mélanger gz, bz2, xz
ou des fichiers zip. La spécification d'une valeur personnalisée à l'option --zcat supprimera cette fonctionnalité de mixte
format compressé.

Notez que le multitraitement ne peut pas être utilisé avec des fichiers compressés ou des fichiers CSV ainsi que
sous plate-forme Windows.

INSTALLATION

Téléchargez l'archive depuis github et décompressez l'archive comme suit :

tar xzf pgbadger-7.x.tar.gz
cd pgbadger-7.x/
perl Makefile.PL
faire && sudo faire installer

Cela copiera le script Perl pgbadger dans /usr/local/bin/pgbadger par défaut et le man
page dans /usr/local/share/man/man1/pgbadger.1. Ce sont l'installation par défaut
répertoires pour l'installation du 'site'.

Si vous voulez tout installer sous / usr / emplacement, utilisez INSTALLDIRS='perl' comme argument de
Makefile.PL. Le script sera installé dans /usr/bin/pgbadger et la page de manuel dans
/usr/share/man/man1/pgbadger.1.

Par exemple, pour tout installer comme le fait Debian, procédez comme suit :

perl Makefile.PL INSTALLDIRS=fournisseur

Par défaut, INSTALLDIRS est défini sur site.

PostgreSQL CONFIGURATION

Vous devez activer et définir certaines directives de configuration dans votre postgresql.conf avant
départ.

Vous devez d'abord activer la journalisation des requêtes SQL pour avoir quelque chose à analyser :

log_min_duration_statement = 0

Ici, chaque déclaration sera enregistrée, sur un serveur occupé, vous pouvez augmenter cette valeur à
enregistrer uniquement les requêtes avec une durée plus longue. Notez que si vous avez log_statement défini sur
'all' rien ne sera enregistré via la directive log_min_duration_statement. Voir suivant
chapitre pour plus d'informations.

Avec le format de journal 'stderr', log_line_prefix doit être au moins :

log_line_prefix = '%t [%p]: [%l-1] '

Le préfixe de la ligne de journal peut ajouter l'utilisateur, le nom de la base de données, le nom de l'application et l'adresse IP du client comme
suit:

log_line_prefix = '%t [%p]: [%l-1] user=%u,db=%d,app=%a,client=%h '

ou pour le format de fichier journal syslog :

log_line_prefix = 'user=%u,db=%d,app=%aclient=%h '

Le préfixe de ligne de journal pour la sortie stderr peut également être :

log_line_prefix = '%t [%p]: [%l-1] db=%d,user=%u,app=%a,client=%h '

ou pour la sortie syslog :

log_line_prefix = 'db=%d,user=%u,app=%a,client=%h '

Vous devez activer d'autres paramètres dans postgresql.conf pour obtenir plus d'informations de votre
fichiers journaux :

log_checkpoints = activé
log_connections = activé
log_disconnections = activé
log_lock_waits = activé
log_temp_files = 0
log_autovacuum_min_duration = 0

N'activez pas log_statement car leur format de journal ne sera pas analysé par pgBadger.

Bien sûr, vos messages de journal doivent être en anglais sans prise en charge des paramètres régionaux :

lc_messages='C'

mais ce n'est pas seulement recommandé par pgBadger.

Remarque : la ligne de session [%l-1] est juste utilisée pour correspondre au préfixe par défaut de "stderr". Les
-1 n'a aucun but réel et n'est fondamentalement pas utilisé dans les statistiques / graphiques de Pgbadger. Vous pouvez
supprimés en toute sécurité de log_line_prefix mais vous devrez définir la commande --prefix
option de ligne.

log_min_duration_statement, durée_journal et instruction_log

Si vous voulez des rapports de statistiques complets, vous devez définir log_min_duration_statement sur 0 ou plus
millisecondes.

Si vous souhaitez simplement signaler la durée et le nombre de requêtes et que vous ne voulez pas tous les détails sur
requêtes, définissez log_min_duration_statement sur -1 pour le désactiver et activer log_duration dans
votre fichier postgresql.conf. Si vous souhaitez ajouter le rapport de demande le plus courant, vous pouvez
choisissez de définir log_min_duration_statement sur une valeur plus élevée ou choisissez d'activer
instruction_log.

L'activation de log_min_duration_statement ajoutera des rapports sur les requêtes et les requêtes les plus lentes
qui a pris le plus de temps. Faites attention que si vous avez log_statement défini sur 'all' rien
sera enregistré avec log_line_prefix.

PARALLÈLE TRAITEMENT DES SEMENCES

Pour activer le traitement parallèle, il vous suffit d'utiliser l'option -j N où N est le nombre
de cœurs que vous souhaitez utiliser.

pgbadger procédera alors comme suit :

pour chaque fichier journal
taille du morceau = int (taille du fichier / N)
regardez les décalages de début/fin de ces morceaux
fork N processus et recherche le décalage de début de chaque morceau
chaque processus se terminera lorsque l'analyseur atteindra le décalage de fin
de son morceau
chaque processus écrit des statistiques dans un fichier temporaire binaire
attendre que tous les enfants soient terminés
Tous les fichiers temporaires binaires générés seront ensuite lus et chargés dans
mémoire pour construire la sortie html.

Avec cette méthode, au début/à la fin des morceaux, pgbadger peut tronquer ou omettre un maximum de N
requêtes fichier journal perl qui est une lacune insignifiante si vous avez des millions de requêtes dans
votre fichier journal. La probabilité que la requête que vous recherchiez soit lâche est proche de 0,
c'est pourquoi je pense que cet écart est vivable. La plupart du temps, la requête est comptée deux fois mais
tronqué.

Lorsque vous avez beaucoup de petits fichiers journaux et beaucoup de processeurs, il est plus rapide de consacrer un cœur
à un fichier journal à la fois. Pour activer ce comportement, vous devez utiliser l'option -JN à la place.
Avec 200 fichiers journaux de 10 Mo chacun, l'utilisation de l'option -J commence à être vraiment intéressante
avec 8 cœurs. En utilisant cette méthode, vous serez sûr de ne perdre aucune requête dans les rapports.

Il s'agit d'un benchmark réalisé sur un serveur avec 8 processeurs et un seul fichier de 9.5 Go.

Option | 1 processeur | 2 processeurs | 4 processeurs | 8 processeurs
--------+--------+-------+-------+------
-j | 1h41m18 | 50m25 | 25m39 | 15m58
-J | 1h41m18 | 54m28 | 41m16 | 34m45

Avec 200 fichiers journaux de 10 Mo chacun et un total de 2 Go, les résultats sont légèrement différents :

Option | 1 processeur | 2 processeurs | 4 processeurs | 8 processeurs
--------+-------+-------+-------+------
-j | 20m15 | 9m56 | 5m20 | 4m20
-J | 20m15 | 9m49 | 5m00 | 2m40

Il est donc recommandé d'utiliser -j à moins que vous n'ayez des centaines de petits fichiers journaux et que vous puissiez utiliser à
au moins 8 processeurs.

IMPORTANT : lorsque vous utilisez l'analyse parallèle, pgbadger générera beaucoup de messages temporaires
fichiers dans le / Tmp répertoire et les supprimera à la fin, alors ne supprimez pas ces fichiers
à moins que pgbadger ne soit pas en cours d'exécution. Ils sont tous nommés avec le modèle suivant
tmp_pgbadgerXXXX.bin afin qu'ils puissent être facilement identifiés.

INCRÉMENTIELLE RAPPORTS

pgBadger inclut un mode de rapport incrémentiel automatique en utilisant l'option -I ou --incremental.
Lors de l'exécution dans ce mode, pgBadger générera un rapport par jour et un cumulatif
rapport par semaine. La sortie se fait d'abord au format binaire dans le répertoire de sortie obligatoire
(voir option -O ou --outdir), puis au format HTML pour les rapports quotidiens et hebdomadaires avec un
fichier index.

Le fichier d'index principal affichera un menu déroulant par semaine avec un lien vers le rapport hebdomadaire et
des liens vers les rapports quotidiens de cette semaine.

Par exemple, si vous exécutez pgBadger comme suit sur la base d'un fichier pivoté quotidiennement :

0 4 * * * /usr/bin/pgbadger -I -q /var/log/postgresql/postgresql.log.1 \
-O /var/www/pg_reports/

vous aurez tous les rapports quotidiens et hebdomadaires pour toute la période de fonctionnement.

Dans ce mode, pgBagder créera un fichier incrémentiel automatique dans le répertoire de sortie,
vous n'avez donc pas besoin d'utiliser l'option -l à moins que vous ne vouliez changer le chemin de ce fichier.
Cela signifie que vous pouvez exécuter pgBadger dans ce mode tous les jours sur un fichier journal tourné chaque
semaine, il ne comptera pas deux fois les entrées de journal.

Pour économiser de l'espace disque, vous pouvez utiliser l'option de ligne de commande -X ou --extra-files pour
force pgBadger à écrire javascript et css dans des fichiers séparés dans le répertoire de sortie. Les
les ressources seront ensuite chargées à l'aide d'un script et d'une balise de lien.

BINARY Format

En utilisant le format binaire, il est possible de créer des incréments et des cumulatifs personnalisés
rapports. Par exemple, si vous souhaitez actualiser un rapport pgbadger toutes les heures à partir d'un journal
fichier journal PostgreSQl, vous pouvez procéder en exécutant toutes les heures les commandes suivantes :

pgbadger --last-parsed .pgbadger_last_state_file -o dimanche/hourX.bin /var/log/pgsql/postgresql-Sun.log

pour générer les fichiers de données incrémentales au format binaire. Et pour générer le nouveau HTML
rapport à partir de ce fichier binaire :

pgbadger dimanche/*.bin

Ou un autre exemple, si vous avez un fichier journal par heure et que vous voulez qu'un rapport soit
reconstruire à chaque changement de fichier journal. Procédez comme suit :

pgbadger -o jour1/heure01.bin /var/log/pgsql/pglog/postgresql-2012-03-23_10.log
pgbadger -o jour1/heure02.bin /var/log/pgsql/pglog/postgresql-2012-03-23_11.log
pgbadger -o jour1/heure03.bin /var/log/pgsql/pglog/postgresql-2012-03-23_12.log
...

Lorsque vous souhaitez actualiser le rapport HTML, par exemple chaque fois qu'un nouveau fichier binaire est
généré, procédez comme suit :

pgbadger -o day1_report.html day1/*.bin

Ajustez les commandes en fonction de vos besoins.

JSON Format

Le format JSON est idéal pour partager des données avec d'autres langues, ce qui facilite
intégrer le résultat de pgBadger dans d'autres outils de surveillance comme Cacti ou Graphite.

AUTEURS

pgBadger est une œuvre originale de Gilles Darold.

Le logo pgBadger est une création originale de Damien Clochard.

Le design de pgBadger v4.x vient de la société "Art is code".

Ce site internet est une œuvre de Gilles Darold.

pgBadger est maintenu par Gilles Darold, les braves gens de Dalibo, et tous ceux qui veulent
contribuer.

De nombreuses personnes ont contribué à pgBadger, elles sont toutes citées dans le fichier Changelog.

Utilisez pgbadgerp en ligne en utilisant les services onworks.net