During my intership in Inria Nancy in 2014, I contributed 6 months on this project to add network monitoring to Kwapi.
I adapted the code, make it compliant with Grid’5000 environment, packaged it for Debian. Then I created one VM per Grid’5000 site, write a Puppet module and deploy it everywhere.
After that, I continue to maintain Kwapi during 2 years, adding some patchs and checking the monitoring on every site.
This is an extract from Grid’5000 website about Kwapi:
Measurements using Kwapi on Grid’5000
For the classic Ganglia measurements, a user requiring a higher resolution can simply deploy his own measurement probes and sample them at a higher frequency. This is not true for all measurements, in particular for probes outside the control of users such as power consumption probes on power distribution units (PDUs) or some network links. This is why Grid’5000 has deployed an adaptation of work on power metering developed by Grid’5000 users named Kwapi (reference page, github page). For the curious, the reference code and developer documentation is available. In the context of Grid’5000, it should be noted that :
- Measurements in Kwapi-g5k are stored in an HDF5 file : no data is lost over time.
- The web interface to display metrics (example for Rennes is aware of OAR jobs, to allow users to have an experiment-centric view of the collected data.
- Kwapi-g5k comes with a native API to retrieve data. This API is partly compatible with the one developed for Ganglia.[…] This gives the illusion of a unified Metrology API to most users.
- No user defined measurements can be collected by Kwapi-g5k.
- There is a 5minutes delay (300 collected values) before data are written to the disk and accessible via the Kwapi API. This delay has been introduced because Kwapi use NFS volumes to store data and frequent writes stress the NFS servers. HDF5 API should be used to retrieve data after an experiment. For more instantaneous results, you should use Kwapi API (port 5000) which expose data in a “Ganglia like” way.