1 Reply Latest reply on Dec 23, 2014 3:10 PM by mazz

    prototype of a rhq next server component that lives on the bus

    mazz Master

      I built on my original rhq-audit stuff to come up with a prototype server component that lives on the bus to process and store audit messages.

       

      The purpose was to come up with some mvn structure to see how easy it would be to assembly a running container that has the message framework available to a server component WAR or EAR.

       

      Here's how it works:

       

      1) you first build rhq-next-agent-distro - this gives you the infrastructure (a Wildfly container, a message broker and the wildfly extension that configures it, a REST interface to the broker, rhq-msg client API, a resource adapter so you can use things like MDBs in your own app to access the message broker, and the rhq.next agent extension which lets you deploy your WAR or EAR from its module directory (this is to help support patching in the future).

       

      2) build rhq-audit which will essentially install its WAR into the rhq next agent container.

       

      3) run the wildfly container buit by rhq-audit-distro

       

      At this point, you have a audit server component listening to the bus. Any audit messages sent to it will be stored in the H2 database that is running in the container (the one that comes with Wildfly. Again, just a prototype, we can put this anywhere, but the H2 datbase was a nice out of box feature that I used.

       

      For example, someone can trigger an audit message to be stored by sending in an audit record via curl:

       

      curl -d "body={"subsystem":{"name":"login-attempts"},"message":"admin login failed 3 times","details":{"key2":"value2","key1":"value1"}}" http://localhost:8080/rest/message/QueueName?type=queue

       

      Alternatively, the alert subsystem could send messages when high-priority alerts are triggered; or if someone gives a bad password while trying to log into rhq-metrics, rhq-metrics can send an audit record to rhq-audit to store that.

       

      I don't have anything right now that queries/reports the audit records - just a matter of adding query code, perhaps a gui front end.

       

      The audit stuff is currently here in my own branch: https://github.com/rhq-project/rhq-audit/tree/mazz/proto/rhq-audit

        • 1. Re: prototype of a rhq next server component that lives on the bus
          mazz Master

          I don't have anything right now that queries/reports the audit records - just a matter of adding query code, perhaps a gui front end.

          I added AuditQueryServlet, so you can see a simple html table with the audit records. So after you submit several audit records (via curl, for example), you can point your browser to http://localhost:8080/audit/AuditQueryServlet (with the optional ?maxRows=# parameter if you want to limit the size of the return set) and you'll see a table such as:

           

          IDCorrelationIDSubsystemTimestampMessageDetails
          ID:mazztower-38863-1419364736135-5:1:1:1:1nullmysubTue Dec 23 14:59:08 EST 2014mymsg1{key2=value2, key1=value1}
          ID:mazztower-38863-1419364736135-5:3:1:1:1nullmysubTue Dec 23 14:59:57 EST 2014mymsg2{key2=value2aa, key1=value1}
          ID:mazztower-38863-1419364736135-5:4:1:1:1nullanotherTue Dec 23 15:00:08 EST 2014mymsg3{key2=value2bb, key1=value1}

          Total rows: 3


          So this audit server component prototype can now accept any audit records from any rhq.next client via the bus and then can provide a simple report of the audit records that resulted. The distribution file is built simply via mvn that produces a .zip file (if you enable the -Pdev profile when you build in mvn, you will even get that unzipped for you under target/ so you can run it right out of there).