DEV Community

Cover image for Managing multiple Dynatrace Managed environments and licence quotas in the CMC
Span Observer
Span Observer

Posted on Originally published at span.observer

Managing multiple Dynatrace Managed environments and licence quotas in the CMC

#administration #clusterapi #cmc #dynatracemanaged

A Dynatrace Managed cluster rarely serves just one team, so the question of how to organise Dynatrace Managed environments comes up quickly. Before long, production sits next to pre-production, a subsidiary asks for its own space, a contractor needs to see its applications without access to anything else, and finance wants to know who consumes what. Without a clear structure, you end up with a single overloaded environment, tangled permissions and a licence used up by whichever team deployed its agents fastest.

This is a Managed-specific topic. Your licence defines a global volume of units (host units, user sessions, synthetic monitors, log or ingestion volumes depending on your model) that you share out between environments in the Cluster Management Console. The cluster will not arbitrate for you: if an environment has no quota, it can consume until the shared pool runs dry.

This article shows how to structure several environments on one cluster, assign and monitor quotas, and automate these tasks with the Cluster API.

Dynatrace Managed environments: the unit of isolation

Each Managed environment is a logically isolated space, reachable at https://{your-domain}/e/{environment-id}. It has its own data, configuration, API tokens, alerting rules and user groups. Agents in one environment cannot see those in another, and data never crosses over.

However, all environments share the cluster’s physical resources: CPU, memory, disk, Cassandra and Elasticsearch storage. Isolation is logical, not physical, which has two practical consequences:

Ways to split

Strategy Pros Cons
By stage (prod / non-prod) Simple, shields production from test noise Traces do not cross environments
By entity (subsidiary, customer, BU) Strong data isolation and easy chargeback No end-to-end view across entities
Single environment + management zones End-to-end tracing, a single configuration More complex permissions, no per-team quota

The rule of thumb: split environments when data isolation or chargeback is a requirement, and stay in one environment (with management zones) when applications talk to each other and you want complete distributed traces.

Understanding quotas

In the CMC, each environment can be given limits per unit type. These quotas apply to the classic licence model: they are not available with Dynatrace Platform Subscription (DPS). You will typically find:

  • Host units: consumed by OneAgents, weighted by host memory and monitoring mode.
  • Sessions / DEM units: consumed by Real User Monitoring and synthetic monitors.
  • Ingestion units (custom metrics, logs, agentless traces), depending on the model.

A quota can be absolute (a fixed cap) or left unlimited, in which case the environment draws from the shared pool. When the cap is reached, the behaviour depends on the unit type: new hosts are refused, extra sessions are no longer captured, and so on. Check this behaviour precisely for your version before setting tight caps in production.

Step-by-step tutorial

Step 1 — Take stock of the licence

In the CMC, open the licence page and note the total volume of each unit type, the expiry date and current consumption. In connected mode, this information is synchronised with Mission Control; in offline mode, make sure the imported licence key is up to date.

Step 2 — Create a Cluster API token

In the CMC, generate a Cluster API token with the Service Provider API permission (ServiceProviderAPI), required by the environment calls. Keep it in a vault: it grants administrative access to the whole cluster.

Step 3 — List existing environments 

curl -sS "https://{your-domain}/api/cluster/v2/environments" \
  -H "Authorization: Api-Token {cluster-token}" | python3 -m json.tool
Enter fullscreen mode Exit fullscreen mode

For each environment, the response gives its ID, name, state and tags; quotas and consumption only appear with the ?includeConsumptionInfo=true parameter.

Step 4 — Create an environment

Through the CMC (Environments menu, then create), or through the API:

curl -sS -X POST "https://{your-domain}/api/cluster/v2/environments" \
  -H "Authorization: Api-Token {cluster-token}" \
  -H "Content-Type: application/json" \
  -d '{
        "name": "{environment-name}",
        "state": "ENABLED",
        "tags": ["{entity}", "{stage}"]
      }'
Enter fullscreen mode Exit fullscreen mode

The response returns the new environment’s ID. The exact body schema (tag, quota and storage fields) varies between versions: check the Cluster API documentation for your cluster, available from the CMC.

Step 5 — Set the quotas

In the CMC, open the environment and fill in the limits per unit type. Cluster API v2 also lets you update an environment’s configuration, quotas included:

curl -sS "https://{your-domain}/api/cluster/v2/environments/{environment-id}?includeConsumptionInfo=true" \
  -H "Authorization: Api-Token {cluster-token}" -o env.json

# Edit the quotas section in env.json, then:
curl -sS -X PUT "https://{your-domain}/api/cluster/v2/environments/{environment-id}" \
  -H "Authorization: Api-Token {cluster-token}" \
  -H "Content-Type: application/json" \
  -d @env.json
Enter fullscreen mode Exit fullscreen mode

Working read-modify-write avoids accidentally overwriting other environment settings.

Step 6 — Configure access rights

In the CMC, create user groups (or map your LDAP/SAML groups) and give them permissions per environment: read access, administration, or access restricted to certain management zones. By default, an environment administrator has no access to the CMC.

Step 7 — Monitor consumption

Check the CMC licence page regularly; it breaks consumption down by environment. For automated tracking, query the Cluster API periodically and push the result into your reporting tool:

curl -sS "https://{your-domain}/api/cluster/v2/environments?includeConsumptionInfo=true" \
  -H "Authorization: Api-Token {cluster-token}" \
  -o "/var/tmp/environments-$(date +%F).json"
Enter fullscreen mode Exit fullscreen mode

Day-to-day governance

  1. Keep an unassigned margin in the pool (for example 10 to 15%) for emergencies and new projects.
  2. Review quotas quarterly, based on actual consumption rather than initial requests.
  3. Document who can request a quota increase and who approves it.
  4. Alert before a cap is reached, not after: an 80% threshold leaves time to act.

Best practices

  • Limit the number of environments: each one adds configuration to maintain.
  • Give environments explicit names and add entity and stage tags.
  • Set quotas on every non-production environment to protect production.
  • Handle Cluster API tokens as carefully as root accounts.
  • Plan cluster capacity (disk, node memory) for the sum of all environments and their retention.
  • Automate environment creation through the API to guarantee consistent configuration.

Frequently asked questions

Should each team get its own environment?

Not necessarily. Split environments when data isolation or chargeback is a requirement; when applications talk to each other, a single environment divided into management zones keeps distributed traces complete.

What happens when an environment reaches its quota?

The behaviour depends on the unit type: new hosts are refused, extra sessions are no longer captured, and so on. An environment without a quota draws from the shared pool until it runs dry, which is why an alert at around 80% is worth having.

Does an environment administrator have access to the CMC?

No, not by default. Rights are granted per environment to user groups; CMC access and Cluster API tokens belong to the administration of the whole cluster.

Conclusion

Multiple environments are one of Dynatrace Managed’s great strengths, but they hand the job of arbitration to the administrator. By choosing a consistent splitting strategy, assigning explicit quotas and automating monitoring through the Cluster API, you avoid unpleasant licence surprises and give every team an isolated, predictable space.

span.observer is an independent community blog, not affiliated with Dynatrace LLC. Dynatrace is a trademark of Dynatrace LLC. Always check values (ports, versions, sizes) against the official documentation for your Managed version.

Originally published on span.observer. French version: https://span.observer/fr/environnements-multi-tenant-quotas/.

Top comments (0)