We have over 250 JVMs that are pretty monolithic. Right now, every single JVM is being split into three service types, but that is not helpful nor accurate for our architecture. How can we prevent this?
The entry point is not an issue. The issue is that we don't derive any value of Dynatrace arbitrarily demarcating parts of our app based on request type. This is all handled internally with highly controlled thread pools.
I'm learning to work around it. But for us folks still supporting legacy systems, it would be nice to have this as a configurable option. Or at least have the Service type listed by the individual services in the Process group view - that would prevent me from opening the wrong service each time I try one of the three.
Based on your last comment, something that may help would be setting up custom service naming rules to help you better identify these services from the process group view. This can be done by going to Settings --> Server side service monitoring --> Service naming rules. You could set one up for each service type you're seeing (RMI, web request, background, etc.) and add something to help you better identify which is which in quick manner.
May I ask, you said you have these 3 services for each JVM. Should those 250 JVMs all be standalone. Or is it that multiple of these JVMs do the same thing and should form a process group? the reason I ask is that process groups split services. a process group is thought to contain many instances (processes/JVMs) of the same deployment. Thus maybe in your case we first need to start adjusting process grouping, the services would then automatically fold as a consequence.
A single service would then have many instances (aka JVMs). It would be treated as such.
Does this make sense?