Showing results for 
Show  only  | Search instead for 
Did you mean: 

This product reached the end of support date on March 31, 2021.

12.4 Sniffing Port Diagnostics / Traffic Trace


12.4 DCRUM Console can't support viewing Sniffing Port Diagnostics or Traffic Traces except inside the wizard, and then only for HTTP traffic. Has there been any decisions made to add this important functionality back into the product?



Hi @Rob Kerry,

As we already briefly discussed this issue some time ago, sniffing point diagnostics have been replaced in 12.4 with the traffic diagnostics (Tools > Diagnostics > Traffic diagnostics) on CAS. As a side effect of the refactoring, only the HTTP wizard allows working on traffic traces. Other protocols, such as XML and SOAP will be added to the wizard in future releases, as we know that it's extremely important and demanded in your case. I cannot provide a precise time frame, but this is on our priority list.

Best regards,


Zeke, we actually never received any concrete answer if any of the missing
functionality was going to be reinstated in DCRUM or not. The method you
describe using (Tools > Diagnostics > Traffic diagnostics) in 12.4 is still
quite limited and won’t give us back the other missing functionality that was
taken out of the console. In CAS version version,
we found that there is still a:

1) Loss of ability to see the other discovered application
protocols on each individual AMD, as well as the IP & Port information or the
decode DCRUM recommends.

2) No SSL Diagnostics page

3) Loss of ability to import outside traces into DCRUM Console
for analysis and tweaking software services.

4) Loss of ability to create Software Services using traffic
traces for any traffic other than HTTP

These things were really what I was asking about and wondering when this functionality
will be returned back into the product. I have attached some of the screens
that we are no longer able to see to illustrate.


Could you provide link to the discussion you mention please Zeke.

That was a call we had, nothing on the forum.

Dynatrace Advisor
Dynatrace Advisor

I don't mean to take a swipe at the Dev team, but this was an extremely useful feature that we used quite a bit out in the field. It made DCRUM significantly more accessible for users that didn't have a deep understanding of their app stack.


Really missing this funcitonality - need to put it back into the tool as soon as possible.

It's planned to enhance the wizard, which handles HTTP(S) only in 12.4, to also handle SOAP/XML in near future though I cannot provide any precise time frame.

The wizard was only a small piece of what was removed from RUM Console. What about all the other things we are talking about that are now also missing? Are they also going to return at a future date?

Potential work around - Whilst not an excuse for this issue not being fixed, if anyone is in the position whereby they can deploy an Endace appliance on which you run your AMD, it will be possible to work around this shortcoming whilst we await the replacement functionality. The Endace chassis will give you the ability to manipulate and view the traffic coming into the AMD, such that you have a much clearer idea regarding the traffic mix and ports in use, and consequently you will be better informed regarding how to configure your AMD decodes.

I believe there are many other benefits for running this appliance beyond the above but this advice isn't intended as a marketing plug, and besides some of you may not be remotely interested in some of its other features. This just might help out a few of you....


We migrated some systems to 12.4 SP1 and we are missing the Sniffing Point Diagnostics as well.

It was very helpful to have a look at what is the AMD currently seeing without adding the data to the CAS reporting. It was good to see if a special IP-Address for a new service is visible.

The autolearning feature is not always a good idea specially for productive environments.

Right now we are able to record a trace from the RUM Console but we aren't able to inspect it.


I too have the very same concern as the others on the forum.


I know that although we used the Sniffing Ports Diagnostics a lot at Target, we were able to get around most of the issue because 12.4 expects all traffic mode to be enabled. With this, you can look at all autodiscovered traffic, then drill into an analyzer type, then look at server IPs and ports for the last monitoring interval. This is especially helpful if you turn off aggregation for autodiscovered traffic (which may not be possible, based on volume).

Sorry for the vagueness of instructions but I don't have an accessible CAS at the moment. @Jacob Potter may be able to help outline this process.


It seems there are at least two things mixed up here. So, let me explain the confusion around Sniffing Point Diagnostics (SPD) and why it's been removed in 12.4.

First, don't confuse diagnostics with discovery. SPD was designed to help you identify traffic quality issues. Discovery (in RUM Console called Application Traffic Overview, ATO) was designed to show you what services have been discovered, and based on that, help you create custom software services.

1. Diagnostics

SPD in RUM Console has been replaced with the new, redesigned and improved Traffic diagnostics on CAS (Tools > Diagnostics > Traffic diagnostics). It can identify traffic quality issues automatically and in an easy way tells you what has been identified, where the potential source of problems lies and how to fix it.

In addition, it does provide secure traffic diagnostics, also known as SSL diagnostics. It's been improved and simplified to follow the same paradigm that we applied for the general traffic diagnostics.

How to assess traffic quality and diagnose issues in DC RUM 12.4 vs 12.3 explains differences between the old and the new diagnostics approaches.

2. Discovery

ATO in RUM Console is no longer the way how you discover and define custom software services. We have moved all the worflow to CAS and improved the way autodiscovered traffic is handled (aggregation turned on by default to prevent the CAS from overloading, even in production environments) and results presented (discovered services "separated" from used-defined ones). The new presentation is seamlessly integrated with the HTTP(S) wizard, so you can easily define custom services for web apps. Support for SOAP/XML in the wizard is planned in next major release, due in summer 2016. Definition of all other services remain manual, as it was in 12.3 or earlier. You can still record a traffic trace on RUM Console and use it in the HTTP(S) wizard, as it was in 12.3.

In addition, discovery also detects cloud-based services and helps you identify issues with naming and Windows domain access services (DNS, LDAP, MS RPC, SMB) out of the box. And you don't need to dig deep in a trace file to find a server -- since the discovered and aggregated data is now in CAS, you can use the search feature to find a server or a server range. Everything in a unified CAS reporting style.

How to discover and create a software service in DC RUM 12.4 vs 12.3 explain differences between the old and the new approach to software service discovery and defining workflow.

Is the traffic trace functionality in RUM Console in 12.4 used just for Software Service creation with a wizard? Or is it used as a data source for any other reports?



Dynatrace Pro
Dynatrace Pro

FYI, there are two pages added to DC RUM documentation that may be helpful:

How to discover and create a software service in DC RUM 12.4 vs 12.3:

How to assess traffic quality and diagnose issues in DC RUM 12.4 vs 12.3

Hi Krzysztof,

The links seem to be down at the moment. Is this documentation still available?

Hi Anton,

It's a mystery to me. I created the topics and haven't changed their location since posting. Try and/or

If the links fail, use the search in the DC RUM context.



Hi Zeke,

Those links work no problem, thank you!

Page titles got changed, this is why the links were broken.



Keep calm and build Community!