Extensions 2.0 Monitoring configurations limit

[Roeir5]

Hi everyone,

I’ve built a Python-based custom script extension (v2.0) that runs locally on each OneAgent host (no remote endpoints).
Each endpoint in the extension definition corresponds to a single script executed on the host itself.

Because these scripts are host-specific, we currently create a separate monitoring configuration per host rather than at the Host Group or Environment level. Our Dynatrace Managed cluster now contains roughly 1 000–2 000 hosts (mix of on-prem VMs, EC2 instances, and K8s nodes) that all require this extension.

I’d appreciate clarification on two points:

1. Configuration-per-extension limit
   I’ve read that each extension is capped at 100 monitoring configurations.

   • Is this limit hard-coded, or can it be increased on a Dynatrace Managed deployment?

2. Scaling strategy
   If the limit is fixed and we must create multiple copies of the extension to cover every host:

   • Are there recommended approaches for minimizing operational overhead (e.g., version alignment, automated rollout, naming conventions)?

   • Any lessons learned from maintaining many near-identical extensions?

Thanks in advance for your insights!

- Roei

[Mike_L · Accepted solution]

The 100 limit can potentially be increased, it depends on your cluster sizing. Reach out to our support organization and they can let you know what is possible.

It's quite uncommon that you have one unique script on each host that needs to be executed. Usually all (for example) SQL Servers would have the same script, and then you could do some grouping through host groups, management zones, or tags.

[Roeir5]

Hi Mike, 

Thank you very much for the response ! 
Most of the time those custom script are quite simple scripts that collect periodic metrics using various commands, 

it can be a status command issued on an app that is installed on a server, a simple check for a mounting point.

Some check for Log file data, and in a clustered/HA app - even a change in path from /server1/log to /server2/log is causing each script to be unique. 
This of course is just a simple example, and there are many other scripts. 

We have tried to find a common ground but for a vast majority of the servers there are unique properties in the scripts that require that separation. 

Any way, i will reach out to support for help.

Thank you !