5.1 The 5-Layer Smartscape Topology: Datacenter to Application
Key Takeaways
- 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.
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, AzureEast US, or Google Cloudeurope-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.
A site reliability engineer investigates an incident where a shared database cluster becomes completely unresponsive due to a storage volume saturation event. Dynatrace Davis AI detects the issue and raises a single root-cause problem card, linking 14 distinct frontend microservices and two customer-facing web applications to this incident. What architectural mechanism in Smartscape allows Davis to consolidate these multiple service degradation events into a single root cause problem instead of generating 16 separate alerts?
During a Smartscape topology review, an administrator observes that an enterprise e-commerce platform shows a single Process Group named "OrderProcessing_Tomcat", but when inspecting the Host layer, three distinct virtual machines (app-prod-01, app-prod-02, app-prod-03) are listed as running this software. How does Dynatrace define and differentiate between a Process Group (PG) and a Process Group Instance (PGI) in this deployment?
An application architect is analyzing the Smartscape topology view for a complex microservices architecture. While reviewing the connection lines between nodes, the architect notices that some connecting lines are rendered as solid arrows while other lines are displayed as dashed or dotted lines. Furthermore, a particular service node is surrounded by a dotted border and appears semi-transparent. What do these visual conventions signify within the Dynatrace Smartscape user interface?