Comments have been closed on this page. Please use AppMon & UEM Open Q & A forum for questions about this plugin.


A Sensor Pack that automatically creates sensors for any method, constructor or all methods/constructors of a class annotated with @DynaTraceSensor.


Sensor Annotation



dynaTrace Diagnostics Version



Paul Kuit


dynaTrace BSD






Sensor Pack Information

The sensor pack automatically creates sensors for all methods / constructors with the @DynaTraceSensor annotation. If used on class level, all methods and/or constructors of the class will be instrumented.

If (entryPoint=true), the sensor will create new PurePaths for these methods / constructors.


  1. Save the attached Sensor Pack file locally to the computer where the dynaTrace Diagnostics Client is installed.
  2. In the dynaTrace Client, choose Setting ⇒ dynaTrace Server Settings
  3. Click on "Sensor Packs".
  4. Click on the "Import..." button.
  5. Select "Custom Sensor Type (*.dtcs)" in the "Files of type" dropdown.
  6. Navigate to the directory where you extracted the .dtcs file and click "Open".


You can confirm successful import by observing the "Sensor Annotation" Sensor Pack in the Sensor Packs Panel. This Sensor Pack is now Placed and Active within all System Profiles on this dynaTrace Server.


Using the annotation

  1. Include the attached dtannotation.jar to your project libraries.
  2. Locate the method/constructor/class that should be measured by dynaTrace and add the @DynaTraceSensor annotation.
  3. If the method/constructor (or all methods/constructors of the class) should initiate a new PurePath, (e.g. a batch process), use attribute (entryPoint=true). Be careful not to instrument the main (or run) method to avoid infinite Purepaths!
  4. Recompile the project and start the application with the dynaTrace Java agent.
  5. For methods annotated with (entryPoint=true), verify new Purepaths appear from the annotated method(s).
  6. For methods annotated without entryPoint or (entryPoint=false), verify the annotated method(s) appear in the method Dashlet.




Example (included in jar file):



Captured PurePaths:



  1. Anonymous (login to see details)



    Very kewl ... I've not had a chance to try it yet ... but if a developer adds annonation and then in PerfTest I want to exclude only a subset of the annotated instrumentation is there a way to create and use something similar to a "global exclude" list in order to take advantage of the annotated sensors but still reduce/control/override it a bit from within dT (vs recompile app to adjust annotations)?




    1. Anonymous (login to see details)

      Global excludes will work. You can e.g: say "Globally exclude all methods from a particular class or that match a particular method signature"

  2. Anonymous (login to see details)

    Paul or Andy,

    can we get this to work with the Java 6 compiler?

    1. Anonymous (login to see details)

      Hello Colin,


      The source is included in the jar file, but I recompiled it with 1.5 compatibility and updated the attached jar.

  3. Anonymous (login to see details)


    This is my first time pulling code from this forum.

    1. Is it legal for a company to use this jar?  Just making sure this is not one of those "ok for personal use, but not for corporations" deals.
    2. Are there any legal ramifications I should know about?  I am OK with the disclaimer on the support page.
    3. Anything else I should know before making this one of my usual tools?
    1. Anonymous (login to see details)

      Hi Hal.  The source code is in the Jar file and is public use.  All this does is tie annotations into the annotations sensor pack in dynatrace eliminating the need to manually create sensor groups.. 

  4. Anonymous (login to see details)


    Thanks, Colin.

    Both for the prompt response and for making the annotation technique available to us.

    1. Anonymous (login to see details)

      My pleasure, Hal.

      Which project are you working on?  I couldn't find you in the directory for some reason...

  5. Anonymous (login to see details)

    Enterprise roll out question:  How do you keep from being overwhelmed when you have nested projects?

    1. Project A annotates some classes. 
    Purepaths are exactly what Project A wants to see.

    2. Project B annotates some classes. 
    Purepaths are exactly what Project B wants to see.

    3. Project B starts using Project A's JAR. 
    Now Project B sees both Project B purepaths and Project A purepaths?
    If so, how does Project B limit what they see in Purepaths without manually creating a lot of exclusions?
    Does each project have to create is own DynaTraceSensor Annotation class and its own sensor pack?

    Sometimes it would be useful to be able to capture data for multiple projects.  But, initially, especially during the Development stage of the SDLC, developers on Project B are primarily concerned with their own code and don't want to sift through another project's data.

  6. Anonymous (login to see details)

    Hello Hal,

    Yes, with the default sensor pack the developer would see all annotated methods within a Purepath. But you could easily change the rules in the sensor pack configuration to look for (or ignore) specific packages within the code.


    1. Anonymous (login to see details)


      How/where do I configure the sensor pack?

      Is it configured in the Dynatrace client?
      Maybe I am missing some options because my id does not have the proper permissions?

      Or do I need to manually edit the DTCS file?


      1. Anonymous (login to see details)

        You can open the server configuration, enter the Sensor Pack tab and edit the Sensor Annotation pack configuration, (if you have sufficient privileges).

        1. Anonymous (login to see details)

          Thanks.  I can see the sensor pack there.

          NOTE:  I am not a Dynatrace expert, or even novice, so please bear with me if you can.

          Referencing my example above...

          I was hoping there would be a way for Project A to identify their important Purepaths during Development, then, if a consumer of their JAR has a problem, the sensors would already be in place to get Project A the information they need – without someone needing to manually manage the sensors in Dynatrace.  Also, I was hoping that sensors would be "cleaner" because, as dead code was removed, the annotations (and sensors) would also be removed.

          If Project B includes Project A's code, in the long run, it sounds like it would be simplest for each project to have its own Sensor Pack that references its own, unique, DynaTraceSensor Annotation class.  Then each Project would only enable their own Sensor Pack unless they specifically wanted information about another Project's code.  Is this what you recommend?

          1. Anonymous (login to see details)

            You could add annother parameter to the annotation, something like:

            @DynaTraceSensor(entryPoint = true, environment = "dev")

            and alter the sensor pack to filter for a certain environment. I choose to keep this 'plugin' as simple as possible.


            1. Anonymous (login to see details)

              Thanks.  That option offers some possibilities.