How does PurePath visualization help me analyze web requests end-to-end?

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 easyTravel-Business MongoDB.

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 Authentication and 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 AuthenticationService.

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 AuthenticationService pane.

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 VerificationService).

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 Node.js code.

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.