Study guide
4.3 Host Groups, Host Naming Rules & Environmental Metadata Extraction
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
4.3 Host Groups, Host Naming Rules & Environmental Metadata Extraction
Key Takeaways Explain This Topic AI
A host can belong to strictly one Host Group at a time; this assignment is configured locally on the host at install time or via oneagentctl, requiring an agent restart to take effect.
Host Groups establish foundational administrative boundaries that partition Process Groups, govern OneAgent automatic update rollout waves, scope Management Zones, and control Davis AI problem alerting.
Server-side Host Naming Rules dynamically format host display names using placeholders, regex extraction, and ingested cloud tags without altering underlying immutable Dynatrace Entity IDs or requiring agent restarts.
Environmental metadata injected via hostcustomproperties.conf, environment variables (DT_CUSTOM_PROP), and cloud provider tags dynamically powers automated tagging, naming conventions, and management zone routing.
Last updated: September 2026
Host Groups, Host Naming Rules & Environmental Metadata Extraction
Exam Focus: The Dynatrace Certified Associate exam rigorously tests the architectural distinction between Host Groups, Host Names, Host Tags, and Custom Metadata Properties. Candidates must master where each property is configured, which ones require agent restarts, how Host Groups partition process groups, and how dynamic Host Naming Rules standardize cryptic cloud infrastructure names.
In large enterprise environments spanning thousands of physical servers, virtual machines, and cloud instances across multi-region deployments, organizing monitored infrastructure is paramount. Without deliberate organizational structures, navigating dashboards is chaotic, permissions cannot be partitioned, and automated alerting cannot be targeted effectively.
Dynatrace provides a multi-layered organizational model comprising Host Groups , dynamic Host Naming Rules , and Environmental Metadata Extraction .
Host Groups: Foundation of Enterprise Organization
A Host Group is a static administrative boundary assigned to a monitored host. Unlike tags, which are flexible labels, Host Groups establish deep structural partitions across the entire Dynatrace platform.
The Fundamental Rules of Host Groups
Single-Assignment Constraint: A host can belong to strictly one Host Group at any given time. Multi-group membership is prohibited.
Configured Locally on the Host: Host Groups cannot be assigned or changed via the Dynatrace web UI . They must be defined locally on the host during OneAgent installation or configured post-installation using oneagentctl .
OneAgent Service Restart Mandatory: Updating a host's Host Group assignment locally requires restarting the OneAgent service ( systemctl restart oneagent on Linux, or restarting the Dynatrace OneAgent Windows service).
- Local Configuration Syntax
- At Linux Installation: /bin/sh Dynatrace-OneAgent-Linux.sh --set-host-group=Production_Payment
At Windows Installation (MSI): msiexec.exe /i Dynatrace-OneAgent-Windows.msi /quiet HOST_GROUP="Production_Payment"
- Post-Installation via oneagentctl : # Linux
- /opt/dynatrace/oneagent/agent/tools/oneagentctl --set-host-group=Production_Payment
- systemctl restart oneagent
- # Windows
- .\oneagentctl.exe --set-host-group=Production_Payment
- Restart-Service "Dynatrace OneAgent"
- Cascading Architectural Impacts of Host Groups
Assigning a host to a Host Group triggers several powerful, platform-wide consequences:
Process Group Partitioning (Critical Exam Rule): As established in Section 4.2, identical software processes running on hosts in different Host Groups are automatically split into separate Process Groups. This provides clean environment isolation (e.g., separating Payment-Service [Dev] from Payment-Service [Prod] ).
OneAgent Update Management: Enterprise release policies are scoped by Host Group. Administrators configure update waves: staging host groups receive new OneAgent versions automatically on Day 1 (canary testing), while mission-critical production host groups are held on stable builds until manual approval.
Management Zone Scoping: Host Groups serve as primary boundary criteria for Management Zones, allowing security administrators to restrict team access to specific host clusters.
Davis AI Problem Alerting Profiles: Anomaly detection sensitivity and alert notifications can be filtered by Host Group, preventing development host threshold breaches from paging on-call production engineers.
Network Zone Routing Alignment: Host Groups can be mapped to specific Network Zones to ensure hosts route telemetry through proximate ActiveGates.
Host Naming Rules: Dynamic Centralized Name Formatting
In modern cloud environments (Amazon Web Services, Microsoft Azure, Google Cloud Platform), default hostnames generated by cloud providers are cryptic, ephemeral, and non-intuitive (e.g., ip-10-0-14-182.ec2.internal or vm-prod-east-08914b ).
While administrators can override a hostname locally using oneagentctl --set-host-name=CustomName , doing so across thousands of auto-scaling cloud instances is unmanageable. Dynatrace solves this through centralized, server-side Host Naming Rules ( Settings > Monitoring > Host naming rules ).
Structure of a Host Naming Rule
A Host Naming Rule consists of:
Conditions: Criteria determining which hosts the rule applies to (e.g., matching a specific Host Group, an IP range, an operating system, or cloud provider tags).
Naming Pattern (Format String): A template combining static text with dynamic placeholders extracted from the host entity model.
Commonly Tested Naming Placeholders
Placeholder Syntax Description / Source
{Host:DetectedName} The original operating system hostname detected by OneAgent.
{Host:HostGroup:Name} The name of the Host Group the host is assigned to.
{Host:IPAddress} The primary IP address of the host.
{Host:Environment:<key>} Custom environmental property extracted from hostcustomproperties.conf .
{Host:AWS:tag:<Key>} Value of an AWS EC2 instance tag ingested via AWS cloud integration.
{Host:Azure:tag:<Key>} Value of an Azure VM tag ingested via Azure monitor integration.
{Host:Google:label:<Key>} Value of a Google Cloud VM label ingested via GCP integration.
Example Production Naming Rule
An enterprise wants all AWS production virtual machines to follow the standardized naming format: [PROD] - {Host:AWS:tag:Application} - {Host:DetectedName} ({Host:AWS:tag:Region})
- Resulting host display in the Dynatrace console: [PROD] - CheckoutService - ip-10-0-14-182 (us-east-1)
- Non-Destructive and Dynamic Characteristics
UI Display Only: Host Naming Rules alter the user-facing display label of the host across dashboards, Smartscape, and alerts. They never alter the immutable internal Dynatrace Entity ID ( HOST-4A19B8C201F5E4D1 ).
No Agent Restart Required: Naming rules are evaluated dynamically on the Dynatrace server cluster. When a rule is created or modified, the new names reflect immediately across all matching hosts without restarting OneAgent or host operating systems.
Retroactive Application: Naming rules apply retroactively to all existing historical data for the host.
Environmental Metadata Extraction & Custom Properties
Dynatrace enriches host entities by ingesting environmental metadata from three distinct sources:
1. Built-in Cloud & Hypervisor Integrations
When Dynatrace connects to AWS, Azure, GCP, or VMware vCenter via an ActiveGate, metadata tags attached to instances (such as AWS EC2 tags, Azure resource group tags, or vCenter datacenter folders) are automatically ingested and attached to the corresponding Dynatrace host entity.
2. Local Configuration File: hostcustomproperties.conf
For on-premises bare-metal servers, private OpenStack clouds, or standalone virtual machines without cloud tag APIs, metadata is injected via a local text file named hostcustomproperties.conf .
File Path on Linux: /var/lib/dynatrace/oneagent/agent/config/hostcustomproperties.conf
File Path on Windows: %PROGRAMDATA%\dynatrace\oneagent\agent\config\hostcustomproperties.conf
- File Syntax: Simple key=value format (whitespace-trimmed, one property per line): CostCenter=10492
- Owner=RetailBanking
- Environment=Production
- DataClassification=PCI-DSS
- Tier=Backend
OneAgent reads this file during service execution and pushes the key-value pairs to the Dynatrace cluster entity model. These custom properties can then be referenced directly in Host Naming Rules ( {Host:Environment:Owner} ) and Automated Tagging Rules.
3. Environment Variables & Static Host Tags
DT_CUSTOM_PROP : Custom properties can be injected dynamically via the process environment variable DT_CUSTOM_PROP="Owner=DevOps DataCenter=East" .
Local Static Tags ( hostautotag.conf ): Located in /var/lib/dynatrace/oneagent/agent/config/hostautotag.conf , this file defines static tags attached directly to the host entity at the agent level.
Installer Tag Flag: --set-host-tag=Environment=Production --set-host-tag=PCI .
Architectural Synthesis: Host Groups vs. Names vs. Tags vs. Custom Properties
The following synthesis matrix clarifies the operational boundaries tested on the certification exam:
Architectural Attribute Host Group Host Naming Rule Host Tag Custom Metadata Property
Where Configured Locally on host (installer / oneagentctl ) Centrally in Dynatrace web UI / API Web UI (rules) or locally on host Locally on host ( hostcustomproperties.conf )
Cardinality per Host Strictly One (1:1) Strictly One (1:1) Unlimited (Many:1) Unlimited (Many:1)
Requires OneAgent Restart? Yes (to update or change) No (server-side dynamic) No (for server-side rules) No (dynamic discovery)
Partitions Process Groups? Yes (hard boundary) No (cosmetic only) No (metadata label only) No (metadata label only)
- Alters Dynatrace Entity ID? No No No No
- Affects Agent Update Policies? Yes (primary rollout vehicle) No No No
Primary Operational Purpose Structural partitioning, update control, baseline isolation Standardizing display names across cloud fleets Dynamic filtering, management zone routing, alerting Feeding data into naming rules and tagging engines