How does Dyntrace generate Service IDs

[fblass]

Hi experts,

I want to understand what data Dynatrace uses to generate the service IDs. We have many k8s landscapes where same deployments are running. Each of the landscapes have their own Dynatrace environment. On all but one of the Dynatrace environments, the Service IDs of the detected services are the same.

What data does Dynatrace use to deterministically generate the Service IDs? Is there any way I can find out why a different service ID was generated for one of the envs?

At best, I'd like to avoid using the service IDs at all and base everything on e.g. names, labels, tags or something. Unfortunately that does not seem to be possible for configuration of Muted Requests. Here I need the Service-ID as the scope: https://docs.dynatrace.com/docs/platform-modules/applications-and-microservices/services/service-mon...

Best regards,

Felix

[PierreGutierrez]

Hi @fblass 

I don't know exactly what the rule for generating Service ID is. What I do know is that the basis for service detection is Process Groups and the rules by which a Process Group ID is created are based on the Technology recognition grouping. For each technology there are different rules that Dynatrace considers to group and generate the ID.

Example for Java processes, use the Jar file or the main class used.

More info : https://docs.dynatrace.com/docs/shortlink/processes-hub 

I don't quite understand the case you're describing, perhaps you could show us some images to see how to help you.

Please note that it is also possible to apply muting rules from the Dynatrace UI interface.

I hope it's help 💪

[fblass]

Hi @PierreGutierrez 

thank you for your response! I tried to illustrate my setup below:

The deployments basically look the same across all the k8s deployment regions. Dynatrace is also deployed the same way (cloud native full stack). However there is one environment where Dynatrace generated Service IDs for all the detected services different to the ones generated on all the other environment. I want to understand why this is and how I can potentially fix it.

We configure all Dynatrace environments via API, because there are too many to do it manually. And for that, we unfortunately need consistent and stable Service IDs in the Muted Requests API.

Hope that helps to outline the problem.

[PierreGutierrez · Accepted solution]

Hello @fblass  , I understand what you are saying.😁

In conclusion, the expected result for you is that the ServiceID remains the same, since you make an identical configuration. And you manage the same deployed processes.

I understand that this has worked to date, because with the ServiceID you apply the MutedRequest rule from the Dynatrace API.

I tell you that there are several conditions that can cause the ServiceID to change between different environments, however there is an internal data called UNIQUE_SERVICE_NAME that is a combination of the attributes that make up the ServiceID.

Example:

It consists of the following parts:

• Service type: 2 (Web service)

• Web service namespace: http://webservice.business.easytravel.dynatrace.com

• Web service name: BookingService

• PG: PROCESS_GROUP-AE08AA994E1E8EBE

• Agent technology type: 1 (Java)

• Constant: S (probably backwards compatibility reasons)

If one of these changes, a new service is created.

In your case, the Service is expected to have the same UNIQUE_SERVICE_NAME in all the processes and clusters that you deployed.

For that reason, my recommendation is that with this data you can "recreate" the chain according to the conditions that I mentioned or create a ticket in dynatrace so that they can review the UI debug of your tentants and ask for that data, for your evaluation. 

I hope it's helpful 💪