Yes, you can use service detection rules to modify this behavior. What you likely want to do is set it so that a separate context root is detected for each value.
This blog post explains it: https://www.dynatrace.com/news/blog/new-dynatrace-api-enhances-automatic-service-detection/
And here is the documentation: https://www.dynatrace.com/support/help/dynatrace-api/configuration-api/service-api/detection-rules/
Sure! By using service detection rules, you can split or join services.
At the time of writing , rules can be defined using API only:
Blog posts with some examples:
Thanks for your very fast reply. I did a deep dive in the APIs, and they seem really the way to go. I do have one doubt though
I'm using the example provided in the "Separate fully monitored web request services based on URL" section of
It does seem that the example would be generic for all process groups. Is it possible to limit the splitting to a specific process group, so it doesn't grab "URLs" from other processes?
Also, any suggestions that should be looked at, as it seems a "dangerous" API?
Well, it's not mentioned in the examples, but you can use process group tags in the conditions! (This is a hidden gem).
You can define the scope for management zone only.
At the moment, I'm splitting with hostname, and it's working as expected. But I may have to add several rules.
I'm wondering on the impact of overhead at the OneAgent level. If I define it at the hostname level, I imagine that the rule has to be deployed across all OneAgents of the environment. But if I define it at the PG level (PG_TAG ), would you say it's more efficient? I would imagine that in this scenario the rules would be interpreted wherever this PG is working, not deploying it environment wide?
Sometimes it's really needed to limit the scope of the rule. Tags are ideal for such purpose. Definitions of hostname can be problematic during any changes.
For the performance effect of the rule, I agree with the answer provided by James.