[jira] [Updated] (QPID-5619) [C++ broker] Add message auditing

["Pavel Moravec (JIRA)" <ji...@apache.org>]

     [ 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-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org