Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 15 Next »

What is the general project status?

In short

Production quality and being continuously developed further ;-)

Short preface
MoSKito was started in 2007 and used in various production environments (friendscout24,,, etc) since 2008. So it is very stable and absolutely ready for production. In the beginning of 2013, we extracted some parts of it into separate projects, namely moskito-control and moskito-central. The "original" MoSKito has been renamed to "MoSKito-Essential" (just because it needed a name, and MoSKito-Core was already taken) ;-)


Status: Stable & production ready.

The project is in production since 2008, being continuously enhanced since then (support for aop and spring, cdi, etc).


Status: Beta

MoSKito-Control was initially created as part of a customer's project and was donated back to MoSKito project. The story is covered in Everything in Control blog port.
After the donation, a huge part of the code was rewritten for making it more generic and removing the customer-specific code. Currently, MoSKito-Control is in beta.



MoSKito-Central was part of moskito, and was refactored into a stand-alone project in 2013. It got some recent additions, for example, psql or mongo (currently in progress).

MoSKito on mobile devices

There are apps for MoSKito-Essential and MoSKito-Control in the iOS app store.

MoSKito-Control for android is being currently developed by a volunteer. 

What is the performance overhead of MoSKito?

Well, the answer to this question is rather unsatisfactory: "It depends!" 

It depends on multiple values, first of all integration type and number of monitoring points. To be clear: each monitoring point costs time. The exact time depends on integration type. For example, Proxy integration is slower than AOP compile time weaving. However, in almost all cases, the costs are in lower microseconds area, depending on your hardware. 

For most web applications the performance drawback of MoSKito will be not measurable. It may consume a bit more CPU, but will be most surely unnoticed by the end user. 

In other words, you can use MoSKito without thinking about performance impacts, until you really see some.

What is the memory footprint?

MoSKito Essential runs within your app's heap space and therefore consumes some of it. Usually the amount of memory used by MoSKito is significantly lower than the amount of memory used by the monitored code. So in case you have millions of monitored classes and your heap size is above 10 Gb, MoSKito will consumer some few hundred MBs, which is about 1-3 percent of your heap. If you have a small application, with 128 MB heap MoSKito will usually consume 1-3 MB. You can calculate your exact memory footprint by creating a histogram. 


I don’t see any feedbacks and reviews on MoSKito, as well as, JIRA is not very active. So do you have any usages references and/or external reviews ?

We have some feedback in our blog, for example, as well as reviews or feedback from conferences and stuff. There are also some references on the homepage We can also provide contact to users from other companies. 


Which components (Essential, Center and Control) are ready for use and on which level (beta/rc/release) ?

Essential in production (release) since many years
Control - in production but still beta, mainly due to polishing.
Central - partially release, some parts are still beta, for example support for postgres.


It is not so clear if Control is a standalone solution or it requires Essential & Center as prerequisites ?

Technically control is a standalone solution. But it doesn't collect any performance data by itself, instead it collects the performance data gathered by other applications. One such application is moskito-control-agent for java which is deployed into the target app (via mvn dependency or just by adding the lib). It uses moskito-essential for actual gathering of the statistics.
So its control ---> network ---> agent --- local_call ---essential.
Technically an agent can be provided for any other language or environment such as php or .net, however there are no 3rd party languages yet.
This blog post: tries to explain what different components stand for. we understand that it can be confusing, but we were not able to come out with shorter naming yet ;-) Well, after all we are mainly developers and not marketers.


Which client side framework is used for charts generation ? Does charts support manipulations like zoom in/out, ranges ?

For charts we use Google Charts:
In the iOS apps we have a small 3rd party open source engine, because google charts was too heavy to use (especially to load on lower bandwith).


Does Center support storing information in Oracle ? Do you use Hibernate and Spring for that, if yes, which versions ?

We are using hibernate 4.2.0 via JPA 2.0.
This should also support oracle by just configuring the proper jdbc driver. However Central is designed to support custom storages, so it is not a problem to add a customized storage that writes the data in the database of your choice in the format of your choice by implementing an interface. It is possible to get this implementation from us also ;-)


Does HTTPS supported for communication between its’ components and for Web UI ?

Yes all the ios apps do support http basic authentication. Also all web-based MoSKito applications support https (or run in a container on https port).



Is there an option to get support?

Yes, you can always write to the mailing list: or via Nables:

For professional support write to



Where is the source code?

Until recently we had the source code in our own subversion repository, accessible from outside. However, we migrated it all to github:








  • No labels