New Service Graph Connector for Observability – Dynatrace SaaS

[Shanay Shah]

Why a new connector

Dynatrace 3rd Gen changed the foundation the connector is built on. Grail and DQL replace the legacy Entity API, giving a single unified query model for more complete CIs, richer attributes, and better lifecycle accuracy. The K8s and cloud entity model was redesigned (cluster UID, AWS ARN) to simplify CMDB mapping, host-to-process-to-service interlinking is more accurate, and alerts arrive fully populated with root cause, affected entities, and severity. Piping Dynatrace AI insights directly into ServiceNow AI Agents is a planned future capability.

What it helps you achieve:

• Enrich the CMDB alongside Discovery so hosts, services, and processes Dynatrace sees are represented with accurate attributes.
• Build automated service topology from Dynatrace's Smartscape dependencies instead of maintaining maps by hand.
• Link Dynatrace alerts to the correct CI so incidents carry service and ownership context.
• Keep a clean multi-source CMDB where Dynatrace data reconciles into existing records rather than duplicating them.

Classic vs. new — the key differences

If you are on Dynatrace SaaS 3rd Gen, use the new SaaS connector. If you are on Dynatrace-managed (self-hosted) or a legacy SaaS environment, continue with the classic connector. Classic connector APIs are not being deprecated at this time.

	Classic connector	New SaaS connector
Target platform	Dynatrace-managed (self-hosted) or legacy SaaS	Dynatrace SaaS, 3rd Generation (Grail)
Data access	Classic REST / Entity API	DQL queries against Grail
Authentication	Classic API tokens	Platform tokens with fine-grained scopes (storage:entities:read, storage:smartscape:read)
Lifecycle / staleness	No automatic retirement of stale CIs	last_discovered populated; for configuring customer automated retirement
Filtering	Management zones	Segments
Hosts	MAC, serial, manufacturer, model, CPU, OS, and virtualisation flag also populated, starting v1.15	No major change from classic — MAC, serial, manufacturer, model, CPU, OS, and virtualisation flag are populated
Process	Starting v1.15: process CI naming aligned to Discovery conventions; Windows path normalisation resolves duplicates	Same enhancements are available in the new connector
Process Groups	Populated, often duplicated in the CMDB for each service	No longer imported, a direct Service-Process-Host relationship is established instead.
Tags	Populated for Hosts, Services, Applications, and other entities except Process and Process Group CIs	Populated for Hosts. Not yet available for Services and Frontends (planned — see Roadmap section)
Services, Frontends	Services and Applications are populated into the CMDB as Calculated Application Services	Applications are now renamed to Frontends. ServiceType filter is not available in the new API to filter out specific Services.
Kubernetes and Cloud	Limited data	Richer attributes and relationships planned — see Roadmap section
Databases	Limited data, ingested as part of Services and populated in the Application Service table	Planned as first-class entities (Roadmap); will be populated into the appropriate CMDB tables

 

 

Roadmap — available now and coming next

Organized by the four outcomes the connector is built around.

 

Enriching the CMDB

Dynatrace entities appear in the right CI classes with the right key attributes.

Available now — v1.1, July 2026

• Hosts, Processes
• Services & Frontends — without tags and filtering
• Richer host attributes for Windows and Linux servers: MAC, serial, manufacturer, model, CPU, OS, virtualization flag

v1.2 — September 2026

• Containers, Clusters, Nodes, Namespaces, Pods, Kubernetes workloads, Kubernetes Services
• Kubernetes services linked to Application Services; labels and annotations preserved as tags

Q4 2026 / Q1 2027

• Services & Frontends — improvements
• Cloud Infrastructure CIs
• Databases

For the full list of target CI classes and mapped attributes, see the SGC Dynatrace documentation.

 

Reconcile without duplicates

Dynatrace CIs appear cleanly alongside Discovery and cloud connectors — no duplicates, no flapping values.

Available now — v1.1, July 2026

• Host enrichment (Windows & Linux): MAC, serial, manufacturer, model, CPU, OS version, virtualization flag populated → stronger matching, fewer duplicates against Discovery
• Process CI names aligned with Discovery conventions for MSSQL, NGINX, Apache, IIS, and WebSphere
• WebSphere process CIs now include cell and node attributes, improving reconciliation accuracy against Discovery
• Containerized processes filtered out by default to reduce duplicate Application CIs
• Windows process path separator and formatting inconsistencies normalized, reducing duplicate Application CIs

v1.2 — September 2026

