Difference between revisions of "Talk:Projects/Trace logging"
(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...) |
|||
| Line 3: | Line 3: | ||
Regarding the requirements: |
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. |
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.''' |
|
| − | >>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. |
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. |
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.)''' |
|
| − | >>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. |
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. |
||
Revision as of 20:48, 8 September 2009
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
