> For the complete documentation index, see llms.txt.
Skip to main content

Check out Port for yourself ➜ 

Ingest cloud resources using APM integrations

Implement with AI

Send this guide to your coding agent.

Prerequisite: Install Port MCP

Open in ClaudeOpen in CodexOpen in Cursor
Open plan mode. Implement this Port guide in my org via MCP:

https://docs.port.io/guides/all/ingest-cloud-resources-using-apm-integrations

Goal: get the guide's core flow working end-to-end in my org; adapting it to fit my existing setup takes priority over matching the guide 1:1.

Plan:
1. Confirm MCP is connected, in the right org, with sufficient permissions.
2. Diff the guide's data model (blueprints, properties, relations, actions, agents, automations, integrations, secrets) against mine.
3. Propose adaptations for gaps, reusing existing blueprints/relations over guide-named duplicates.
4. Flag what needs a UI click, credential, or secret from me, testing MCP capability empirically before ruling anything out.
5. Stop on any blocker and give me options. Approving this plan authorizes the writes it lists; pause only for writes beyond what's listed.

Build:
- Extend blueprint schema additively when upserting; don't remove or overwrite existing properties, and treat type conflicts as a blocker, not an auto-fix.
- List any mock data in the plan, minimal and labeled mock; once approved, seed it without re-asking, and tell me what you seeded.
- For anything the guide writes downstream (e.g. a webhook target), use a real entity, not a mock.
- For pages/widgets, use the real page identifier from the app URL, not a guessed slug.
- When you hit a UI step confirmed (not assumed) unsupported via MCP, pause, give exact clicks, then resume via MCP.
- Validate and give links after each meaningful step (only a tool-returned URL, no guessed paths); don't proceed if the last run wasn't a success.

Done:
- Confirm the guide's expected output exists and runs in Port.
- Summarize adaptations, seeded data, what was mocked or skipped, remaining UI steps, and how to verify.

This guide demonstrates how to ingest cloud resources monitored by Datadog, Dynatrace, or New Relic into Port.

Select your application performance monitoring (APM) provider once, and the provider tabs will stay synchronized throughout the guide.

Common use cases​

  • Map cloud resources monitored by Datadog, Dynatrace, or New Relic into Port.
  • Centralize cloud resource metadata from AWS, Azure, and GCP in your software catalog.
  • Track provider-specific health, identity, type, tag, and infrastructure data.
  • Assign team ownership to Dynatrace resources using labels, tags, or search queries.

Prerequisites​

Complete the prerequisites for your selected provider:

Set up data model​

Create the cloud resource blueprint for your selected provider.

Create the Datadog cloud resource blueprint

The blueprint captures host availability, platform, agent, source, and tag data from Datadog.

  1. Go to the Builder page.

  2. Click + Blueprint.

  3. Click Edit JSON.

  4. Copy and paste the following JSON configuration into the editor:

    Datadog cloud resource blueprint (Click to expand)
    {
      "identifier": "datadogCloudResource",
      "description": "This blueprint represents a cloud resource in Datadog",
      "title": "Datadog Cloud Resource",
      "icon": "Datadog",
      "schema": {
        "properties": {
          "up": {
            "type": "boolean",
            "title": "Is Running?",
            "description": "Is the host up?"
          },
          "host_name": {
            "type": "string",
            "title": "Host Name",
            "description": "the name of the host"
          },
          "description": {
            "type": "string",
            "title": "Description",
            "description": "the host description"
          },
          "platform": {
            "type": "string",
            "title": "Platform",
            "description": "the host platform"
          },
          "machine": {
            "type": "string",
            "title": "Machine",
            "description": "The CPU architecture of the host machine (e.g., amd64, x86, x64, arm, arm64)."
          },
          "cpu_cores": {
            "type": "number",
            "title": "CPU Cores",
            "description": "the host CPU cores"
          },
          "agent_version": {
            "type": "string",
            "title": "Datadog Agent Version",
            "description": "the Datadog agent version installed on the host"
          },
          "is_muted": {
            "type": "boolean",
            "title": "Is Host Muted?",
            "description": "Indicates whether alerts for that specific host are temporarily suppressed."
          },
          "sources": {
            "title": "Sources",
            "type": "array",
            "description": "Source or cloud provider associated with your host."
          },
          "tags": {
            "title": "Tags",
            "type": "object",
            "description": "Tags associated with the host."
          }
        },
        "required": []
      },
      "mirrorProperties": {},
      "calculationProperties": {},
      "relations": {}
    }

  5. Click Save to create the blueprint.

