PostgreSQL La base de donnees la plus sophistiquee au monde.

Forums PostgreSQL.fr

Le forum officiel de la communauté francophone de PostgreSQL

Vous n'êtes pas identifié(e).

#1 16/01/2020 02:12:14

null008
Membre

rapport pg_badger vide

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

#2 16/01/2020 09:56:14

gleu
Administrateur

Re : rapport pg_badger vide

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

#3 05/11/2021 17:58:24

lemjid
Membre

Re : rapport pg_badger vide

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

#4 06/11/2021 10:59:12

rjuju
Administrateur

Re : rapport pg_badger vide

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.

Hors ligne

#5 08/11/2021 11:01:16

lemjid
Membre

Re : rapport pg_badger vide

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

#6 08/11/2021 13:06:46

rjuju
Administrateur

Re : rapport pg_badger vide

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?

Hors ligne

#7 09/11/2021 15:45:33

lemjid
Membre

Re : rapport pg_badger vide

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

#8 09/11/2021 17:13:31

lemjid
Membre

Re : rapport pg_badger vide

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

#9 09/11/2021 17:52:22

rjuju
Administrateur

Re : rapport pg_badger vide

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.

Hors ligne

#10 09/11/2021 18:36:29

lemjid
Membre

Re : rapport pg_badger vide

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

#11 09/11/2021 19:14:07

rjuju
Administrateur

Re : rapport pg_badger vide

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.

Hors ligne

#12 10/11/2021 15:49:51

dverite
Membre

Re : rapport pg_badger vide

lemjid a écrit :

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.

Hors ligne

#13 10/11/2021 15:56:37

dverite
Membre

Re : rapport pg_badger vide

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à.

Hors ligne

Pied de page des forums