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.
Applications grow. At least successful applications. At some point your growing application will require a loadbalancer. It may be for scaling or availability purpose or something else. The day your application runs behind the loadbalancer first time will make you proud. And it will make you ask, how can I control what the loadbalancer thinks of my application availability? This is how.
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.
Today we are going to connect MoSKito-Central to MongoDB database.
In a few words, MoSKito-Central is a service (remote or embedded) that receives your MoSKito statistics and stores it in the place of your choice (Filesystem, Database, …).
Our choice for now is MongoDB and MoSKito-Central in embedded mode.
About 10 years ago log4j was the logging framework for java. Years passed and many logging frameworks emerged. For many people, including myself, logback is the new log4j (and that is not only because of Ceki).
Unfortunately it is not possible to run logback as slf4j implementation OOTB in JBoss like in Tomcat. The following 5 steps explain you how to get it running.
today I am going to speak about a concrete example of the MoSKito Control capabilities. Today we will build up a monitoring system, but not for WebApps as in previous posts, but for just plain java processes, that we are going to call daemons. Daemon, in my understanding, is just a plain old java bean/thread running in background in a separate JVM and doing some work. To make the post easier to write I created a small project on github that serves me as example:
This is a small sidekick for this post. People often complain that automating the deployment line is sooooooo hard. It isn’t. This post explains the simplest way to automate something with the less possible effort.
I have had 2 talks about DevOps@Runtime (here and here), I’ve also been talking to people about the topic and I’ve promised to write a blog post about it, which I’m doing now. But before I can start with the Runtime, I have to talk a bit about DevOps in general and what it is. Therefore, in the prologue I will explain DevOps in a NutShell 😉
I just came back from the DevOpsDays 2013 in Berlin earlier this week, and wanted to share my impressions.