Dynatrace on SAP Commerce Cloud: The Troubleshooting Workflows That Matter

Every CCv2 node in every environment carries a Dynatrace OneAgent, wired into services, JVM, OS, and database, included in the subscription. It is the most under-used asset on most commerce projects: opened for the first time during an incident, navigated by guesswork, abandoned for log-grepping. This guide is the working knowledge that changes that: how to get in, what the tool is and is not for, the data-retention rules that shape investigations, and the concrete workflows for the six problems that generate most war-room hours.

Access and Scope#

Entry is through the Cloud Portal: subscription, environment, Monitoring section, Dynatrace icon. Each environment has its own Dynatrace view; bookmark production and staging separately, and get access sorted for the on-call rotation before the first incident, because identity questions at 2 a.m. are a bad first responder.

Equally important is what Dynatrace on CCv2 is not for, because misusing it wastes the incident clock:

Retention: Investigate While the Data Is Fresh#

The bundled instance has retention limits that surprise teams mid-investigation:

• Code-level data: 10 days. Service-level data: 14 days. After that, granularity decays progressively (per-minute data for 14 days, five-minute to 28 days, hourly to roughly 400 days, daily beyond).
• Transactional storage is capped (on the order of 100 GB for production, 10 GB for lower environments); overflow truncates older data early by reducing its granularity.

Operational consequence: root-cause analysis of an incident must happen within days, not sprints. If the retro is two weeks out, capture screenshots and PurePath details now. And if a recurring weekly issue needs comparison across occurrences, the comparison window is exactly two of them.

Before the First Incident: Three Capabilities to Set Up#

1. Alerts. Configure alerting on the problem types you care about (response-time degradation, failure-rate increases); routing alerts to email involves SAP support, so arrange it in a calm week.
2. Service flows. Learn to read the storefront service flow once while healthy: which services call which, where time is spent on a normal day. Anomaly recognition requires a memorized baseline.
3. Dashboards. The preconfigured dashboards cover infrastructure basics; build one per audience on top: an operations view (throughput, response time percentiles, failure rate per aspect) and an event view for peak days (see the high-traffic guide).

The Six Workflows#

1. "The website feels slow"#

Start with what the AI already found: Problems in the sidebar lists detected anomalies; look for response-time degradation entries, open them, and read the analyzed root cause, which frequently ends the investigation in two clicks. If Problems is quiet but the complaint persists, go to Hosts and review each host for saturation the problem detection did not flag as anomalous (a host that is always at 90 percent CPU is "normal" to the baseline, and still your answer).

2. Heavy database load#

Two equivalent paths to the guilty SQL:

• Diagnostic tools, Top database statements: select the high-load window, find the statement with the outsized execution time or count.
• Databases in the sidebar: select the database, set the timeframe, read the Hotspots.

Either way, the decisive click is the same: on the statement's ... menu, choose Service backtrace. That walks from the SQL statement back up through the service chain to which request, which page, which code path issued it. The difference between "the database is slow" and "the wishlist page runs an unindexed query per item" is that one click, and only the second statement is fixable.

3. A specific page is failing or slow#

Transactions and services, select the storefront service, then under Requests choose Response Time or Failure Rate, and filter by web request URL (/sale, /checkout/multi/...). From the offending request, the ... menu offers the two deep dives: Service backtrace (who calls what) and Method hotspots, where you can filter to suspects by name; filtering method hotspots on "Populator" is a commerce-specific trick that pays off with embarrassing regularity, for reasons the code review playbook explains.

4. Random users failing on a feature#

Intermittent failures ("some customers cannot add to cart") are exception work: Diagnostic tools, Exception Analysis, filter on the failing request path (/cart/add), and read the exception distribution. Select the interesting exception, open its details, or jump to the PurePath (the full distributed trace of one affected request) to see exactly what that one user's request did. Intermittence usually resolves into a pattern here: one node, one product family, one payment method, one null field in migrated data.

5. CPU: who is burning it#

Diagnostic tools, CPU Analysis, search the process group (tomcat accstorefront-*), select the storefront webapp, then Service request CPU, Show code level, filtered by thread state "code execution". The result is the honest CPU profile of your storefront by method. Cross-check with Transactions and services filtered to the same process group, where the Dynamic web requests section ranks top pages three ways: by response-time contribution, by CPU, and by throughput. The page that is top of CPU but middling in throughput is your optimization target; the top-throughput page teaches you what to protect.

For anything hotspot-shaped, widen the analysis window (15 minutes rather than 5) before trusting the ranking; short windows over-represent whatever cronjob happened to fire.

6. Threads, without thread dumps#

The old ritual of catching thread dumps at the right moment is obsolete here: thread analysis is continuous. Diagnostic tools, CPU Analysis, find the process group (tomcat backgroundprocessing-*), Actions menu, Threads, select the timeline and drill into thread groups, then per-thread Method hotspots. This is the workflow for stuck cronjobs, hot folder pollers that stopped polling (pair it with the checks in the Cloud Hot Folders guide), and task-engine starvation, and it works retroactively over the retention window, meaning you can analyze last night's hang this morning.

Bonus: logs in a pinch#

Kibana is the right log tool, but Dynatrace can fetch node logs when you are already in it: Logs in the sidebar, pick the Kubernetes node and process, download (past 7 days, capped around 500 MB). Useful for grabbing a specific node's file during a trace-correlated investigation; not a log analysis strategy.

Making It Stick#

The difference between teams that get value from Dynatrace and teams that do not is not licensing or skill; it is that the first group opens it weekly when nothing is wrong. The concrete habit worth institutionalizing: a 20-minute weekly review of Problems, top pages by response time, and top database statements, with one finding turned into a backlog item each week. After three months of that, the on-call engineer navigates by muscle memory during real incidents, the baseline lives in people's heads, and the load tests from the performance engineering guide have an analysis tool the whole team can read. The agent was always installed; the practice is the feature you turn on.