Overview

1. Overview

Application performance and stability is growing to become the project killer number one of nowadays software projects. Recognizing a performance problem in production can lead – in extreme cases – to a complete architectural redesign of the software.
Gain the upper hand in the performance struggle by opening the JVM black-box and thus being able to see which parts of your application perform as you expect them and which to improve. Win the performance battle by integrating transparent inspectIT sensors within your code. Integrating measurement points is as easy as writing a single line of configuration defining the place of this measurement point. Save time, effort and customer support by identifying possible performance bottlenecks prior to shipping the application to your customer. The earlier you can identify and fix a performance problem, the better.

2. inspectIT components

This chapter briefly describes the components of the inspectIT architecture. Each component will be described in more detail in the other pages.

2.1 inspectIT Agent

The inspectIT Agent is the component that enables measurement points in your application. It is integrated into the JVM of the application you want to monitor and will instrument the configured methods with the defined sensor types.

The agent is configured by a simple configuration file. Within this configuration file, settings like the Agent name, the CMR location and the sensors to be integrated are defined. This file is the most important piece of configuration within inspectIT as it allows the user to define what information will later be provided in the graphical user interface. Detailed information about the configuration of the various sensor types can be found at the Agent Configuration section

2.2 Sensors

Sensors are small components that connect to the instrumented hooks of methods (instrumentation is performed by the javaagent implementation) and collect measurements.You can think of this as follows: The agent initially checks based on its configuration file which methods will be monitored by sensors. For these methods hooks are integrated (by means of bytecode modification) before the method and after the method (to be correct, there are two after method hooks, but we just ignore this fact for the time being).

2.3 Centralized Measurement Repository (CMR)

The Central Measurement Repository (a.k.a. CMR) acts as the server component of the inspectIT architecture. Its purpose is to collect the measurements, persist them and provide the data in the correct format to the user interface for display.To limit the amount of data being sent, the CMR also provides a registration service to the sensors.

Note that CMR does not persist some data types, but stores them in a memory for faster access. Please refer to Working with the in-memory storage page for more information about memory storage.

2.4 User Interface

The inspectIT user interface allows the user to do his analysis based on the gathered information.

3. Technical perspective: How does inspectIT work

inspectIT works by transparently integrating callback hooks into the application using load-time Java byte code modification. These hooks are afterwards being used by inspectIT’s sensors to gather various monitoring information about the application. This monitoring approach integrates with a minimum of (transparent) code adaptation and thus is the safest possible way to integrate monitoring. All measurement logic is extracted to the sensors that run “outside” the business logic code and thus safely separated from your application.