Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Ability to produce a broker wide log which may or may not include the activity of virtual hosts
  2. Ability to produce separate logs for each virtualhost
  3. Ability to assign/change the level of any logger at runtime.  It will be possible to assign the logging level on a logger related to a class e.g. o.a.q.X or hierarchy e.g. o.a.q.
  4. Logger levels can be assigned durably or non-durable.  Those durable will survive a restart.
  5. Ability to assign different logger levels for different virtual hosts.
  6. Ability to logs to different destinations, e.g.
    1. to a plain file on the filesystem
    2. to a stream
    3. to a bounded buffer
  7. Logging configuration will be persisted to the Broker/Virtualhost configuration stores.  As such in the HA use-case, the same logging configuration will be applied to all nodes within a HA group.
  8. Ability to configure file rolling and compression
  9. Ability to configure logging and view logs from Web Management Console, REST API and later AMQP management.
  10. Ability to limit who may configure logging or who may view logs via the Management interfaces.

Do we want the ability to view a log file that is on disk from Management, or is the ability to view the log messages within the bounded buffer recorder sufficient?

High Level Design

 

The Broker and Virtualhost objects will become objects that are responsible for the production of logging. By the production of logging logs.  By this we mean:

  • the production of a log file
,
  • to disk or logging to a stream
and
  • the collection of recent logs for viewing via management

Both Broker and Virtualhost have have LogFilter children.  These define the what logging statements .  Both will support one or more LogFilters that will define what will appear in the log. 

Proposed Configure Object Model

Gliffy Diagram
nameConfigModelShowingProposedLoggingObjects

Broker and Virtualhost changes

 

LogFilter

Associates a logger with a logging level.

When considering whether a logging event should be written, the implementation will check for a LogFilter with a matching logger, if it exists the level of the log event is compared against the level of the filter.  If the level of the event is higher or equal to that of the level filter, the logging event will be written.  If there is no matching log filter, the implementation will check for a filter for the logger's parent and then make the same determination.  If this fails to find a filter, this will continue until the root it reached.  If this occurs, the determination will be made against the level associated with the Broker or Virtualhost itself.

 

Gliffy Diagram
LoggingObjectHierarchy
nameLogLevel

 

 

LogRecorders

The types of LogRecorder will be:

FileLogRecorder

A type that logs to a file on disk supporting rolling (time or sized based) and compression.  It should also accept a umask allowing the file permissions of logs to be controlled (in POSIX environments).

StreamRecorder

Sends a log file to standard out or standard error.  Maybe a boolean option flush?

BoundedBufferRecorder

Logs to a bounded buffer.  

Might be useful to define other recorder types to support testing.

LogFilters

Need LogFilters to have the ability to express that certain loggers should be logger at a certain level e.g. o.a.qpid at level DEBUG.  Also need a way to express whether a virtual hosts messages should be included or not?