Bug 5225 – Update logging to use Best practice guidelines

Bug 5225 - Update logging to use Best practice guidelines

Summary:

Update logging to use Best practice guidelines

Status:	NEW

Product:	GridFTP
Component:	Campaign
Version:	4.1.0
Platform:	PC Windows XP

Importance:	P3 normal
Target Milestone:	---
Assigned To:	Raj Kettimuthu

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2007-04-19 07:42 by jennifer schopf
Modified:	2008-02-12 11:00 (History)

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note

You need to log in before you can comment on or make changes to this bug.

Description From jennifer schopf 2007-04-19 07:42:58

Campaign: GridFTP Log Updates

Campaign Leader: Jennifer Schopf

People: GridFTP Developer TBD, Jen Schopf

Projects: CEDPS

Technologies: GridFTP

Objective:
Extend and clarify GridFTP logs according to CEDPS best practices guide. This
is a CEDPS deliverable.


Benefits:
Within CEDPS, a best practices for Logging guideline has been written
http://cedps.net/wiki/index.php/LoggingBestPractices
The goal of this work has been to define a uniform format and minimum set of
data that middleware logs contain in order to make the use of those logs for
troubleshooting and fault detection more straightforward, and will allow
performance analysis, security auditing, and incident tracing.


Implementation details/tasks:
1)    Fix timestamp formatting
2)    Verify start/end for each event
3)    Make sure event names match recommended event names, when possible
4)    Make sure error numbers include description of error


Deliverables:
Augmented code, to be part of 4.1.2
Documentation

Resources:
Developer: 3(?) days of Coding
Developer: 1 day of testing, documentation
Jen/LBNL folks (Brian Tierney, Dan Gunter): couple hours of
explaining/coordinating

------- Comment #1 From Mike Link 2007-08-23 09:24:51 -------

A sample log file is here:
http://www-unix.mcs.anl.gov/~mlink/bugs/5225-gridftp.log.


A few more notes:
On transfers failed before they actually start moving data (file not there,
permissions, etc), there is no transfer.start or transfer.end, just a
transfer.error.  It would be awkward to add a start/end in a place where it
would make sense.  I can do it as a special case, but I'd rather not just for
the sake of a start/end message.

When the log level is set to show control channel messages, there is no start
or end.  I just added a .message event for those.  Internally the reporting of
a message being sent/recvd is atomic, so if I instead made it start/end it
would just be two lines written to the log with virtually the same timestamp.

Commands (MKD, DELE, etc) aren't noted unless they fail, and again they are
just .error messages.  The generic control channel message tracing accomplishes
tracking of successful commands. 

Let me know if anything is missing or needs changing.

Mike