Study guide
5.1 The 5-Layer Smartscape Topology: Datacenter to Application
Dynatrace Certified Associate Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Platform Overview, Deployment Models & Architecture
1.1 Dynatrace Platform Capabilities, Web UI Navigation & the Dynatrace Hub 1.2 SaaS vs. Dynatrace Managed Architecture & Security 1.3 Core Telemetry Components: OneAgent, ActiveGate & Grail Lakehouse 1.4 Licensing Models: Dynatrace Platform Subscription (DPS) & Davis Data Units (DDUs)
2 Chapter 2: ActiveGate Architecture & Network Topologies
2.1 ActiveGate Types: Environment vs. Cluster ActiveGates 2.2 ActiveGate Capabilities: Proxying, Private Synthetic, Cloud Integrations & Extensions 2.3 Network Zones, Multi-DC Routing & Firewall Traversal
3 Chapter 3: OneAgent Deployment, Configuration & Management
3.1 OneAgent Architecture, Components & Automatic Injection 3.2 Host Installation on Linux, Windows & Containerized Hosts 3.3 Cloud-Native Deployment: Dynatrace Operator on Kubernetes & OpenShift 3.4 Kubernetes Observability: Clusters, Nodes, Namespaces, Workloads & Events
4 Chapter 4: Monitoring Modes, Process Groups & Infrastructure Observability
4.1 Monitoring Modes: Full-Stack vs. Infrastructure-Only vs. Discovery 4.2 Process Groups, Process Instances & Custom Process Group Detection Rules 4.3 Host Groups, Host Naming Rules & Environmental Metadata Extraction 4.4 Infrastructure & Operations: Host Health, Disk, Network & Availability Analysis 4.5 Database Observability: The Databases App, Connection Pools & Storage Latency
5 Chapter 5: Smartscape Topology & Service Flow
5.1 The 5-Layer Smartscape Topology: Datacenter to Application 5.2 Service Detection: Web Services, Background Tasks & Custom Services 5.3 Service Flow, Backtrace Analysis & Horizontal/Vertical Dependency Mapping
6 Chapter 6: PurePath Distributed Tracing & Code-Level Diagnostics
6.1 PurePath Architecture, Distributed Tracing & Request Context Propagation 6.2 Method Hotspots, CPU Profiling & Memory Allocation Thread Analysis 6.3 Database Service Diagnostics, Slow Queries & Exception Analysis
7 Chapter 7: Davis AI Engine, Baselining & Causation
7.1 Davis Deterministic Causation Engine vs. Pure Correlation 7.2 Automated Dynamic Baselining, Percentiles & Traffic Seasonality 7.3 Event Ingestion, Event Types & Event Hierarchy in Problem Evolution
8 Chapter 8: Problem Lifecycle, Root Cause Analysis & Alerting
8.1 Problem Lifecycle, Severity Categories & Root Cause Cards 8.2 Alerting Profiles, Delay Filters & Management Zone Routing 8.3 Problem Notification Integrations: Webhooks, Slack, ServiceNow & ITSM
9 Chapter 9: Digital Experience Monitoring: Synthetic Monitoring
9.1 Synthetic Monitors: HTTP, Single-Step Browser & Multi-Step Clickpaths 9.2 Private Synthetic Locations, ActiveGate Engines & Credential Vault 9.3 Outage Detection, Performance Baselining & Maintenance Suppression
10 Chapter 10: Digital Experience Monitoring: Real User Monitoring (RUM)
10.1 RUM Architecture, OneAgent Script Injection & Mobile/OpenKit Telemetry 10.2 User Actions: Load vs. XHR/Fetch Actions, Visually Complete & Speed Index 10.3 Apdex Performance Ratings, User Sessions & Session Replay Masking
11 Chapter 11: Log Management and Analytics on Grail with DQL
11.1 Log Management on Grail: Storage, Ingestion Pipelines & Log Masking 11.2 Dynatrace Query Language (DQL): Fetch, Filter, Fields & String Operations 11.3 DQL Aggregations: Summarize, MakeTimeseries, Sorting & Visualizations
12 Chapter 12: Platform Governance, OpenTelemetry & Automation
12.1 Management Zones: Scoping Observability, Dashboards & Access Control 12.2 Tagging Strategies: Automated Rule-Based Tags, Manual Tags & AWS/K8s Metadata 12.3 OpenTelemetry Ingestion, OpenPipeline & Dynatrace Workflows Automation
13 Chapter 13: Cloud Integrations & Agentless Infrastructure Ingestion
13.1 AWS, Azure & Google Cloud Integrations 13.2 VMware vSphere, Extensions & Other Agentless Ingestion Paths
14 Chapter 14: Business Analytics & Business Events
14.1 Business Events: Capture, Ingestion & the bizevents Grail Table 14.2 Business Analytics: Connecting Performance to Revenue, Conversion & KPIs
15 Chapter 15: Notebooks, Dashboards & Data Visualization
15.1 Notebooks: Section-Based Investigation & Shareable Analysis 15.2 Dashboards: Tiles, Variables, Segments & Continuous Monitoring 15.3 Choosing Visualizations: Data Explorer, Chart Types & Metric Selection
16 Chapter 16: Reporting, Metrics & User Behavior Analysis
16.1 Metrics on Grail: Built-in Metrics, Granularity & Retention 16.2 Dashboard Reports, Subscriptions & Exporting Data via APIs 16.3 User Behavior Analysis: Bounce Rate, Landing & Exit Pages, Conversion Goals 16.4 Session Segmentation, User Journeys & Funnel Drop-Off Analysis
17 Chapter 17: Security, Vulnerability Analytics & Application Protection
17.1 Platform Security: Data Privacy, Encryption & Access Control 17.2 Third-Party Vulnerabilities, the Davis Security Score & Security Advisor 17.3 Code-Level Vulnerabilities, Attacks & Runtime Application Protection 17.4 Security Investigator, Notifications & the Remediation Workflow
5.1 The 5-Layer Smartscape Topology: Datacenter to Application
Key Takeaways Explain This Topic AI
Smartscape is Dynatrace's real-time topological model that automatically visualizes and maintains relationships across five vertical architectural layers: Datacenter, Host, Process Group, Service, and Application.
Vertical dependencies map hierarchical infrastructure relationships (applications run on services, services on process groups, process groups on hosts, hosts in datacenters), while horizontal dependencies map communication flows (network connections, process traffic, service calls).
A Process Group (PG) represents a cluster of processes executing identical software/code across an environment, whereas a Process Group Instance (PGI) is the single running process entity bound to a specific host.
Davis AI relies on the Smartscape topology graph to dynamically traverse causal dependency trees, filter benign symptoms, pinpoint root causes, and evaluate problem blast radius without static alerting thresholds.
Last updated: September 2026
The 5-Layer Smartscape Topology: Datacenter to Application
Exam Focus: Understanding the five vertical layers of Smartscape, the vital distinction between Process Groups and Process Group Instances, the differences between horizontal and vertical dependencies, and how Davis AI utilizes this real-time topological model for root-cause analysis is foundational for the Dynatrace Certified Associate exam.
In modern enterprise software ecosystems, applications are no longer deployed as static monoliths onto predictable bare-metal servers. Cloud-native architectures, microservices, container orchestrators (Kubernetes/OpenShift), serverless functions, and multi-cloud environments introduce extreme dynamism: components scale elastically, containers cycle every few minutes, and network routes reconfigure dynamically. Traditional monitoring systems rely on static CMDBs (Configuration Management Databases) or manual network topology diagrams that become obsolete within hours of publication.
Dynatrace addresses this complexity through Smartscape : an automated, continuously updated, real-time topological graph that discovers and maps every component of your IT environment without manual configuration. Smartscape provides the structural intelligence that powers Dynatrace, serving as the definitive architectural map for Davis AI, causation engines, service flow analyzers, and problem correlation pipelines.
The Five Vertical Layers of Smartscape
Smartscape organizes an enterprise technology stack into five interconnected, vertical architectural layers. Each layer represents a distinct abstraction level in the computing hierarchy, extending from underlying physical and cloud infrastructure up to end-user digital touchpoints. [ 5. Application Layer ] ==> Web Apps, Mobile Apps, Custom Apps, Synthetic Monitors
- |
- [ 4. Service Layer ] ==> Web Requests, REST/gRPC Services, Database Services, Queues
- |
- [ 3. Process Group Layer ] ==> Process Groups (PG) & Process Group Instances (PGI)
- |
- [ 2. Host Layer ] ==> Physical Servers, Virtual Machines, Cloud Instances, K8s Nodes
- |
- [ 1. Data Center Layer ] ==> Physical Datacenters, Cloud Regions & Availability Zones, VMware DCs
- 1. Data Center Layer
The Data Center layer represents the physical or cloud geographic boundary where infrastructure resides. It provides geographical and structural context to your computing assets.
On-Premises Environments: Represents physical server rooms, enterprise datacenters, or VMware vCenter Datacenter objects.
Cloud Environments: Maps directly to cloud provider regions and availability zones (for example, AWS us-east-1a , Azure East US , or Google Cloud europe-west1-b ).
Significance: Smartscape uses the datacenter layer to correlate broad regional outages, cloud availability zone disruptions, or physical datacenter power/cooling failures that impact multiple hosts simultaneously.
2. Host Layer
The Host layer represents physical or virtual operating system instances running in the environment.
Supported Entities: Bare-metal physical servers, hypervisor virtual machines (VMware ESXi, Hyper-V, KVM), cloud compute instances (Amazon EC2, Azure VMs, Google Compute Engine), and container worker nodes.
Telemetry Captured: CPU utilization, memory consumption, page faults, disk storage saturation, disk I/O, network interface throughput, and packet drops.
Significance: Hosts provide the execution environment for processes. Host health problems (such as memory exhaustion or high CPU steal) propagate upward to degrade hosted processes and services.
3. Process Group Layer
The Process Group layer represents the running operating system processes discovered by OneAgent. A foundational exam topic is the distinction between a Process Group (PG) and a Process Group Instance (PGI) :
Process Group (PG): A logical collection of processes executing identical software, binaries, and command-line configurations across an environment (for example, a cluster of six Apache Tomcat nodes delivering an order-processing service). A Process Group spans across hosts.
Process Group Instance (PGI): The actual individual process executing on a specific host machine (for example, the single Tomcat process running on host prod-app-03 ). A PGI is bound to exactly one host.
Process Group Properties: Dynatrace identifies and clusters processes based on executable name, command-line arguments, working directory, and environment variables. Technologies detected include Java Virtual Machines, .NET CLR runtimes, Node.js engines, PHP workers, Go binaries, Apache HTTP, and NGINX.
4. Service Layer
The Service layer represents discrete business logic and functional code modules executing within process groups. Services accept incoming requests, process business logic, and communicate with other services or data stores.
Service Types: Web request services, Web services (REST, SOAP, gRPC), Database services, Messaging/Queue services (Kafka, RabbitMQ, JMS), and Background task services.
Cluster Awareness: A single logical service can span across multiple Process Group Instances. For example, a clustered payment service runs across four distinct Tomcat PGIs on four hosts, yet Dynatrace models it as a single logical service with aggregated metrics.
Significance: Services are the core operational units analyzed for response time, throughput, failure rate, and PurePath distributed transaction tracing.
5. Application Layer
The Application layer represents the digital touchpoints where human users, external systems, or synthetic probes interact with your services.
Application Classifications:
Web Applications: Browser-based frontends instrumented with Real User Monitoring (RUM) JavaScript tags.
Mobile Applications: Native iOS and Android applications instrumented via the Dynatrace Mobile SDK.
Custom Applications: IoT devices, smart TVs, desktop clients, or point-of-sale terminals instrumented via the Dynatrace OpenKit SDK.
Synthetic Applications: Synthetic web checks and HTTP API monitors simulating customer transactions from global locations.
Significance: The Application layer measures customer experience: user action duration, visual completeness, JavaScript errors, crash rates, and user frustration (Apdex ratings).
Dual Topological Dimensions: Vertical Hierarchy vs. Horizontal Dependencies
Smartscape visualizes enterprise infrastructure across two distinct analytical dimensions: Vertical Hierarchical Dependencies and Horizontal Communication Flows . =========================================================================================
- VERTICAL DEPENDENCY (Containment Hierarchy) HORIZONTAL DEPENDENCY (Flow / Traffic)
- =========================================================================================
- [Application] [Frontend App] --> User Web Traffic
- | (delivers user touchpoint) |
- [Service] [Web Service] --> HTTP / gRPC Call
- | (executes business logic) |
- [Process Group Instance] [Backend Serv] --> TCP Socket Traffic
- | (runs inside process runtime) |
- [Host] [Database] --> Network Packets
- | (executes on OS / hypervisor)
- [Data Center]
- =========================================================================================
- Vertical Dependency (Hierarchical Hosting)
Vertical dependencies represent structural, parent-child containment relationships. Moving vertically down through the stack reveals the infrastructure supporting a business application:
An Application depends on underlying Services to process user requests.
A Service runs inside one or more Process Group Instances .
A Process Group Instance executes on a specific Host .
A Host is physically or logically located within a Data Center .
When troubleshooting, vertical navigation allows engineers to evaluate whether a slow service is constrained by a saturated process runtime (such as JVM garbage collection pauses) or host-level infrastructure degradation (such as CPU saturation or disk I/O bottlenecks).
Horizontal Dependency (Communication & Call Paths)
Horizontal dependencies represent network traffic, communication protocols, and data exchange between peer entities operating within the same layer or across architectural boundaries:
Service-to-Service: Upstream microservices invoking downstream web services via HTTP, REST, SOAP, or gRPC; services publishing messages to message brokers.
Process-to-Process: Inter-process communication (IPC), TCP socket connections, and port-to-port connections discovered by oneagentnet .
Host-to-Host: Network routes, packet throughput, round-trip times (RTT), and connection states between physical and virtual hosts.
Smartscape UI Visual Language & Symbology
The Smartscape user interface utilizes standard visual conventions to convey real-time topological health, communication state, and traffic volume:
Visual Element Graphical Styling Technical Meaning & Platform Behavior
Healthy Node Solid circle with green border/center Entity is functioning normally within calculated baseline parameters; no active anomalies.
Impacted Node (Problem) Solid circle with red halo or red icon Entity is currently experiencing an active Davis problem (e.g., elevated error rate, CPU saturation).
Slowed Node Yellow border or warning glyph Entity is experiencing response time degradation or approaching warning thresholds.
Inactive Node Dotted border, semi-transparent / grayed out Entity has been detected in the environment during the timeframe, but has not communicated recently.
Active Connection Solid arrow line between nodes Live network or request traffic is actively flowing between the two entities in the current timeframe.
Historical Connection Dashed or dotted line between nodes Structural dependency exists based on historical discovery, but no traffic was recorded in the selected window.
Selected Node Highlighted boundary with callout panel Active focus entity; all directly connected upstream and downstream dependencies are illuminated.
Navigation and Filtering Pane
On the left side of the Smartscape view, Dynatrace provides a multi-layer selector that displays the total count of discovered entities at each of the five layers. Clicking any layer shifts the primary canvas to focus on that architectural tier, while maintaining cross-layer visual connectors to highlight how selected entities map into higher or lower layers.
Entity Cardinalities and Cross-Layer Mappings
Understanding entity relationships and cardinalities is essential for designing management zones, writing tagging rules, and passing the associate exam.
Layer Entity Type Direct Parent Entity Direct Child Entity Cardinality Rules
Application Web, Mobile, Custom, Synthetic N/A (Top of stack) Services One Application maps to One or Many Services. A Service can serve Multiple Applications.
Service Web Request, Web Service, DB, Queue Application Process Group Instance One Service can span Many PGIs (clustered service). One PGI can host Multiple Services.
Process Group Logical Process Cluster Host Group / N/A Process Group Instance One Process Group contains One or Many PGIs distributed across distinct hosts.
Process Group Instance Running OS Process Host & Process Group Services One PGI runs on Exactly One Host and belongs to Exactly One Process Group.
Host Physical, VM, Cloud Instance Data Center Process Group Instance One Host resides in Exactly One Data Center; One Host runs One or Many PGIs.
Data Center Cloud Zone, Region, Enterprise DC N/A (Base of stack) Hosts One Data Center contains One or Many Hosts.
Davis AI Root Cause Analysis & Topological Graph Traversal
The ultimate purpose of Smartscape is enabling Davis AI —the Dynatrace deterministic artificial intelligence engine. Traditional monitoring platforms rely on static alert rules that trigger hundreds of disjointed alerts when a core component fails (an alert storm).
How Davis Traverses Smartscape
When an anomaly is detected, Davis does not use probabilistic guesses or simple time-series correlation. Instead, Davis performs a deterministic graph traversal across Smartscape: 1. Anomaly Trigger ==> Davis detects degraded user experience on an Application (Apdex drop).
2. Downward Traversal ==> Traverses vertical dependencies from Application down to underlying Services.
3. Horizontal Tracing ==> Follows horizontal service flow calls to identify failing downstream microservices.
4. Process Inspection ==> Moves down vertically to the underlying Process Group Instance.
5. Host / OS Analysis ==> Inspects the Host layer: discovers disk saturation or hypervisor CPU steal.
6. Event Consolidation ==> Aggregates dozens of downstream symptoms into a SINGLE root-cause problem card.
By evaluating the causal tree across Smartscape, Davis eliminates alert noise, clearly differentiates between root causes and consequential symptoms, and dynamically calculates the business blast radius across all affected applications and user sessions.