[ https://issues.apache.org/jira/browse/QPID-5619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Pavel Moravec updated QPID-5619: -------------------------------- Description: There is a reasonable request to have message enqueue/dequeue audited. It can help troubleshooting or monitoring situations when the broker is suspected from discarding a message that was sent to it but never received by a consumer. Implementation options as to be discussed in qpid users mailing list: 1) Key feature: a) where to store/send the information about new message enqueue/dequeue? - store it in a configurable log-file (per queue? per broker?) - problem with format of binary data there - amend/modify replicated queues for this purpose - though replicated queues are designed not to replicate messages that are dequeued before they have been replicated - generate QMF event to be sent to "qmf.default.topic/agent.ind.event.org_apache_qpid_broker.<queue_name>.audit.<enqueue|dequeue>" topic - note this would have to change qpid.subject to route the message properly - have dedicated audit exchange for this purpose (of topic type, I expect) - again, qpid.subject would have to be changed b) how to trigger message auditing: - via QueueObserver (thanks Gordon for idea) 2) Options of auditing: a) audit enqueue+dequeue events only? or also acquire, release, reject? b) it should be possible to track only one from enqueue | dequeue | acquire events, or all of them c) event/message should contain: - timestamp - original message (or just its header? or configurable?) - type of event (enqueue/dequeue/..) - identification of consumer acquiring/dequeueing the message (and also producer?) 3) Provisioning/managing auditing: a) have the possibility to turn on/off auditing per queue (via QMF) b) have some x-declare arguments for the auditing when declaring the queue? was: There is a reasonable request to have message enqueue/dequeue audited. It can help troubleshooting or monitoring situations when the broker is suspected from discarding a message that was sent to it but never received by a consumer. Implementation options as to be discussed in qpid users mailing list: 1) Key feature: - where to store/send the information about new message enqueue/dequeue? - store it in a configurable log-file (per queue? per broker?) - problem with format of binary data there - amend/modify replicated queues for this purpose - though replicated queues are designed not to replicate messages that are dequeued before they have been replicated - generate QMF event to be sent to "qmf.default.topic/agent.ind.event.org_apache_qpid_broker.<queue_name>.audit.<enqueue|dequeue>" topic - note this would have to change qpid.subject to route the message properly - have dedicated audit exchange for this purpose (of topic type, I expect) - again, qpid.subject would have to be changed - how to trigger message auditing: - via QueueObserver (thanks Gordon for idea) 2) Options of auditing: - audit enqueue+dequeue events only? or also acquire, release, reject? - it should be possible to track only one from [enqueue|dequeue|acquire] events, or all of them - event/message should contain: - timestamp - original message (or just its header? or configurable?) - type of event (enqueue/dequeue/..) - identification of consumer acquiring/dequeueing the message (and also producer?) 3) Provisioning/managing auditing: - have the possibility to turn on/off auditing per queue (via QMF) - have some x-declare arguments for the auditing when declaring the queue? > [C++ broker] Add message auditing > --------------------------------- > > Key: QPID-5619 > URL: https://issues.apache.org/jira/browse/QPID-5619 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker > Affects Versions: 0.24 > Reporter: Pavel Moravec > Labels: features > > There is a reasonable request to have message enqueue/dequeue audited. It can > help troubleshooting or monitoring situations when the broker is suspected > from discarding a message that was sent to it but never received by a > consumer. > Implementation options as to be discussed in qpid users mailing list: > 1) Key feature: > a) where to store/send the information about new message enqueue/dequeue? > - store it in a configurable log-file (per queue? per broker?) - problem > with format of binary data there > - amend/modify replicated queues for this purpose - though replicated > queues are designed not to replicate messages that are dequeued before they > have been replicated > - generate QMF event to be sent to > "qmf.default.topic/agent.ind.event.org_apache_qpid_broker.<queue_name>.audit.<enqueue|dequeue>" > topic - note this would have to change qpid.subject to route the message > properly > - have dedicated audit exchange for this purpose (of topic type, I expect) > - again, qpid.subject would have to be changed > b) how to trigger message auditing: > - via QueueObserver (thanks Gordon for idea) > 2) Options of auditing: > a) audit enqueue+dequeue events only? or also acquire, release, reject? > b) it should be possible to track only one from enqueue | dequeue | > acquire events, or all of them > c) event/message should contain: > - timestamp > - original message (or just its header? or configurable?) > - type of event (enqueue/dequeue/..) > - identification of consumer acquiring/dequeueing the message (and also > producer?) > 3) Provisioning/managing auditing: > a) have the possibility to turn on/off auditing per queue (via QMF) > b) have some x-declare arguments for the auditing when declaring the queue? -- This message was sent by Atlassian JIRA (v6.2#6252) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org