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

Check out Port for yourself ➜ 

Auto-discover service dependencies from your APM tools

Implement with AI

Send this guide to your coding agent.

Prerequisite: Install Port MCP

Your APM already knows which services call which services in production. Filling a depends on relation by hand does not scale, and a coding agent inside one repository cannot see the rest of the system.

Let's auto-discover those dependencies into a calls relation on your catalog service entities. We ingest the graph from New Relic, Datadog, or Dynatrace, then use catalog auto discovery to match APM names to services you already track in Port.

Select your APM provider once. The provider tabs stay synchronized through the rest of the guide.

Runtime topology, not source code

This map is who called whom in production, from APM telemetry. It is not a code-level graph of imports, functions, or files.

Common use cases​

  • Blast radius of a change. Ask which other services a pull request can affect, based on who calls whom in production.
  • Design review across a large system. Give an architect or an agent the service-to-service picture that no single repository contains.
  • Context for coding agents. Answer "which services consume this" from the catalog instead of searching every repository.

Prerequisites​

This guide assumes the following:

  • You have a Port account and have completed the onboarding process.
  • You have a service blueprint in your catalog (created during onboarding). If your identifier is Microservice or similar, use that identifier in the snippets below.
  • Catalog auto discovery is available in your organization (it uses Port AI).

Complete the prerequisite for your APM:

  • Port's New Relic integration is installed.
  • The default mapping already ingests newRelicService entities.

How it works​

  1. Ingest the APM graph. Each APM service becomes an entity with a dependencies relation to the services it calls.
  2. Add a calls relation on your catalog service blueprint (a self-relation from service to service).
  3. Run auto discovery so Port AI matches APM names to catalog services and proposes calls edges. You review and approve the suggestions.

APM identifiers are often GUIDs or vendor IDs, while catalog services use names such as payments. Auto discovery is the step that joins those two pictures. If your catalog identifiers already match APM service names, you can map calls with JQ instead.

Set up the catalog relation​

Let's add a calls relation on the service blueprint. This is the relation auto discovery will populate.

  1. Go to the Data model page in Port.

  2. Find the Service blueprint and click on it.

  3. Click the ... button, then choose Edit JSON.

  4. Add the following object to the existing relations object. Do not remove relations you already have.

    Calls relation (click to expand)
    "calls": {
    "title": "Calls",
    "description": "Services this service calls in production, from APM telemetry",
    "target": "service",
    "required": false,
    "many": true
    }
  5. Click Save.

If you already added depends_on from the calculate blast radius with AI guide, skip this relation and use depends_on in the discovery prompt later. Do not create both unless you want two copies of the same graph.

Ingest the APM dependency graph​

Add the APM-specific blueprint and mapping, then resync. After this step, Port holds the raw who-calls-whom graph from your APM.

Create the New Relic service dependency blueprint

This blueprint stores one entity per New Relic service. The dependencies relation lists the other New Relic services it calls (outbound CALLS relationships).

  1. Go to the Data model page in Port.

  2. Click + Blueprint.

  3. Click Edit JSON.

  4. Copy and paste the following JSON, then click Save.

    New Relic service dependency blueprint (click to expand)
    {
    "identifier": "newRelicServiceDependency",
    "description": "This blueprint represents the services a New Relic service calls.",
    "title": "New Relic Service Dependency",
    "icon": "NewRelic",
    "schema": {
    "properties": {},
    "required": []
    },
    "mirrorProperties": {},
    "calculationProperties": {},
    "aggregationProperties": {},
    "relations": {
    "dependencies": {
    "title": "Depends on",
    "description": "Services this service calls",
    "target": "newRelicService",
    "required": false,
    "many": true
    }
    }
    }

Add the New Relic mapping

This kind is not part of the default New Relic mapping. entityQueryFilter is required. It chooses which services are included in the map. Only outbound CALLS to other SERVICE or APPLICATION entities in that filter are ingested.

  1. Go to the Connectors page in Port.

  2. Select your New Relic integration.

  3. Add the following resource to the existing resources list. Keep your newRelicService mapping.

    New Relic service dependency mapping (click to expand)
    - kind: newRelicServiceDependency
    selector:
    query: "true"
    entityQueryFilter: "type in ('SERVICE','APPLICATION')"
    port:
    entity:
    mappings:
    blueprint: '"newRelicServiceDependency"'
    identifier: .guid
    title: .name
    relations:
    dependencies: .calls
  4. Click Save & Resync.

Live events do not refresh this kind. Run a resync whenever you need an up-to-date map.

Verify the APM graph​

Before you run auto discovery, confirm the raw graph landed in Port.

  1. Open the Catalog page and select New Relic Service Dependency.
  2. Open a service that you know calls others in New Relic.
  3. Confirm the Depends on relation lists other newRelicService entities.

If the relation is empty, check that entityQueryFilter is set correctly.

Run auto discovery​

Auto discovery reads the APM graph and proposes calls on your catalog service entities. You approve every suggestion, so a bad name match does not silently rewrite the catalog.

  1. Go to the Catalog page in Port.
  2. Open the catalog page for your Service blueprint.
  3. Click the Port AI iconPort AI icon button in the bottom right corner.
  4. Paste the prompt for your APM:
Populate "calls" relations on existing service entities.
Map dependencies from New Relic: use newRelicService entities and
newRelicServiceDependency "dependencies" relations to identify which
catalog services communicate with each other.
Match by title or identifier. Prefer updating existing services.
Only suggest creating a service when no catalog match exists.
  1. Select the related blueprints to analyze:
  • newRelicService.
  • newRelicServiceDependency.
  1. Click Discover.

    Catalog auto discovery form with instructions and related blueprints selected
  2. Review the Update and Create lists. For a catalog that already has services, most suggestions should be Update rows that fill calls.

  3. Approve suggestions you trust.

    Catalog auto discovery results with create and update suggestions
Discovery evaluates 500 entities per blueprint

Each run analyzes the 500 most recently added entities from each related blueprint, and only the first 100 characters of each property. For a large catalog, approve a batch, then run discovery again.

What you should see​

After you approve, a catalog service looks like this. The calls relation points at other service entities.

{
"identifier": "payments",
"title": "payments",
"blueprint": "service",
"relations": {
"calls": [
"billing",
"checkout",
"notifications"
]
}
}

Open a few services you know well and compare calls with the APM service map. That is the fastest way to catch a bad match.

Troubleshooting​

  • APM dependency entities have empty dependencies. For New Relic, confirm entityQueryFilter is set. For Datadog, confirm environment matches your service map. For Dynatrace, confirm fromRelationships is in entityFields and that you resynced.
  • Discovery creates new services instead of updating existing ones. Strengthen the prompt to match on title and identifier, and to prefer updates. Decline the extra creates.
  • A related blueprint does not appear in the form. Add a relation from Service to that blueprint, then run discovery again.
  • Suggestions look noisy. Auto discovery is a proposal step. Decline weak matches. Re-run after you have approved a clean batch so later runs see a better catalog.