Linux Event Logging -- Candidates for future releases

Note:  If you have comments or suggestions for additional new features, please send e-mail to the mailing list evlog-developers@lists.sourceforge.net.
This list is not intended to be in order of priority, although (1) our employer and (2) those contributing code or documentation, or helping to resolve bugs, do have influence on what we work on, and when we work on it.
---the Event Logging Team

1. Kernel patches for the 2.5 kernel to exploit new logging interfaces, like dev_printk() and similar follow-on logging macros. Specifically, implement printkat(), the kernel equivalent of syslogat() from user-space. printkat() will be patched inside dev_printk(), and other follow-on logging macros, so that additional details from the device struct can be captured for event logging, attributes can be named, and information for generating formatting templates with the evlgentmpls command can be stored into the .log section in kernel .o files, all without additional code changes in device drivers (other than switching from printk() to dev_printk()).
   A posting on LKML explains the overall scheme.
   Please note that the actual macro definition in the latest version of the 2.5 kernel passes a pointer to the device structure, which is different than the macros shown in the LKML posting.It now looks like this:
   
   

    #define dev_printk(level, dev, format, arg...)  \
                       printk(level "%s %s: " format ,  \
                       (dev)->driver->name ,  \
                       (dev)->bus_id, ## arg)
   

   
   
2. A utility will be needed for (1) identifying formatting template changes between kernel versions, application versions, etc. and (2) assisting with updating the template and template database.
3. An Event Log Analysis (ELA) client that registers via event notification for particular events, performs analysis based on those events, and takes the appropriate specified action. Although, the evlnotify command provides a general capability, the ELA client would do much more. For example:
   • Keep a history of events over a time interval, and initiate some action when a threshold is exceeded
   • search through the event log for related events that occurred previously
   • invoke specific diagnostic routines for possibly collecting more event data
   • examine the system configuration to determine the impact of an event on system availability and performance
   • alert a Sys Admin via system console, SNMP alert, CIM event notification, etc.
4. SNMP subagent and MIB for event logging.
5. A CIM-provider for event logging.
6. Enhanced support for remote event forwarding:
   • Mixed-architecture environments. (currently all hosts must be the same architecture)
   • Encryption and possibly other security enhancements
7. Verbosity control in the kernel--where events with severity less than the specified logging level will be discarded by the kernel event logging functions, and not written into kernel buffer.
8. Capability to extract and format the kernel event buffer from a system dump.
9. Add capability to evlview command (and underlying functions) to properly format and display event records from an event log generated on another system with a different architecture.
10. Kernel symbol resolution for event records with log_format besides POSIX_LOG_PRINTF (which is already supported).
11. Mechanism for dealing with (restarting) failed event logging daemon(s).
12. Compression of event records / event log.
13. "configurable" event record headers where some, but not all fields, are logged (to reduce record size).
14. Option to configure kernel event buffer to save most recent event, or oldest event (current behavior) when the buffer overflows.
15. Synchronous notification at the logging API level, allowing a drastic action to be initiated immediately in response to a critical situation. For example, halting the system when a breach of security is detected, or on buffer overflow.
16. Threads-based event notification, to make evlog fully draft POSIX-compliant.