Hello, we're using OpenTelemetry to auto instrument several Java applications running on Websphere Application Server.
However the issue we have is that some of the services appear with a too general endpoint name.
It seems that the span name is generated with a generic http.route attribute that is masking part of the whole request, so the endpoint name that appears in Dynatrace is equally generic and broad. Only when viewing the details of the trace/span, we can see the actual http.target and the real URI of the request.
http.route says /example/*.go
http.target is /example/login.go
The endpoint name ends up being only GET /example/*.go
This causes that all the traces/spans that share that same generic http.route are being grouped incorrectly inside that endpoint when they are very different URIs and requests.
We would like to have the endpoint name called GET /example/login.go
So the endpoint would correctly group only those login requests inside it.
We're using the new Unified Service capabilities to enrich the OpenTelemetry information and its representation in Dynatrace Services.
We're using auto-instrumentation OpenTelemetry for Java.
It sounds like you are encountering an issue with the naming of endpoints in Dynatrace when using OpenTelemetry to instrument Java applications running on Websphere Application Server. The problem appears to be related to the generic `http.route` attribute being used for the span name, which results in less informative endpoint names.
To achieve more specific and informative endpoint names in Dynatrace, you can consider the following approaches:
1. **Custom Instrumentation**:
- One approach is to perform custom instrumentation of your Java applications using OpenTelemetry. This will allow you to define how the span names are generated. You can extract the actual endpoint information from the `http.target` attribute and set it as the span name. This way, you can have more specific endpoint names in Dynatrace.
2. **Attribute Extraction and Transformation**:
- You can configure OpenTelemetry to extract the relevant information from the `http.target` attribute and transform it into a more meaningful span name before it's reported to Dynatrace. This can be done using OpenTelemetry's attributes processor or a similar mechanism depending on your OpenTelemetry configuration.
3. **Dynatrace Service Naming Rules**:
- Dynatrace provides the ability to create custom service naming rules. You can define rules that use the extracted information from `http.target` to create more specific service names in Dynatrace. This can help in better grouping and visualization of your traces.
4. **Dynatrace Custom Attributes**:
- You can also use custom attributes in Dynatrace to store additional information related to the service or endpoint. This can be used to add more context to your traces and help differentiate between different endpoints.
5. **OpenTelemetry Instrumentation Configuration**:
- Check your OpenTelemetry instrumentation configuration for any settings related to span naming. Some instrumentation libraries allow you to customize how span names are generated. You might find an option to use a specific attribute as the span name.
6. **OpenTelemetry Updates**:
- Ensure that you are using the latest version of the OpenTelemetry instrumentation for Java. Newer versions may provide enhanced capabilities for customizing span names or extracting attributes.
7. **Collaborate with Dynatrace Support**:
- If you are still facing difficulties after trying the above steps, consider reaching out to Dynatrace support. They may have specific recommendations or updates related to their integration with OpenTelemetry.
By combining these approaches, you should be able to improve the specificity and accuracy of endpoint naming in Dynatrace, allowing for better trace grouping and analysis. Remember to thoroughly test any changes in a non-production environment before applying them to your production setup.
Thanks for your tips!
So as far as current Dynatrace capabilities, we cannot change the naming for these endpoints?
We have worked with Service Naming Rules and Service Request naming rules but in this case for Unified Services ingested with OpenTelemetry, the naming section doesn't show up inside those services.
And we don't have the option right now to customize the OpenTelemetry instrumentation, we can only work with auto-instrumentation.
Strange thing is, some services DO have the correct endpoint names, and others do not.