[bind10-dev] Enabling/disabling logging on per-message basis

[Jerry Scharf]

Hi,

I am not sure that enabling/disabling is the right right way to see 
this. You will always have some system default level of logging in 
operation. It is more a question of whether a single query can get a 
different logging level and processing than the normal production stream.

I am one of the people who strongly argued for doing per packet logging. 
The reason from my point  of view is that I want to be able to run a 
specific query from a command tool with lots of debugging on a 
production server that would otherwise die at this level of debugging. I 
also want that logging information for my query separated so that I can 
easily digest it and prevent pollution of the normal logging system. 
Think of this as an aid in reducing the "time till repair" of a 
contextually processed DNS query issue.

Sometimes it is very easy to separate the query for a test from normal 
traffic, but when you are dealing with things like filters, views and 
other context sensitive processing, you need to have things look very 
real to figure out what it going on. Off-line tests are problematic 
because you are never sure that the systems are identical and you don't 
want to deep trace any normal queries while you are debugging the issue. 
I know there are many who hate views and such, but there are people who 
have to live with them and we need to make their lives easier. I think 
it may turn out to be more generally useful, but this is the main drive.

This came from my direct experience of running DNS load balancers for a 
very high traffic 1 day event. I needed to be able to and trace a query 
that was reported as problematic while the rest of the system continued 
to operate in production at full load. The only difference between the 
query I wanted to run and a production query was that it was tied to out 
of band communication and had a synthesized source address. The software 
didn't have it, I suffered for not having it and I got the vendor to add 
the capability after the fact.

Not being a in the code at all, this may turn out to be expensive. If it 
helped to have this as a function that could be turned on and off 
globally to improve the normal production query flow, that would be 
fine. Just remember that this will no doubt need to be turned on at the 
most inoportune time (when load is highest because things are burning...)

jerry


On 02/29/2012 08:32 AM, Michal 'vorner' Vaner wrote:
> Hello
>
> We talked yesterday on the call about the possibility of enabling and disabling
> of logging of specific message. So, it would mean you could set the logging to
> info, but would be interested in THIS_SINGLE_DEBUG_MSG as well, so you could
> enable that one and you're not interested in the
> WARN_ABOUT_REMOTE_SERVER_BEING_STUPID, so you disable that one, because it spams
> your logs. There was a discussion if it'd be really useful, but I think it might
> be (and if not, it could still be a nice publicity thing, and I actually got the
> idea from a friend who asked just for that). And I'd like to show it could be
> implemented quite easily. I don't know what the consensus was (if any).
>
> We have the LOG_DEBUG and similar macros. They first check if the log level is
> enabled. The check could get another parameter - the message ID - and look into
> a map<MessageID, boolean>  if it is there. If it wasn't there, then it would work
> the normal way, by the log level. If it was, the boolean there would be taken as
> the override for the given message. If the user didn't set any of the overrides,
> the map would be empty, so the lookup would be fast, having only small
> performance impact (it would be negligible to the virtual call we have to the
> isDebugEnabled, as the map is a template, therefore inlined).
>
> And the configuration could be simple as well. A named set in the logger
> configuration.
>
> So, there'd be only little work on it (changing the is*Enabled, the macros and
> python wrappers, add the loading).
>
> Do you think it makes sense to create the ticket and tackle it sometime soon?
>
> With regards
>
>
>
> _______________________________________________
> bind10-dev mailing list
> bind10-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind10-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20120229/11e2ecd6/attachment-0001.html>