Hi @awahab ,
Dynatrace OneAgent already has built-in mechanisms to reduce resource consumption.
For example, the network monitoring module does along the lines of what you described, whereby it will throttle and pause monitoring in stages. Link: Network monitoring overhead
I suggest reading up also on how OneAgent uses adaptive traffic management and control.
If OneAgent simply paused or started and stopped, then we'd potentially lose data. Instead, with adaptive traffic management, we ensure data is statistically relevant to monitoring while maintaining a built-in limiter that helps to reduce resource consumption, like network bandwidth (especially for high volume scenarios).
Also for code modules, keep in mind that it is highly dependent on the monitored applications. See OneAgent code module memory requirements for describing the memory demand variance.
See also File aging mechanism for how OneAgent manages disk space resources.
I shared more links than that just the network one. Some of it is a bit 'reading between the lines' and I apologise for that.
For your specific concerns, I suggest to reach out to Dynatrace ONE via in-product chat. They could help answer your queries.
answering your question would be entering windows control panel services and looking for the Dynatrace Oneagent service and click on stop. On linux, service oneagent stop
you can visit the following link:
We know how to stop it manually 🙂
The intention is to get dynatrace stop itself and send a notification when the issue happens without any manual intervention. We manage 30000+ servers. If this is already there , it will give peace of mind.
In a month we get 2-3 incidents like this.
@awahab Bare in mind that code modules reside in the application process itself once it gets up and are not seperated. This is why measuring agent "overhead" by its own can only be done for the general purpose things.
If your IIS Application pool consumes 80% CPU because it is receiveing a lot of requests and working heavily against the DB, dynatrace will monitor all of it and will obviously consume CPU as well. How will you decide in this case that it is the cause for high cpu and not the application?
In any case, for these cases, disabling it dynamically really depends on the technology and whether you've enabled real time updates (if the technology permits). With .NET (for example) you'll need to restart your processes because that's how Microsoft is handling these changes.