Configure the mapping​

Update your integration mapping to select cloud resources and create entities from them.

Update the Datadog integration mapping

The Datadog integration exposes monitored hosts through the host kind. This mapping selects hosts whose sources include AWS, Azure, GCP, or Google Compute Engine (gce).

  1. Go to the Data sources page of your portal.

  2. Select your Datadog integration.

  3. Add the following YAML block into the editor:

    Datadog cloud resource mapping (Click to expand)
    deleteDependentEntities: true
    createMissingRelatedEntities: true
    resources:
      - kind: host
        selector:
          query: >-
            [.sources[] | . as $source | ["azure", "gcp", "gce", "aws"] |
            contains([$source])] | any(.)
        port:
          entity:
            mappings:
              blueprint: '"datadogCloudResource"'
              identifier: .id | tostring
              title: .aws_name // .host_name
              properties:
                up: .up
                host_name: .host_name
                platform: .meta.platform
                is_muted: .is_muted
                machine: .meta.machine
                description: .description
                sources: .sources
                cpu_cores: .meta.cpuCores
                agent_version: .meta.agent_version
                tags: .tags_by_source

  4. Click Save & Resync to apply the mapping.

Assign Dynatrace team ownership​

Dynatrace supports multiple methods for assigning team ownership, including Kubernetes labels and annotations, host metadata, environment variables, tags, and management zones.

The examples below are complete mapping blocks. If you want to assign ownership, replace the base mapping from the previous section with the mapping that matches your preferred method.

If you want to apply the same ownership pattern to Port's default Dynatrace entity blueprint, replace "dynatraceEntityCloudResource" with "dynatraceEntity" in the relevant mapping.

If the default Dynatrace entity blueprint does not already have an owned_by relation, add it before applying an ownership mapping:

Team relation for the default Dynatrace entity blueprint (Click to expand)
"relations": {
  "owned_by": {
    "title": "Owned by",
    "target": "dynatraceTeam",
    "required": false,
    "many": true
  }
}

Choose one of the following YAML blocks:

This mapping reads team ownership from Kubernetes label keys such as dt.owner or owner.

Ownership mapping using Kubernetes labels and annotations (Click to expand)
deleteDependentEntities: true
createMissingRelatedEntities: true
enableMergeEntity: true
resources:
  - kind: entity
    selector:
      query: 'true'
      entityTypes:
        - CLOUD_APPLICATION
        - KUBERNETES_SERVICE
        - KUBERNETES_CLUSTER
        # Add more entity types.
      entityFields: firstSeenTms,lastSeenTms,tags,properties,managementZones,fromRelationships,toRelationships
    port:
      entity:
        mappings:
          identifier: .displayName | gsub(" "; "-")
          title: .displayName
          blueprint: '"dynatraceEntityCloudResource"'
          properties:
            firstSeen: .firstSeenTms / 1000 | todate
            lastSeen: .lastSeenTms / 1000 | todate
            type: .type
            tags: .tags[].stringRepresentation
            managementZone: .managementZones[0].name
          relations:
            owned_by: .properties.kubernetesLabels | to_entries | map(select(.key == "dt.owner" or .key == "owner") | .value) | if length == 0 then null else . end
Ownership keys

In this example, the dt.owner and owner keys from Kubernetes resource labels define ownership. Use the keys configured in your Dynatrace environment. For more details, see the Dynatrace ownership documentation.

After choosing a mapping:

  1. Go to the Data sources page of your portal.

  2. Select your Dynatrace integration.

  3. Replace the existing cloud resource mapping with the YAML block you chose.

  4. Click Save & Resync to apply the mapping.

Let's test it!​

Test the flow

After the sync finishes, open the Datadog Cloud Resource blueprint in your software catalog.

Confirm that Datadog hosts associated with AWS, Azure, or GCP were created:

Datadog cloud resources ingested into the Port catalog

Review provider entity types​

Review Datadog source values

The Datadog mapping selects hosts whose sources property contains one of these cloud provider values:

  • aws.
  • azure.
  • gcp.
  • gce.

Add or remove values in the mapping selector to match the sources configured in your Datadog environment.

More relevant guides​