improving log management
Hi,
We support several methods for logging server messages. The "native" methods
(stderr, csvlogs) has poor management. We can't compress logs, send them to
another location/server, or just remove old ones. Another problem is that we
can't remove (automatically) old logs based on the number of existing log
files (of course we can do it using log_truncate_on_rotation and a
log_filename that matches the number of files -- but it *isn't* flexible). The
other log management softwares have a way to do that so why our logger doesn't
have such capability?
I want to propose a new command to be execute after the log file is rotated. A
GUC parameter log_after_rotation_command that takes a (set of) command(s) that
will be executed after a log file is rotated. It should be set only by
superuser. For example:
# compress and store the log file in another location
log_after_rotation_command = 'gzip %f && mv %p.gz /a/mylogs'
Depending on the comments, I will clean up the patch and send it later today.
--
Euler Taveira de Oliveira
http://www.timbira.com/
Euler Taveira de Oliveira <euler@timbira.com> writes:
I want to propose a new command to be execute after the log file is
rotated.
(1) Windows compatibility?
(2) What happens if the command takes a significant amount of time to
execute? We can't afford to have the log collector blocked.
(3) What do you intend those %p and %f symbols to signify?
regards, tom lane
Euler Taveira de Oliveira <euler@timbira.com> wrote:
other log management softwares have a way to do that so why our logger doesn't
have such capability?I want to propose a new command to be execute after the log file is rotated. A
GUC parameter log_after_rotation_command that takes a (set of) command(s) that
will be executed after a log file is rotated.
If you have better loggers already, why don't you use them? In another word,
should we cooperate with them instead of re-inventing alternative loggers?
We have "Logging Brainstorm" topic in out wiki. It might help you.
http://wiki.postgresql.org/wiki/Logging_Brainstorm
Regards,
---
Takahiro Itagaki
NTT Open Source Software Center
Tom Lane escreveu:
(1) Windows compatibility?
Yes.
(2) What happens if the command takes a significant amount of time to
execute? We can't afford to have the log collector blocked.
You're right. We can't have that command in the same process because DBAs
could have high values for log_rotation_* parameters or resources could become
unavailable. :( One idea is to have another process (logger worker) to execute
it. Also we need to store the logfiles that were already rotated.
(3) What do you intend those %p and %f symbols to signify?
%p and %f are relative log path and log filename, respectively.
--
Euler Taveira de Oliveira
http://www.timbira.com/
Takahiro Itagaki escreveu:
If you have better loggers already, why don't you use them? In another word,
should we cooperate with them instead of re-inventing alternative loggers?
We can use but they don't features that our logger has. If we have a logger,
let's improve it.
We have "Logging Brainstorm" topic in out wiki. It might help you.
http://wiki.postgresql.org/wiki/Logging_Brainstorm
Interesting. Don't know about that. Why some of those ideas aren't in our TODO?
--
Euler Taveira de Oliveira
http://www.timbira.com/