Saltar al contenido
Marketplace

dt-migration

de dynatrace

Migrate Dynatrace classic and Gen2 entity-based DQL to Smartscape equivalents. Covers three scenarios. (1) mass data queries filtered by classic entity conditions — migrate to direct dimension filters first, Smartscape only as fallback; (2) mass data queries using entity subqueries for filtering — same dimension-first strategy; (3) pure entity list queries — migrate fetch dt.entity.* to smartscapeNodes. Also handles entityName, entityAttr, classicEntitySelector, and classic relationship patterns.

Resumen

SKILL.mdLeída en 4f9aa71

Smartscape Migration Skill

This skill migrates Dynatrace classic and Gen2 entity-based DQL queries and query patterns to Smartscape-based equivalents.

Load the dt-dql-essentials skill before writing final DQL so the translated query also follows current DQL syntax rules.

This skill focuses on Smartscape-oriented DQL migration only. It does not cover asset-level migration workflows.

Query Purpose Classification

Start here. The correct migration strategy depends on what the query is actually trying to do — not just which classic constructs it uses.

There are three distinct situations:

#SituationClassic anti-patternMigration strategy
1Mass data query filtered by entity conditionsclassicEntitySelector(...) inline in filter: of a timeseries, logs, or metrics queryResolve entity conditions to raw data dimensions first. Smartscape is a fallback, not the default.
2Mass data query using entity subquery for filteringfetch dt.entity.* inside in [...], lookup [...], or join [...] to filter the outer mass data querySame dimension-first strategy. Rewrite as raw dimension filter or in [smartscapeNodes ...] subquery.
3Pure entity list queryfetch dt.entity.* used standalone or as the primary result sourcesmartscapeNodes is the only valid path. No raw dimension alternative exists.

Decision:

  • Situations 1 or 2 — load references/mass-data-filtering-strategy.md and complete all steps including field discovery (Step 2) and equivalence verification (Step 4). Do not skip the fieldsSnapshot gates — they determine which approach is viable. Only fall back to the Migration Workflow below when the entity-type mapping or relationship traversal is needed to complete a Smartscape subquery.
  • Situation 3 — continue with the Migration Workflow and entity mapping table below.

Note: Situation 3 has a sub-case where classicEntitySelector is used to filter the entities returned by fetch dt.entity.*. This is rare and follows the same smartscapeNodes path — resolve the selector conditions using references/mass-data-filtering-strategy.md Step 1B, then apply them as node filters in smartscapeNodes.

Migration Workflow

Follow this order for Situation 3 (pure entity list queries) and for constructing Smartscape subqueries in Situations 1 and 2:

  1. Identify the classic input pattern:
    • fetch dt.entity.*
    • classicEntitySelector(...)
    • relationship field access such as belongs_to[...], runs[...], instance_of[...]
    • signal or event queries using dt.entity.*
  2. Identify the involved classic entity types.
  3. Look up the Smartscape replacement in the core entity mapping table below.
  4. Check which classic DQL constructs need explicit migration.
  5. Rewrite the query using Smartscape primitives:
    • smartscapeNodes
    • smartscapeEdges
    • traverse
    • references
    • getNodeName()
    • getNodeField()
  6. Check for special cases, unsupported entities, or ID assumptions.
  7. Load the matching detailed references for the specific entity family or migration pattern.

For the full migration process and output expectations, load references/migration-workflow.md.

Core Entity Mapping Table

Use this compact table first for common migrations. For the full mapping set, load references/type-mappings.md.

Classic / Gen2 entitySmartscape fieldSmartscape node typeNotes
dt.entity.hostdt.smartscape.hostHOSTStandard host mapping
dt.entity.servicedt.smartscape.serviceSERVICEStandard service mapping
dt.entity.process_group_instancedt.smartscape.processPROCESSProcess instance maps directly
dt.entity.container_group_instancedt.smartscape.containerCONTAINERContainer-group instance maps directly
dt.entity.kubernetes_clusterdt.smartscape.k8s_clusterK8S_CLUSTERKubernetes cluster
dt.entity.kubernetes_nodedt.smartscape.k8s_nodeK8S_NODEKubernetes node
dt.entity.kubernetes_servicedt.smartscape.k8s_serviceK8S_SERVICEKubernetes service
dt.entity.cloud_applicationmultiple workload fieldsmultiple K8S workload node typesMaps to multiple workload types; load the cloud-application guide
dt.entity.cloud_application_instancedt.smartscape.k8s_podK8S_PODClassic cloud app instance becomes pod
dt.entity.cloud_application_namespacedt.smartscape.k8s_namespaceK8S_NAMESPACENamespace mapping
dt.entity.applicationdt.smartscape.frontendFRONTENDFrontend application mapping
dt.entity.aws_lambda_functiondt.smartscape.aws.lambda_functionAWS_LAMBDA_FUNCTIONCloud-function entity mapping

DQL Constructs to Inspect During Migration

These classic constructs usually need explicit rewriting:

