inspectIT 1.6 - New Features of the Open-Source APM Solution: Configuration Interface

On July 15, 2016 a new stable version of the open-source Application Performance Management (APM) tool inspectIT has been released.  With about two years of development work, inspectIT 1.6 appears in a new guise with a new logo, new homepage, open sources on GitHub and a bunch of new features. In this series of blog posts we are going to present you the new features that makes the open-source APM solution even more the tool of choice. In this blog post we will take a closer look at the new Configuration Interface of inspectIT.

What is the instrumentation configuration about?

inspectIT uses an instrumentation-based approach to collect measurement data from a target application. This means that inspectIT’s agents weave measurement probes into the bytecode of the target application at run-time. Data collected by the inspectIT agent is sent to the inspectIT Server for further analysis. What to measure, Where to measure and How to deal with collected data is a matter of configuration. In other words: inspectIT’s instrumentation configuration provides means to specify

• available sensor types (e.g. timing sensor, HTTP sensor, SQL sensor, etc.) and their properties
• measurement probes (assignments of sensors types to methods of the target application to be instrumented)
• system information to be sampled (CPU utilization, Memory usage, etc.)
• inspectIT agent’s buffering and sending strategies for collected data

These configuration aspects are context-specific and a prerequisite for the core functionality of inspectIT. Hence, configuration of the instrumentation should be intuitive, scalable and reusable to enable efficient working with inspectIT.

Instrumentation in previous versions

In inspectIT versions prior to 1.6 the instrumentation process has been fully performed by the inspectIT agents. In particular, an inspectIT agent was responsible for reading and parsing the instrumentation configuration, intercepting class loading of the target application, deciding which classes and methods to enrich with measurement probes by means of the configuration, and conducting the bytecode swapping.

Thereby, the configuration has been managed by means of textual config files, as depicted below:

In this example, we see all the configuration aspects listed before. Method-sensor-type and platform-sensor-type declare the available sensor types and the system information to be collected, respectively. Buffer-strategy and send-strategy specify how long the agent should buffer collected data and when it should be sent to the inspectIT server. And finally, the last paragraph (Probes) defines which methods different sensors shall be applied to.

Though the configuration with the text files worked well and the configuration language was quite expressive, managing the instrumentation by means of text files also brought some disadvantages.

Intuitiveness

Working with textual configuration files requires knowledge of the syntax and available configuration options. Therefore, especially for users that are new to inspectIT working with configuration files is a cumbersome task that often leads to exceptions during application start-up due to syntax errors in the config files.

Scalability

In previous versions of inspectIT, the instrumentation configuration has been specified per inspectIT Agent. In particular, the config files have been placed with the individual agents making the agents responsible for reading and parsing the config files. In distributed scenarios of the target application (e.g. multiple equivalent application servers) inspectIT required a corresponding amount of inspectIT agents, each with its own set of configuration files. To ensure consistency the configuration files of the different agents needed to be kept in sync. Hence, changes on one configuration implied changing the configuration of other agents correspondingly. Consequently, the bigger the target environment was, the more difficult it was to manage instrumentation configuration with the config files.

Reuse

Different software systems are often build on common frameworks using common libraries and APIs for similar purposes. For instance, many applications use the Java Sevlet API for HTTP request handling, JPA/JDBC for persistence or EJB for software component definition. Common frameworks, libraries and APIs are good candidates for instrumentation configuration as they provide generic entry and exit points in the target application. In general, corresponding instrumentation configurations are generic, as well, and provide potential for reuse among different scenarios. Though, in previous versions of inspectIT, reusing and sharing configuration fragments with the configuration files was not impossible, managing configuration components with the config files was cumbersome and error prone as there was no clear concept behind modularization of the configuration.

Performance

As described before, in previous versions of inspectIT the agents were fully responsible for the instrumentation process. With every restart of the target application the agents performed the necessary instrumentation steps again and again, from reading the configuration files upto bytecode swapping. This lead to the result that the application startup has been slowed down significantly if the agent was active.

What changed with the new Configuration Interface?

inspectIT 1.6 comes with a new Configuration Perspective in the GUI.  Working with inspectIT becomes a more intuitive task and enables even users that are new to inspectIT to start right away with configuration.

The basis for the new Configuration Interface is a completely revised instrumentation approach. Instead of making the inspectIT agents fully responsible for the instrumentation process, in version 1.6 the inspectIT Server takes part in the instrumentation process. In particular, the inspectIT Server manages the instrumentation configuration and decides which specific classes and methods to instrument. This allows a more sophisticated configuration approach for the instrumentation.

Profiles and Environments

The new configuration approach comes with an elaborated modularization concept. Thereby, different instrumentation aspects are separated into individual configuration components called Profiles. A profile is a self-contained, logical unit of instrumentation that can be reused in different scenarios. inspectIT comes with a set of common profiles for HTTP, SQL, EJB, etc. and allows to create custom profiles. Therefore, the inspectIT GUI provides an editor (see screenshot above) that allows to specify instrumentation points in an intuitive and straightforward way.

Since profiles can be seen as building blocks for instrumentationm, they need to be combined to create a complete instrumentation configuration. For this purpose, inspectIT 1.6 provides the concept of Environments. An environment brings together the configuration for a target application environment. In an environment configuration the inspectIT users can select the profiles to be used, specify the buffering and sending strategies for the corresponding agents, select platform sensors and provide detailed configuration for individual sensor types. Similar to the profiles editor, inspectIT 1.6 provides an intuitive GUI for editing environment settings. The profiles and environments concepts in inspectIT 1.6 significantly ease the management of instrumentation aspects and reuse of configuration.

Agent Mapping

We need to tell the inspectIT Server which environments shall be used for which agents. For this purpose, inspectIT 1.6 provides an agent mapping configuration as shown in the following screenshot:

Agents are identified by the agent name and the IP address and can get an environment assigned. Both fields (agent name and IP address) allow the usage of wildcards. In this way, whole groups of agents can be specified to use the same environment. By implication, one change on the environment or one of the used profiles affects directly all agents that use that environment or profile, respectively. Hence, manual synchronization of distributed configuration files is gone with inspectIT 1.6.

Start-up Performance

With the new instrumentation approach inspectIT 1.6 shows also an improved start-up behaviour of the inspectIT agents. Since the inspectIT Server manages instrumentation configuration and decides which classes to instrument, the server is also able to track changes in the instrumentation configuration. Hence, at start-up of an inspectIT agent, only those classes need to be processed for which a change in the instrumentation configuration exists. All other classes are served directly from a cache, which significantly speeds up the start-up of the target application with an inspectIT agent.

To sum up, the new Configuration Interface and instrumentation approach of inspectIT 1.6 bring a lot of improvements that make working with inspectIT a pleasure instead of a cumbersome task. The improvements comprise an intuitive GUI for configuration, ease of reusing configuration elements, improved scalability with respect to managing configuration for distributed scenarios, and faster start-up of the inspectIT agents.

Curious to try out the new features yourself?
Visit the inspectIT homepage and download the latest release!

— Alexander