Yes, your understanding is correct. More specific answers inline in your text. 2016-03-22 16:08 GMT+01:00 Vincent ZURCZAK <vzurczak@linagora.com>:

Hi,

I have questions about OCCI Monitoring. I read the specifications [0] and the Slideshare's presentation [1] of Augusto Ciuffoletti.

I would like some clarifications, just be sure I understand correctly the scope of this specification. In the same way than OCCI Infrastructure provides an API to create infrastructure resources (virtual machines, network configurations...), OCCI Monitoring allows to configure probes and measures collection. So, assuming I have a model of OCCI resources associated with the following Software architecture...

... that is to say machines, network and storage resources (IaaS), applicative resources (web server, application server, database - and assuming I wrote OCCI extensions for them), then OCCI Monitoring would allow me to configure their monitoring through a single (REST) API. One API to configure the monitoring of several cloud layers / providers. So far, so good, right?

Yes

What is not clear to me for the moment is the following. Does this API also allow to request directly a sensor? Assuming I have a sensor that collect CPU usage, is it this same API that can give me the probe's value (i.e. the CPU usage at this specific moment)? This is not the same question than "can I implement a sensor / collector / publisher that makes my monitoring data available through a REST service" (to this, the answer is definitely yes). For what I understand, the answer is no. OCCI Monitoring is about monitoring configuration, not about monitoring itself. An API that implements OCCI Monitoring is not an API that exposes a probe as a REST service (or at least, it is not its spirit).

Yes, the description of the implementation of the measurement/processing/delivery activity is not in the scope of OCCI-monitoring. But you have the hooks to attach a specific implementation to a given sensor or collector. That is, to say that a given collector measures the cpuload of a given core, or the average traffic on a webserver by using the OCCI monitoring interface. The hooks are provided by the mixin mechanism: you instantiate your collector, and next you attach to it the cpuload mixin that you have defined and implemented. The collector is totally abstract, and you add meaning with mixins that you define. The same for the sensor, that processes and publishes the aggregated measurements. This has the great advantage of letting users keep the rendering /

analyzing tools they want.

Yes: the users define the mixins and plug them into the entities.

I was also wondering whether there were real implementations of OCCI Monitoring.

There are currently two prototype implementations: one in Java, another in Ruby. The difference between the two is that the first one is as "elementary" as possible (sockets, rmi, pipes), while the other exploits advanced tools like websockets, lightweight servers and such. I have a paper describing a Ruby docker-based implementation of the whole thing, where OCCI entities are implemented as Docker containers. It should be open access here <http://dx.doi.org/10.1016/j.procs.2015.09.232>. I can send you a copy anyway.

I saw Augusto will present "Beyond Nagios - Design of a cloud monitoring system" in Rome, in April. Unfortunately, I will not be able to attend it. What level of maturity does it have?

Maybe you are at SOSE in Oxford next week? I'm going to be there, and in case we can meet. It is difficult for me to understand the level of maturity of an idea of mine. I'd say that it is ready for a real scale experiment. There is a journal paper <http://www.sciencedirect.com/science/article/pii/S0920548916000027> with a more detailed description of the monitoring interface that is already available in its web version, and should be published around May. Probably free access until April 12, but again, if you can't download just ask me. Bye Augusto

Best regards,

Vincent.

[ 0 ] : https://redmine.ogf.org/attachments/182/monitoring.pdf [ 1 ] : http://slideshare.net/AugustoCiuffoletti/2013-03-occimonitoring-26159563

-- Vincent Zurczak Linagora: www.linagora.com

[image: Twitter] <https://twitter.com/VincentZurczak> [image: Vincent Zurczak @ LinkedIn] <http://fr.linkedin.com/pub/vincent-zurczak/18/b35/6a7> [image: My Skype ID] <callto://vincent.zurczak> [image: My English blog] <http://vzurczak.wordpress.com>

_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg

-- Augusto Ciuffoletti Dipartimento di Informatica Università di Pisa 56100 - Pisa (Italy)