Rob Cernich wrote:

 

That said, what do other projects/products use today?  Log scrapers?

Good question - not sure. I think we eventually need to support log scrapers, but you can't necessarily guarantee that all the required information will be available in a log. For example, to be able to correlate activity between two services based on an invocation or message exchange, we need to have context information that may only be available in the header or contents of a message. Generally, due to the potential size of the message payload, this level of detail is not recorded - possibly if lowest level of diagnostics is enabled, but this does not usually occur in a production system for performance reasons.

Ok, assuming we are going define our own schema, at the top level I think activity events should be recorded in groups related to a 'unit of work' - the CIM model uses the concept of unit for work, but in relation to the scope of service metrics.

I was thinking that if we are directly intercepting events, and have an understanding of the transaction scope, then all events that occur within a particular XA transaction scope should be recorded as a group. This means that some of the individual events don't need to be concerned by their context, or relationship to other events, as this will be taken care of by their inclusion in the group. Recording following a transaction scope also makes sense in a JEE context, as the transaction may get rolled back, and therefore essentially the activities did not occur.

So at the top level, there would be:

• a header of some sort containing the system wide information (e.g. server details (port), host, etc)
  • this is simplier than the TPTP component id concept, as it does not try to cater for all the different identifies that may be relevant to different events - this information should be specific to the event type being reported
  • if recording a group of activity events, then each of those events could occur at different times, albeit within milliseconds of each other possibly - however some transactions may be open for minutes resulting in some activities being quite spread out. So the timestamp should be recorded on the individual events
• context - basically a set of properties that can be used for correlation
  • the individual properties should have a name and value, although essentially it is the value that is important, as different models (for different services) may name the correlation information differently
  • the properties should also have a type, to indicate what the information represents. Some possible candidates may be, business identifier (or possibly just identifier), process instance id, etc
• events - the list of activity events that occurred within the transaction scope

This approach should hopefully reduce the duplication of header and correlation information across the individual events, if they were reported separately.

From an analysis perspective there are some pros and cons:

• If analysing the time taken to perform a task, and understanding where the time was spent within that task, then the grouping on a transaction basis may provide all the information required
• The CEP rules that may be used to analyse the activity events may only be interested in individual event types, and then perform any correlation between the event types itself, without wanting to be concerned about potential transaction groups
• Solution may be to initially dispatch the activity group into the analysis phase, but enable individual analysis steps to easily extract particular event types of interest as individual events, which are then passed to subsequent modules for further analysis

From a visualisation perspective:

• It should be easier to correlate between groups, to build up a graph of related groups which can then be presented to a user
• The 'activity units of work' can be expanded to show the individual detailed activities that were performed to achieve a particular business step