Proposal: More structured logging

Поиск
Список
Период
Сортировка
От Ronan Dunklau
Тема Proposal: More structured logging
Дата
Msg-id 3207907.AWbSqkKDnR@aivenronan
обсуждение исходный текст
Ответы Re: Proposal: More structured logging  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Re: Proposal: More structured logging  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Re: Proposal: More structured logging  (Greg Stark <stark@mit.edu>)
Список pgsql-hackers
Hello,

The logging system already captures a lot of information in the ErrorData. But 
at present there is no way for a log message authors to include more metadata 
about the log outside of the log message itself. For example, including the 
extension name which can be useful for filtering / dispatching log messages.
This can be done in the log message itself, but that requires specialized 
parsing in the log output. 

Even though among the available loggers in core, only the csv logger would be 
able to make sense of it, I feel it would be beneficial to add a tagging system 
to logs, by adding different (tag, value) combinations to a log entry, with an 
API similar to what we do for other ErrorData fields:

ereport(NOTICE,
 (errmsg("My log message")),
 (errtag("EMITTER", "MYEXTENSION")),
 (errtag("MSG-ID", "%d", error_message_id))
);

Please find attached a very small POC patch to better demonstrate what I 
propose.  

Third party logging hooks could then exploit those values to output them 
correctly. For example the json loggger written by Michael Paquier here: 
https://github.com/michaelpq/pg_plugins/tree/master/jsonlog, or  the 
seeminlgy-abandonned journald hook here: https://github.com/intgr/pg_journal 
could add those information in a structured way.

I think the pgaudit extension (or something similar) could also make good use 
of such a feature instead of dumping a CSV entry in the log file. 

As for Postgres own log messages, I'm sure we could find practical use cases 
for tagging messages like this.

On a related note, the only structured logger we have in-core is the CSV 
logger. Many users nowadays end up feeding the logs to journald either by 
capturing the stderr output with systemd, or by having syslog implemented by 
journald itself. Would there be any interest in having native journald support 
as a logging_destination ?

Best regards,

-- 
Ronan Dunklau
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: CI/windows docker vs "am a service" autodetection on windows
Следующее
От: "David G. Johnston"
Дата:
Сообщение: Re: Default to TIMESTAMP WITH TIME ZONE?