Abstract:
A unified logging service is provided which may be employed across a variety of applications, allowing collected information to be stored, aggregated, and accumulated; presenting a more complete view, than previously available, related to those applications. The unified logging service provides a generalized centralized web services based service with the capability of accepting and collecting a variety of log formats containing a variety of logged events. These events may originate from clients using differing log formats or types in a heterogeneous distributed computing environment. Acknowledgement of receipt of log files may be provided to the originating clients. A log routing capability is also provided as well as a central repository for storing and forwarding log messages flowing throughout the system. These services may be accessed locally or remotely via published web services interfaces.

Description:
FIELD OF THE INVENTION  
         [0001]    This present invention relates generally to the logging of events generated by computer applications, and more particularly to the unified logging of events generated by computer applications distributed across a network.  
         BACKGROUND  
         [0002]    Event logging has been known since the early days of sailing. Today in computer based systems and applications the idea of logging has taken new meaning. The recording of event occurrence information is the act of logging. The data captured is placed in storage devices and later processed in a variety of ways. The processing typically involves problem determination, recovery or statistical analysis to derive information related to system as well as application usage or behaviour.  
           [0003]    Some computer systems include logging services to maintain system specific information. Such information may be stored on a local device for later use. Cases of remote logging are also known wherein the log information is transmitted over a network and stored at a location remote from the source of the logged event. Remote logging requires the knowledge of host system information to keep track of the source.  
           [0004]    Applications which operate on top of system operating systems also create events and record the occurrence of such events. These log files are created and maintained for the purpose of monitoring application activity and status of components or other objects and activities important to the operation of the application and the care of the data created. Application log files tend to be application specific in content and format. These log files as in the case with system log files tend to be created and maintained in close proximity to the source. When such log files are remote they have the same requirements as do the system based log files, that is the identification of the source of the information which includes some form of network addressing.  
           [0005]    Even when log files are collected from remote locations the collected log files are maintained in the same form as they were created. This creates islands of log data wherein each island is tailored to a specific kind or format of log. Interface requirements of each log type are known and required to input and extract information from the respective log files.  
           [0006]    The uniqueness of the log file across applications and systems causes operational concerns as system and application administrators cope with the varying requirements. The uniqueness also inhibits the data sharing across log types or formats. Problems requiring data from multiple log sources typically requires the involvement of multiple people each having skill in interpreting and working with particular logs or log formats. For example an application problem may be resolved after investigating the system, application and network logs; each involving a separate person and set of tools.  
           [0007]    As the data formats of the various logs differ so have the tools used to maintain and report on log data. Additional tools require more time and money to acquire and maintain as well as get training.  
         BRIEF SUMMARY OF THE INVENTION  
         [0008]    Conveniently, software exemplary of the present invention allows the collection of specific information associated with an application or a system, such as the transactional information of an application collected in the form of log files to be gathered in a location which may be separate from the location of the source and combined with a similar type of information from other dissimilar sources.  
           [0009]    Advantageously, the technique may be employed across a variety of applications, allowing collected information to be stored, aggregated, and accumulated; presenting a more complete view related to those applications.  
           [0010]    The unified logging service is provided as a generalized, centralized web based service. This service has the capability of accepting and collecting a variety of log formats containing a variety of logged events. These events may originate from clients using differing log formats or types in a heterogeneous distributed computing environment.  
           [0011]    A log routing capability is also provided as well as a central repository for storing and forwarding log messages flowing throughout the system.  
           [0012]    These services may be accessed locally or remotely via published web services interfaces. There are typically no restrictions on the common format of the stored log information or consistent interfaces of the logging service. This allows the handling of different logs in different formats under different computing environments. XML has been used to provide the flexibility required to transform log objects as they enter and leave the unified logging service, making these objects more portable and compatible than before.  
           [0013]    In a hosting service platform various types of logs are typically generated from the hosted applications and services as well as from the actual components of the hosting system platform itself. A unified logging service must therefore be versatile to handle the variety of log formats encountered. This unified logging service is designed to provide a generalized service with a logging interface for viewing the logs from various log clients where these clients were the originators of the logged events.  
           [0014]    The specific log formats generated by the log clients can be restructured using log adapters and log renderers. The log adapters and renderers are paired to work in conjunction with specific log formats using XML based services to format log information for transmission into and out of the unified log service. Processing of the received log file by the unified log service uses the same log renderers to restructure the log file for return to the original specific log format.  
           [0015]    Using a well known publish and subscribe mechanism allows differing log type to be identified and routed to the appropriate log handler that has subscribed to those types of logs previously. Through the use of different log handlers the log files can be forwarded to other log system or stored in a log file repository.  
           [0016]    In one aspect of the invention there is provided a method of providing a unified logging service, for use in a network having a plurality of nodes capable of generating event logs, wherein the unified logging service having a unified log server and repository, comprising the steps of converting an event log file of a first log type and structure associated with a sending node into a predefined format and transmitting the converted event log file over said network to said unified log server. The unified log server receiving the converted event log file, determining the log type of the converted log file and routing the converted log file to a log handler compatible with the log type and the predefined format. Identifying a receiving node compatible with the log type for the converted event log file, and forwarding the converted event log file from the log handler to the identified receiving node.  
           [0017]    In another aspect of the invention, there is provided an apparatus for providing a unified logging service, used with event log files having a first log type and structure, for use in a network having a plurality of nodes capable of generating event log files, comprising a unified logging server, means for receiving said event log file at said unified logging server, a log adapter for converting said event log file from said first protocol to a predefined format, means for determining a log type of said converted event log file and a log handler suitable for said log type, means for forwarding said converted event log file to said log handler, means for identifying a receiving node, and means for forwarding said converted event log file to said identified receiving node.  
           [0018]    In yet another aspect of the invention, there is provided a system for providing a unified logging service, for use in a network having a plurality of nodes capable of generating event logs, wherein the unified logging service having a unified log server and repository, comprising a sending node having a first log type and structure, an event log file having a first log type associated with the sending node, a log adapter for the sending node for converting the event log file from the first protocol to a predefined format, and means for transmitting the converted event log file across the network to the unified logging server. Additionally, means for receiving the converted event log file at the unified logging server, means for determining the log type of said converted event log file and a log handler suitable for the log type, means for forwarding the converted event log file to the log handler, means for identifying a receiving node for the converted event log file, and means for forwarding said converted event log file to the identified receiving node.  
           [0019]    Other aspects and features of the present invention will become apparent to those of ordinary skill in the art upon review of the following description of specific embodiments of the invention in conjunction with the accompanying figures. 
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0020]    In the figures, which illustrate embodiments of the present invention by example only,  
         [0021]    [0021]FIG. 1 is a hardware overview of a network including at least one unified log server for collecting heterogeneous log information, several application computing devices, and at least one client computing device, exemplary of embodiments of the present invention;  
         [0022]    [0022]FIG. 2 illustrates exemplary hardware architecture of a unified log server of FIG. 1;  
         [0023]    [0023]FIG. 3 illustrates a first exemplary software architecture of a unified log server of FIG. 1;  
         [0024]    [0024]FIG. 4 illustrates a process flow of a unified log server of FIG. 3;  
         [0025]    [0025]FIG. 5 illustrates a second exemplary software architecture of a unified log server of FIG. 1;  
         [0026]    [0026]FIG. 6 illustrates a process flow of a unified log server of FIG. 5  
         [0027]    [0027]FIG. 7 is a class diagram of interface and implementation classes of an exemplary embodiment of a unified log server of FIG. 3;  
         [0028]    [0028]FIG. 8 is an object model diagram of an exemplary embodiment a unified log server of FIG. 3;  
         [0029]    [0029]FIG. 9 is a code example of definitions associating a log type to an internal processing format of exemplary embodiment of FIG. 3;  
         [0030]    [0030]FIG. 10 is a code example of invoking a web service interface in an embodiment of a unified log server of FIG. 3;  
         [0031]    [0031]FIG. 11 is a code example of adapter code in an embodiment of a unified log server of FIG. 3; and  
         [0032]    [0032]FIG. 12 is a code example of a configuration file of a unified log server of FIG. 3. 
     
    
     DETAILED DESCRIPTION  
       [0033]    The present invention will now be described more fully hereinafter with reference to the accompanying drawings, in which preferred embodiments of the invention are shown. This invention may, however, be embodied in different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Like reference numbers signify like elements throughout the description of the figures.  
         [0034]    The present invention may be embodied as methods, systems, and/or software products. Accordingly, the present invention may be embodied in software (including firmware, resident software, micro-code, etc.). Furthermore, the present invention may take the form of a software product on a processor-usable or processor-readable storage medium having processor-usable or processor readable program code embodied in the medium for use by or in connection with an instruction execution system. In the context of this document, a processor-usable or processor readable medium may be any medium that can contain, store, communicate, propagate, or transport the software for use by or in connection with the instruction execution system, apparatus, or device including a network of such devices.  
         [0035]    [0035]FIG. 1 illustrates an exemplary data communications network  20 , interconnected with a server  50 , in communication with a plurality of computing devices  40   a ,  40   b  and  40   c  (individually and collectively devices  40 ), exemplary of embodiments of the present invention. A client computing device  30  in communication with network  20  to establish communication with server  50  is also illustrated. Computing devices  40  and client computing device  30  are differing examples of sending and receiving nodes. Determination of being a sending or a receiving node is based on the circumstance of communication with server  50 .  
         [0036]    Computing devices  40 , client computing device  30  and data collection server  50  are all conventional computing devices, each including a processor and computer readable memory storing an operating system and software applications and components for execution.  
         [0037]    Network  20  may for example be a conventional local area network that adheres to suitable network protocol such as the Ethernet, token ring or similar protocols. Alternatively, the network protocol may be compliant with higher level protocols such as the Internet protocol (IP), Appletalk, or IPX protocols. Similarly, network  20  may be a wide area network, or the public internet.  
         [0038]    Client computing device  30  is a network aware computing device, providing an end-user interface that allows an end-user to exchange and view information stored at server  50 .  
         [0039]    Computing devices  40  are computing devices storing and executing data processing, data storage or similar applications. Often such computing devices are referred to as application servers. As will become apparent, applications at each device  30  and  40  store data such as log files for their own use and processing, typically on computer storage memory at devices  30  and  40 .  
         [0040]    Server  50  collects log file information from computing devices  30  and  40 , by way of component software stored and executing at computing devices  30  and  40 . Collected information is stored at server  50  for viewing and analysis, for example by way of client computing devices  30  and  40 .  
         [0041]    Simplified preferred hardware architecture of an example computing device  50  is schematically illustrated in FIG. 2. In the illustrated embodiment, device  50  is a conventional network capable server. Device  50  could, for example, be an Intel × 86  based computer acting as a Microsoft Windows NT, Apple, or Unix based server, workstation, personal computer or the like. Example device  50  includes a processor  12 , in communication with computer storage memory  14 ; network interface  16 ; input output interface  18 ; and video adapter  22 . As well, device  50  may optionally include a display  24  interconnected with adapter  22 ; input/output devices, such as a keyboard  26  and disk drive  28  and a mouse (not shown) or the like. Processor  12  is typically a conventional central processing unit, and may for example be a microprocessor in the INTEL ×86 family. Of course, processor  12  could be any other suitable processor known to those skilled in the art. Computer storage memory  14  includes a suitable combination of random access memory, read-only-memory, and disk storage memory used by device  12  to store and execute software programs adapting device  12  to function in manners exemplary of the present invention. Drive  28  is capable of reading and writing data to or from a computer readable medium  32  used to store software and data to be loaded into memory  14 . Computer readable medium  32  may be a CD-ROM, diskette, tape, ROM-Cartridge or the like or other large capacity storage. Network interface  26  is any interface suitable to physically link device  10  to network  16 . Interface  26  may, for example, be an Ethernet, ATM, ISDN interface or modem that may be used to pass data from and to network  20  or another suitable communications network.  
         [0042]    The hardware architectures of computing devices  40  and client computing device  30  are materially similar to that of server  50 , and will therefore not be further detailed.  
         [0043]    [0043]FIG. 3 schematically illustrates first exemplary software architecture of a unified log server of FIG. 1.  
         [0044]    Client  30  is shown comprising log client  32 , log renderer  34  and log adapter  36 . Log renderer  34  and log client adapter  36  although shown in relation to client  30  need not be located with client  30  as they may be disposed at server  50  of FIG. 1. Log client  32  produces the events that are captured via logging means. Log renderer  34  is exemplary software used by log adapter  32  to format a particular log file into presentable format for log client  32 . Log client adapter  36  is exemplary software that restructures log file data into a common format for transmission to unified logging service  50 .  
         [0045]    Client  40  is another embodiment of client  30 , wherein client  40  comprises log client  42 , having log adapter  44  using log renderer  46 . Similar components function as set forth in describing client  30 .  
         [0046]    Log files move between client  30  and server  50  by means of the common logging web services  52  interface. Common logging service and unified logging service may be used interchangeably throughout the following description and is to be taken as meaning the same. The web services based logging interface is one that can be published to a public service directory for use with Universal Data Description and Interchange (UDDI). If client  30  has implemented log adapter  36  then a log file coming from client  30  would be prepared in a common log file format by log adapter  36 . If log adapter  36  was not implemented at client  30  then the log file from client  30  would be transmitted to log adapter  36  implemented on server  50 . A log file of client  30  would have a first log type and structure associated the file. Log adapter  36  would perform restructuring as required in accordance with the type of log and differences described between the source log format and the common log format of server  50 . The unified log service can be public and subscribed to externally from the enterprise. There is also potential to provide the service as a billable service (user pay).  
         [0047]    Log processor  54  has a capability of recognizing different log types and routing those identified logs to their respective log handlers. Log processor  54  may also perform log filtering based on log configuration information maintained on log server  50  and route processed logs to an appropriate log repository or forward to another log system. Log processing can be buffered at the sending end to batch the call to the log service for log creation enhancing throughput.  
         [0048]    Log renderer  56  performs serialization of the log message body between XML format of the unified log file and the object structure of the specific event log files. A log renderer is required for each type of event log file to be supported. The service employs pairs of log handler/log renderers to handle specific formats which may be customized (user provided if one not previously available) for handling unlimited log types and log formats using XML as the message body.  
         [0049]    Log handler  58  handles specific types of logs. They are used to display and store and forward log messages to differing destinations or target users. The log handlers process most of the log information in the log files.  
         [0050]    Log consumers  38  and  48  are requesters or recipients of log file data. Log consumers  38  and  48  typically request log information in a “requester format” requiring conversion between the unified logging service format and the particular unique object structure of the requester. The conversion would be performed by the associated log handler  58  and log renderer  56 .  
         [0051]    Repository  64  is storage medium for containment of the log data in the unified format of the unified log server. The repository performs storage duties for store and forward needs as well as persistent storage. The storage medium may be searched to find specific information related to or held within the unified logs.  
         [0052]    [0052]FIG. 4 illustrates a typical unidirectional flow of messages of the unified log server of FIG. 3. Beginning with step  300  a log creation is initiated by invocation of log adapter in  302 . During  304  the log adapter is required to make a determination of the applicability of the log request with respect to the capability of the log adapter. If the log adapter cannot handle the request, the request and file are dumped. In this example log adapter  36  and log renderer  34  would be used in combination to reformat the log object from the sending node format or first structure into a predefined format of the common or unified logging service. In this manner the log renderer  34  functions much like a “plug-in” to log adapter  36  providing necessary function for the specific conversion required. A suitable request being made allows buffering of the log to begin in step  306 . As buffering is performed checks are made in  308  to determine if the buffer is full. If not full more data is simply added. When the buffer is filled the data is transmitted in step  310 . A corresponding receipt in step  312  on unified logging server  50  causes the converted log file to be available for processing. First in step  314  a determination is made as to whether the log received is supported by the unified logging server  50 . If not the log is dumped, other wise a determination is made in step  316  regarding the type of log to be processed and a corresponding log handler for that log type. Having made this determination in step  318  the log is sent to the indicated log handler. In step  320  the log handler determines which log consumer requested the log, processes the log according to the requester requirements and forwards the results to the target requester. During step  322  the requester consumes the log as requested or in the event no requester was found the data is stored for future use causing the instant action to cease at  324 .  
         [0053]    [0053]FIG. 5 is similar to FIG. 3 with the exception that the arrows denoting the path of messages throughout the service are bidirectional. FIG. 5 illustrates the capability of the unified logging service to process messages in more than a single direction. This bidirectional capability provides an opportunity to have a “dialog” between senders and “requesters” of log information. The components of FIG. 5 are similar to those of FIG. 3 and therefore will not be dealt with again.  
         [0054]    [0054]FIG. 6 illustrates the flow of messages in two directions rather than the single direction of FIG. 4. Although the flow is explained from the top down through the service, it may be appreciated that the flow could also be initiated from the bottom to the top.  
         [0055]    Beginning with step  500  a log creation is initiated by invocation of log adapter in  502 . During  504  the log adapter is required to make a determination of the applicability of the log request with respect to the capability of the log adapter. If the log adapter cannot handle the request, the request and file are dumped. In this example log adapter  36 , and log renderer  34  would be used in combination to reformat the log object from the sending node format or first structure into a predefined format of the common or unified logging service. In this manner the log renderer  34  functions much like a “plug-in” to log adapter  36  providing necessary function for the specific conversion required. A suitable request being made allows buffering of the log to begin in step  506 . As buffering is performed checks are made in  508  to determine if the buffer is full. If not full more data is simply added. When the buffer is filled the data is transmitted in step  510 . A corresponding receipt in step  512  on unified logging server  50  causes the converted log file to be available for processing. First in step  514  a determination is made as to whether the log received is supported by the unified logging server  50 . If not the log is dumped, other wise a determination is made in step  516  regarding the type of log to be processed and a corresponding log handler for that log type. Having made this determination in step  518  the log is sent to the indicated log handler. In step  520  the log handler determines which log consumer requested the log, processes the log according to the requester requirements and forwards the results to the target requester. During step  522  the requester consumes the log as requested or in the event no requester was found the data is stored for future use. Departing from where the process of FIG. 4 stopped there is now step  524  in which the log consumer or recipient initiates an acknowledgement or call back message. If the call back message is in a format suitable for the log message format of the destination no conversion will be necessary, as in the case of a simple acknowledgment. Although not shown, the log consumer  38  may also have been configured to contain a log adapter  36  and log renderer  34  as in client  30  providing a capability to create more complex messages in a predefined format of the unified logging service. However if the format of the call back message is different than that of the destination node, conversion will have to be performed. Conversion to the destination node format will be performed by the log adapter and log renderer of the destination node to a first structure of the destination node. The log handler receives the call back in  526  and proceeds in  528  to determine the destination of the message by looking in the message header for target identifier of a log adapter. Having made the association in  528 , the message is then sent in  530  to the identified log adapter. The message is received in  532  at the specified log adapter and the log client renderer is invoked to present the message. The flow terminates now at  534 .  
         [0056]    Referring now to FIG. 7 is a class diagram of interface and implementation classes of an exemplary embodiment.  
         [0057]    The parent interface for the unified logging service  600  is CommonLogAPI  610  defining the high level structure of a log used in the service. A log consists of a log header and a log message body. A log processor must be able to handle both parts of the log in which the header is common across log types and the body portion varies. A log handler may be capable of handling more than one type of log concurrently.  
         [0058]    Interfaces CommonLogClientAdapterAPI, CommonLog ProcessorAPI, and CommonLogHandlerAPI,  612 ,  614  and  616  respectively are extensions of CommonLogAPI  610 . Each defines an extension for a respective process of log creation, log processing and log handling.  
         [0059]    CommonLogClientAdapterImpl  620  implements CommonLogClientAdapterAPI  612  interface forming the basis of the log adapter implementation. To accommodate differing types of logs, each log type has its own dedicated adapter. For example the CommonLogClientAuditLogAdapter  628  class is exemplary of a specific implementation for support of audit logs.  
         [0060]    CommonLogProcessorlmpl  622  implements interfaces of CommonLogProcessorAPI  614  forming the basis the log processor implementation. CommonLogProcessorlmpl  622  provides the log type recognition services used to differentiate logs of one type from another. It also provides a capability to route specific log types to their respective log handlers as in those of the ‘63×’ designation of FIG. 7. Further support may be provided in the form of log filtering allowing logs to be selected based on a particular configuration specification. (see FIG. 12 for an example)  
         [0061]    CommonLogHandlerlmpl  624  implements interfaces of CommonLogHandlerAPI  616  forming the basis for the log handlers that have been extended to handle the specific logs of the various types supported by the service. Examples of log types typically supported are shown in FIG. 7 designated as ‘63 ×’.  
         [0062]    CommonLogMessageRendererAPI  618  provides the interfaces for the various specific log renderers. A log renderer is typically responsible for the serialization of the log message body between the object log structure and the XML format of the common or unified log.  
         [0063]    Exemplary software of an embodiment may have AuditLogMessageRenderer  626  implemented as an extension of the interfaces of CommonLogMessageRendererAPI  618 . Each different type of log would require a similar implementation of an associated log renderer, such as AuditLogMessageRenderer  626  with CommonLogMessageRendererAPI  618  being common across the renderers.  
         [0064]    With reference to FIG. 8 a common logging service object model is presented. CommonLog  600  is presented again as in FIG. 7, containing the necessary high level interfaces for the service. CommonLoginfo  656  implements the interfaces of CommonLog  610 , containing the log header and body information for a particular log.  
         [0065]    LogHeader  650  is a set of interfaces defining the processing of the log header information. The supported components of the specific log will be defined in this object. LogHeaderlnfo  658  implements the interfaces of LogHeader  650  containing the various components of the specific supported log header.  
         [0066]    LogMessage  652  is a set of interfaces designed to acquire log message components from a target log. LogMessagelnfo  660  implements the interfaces of LogMessage  652  allowing extensions to accommodate the various elements of the log message body.  
         [0067]    AuditLogMessage  654  is an exemplary implementation of a set of interfaces in support of an audit type log within the unified logging services as defined. AuditLogMessagelnfo  662  is implemented as a child of AuditLogMessage  654  providing necessary extensions to describe the various elements specific to the audit log message body.  
         [0068]    [0068]FIG. 9 details exemplary code shown using XML to define a typical association of a log type to an internal processing form as used in a preferred embodiment of a unified logging service.  
         [0069]    Each type of logs in the common or unified logging service is defined with the following attributes:  
         [0070]    Name: log type name  
         [0071]    Renderer: the implementation class of log renderer associated with the type of log  
         [0072]    Handlers: the list of log handlers that are registered to receive this type of logs  
         [0073]    Handler name: the name of the log handler  
         [0074]    Handler enable: the state of the log handler. Set this attribute to false to disable the log handler for the type of log.  
         [0075]    The log system type differentiates the type of log systems from which the log files originate. Typical logs systems may be as follows, but not limited to, metering service (logs from a metering service through a metering event adapter), system web service (logs originating from a web service either directly or indirectly invoking the common logging web service interface) and application adapter (logs originating from hosted applications are sent via an application adapter.  
         [0076]    The log type itself differentiates the nature or purpose of the log. Typical log types are, but not limited to, billing, audit, message, and trace.  
         [0077]    [0077]FIG. 10 details exemplary code showing a sample interface invoking the common logging service through the use of a web service interface to create a log. Provision of web services is well known and will not be detailed further.  
         [0078]    [0078]FIG. 11 is a sample of exemplary code used in an adapter of an embodiment of the common logging or unified logging service. Further is included a sample portion detailing specific inclusion of audit log adaptation. The adapter builds the common format header portion of the converted log file and the log unique message portion particular to the audit log type.  
         [0079]    [0079]FIG. 12 is another sample of exemplary code of an embodiment of the unified logging service, but in this case it pertains to the log configuration information as used by the log processor component. The first portion of code deals with the loading of the log handler. Next the relationship between the log type and the log handler is made (in this example billing, audit), and then filtering information is provided. The filtering information is provided in the form of exclusionary information, that is the noted conditions will cause logs meeting those conditions to be not processed by the unified logging service.  
         [0080]    In the code sample provided three log handlers are registered to the unified logging service; LogBilling Handler, LogConsoleHandler and LogDBHandler.  
         [0081]    Each of the log types is further mapped to an appropriate log handler in a simple format such as that illustrated by the following table:  
                                           Log Type   LogConsolehandler   LogBillingHandler   LogDBHandler                   Billing   X   X   X       Audit   X   X                  
 
         [0082]    Further, in the example for filtering, any logs having the following format would be filtered out of the processing; a server name of “abc.xzy.com” or “pqr.xyz.com”, or a log system type of “Metering Service” or WAS JRas”, or log type of “Unknown”, or “Billing” or “trace”.  
         [0083]    An application need not be a database management system, it may be a mail system managing a collection of mail files exploiting flat file or hierarchical file means. Typically an application is one that manages its own storage allocation and the OS file system is unaware of application structure inherent within the application managed data. All elements of the invention may reside on one machine or many. The network may or may not exist but communication among the components of the invention and between the invention and the applications is presumed to be evident. Application data may be accessed by programmatic means in conjunction with the application or unknown to the application, as a case may be made for efficiency. The agent of the invention may also provide forms of summarization and/or filtering on the data collected from the application prior to send such data to the server.  
         [0084]    The service may be made fully symmetrical by implementing adapter and renderer function within the log consumer or receiving node to have the same capability as the sending node or log client. Additionally the log adapter and log renderer function may be implemented solely on the server portion to allow for more lightweight client support.  
         [0085]    Although a preferred embodiment using XML as a form of describing log objects for converting to the common format has been shown it may be appreciated that other descriptive languages may be used in place. Additionally the common format is not important other than it must be capable of containing all types of desired log information.  
         [0086]    Although publish and subscribe style of message exchange has been shown in a preferred embodiment it may be appreciated that direct addressing may also be used. In direct addressing the sending node knows the target to receiving node and need not use the publish or subscribe capability nor additional directory services.  
         [0087]    It should be understood that the present invention contains one or more software systems. Software systems that operate in a processor or network to carry the functions described above. In this context, a software system is a collection of one or more executable software programs, and one or more storage areas (for example, RAM, ROM, cache, disk, flash memory, compact flash, EEPROM, PCMCIA, CD-ROM, CD-RW, DVD, DVD-RW, Server=s Memory etc.) In general terms, a software system should be understood to comprise a fully functional software embodiment of a function or collection of functions, which can be run on a processor or network to provide new function to that processing system or network.  
         [0088]    It should be understood in the context of the present invention that delineations between software systems are representative of the preferred implementation. However, the present invention may be implemented using any combination or separation of software or hardware systems.  
         [0089]    While the invention has been described in detail herein in accord with certain preferred embodiments thereof, modifications and changes therein may be effected by those skilled in the art. Accordingly, it is intended by the appended claims to cover all such modifications and changes as fall within the true spirit and scope of the invention.