PurePath visualization

Through PurePath technology, DESK 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 175,000 service requests during the selected 2-hour timeframe. 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 AuthenticationService, and then easyTravel-Business MongoDB. As this service doesn’t have a significant contribution in the overall response time, it's enclosed within the aggregated entry called 6 services. By clicking this specific aggregate and selecting AuthenticationService from the list, we see that there are only 752 of these.

Note that the AuthenticationService and easyTravel-Business services have 2,580 and 3,310 requests respectively. However, these are overall calls from many services, not just easyTravel Customer Frontend.

To focus on this subset of requests, select the last service in the desired chain of service calls that you want to analyze—easyTravel-Business in our case, and click the Filter service flow button.

Now we see the selected subset of services. 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 node and then click the View PurePaths button in easyTravel Customer Frontend box from the right-hand pane, to access the list of PurePaths that are initiated by easyTravel Customer Frontend.

The View PurePaths button from the VerificationService box of the same pane would show you the PurePaths that were initiated by VerificationService as this is the currently selected service in the service flow.

For the given timeframe, you can see the 100 last single requests that were initiated by the service under analysis (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 AuthenticationService and VerificationService. But the list is still too large—we only need to analyze the slower requests.

Let’s modify the filter on the easyTravel Customer Frontend node so that only those requests that have Response time slower than 500 ms are displayed. To do so,

1. Click the easyTravel Customer Frontend node.
2. From the Create filter for list, select Response time.
3. In the from editbox, type 500.
4. Click Add.
5. Click Apply.

As you can see in the following image, after applying the response time filter, we’ve identified 5 requests out of initial 175,000 that justify in-depth PurePath analysis. To begin PurePath analysis of a request, select a request and then click View PurePath.

PurePath analysis of a single web request

PurePath analysis provides a waterfall visualization of all requests. Each service in the call chain is represented in the PurePath.

In the Breakdown of PurePath processing time section of the example PurePath above, you can see that the whole transaction consumes about 32.8 ms of CPU time, spends 559 ms in suspension, and 74.3 ms someplace else.

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 Authentication 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 getLoyaltyStatus 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 five 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 583ms on the calling side, but only 1.11ms 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. DESK 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, DESK 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. DESK 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 easyTravel 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. To do so, go back to the service flow, select the AuthenticationService node, and click the View PurePaths button in the AuthenticationService box.

We can additionally add a response time filter on the AuthenticationService node, to view only requests, slower than 50ms. With this adjustment, the list now only shows requests of AuthenticationService that are slower than 50ms that are called by the Customer Frontend service, and 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. To do so, click the Analyze tab of the PurePath details, and click the Analyze backtrace button.

We can then choose to once again look at the same PurePath from the perspective of the easyTravel Customer Frontend service. To do so, go to the Analyze tab of the Analysis of easyTravel Customer Frontend request section, and click View PurePaths in the Analyze selection 'easyTravel Customer Frontend' column.

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.