Re: Event logging vs enhancing printk

[Francois-Xavier Kowalski]

Hello,

Michel Dagenais <[e-mail]> writes

>> People want to be able to get better debug information, with more detail
>> than is currently possible with printk, hence the Event logging project.
>
>I would like to emphasize that point; logging and tracing is of prime 
>importance in several areas:
>
>- Telecom and Security. Logging and auditing is a requirement in Telecom 
>  applications. It is for instance one of the important features of the 
>  Distributed Security Infrastructure proposed by Ericsson Research and to 
>  be presented in a couple of months at the Ottawa Linux Symposium.
>  The OSDL "Carrier Grade Linux" is certainly no different.
>

I am currently working in the Telecom area (signalling), on systems that 
usually process several tenths of thousands of telephone calls per 
second, during years. So I am the kind of guy interrested in having 
enhancements to the Linux logging sub-systems, to:

   1. Make my life easier when something goes wrong on my user's sites &
      I am supposed to gather the information from the logs.
   2. Make my user's life easier, to detect that something is going
      wrong on my machines (among hunderds of other ones), so that he
      can (try to) join me.
   3. Make my developer's life easier, not forcing me to code yet
      another log parser dedicated to one system & use open standard
      instead.
   4. Not make my Linux desktop system an intensive disk & CPU consume r
      for logging-only purpose (this is more a personal view than a
      professional constraint... :-)

I have been following the work done by evlog team since a few monthes 
now, so I can say now - as an evlog user - that it provides support for 
every requirements listed above, the following ways:

    * Evlog can be configured to flag log messages as part of a
      functional area (facilty) so that they can be logged in separated
      log files, regardless of the source of the log: kernel or
      userland. Take the case of a telecom protocol stack running partly
      in kernel space (device driver and/or protocol module) and partly
      in userland (application). Evlog can be configured a way so that
      logs coming from the telecom functional area are consolidated at
      the same place. If something goes wrong in kernel space, the logs
      of the whole telecom sub-system are placed together showing
      (mostly) the appropriated order of failure. This considerably
      helps troubleshooting a failure (my trouble-shooting life).
    *  From the telecom network supervision/management perspective (my
      user's life), the ability of evlog to have registered call-backs
      (in user-land) on specified (configured) events permits to:
          o Take automatic corrective actions if possible
          o Raise network alarms, so that the operators can log on the
            system & trouble-shoot it (or at least apply a corrective
            procedure & call a help-desk)
    * Evlog is a proposed standard to POSIX. I do hope that it will be
      accepted (as well as in the LSB, but this is probably another
      story...), so that the telecom stack & network supervision work
      can be re-used from one system to another.
    * Evlog can be totally optimized away at kernel configuration time
      (like any other CONFIG_XXX component, after all), or have no
      noticeable no cost when compiled-in & powered-off. (my day-to-day
      Linux desktop user life).

For the reasons listed above, I strongly support integrating evlog in 
the Linux kernel.

FiX

-- 
Francois-Xavier "FiX" KOWALSKI     /_ __    Tel: [phone]
Telecom Infrastructure Division   / //_/    Fax: [phone]
SigTech eXpert                      /       HP Telnet: 779-6327
                               i n v e n t  http://www.hp.com/go/opencall