The first MoSKito Hackathon this year took place in Kiev on June 17th. This is the report.
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:
In all previous steps, we integrated MoSKito into our application and set up data storage. In simple words, we learned how to monitor our app’s performance and store the obtained MoSKito data for later analysis. What’s next?
Here’s the good news: our burgershop is now the world’s leading burger-seller, with million revenues. It has become a big distributed app, with multiple instances and servers.
The bad news: even the smallest fail might lead to a thousand-euro loss per minute.
The question: how to keep trace of hundreds of producers on a dozen of instances? It’s the moment to call
Superman another hero!
So, today we’re setting up MoSKito-Control, a tool for monitoring multi-node web applications.
You may ask “Why do we need it?”, the answer is: our burgershop has become a real empire with multiple application instances and we want to monitor all of them and consolidate the obtained performance data in one place.
So, let’s start!
Today we are going to unlock even more MoSKito power: more persisting, more centralising.
As you know, we can access MoSKito producer’s statistics while application is running: http://localhost:8080/burgershop/mui/mskShowAllProducers.
But what if:
- we want to check statistics for some time ago, like the last night, when we were sleeping?
- we want to have and check statistics for all our applications, not only a single burgershop (as good businessmen, we surely have various projects to be safe from total fail one day!)?
- we want to automatically analyse the collected (in time and space) data and make
some strategical changes, based on results of this analysis?
The answer to all these if’s is: MoSKito-Central.
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.
After we created our guinea pig in the previous step, it’s now time to integrate MoSKito-Essential into our application. Our plan for today is:
- Add monitoring to the core parts of our code.
- Download and connect MoSKito Inspect
- Learn about WebFilters and Listeners
At the end of the guide we want to:
- see the access data in MoSKito Inspect,
- record a Journey.
Despite the efforts we put into MoSKito documentation, we are continuously facing questions like ‘How to do this’ and ‘How to get that’.
Now we want to give you a guide for the whole setup cycle, which this posts starts.
The guide will cover a complete application lifecycle with MoSKito, from integration of the first MoSKito-Essential Producer to installing MoSKito-Control and MoSKito-Central setup.
But before we start, we need a guinea pig. This is what we do today – set up a simple application for experimental purposes.
Slowly but inevitable the holidays are coming and with that an urge to make some kind of retrospective for 2013. We will not do that. But instead we will shortly speak about recent MoSKito development and what lies ahead in 2014.