Monitoring in Federated and Self-Manageable Clouds are three kinds of consumers, other Cloud com- ponents, the Cloud administrator and the Cloud clients (both human and their software, if any). Depending on the nature of the consumer, there are differences in the format that the monitored data are communicated to their target (like UIs & friendly alerts, as opposed to a REST API), as well as the amount of historical information that has to be kept by the monitoring mechanism (real time feeds, as opposed to batch analysis). In addition, providing monitoring information to the Cloud platform's clients set another set of requirements, mostly regarding security, since the Monitoring mechanism is publicly visible, but also they may have to do with SLA. The aforementioned list of requirements should make it obvious that the realization of a Monitoring mechanism which covers all of them requires a very delegate design of its architecture. There is no solution, to the best of our knowledge, which would primarily serve as a system moni- tor rather than an integrated system component. This task can be undertaken by tools like Collectd (Collectd - The system statistics collection dae- mon, n.d.) and Ntop (What is ntop, n.d.), the later only monitoring network resources. These tools would need a great deal of time and effort put to managing them, since they offer no support for several features, notably failover, interoperability with other instances of themselves, no notion of elasticity or resource migration, and they are not autonomous. However, it should be noted that these solutions are among the ones which have the less overhead on the monitored host or network. One step further lie tools which have been designed for monitoring large clusters of nodes. Such systems are Nagios and Ganglia, both open source solutions. They are all modular solutions to allow for custom and extensible list of probes. They also excel in scalability, able to manage