Redis connections with Jedis client
Hi all,
my application is connecting to a Redis server using the Jedis Java client library (https://github.com/xetorthio/jedis/releases/tag/jedis-2.9.0) and I doesn't see the Redis Host in the transaction flow (a a external call), any ideas why?
Maybe because the connection protocol used by the Jedis library to connect the Redis server?
Regards, Josep Maria
Best Answer
I would be careful about excessive instrumentation (and subsequent overhead) due to your wildcard rule. Use the Methods Dashlet to see if there is a lot of calls to the REDIS API layer and how long they take. If there's lots of calls that are very quick, then those are inducing possibly excessive overhead and might be candidates for exclusion rules in your method sensor rule.
But to answer your question on the BT: What about adding multiple items to the filter (or Split) part of the BT.
Josep,
External hosts do not always show up automatically in Transaction Flow. This is automatic only when certain protocols and libraries are used that we recognize. However you can create your own definition of an external service based on any Method Sensor rule. Be sure to select the "This method rule denotes an External API Service call", and specify a ServiceName & Instance Name. Be sure to place this new sensor rule into a Sensor Group, restart the application and you should see a new node in Transaction Flow.
The challenge is always to determine the ideal Class.Method to specify. If you're not sure which class.method within the JEDIS library should be specified, using the CPU Sampler & Thread Dump utility to inspect the application can be a big help in this process.
Hi Joseph,
thanks for your comments! With your approach I see this problem: Jedis has a lot of methods calling the Redis database, not only one method to define the external service call. How can I deal with this?
Regards!
Hi Joseph,
following your suggestion I've identified all calls to Redis are done with methods inside the
redis.clients.jedis.BinaryClient class so putting sensors in all this class methods and creating one External API Service Call like this:
I see the TX Flow whith all calls to REDIS:
Now I want to define one BT with the time and number of REDIS calls, I know this is possible for one specific call (documented here:https://community.dynatrace.com/community/display/DOCDT65/External+API+services?_ga=2.156095411.921542391.1520846144-1399772338.1467870946) (for example for the connect calls) but I want one BT splitted by all REDIS calls to monitor all REDIS calls. Is this possible?
Regards!
Hi Joseph,
my customer ask for the overhead introduced in this case, so if we've one call with 1 ms and we instrument this method, what are the aproximated overhead in every call?
Regards,
The overhead is a very hard thing to quantify on a per-call basis.
A single invocation of a 1ms instrumented method isn't the concern and would likely not be noticed by the user. The bigger concern would be the collective overhead if that method is invoked a lot.
It's also important to weigh the overhead against the value of the information. Perhaps the overhead is more than other methods, but if the method in question contains very important information, then perhaps the increased overhead to capture the metrics is worth the cost.
Also consider the option that you can inject the instrumentation but then disable it thru Sensor Configuration. This approach results in very little added overhead, and provides the ability to enable/disable on an as needed basis. Thru the usage of Environments, one can even programatically switch from an enabled/disable state on the fly.
If a hard overhead value is important, the best way is to run a load test with/without and see if you can even measure the difference. I doubt you'd notice a statistical difference from the users perspective.
Community Member of the Month
December 2019
Announcing Dynatrace's Community Member of the Month for December 2019, Enrico F.! Click here to read more! Employee Member of the Month
December 2019
Announcing Dynatrace's Employee Member of the Month for December 2019, Silvia M.! Click here to read more! 
