Re: Log analysis requirements

["Vladimir G. Ivanovic" <vladimir@acm.org>]

I was wondering what logging you got from `iptraf' that you couldn't get
from `tcpdump' or `ethereal'? I believe that both those programs have
extensive options for logging data.

--- Vladimir

--------
Vladimir G. Ivanovic                        http://leonora.org/~vladimir
2770 Cowper St.                                         vladimir@acm.org
Palo Alto, CA 94306-2447                                 +1 650 678 8014

"GF" == Greg Fenton <greg_fenton@yahoo.com> writes:

  GF> --- Gerard Paul Java <riker@seul.org> wrote:
  >> 
  >> I too would like to see a logfile monitoring script, please feel free
  >> to post it on the list.
  >> 

  GF> Alright, will post what I have when I can.


  >> However I remain open to your suggestions regarding the logfile
  >> analysis.  

  GF> Well, the first thing would be documentation on the format  :-)

  GF> I've looked the code over.  The logging is good enough for readability
  GF> purposes, but poses some real challenges for the analysis scripts.

  GF> Some code calls standard logging methods (writetcplog, writeothplog)
  GF> while others call writelog() with their own messages (and thus, their
  GF> own message format).

  GF> I have reverse-engineered a number of the line formats in order to
  GF> analyze the log for what I need, but for future development it would be
  GF> nice to:

  GF>   a) Replace calls to writelog() with a "higher-level" call like
  GF>      writetcplog()
  GF>   b) Have all "higher-level" functions call writelog() to do their
  GF>      logging, prefixing their message with a "type" identifier
  GF>      (e.g. NORMAL_TCP, RESET_TCP, etc...)

  GF> Then we could easily extract the format of each line in the log file
  GF> and parse it according to its type.  And we'd only need to document the
  GF> output format of these "higher-level" functions.

  GF> Right now my only real recourse is to take an existing log file, parse
  GF> it and look for errors.

  GF> But please, don't take this as a harsh criticism.  I appreciate that
  GF> daemon mode was not an original intent.  I also appreciate that the log
  GF> format, for the most part, easily parsable.  There are only a couple of
  GF> cases that through me for a loop.

  GF> Gerard, thank you for your efforts on this tool and for your
  GF> contributions to Free Software in general.  Should you need some help
  GF> with this project (coding, testing, whatever) please feel free to
  GF> contact me directly.

  GF> greg_fenton.

  GF> =====
  GF> Greg Fenton
  GF> greg_fenton@yahoo.com

  GF> __________________________________________________
  GF> Do You Yahoo!?
  GF> LAUNCH - Your Yahoo! Music Experience
  GF> http://launch.yahoo.com