29 Nov 2018 01:08 PM - last edited on 03 Mar 2023 11:52 AM by Karolina_Linda
Is there any way to detect how much cpu% the instrumentation of Oneagent is adding to the OSB process / Service (Or any other tech)?
Not necesary to see it in Dynatrace, but maybe using an especific command or memorydump?
I know that the overhead added should be low and depends mostly of the traffic and technology. But we have a requirment from a client to give an "idea" of how much it is.
ps: the OSB process are currently being monitored by oneagnet.
Solved! Go to Solution.
In my experience, the best way to show the CPU overhead of a monitoring tool is not a measure that you get from that monitoring tool (regardless how accurate this measure is). This is not because the tool wouldn’t be able to measure it, but mainly because stakeholders want to see an “objective test”.
If you have a stable loadtest environment, you can run the application with and without monitoring, and look at the resource usage of the system. This also because Dynatrace runs multiple processes on your server to implement the monitoring (in the process overview in Dynatrace you can see several oneagent processes with their resource usage).
Multiple scenario’s you can consider:
* Install oneagent and disable deep-monitoring for the OSB process and do a loadtest, then enable deep-monitoring and rerun the loadtest. This shows the “JVM only” increase of CPU, e.g. when you plan to be running multiple processes on the same machine (all common processes will remain almost the same for additional processes).
* Run loadtest on “clean” machine and then install the oneagent and rerun the loadtest. This will show the increase in resources for a dedicated machine where only your OSB process is running (1 instance), because you also measure all shared components as being part of the increase.
Make sure that your loadtest gives consistent results when running multiple times, so that you can report on the actual difference, rather than on a variance in the loadtest. I mention this because otherwise you couldn’t spot the +/- 2% of CPU increase 🙂
Does this help?