Vous n'êtes pas identifié(e).
Pages : 1
Bonjour la communauté !
J'ai installé pgbadger sur une VM debian 8.
Les rapports de pgbadger sont vides bien que les fichiers de logs loguent bien.
Pour rappel, j'ai configuré le postgresql.conf comme suit:
log_min_duration_statement = 0
log_checkpoints = on
log_connections = on
log_disconnections = on
log_lock_waits = on
log_temp_files = 0
log_autovacuum_min_duration = 0
log_error_verbosity = default
lc_messages= 'C'
lc_monetary = 'C'
lc_numeric = 'C'
lc_time = 'C'
Merci d'avance à tous !!
Hors ligne
Pourrait-on avoir quelques lignes du fichier de log ? La seule devinette possible pour l'instant est que le log_line_prefix est incompatible avec pgbadger... Du coup, un extrait du log, la valeur du log_line_prefix et du log_destination seraient un plus.
Guillaume.
Hors ligne
Bonjour,
Je me permet de relancer le sujet car j'ai presque le même problème: (le rapport est vide).
Particularité:
log_destination='syslog'
J'ai essayé pas mal de combines dans 'log_line_prefix', ça n'a pas fonctionné. Mon problème c'est que dans le log j'ai un champ que pgbadger n'arrive pas à l'interpréter
Exemple:
[10-1] 2021-11-05 16:01:07 CET;2045;;;00000;LOG: automatic analyze of table "alisa_db.alisa.act_ru_job" system usage: CPU 0.00s/0.00u sec elapsed 0.00 sec
[11-1] 2021-11-05 16:01:07 CET;2045;;;00000;LOG: automatic vacuum of table "alisa_db.alisa.act_ge_property": index scans: 0
[12-1] 2021-11-05 16:01:07 CET;2045;;;00000;LOG: automatic analyze of table "alisa_db.alisa.act_ge_property" system usage: CPU 0.00s/0.00u sec elapsed 0.00 sec
[13-1] 2021-11-05 16:01:08 CET;2045;;;00000;LOG: automatic vacuum of table "alisa_db.alisa.act_ru_variable": index scans: 1
[14-1] 2021-11-05 16:01:08 CET;2045;;;00000;LOG: automatic analyze of table "alisa_db.alisa.act_ru_variable" system usage: CPU 0.00s/0.07u sec elapsed 0.16 sec
[15-1] 2021-11-05 16:01:08 CET;2045;;;00000;LOG: automatic vacuum of table "alisa_db.alisa.qrtz_fired_triggers": index scans: 1
[16-1] 2021-11-05 16:01:08 CET;2045;;;00000;LOG: automatic analyze of table "alisa_db.alisa.qrtz_fired_triggers" system usage: CPU 0.00s/0.00u sec elapsed 0.02 sec
[17-1] 2021-11-05 16:01:08 CET;2045;;;00000;LOG: automatic vacuum of table "alisa_db.alisa.qrtz_triggers": index scans: 1
[18-1] 2021-11-05 16:01:08 CET;2045;;;00000;LOG: automatic analyze of table "alisa_db.alisa.qrtz_triggers" system usage: CPU 0.00s/0.00u sec elapsed 0.02 sec
[89-1] 2021-11-05 16:01:37 CET;31237;postgres;alisa_db;00000;LOG: duration: 19583.248 ms statement: select count(*) from f_parameter;
==> J'ai l'impression que le champ entre crochets au début de chaque ligne plante le traitement pgbadger et sort le rapport à 0 pourtant dans les logs pas mal de requ^tes de tout type (SELECT, INSERT, UPDATE...etc.
Quelqu'un à une idée.
Par avance merci.
Hors ligne
Vous pouvez préciser un log_line_prefix à l'appel de pgbadger, est-ce que c'est ça que vous avez utilisé ? Si oui je ne vois pas pourquoi cela ne fonctionnerait pas, à partir du moment où vous spécifiez bien une valeur en accord avec votre format de log.
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour rjuju,
Merci pour ta réponse.
Voici la valeur du "log_line_prefix" ('%t;%p;%u;%d;%e;')
voici la commande lancé:
pgbadger -f syslog -p '%t;%p;%u;%d;%e;' -o /tmp/`uname -n`-$PG_SERVERNAME-`date +%Y%m%d-%H%M%S`-PgBadger.out.html /pgqdata/$PG_SERVERNAME/data/pg_log/pgxxxx.log
Par avance merci
Hors ligne
Je pense que votre identifiant de ligne dans la session (%l) n'est pas standard pour un syslog. Aves-vous essayé de le rajouter manuellement dans le log_line_prefix avec le format tel qu'il est dans votre log et en supprimant l'option -f syslog?
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour rjuju,
J'ai bien rajouté '%l' au paramètre log_lin_prefix comme ceci '%l;%t;%p;%u;%d;%e;'. j'ai fais les tests après, ça ne change pas même pire la colonne au début '[1-xxx]' existe toujours. Je pense que c'est cette colonne qui plombe la lecture des logs par pgbadger.
Par avance merci
Hors ligne
Re,
Au fait je ne comprend pas pourquoi la colonne [xxx-1] est dans les logs alors que dans mon log_line_prefix, il n'y a pas '%l', j'aimerai bien savoir d'où ça peut venir?!
[89-1] 2021-11-05 16:01:37 CET;31237;postgres;alisa_db;00000;LOG: duration: 19583.248 ms statement: select count(*) from f_parameter;
Hors ligne
Vous avez ajouté "%l" alors que vos logs contiennent une information telle que "[89-1]". Il faut respecter le format généré, soit [%l-1].
Cette information supplémentaire est générée par votre serveur syslog.
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour,
Merci pour la réponse.
En effet j'ai testé cela et voici ce que ça donne comme format de log:
#alter system set log_line_prefix TO '[%l-1]%t;%p;%u;%d;%e;';
#seletct pg_reload_conf();
[740-1] [801-1]2021-11-09 17:21:43 CET;31687;alisa;alisa_db;00000;LOG: duration: 0.162 ms parse <unnamed>: update ACT_RU_VARIABLE
==> ça me rajoute une autre colonne [xxx-xx].
En revanche si je modifie les paramètres :
alter system set syslog_split_messages TO 'off';
alter system set syslog_sequence_numbers TO 'off';
select pg_reload_conf();
Voici ce que ça donne:
2021-11-09 16:49:13 CET;17946;;;00000;LOG: automatic analyze of table "alisa_db.alisa.act_ru_variable" system usage: CPU 0.00s/0.06u sec elapsed 0.09 sec
Donc je retrouve le format (habituelle) du log PostgreSQL mais je ne sais pas encore pour le rapport PgBadger. (pas fait le test encore).
Est ce que c'est une bonne piste?
Bien cordialement
Hors ligne
Ah, je vois qu'il y a un malentendu. Comme indiqué dans mon premier message je voulais parler du log_line_prefix utilisé lors de l'appel à pgbadger. Vous ne devez pas modifier la configuration de postgres mais utiliser le prefix correct avec pgbadger. Vous devriez donc rétablir votre ancien log_line_prefix dans postgres.
Julien.
https://rjuju.github.io/
Hors ligne
Re,
Au fait je ne comprend pas pourquoi la colonne [xxx-1] est dans les logs alors que dans mon log_line_prefix, il n'y a pas '%l', j'aimerai bien savoir d'où ça peut venir?!
[89-1] 2021-11-05 16:01:37 CET;31237;postgres;alisa_db;00000;LOG: duration: 19583.248 ms statement: select count(*) from f_parameter;
La présence de cette séquence est normale si syslog_sequence_numbers est à ON (sa valeur par défaut) mais ce qui n'est pas normal, c'est sa position en début de ligne. Par exemple mettons qu'on ait
log_line_prefix à %t;%p;%u;%d;%e comme mentionné plus haut et log_destination à syslog, voilà le genre de ligne que j'obtiens sur Ubuntu avec rsyslog par défaut:
Nov 10 14:26:16 cyan postgres[22656]: [9-1] 2021-11-10 14:26:16 CET;22656;daniel;daniel;00000LOG: statement: select 'test';Le début de la ligne est émis par syslog. La partie émise par postgres et qui correspond à log_line_prefix commence avec le 2021.
Si on compare à l'exemple de sortie du message #3, vous n'avez pas la partie émise par syslog. Autrement dit on dirait que c'est un log émis avec log_destination=stderr, ou bien le syslog n'a pas ajouté automatiquement son entête pour une raison inconnue.
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
La manière dont fonctionne syslog pour la partie qui peut intéresser cette discussion est décrite ici:
https://datatracker.ietf.org/doc/html/r … ection-4.2
L'émetteur peut ajouter ou non le HEADER et en fonction de ça, syslog l'ajoute ou pas. Il est possible qu'il y ait une configuration ou un relai qui provoque une mauvaise interprétation faisant qu'au final le HEADER ne figure pas dans le fichier résultant, et que pgbadger ne ne soit pas capable de l'interpréter.
En dehors de régler le problème à la source, il suffirait de dire à pgbadger que ce n'est pas un fichier syslog, et il ne chercherait pas le header qui n'est pas là.
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Pages : 1