• Process quality fixes (DB2, MSSQL, Apache, IIS, PostgreSQL) — naming alignment and missing attribute mappings for cleaner reconciliation across Application CI classes
• VM-to-server relationships: virtual machine CIs, where present in the CMDB, linked to their Server CI imported as Host
• Kubernetes cluster de-duplication and entity-bloat controls; Kubernetes labels and annotations

 

Lifecycle, governance, and scale

Auto-retire stale CIs and filter data to avoid CMDB bloat.

Available now — v1.1, July 2026

• last_discovered populated, providing the foundation for lifecycle management through CMDB Data Manager retire/delete policies
• Property to disable service-to-service relationships where they create noise or performance impact at scale — disabled by default
• Segment to filter imported data, replacing management zones from the classic connector.  Currently only one segment can be configured, and only static segments are supported. Variable-based segments are not yet supported for filtering.

Not in scope

• CMDB Data Manager retire/delete policies are customer-configured, not shipped by the connector
• Bidirectional or shared services are not cleanly handled or accurately captured in service maps

 

Service maps, alert routing, and AIOps

Service maps reflect real dependencies mapped to business services; alerts route to the correct CI with ownership and business context.

Available now — v1.1, July 2026

• Tags for Hosts
• Service-Process-Host relationships
• Front-end entities mapped to their dependent services, improving service topology visibility in ServiceNow
• No process groups

v1.2 — September 2026

• Dynatrace Event Connector updates for improved CI linkage for entities ingested through the connector
• Kubernetes services linked to Application Services; labels and annotations preserved as tags

Q1 2027

• Tags for Services and Frontends

Not in scope

• No out-of-the-box bridge today from Dynatrace's Technical Services to ServiceNow Business Services
• Customers can explore ServiceNow tag-based service mapping, Unified Mapping, or custom transforms to connect technical and business services using Dynatrace tags and data

Limitations, Known issues and Migration FAQs

 

Limitations:

• Tag values are not received for Services and Frontends through the new APIs. This is a gap compared with the classic connector; tag support for Services and Frontends is planned for Q1 2027 or when Dynatrace API support is available.
• No serviceType filter for Services in the new API. As a result, all Service types are ingested into ServiceNow — there is currently no way to narrow ingestion by service type.
• Management zones are replaced by Segments. Currently only one segment can be configured, and only static segments are supported. Variable-based segments are not yet supported for filtering.

Known issues:

PRB	Issue	Workaround	Fix
PRB2052492	Smartscape-ID-based filtering causes pagination requests to fail, producing errors and incomplete data ingestion. Root cause: the connector's pagination logic assumes Smartscape IDs are strings, but Dynatrace changed the underlying ID type.	—	Fixed in v1.1.1, now available in the Store.
PRB2041390	The SGO-Dynatrace SaaS process job terminates when the Dynatrace API returns an HTTP 202. Occurs intermittently when a DQL response is not generated within 60 seconds (a hard limit in the Dynatrace APIs).	Re-run the job manually. It is most likely on the first run (the initial full pull); subsequent jobs pull deltas, so volumes and the chance of recurrence are low.	Planned for the v1.1.2 August release.

 

Frequently asked questions

Q: How do I migrate from Classic connector and start using Dynatrace SaaS?

Recommended approach:
1. Upgrade the existing classic connector to Dynatrace v1.15.
2. Install and configure the new connector in a sub-production environment.
3. Disable the scheduled import jobs for the classic connector in that environment.
4. Validate data coverage — confirm entities are imported and key attributes are populated. Check reconciliation behaviour against your other discovery sources.
5. Share any issues encountered with the ServiceNow Product team.
6. Ensure all requirements are met before moving to production.

Q: Can I run both connectors at the same time?

No. Running both in parallel is not recommended — it can create duplicate CIs for Application (cmdb_ci_appl) records. Disable the scheduled import jobs of the classic connector before activating the new one.

Q: What happens to existing CI relationships and identifiers?

Server CIs (Hosts): The new connector populates richer identification attributes (MAC, serial, manufacturer) that align with IRE identification rules — in most cases existing Server CIs reconcile automatically without duplication.

Application Services (Services & Frontends): Reconciliation logic for these classes is built in. Records created by the classic connector should be matched and updated rather than duplicated. 

Application CIs (Process): IRE reconciles on available identifiers. Some process/application CIs may not fully reconcile due to identifier differences between the classic and new connectors. The migration cleanup script is available to configure that identifies and cleans up duplicate records.