Best Practices to Monitor .EXE Processes

[Babar_Qayyum]

Dear All,

What type of .EXE processes should be monitored?

What type of .EXE processes should not be monitored?

e.g. do we need to monitor the below ones?

• ServerManager.exe
• Archiver.exe
• aspnet_state.exe

Regards,

Babar

[AntonioSousa · Accepted solution]

@Babar_Qayyum 

Most of .EXE processes are not monitorable at all, but there are some that are full-stack instrumentable, if they are built with .NET, as should be the case for all 3 you mention. Some details on those 3:

• ServerManager.exe is that dashboard that launches in most Windows server. In my opinion, I recommend not even running it in production, as most sysadmins don't even use it, and it does consume some resources, especially memory.
• Archiver.exe is some process that am not sure what it is. Probably better to check inside one of those servers what it really is
• aspnet_state.exe seems to be a component of the .Net framework, but I don't recall seeing it myself in any Dynatrace environment. Probably better to check it out locally too.

In my case, I have manually instrumented some .NET .exe executables, and with great success in some of them. You will probably have to create custom services to get a view of what is going on, especially Purepaths involving network/database requests. It is sometimes a very tricky subject, as you might need to have a code understanding of what is going on, but in some cases I have used it in conjuction with "Method Hotsposts" to be able to get to Purepaths without knowing about the code.

[Babar_Qayyum]

Hello @AntonioSousa 

Thank you for your comments. 

Do we have a way to instruct the Dynatrace not to detect certain EXE processes on the installation of Full-Stack mode?

Regards,

Babar

[AntonioSousa]

You should be able to do that with process monitoring rules:

https://www.dynatrace.com/support/help/how-to-use-dynatrace/process-groups/configuration/set-up-proc...

[Babar_Qayyum]

Hello @AntonioSousa 

These settings are after the fact. I meant we can only force to monitor/not monitor or deep monitoring etc.

Is there a way to configure that the OneAgent should not detect the process?

Regards,

Babar

[AntonioSousa]

I understand that if you don't monitor certain processes, new OneAgent installations will not show the process.

[Babar_Qayyum]

Hello @AntonioSousa 

Please correct my understanding. If I configure the following so any new OneAgent installation on the windows host will not show/detect the process?

What about the existing detected processes? Will they vanish or only the monitoring will be disabled?

Regards,

Babar

[AntonioSousa]

@Babar_Qayyum 

I'll have to take back what I said. I tried it out myself, and didn't work as expected. I'll be back when I can check some things.

[Babar_Qayyum]

Hello @AntonioSousa 

Thank you for your continued feedback and efforts with me to understand the whole concept. I am trying a few things as well and will keep updating you about it.

Regards,

Babar

[fstekelenburg]

you mean a "do not monitor" (if EXE=...) in Custom process monitoring rules did not work out as you expect, that this exe is no longer monitored? I would expect it to be, because it there for to define process monitoring rules if you don’t want to monitor all your processes automatically, or if you need to define an exception for specific processes.

[Babar_Qayyum]

Hello @fstekelenburg 

The objective is not to detect the processes once configured in the cluster. The rules are working perfectly fine but the unwanted processes will remain there without any purpose. 

e.g. Nginx is not supported in Windows but you will find them in the technology and processes.

In a similar way, we want that once the process is marked do not monitor so on the next restart of the host/OneAgent that process should not be detected by OneAgent.

The same should apply to the hosts.

Regards,

Babar

[Kenny_Gillette]

Our practice at our company is only to deep monitor process (code level) if it is used a lot and we need to see down or upstream calls for process.