Re: [logs] a small reminder

From: Chris Adams (cadamsat_private)
Date: Mon Aug 26 2002 - 19:46:03 PDT

  • Next message: Russell Fulton: "Re: [logs] tokens and layouts..."

    On Monday, Aug 26, 2002, at 14:00 US/Pacific, Tina Bird wrote:
    > as seems to be standard when we talk about logging, we have gone haring
    > off after how to transport the data and how to parse the data and we've
    > lost track of what bloody data we're after.  arguments about "could it 
    > be
    > standardized" notwithstanding, sniff, sniff, surely >>someone<< out 
    > there
    > has opinions about other things they'd like to see?
    
    In an attempt to atone for contributing in the XML thread, I'd like to 
    touch on something that came up in the subtopic about developer support 
    - exposing lower-level error info. Tom's message included all of the 
    basic categories I'd like to get; what I'm more concerned with is 
    getting usable information in the messages - entirely too many apps 
    will log something like "access denied" with no further explanation.
    
    	- anything involving file I/O should include the fully qualified 
    filenames for every file involved
    
    	- anything involving TCP/IP should include the IPs and ports for both 
    ends of every connection
    
    	- any error message should include at least the return value or system 
    error number
    
    	- the user the process was currently running as and, where 
    appropriate, the user it was handling a request for (in the context of 
    a web request, this could be the remote host).
    
    	- In a similar vein it would often be handy to have a complete copy of 
    the original request. I'm concerned that the space used would quickly 
    get unwieldly for complex requests. OTOH, compression might take much 
    the sting out of that. What do you think?
    
    	- any language which has a higher level error construct (e.g. Java 
    Exceptions or the various structs used by C programmers on different 
    platforms) should include some flavor serialized representation of that 
    data. Even if it's a little opaque it will at least be possible to dig 
    deeper.
    
    	- standalone daemons can make sessions harder to follow since you 
    can't use tricks like tracking the PID for processes from inetd. I'd 
    like any daemon to include some sort of unique session ID to avoid this.
    
    Chris
    
    _______________________________________________
    LogAnalysis mailing list
    LogAnalysisat_private
    http://lists.shmoo.com/mailman/listinfo/loganalysis
    



    This archive was generated by hypermail 2b30 : Tue Aug 27 2002 - 09:34:53 PDT