[bind10-dev] Tracking queries and other data

[Stephen Morris]

On 3 Dec 2010, at 11:02, Michal 'vorner' Vaner wrote:

> Hello
> 
> On Fri, Dec 03, 2010 at 10:19:25AM +0000, Stephen Morris wrote:
>> My thoughts are to make the query tracing selective: instead of logging all queries or none, we tag queries we are interested in with an ID and log only queries (and related events like upstream fetches) whose ID is non-zero.  These could be enabled in a live server by appropriate commands, e.g.
> 
> Do you want to filter what is logged inside the logging framework or in the
> logic itself?
> 
> I think filtering it in the logging framework would be more flexible and allowed
> future features. What comes into my mind would be multiple logging targets
> (file, pipe, etc) with each one having different events/queries logged/traced or
> a ringbuffer of last few events that could be output as a result of some other
> event (print all events generated by query resulting in error). And I think
> there could be many more.

The problem I addressed is a specific case of filtering.  My suggestion put the identification of packets to trace in the application logic itself as the identification means marking the packet in some way (in the case I described, by setting a query ID).  If we try to do it wholly in the logging framework (with the implication that the framework will not modify the packets or other application data), then the framework will need to somehow identify and remember the packets it is interested in. I think this will be a more difficult option to implement.

However, perhaps what I am describing is really fine-grain filtering.  The logging framework does filtering but uses the coarse filter "packet ID != 0"; what I've described is how to set that condition.

Most logging frameworks have the things you describe and I would think that the BIND10 one will have many of those characteristics.  But we need to define exactly what we want; for example, we may want trace multiple queries at once, but would we ever want the output from each going to a different destination?  And the ring buffer idea is nice, but is it a single server-wide buffer, or would each query have its own ring buffer?

Stephen