0 Replies Latest reply on Nov 21, 2014 4:47 AM by objectiser

    Business Transaction Monitoring - "Agent"/Activity Collector


      RTGov can operate in two modes at present - co-located server, where information from the embedded activity collector is reported directly to the activity server running in the same server, and separate client/server.


      Where the RTGov server is remote, the embedded collector in the client environment reports activities via a REST API. The client collector groups the events and reports them to the server based on elapsed time or max size reached, whichever comes first. Currently only REST is supported for remote reporting, and there is no failure support - so if activities can’t be reported they are discarded. Both areas were intended for future work.


      One of the ways I was considering to address both of these limitations was with a pluggable integration with projects such as Logstash, Fluentd, Flume, etc. So where an organisation has already setup a distributed information collection mechanism, we should be able to piggyback on it to transfer the collected information to our server - but having a default implementation available where nothing is being used.


      Using this approach would also allow the information collected from existing adapters supported by those technologies to be analysed using RHQ.next alerts.


      In terms of RTGov requirements - the collector/agent would need to be embeddable in the application environment, and collect activity events from the execution of business transactions. As the events are collected, they would need to be pre-processed before being sent to the server. Pre-processing involves the following optional tasks:


      a) Information Processor - used to derive correlation information and extract “business relevant” properties from the message header/content, as well as determine whether none/some/all of the message content should be included in the reported event (for security/performance purposes).


      b) Activity Validator - used to apply inline business policies that could block the business transaction if necessary.


      So ideally the Management.next Agent/Collector would need to support such capabilities.