Thanks for the post, actually I know the problem of no metric for .NET generation memory is because of permissions issue to read the PerfMon.
Actually the reason I ask this question (sorry for not being clear enough) is because the agent logs had grow to more than 10GB, and I see the error message all over the log content. Although not sure if this is the reason the log files size grow, thought that maybe I should get rid of those message.
Hence, if those message is just another symptom of the perfmon permission issue, then I can know with confidence that once that is fixed, the issue of huge log files would also fix. (I would only fixed the permission issues few hours later, meanwhile I configured the logging of .NET agent to 'none' to prevent the growth)
I replied to your answer in the below post about the agent log file size. I am wondering about that how the logs growth reached to the 10GB even the combined size of all log files can take maximum 1GB of storage space.
Hi Babar, thanks for the clarification, I've just found out it was because the memory dump is being dumped into the /log/ directory (each .dmp file took about 500MB space) and thus cause the explosion.
However, that brings out another question of mine: https://answers.dynatrace.com/spaces/148/uem-open-q-a_2/questions/194764/regarding-automatic-memory-dump-during-oom-which-o.html
Also, I am not quite sure why the memory dump would dump to /log directory anyway, can I configure it ti be somewhere else?