Understanding sensor mechanism
Hi, I'm quite puzzle in sensoring mechanism.
There are sensor for
- application (method)
- application (memory)
- EJB invocation
- JNDI
- ....
Those sensors are ordered but I don't understand meaning them and the difference with the auto-sensor.
Hi Pierre,
What you find listed in the sensor placement part of the system profile are all byte code sensors. The first two are groups for your custom sensors, the rest are the out-of-the-box sensors for known technologies like JNDI, JDBC, thread-tagging and so on. If you are interested which specific methods those sensors would instrument go to "Settings" - "dynaTrace Server" - "Sensors Packs" and click Edit for the pack you want to view.
Auto sensors are different, they don't have any configuration besides the overhead setting. They will use transactional snapshots to augment the data captured by the byte code instrumentation.
Last a couple of links to the documentation with more details:
- Auto Sensor
- Sensor Configuration
- APMU - Course "Deep Dive Diagnostics": http://apmuonline.compuwareapm.com/course/view.php?id=480
Best, Roman
as usually many thanks for your speed.
But what I don't understand is the meaning of ordering the sensor, is it to maintain the overhead at 5% maximum and telling to Dynatrace which sensors are the most important and which ones could be deactivated when 5% is reached ?
The byte-code sensors are never deactivated/activated automatically - the auto sensor has the settings you refer to (PurePath explained#AutoSensorResolutionSettings).
The ordering is necessary because all the sensor rules are executed sequentially, top-down. This allows you for example to exclude a method that would have been instrumented by an out-of-the-box sensor simply by having your custom rule higher in priority.
Best, Roman
sorry Roman, but this information is not a 100% correct.
the Sensors are processed sequentially from top to bottom, that's correct. however, excludes are only local, so they can only prevent instrumentation in the same Sensor. an exclude rule can never prevent a method from being instrumented by another Sensor. that's what global exclude rules are for and they are applied to all Sensors, regardless of the order.
so in your above example getName() would get instrumented in any case regardless of the order of the Sensors.
generally the order of Sensors is only relevant, if the same method should be instrumented by multiple Sensors. this order is then used for basically 2 things:
- defining the most significant API: when multiple APIs are applied to one instrumented method, there has to be only one API, which the timing information about this method is accounted to, because otherwise the time would get accounted multiple times. and this API is the most significant API, meaning the API of the first Sensor that was applied.
- configuration of runtime settings (active/inactive/start PurePath): these settings can only be configured on the Sensor rule which matched the very first
best, Christian
