<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi,<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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...)<br>
<br>
jerry<br>
<br>
<br>
On 02/29/2012 08:32 AM, Michal 'vorner' Vaner wrote:
<blockquote cite="mid:20120229163252.GA15374@hydra" type="cite">
<pre wrap="">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
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
bind10-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bind10-dev@lists.isc.org">bind10-dev@lists.isc.org</a>
<a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/bind10-dev">https://lists.isc.org/mailman/listinfo/bind10-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>