Re: [Hawkular-dev] Is this an applicable use-case for Hawkular

Hi Anton Good point. The reason it is done this way is to give administrators control over what is monitored at any particular time, rather than having something that needs to be defined at development time. At present, if a business transaction is recognised (i.e. by the URI), then it will be named and processed as defined by its configuration. But as you point out, if something changes in the service (i.e. its URI is changed), then there is potential for the administrators to miss this, and subsequently receive no further information about the business transaction. At the moment there is a high level property that indicates that any instrumented activity, that is not associated with a named business txn, should be ignored - by default this is not enabled, so the server will receive business txn fragments that may or may not be associated with a business transaction name - this config option enables the unnamed fragments to be filtered out, but this could potentially miss the case where a service has had its URI changed, and so will go from being named, to being ignored. One alternative would be to use the 'exclusion' filter approach to filter out any fragments that are definitely not of interest, so if a URI change occurred, the fragments would be reported - but just not have a business transaction name. We could use this fact to pick up the fact that unnamed fragments are being reported, which could direct an administrator to fix the problem or add it to the exclusions if no longer of interest. Although a typed API may still work best in your situation, would the approach outlined above address your concern? Regards Gary