Apache Qpid : Status Update Design - Logging Configuration
This page last changed on Jul 01, 2009 by ritchiem.
OverviewTo better address this and to allow us to more eaily move between logging implementations an abstraction is recommended. This approach will allow the simplification of the logic around determining if logging should be performed in the main code base. For example a Binding logging statement can be controlled via Exchange and Queue, each of which may be limited to s specific instance. Logging ControlInitialy the use of a properties file will be used to enable/disable various logging options. The property value will be one of a set list. This will help avoid the ambigious parsing of Java Properties files. Control File Structure # Comment Line <logger> = <value [OFF|TRACE|DEBUG|INFO|WARN|ERROR|FATAL|ALL]> The values for the <logger> are based on navigation through the hierarchy. Hierarchy RefinementRefining the hierarchy presented in the high level design such that we can implement it in terms of an easily parseable structure for use as the <logger> values. qpid ─┬─ broker │ │ │ ┌── [<username>] ───┐ │ ├─ [<ip/hostname>] ─┤ ├─ connection ─┴───── [<id>] ──────┴─ channel ── [<id>] ──────┬── subscription ── [<id>] │ │ └─ virtualHost ── <name> ─┐ ┌─ binding │ │ │ │ ├─ exchange ── <name> ─┤ │ │ │ │ ├─ queue ── <name> ────┴────────────┘ │ ├─ plugin ── <name> │ └─ messagestore This hierachy has a number of paths which make it more difficult to process.
It is these difficulties that make it best to provide an abstraction layer so that a simple interface can be used at the site of the logging. These difficulties can be distilled to:
Procsessing values for all values of '<name>'To ensure that the logger path is processable the '<name>' must be present to make it easier to understand when we have an identifier or a <name> value. i.e. Is this logging all events for exchanges on Virtualhost called 'queue' or logging all exchange events that occur in relatation to queues. qpid.virtualhost.queue.exchange = INFO By introducing the use of the '*' wild card we can make these two situations easier to read: qpid.virtualhost.queue.exchange = INFO qpid.virtualhost.*.queue.exchange = INFO The '*' can then be used at the end of the logger to ensure all logging from this point in the hierarchy will be logged, rather than just events to the specified entity. Overlapping configuration resolutionThe loops in the graph will be handled by the logger configurator so that only one log entry is created for each event, even if there are multiple matching entries in the configuration. For example, the follow two entries are equivalent and will both enable all loging for bindings. If the user wishes to log all binding operations then only one entry is necessary but the presence of both should not cause duplicate messages. Multiple equivalent entries doesn't result in multiple logging qpid.virtualhost.*.exchange.*.binding = INFO qpid.virtualhost.*.queue.*.binding = INFO The overlapping of configuration such as logging all details of connection from user guest and from ip 127.0.0.1 will not result in a duplicated logging if guest connects from 127.0.0.1. Overlapping configuration doesn't result in multiple logging qpid.connection.guest.* = INFO qpid.connection.<127.0.0.1>.* = INFO Presentation of entities with multiple pathsEach entitiy will have a prescribed log format which will be designed to take into consideration its place in the hierarchy, see Logging Format Design for further details. Log Configuration processingThe configuration will be processed top-to-bottom. This allows for defaults to be set and specific cases to have further logging enabled. The example below enables INFO logging for all events and specifically adds DEBUG logging for all activity related to the user 'guest'. Example Control File qpid.* = INFO qpid.connection.guest,* = DEBUG |
![]() |
Document generated by Confluence on May 26, 2010 10:32 |