JCatascopia

Introduction

The JCatascopia Monitoring System: is a fully automated, multi-layer, interoperable cloud monitoring system suitable for monitoring elastically adaptive cloud services. JCatascopia runs in a non-intrusive and transparent manner to any underlying virtualized infrastructure and can even monitor services distributed across multiple cloud platforms.
JCatascopia can be utilized to collect monitoring metrics from multiple levels of the underlying cloud infrastructure as well as performance metrics from cloud applications and subsequently distribute them to subscribed users and platform operators.
The JCatascopia Probe API can be utilized by application developers to create their own custom monitoring probes in an easy and straightforward manner. Furthermore, JCatascopia is enhanced with a metric subscription rule mechanism where application developers can subscribe to aggregated metrics and also compose high-level metrics from low-level metrics.
Users and platform operators can monitor the performance of their services and the underlying platform by accessing metrics through the JCatascopia REST API or via the JCatascopia web interface which generates for each metric real-time graphs.

JCatascopia novel features, design and analysis, architecture and evaluation experiments are presented in two scientific publications [C1], [C2] while in other works [C3] , [C4], JCatascopia was used to provision and manage cloud service deployments and to support an elasticity controller while scaling a number of elastic cloud services respectively.
As the contractual development of JCatascopia is shortly coming to an end (October '14), v2.0 will be released and the JCatascopia Probe Library [D2] will be enriched with a number of application-specific monitoring probes.
Most importantly, JCatascopia will continue its lifespan as a standalone system after its contractual obligations have been fulfilled, as we seek to increase its user-base by introducing to the community the JCatascopia website (currently under development) which will exhibit JCatascopia current and past releases, source code, tutorials, documentation and contact form for users in need of support.
The complete source code [D1] of JCatascopia is open-source and available to the community under the Apache 2.0 licence and anyone is welcome to contribute to either the JCatascopia core or to share their Monitoring Probes as the list of available Probes grows larger.

Functionality

JCatascopia monitoring web interface

As we can observe from JCatascopia web interface, the initial deployment is comprised of 3 VMs: (i) a load balancer; (ii) an application server; and (iii) a Cassandra DB node.

JCatascopia monitoring web interface

To stress the video service, we have developed a client request workload generator where the workload form (i.e. sinusoidal, linear),
type (i.e. read-heavy, write-heavy, combination) and parameters (i.e. intensity, max execution time) are all configurable.
Attendees will be able to configure the workload, in order to observe how the workload imposed, affects the overall system.
The following figure depicts a sinusoidal client request rate as shown in JCatascopia.

sinusoidal client request rate workload

The following figure shows the current number of busy threads (active client connections) of an application server which runs the video streaming web application when a sinusoidal workload is utilized.
The current number of busy threads, as well as, memory utilization are key indicators of when a resizing action should be enforced.
When the number of busy threads is too high (low) then a new application server is automatically added (or removed).

JCatascopia: monitoring the active number of connections on an application server

Application scaling based on collected metrics and the user-defined elasticity requirements

Imposing a significant workload to the video service will result in instantiating a number of Cassandra Database nodes to facilitate the high number of client requests to download/upload videos.
In the following figure, we observe that 6 Cassandra nodes are up and running and we can see the average CPU utilization imposed to the Cassandra ring.
The average CPU utilization is exposed by creating in JCatascopia, at runtime, a new metric which aggregates CPU utilization throughout the Cassandra ring.

JCatascopia: viewing the average CPU utilization on a 6 node cassandra ring

Finally, in the following figure we can see the deployment after an hour which we can see that currently 9 nodes (1 load balancer, 2 application servers and 6 cassandra nodes) are up and running.

JCatascopia: viewing the video streaming service deployment after an hour

Code Repository

The code for JCatascopia and details on how to use it can be found on the links below. Here, one can find the required information on how to write and configure the user application specific monitoring probes:

This video showcases the use of two open source tools: the c-Eclipse tool for describing and deploying cloud applications and JCatascopia for monitoring the performance of the deployments. First, using c-Eclipse, the user creates a vendor-neutral description of the application containing its topology, together with the artifacts required to realize its deployment. Such artifacts can be the application executables and binary artifacts, the deployment scripts and the key pairs for accessing the deployment. The important metrics to be monitored by the JCatascopia monitoring system can also be specified.
In the next phase, the application submission phase, the user selects Amazon as the Cloud vendor for deploying the application, and he enriches the vendor-neutral description with Amazon specific information, such as virtual machine images and elasticity strategies. Then, the applications description is send for deployment to the orchestrator hosted on Amazon EC2, and the deployment status is presented in c-Eclipse.

Once the application is up and running, JCatascopia collects the specified low level and application level performance metrics and displays them to the user through intuitive graphs.
Users can also create at runtime aggregated monitoring metrics which are also presented graphically through the JCatascopia web interface. Finally, the deployment scales at runtime by adding and removing virtual machines, based on the elasticity strategies specified by the user in c-eclipse and the monitoring metrics reported by JCatascopia. JCatascopia monitoring agents are added and removed automatically to satisfy the new deployment resulted by the scaling actions.