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

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

Dealing with absences in the Purepath

ana_dragomir
Participant

Is it possible to know, whether a purepath is complete or whether just part of the system execution was captured during instrumentation?

To exemplify: if we have a purepath (call1, call2, call3, call4,....), one could make the assumption (especially if the system was almost in its entirety instrumented), that call1 has called call2, call2 has called call3, etc. However, if, due to the server configuration, parts of the execution were not captured by Dynatrace, then it can be possible that between two neighboring calls, say call1 and call2, there is an entire set of non-captured calls callx, cally, callz.... Consequently, in the case the assumption that call1 called call2 would be wrong.

Is there any possibility to find out, given a purepath, whether between two entries there exist further, not documented ones?

3 REPLIES 3

florian_ortner
Dynatrace Advisor
Dynatrace Advisor

Typically, auto sensors fill the gap between sensors; no instrumentation or configuration required. See https://community.dynatrace.com/community/display/DOCDT65/Sensors for details.

We couldn't fill the gap using autosensors. As shown in the
printscreen attached, it seems that the readConfiguration method has
accessed the xerces.properties. However, this is not the case. We have
done a very thorough code inspection and we know for sure that
readConfiguration actually accesses a 3rd party library. This 3rd party
library is not instrumented, so it is not monitored, for performance
reasons. However, this 3rd party accesses xerces.properties. The gap
represented by the missing third party is not signaled in any way in the
purepath. Consequently, during an architecture analysis we detected
many false positives, because it seems that methods such as the
exemplified readConfiguration illegally access directly such properties
files.

Do you have any suggestion how to overcome this?

partial-trace-xerces.png

ana_dragomir
Participant

We couldn't fill the gap using autosensors. As shown in the
printscreen attached, it seems that the readConfiguration method has
accessed the xerces.properties. However, this is not the case. We have
done a very thorough code inspection and we know for sure that
readConfiguration actually accesses a 3rd party library. This 3rd party
library is not instrumented, so it is not monitored, for performance
reasons. However, this 3rd party accesses xerces.properties. The gap
represented by the missing third party is not signaled in any way in the
purepath. Consequently, during an architecture analysis we detected
many false positives, because it seems that methods such as the
exemplified readConfiguration illegally access directly such properties
files.

Do you have any suggestion how to overcome this?

partial-trace-xerces.png

@Florian O.