Talk:Projects/Trace logging - Revision history

TomYu at 14:42, 10 September 2009

2009-09-10T14:42:19Z

Jc at 01:49, 9 September 2009

2009-09-09T01:49:15Z

Jc at 01:48, 9 September 2009

2009-09-09T01:48:59Z

Jc at 01:48, 9 September 2009

2009-09-09T01:48:26Z

Jc: New page: Hello, Regarding the requirements: >>It is sufficient to be able to be able to log to a file specified by an environment variable. Good. We run multiple processes interfacing to the k...

2009-09-09T01:47:20Z

New page: Hello, Regarding the requirements: >>It is sufficient to be able to be able to log to a file specified by an environment variable. Good. We run multiple processes interfacing to the k...

New page

Hello,

Regarding the requirements:

>>It is sufficient to be able to be able to log to a file specified by an environment variable.

Good. We run multiple processes interfacing to the krb5 library, we'll want to ensure each process can write to a unique file.

>>It is important that it be possible to enable trace logging in a standard build, such as the
>>one shipped by the operating system vendor, because it is generally not possible to substitute
>>specially compiled code in a customer deployment.

Yes. We'd need the ability to enable it, get the data we need, then disable it.

>>There are four basic possibilities here:
>>
>>4. (2) and (3) could be combined, perhaps with a separate logging level for each keyword.

I like #4. We need the flexibility to be able to selectively log so we can pin-point the problem area and get a problem resolved without having to troll through too many gigs of data.

>>APIs could be provided to turn tracing on and off, or direct different contexts to
>>different files. (However, API control of tracing is not a requirement.)

this will be hard to work with as we'd need to build some interface to the process that links and uses the krb library to enable/disable logging. would it be possible to do this by writing something in krb5.conf, which seems to get read quite a bit by the library already? or, perhaps by testing presence of a file, i.e., /etc/krb5_logging.conf and if present, reading/processing it? I agree, from a performance point of view, an API is the way to go; implementation wise to enable, it is harder, but not impossible.

-jc

← Older revision		Revision as of 14:42, 10 September 2009
Line 20:		Line 20:

	-jc		-jc
		+
		+	: Hi -- would you please make your comments on the krbdev list? Many developers do not monitor the Talk pages on the wiki, and it is more productive to have a discussion on the list. -[[User:TomYu\|TomYu]] 10:42, 10 September 2009 (EDT)

@@ Line 11: / Line 11: @@
 Yes.  We'd need the ability to enable it, get the data we need, then disable it.
-'''There are four basic possibilities here:
+'''There are four basic possibilities here: [...] 4. (2) and (3) could be combined, perhaps with a separate logging level for each keyword.'''
 I like #4.  We need the flexibility to be able to selectively log so we can pin-point the problem area and get a problem resolved without having to troll through too many gigs of data.

← Older revision		Revision as of 01:48, 9 September 2009
Line 12:		Line 12:

	'''There are four basic possibilities here:		'''There are four basic possibilities here:
−
	4. (2) and (3) could be combined, perhaps with a separate logging level for each keyword.'''		4. (2) and (3) could be combined, perhaps with a separate logging level for each keyword.'''

@@ Line 3: / Line 3: @@
 Regarding the requirements:
->>It is sufficient to be able to be able to log to a file specified by an environment variable.
+'''It is sufficient to be able to be able to log to a file specified by an environment variable.'''
 Good.  We run multiple processes interfacing to the krb5 library, we'll want to ensure each process can write to a unique file.
->>It is important that it be possible to enable trace logging in a standard build, such as the
+'''It is important that it be possible to enable trace logging in a standard build, such as the one shipped by the operating system vendor, because it is generally not possible to substitute specially compiled code in a customer deployment.'''
 Yes.  We'd need the ability to enable it, get the data we need, then disable it.
->>There are four basic possibilities here:
+'''There are four basic possibilities here:
->>
->>4. (2) and (3) could be combined, perhaps with a separate logging level for each keyword.
+. (2) and (3) could be combined, perhaps with a separate logging level for each keyword.'''
 I like #4.  We need the flexibility to be able to selectively log so we can pin-point the problem area and get a problem resolved without having to troll through too many gigs of data.
->>APIs could be provided to turn tracing on and off, or direct different contexts to
+'''APIs could be provided to turn tracing on and off, or direct different contexts to different files. (However, API control of tracing is not a requirement.)'''
 this will be hard to work with as we'd need to build some interface to the process that links and uses the krb library to enable/disable logging.  would it be possible to do this by writing something in krb5.conf, which seems to get read quite a bit by the library already?  or, perhaps by testing presence of a file, i.e., /etc/krb5_logging.conf and if present, reading/processing it?  I agree, from a performance point of view, an API is the way to go; implementation wise to enable, it is harder, but not impossible.