2:31 a.m.
Hi John
Thanks for the information - at the moment I am unclear on the requirements, so I think we
need to revisit them. However if an audit approach is required this sounds like a good
start.
Possibly everyone has a different understanding of what was discussed at the F2F, but my
interpretation at the time was we wanted an event store for storing source and derived
events, removing the need for each component to worry about storing its own. However after
the discussion on this thread with Lucas and Juraci, about decisions taken in the
architecture session, it seems like each component would need to maintain its own
information - to allow it to be used standalone independent of the bus.
So before doing too much work on this audit component of yours, I think we need to clarify
the use case.
One possibility is that this new 'audit' component could be used to persist
derived events that are not retained by their source components. So for example, inventory
generates notifications when changes occur.
However, metrics and alerts (I believe) persist all of their own 'derived' events
- i.e. computed metrics are stored along side raw metrics, and the alerts engine will
persist the generated alerts? So not sure these components will require any further events
recorded.
Regards
Gary
----- Original Message -----
I briefly mentioned this in the F2F - a couple months ago I wrote an
"audit"
subsystem component prototype that basically does what we mentioned we want.
The idea for this was it is a generic audit log - all other components would
use it to log audit events (like "user failed to log in due to bad password"
or "metric exceeded SLA" or whatever). We can obviously extend this to be
ANY event, not just audit trails.
For sure this is gonna miss some things we need, but essentially, this
"audit" subsystem is simply a way to store "events" in a backend data
store.
It is what you guys have been talking about in this thread (I think, unless
I didn't understand).
Here's the code:
https://github.com/jmazzitelli/hawkular-audit
Just replace the word "Audit" with the word "Event" :) Here's
what it does:
1) listens to a topic - anyone can send an "Audit Record" which consists of a
timestamp (when it happened), a subsystem (who it happened to), a message
string (what happened), and a Map<String, String> of details (more details
on what happened).
Think of a Subsystem as "Business Transaction Manager" or "Metrics"
or
"Alerts" or whatever we want. The Map can be anything - say, keyed on
"transactionId" with the value the actual tx id. That's just an idea. We
will probably extend that data structure to include more things if the above
isn't enough. The point is, the "Audit Record" fully describes the event.
Here's the AuditRecord (it is a JSON-encoded POJO):
https://github.com/jmazzitelli/hawkular-audit/blob/master/hawkular-audit-...
2) once the message is received, it is stored using a storage mechanism.
Right now, it supports storing it in a log file (org.jboss.logging) or a
RDBMS (when I was testing, I was using H2). We'll want a Cassandra
implementation.
That's it. It is a very small component. It doesn't have a REST endpoint
today, but we'll just add that like all our other components. It also has no
notion of tenant Id, we'll need to add that too. Since this probably isn't
going to be a component that must live standalone (like metrics) we won't
have to play games with building two assemblies. We'll just always have a
bus dependency on this component.
I was going to slap a REST endpoint on here, and rename it from "audit" to
"event" but I think I'm getting sick and jetlag is killing me :) I'll
try to
do something this week. Unless someone wants to take what I have and run
with it.
John Mazz
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev