inspectIT 1.5 Release Notes

02.05.2014 With great pleasure, NovaTecs APM competence group presents the new version 1.5 of inspectIT. Once again NovaTec demonstrates that application performance management can be done without high initial tooling costs and that free solutions are available.

This release was once again quite a big one. Actually we even intended to extend the size of the release but recognized that we should allow our users to use these new features and move the other features to a version 1.6. There is so much we improved and extended that I really had problems writing these release notes.

Licensing be gone

inspectIT will be even easier to use for you as we drastically removed our licensing approach. With 1.4 you had to request a license and update this license at least every year. Furthermore we had some restrictions on the use of inspectIT, that irritated some of our users. We heard your complaints and removed the need for renewing the license entirely. Sure there still is a small license but this license only states that inspectIT is free, but not open source, so everyone should now be able to use inspectIT without further complications.

jRebel compatibility

From the new version you can enjoy having both jRebel and inspectIT active on your application server. The compatibility with jRebel does not only mean that inspectIT functions flawless when jRebel is active, but also enables monitoring to continue being active even when class is changed and reloaded by jRebel. Quite a cool feature for all the developers who like to "hot-deploy" all day long.

Storage optimizations 

The main feature of inspectIT 1.4 was the storage concept that allows user to store metric data persistently. With 1.5 we further improved the functionality of the storages.

Automatically store data to storages with the new RESTful service.

First and foremost we allow all storage operations to be accessible via the RESTful Storage Service. We already use this feature internally in our weekly loadtest of inspectIT - which ensure that inspectIT performs as desired. Before our tests we start a new storage, record the whole loadtest in the storage and at the end of the test close the storage. 

You can now completely automate inspectIT for your loadtest. Simply tell your loadtest script to first start a storage and - at the end of the run - save the storage and you are good to go. Running loadtests at night and analyzing the data the next day is now piece of cake. As the REST API often uses the storage ID as key, we now provide the storage ID in the CMR storage view.

Future recording & Download speed & Co.

We are very passionate about thinking about every possible way of improving a feature of our tool. Thus we integrated additional "nice to have" information in the storage.

Imagine your loadtest starts at 23:00, you do not want to be the one clicking on "start recording now" in inspectIT to gather data. But you also do not want to run your test without inspectIT data, because how would you diagnose an arising problem? With inspectIT 1.5 you will now be able to define a start time in the future so you can go have a drink, or just go to bed. Also, an often asked feature was to see the download speed of storage (when transfering the storage from the server to your local environment), so here you go, integrated as well. You want to download multiple storages at once, your wish is our bidding.

Created storages are not per se backward compatible. We do not offer this feature as this will potentially hinder us in further optimizations. Thus we now provide the version with which a storage was recorded.

We also included statistical information about the storage status to our statistic log.

Autofinalize

Delete not finalized storages

start and end dates

Web monitoring improvements

Charting improvements - Charting webrequests for monitoring is now easy

With inspectIT 1.4 we introduced HTTP diagnostic possibilities. With 1.5 we extended the possibilities and allow to display the timings in charts. This new charting feature can also be used when selecting other data.

Business mapping

Since often different URIs represent the same action, inspectIT bring the possibility to define the regular expression and regular expression template that can be used to transform the URIs. Please read the Http Sensor for information on how to correctly define these in the HTTP sensor definition.

URis	Transformed URIs with regular expression

Usability 

Easy-to-use installers

inspectIT now ships with easy-to-use installers that you can use to install all three components of inspectIT. The installers can also be executed on a non-ui system.

Welcome Screen in the inspectIT UI

If you are the first-time user of inspectIT our new Welcome Screen will quickly point you to the most interesting topics you need to know before starting to monitor your application. Even if you are a long-time user of inspectIT, you should check it out, you might learn something new.

Restart/Shutdown of CMR via inspectIT UI

Not have access to the machine where the CMR runs and you would like to restart it or shut it down. Not a problem anymore, since the new versions brings the possibility to execute these tasks directly from inspectIT UI.

Misc

Performance improvement

We integrated a new communication format and now use this format between client and server. This reduces the amount of data being transferred and thus improves performance.

In addition we did a huge improvement in the way we collect database related metrics. Especially for prepared statements with enabled bind parameter capturing, we managed a big performance improvement.

We found a performance problem in our exception tab display in the invocation sequences. Guess what, it is gone now.

Agent sends remaining data on JVM shutdown

When monitored application is terminated the Agent will send the remaining monitoring data to the CMR. This feature proved to be very useful when monitoring a short-running Java applications.

Agent configuration can now be shared, specific configuration can be done via command line properties

We optimized the setup of inspectIT for larger environments. If you have multiple instances of your service, you usually use the same configuration of the agent. With inspectIT 1.5 you can now use the same configuration file for all these environments and override the specific information, like the agentname, using command line parameters.

inspectIT can now also be used for short running tests

Prior to 1.5 inspectIT send data only at some intervals. If you stopped the application under diagnosis it could happen that you lose the diagnose data of the last few seconds. inspectIT 1.5 now fixes this problem. You will always ever get all diagnosis data.

Disconnecting an agent now shows in the UI

Disconnecting an agent now sends a signal to the CMR. Prior to 1.5, the agent was still being listed as active.

Deleting old agents

Agents can now be deleted using the inspectIT frontend. This will internally also delete all the data in the database and thus reduce its size. Great if you used inspectIT for a longer period of time or if you just want to clean up.

Quality improvements

No error is just good enough

We further invested into the improvement of our test procedure and increased test coverage. Since the start we have the credo "If some code analysis tools thinks there is a warning, treat it as a defect". Our automated and release process fails as soon as some QA tools even suspects a problem. We also used ThreadSafe to analyze our code. A great tool, we wrote a small blog post about it: http://blog.novatec-gmbh.de/threadsafe-fast-way-discover-concurrency-problems/

Diagnose inspectIT with inspectIT

You might ask yourself: "How do the inspectIT guys analyze inspectIT for performance problems". We use inspectIT for that as well. We bootstrap ourself and are able to analyze ourselves, pretty cool, right.

Continuous Delivery with continuous loadtesting

In addition we have - and improved - our automatic loadtesting approach. See we have these servers internally that we use for testing our development. On the weekends nobody is using them, which bothered us, as this is a lost resource. Thus we execute quite a big loadtest automatically every weekend on our current version and get automated results about our current performance.