Unable to Navigate to Traces from Opaque Services in the Latest Dynatrace Service App

[rsmsdk]

Hi

In our environment, we rely on Opaque Services, as they provide a valuable way to categorize request endpoints that, for various reasons, we haven’t been able to monitor with OneAgent.

While not as detailed as fully monitored services, Opaque Services have always given us a certain level of insight.

Previously, we could easily navigate these services and proceed to Distributed Traces to identify the traces in which these Opaque Services appeared. However, in the new Service app, this functionality seems to have changed significantly.

Opaque Services no longer appear as individual services in tracing, although they are still searchable in the Service app. Instead, they are now represented as artifacts in the trace of the calling service that utilizes the Opaque Service request endpoint

This change has made it much harder for us to navigate to distributed traces that involve Opaque Service request endpoints. For many of our use cases, this is a significant limitation and a concerning development.

Why did Dynatrace decide to remove this option and drastically change how Opaque Services traces are handled?

This shift has impacted our ability to effectively analyze and trace these services, and I’d like to understand the reasoning behind this decision.

Best regards

[sujit_k_singh]

Hello @rsmsdk ,

Dynatrace redesigned the new Services app to focus on fully monitored services and simplify trace navigation. Opaque Services were never deeply instrumented—they only provided endpoint-level metrics and appeared as pseudo-services in older views. In the latest architecture, Dynatrace treats them as external call artifacts within the trace of the calling service rather than standalone traceable entities.

Like you mentioned, yes you can still search for Opaque Services in the Services app, but trace navigation now starts from the monitored service that invokes them.

Thanks,

Sujit

[rsmsdk]

I’m puzzled by the decision to redesign a feature that plays a significant role in addressing blind spots within our monitored environment.

While I understand that opaque services only provide endpoint-level metrics and appeared as pseudo-services, I fail to see how it caused any harm. In fact, this redesign feels like a noticeable reduction in value for our specific use cases, and I must admit I’m disappointed to see features we rely on being removed.

From a customer perspective, I struggle to find a reason for this change, though I can imagine there might be internal motivations from Dynatrace side.

I would appreciate further context or clarification on how this redesign benefits customers.

[m3tomlins]

I agree this is a change, especially as you state your common practice of finding/filtering opaque services. It could be cool to find an option to filter/facet under the Metadata category? 

One option you might try is filtering on Server Address attribute in the new Distributed Tracing app - but use the negation (e.g. Server Address != "*my_internal_domain*" - which could end up showing all the spans going to servers/domains and or IP addresses that are NOT yours.

In the old days it was "Requests to Public Networks" - and I miss it, too. 🙂