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: [email protected]
For additional commands, e-mail: [email protected]
