14 Replies Latest reply: Apr 13, 2012 10:26 AM by Rob Cernich RSS

Hooking into switchyard service metrics

Gary Brown Master

Hi

 

Could you provide some pointers for how I should obtain access to the service metrics/api?

 

Although access via the REST api is ok, I would also like to investigate using the internal (direct) api as an option for doing some SLA monitoring work.

 

Regards

Gary

  • 1. Re: Hooking into switchyard service metrics
    Keith Babo Master

    There is a service registered in AS7 with the top-level admin node named "SwitchYard".

     

    https://github.com/jboss-switchyard/release/blob/master/jboss-as7/extension/src/main/java/org/switchyard/as7/extension/services/SwitchYardAdminService.java

     

    This is how the console gets at it, IINM.

  • 2. Re: Hooking into switchyard service metrics
    Gary Brown Master

    Hi Keith

     

    Only just got around to looking into this in more detail - it is possible to provide access to the org.switchyard.admin.Switchyard implementation in a more standard way (e.g. JNDI) - i.e. without requiring microcontainer code?

     

    Had a look at the console code, and it gets supplied the org.jboss.msc.service.ServiceRegistry as part of the context when an admin operation is invoked. But not sure if application code can easily obtain access to the ServiceRegistry?

     

    Haven't had to deal with the as7 microcontainer code before, and can't find any  docs on this - if it is possible to easily obtain ref to ServiceRegistry, can you point me in the right direction

     

    Update:

     

    Actually I think it may be the ServiceDomainManager I will need access to - but same question applies for this, i.e. it would be useful if it could be accessed via JNDI.

     

    Is this also the component (i.e. the event manager) that would need to be accessed for obtaining the general activity information about exchanges?

     

    Thanks in advance.

     

    Regards

    Gary

  • 3. Re: Hooking into switchyard service metrics
    Keith Babo Master

    We could do that.  We planned to do a JMX wrapper around the core admin API.  You should be able to get a hook to the MBeans you need via the platform MBean server.  Would that be acceptable?

     

    BTW, are you interested in polling metrics or in registering an event listener for things like deployment/message exchange/etc.?

     

    ~ keith

  • 4. Re: Hooking into switchyard service metrics
    Gary Brown Master

    The JMX MBean approach would be ok to access the admin api, however I think it may be better to be event driven. So ideally need access to the service domain manager.

  • 5. Re: Hooking into switchyard service metrics
    Keith Babo Master

    I hadn't really intended to provide outside access to ServiceDomainManager, but it's something we can consider for 'internal' consumers through JNDI since it's already published as an AS7 service.  I guess the real question is whether you want to use our public API or if you want to use a back door.  Can you give me an idea of the exact API methods you plan on using?  The admin API today is really just an event listener which grabs events thrown off a ServiceDomain.  If you are looking at monitoring those events yourself, then I don't think you would use the admin API at all - just the core API.

     

    Another consideration is that we can emit notifications with JMX, so that's another way to register an event-based listener.  Once I have a better idea of exactly which pieces of the API you plan on using, I can slap something together.

  • 6. Re: Hooking into switchyard service metrics
    Gary Brown Master

    I think I just need access to the EventManager, so probably best to keep for internal use - and just access via jndi. Initially the interest will be in the ExchangeCompletionEvent, in the same way as the current service metrics information. So this would be used for SLA monitoring.

     

    So that is essentially the short term requirement covered.

     

    In terms of future BAM functionality, I know that you added a HandlerChain mechanism (SWITCHYARD-229), but not sure if that requires a handler to be registered as part of the app config (i.e. in switchyard.xml) - or whether a global system wide handler could also be registered, possibly programmatically?

     

    If not, then possibly this event manager could be used for this BAM functionality aswell? In this case, I think it will be necessary to have atleast another type of event, to represent the exchange initiation (i.e. request dispatched), and then the ExchangeCompletionEvent representing the response.

  • 7. Re: Hooking into switchyard service metrics
    Rob Cernich Master

    Hey Gary,

     

    I've forgotten where we left off regarding a generic BAM/SAM solution, but were you planning on providing a monitoring server/service?  If so, would it be better if SY used that API for publishing events?  In other words, wouldn't it be better if SY forwarded events to a generic monitoring service?  This could be an optional dependency/service requirement for SY, allowing it to function with or without the service.  That approach would also lend itself to other service providers (e.g. JB-WS, RESTEasy, etc.).  Just an idea.

     

    Best,

    Rob

  • 8. Re: Hooking into switchyard service metrics
    Gary Brown Master

    Hi Rob

     

    There will be a RESTful API for reporting activity events, however initially I would prefer to handle the collection locally. Partly this is to allow for experimentation with enrichment of the information based on other data that may be available in the context, but also we may need to dynamically control what level of information is collected.

     

    So for now, while the approach is still evolving, it may be better for the BAM system to use interceptors/observers - but if later on it seems unnecessary, then once the complete solution is available we can change it to record the activity directly.

     

    Regards

    Gary

  • 9. Re: Hooking into switchyard service metrics
    Keith Babo Master

    I think I just need access to the EventManager, so probably best to keep for internal use - and just access via jndi. Initially the interest will be in the ExchangeCompletionEvent, in the same way as the current service metrics information. So this would be used for SLA monitoring.

     

    Would you mind patching your local env to do this registration into JNDI as a short term measure?  I still want to look at doing this as part of our JMX wrapper of the admin API (query and events), but won't have a chance to do that until later in the release.  If you can use a locally modified version for now, that allows you to make progress immediately and also will allow us to compare/contrast the JNDI route with the JMX route once it's ready.

     

    Adding the registration to start() and the unregistration to stop() here will probably do the trick:

     

    https://github.com/jboss-switchyard/release/blob/master/jboss-as7/extension/src/main/java/org/switchyard/as7/extension/services/SwitchYardServiceDomainManagerService.java

     

     

    In terms of future BAM functionality, I know that you added a HandlerChain mechanism (SWITCHYARD-229), but not sure if that requires a handler to be registered as part of the app config (i.e. in switchyard.xml) - or whether a global system wide handler could also be registered, possibly programmatically?

     

    If not, then possibly this event manager could be used for this BAM functionality aswell? In this case, I think it will be necessary to have atleast another type of event, to represent the exchange initiation (i.e. request dispatched), and then the ExchangeCompletionEvent representing the response.

     

     

    It requires the handler to be configured as part of the domain definition.  Strictly speaking, you can do that via the the application's switchyard.xml, but that's a bit of a hack at the moment.  We likely need a standalone configuration for the runtime which also provides access to the root domain's handler chain definition.  Programmatic registration sounds like something we could consider as well.

  • 10. Re: Hooking into switchyard service metrics
    Gary Brown Master

    Hi Keith

     

    Thats fine - I'll do the change locally for now.

     

    Regards

    Gary

  • 11. Re: Hooking into switchyard service metrics
    Rob Cernich Master

    Would you mind patching your local env to do this registration into JNDI as a short term measure?  I still want to look at doing this as part of our JMX wrapper of the admin API (query and events), but won't have a chance to do that until later in the release.  If you can use a locally modified version for now, that allows you to make progress immediately and also will allow us to compare/contrast the JNDI route with the JMX route once it's ready.

     

     

    I thought we were supposed to get JMX for free from the management subsystem.  Hopefully, this is still true.

  • 12. Re: Hooking into switchyard service metrics
    Rob Cernich Master

    Hey Gary,

     

     


    There will be a RESTful API for reporting activity events, however initially I would prefer to handle the collection locally. Partly this is to allow for experimentation with enrichment of the information based on other data that may be available in the context, but also we may need to dynamically control what level of information is collected.

     

    Sorry, I wasn't implying using a WS for reporting activity event, just that other WS subsystem providers could also report their activity events.

  • 13. Re: Hooking into switchyard service metrics
    Keith Babo Master

    You'll probably have to expand on that a bit, Rob.  Do you mean that the DMR stuff is also exposed via JMX?  That's definitely interesting, although I definitely would want to see what it looks like.  I think most management clients using JMX would want a traditional attributes/operations layout in an MBean for our top-level admin API classes.  My original idea was to simply wrap the admin API with a set of MBeans and delegate down.  If there's an automagic way of getting this done which yields the same result, I'm all for it.  One additional consideration is that I doubt the notification stuff would come along with the automagic route.

  • 14. Re: Hooking into switchyard service metrics
    Rob Cernich Master

    Hey Keith,

     

    Yep (to everything).