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.
From time to time we are asked by the users of MoSKito, how to do this or that, and how to implement a specific use-case with MoSKito. This is why we started a recipes section in our documentation and now also on the blog. A recipe will describe how to achieve a specific goal.
So the original question which led to this recipe: “Lets say I have a process, some kind of job, which is running every x seconds, and I want to monitor the number of successful and unsuccessful executions, with least possible effort”. And here how it goes.
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 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.
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:
We ‘invented’ (at least we say we invented it, until someone else claims the authorship), that kind of locking, where you lock not an object itself, but what the object means in the real world (or at least in your domain). It was long part of the ano-utils project. However ano-utils is a bit bloated, so we refactored it into a small separate project, without any further dependencies to external libs.
I will not repost the explanations why it is needed and what it does, instead just a link to the github page, that explains everything: https://github.com/anotheria/idbasedlock
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.