qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakub Scholz <ja...@scholz.cz>
Subject Re: Message auditing in C++ broker
Date Tue, 11 Mar 2014 08:33:16 GMT
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

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

On Mon, Mar 10, 2014 at 10:27 AM, Pavel Moravec <pmoravec@redhat.com> 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: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message