Connect Dynatrace

Connect a Dynatrace account so leancosts shows your Dynatrace Platform Subscription (DPS) consumption next to your cloud spend: what each capability costs per day, how far the contract has burned, and what monitoring each Azure VM or App Service is costing you. leancosts is read-only here as everywhere: every call it makes to Dynatrace is a GET, apart from the two reads Dynatrace itself only exposes as POST: the OAuth token exchange and the token lookup that reports a token’s own scopes. For the full posture see Security and data handling.

Before you start

• You need account-level access in Dynatrace to create an OAuth client, and access to each environment to create an API token. In leancosts you need the connections-manage permission.
• Your account needs an active DPS subscription. Without one leancosts can still read your environments, but there is no booked cost to ingest and no contract to burn down.
• Dynatrace support is rolling out. If the Dynatrace card in the Add-connection picker is disabled and reads “Not enabled in this deployment”, there is nothing to set up yet; it opens when it is ready.

What leancosts reads, and what the credentials allow

Caution

Read this before you paste a secret. The connect form repeats it.

• What we read. The account’s DPS subscription with its budget and term, its per-day consumption and cost per capability, and (from each environment) the monitored hosts, the entities the billing metrics name (synthetic monitors, applications), and the billing metrics themselves. Money always comes from the account subscription; the environment metrics only split it across hosts.
• What the credentials can do. An account OAuth client with two read scopes and one API token per environment with four read scopes. leancosts never creates, edits or deletes anything in Dynatrace, and refuses a token that merely carries a write scope, naming the scope, at test time.
• How it is stored. The client secret and every API token are AES-256-GCM encrypted, the same primitive Azure service-principal secrets use, and never logged or echoed back.

1. Create the account OAuth client

In Dynatrace Account Management, open Identity & access management → OAuth clients and create a client for your account.

1. Give it a description you will recognise, for example leancosts read-only.
2. Grant exactly two scopes, both read:
   • account-env-read: the environment list.
   • account-uac-read: the subscription, its budget and its per-capability cost and usage.
3. Save, then copy the client id (dt0s02.…) and the client secret. Dynatrace shows the secret once.
4. Note your account UUID from the same Account Management area. It is the urn:dtaccount:<uuid> the token exchange is scoped to.

2. Create one API token per environment

In each Dynatrace environment you want connected, open Access tokens and generate a token with exactly these four scopes:

• entities.read: the monitored hosts and the synthetic and RUM entities.
• metrics.read: the builtin:billing.* series that split a day’s cost.
• settings.read and ReadConfig: the settings objects the sync reads, and the classic dashboards, metric events, Davis anomaly detectors and SLOs it checks before calling a billed metric key unused.

Give each token an expiry you can live with. leancosts reads the expiry back from Dynatrace on every test and counts it down on the connection (Open → Settings → Environments), so you do not have to keep your own reminder.

Caution

Do not add any write scope. The connection test refuses a token that carries one and names it.

Grail bucket retention lives behind a separate platform scope (storage:bucket-definitions:read) that an account OAuth client cannot always mint. If it is unavailable, everything else still works and only the log retention finding is withheld, with a reason.

3. Add the connection

1. In leancosts go to Admin → Connections and click Add connection.
2. Pick Dynatrace.
3. Give the connection a nickname, paste the account UUID, client id and client secret, then click Test account. leancosts lists the environments this account can reach and the active subscription. Nothing is stored yet.
4. Tick the environments to connect, paste the API token for each, pick a sync schedule (default every 6 hours) and click Create connection.
5. The row shows Validating… while leancosts proves the credentials, then Connected. Test re-runs that check any time and reports the subscription name and the environment count.

The first sync reads the subscription, then the monitored estate per environment, then one cost and one usage call per capability, three months back by default. Sync on the row, and Sync now and Force refresh in the connection’s Settings, work like the cloud connectors; Pause stops the schedule without removing anything. Open on the connection row shows its sheet: Settings holds the name, the sync schedule, the credential and Remove; Console tails the sync log.

4. Where the data lands

• Costs gains Dynatrace spend as its own provider: the DPS capability (Full-Stack Monitoring, Log Management & Analytics - Ingest & Process, …) is the service, and the money is what Dynatrace booked for that day. Budgets, forecasts, anomaly alerts and digests treat it like any other spend.
• Commitments gains your DPS contract, with both the committed total and the consumed amount coming from Dynatrace’s own API. It carries a from Dynatrace account badge and cannot be edited by hand: the next sync would overwrite it.
• The Azure resource drawer shows the Dynatrace share of a VM or App Service the account monitors, as its own line marked with the Dynatrace glyph. The resource total goes up, because that monitoring really is part of what the resource costs you.
• Dynatrace is the dedicated page in the sidebar: spend and contract burn, a daily stacked series by capability, breakdowns by capability, host and environment, and the current findings.
• The Savings Register gains six Dynatrace findings: Full-Stack monitoring on a host with no discovered service, Full-Stack on App Service instances, a site watched by both Dynatrace and Application Insights, a Grail log bucket retaining above the default, a single-URL browser monitor, and an application recording a replay for nearly every session. Every figure is priced from your own booked cost divided by your own booked usage, never a Dynatrace list price.
• Dynatrace spend does not count toward your leancosts bill. You connected it for governance, not for metering.

Verify

You should see, within one sync:

1. The connection row reads Connected and its meta line names the account, the linked DPS subscription and the environment count.
2. The connection’s Console tab shows three phases: subscription, estate, cost.
3. Costs, filtered to Dynatrace, totals the same as the account API’s own booked cost for the same days. Compare directly:

ACCOUNT=00000000-0000-0000-0000-000000000000
TOKEN=$(curl -sS -X POST https://sso.dynatrace.com/sso/oauth2/token \
  -d grant_type=client_credentials \
  -d client_id="$DT_CLIENT_ID" -d client_secret="$DT_CLIENT_SECRET" \
  -d resource="urn:dtaccount:$ACCOUNT" | jq -r .access_token)

curl -sS -H "Authorization: Bearer $TOKEN" \
  "https://api.dynatrace.com/sub/v2/accounts/$ACCOUNT/subscriptions/$SUB/cost?capabilityKeys=FULLSTACK_MONITORING" \
  | jq '[.data[].value] | add'

4. On the Dynatrace page, a capability you use that shows an em dash instead of a cost is not free: Dynatrace booked no money against it in that window, and hovering the dash says so.

Removing a connection

Open → Settings → Remove purges the host and entity rosters, the stored environments and their tokens, the DPS contract row and every Dynatrace cost row the connection ingested. The data cannot be refreshed once the connection is gone, so removal always purges. Delete the OAuth client and the API tokens in Dynatrace afterwards.