How do you add LOGLEVEL labels to Postfix log output?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

How do you add LOGLEVEL labels to Postfix log output?

yodeller
Hello,

I use Postfix's per-domain debug logging a lot.

My configuration's got

        parent_domain_matches_subdomains = debug_peer_list
        debug_peer_list = pcre:/etc/postfix/debug_peer_list.pcre
        debug_peer_level = 1
        debugger_command =
          PATH=/bin:/usr/bin:/usr/local/bin:
          ddd /usr/libexec/postfix/${process_name} ${process_id} & sleep 5

For the domains in the peer list all the debug level logging still goes into the systemd journal and I pull out postfix-specific entries with rsyslog into my main postfix log, /var/log/postfix/postfix.log

It's all good!

But it's getting noisy in there.

I want to redirect the debug-level log info into it's own file.

There's no label in my postfix logs of what loglevel each line is being generated at.

Is there a way to customize the log format to add a loglevel label to the logs?  How & where would you configure that?

Thanks alot.

Reply | Threaded
Open this post in threaded view
|

Re: How do you add LOGLEVEL labels to Postfix log output?

Noel Jones-2
On 8/19/2017 3:53 PM, [hidden email] wrote:
> Hello,
>
> I use Postfix's per-domain debug logging a lot.


Why?  The general opinion here is everything important is already in
the normal logs, and the debug logs usually just make it hard to
find the real problem among the noise.  Is there some specific event
that maybe needs to be included in the normal logs?

> I want to redirect the debug-level log info into it's own file.
>
> There's no label in my postfix logs of what loglevel each line is being generated at.

Sorry, not configurable other than patching the source.



  -- Noel Jones
Reply | Threaded
Open this post in threaded view
|

Re: How do you add LOGLEVEL labels to Postfix log output?

Wietse Venema
Noel Jones:

> On 8/19/2017 3:53 PM, [hidden email] wrote:
> > Hello,
> >
> > I use Postfix's per-domain debug logging a lot.
>
>
> Why?  The general opinion here is everything important is already in
> the normal logs, and the debug logs usually just make it hard to
> find the real problem among the noise.  Is there some specific event
> that maybe needs to be included in the normal logs?
>
> > I want to redirect the debug-level log info into it's own file.
> >
> > There's no label in my postfix logs of what loglevel each line is being generated at.
>
> Sorry, not configurable other than patching the source.

The logging level is specified via the syslog protocol. Every
syslog-compatible server (syslogd, etc.) will allow you to configure
handling that depends on the logging level.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: How do you add LOGLEVEL labels to Postfix log output?

Viktor Dukhovni

> On Aug 19, 2017, at 9:07 PM, Wietse Venema <[hidden email]> wrote:
>
>> Sorry, not configurable other than patching the source.
>
> The logging level is specified via the syslog protocol. Every
> syslog-compatible server (syslogd, etc.) will allow you to configure
> handling that depends on the logging level.

That said, both regular and debug logging in Postfix are logged
at the "info" level, Postfix does not use the syslog "debug" log
level.  Therefore, built-in syslog log filtering cannot isolate
just the debug messages from Postfix, but as Noel points out,
you really should not have Postfix debug logging enabled on a
routine basis.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: How do you add LOGLEVEL labels to Postfix log output?

yodeller
Hello,

On Sat, Aug 19, 2017, at 06:58 PM, Viktor Dukhovni wrote:
> That said, both regular and debug logging in Postfix are logged
> at the "info" level, Postfix does not use the syslog "debug" log
> level.  Therefore, built-in syslog log filtering cannot isolate
> just the debug messages from Postfix

Okay so the answer sounds lika a "no".  Thanks for letting me know.  I'll have to figure something else out.

> but as Noel points out, you really should not have Postfix debug logging enabled on a
> routine basis.

It's there for a reason isn't it?  I use it when there's a problem and I need more information.  It's great having that level of detail.  It's helped me solve a bunch of problems for specific domains without drowning in a flood of useless detail for all domains.  When then problem's solved I turn it off for that domain and move on.  I honestly don't see what the problem is using debugging facility that's provided when it provides the info you need to solve the problem.  Personally I see that as a great, helpful feature.
Reply | Threaded
Open this post in threaded view
|

Re: How do you add LOGLEVEL labels to Postfix log output?

Viktor Dukhovni

> On Aug 19, 2017, at 11:31 PM, [hidden email] wrote:
>
>> but as Noel points out, you really should not have Postfix debug logging enabled on a
>> routine basis.
>
> It's there for a reason isn't it?  I use it when there's a problem and I need more information.  It's great having that level of detail.  It's helped me solve a bunch of problems for specific domains without drowning in a flood of useless detail for all domains. When then problem's solved I turn it off for that domain and move on.  I honestly don't see what the problem is using debugging facility that's provided when it provides the info you need to solve the problem.  Personally I see that as a great, helpful feature.

Indeed it is useful as needed from time to time.  If you don't
have debug logging turned on all the time, you're fine.  The
debug logs do end up intermixed with regular Postfix "info"
logging when enabled.  There's not much you can do about that.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: How do you add LOGLEVEL labels to Postfix log output?

Bill Shirley
In reply to this post by yodeller
Is there some specific text that rsyslog can key off of?  I use this for
Shorewall and dhcpd (right after the #### RULES #### line):
if $msg contains 'Shorewall' then {
  action(type="omfile" file="/var/log/shorewall.log")
  if ($syslogfacility == 0 and $syslogseverity >= 6) then stop  # info
}
 
if $programname == 'dhcpd' then {
  action(type="omfile" file="/var/log/dhcpd.log")
#  if $syslogseverity >= 4 then stop    # warning
#  if $syslogseverity >= 5 then stop    # notice
  if $syslogseverity >= 6 then stop     # info  
  if $msg contains 'incoming update is less critical than outgoing update' then stop
}
The first rule logs all Shorewall messages to /var/log/shorewall.log.  Any
message more severe than 'info' is allowed to pass on to the other rules
which for me, will also log in /var/log/messages.

The second rule is similar.

I don't know what a Postfix debug message looks like.  But something like:
if $programname == 'postfix' and $msg contains 'debug' then {
  action(type="omfile" file="/var/log/postfix-debug.log")
  stop
}
might work for you.

Bill


On 8/19/2017 11:31 PM, [hidden email] wrote:
Hello,

On Sat, Aug 19, 2017, at 06:58 PM, Viktor Dukhovni wrote:
That said, both regular and debug logging in Postfix are logged
at the "info" level, Postfix does not use the syslog "debug" log
level.  Therefore, built-in syslog log filtering cannot isolate
just the debug messages from Postfix
Okay so the answer sounds lika a "no".  Thanks for letting me know.  I'll have to figure something else out.

but as Noel points out, you really should not have Postfix debug logging enabled on a
routine basis.
It's there for a reason isn't it?  I use it when there's a problem and I need more information.  It's great having that level of detail.  It's helped me solve a bunch of problems for specific domains without drowning in a flood of useless detail for all domains.  When then problem's solved I turn it off for that domain and move on.  I honestly don't see what the problem is using debugging facility that's provided when it provides the info you need to solve the problem.  Personally I see that as a great, helpful feature.