Classic constructTypical Smartscape replacementNotes
entityName(x)name or getNodeName(x)Prefer name when querying nodes directly
entityAttr(x, "...")direct node field or getNodeField(x, "...")Prefer direct fields when available
classicEntitySelector(...)node filters plus traverseStart from the constrained side; for mass data queries see mass-data-filtering-strategy.md first
dt.entity.* in signal queriesdt.smartscape.*Applies to by, filter, fieldsAdd, expand, and related clauses
belongs_to[...], runs[...], instance_of[...]traverse or references[...]references works only for static edges
classic entity ID filtersSmartscape idDo not reuse classic IDs blindly
affected_entity_ids and affected_entity_typessmartscape.affected_entitiesOne record array replaces the two parallel arrays; each record has id, type, and name

For the detailed function-by-function guide, load references/dql-function-migration.md.

Special Cases

Do not translate these patterns literally:

  • Host group — no standalone Smartscape entity; use fields on HOST
  • Process group — no standalone Smartscape entity; use fields on PROCESS
  • Container group — no standalone Smartscape entity; preserve output shape with placeholders if needed
  • Classic IDs — classic entity IDs do not carry over to Smartscape automatically
  • Planned, missing, or not-planned mappings — check the full mapping table before assuming direct support

Load references/special-cases.md before migrating these patterns.

Entity-Focused Guides

When a migration centers on a specific entity family, load the matching detailed guide:

Each guide explains:

  • what the classic entity represented
  • what the Smartscape replacement is
  • which fields usually change
  • how relationships are migrated
  • common examples and pitfalls

References

Archivos 18 archivos

y 6 archivos más en GitHub

Instálala a mano

Deska ejecuta esto por ti, para cada agente que elijas. Para ejecutarlo tú en una terminal:

npx skills add dynatrace/dynatrace-for-ai --skill dt-migration

Más de dynatrace

  • dt-dql-essentialsdynatraceCore DQL syntax, pitfalls, query patterns, and query optimization. Load to write, build, fix, or OPTIMIZE a DQL query — prevents syntax errors and makes queries faster, more efficient, and cheaper (less data scanned = lower query consumption/cost per run). Covers fetch commands, data models, field namespaces, time alignment, entity/smartscape patterns, metric discovery, and performance/cost optimization (filter early, bucket filters, short time ranges, field selection, sampling, cardinality). Trigger: \"write/build/fix a DQL query\", \"DQL syntax\", \"query logs/spans/metrics\", \"create a timeseries\", \"optimize my DQL\", \"make my query faster/cheaper\", \"reduce DQL cost/consumption/scanned data\", \"keep DQL cost under control\". Do NOT use to explain an existing query or answer product questions. For MONITORING a tenant's ACTUAL query consumption/billing (how much queries cost, who scanned most, cost trends) use dt-platform-costs — this tunes the query text, not billing data.2,600 instalaciones en skills.sh0
  • dt-app-dashboardsdynatraceWork with Dynatrace dashboards - create, modify, query, and analyze dashboard JSON including tiles, layouts, DQL queries, variables, and visualizations.2,500 instalaciones en skills.sh0
  • dt-app-notebooksdynatraceWork with Dynatrace notebooks - create, modify, query, and analyze notebook JSON including sections, DQL queries, and visualizations.2,400 instalaciones en skills.sh0
  • dt-obs-hostsdynatraceHost and process metrics including CPU, memory, disk, network, containers, and process-level telemetry. Use when analyzing infrastructure health, resource utilization, process consumption, or host discovery. Also use when building timeseries queries for host metrics that feed into analytical workflows like anomaly detection, forecasting, or seasonality analysis. Trigger: "show hosts", "CPU usage", "memory utilization", "disk space", "high CPU", "top hosts by CPU", "top processes by memory", "Linux hosts in AWS", "what databases are running", "infrastructure costs by cost center", "hosts running EOL Java", "container monitoring", "listening ports", "process resource consumption", "CPU forecast", "memory anomaly", "host seasonality", "OneAgent mode", "OneAgent version", "GCP hosts". Do NOT use for explaining existing queries, product documentation questions, Kubernetes pod/workload queries (use dt-obs-kubernetes), AWS cloud resource inventory (use dt-obs-aws), or service-level metrics (use dt-obs-services).2,400 instalaciones en skills.sh0
  • dt-obs-kubernetesdynatraceKubernetes cluster, pod, node, and workload monitoring. Use when analyzing K8s health, resource optimization, pod failures, OOMKills, scheduling, or security posture. Also use for Kubernetes operational events like pod restarts, OOM events, evictions, and cluster event history. Trigger: "Kubernetes pods", "K8s cluster health", "OOMKill", "pod restarts", "container CPU", "namespace resource usage", "over-provisioned pods", "privileged containers", "pod placement", "K8s node capacity", "running containers by cluster", "workload scheduling", "pod evictions", "K8s labels and annotations", "kubernetes events", "pod restart events", "OOM events", "K8s event history". Do NOT use for explaining existing queries, product documentation questions, AWS-specific resource queries, service-level RED metrics, distributed tracing, or log analysis — use the relevant skill instead.2,400 instalaciones en skills.sh0
Todas las skills de dynatrace