[RADIATOR] per-clause vs global Logs

[David Zych]

For a long time, I have used a single global <Log FILE> and a single global <Log SYSLOG>, both at Trace 3, to capture everything I might want to know about that doesn't fall into the separate categories of AuthLog or AcctLogFileName.

Now, however, I'm trying to put my Radiator servers behind a server load balancer (SLB); every few seconds, the SLB sends a health check request which Radiator is configured to REJECT (this is safer than ACCEPT and equally effective proof that the server is alive and answering).  The problem is that each REJECT generates INFO-level log output which is cluttering up my logs:

Fri Nov  8 16:56:03 2013 416230: INFO: Access rejected for SI_radius_keepalive: L7 Health Check from SLB


AFAICT there is no way to turn _off_ logging only for certain clauses, so the tentative solution I've come up with is to revamp my logging system so that the global ones are Trace 2, and I use individual Log clauses to do Trace 3.


## Additional finer-grained loggers for use in individual Handlers,
## defined here inside a dummy Handler so they won't be global (see
## http://www.open.com.au/pipermail/radiator/2004-June/009606.html).
<Handler Client-Identifier=GLOBAL_LOGGING_DUMMY_HANDLER>

<Log FILE>
  Identifier logFile-INFO
  Filename %L/general/%Y/%m/logfile.%Y-%m-%d
  LogFormat %Y-%m-%dT%H:%M:%S.%s %{Server:Identifier}: %1: %2
  Trace 3
</Log>

<Log SYSLOG>
  Identifier logSyslog-INFO
  LogSock udp
  LogHost %{GlobalVar:LogHost}
  LogIdent %{Server:Identifier}
  Facility user
  Trace 3
</Log>

</Handler>

#...

# example real handler for wireless access requests
<Handler Client-Identifier=wireless, Request-Type=Access-Request>
  Identifier wireless
  AuthByPolicy ContinueWhileAccept

  # Block by MAC address
  AuthBy wireless-mac_block

  AuthBy wireless-eapOuter

  AuthLog wirelessAuthlog
  AuthLog wirelessSyslog
  Log logFile-INFO
  Log logSyslog-INFO
</Handler>


My first pass was to put those Log lines in every Handler clause (except the one for the SLB health checks)... but empirically that still misses some important INFO messages, such as the following from an AuthBy RADIUS:

Wed Nov  6 16:36:49 2013 319320: INFO: AuthRADIUS ci-authproxy: Could not find a working host to forward admin (1) after 5 seconds. Ignoring
Wed Nov  6 16:36:49 2013 319537: INFO: AuthRADIUS ci-authproxy: No reply after 5 seconds and 0 retransmissions to 127.0.0.1:10006 for admin (115)


My questions:

1. Where do I need to put those "Log" config lines in order to achieve my goal of getting INFO-level logging everywhere except for the one place I specifically don't want it?  Is there some subset of clause types that will suffice (or mostly suffice), or do they have to go in literally every clause in my entire config?

2. If I do put them in literally every clause, will that work?  Or will it generate duplicate log messages?

3. Is there a better way to accomplish this that I'm not seeing?

Thanks,
David