Ever wonder which services send requests to one of your back-end services? More than just knowing which service directly calls one of your services, what about the sequence of service calls that leads up to each request, all the way back up to the browser click that triggered the sequence of calls? Dynatrace service backtrace can provide you with exactly this information.
Say for example that you’re analyzing a SQL database service and you want to understand the sequence of preceding service requests that ultimately triggered the incoming requests to the SQL service. With service-level backtrace you might learn that, for example, the SQL database service is called by Service1, while Service1 is called by Service2, which in turn was triggered by a click on a Login button.
Consider another example. The screencapture below shows that a CouchDB service receives 24.5 requests per minute and that all those requests come from a single service. But you know that the service in question is called by other services that collectively make up your web application. The question is, how can you know exactly which click leads to which specific request?
To answer this, click the More […] button on any Service page. Then click Service backtrace.
Notice in this example that the requests come from a single web application: easyTravel. Also notice that the calls come in via a specific chain of services (Nginx calls the easyTravel Customer Frontend which in turn calls CouchDB). But there’s more. Click the View requests button for any of these services to see the names of individual requests.
Now you can see that all Image requests to CouchDB come from three user actions. Most of these were triggered by the loading of Homepage and the page /special-offers.jsp, but some requests were also triggered by a click on the Login button.
Service-level backtrace works for every service and request type, including database requests. In the screencapture below you can see where all Write requests to the easyTravel-Business MongoDB database come from. The majority come in via the Login click and the Authentication service.
Analyzing the impact of errors
This feature becomes even more useful when it comes to analyzing errors! See the image below. It shows a 100% Failure rate for the AdsForBlog request.
Analyzing the failure rate increase shows you that the root cause of the failures is an exception—you get the message and the stacktrace. But is this important? Does this have any impact on your users? To find out, click the new service backtrace button.
Dynatrace shows you how this failed request impacts your other services and your users. You can see that all requests come from a single user action, the loading of the blog. You can also see that the /blog request on the web server isn’t impacted by the failed Ads request. Not a single /blogs request failed, so it seems that the error is handled gracefully.
In contrast, have a look at the service analysis page below. You can see immediately that the failure of the CreditCard service has some impact on your users. The Booking requests fail and users can no longer buy things. This shows clearly that this error is of high importance and should be addressed immediately.
Understanding third-party impact
Dynatrace enables you to analyze which services call which third-party services, in addition to the browser click that began the sequence of calls. In the screenshots below you can see that all requests to fedex.com are failing. The service backtrace tells you which services and which user clicks led up to this third-party call.
There is much more that Dynatrace can do here and we will extend this feature in the near future.
