[
https://issues.apache.org/jira/browse/QPID-3902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13293205#comment-13293205
]
Rajith Attapattu edited comment on QPID-3902 at 6/12/12 12:07 AM:
------------------------------------------------------------------
(*) I echo Justin's comment about Network and Protocol instead of IO and AMQP.
(*) For Protocol we should really have something like
[Protocol][{PROTOCOL_NAME}-{VERSION}]... bcos we will mostly likely end up with
supporting multiple protocol versions in the same broker. So it will be very
useful to filter by a specific version. Ex. [Protocol][AMQP-0-10]
(*) I also think that BROKER is too broad a category to be really useful. A lot
of things are lumped in there. I'm not sure if the following is possible , but
if you can have more granular categories for BROKER it might be more useful.
Ex. QUEUEING -- for logs related in putting/pulling messages from queues, flow
control etc..
ROUTING -- logs related to routing messages (would be more relevant going
forward)
SUBSCRIPTION -- logs related to subscription state (capacity, acks ..etc)
(*) Another general category could be CONFIGURATION. Often times customers
wants to see logs to verify if they've got the config right. It's really a
separate category from any of the above. We currently don't have much here.
was (Author: rajith):
(*) I echo Justin's comment about Network and Protocol instead of IO and
AMQP.
(*) For Protocol we should really have something like [Protocol][AMQP-0-10]...
bcos we will mostly likely end up with supporting multiple protocol versions in
the same broker. So it will be very useful to filter by a specific version.
(*) I also think that BROKER is too broad a category to be really useful. A lot
of things are lumped in there. I'm not sure if the following is possible , but
if you can have more granular categories for BROKER it might be more useful.
Ex. QUEUEING -- for logs related in putting/pulling messages from queues, flow
control etc..
ROUTING -- logs related to routing messages (would be more relevant going
forward)
SUBSCRIPTION -- logs related to subscription state (capacity, acks ..etc)
(*) Another general category could be CONFIGURATION. Often times customers
wants to see logs to verify if they've got the config right. It's really a
separate category from any of the above. We currently don't have much here.
> Add formal message categories to C++ Broker log messages
> --------------------------------------------------------
>
> Key: QPID-3902
> URL: https://issues.apache.org/jira/browse/QPID-3902
> Project: Qpid
> Issue Type: Improvement
> Reporter: Chuck Rolke
> Attachments: qpid-log-src-tabbed2.txt
>
>
> h3. This is a proposal to add log categories to C++ Broker log messages.
> h4. Problem Statement
> There are difficulties working with C++ Broker logging when appplying a log
> filter criterion. What precise FILTERTEXT can a user specify for:
> {noformat}
> --log-enable debug+:FILTERTEXT
> {noformat}
> Even after the fix from QPID-3891 it is not intuitive what to specify for a
> FILTERTEXT and any useful filter requires detailed knowledge of the source
> code.
> h4. Proposal
> A log category is a high-level classification of the nature of the logged
> event that is not tied to a particular source module or code function name.
> This log category would become the target for FILTERTEXT log filters.
> The following list is the proposed log category definition. Each log category
> name is followed by a list of source code directory names that would
> generally produce logs using that log category.
> ||Category||Source code directory||
> |Security| acl ssl gssapi sasl cyrus|
> |Broker | broker|
> |Management| agent console qmf|
> |Amqp| amqp_0_10 framing|
> |System| log sys types xml thread mutex fork pipe time ...|
> |HA| cluster ha replication|
> |Messaging| messaging client|
> |Store| store|
> |IO| tcp rdma AsynchIO socket epoll|
> |Test| |
> |Unspecified| |
> There is no strict rule that a module produce only log entries of a specific
> category.
> The category would be inserted into each log message after the time of day
> but before the message text.
> {noformat}
> 2012-03-06 16:55:38 [Management] SEND PackageInd
> package=org.apache.qpid.broker to=schema.package
> {noformat}
> A user could then filter log messages by using the category names:
> {noformat}
> --log-enable debug+:Management
> {noformat}
> This scheme would have a number of benefits:
> 1. On a per-message basis the filter comparisons would be using enumeration
> values and not strings.
> 2. The feature could be documented sensibly.
> 3. Log files would be easier to interpret manually or by event management
> systems.
> The classifications could be phased in gradually. The current
> QPID_LOG(LEVEL, MESSAGE) would produce [Unspecfied] events while the new
> QPID_LOG_CAT(LEVEL, CATEGORY, MESSAGE) would produce events using an actual
> category.
> Similar additions are made for the QPID_MSG entries.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
