People have been asking us time over time, if it’s possible to disable MoSKito in a running system completely. Also we don’t understand why you’d ever want to do it, after first pull request for this feature has been opened, we understood that people are quite serious about it. Well your wish, is our command, so here it goes.
We continuously monitor how other developers use MoSKito with a wide variety of their web-apps, we carefully listen to their feedback and in response we keep adding new features along with tweaking existing ones to make MoSKito more and more robust with every released version.
Today we would like to introduce you two more built-in tags. These new tags were found to be highly useful in real working environments. They will save you a lot of time and they will allow you to understand reasons behind certain bugs much easier.
Custom dashboards are clearly one of the most useful visualization features MoSKito has to offer. The ability to see all related information at a glance collected in one place improves the analytic capabilities and help tracking the anomalies. However, until now, configuring a dashboard could be cumbersome especially with high amount of charts and producers. Also adding a new producer to the system would require to add it to the dashboard explicitly, a step that could easily be overlooked. With MoSKito 2.8.7 we improved!
MoSKito has many powerful features, it can monitor almost every aspect of your application, it is the worlds best open-source APM for Java. But sometimes all this functionality can be a bit overwhelming to the user, and you might run into some issues figuring out how monitor your app efficiently. To address this, and give you an example of problem solving with MoSKito, today we will give you an insight on a real life case of tracing bugs and optimizing your application using MoSKito.
In this tutorial we will demonstrate how to use MoSKito Javaagent to monitor existing web-application with no changes to the app’s source code. We will show how to add MoSKito Javaagent to the app deployed in Tomcat servlet container, and how to connect to this app using MoSKito Inspect.
Today MoSKito 2.7.3 is released, and it contains the hottest feature since long time. But decide for yourself.
The feature request goes back some years to Dec 02, 2010 to my time at Parship, as Malte once asked, if it would be possible to know where a call to a method actually came from. It was on the list since then, but time was hard to find.
So what are tracers anyway? Tracers have 3 purposes or aspects:
- Tracers allow you to find out which part of your code has been calling some methods in a class of your application you are interested in. They achieve it by guarding the class in question (works with most monitoring points) and triggering and saving a stack trace once something passes by. This is useful if you see strange behavior of some method/class in the MoSKito monitoring, but don’t know who is actually using this class.
- After the execution has passed the tracer, the tracer start to record everything that happens afterwards. This means that a TracedCall (part of MoSKito Journey) is created on the fly and recorded. Every call on the monitored class will be noted, along with parameters and return values.
- To round this up, tracer will gather some amount of traces (code passing by). Depending on how you configured MoSKito, the tracers could collect only calls with largest duration or simply oldest or newest calls. This way you can run a tracer over a long period of time, collect all slow calls and investigate what slows them down.
MoSKito enables you to analyze and monitor your running Java application.
During this blog post, we guide you how to fully integrate MoSKito within Java EE 6 environment und run it with JBoss Application Server 7. Furthermore we provide some hooks for integrating Producers, Threshold and Accumulators.
Back in 2010 we were helping Parship to migrate their platform to a new provider and establish working application management. Migration to a new hosting provider and parallel re-architecturing of the platform is a funny combination and it actually rattled from time to time. Now imagine the situation were you have 4 different parties with at least 4 different tools and every tool shows something different.