Modern web applications typically feature complex service architectures that can process millions of different types of requests. With each unique request behaving slightly differently and triggering a slightly varied service flow, it can be a real challenge to analyze the performance and behavior of individual requests.
The filtering features help you to navigate the complexity of your application's service architecture—enabling you to find the proverbial needle in the haystack. Dynatrace Service flow enables you to analyze subsets of requests triggered by a given service.
The general Service flow filtration procedure looks like this:
See below for a more detailed explanation.
Call sequence filters are available in most service analysis views, but they’re most obvious in the Service flow. As you can see in the example below, only 5.9% of the requests to the easyTravel Customer Frontend
service also called the JourneyService
service. Next, 99% of them called the easyTravel-Business
database service.
To focus Service Flow on these calls
easyTravel-Business
.Let's go back to our example. A filter has been created to focus analysis only on those requests from the easyTravel Customer Frontend
service that call the JourneyService
service and subsequently call the easyTravel-Business
database.
Notice that the number of requests analyzed on easyTravel Customer Frontend
has been reduced to 8.73k from 156k, as only a subset of calls is now taken into account. Consequently, the average response time now represents only those easyTravel Customer Frontend
requests that call JourneyService
.
Now take a close look at the JourneyService
node. Note that 35% of the easyTravel Customer Frontend
service's response time is taken up by JourneyService
. Service flow also reveals something unexpected—some of the selected requests trigger the RMI server
.
Each filter can contain multiple call sequences. This means that you can create complex, multi-faceted call-sequence filters based on your unique service-analysis needs. Service Flow will only focus on calls that fit all the criteria.
To add the new sequences to the existing filter
In the example below, the filter criteria are extended with calls from the easyTravel Customer Frontend
service that call the RMI server
service and subsequently call the easyTravel-Business
database. Now the number of requests analyzed on easyTravel Customer Frontend
has been reduced to 528. Also, the JourneyService
service is now responsible for 39% of the response time.
After you've narrowed down the number of calls based on the involved services, you can add more criteria to the filter.
In the filter, select the service where you want to apply additional filtering.
From the Filtered by list, select the criterion.
Specify the threshold or matching rules for the criterion.
Select Apply.
If needed, add more criteria to the filter.
When finished, select Apply.
In our example, we applied the Response time threshold of 200 ms to JourneyService
. Now only calls with a response time longer than 200 ms are shown, and there are just 6 of them. We're now very close to finding the needle in this haystack!
The true power of call-sequence filtering becomes apparent when you begin analysis of a problematic call sequence. In the example above, Service flow now shows us that 40% of the easyTravel Customer Frontend
service's response time is taken up by JourneyService
.
The next logical step is to analyze the response time of the JourneyService
service in the context of the selected call sequence. To do this, select JourneyService
within Service flow
. The right pane reveals all the analysis options that you can perform on the selected service—all within the context of the filtered call sequence. All the filters you created in Service flow will also be applied to the additional analysis.
Learn more about additional analysis options in topics listed below.