Traditional monitoring systems such as Ganglia or Nagios are designed to monitor infrastructures which have low volatility, i.e., change at a very low rate, and assume a monitored node/machine dies only if an error occurs.

MELA differs, as it assumes virtual machines are volatile, and only the service running those virtual machines is persistent. Thus, MELA associates monitoring information with the service structure, without loosing information if VMs disappear.

Traditional monitoring systems associate monitoring information (i.e., metrics) with individual VMs or virtual clusters. As the virtual infrastructure running elastic cloud services is volatile, MELA allows associating metrics to logical service elements: service units, topology, or whole service. This enables analysis of service unit behavior, irrespective if or or more service unit instances run on one or multiple virtual machines.

Traditional monitoring systems just collect monitoring information, and do not enrich it with information hard to monitor directly, such as virtual infrastructure usage cost. As elasticity of cloud services revolves around resources elasticity (allocation, deallocation), quality elasticity (increase/decrease), and cost elasticity (changing pricing schemes, increasing/decreasing cost), only directly monitored information is not sufficient for analyzing the elasticity of cloud services. MELA provides users the ability of defining custom metric composition and aggregation rules. Using such rules, one can create new metrics based on existing ones, add enrich collected information with information hard to monitor directly, such as cost.

The service units, topologies and whole cloud service have elasticity boundaries on the service metrics (i.e., service elasticity dimensions) important for the MELA user. These boundaries are requirements expressed over the service metrics, which need to be enforced by elasticity controllers. Simple boundaries could be "response time < X", "latency < Y". A higher level requirement could be "cost/client/hour < Z$".

Unfortunately, many times the complete boundaries needed to control the service are not known in advanced. For example, a service owner might know that s/he wants a cost less than 10$/hour, but might have no idea on what the values of CPU usage or response time need to be for the cost requirement to be fulfilled. Knowing the complete boundaries is crucial for elasticity controllers which must determine what is the cause of requirements violation. For example, if the previous "cost" requirement must be enforced, a controller must decide if the cost is too high due low number of clients, which means resources are underused and a SCALE IN is needed, or due to very high response time, which means resources are overused and a SCALE OUT is needed.

MELA provides functionality for determining, from real-time monitoring information, the elasticity boundaries of all metrics recorded for a service, thus allowing a human user or automated controller to analyze which metrics do not respect their individual boundaries, and take appropriate actions.