qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: Message auditing in C++ broker
Date Wed, 12 Mar 2014 17:30:59 GMT
On 03/12/2014 05:10 PM, Jakub Scholz wrote:
>>
>>
>> I assume the audit log doesn't need to be synced in anyway, i.e. if the
>> machine the broker is on has a sudden power failure, its accepted that the
>> activity actually recorded on disk may not be fully up to date?
>>
>>
> Yes, I assume it would be acceptable to lose some minor parts of
> information in case of rare situations like power failure.

The key for some other mechanism for recoding data would be (a) as you 
say that it is very fast, even from concurrent threads and (b) can 
handle large amounts of data with either manual deletion of old data or 
some configuration to hold N days worth whatever.

>> Would the queues being audited generally be durable or might they also be
>> transient? (and what about the persistence of messages)?
>>
>>
> In most cases persistent messages in durable queues. Having the auditing
> for non-persistent messages / non-durable queues might be nice, but not
> 100% necessary. Such messages are unreliable anyway, so when they get lost
> it is not an unexpected event - therefore one might not need an extensive
> audit trail to see all the details about them.

The journal obviously already records the enqueues and dequeues, it just 
doesn't keep them around. One option might be to have a modified 
journal/store that kept the data for longer in some way or moved it into 
some other repository before removing it from the journals themselves.

Might overcomplicate the store, just observing that there is some overlap.

>> Would tcpdump be a possible route? I.e. capture all the AMQP data in and
>> out of the broker, and perhaps then asynchronously process that into a more
>> useful form in a database of some kind?
>>
>>
>>
> I don't think so. Large part of the communication is SSL encrypted - I
> don't think it is possible to decrypt the stream without having the private
> keys from both sides. Or is it? I actually never tried it.

Good point!


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message