william,
Comments in line.
On 03/17/10 03:20 AM, William Schumann wrote:
> Virginia,
> Please see replies inline:
> On 03/16/10 09:50 PM, Virginia Wray wrote:
>>
>> On 03/16/10 11:09, William Schumann wrote:
>>>
>>> RE: 6. Output Format: There should be sufficient parseable data or
>>> metadata in the log messages so that they can be predictably and
>>> easily filtered. For example:
>>>
>>> <timestamp>;<severity>;<application id>;<specific ID>;<content
>>> type>;<payload>
>>>
>>> - where "specific ID" is a number that is cataloged (for ez lookup,
>>> localization, etc.)
>> What kind of specific id are you referring to? A process id? I'm not
>> sure what you're referring to here or how it would be generated.
> A specific ID would be a number or name that identifies an event. The
> event could be a milestone ("install complete") or an error code
> ("disk full", "assertion failed"), for example. It would be unique in
> itself or in combination with the application ID. The idea is to
> standardize the way it is referred to so that it can be filtered by ID
> later without having to search for text that can change at any time.
I believe what you are expressing via specific ID is the error message
type information which will be available. The error handling framework
provides specific ids and associates the messages with them. There is
also an ID associated with the component which generates a message by
default. So if one wanted to filter for debugging purposes on that
component it is possible.
>
> The codes would not have to be generated. Codes to represent events
> that occur at any time, such as "disk full" could be taken from a
> standard library. Application-specific codes could be defined locally
> to an application, module, or class, e.g.,
> TargetDiscovery,slice_not_found. In a program, there would be a
> symbolic reference to the code. Perhaps the codes could all map to
> exceptions. Having them cataloged would be nice, but the main idea is
> that the codes themselves be reliable whereas the text is subject to
> change and localization.
>
>>
>>> - "content type" in the sense of an SMTP email message
>> The output format shown is specific to output to a File. There are
>> different types of handlers that are available through the Python
>> Logging
>> module that we can engage for different types of format. For example,
>> there is an SMTP handler that would manage output to an SMTP mail
>> server.
> What I am proposing here is embedding the content type into the
> message, i.e., the input. That would permit more sophisticated
> payloads that were customized for a particular output content type:
> *HTML*, for example. You could even have crazy stuff like graphical
> screenshots in the log for the GUI installer.
Indeed these are some of the potential capabilities we discussed. The
payload is planned per handler not per message. It is worth thinking
what this might mean.
>>> A position-independent format might have variables such as:
>>> lang=en_US,msgid=22,type=assertion
>> The last sentence of the section leaves open the possibility of
>> formatting being customized by applications.
> Yes. The design document should at least allude to these
> possibilities and perhaps suggest how they would be encoded.
>>>
>>> For 8.1 Client Side: what purpose does it serve for add_handler() to
>>> specify:
>>> - a date?
> Please explain what "date" as add_handler() input means.
>>> - Content type?
>> Sorry, I missed that when I changed the name of the method. That
>> should be init_handler. I'll fix it.
>> The handlers manage the destinations where things will be logged. In
>> this case, it will set up a handler
>> that supports sending logging messages to a Web server, which is how
>> remote logging is being managed.
>>>
>>> The design should provide for filtering and forwarding log messages
>>> upstream. Take for example a network in which a data center wants
>>> to see only critical error messages, or if someone wants to see a
>>> specific error from a wide variety of locations. The model might
>>> look like this:
>>>
>>> INSTALL INSTALL ...
>>> | |
>>> V V
>>> LOGSERVER LOGSERVER ...
>>> | | <--filtered
>>> V V
>>> -DATACENTER-
>>> | <--filtered even more
>>> V
>>> CURIOUS_USER_WITH_SPECIFIC_INTEREST
>>>
>>> For another example, perhaps a programmer wants to see all
>>> assertions that occur in all installs in a large network. Or a
>>> sysadmin wants to oversee a number of installations from a wide
>>> geographic range and only see very specific information, such as
>>> "install complete" without filtering for specific text, but rather,
>>> a specific code that meant "installation complete". Could this be
>>> accomplished with the current design?
>> It could definitely be an enhancement. The Python logger has
>> filtering functionality.
> To clarify, I would like to see support for the logging server to
> forward logging information to clients, including:
> - sending the raw logging data to another logging server
> - using a particular filter
> In the diagram from the document, this would be represented as an
> arrow from the Log Server to another network cloud to another Log
> Server or client (possibly with arrows in the other direction to
> indicate the filtering requests).
> I think that add_handler() could be used to forward the raw messages
> (filtered or unfiltered) to another destination, likely remote and
> centralized - is this correct?
>>> How is it Python logging hierarchical?
>> It is how the python docs refer to the capability of doing the
>> following:
>> You create a logger and configure it:
>> getLogger(L)
>>
>> Then you can create loggers such as:
>> getLogger(L.M)
>> getLogger(L.M.N)
>> getLogger(L.O)
>>
>> They would all be children of L. So you wouldn't need to define all
>> of these loggers further. They could pick up the configuration of L.
>> However, you could provide unique configuration if you chose.
> What would this be useful for?
>
> William
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/caiman-discuss/attachments/20100317/3dc0c014/attachment.html>
