Name: Troubleshooting Issues via Dynatrace in SAP Commerce Cloud
Uploaded: 2022-7-22
Duration: 600 s
Description: This video explains how to troubleshoot application issues using Dynatrace APM. It also provides an in-depth investigation of common problems, identification of false alerts, and guidance on determining when an application restart is required.

Share feedback

<p><u><strong>Planned maintenance of Practice Systems</strong></u></p>

Planned maintenance of Practice Systems

Why create an SAP account?

Enhance your learning experience

SAP Learning

Choose your subscription

Manage your subscription

Live Sessions

Hands-on Practice

Certification

My Learning

Ready to start learning?

<div><div><div><div><div>This video explains how to troubleshoot application issues using Dynatrace APM. It also provides an in-depth investigation of common problems, identification of false alerts, and guidance on determining when an application restart is required.</div></div></div></div></div>

Troubleshooting Issues via Dynatrace in SAP Commerce Cloud

In this video, we will look at various sections in the Dynatrace APM that are useful for troubleshooting application issues. We will also have a deep dive to investigate common problems, explore a false alert and see when an application restart is required. Let's start by clicking the link in the monitoring section on the CV2 environments dashboard. To open Dynatrace monitoring. This will open the Dynatrace APM in a new browser window. The landing page displays the performance monitoring dashboard. By default, the data for the last two hours is displayed. I can change this by clicking on last two hours at the top right of the screen and selecting a different period. The SAP Commerce Cloud subscription comes bundled with many pre-configured dashboards. Let's take a brief look to performance monitoring. Dashboard provides a high level view of the environment, monitoring the system's health across hosp services and databases. Predefine graphs within this dashboard provide comprehensive information on the application database. Cloud infrastructure. And network performance. The SAP Commerce Cloud SLOs, also known as Service Level Objectives Dashboard, contains graphs at the service level performance of the Commerce application. The problem section shows a list of problems that occurred within the selected time slot. It allows you to directly drill down and analyze a particular problem. Before we start with troubleshooting, let's understand how Dynatrace manages performance anomalies. Dynatrace detects incidents such as a breach of configured metrics, threshold, performance degradation, etc. these are termed as events. These events have a type and severity associate with them. The different event types in related severity are monitoring, unavailable, availability, error, slowdown, resource and custom. A problem is a collection of multiple events of the same type with the same root cause. A problem can start at the lower severity and get promoted to a higher severity automatically, based on its application impact. Now let's check out a few common troubleshooting scenarios and how Dynatrace can be used to find the root cause. Let's check the website's slowness, a common problem occasionally observed on web applications. A slow down event points to application or service performance deterioration, and navigate to the problem view and select last seven days. In the analysis period, drop down and select one of the slowdown problems. This screen here displays details of the issue along with multiple options for further analysis. I'll click on the Analyze Metric Anomalies button. This will provide insights on the metrics breached by this problem. The subsequent page displays the service details where the problem was detected. I click on the service link for further information. I'll click the Create Analysis View button and check the various metrics available in the dropdown of the subsequent screen. For example, unselect Http 400 count. On this screen, we observe that 20, Http four, or four errors occurred during the selected period. For a JavaScript file based on the number of overall requests served and other criteria. Dynatrace has created a problem with a slow down, even severity. A lesser number of errors may have resulted in a resource severity event. I'll click on the three dots in the actions column and select distributed traces. Here we can see that the Http four. All four errors were caused while trying to fetch a JavaScript file. Let's analyze another common issue API availability errors and select an API endpoint outage problem. A page with the problem details is displayed. I click on the pane displaying the impacted service. The page now displays the service issue details saying Http 500 errors are more than usual. I'll press the Create Analysis View button. Now I'm in the multidimensional Analysis page of the impacted service. I'm select Http 500 count metric as metric filter. The graph displays the error distribution across the selected period. In the top dimensions, the one related to images folder contains the one Http 500 error. I'll click on the three dots and select distributed traces. We can observe that a few calls to the media service for fetching the images has resulted in an Http 502 error. We can check the details of failure after request to get further details. Here we can even see the root cause for the request directly. Please note an Http 502 error can occur due to a network issue or too many concurrent requests received by a service, which can result in a delay in sending the response. The details of the exact error will be captured in the Tomcat logs. In such cases, we need to monitor the service for a longer period to check if the issue recurs. In this scenario, no corrective action is required as there were no further issues observed. However, in case the issue persists for a longer duration, analyzing the logs will be required to fix the problem. Finally, we will look at a false alerts scenario. I'll go to the problems screen. I'll scroll down the list of problems and select problem key 22079. The problem was created by the synthetic monitoring based on the performance threshold violation. I'll click on the Commerce API endpoint panel. It will display the affected services details. In this case, the LTC service response time was a slow considering a single page rendering requires multiple web services calls, which can have a big impact on page load performance. I'll select Commerce Web Services to inspect further details. I move the pointer onto the total time consumption value of the OSC service. This displays a low median response time of 3.19 millisecond, indicating that this is a false positive. However, similar issues are common during sales periods when the website experiences a sudden spike in traffic. Let's continue on to see the steps for further analyzes of such an issue. View the distributed traces. I'll click on the Response time column to sort the data. I'll select Response Time Hotspots in the context menu for the slowest request. The subsequent screen displays a breakdown of the time spent. We can observe that almost one second was spent in code execution, and select code execution to get the breakdown of its execution time. I'll click on View Method Hotspots. I can see the class hierarchy invoked in this service request and the execution time of each method. We can drill down to check for further details. This was a false positive caused by synthetic monitoring observing a slowdown in the response time. In this instance, the JSP must have been accessed for the first time, requiring the compilation. However, the process for analyzing the performance bottlenecks in the custom code will remain the same as above.