Timer sensor
- Copy Space for Confluence
1. Overview
The timer sensor types measure the execution time of methods within the monitored application. inspectIT provides different multiple realizations of the timer sensors. The most widely used realization is the average-timer. All other realizations are only optimizations for very specific application areas.
If in doubt, select the average-timer.
2. Average Timer
The average timer is the most widely used realization of the timer.
2.1 Configuration
method-sensor-type <name> info.novatec.inspectit.agent.sensor.method.averagetimer.AverageTimerSensor <priority>
priority can be one of MIN, LOW, NORMAL, HIGH, MAX. It is used to define the order of the sensor type execution if more than one method sensor type is defined for a single instrumented method. Usually you will select MAX as priority.
3. Generic timer factory
Apart from the "Average Timer", inspectIT provides a "Timer" sensor that was created to easily integrate different realizations of the same timer behaviour. Each implementation collects and/or stores the values in a different way, thus affecting system resources in a different manner. Switching between internal implementations is completely transparent to the user of inspectIT.
Example: The default implementation of the "timer" listens to the callbacks of the method hooks and calculates the time spent within the method. This information is directly aggregated within the sensor for all calls within this data collection interval. Thus data aggregation is done within the JVM of the application to be monitored. Another implementation of the "timer" does not calculate the average time within the sensor but sends raw data to the CMR. In this case the CMR will deal with aggregation of data. The information the user will see do not differ - in fact the user will not even be aware about which implementation will be used. It is completely transparent. Approach (a) will most likely use more CPU time than approach (b), but approach (b) will definitely sent much more data over the network.
3.1 Available Timer Realizations
The following modes are available for the timer sensor.
Timer mode | Description | Network | CPU |
|---|---|---|---|
aggregate | aggregates the data before sending to minimize the network load, but will affect the application JVM |
|
|
optimized | reduces the memory usage as it calculates the results immediately when new measurements arrive |
|
|
raw | timer measurements are collected, but not aggregated. All data is sent to the CMR. |
|
|
3.2 Configuration
method-sensor-type <name> info.novatec.inspectit.agent.sensor.method.timer.TimerSensor <priority> mode=<optimized|aggregate|raw>
priority can be one of MIN, LOW, NORMAL, HIGH, MAX. It is used to define the order of the sensor type execution if more than one method sensor type is defined for a single instrumented method.
3.3 Comparison to the Average Timer
As outlined in the introduction, the Average Timer sensor type is basically the same as the Timer sensor type with a difference in the processing of the recorded data. The Timer sensor type is using a factory internally to select the storage mechanism based on the definition in the configuration. The Average Timer doesn't need this configuration and the aggregated mode in the Timer sensor type is the same as the one used in the Average Timer. Thus the difference is only that the additional abstraction is removed and the processing and storing of values should be a little bit faster.
4. Other options
4.1 String length
from version 1.3
This sensor enables the limitations of the string values collected. The timer sensor concretely can limit the maximum size of the strings collected as context parameters. The following definition will, for example, limit all the strings collected by the sensor to 500 characters:
method-sensor-type <name> info.novatec.inspectit.agent.sensor.method.timer.TimerSensor <priority> mode=<optimized|aggregate|raw> stringLength=500
You can read more about string length limitations on Sensor type definition page.