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

Software technology detection


We use the attribute values "software-technology" from the Dynatrace API (host, process) to implement specific use cases in the area of IT security and enterprise architecture.

The following questions arise for us:

  • Apparently the type and version for a process can only be determined for certain technologies. Why is this so or how are the type and version determined?
  • We see that in the life cycle of a process the version is not available at a later point in time. What could be the reason for this?

Can anyone give us insights into this? Thanks!



Thanks, Chad,

my questions focused more on the recognition mechanism. How can Dynatrace determine the type, edition and version of a process or service?

The information is stored in an array and I would also like to understand ...
* why the type, edition and version cannot always be determined?
* whether the order has any meaning?

I have attached a screenshot from, which we used to process the Dynatrace data via API.

Ahh I see. Im not sure how the system detect this information other then maybe a repository or some type of detection based off of log details etc...


Based on my experience the technology and versions are detection rules are "hardcoded" in the agent itself based on the known technologies based on the detection of the process being started. For the detail, you would most likely need to talk to PM or developers of OneAgent process agent. It is not public. For some generic technologies such as Apache HTTP / JVM / NET this is quite straightforward.

I don't think the order does any sense. It's just an array of objects representing technologies.

If the version is not available using API at some point and the process group instance still exists, then I believe this is a bug and should be reported.

TEMPEST a.s., Slovakia, Dynatrace Master Partner

Dynatrace Advisor
Dynatrace Advisor

The OneAgent does technology detection in multiple ways. Some of which are:

  • When native libraries are loaded (e.g. glibc, musllibc, ...)
  • When managed libraries / packages / classes are loaded
  • When certain methods are invoked the first time (e.g. sometimes the presence of a library does not really mean it's used at all)
  • Very specialized logic (e.g. determining the proper .NET version is more complicated than you might think ;))

All of these tech detections are based on hardcoded mechanisms & rules. Most tech detections do report edition/version but some don't implement that. That can be because it's too complex or too much overhead to get the version.

It can also make a difference if "deep monitoring" is enabled, as some tech detections can only be done with Code Modules.

That being said, some Code Modules employ "generic" package reporting. That means they just report all managed packages that are being loaded (no hardcoded rules). This is done for

  • Node.js packages (with versions)
  • Go packages
  • (NXING, Apache) webserver modules

Does this explanation help you?

We see that in the life cycle of a process the version is not available at a later point in time. What could be the reason for this?

This should not happen and sounds like a bug.


Hi Christoph,
that's kind of what I had in mind. Thank you for your explanation!

Regards Matthias