Detailled innfeed logging?

[Bill Davidsen]

Christoph Biedl wrote:

>I'm puzzled about it since I've started using INN ...
>
>Incoming articles: innd logs (into the news logfile) in detail which
>articles were received, when, from which site, which sites will receive
>it or why one was rejected.
>
>Outgoing articles: innfeed as the preferred transmission program is very
>silent about its activities. At least in the default configuration
>there's nothing more than an a summary in log/news.notice and
>log/innfeed.status.
>
>At least sometimes I'd like to have a detailled log per remote site. In
>a first step this would include the articles rejected by the peer (i.e.
>not accepted but not simply duplicate) to debug malformed group patterns
>and the like. Even more verbose but sometimes really helpful was the
>information when a given article was offerend to a peer and whether it
>was transmitted and how the response was.
>
>Did I oversee something in the manpages and the sources? Or is there
>nobody else who is interested in such information?
>
If you want to do it "right" you want a status of accepted, rejected, 
refused, pushed back, dropped, etc, for every article offered to every 
peer... I have the feeling that in many cases the logs would need more 
space than the articles and the overhead of formatting would be 
significant. The places where it would be useful might be large sites 
with a hundred or more peers and a bunch of internal machines. Lot of data.

It might be useful to watch the feed to one site for a minute or so, but 
like any collection of everything available, digging out what you want 
becomes harder as the volume goes up. I personally think exception 
reporting would be tons more useful, because I could usually leave it on.

I presume you have something more than "log hell out of everything" in 
mind, sharing that would get you some feedback, but my first thought is 
that I couldn't afford to have it on all the time, if I did it would be 
expensive to parse, and if I know enough to turn it on for one site at 
the right time, I can probably catch what I need with a sniffer or tcpdump.

Feel free to tell me this would be really useful, and in what instance.

-- 
bill davidsen <davidsen at tmr.com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979