|
Boost : |
From: Andrey Semashev (andysem_at_[hidden])
Date: 2007-04-06 16:38:27
Hello Scott,
Friday, April 6, 2007, 2:08:58 AM, you wrote:
> Hi,
> What requirements are ultimately targeted by this thread? I have had
> a variety of software requirements that I would broadly label as "logging"
> but am unclear as to whether those requirements might be met by
> software arising here, e.g.
> * Testing-only log for troublesome function, removed prior to release
> Free-form text, i.e. fixed content interspersed with runtime values
> No time stamp needed, sequence significant
> All output directed to a named system file
> Each invocation of the function overwrites the system file
> * Capture of high-speed events, logging unexpected sequences
> Fixed binary format, a list of "machine state" and "detected event"
> pairs
> Each pair representing an event with no appropriate transition
> Time stamped
> Output written to a block of shared memory
> * Audit trail of calls made to a set of stored procedures
> XML format, incl time, procedure name and parameter values
> Output directed to a series of files with names reflecting a connected
> user and session id
> * Audit trail for customer support and system adminstration
> Extended log file format from W3C (WD-logfile-960323)
> Output sent asynchronously to an in-process queue
> Forwarded from the in-process queue to a configured network service
> Network service directs received information to a set of files managed
> by an in-house library
> A dedicated viewing and filtering tool
> Export of selected time slices to customers for analysis with 3rd party
> tools
> Is Boost.Log interested in such circumstances?
Thanks a lot for your input in describing your use cases.
Currently the discussion is about the collecting and storing part of
the library, no external log viewing, filtering or extracting tools
are considered for now. Although, I think, some basic tool for
reading, e.g. binary logs may be provided as an example.
As for the discussed part of the lib, I'd appreciate if you describe
the following aspects:
- The common ways of collecting data from the application. Loggers?
Channels? Maybe some other sources of logging records?
- The ways of storing logs (don't get this literally as "storing"
somewhere - this may also include things like redirecting it to some
other subsystems, on-the-fly analysis and other). What common formats
of stored logs do you use? Do you use log splitting by size or time?
- What common types of attributes do you use?
- Do you involve log filtering?
- Maybe some fresh ideas or proposals that were not highlighted in the
thread?
All these ideas and requirements may be noted in the Wiki:
-- Best regards, Andrey mailto:andysem_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk