Through PurePath technology, Dynatrace enables you to efficiently find the proverbial needle in the haystack and focus on those few requests (out of tens of thousands) that you’re interested in. You can view requests from multiple vantage points—from the perspective of the services you’re responsible for or from the point of view of where a request originates in your system. With PurePath, you really do get an end-to-end view into each web request.
PurePath for method-level transaction analysis
The first step in your analysis should be to locate those requests that you want to analyze at a granular level. Filters can be used to narrow down many thousands of requests to just those few requests that are relevant to your analysis. This can be achieved during problem analysis by following the root-cause analysis drill downs (select Problems from the navigation menu to start problem analysis), or manually by segmenting your requests using the advanced filtering mechanisms in service flow and outlier analysis. Ultimately, you’ll likely discover a handful of requests that require deeper analysis. This is where PurePath analysis comes in.
Detection of a single request
In the example below, the service
easyTravel Customer Frontend received
138,000 service requests during the selected 2-hour time frame. This is an unwieldy number of requests to work with, so we need to narrow down these results.
Suppose that we’re interested specifically in those requests that call the
Authentication Service. As this service doesn’t have a significant contribution in the overall response time, it's enclosed within the aggregated entry called
5 services. By clicking this specific aggregate and selecting
AuthenticationService, we see that there are only
656 of these (see image below). To focus on this subset of requests, click the Filter service flow button after selecting the desired chain of service calls that you want to analyze.
After filtering the service flow, we see the selected subset of services (see below). This fraction indicates that we're looking only at transactions where
easyTravel Customer Frontend calls
AuthenticationService, which in turn calls
As you can see,
75% of the
easyTravel Customer Frontend requests that call
AuthenticationService also call
VerificationService. These are the requests we want to focus our analysis on. Therefore, let’s add
VerificationService as a second filter parameter to further narrow down the analysis. To do this, select
VerificationService and then click the View PurePaths button in the upper right box to access the list of PurePaths that are initiated by
easyTravel Customer Frontend. The View PurePaths button in the pane on the lower right would show you the PurePaths that were initiated by
VerificationService (as this is the currently selected service in the service flow).
PurePaths view includes a list of single requests that you can browse, sort, filter, and analyze. For the given time frame, you can see the 100 last single requests that were initiated by the service that is being analyzed (the
easyTravel Customer Frontend service in this example) that also match the filter criteria. You can sort these single requests by Response time, CPU time, Method, or Response code. To view the PurePath of a single request, expand the Details column and click View PurePath.
In the image above, notice the filter visualization in the upper-left corner. The provided PurePath list includes only those requests to
easyTravel Customer Frontend that call both
Authentication Service and
VerificationService. But the list is still too large—we only need to analyze the slower requests. To do this, let’s modify the filter on the
easyTravel Customer Frontend node so that only those requests that have Response time >
500 ms are displayed. As you can see in the following image, after applying the response time filter, we’ve identified
4 requests out of
138,000 that justify in-depth PurePath analysis. To begin PurePath analysis of a request, select the request and then click View PurePath.
PurePath analysis of a single web request
PurePath analysis provides a waterfall visualization of all requests (see the
easyTravel Customer Frontend example below). Each service in the call chain is represented in the PurePath.
In the top section of the example PurePath above, you can see that the whole transaction consumes about
20 ms of CPU and spends time in
1 database. However, the waterfall chart shows much more detail. The waterfall indicates which other services are called and in which order. We can see each call to the
Verification services. We also see the subsequent calls to the
MongoDB service that were made by both service requests. PurePath, like Service Flow, provides end-to-end web request visualizations—in this case that of a single request.
The colors and positions of the horizontal bars in the chart indicate both the sequence and response time of each of the requests. You can easily see which calls that were executed synchronously and which were executed in parallel.
According to the example above, most of the time of this particular request was spent on the client side of the
isUserBlacklisted web service call. As indicated by the colors of the bars in the chart, the time was not spent on the server side of this web service but rather on the client side. If we were to investigate this call further, we would find underlying network latency.
By selecting one of the service or execution bars you can get even more detail. You can analyze the details of each request in the PurePath. In the example below, you can see the web request details of the main request. Such details include metadata, request headers, request parameters, and more. You can even see information about the proxy that this request was sent through.
Notice that some values are obscured with asterisks. This is because these are confidential values and the current user account doesn’t have permission to view confidential values. These values would be visible if the active user account had permission to view these values.
Besides the information provided in the Summary tab, you can also view more timing-specific details. Just select the Timing tab for the service call you're interested in. The example below shows timing details for the
authenticate web service call. In this case, we see that the request lasts
15ms on the calling side, but only
1.43ms on the server side. Here again, there is significant network latency.
Code execution details of individual requests
Each request executes some code, for example, Java, .NET, PHP, Node.js, Apache webserver, Nginx, IIS, or something else. PurePath view enables you to look at the code execution of each and every request. Simply click on a particular service and select the Code level tab.
This view shows you code-level method executions and their timings. Dynatrace tells you the exact sequence of events with all respective timings (for example, CPU, wait, sync, lock, and execution time). As you can see above, Dynatrace tells you exactly which method in the
orange.jsf request on the
easyTravel Customer Frontend called the respective web services and which specific web service methods were called. The timings displayed here are the timings as experienced by the
easyTravel Customer Frontend, which, in the case of calls to services on remote tiers, represent the client time.
Notice that some execution trees are more detailed than others. Some contain full stacktraces. Dynatrace automatically adapts the level of information it captures based on importance, timing, and estimated overhead. Because of this, slower parts of a request typically contain more information than faster parts.
You can look at any request in the Purepath and navigate between the respective code-level trees. This gives you access to the full execution tree.
Different teams, different perspectives
Each PurePath tracks a request from start to finish. This means that PurePaths always start at the first fully monitored process group. However, just because a request starts at the
Customer Frontend service doesn’t mean that this is the service you’re interested in. For example, if you’re responsible for
AuthenticationService, it makes more sense for you to analyze requests from the perspective of
Let’s look at the same flow once again, but this time we’ll look at the requests of
AuthenticationService directly. This is done by clicking the View PurePaths button in the
We can additionally add a response time filter. With this adjustment, the list now only shows requests of
AuthenticationService that are slower than
50ms that are called by the
Customer Frontend service (at the time when the frontend request also calls
Now we can analyze
AuthenticationService without including the
easyTravel Customer Frontend service in the analysis. This is useful if you’re responsible for a service that is called by the services developed by other teams.
Of course, if required, we can use service backtrace at any time to see where this request originated from.
We can then choose to once again look at the same PurePath from the perspective of the
easyTravel Customer Frontend service. Just click View PurePaths on the left.
This is the same Purepath we began our analysis with. You can still see the
Authenticate call and its two database calls, but now the call is embedded in a larger request.
PurePath for Error analysis
Analyzing individual requests is often a useful way of gaining a better understanding of detected errors. In the image below you can see that requests to
Redis started to fail around the
10:45 mark on the timeline. To find the Failure rate tab, go to the service’s details page, and click the View... button (View requests, View dynamic web requests, or View resources).
Click the View backtrace button to see where these requests came from. We can now see that all of these requests originate in the
weather-express service. We also see that nearly all failed
Redis calls have the same Exception—an
AbortError caused by a closed connection.
We can go one step further, down to the affected
Node.js PurePaths. With the
weather-express service selected, click the Analyze tab in the bottom right corner of the page and then click View Purepaths on the left column. Below you can see such a
Node.js PurePath and its code level execution tree. Notice that the
Redis method call leads to an error. You can see where this error occurs in the flow of the
We can also analyze the exception that occurs at this point in the request. Just select the Exceptions tab.
Each PurePath shows a unique set of parameters leading up to the error. With this approach to analysis, PurePath view can be very useful in helping you understand why certain exceptions occurred.