From the version 1.6.8 inspectIT uses configuration interface on our UI to define complete agent configuration and instrumentation. This section provides more information on how to configure the agent using the user interface. 

Basic concepts

Complete configuration for all the agents is saved on the server (CMR) component of the inspectIT. The configuration is managed via the user interface Configuration Interface perspective.

Brief overview of the configuration elements

There are three main elements that are used to define the complete configuration:

Profiles can be used in many environments, while environments can include multiple profiles. This n:m relationships enables easy separation of the configuration and easier management. One environment can be assigned to one or more mappings. Thus, many agents can use the same environment easily. In addition, mappings enable easy switching of the environments for the agent. 

Process of applying configuration and instrumentation

When the agent is started, it reads the repository information and the agent name from the JVM parameters (see Installation Guide and Setting the repository and agent name via JVM parameters). The agent then tries to registers itself with the given repository. If the repository is available and registration is successful agent will receive the configuration from the server that includes basic options and active sensors with their properties. Note that registration will be successful only if there is exactly and only one environment mapped for this agent in the configuration interface. Any change in the configuration requires agent restart, so that updated configuration can be sent to the agent.

Every time the JVM loads a class the agent will intercept this and parse the byte-code of the class to be loaded in order to get information about the class structure (like methods, implemented interfaces, super-class, etc.) The class parsing will not be done if the class name matches any of the excluded classes patterns defined in the configuration. The class structure information is then sent to the server (CMR) where it's analyzed for possible instrumentation. The server will send back the information if the class needs to be instrumented and if this is the case agent will perform the instrumentation by adding byte-code to the methods that should be monitored.

To decrease the amount of calls to the server during class loading, the agent will keep information about all the classes already sent to the server. This information will be used on every successive agent restart, so the agent will not send any class that is already sent, except in case when the byte-code of the class has changed. More on this you can read in the Sent classes cache page.