26 Jan 2021 03:51 PM
I have a Service that supports two different sites: /pt/... for Portugal and /es/... for Spain.
Is it possible to split a service, so that I have two services, say a ServicePt and a ServiceEs ?
Solved! Go to Solution.
26 Jan 2021 03:55 PM
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/
26 Jan 2021 03:59 PM
Sure! By using service detection rules, you can split or join services.
At the time of writing , rules can be defined using API only:
https://www.dynatrace.com/support/help/dynatrace-api/configuration-api/service-api/detection-rules/
Blog posts with some examples:
26 Jan 2021 04:45 PM
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
https://www.dynatrace.com/news/blog/new-dynatrace-api-enhances-automatic-service-detection/?_ga=2.19...
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?
26 Jan 2021 04:58 PM
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.
28 Jan 2021 02:44 PM
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?
28 Jan 2021 03:02 PM
This type of processing is going to typically happen on the Dynatrace cluster side. The OnenAgents are just sending the data over, it's the server's job to stitch things together and detect services.
28 Jan 2021 09:06 PM
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.
28 Jan 2021 10:20 PM
Yes, good point. I was confusing here with another problem that I've got and that is related to server side request attributes...