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 24 Next »

What is the general project status?

General status

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: In production, but still beta (mostly due to fine-tuning).

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.


Status: Partially released, some parts are still in beta (support for postgres and other features).

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. They are free and fully functional.

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.

Are there any external reviews and/or usage references for MoSKito?

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

Is MoSKito-Control a standalone solution or it requires Essential & Central?

From the deployment point of view, MoSKito-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 of such applications is moskito-control-agent for java, which is deployed into the target app (via maven dependency or just by adding the lib). MoSKito-Control uses MoSKito-Essential to actually gather the statistics.

So, the data flows like this:
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 supported 3rd party languages yet.

This blog post describes all MoSKito projects and components, explaining their relations. We understand it can be confusing in the beginning, but we were not able to come out with shorter naming yet ;-)
Well, after all we are mainly developers and not marketers.

What framework is used for charts? Do charts support zooming in/out and ranges?

We use Google Charts: Please refer to Google charts documentation for more details.

In the iOS apps we have a small 3rd party open source engine, because google charts were too heavy to use (especially to load on lower bandwidth).

Can MoSKito-Central store information in Oracle ? What instruments are used for that?

We using Hibernate 4.2.0 via JPA 2.0.
This should also support Oracle by just configuring the proper jdbc driver.

However, MoSKito-Central is designed to support custom storages, so it is not a problem to add a customised storage that writes data in the database and format of your choice, by implementing an interface. You can also get this implementation from us ;-)

Does MoSKito support HTTPS for communicating with WebUI and other components?

Yes, it does.
All web-based MoSKito applications support HTTPS (or run in a container on HTTPS port).
Also, all the iOS apps support basic HTTP authentication.

Can I get support for MoSKito?

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

For professional support, please 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