Hi Pavel, This is definitely a feature I would be interested in :-)
Some time ago, I had a brief look at how such feature could be implemented. My ideas were going around the *Observer interfaces (not only QueueObserver, but also ConnectionObserver etc.) which seem to be able to capture most of the important information, not only message enqueues and dequeues. It seemed to me that it might be possible to use the observers to receive information about new connections, sessions, queues, messages etc. I know the original issue was mainly about message enqueue and dequeues, but adding information about connections, sessions and queue creation would create much more complete picture in the audit file. Although I guess to some extent that can be already now captured by the object life cycle tracking in the regular log files, which can be probably used to complement the message audits. ad 1a) Based on my experience with auditing in our internal software applications, I would store the messages in whatever way is considered to be the fastest for writing (for example as a structures in a binary file?) and provide some tools/API for analysis / parsing of the audit file. Providing the audit information as AMQP stream (in a form of replicated queue or as QMF messages) seems like something what would create unnecessary overhead to the task. For example in my situation, I probably will not be able to analyse the messages in realtime anyway due to security reasons. So I would still end up consuming such stream in some client and putting it into a file for later analysis. Storing it directly into a file would also avoid any problems with modifying parts of the messages. ad 1b) As mentioned before, I would probably capture everything possible ... connections, sessions, queue creation/deletion, etc. But even only the message would do :-). It would be also great if we can audit messages dropped by exchange, but I guess that can be worked around by a small ring queue and alternate exchange. ad 2a) Clearly, enqueue and dequeue are the main events, but everything else might be also of interest. It would be also great if we can capture delivery in browse mode, where I guess acquire/release is not triggered explicitely. ad 2b) If you assign some unique ID to a message in enqueue, the dequeue/acquire/release/reject probably can contain only a reference to this ID instead of complete message. That might make auditing of this additional information quite cheap, so maybe we do not need configuration for this in such case. ad 2c) Apart from the obvious timestamp, we also need some sort of link to the queue where the messages was enqueued/dequeued. The message versus header might be configurable. In some situation, the header is sufficient to identify the message content in other source (i.e. producer log) and in such case it would be unnecessary to store the content. But that doesn't always apply - therefore configuration would make sense. Also, in my case the producer/consumer username is not so interesting (as I can in most cases tell that from the queue name). But a possibility to link the message to a specific connection/session (especially for consumer) would be great. ad 3a) For me, that would not be necessary - I would probably have the auditing switched on all the time. ad 3b) That is a good question. X-declare might be easily missed at a temporary queues created by third party entities which forgot to specify it. Also I'm not sure how easily would x-declare/queue attribute work with non-Qpid AMQP 1.0 clients. On the other hand, I think there should be some possibility to say what should be audited and what should not - for example the QMF messages delivered to some monitoring utilities probably don't need to be audited. So from that perspective, queue attribute would be useful. Thanks & Regards Jakub On Mon, Mar 10, 2014 at 10:27 AM, Pavel Moravec <[email protected]> wrote: > Hi all, > I raised QPID-5619 to implement message auditing in C++ broker. As a new > feature with more options of implementation and mainly configuration, I > would like to discuss it first. Quoting the JIRA for discussion: > > > > 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? > > > Thanks in advance for your feedback. > > Kind regards, > Pavel > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
