A new version of inspectIT has been released! And this time, besides many new features and bug fixes, we introduced our concept of tracing cross-JVM requests.
Up until now, inspectIT was focused on analysing and monitoring a single JVM from which you could extract much information for resolving and understanding any kind of problems. And even though you could add as many agents to a single server as you wanted; the moment a call was made from one JVM to another, the complete link between these two were lost. This is especially a problem if it comes down to the “new age” of how applications are currently developed: rather small, independent from each other, functionality is achieved by orchestrating services. To gain an end-to-end view, our past approach was definitely lacking in this area and this feature is now clearly filling up that hole.
Even though it sounds like we recently started developing this feature, it is actually quite old for us. Years ago we already wanted to go for it – and even developed some small PoCs – but more important features at that point in time were pushed forward and this was restrained for a bit. From my current perspective, this was a good thing! This allowed us to base our current implementation on a quite new open standard: opentracing.io. We love Open Source, we really do. And for that reason it was a pretty obvious approach to go for a vendor-neutral open standard for distributed tracing. What this means is that if you go for a programmatic approach to integrate additional tracing information in your application, only a very small part of it references inspectIT directly, everything else is just using the standard opentracing classes and interfaces (which we want to show you in a later blog post). Thus you will not be bound to inspectIT and can easily switch – if you want to – to another realization of that standard. Flexibility at its finest!
Alright, enough of the introduction, lets get down to the real deal!
# This will take some time until everything is started, just wait for it
Start now the UI and if everything worked out, you should see 5 connected agents in the Repository Manager:
The browser should also open the petclinic page automatically. If it doesn’t, just browse to http://localhost:8080/#!/welcome. Play around with the application a little bit; show and add new owners, list the veterinarians etc. After you have generated some data, open the inspectIT UI again and switch to the Data Explorer. A little bit hidden for now is the new action to show up the tracing view:
Execute the action and you should see some similar traces like in the following picture:
As you can see, we provide information about the start time, duration, type of the propagation (like HTTP, JMS) and a unique Trace ID. The details column list the URLs being called with some additional information like the response code and used http method. Don’t be surprised about some entries having a prefix “Client”. This indicates that we recorded a call to some system, but we have no entry point recorded into this system before this call. It happens here because these health calls for instance are executed regularly without any user interaction needed. We could further configure it to have own entry points defined if we really want to.
Quite standard for the UI is now how to go further. Just double click on an entry to retrieve all the details of this trace. For demonstration purposes, I will open a trace which includes opening the details of a pet owner:
If you worked with inspectIT before, this view should remind you of how invocation sequences are presented. The top will show all the entry and exit points recorded by the agents into all the applications that are monitored. In this case, the api-gateway and customers-services are included. The bottom will fill up the tracing details with data from the invocation sequences involved in this specific trace. Thus all SQLs, exceptions, timing information will be added into this tree to provide a complete view over the whole trace!
And with this whole picture, you can easily understand and visualize the complete dependencies of calls between all the monitored applications that you have rather than a single view on each one of them. This will help massively in locating any kind of problems and on the other side understand the impact of problems to e.g, users and the applications functionality.
As always for us, this is not the finish line of the feature but rather the start. Many additional features and views which we consider important are not yet there. This includes for instance a topological view over all the agents, combine invocation sequences and tracing information even more so that only one is needed in the future, change the UI to be completely application-focused and not agent-focused and many more.
For our next release 1.8, we will further extend our end-to-end tracing vision by including the browser as well. Many APM tools already provide a browser agent to have an end-user monitoring available as well. This end-user monitoring (or short EUM) provides metrics / statistics about the users environment, loading / rendering times and much more. In addition, requests from the user will also be correlated and integrated into our traces so that requests do not start at the server anymore but in the client. The development of our browser agent already reached a very good state and the first iteration is very close to being integrated. If you want to have a sneak preview of this, just jump over to the page “Integrate inspectIT default dashboards” and take a look at the last 3 screenshots. The are created with metrics sent by the browser agent.
We would be happy to hear from you what you think about our new tracing feature and what you like to have in the future! Just come over to our chat at Gitter and say Hi :-).