Is it possible to split a service?

[AntonioSousa]

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 ?

[JamesKitson · Accepted solution]

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/

[Julius_Loman · Accepted solution]

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:

• https://www.dynatrace.com/news/blog/new-dynatrace-api-enhances-automatic-service-detection/
• https://www.dynatrace.com/news/blog/new-dynatrace-api-enhances-automatic-service-detection-part-2/

[AntonioSousa]

@Július L. & @James K.

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?

[Julius_Loman]

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.

[AntonioSousa]

@Július L.,

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?

[JamesKitson]

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.

[Julius_Loman]

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.

[AntonioSousa]

Yes, good point. I was confusing here with another problem that I've got and that is related to server side request attributes...