Environment configuration
- Ivan Senic
- Marius Oehler
Environment defines all the configuration options for the agent. Each agent connected to the inspectIT CMR repository will use exactly one environment that defines all the needed configuration. Please read the basic concepts first in order to understand all the configuration elements in inspectIT.
Management
Environments are created and managed with the 
Configuration Interface view. By selecting the Environment radio button in the Configuration Interface view all the environments in the selected CMR repository will be displayed:
Creating new environment
New environment can be created by clicking on the 
Add → Create Environment action in the Configuration Interface view tool-bar. The name of the environment must be defined, while the description is optional.
Configuration
To edit a environment double-click on the environment in the Configuration Interface view. The 
Environment Settings page displays all the possible configuration settings for an environment.
Agent restart required
In order for changes in the settings to take effect on agents using the given environment, all agents must be restarted.
Profile selection
Profile selection part shows all existing profiles that can be included in the environment. Here it is important to know several things:
- The profile
[Common] Exclude rules should always be included in the selected profiles as the correct functioning of the agent depends on it. For more information read the Exclude rules configuration. - Profiles that are not active will not be included in the environment even if they are selected for an environment. For more information read the Profile configuration.
This part enables easy filtering of the profiles based on their name. Furthermore, double-clicking on the profile opens Profile Editor where selected profiles can be changed.
Strategies
This configuration section defines the strategies that will be used on the agent. The following options apply:
Sending strategy
The agent has to know when to send its measurements to the CMR. For that purpose, sending strategies must be defined. There are two available options:
Sending strategy | Description | Option |
|---|---|---|
Time Strategy | This strategy will cause the agent to send its measurements after a specific interval. This interval can be set by using the option text box. | time in milliseconds |
List Size Strategy | This strategy will cause the agent to send its measurements after a specific size of value objects is reached. The size can be set by using the option text box. | size |
Buffer strategy
The next important aspect to configure is how the agent should handle connection problems when they appear. One could imagine that there is no buffer at all, or a specified size etc. After a connection is reestablished, the buffer will return all the elements it contains and they will be send to the CMR.
Buffer strategy | Description | Options |
|---|---|---|
Simple Buffer | The simplest version of a buffer is apparently no buffer at all. It contains exactly one element. This is useful if old data isn't necessary or maybe the memory of the application is very limited. | none |
Size Buffer | This buffer strategy needs an additional size option to set the size of this buffer. This buffer works as a FILO stack, so last added elements will be sent first (as they are more important), and old ones are thrown away if this buffer is full. | size |
Retransformation strategy
The retransformation strategy defines how the agent is handling changes of the instrumentation configuration and whether it changes the instrumentation on-the-fly or only once at application startup.
Retransformation strategy | Description |
|---|---|
| Disable retransformation on IBM JVMs | This is the default strategy. The agent tries to change the current instrumentation accordingly to an instrumentation configuration change immediately (max. 30 second delay) on-the-fly, but only if the used JVM is not an IBM JVM. If an IBM JVM is used, the agent is instrumenting classes only during startup phase. |
| Always use retransformation | The agent always tries to update instrumented classes on-the-fly immediately (max. 30 second delay) after a change of the instrumentation configuration. |
| Never use retransformation | The agent never tries to update instrumented classes on-the-fly. The instrumentation of any class is only applied during startup phase. |
Class loading delegation
Expert user option
If activated all sub-classes of java.lang.ClassLoader will be instrumented so that loading of the inspectIT classes is delegated to the inspectIT class loader. Should only be changed to false in rare cases. By default this setting is active.
In case you are running on IBM JVM the default exclude-rules will ignore the default IBM boot class loader com.ibm.oti.vm.BootstrapClassLoader. Using class loading delegation with this class loader results in recursive calls that end in stack overflow errors. If by any chance you define a custom boot class loader, please be aware of the problem with recursion and if needed ignore it's class from any instrumentation using exclude rules.
Platform sensors selection
The platform sensor selection allows specification of which Platform sensors should be active on the agent. The selection is possible for all existing platform sensors. By default all sensors are active.
Sensor options
Sensor options part defines all possible general sensor options that can be configured.
String length
All the method-sensor-types and the exception-sensor-type allow specification of the string length option. With this option a user can specify maximum length of Strings values collected by these sensors. What the String values are depend on the concrete sensor used. For example, database related sensors will decrease the size of the SQL statement strings if the length is higher than the specified one. On the other hand, the exception sensor will, for example, decrease the size of the exception stack trace and/or message.
This can be valuable in different situations. The application that has too many created exceptions, can try to send large amount of data to the CMR, because the stack traces of the exception can be long. This can create a very high overhead, that can influence the general performance of the monitored application. inspectIT team already had an opportunity to face the problems where 20,000+ exceptions are created in several seconds, making the network transfer of the data impossible.
This setting is available for following sensors:
Timer sensor
HTTP sensor
Exception sensor
JDBC Statement sensor- JDBC Prepared Statement sensor
Enhanced Exception sensor
The exception sensor can be run in two modes: simple and enhanced. More information about these modes can be found on the Exception Sensor page. The simple mode is default one. When in doubt use the simple exception sensor.
Logging sensor options
In this section it's possible to set the Minimum level parameter for all the logging sensors. This defines the minimum severity level a logging message must have to be captured by inspectIT. The default values are:
- log4j: WARN
More information you can find on Logging Sensor page.