Bug 1232188

I believe the problem is two fold:

1) Response times are only created (and logged in Elasticsearch) for the called services (i.e. consumer side), so the external invocation of remote (unmonitored) services is not recorded in Elasticsearch (as response time info).

2) The invocation details compiled as part of building a service description does not include the properties - so even if invocations (producer side) response times were recorded, the properties would not currently be available.


A solution would be to also record producer side response time information, and distinguish producer/consumer on the response time - as in some situations a single invocation may result in two response times being logged - one for the consumer side and one for the producer - so the user could filter out either depending on what they are interested in.

Does this sound a reasonable solution?

Point1:I am not sure about this point or I did not understand it well.
In elastic search I can see the complete response(RequestReceived/RequestSent/RequestReceived/ResponseReceived/ResponseSent)

Point2:Agreed

Solution looks quite reasonable and will enhance the product flexibility.Because as of now we are logging the complete payload(Which can be very large) and we have to parse it for retrieving the value.While in case of property we can have it as indexed elastic search properties.

It sounds like the properties are being captured in the raw activity information (request/response sent/received), which is also stored in elasticsearch, but is not available in the response time information, which is indirectly derived from the code you referenced in your original comments.

So I'll build a community jar with the proposed change, and then you can try it out to see if it provides the functionality you require.

Created attachment 1039470 [details]
sample Response from elastic search.Please open it in json editor

This product has been discontinued or is no longer tracked in Red Hat Bugzilla.