OCCI monitoringextension

Augusto Ciuffoletti

OCCI monitoring extensionand its proof of concept

Augusto Ciuffoletti

Dept. of Computer Science - Univ. of Pisa

September 5, 2014

OCCI monitoringextension

Augusto Ciuffoletti

The OCCI framework

I There is an interface between the user of a cloud serviceand the cloud service itself

I Data entities that describe the service traverse thisinterface during its provisioning

I The protocol used during this conversation follows theREST paradigm:

I the user plays the role of the clientI the conversation follows the HTTP protocolI responses are cacheable, as far as possible

I OCCI proposes a minimalistic conceptual framework (orontology) for the entities used to describe the service

OCCI monitoringextension

Augusto Ciuffoletti

The OCCI framework

I There is an interface between the user of a cloud serviceand the cloud service itself

I Data entities that describe the service traverse thisinterface during its provisioning

I The protocol used during this conversation follows theREST paradigm:

I the user plays the role of the clientI the conversation follows the HTTP protocolI responses are cacheable, as far as possible

I OCCI proposes a minimalistic conceptual framework (orontology) for the entities used to describe the service

OCCI monitoringextension

Augusto Ciuffoletti

The OCCI framework

I There is an interface between the user of a cloud serviceand the cloud service itself

I Data entities that describe the service traverse thisinterface during its provisioning

I The protocol used during this conversation follows theREST paradigm:

I the user plays the role of the clientI the conversation follows the HTTP protocolI responses are cacheable, as far as possible

I OCCI proposes a minimalistic conceptual framework (orontology) for the entities used to describe the service

OCCI monitoringextension

Augusto Ciuffoletti

The OCCI framework

I There is an interface between the user of a cloud serviceand the cloud service itself

I Data entities that describe the service traverse thisinterface during its provisioning

I The protocol used during this conversation follows theREST paradigm:

I the user plays the role of the clientI the conversation follows the HTTP protocolI responses are cacheable, as far as possible

I OCCI proposes a minimalistic conceptual framework (orontology) for the entities used to describe the service

OCCI monitoringextension

Augusto Ciuffoletti

The OCCI framework

I There is an interface between the user of a cloud serviceand the cloud service itself

I Data entities that describe the service traverse thisinterface during its provisioning

I The protocol used during this conversation follows theREST paradigm:

I the user plays the role of the clientI the conversation follows the HTTP protocolI responses are cacheable, as far as possible

I OCCI proposes a minimalistic conceptual framework (orontology) for the entities used to describe the service

OCCI monitoringextension

Augusto Ciuffoletti

The OCCI framework

I There is an interface between the user of a cloud serviceand the cloud service itself

I Data entities that describe the service traverse thisinterface during its provisioning

I The protocol used during this conversation follows theREST paradigm:

I the user plays the role of the clientI the conversation follows the HTTP protocolI responses are cacheable, as far as possible

I OCCI proposes a minimalistic conceptual framework (orontology) for the entities used to describe the service

OCCI monitoringextension

Augusto Ciuffoletti

The OCCI framework

I There is an interface between the user of a cloud serviceand the cloud service itself

I Data entities that describe the service traverse thisinterface during its provisioning

I The protocol used during this conversation follows theREST paradigm:

I the user plays the role of the clientI the conversation follows the HTTP protocolI responses are cacheable, as far as possible

I OCCI proposes a minimalistic conceptual framework (orontology) for the entities used to describe the service

OCCI monitoringextension

Augusto Ciuffoletti

The OCCI core concepts

I Anything is an entity, and is identified with an URII A relationship between entities is an entity

I we distinguish resource entities and link entities(relationship)

I There are many kinds of entities, with distinguishingattributes

I An entity of a certain kind can be integrated withmixins that carry more attributes or bind existing ones

OCCI monitoringextension

Augusto Ciuffoletti

The OCCI core concepts

I Anything is an entity, and is identified with an URII A relationship between entities is an entity

I we distinguish resource entities and link entities(relationship)

I There are many kinds of entities, with distinguishingattributes

I An entity of a certain kind can be integrated withmixins that carry more attributes or bind existing ones

OCCI monitoringextension

Augusto Ciuffoletti

The OCCI core concepts

I Anything is an entity, and is identified with an URII A relationship between entities is an entity

I we distinguish resource entities and link entities(relationship)

I There are many kinds of entities, with distinguishingattributes

I An entity of a certain kind can be integrated withmixins that carry more attributes or bind existing ones

OCCI monitoringextension

Augusto Ciuffoletti

The OCCI core concepts

I Anything is an entity, and is identified with an URII A relationship between entities is an entity

I we distinguish resource entities and link entities(relationship)

I There are many kinds of entities, with distinguishingattributes

I An entity of a certain kind can be integrated withmixins that carry more attributes or bind existing ones

OCCI monitoringextension

Augusto Ciuffoletti

The OCCI core concepts

I Anything is an entity, and is identified with an URII A relationship between entities is an entity

I we distinguish resource entities and link entities(relationship)

I There are many kinds of entities, with distinguishingattributes

I An entity of a certain kind can be integrated withmixins that carry more attributes or bind existing ones

OCCI monitoringextension

Augusto Ciuffoletti

OCCI IaaS interface

I The first use case for OCCI, adopted as an openstandard

I Resources are processors, storage, networks.I Links are network interfaces, and processor/storage

associationsI Mixins add OpSys attributes to a processor, a

filesystem to a storage, etc.

I However OCCI is designed to smoothly adapt to diverseuse cases

I Here we want to propose its application to monitoringthe performance of cloud resources

OCCI monitoringextension

Augusto Ciuffoletti

OCCI IaaS interface

I The first use case for OCCI, adopted as an openstandard

I Resources are processors, storage, networks.I Links are network interfaces, and processor/storage

associationsI Mixins add OpSys attributes to a processor, a

filesystem to a storage, etc.

I However OCCI is designed to smoothly adapt to diverseuse cases

I Here we want to propose its application to monitoringthe performance of cloud resources

OCCI monitoringextension

Augusto Ciuffoletti

OCCI IaaS interface

I The first use case for OCCI, adopted as an openstandard

I Resources are processors, storage, networks.I Links are network interfaces, and processor/storage

associationsI Mixins add OpSys attributes to a processor, a

filesystem to a storage, etc.

I However OCCI is designed to smoothly adapt to diverseuse cases

I Here we want to propose its application to monitoringthe performance of cloud resources

OCCI monitoringextension

Augusto Ciuffoletti

OCCI IaaS interface

I The first use case for OCCI, adopted as an openstandard

I Resources are processors, storage, networks.I Links are network interfaces, and processor/storage

associationsI Mixins add OpSys attributes to a processor, a

filesystem to a storage, etc.

I However OCCI is designed to smoothly adapt to diverseuse cases

I Here we want to propose its application to monitoringthe performance of cloud resources

OCCI monitoringextension

Augusto Ciuffoletti

OCCI IaaS interface

I The first use case for OCCI, adopted as an openstandard

I Resources are processors, storage, networks.I Links are network interfaces, and processor/storage

associationsI Mixins add OpSys attributes to a processor, a

filesystem to a storage, etc.

I However OCCI is designed to smoothly adapt to diverseuse cases

I Here we want to propose its application to monitoringthe performance of cloud resources

OCCI monitoringextension

Augusto Ciuffoletti

OCCI IaaS interface

I The first use case for OCCI, adopted as an openstandard

I Resources are processors, storage, networks.I Links are network interfaces, and processor/storage

associationsI Mixins add OpSys attributes to a processor, a

filesystem to a storage, etc.

I However OCCI is designed to smoothly adapt to diverseuse cases

I Here we want to propose its application to monitoringthe performance of cloud resources

OCCI monitoringextension

Augusto Ciuffoletti

Motivation

I The monitoring of resource performance is a key issueto implement:

I Service Level Agreement, a defined target to obtain userconfidence

I fault-tolerance targets defined by the user

I The user wants to customize resource monitoringI the user may be in his turn a service providerI the user may simply want to verify the quality of the

serviceI major cloud providers providers offer resource

monitoring as a part of the service

I Standardization matters!I Consider the case of a composite service (many

providers)

I We propose a simple ontology for resource monitoringthat is aligned with OCCI

OCCI monitoringextension

Augusto Ciuffoletti

Motivation

I The monitoring of resource performance is a key issueto implement:

I Service Level Agreement, a defined target to obtain userconfidence

I fault-tolerance targets defined by the user

I The user wants to customize resource monitoringI the user may be in his turn a service providerI the user may simply want to verify the quality of the

serviceI major cloud providers providers offer resource

monitoring as a part of the service

I Standardization matters!I Consider the case of a composite service (many

providers)

I We propose a simple ontology for resource monitoringthat is aligned with OCCI

OCCI monitoringextension

Augusto Ciuffoletti

Motivation

I The monitoring of resource performance is a key issueto implement:

I Service Level Agreement, a defined target to obtain userconfidence

I fault-tolerance targets defined by the user

I The user wants to customize resource monitoringI the user may be in his turn a service providerI the user may simply want to verify the quality of the

serviceI major cloud providers providers offer resource

monitoring as a part of the service

I Standardization matters!I Consider the case of a composite service (many

providers)

I We propose a simple ontology for resource monitoringthat is aligned with OCCI

OCCI monitoringextension

Augusto Ciuffoletti

Motivation

I The monitoring of resource performance is a key issueto implement:

I Service Level Agreement, a defined target to obtain userconfidence

I fault-tolerance targets defined by the user

I The user wants to customize resource monitoringI the user may be in his turn a service providerI the user may simply want to verify the quality of the

serviceI major cloud providers providers offer resource

monitoring as a part of the service

I Standardization matters!I Consider the case of a composite service (many

providers)

I We propose a simple ontology for resource monitoringthat is aligned with OCCI

OCCI monitoringextension

Augusto Ciuffoletti

Motivation

I The monitoring of resource performance is a key issueto implement:

I Service Level Agreement, a defined target to obtain userconfidence

I fault-tolerance targets defined by the user

I The user wants to customize resource monitoringI the user may be in his turn a service providerI the user may simply want to verify the quality of the

serviceI major cloud providers providers offer resource

monitoring as a part of the service

I Standardization matters!I Consider the case of a composite service (many

providers)

I We propose a simple ontology for resource monitoringthat is aligned with OCCI

OCCI monitoringextension

Augusto Ciuffoletti

Motivation

I The monitoring of resource performance is a key issueto implement:

I Service Level Agreement, a defined target to obtain userconfidence

I fault-tolerance targets defined by the user

I The user wants to customize resource monitoringI the user may be in his turn a service providerI the user may simply want to verify the quality of the

serviceI major cloud providers providers offer resource

monitoring as a part of the service

I Standardization matters!I Consider the case of a composite service (many

providers)

I We propose a simple ontology for resource monitoringthat is aligned with OCCI

OCCI monitoringextension

Augusto Ciuffoletti

Motivation

I The monitoring of resource performance is a key issueto implement:

I Service Level Agreement, a defined target to obtain userconfidence

I fault-tolerance targets defined by the user

I The user wants to customize resource monitoringI the user may be in his turn a service providerI the user may simply want to verify the quality of the

serviceI major cloud providers providers offer resource

monitoring as a part of the service

I Standardization matters!I Consider the case of a composite service (many

providers)

I We propose a simple ontology for resource monitoringthat is aligned with OCCI

OCCI monitoringextension

Augusto Ciuffoletti

Motivation

I The monitoring of resource performance is a key issueto implement:

I Service Level Agreement, a defined target to obtain userconfidence

I fault-tolerance targets defined by the user

I The user wants to customize resource monitoringI the user may be in his turn a service providerI the user may simply want to verify the quality of the

serviceI major cloud providers providers offer resource

monitoring as a part of the service

I Standardization matters!I Consider the case of a composite service (many

providers)

I We propose a simple ontology for resource monitoringthat is aligned with OCCI

OCCI monitoringextension

Augusto Ciuffoletti

Motivation

I The monitoring of resource performance is a key issueto implement:

I Service Level Agreement, a defined target to obtain userconfidence

I fault-tolerance targets defined by the user

I The user wants to customize resource monitoringI the user may be in his turn a service providerI the user may simply want to verify the quality of the

serviceI major cloud providers providers offer resource

monitoring as a part of the service

I Standardization matters!I Consider the case of a composite service (many

providers)

I We propose a simple ontology for resource monitoringthat is aligned with OCCI

OCCI monitoringextension

Augusto Ciuffoletti

Motivation

I The monitoring of resource performance is a key issueto implement:

I Service Level Agreement, a defined target to obtain userconfidence

I fault-tolerance targets defined by the user

I The user wants to customize resource monitoringI the user may be in his turn a service providerI the user may simply want to verify the quality of the

serviceI major cloud providers providers offer resource

monitoring as a part of the service

I Standardization matters!I Consider the case of a composite service (many

providers)

I We propose a simple ontology for resource monitoringthat is aligned with OCCI

OCCI monitoringextension

Augusto Ciuffoletti

A monitoring framework

I Monitoring is made of three basic activities:I extract performance parameters from the target

ResourceI aggregate them and compute the metric of interestI deliver the measurement to the relevant party

I The last two steps consist of aggregation and renderingof data

I this makes a candidate for a new Resource kind

I The first step entails the collaboration among entitiesI this makes a candidate for a new Link kind

I The resource kind is named Sensor, and the link kindCollector

I and this is bare minimum for a stand-alone monitoringframework

I The OCCI monitoring framework complements anyOCCI framework

I it handles any type of Resource.

OCCI monitoringextension

Augusto Ciuffoletti

A monitoring framework

I Monitoring is made of three basic activities:I extract performance parameters from the target

ResourceI aggregate them and compute the metric of interestI deliver the measurement to the relevant party

I The last two steps consist of aggregation and renderingof data

I this makes a candidate for a new Resource kind

I The first step entails the collaboration among entitiesI this makes a candidate for a new Link kind

I The resource kind is named Sensor, and the link kindCollector

I and this is bare minimum for a stand-alone monitoringframework

I The OCCI monitoring framework complements anyOCCI framework

I it handles any type of Resource.

OCCI monitoringextension

Augusto Ciuffoletti

A monitoring framework

I Monitoring is made of three basic activities:I extract performance parameters from the target

ResourceI aggregate them and compute the metric of interestI deliver the measurement to the relevant party

I The last two steps consist of aggregation and renderingof data

I this makes a candidate for a new Resource kind

I The first step entails the collaboration among entitiesI this makes a candidate for a new Link kind

I The resource kind is named Sensor, and the link kindCollector

I and this is bare minimum for a stand-alone monitoringframework

I The OCCI monitoring framework complements anyOCCI framework

I it handles any type of Resource.

OCCI monitoringextension

Augusto Ciuffoletti

A monitoring framework

I Monitoring is made of three basic activities:I extract performance parameters from the target

ResourceI aggregate them and compute the metric of interestI deliver the measurement to the relevant party

I The last two steps consist of aggregation and renderingof data

I this makes a candidate for a new Resource kind

I The first step entails the collaboration among entitiesI this makes a candidate for a new Link kind

I The resource kind is named Sensor, and the link kindCollector

I and this is bare minimum for a stand-alone monitoringframework

I The OCCI monitoring framework complements anyOCCI framework

I it handles any type of Resource.

OCCI monitoringextension

Augusto Ciuffoletti

A monitoring framework

I Monitoring is made of three basic activities:I extract performance parameters from the target

ResourceI aggregate them and compute the metric of interestI deliver the measurement to the relevant party

I The last two steps consist of aggregation and renderingof data

I this makes a candidate for a new Resource kind

I The first step entails the collaboration among entitiesI this makes a candidate for a new Link kind

I The resource kind is named Sensor, and the link kindCollector

I and this is bare minimum for a stand-alone monitoringframework

I The OCCI monitoring framework complements anyOCCI framework

I it handles any type of Resource.

OCCI monitoringextension

Augusto Ciuffoletti

A monitoring framework

I Monitoring is made of three basic activities:I extract performance parameters from the target

ResourceI aggregate them and compute the metric of interestI deliver the measurement to the relevant party

I The last two steps consist of aggregation and renderingof data

I this makes a candidate for a new Resource kind

I The first step entails the collaboration among entitiesI this makes a candidate for a new Link kind

I The resource kind is named Sensor, and the link kindCollector

I and this is bare minimum for a stand-alone monitoringframework

I The OCCI monitoring framework complements anyOCCI framework

I it handles any type of Resource.

OCCI monitoringextension

Augusto Ciuffoletti

A monitoring framework

I Monitoring is made of three basic activities:I extract performance parameters from the target

ResourceI aggregate them and compute the metric of interestI deliver the measurement to the relevant party

I The last two steps consist of aggregation and renderingof data

I this makes a candidate for a new Resource kind

I The first step entails the collaboration among entitiesI this makes a candidate for a new Link kind

I The resource kind is named Sensor, and the link kindCollector

I and this is bare minimum for a stand-alone monitoringframework

I The OCCI monitoring framework complements anyOCCI framework

I it handles any type of Resource.

OCCI monitoringextension

Augusto Ciuffoletti

A monitoring framework

I Monitoring is made of three basic activities:I extract performance parameters from the target

ResourceI aggregate them and compute the metric of interestI deliver the measurement to the relevant party

I The last two steps consist of aggregation and renderingof data

I this makes a candidate for a new Resource kind

I The first step entails the collaboration among entitiesI this makes a candidate for a new Link kind

I The resource kind is named Sensor, and the link kindCollector

I and this is bare minimum for a stand-alone monitoringframework

I The OCCI monitoring framework complements anyOCCI framework

I it handles any type of Resource.

OCCI monitoringextension

Augusto Ciuffoletti

A monitoring framework

I Monitoring is made of three basic activities:I extract performance parameters from the target

ResourceI aggregate them and compute the metric of interestI deliver the measurement to the relevant party

I The last two steps consist of aggregation and renderingof data

I this makes a candidate for a new Resource kind

I The first step entails the collaboration among entitiesI this makes a candidate for a new Link kind

I The resource kind is named Sensor, and the link kindCollector

I and this is bare minimum for a stand-alone monitoringframework

I The OCCI monitoring framework complements anyOCCI framework

I it handles any type of Resource.

OCCI monitoringextension

Augusto Ciuffoletti

A monitoring framework

I Monitoring is made of three basic activities:I extract performance parameters from the target

ResourceI aggregate them and compute the metric of interestI deliver the measurement to the relevant party

I The last two steps consist of aggregation and renderingof data

I this makes a candidate for a new Resource kind

I The first step entails the collaboration among entitiesI this makes a candidate for a new Link kind

I The resource kind is named Sensor, and the link kindCollector

I and this is bare minimum for a stand-alone monitoringframework

I The OCCI monitoring framework complements anyOCCI framework

I it handles any type of Resource.

OCCI monitoringextension

Augusto Ciuffoletti

A monitoring framework

I Monitoring is made of three basic activities:I extract performance parameters from the target

ResourceI aggregate them and compute the metric of interestI deliver the measurement to the relevant party

I The last two steps consist of aggregation and renderingof data

I this makes a candidate for a new Resource kind

I The first step entails the collaboration among entitiesI this makes a candidate for a new Link kind

I The resource kind is named Sensor, and the link kindCollector

I and this is bare minimum for a stand-alone monitoringframework

I The OCCI monitoring framework complements anyOCCI framework

I it handles any type of Resource.

OCCI monitoringextension

Augusto Ciuffoletti

A monitoring framework

I Monitoring is made of three basic activities:I extract performance parameters from the target

ResourceI aggregate them and compute the metric of interestI deliver the measurement to the relevant party

I The last two steps consist of aggregation and renderingof data

I this makes a candidate for a new Resource kind

I The first step entails the collaboration among entitiesI this makes a candidate for a new Link kind

I The resource kind is named Sensor, and the link kindCollector

I and this is bare minimum for a stand-alone monitoringframework

I The OCCI monitoring framework complements anyOCCI framework

I it handles any type of Resource.

OCCI monitoringextension

Augusto Ciuffoletti

A Sensor

I It is a distiguished activity that needs the provision ofcloud resources

I Tightly integrated in cloud infrastructureI Under control of the providerI Tuned using user requests

I The provider defines the available aggregation andpublishing capabilities

I The user instantiates the Sensor as a composition ofsuch capabilities

OCCI monitoringextension

Augusto Ciuffoletti

A Sensor

I It is a distiguished activity that needs the provision ofcloud resources

I Tightly integrated in cloud infrastructureI Under control of the providerI Tuned using user requests

I The provider defines the available aggregation andpublishing capabilities

I The user instantiates the Sensor as a composition ofsuch capabilities

OCCI monitoringextension

Augusto Ciuffoletti

A Sensor

I It is a distiguished activity that needs the provision ofcloud resources

I Tightly integrated in cloud infrastructureI Under control of the providerI Tuned using user requests

I The provider defines the available aggregation andpublishing capabilities

I The user instantiates the Sensor as a composition ofsuch capabilities

OCCI monitoringextension

Augusto Ciuffoletti

A Sensor

I It is a distiguished activity that needs the provision ofcloud resources

I Tightly integrated in cloud infrastructureI Under control of the providerI Tuned using user requests

I The provider defines the available aggregation andpublishing capabilities

I The user instantiates the Sensor as a composition ofsuch capabilities

OCCI monitoringextension

Augusto Ciuffoletti

A Sensor

I It is a distiguished activity that needs the provision ofcloud resources

I Tightly integrated in cloud infrastructureI Under control of the providerI Tuned using user requests

I The provider defines the available aggregation andpublishing capabilities

I The user instantiates the Sensor as a composition ofsuch capabilities

OCCI monitoringextension

Augusto Ciuffoletti

A Sensor

I It is a distiguished activity that needs the provision ofcloud resources

I Tightly integrated in cloud infrastructureI Under control of the providerI Tuned using user requests

I The provider defines the available aggregation andpublishing capabilities

I The user instantiates the Sensor as a composition ofsuch capabilities

OCCI monitoringextension

Augusto Ciuffoletti

Describing a Sensor

I Any Sensor has a few generic featuresI ...they can be included in a standard definition of a

SensorI When the sensor operatesI How frequently the sensor produces a new measurementI They are timing attributes

I Other features are specific for the providerI ...they are defined as mixins for the sensorI How data are aggregated (low pass, patterns etc.)I How data are published (archive, email, streaming etc.)

I There is no limit to the semantic of the mixinsI however the hooks to connect a Sensor to a Collector

must be defined

OCCI monitoringextension

Augusto Ciuffoletti

Describing a Sensor

I Any Sensor has a few generic featuresI ...they can be included in a standard definition of a

SensorI When the sensor operatesI How frequently the sensor produces a new measurementI They are timing attributes

I Other features are specific for the providerI ...they are defined as mixins for the sensorI How data are aggregated (low pass, patterns etc.)I How data are published (archive, email, streaming etc.)

I There is no limit to the semantic of the mixinsI however the hooks to connect a Sensor to a Collector

must be defined

OCCI monitoringextension

Augusto Ciuffoletti

Describing a Sensor

I Any Sensor has a few generic featuresI ...they can be included in a standard definition of a

SensorI When the sensor operatesI How frequently the sensor produces a new measurementI They are timing attributes

I Other features are specific for the providerI ...they are defined as mixins for the sensorI How data are aggregated (low pass, patterns etc.)I How data are published (archive, email, streaming etc.)

I There is no limit to the semantic of the mixinsI however the hooks to connect a Sensor to a Collector

must be defined

OCCI monitoringextension

Augusto Ciuffoletti

Describing a Sensor

I Any Sensor has a few generic featuresI ...they can be included in a standard definition of a

SensorI When the sensor operatesI How frequently the sensor produces a new measurementI They are timing attributes

I Other features are specific for the providerI ...they are defined as mixins for the sensorI How data are aggregated (low pass, patterns etc.)I How data are published (archive, email, streaming etc.)

I There is no limit to the semantic of the mixinsI however the hooks to connect a Sensor to a Collector

must be defined

OCCI monitoringextension

Augusto Ciuffoletti

Describing a Sensor

I Any Sensor has a few generic featuresI ...they can be included in a standard definition of a

SensorI When the sensor operatesI How frequently the sensor produces a new measurementI They are timing attributes

I Other features are specific for the providerI ...they are defined as mixins for the sensorI How data are aggregated (low pass, patterns etc.)I How data are published (archive, email, streaming etc.)

I There is no limit to the semantic of the mixinsI however the hooks to connect a Sensor to a Collector

must be defined

OCCI monitoringextension

Augusto Ciuffoletti

Describing a Sensor

I Any Sensor has a few generic featuresI ...they can be included in a standard definition of a

SensorI When the sensor operatesI How frequently the sensor produces a new measurementI They are timing attributes

I Other features are specific for the providerI ...they are defined as mixins for the sensorI How data are aggregated (low pass, patterns etc.)I How data are published (archive, email, streaming etc.)

I There is no limit to the semantic of the mixinsI however the hooks to connect a Sensor to a Collector

must be defined

OCCI monitoringextension

Augusto Ciuffoletti

Describing a Sensor

I Any Sensor has a few generic featuresI ...they can be included in a standard definition of a

SensorI When the sensor operatesI How frequently the sensor produces a new measurementI They are timing attributes

I Other features are specific for the providerI ...they are defined as mixins for the sensorI How data are aggregated (low pass, patterns etc.)I How data are published (archive, email, streaming etc.)

I There is no limit to the semantic of the mixinsI however the hooks to connect a Sensor to a Collector

must be defined

OCCI monitoringextension

Augusto Ciuffoletti

Describing a Sensor

I Any Sensor has a few generic featuresI ...they can be included in a standard definition of a

SensorI When the sensor operatesI How frequently the sensor produces a new measurementI They are timing attributes

I Other features are specific for the providerI ...they are defined as mixins for the sensorI How data are aggregated (low pass, patterns etc.)I How data are published (archive, email, streaming etc.)

I There is no limit to the semantic of the mixinsI however the hooks to connect a Sensor to a Collector

must be defined

OCCI monitoringextension

Augusto Ciuffoletti

Describing a Sensor

I Any Sensor has a few generic featuresI ...they can be included in a standard definition of a

SensorI When the sensor operatesI How frequently the sensor produces a new measurementI They are timing attributes

I Other features are specific for the providerI ...they are defined as mixins for the sensorI How data are aggregated (low pass, patterns etc.)I How data are published (archive, email, streaming etc.)

I There is no limit to the semantic of the mixinsI however the hooks to connect a Sensor to a Collector

must be defined

OCCI monitoringextension

Augusto Ciuffoletti

Describing a Sensor

I Any Sensor has a few generic featuresI ...they can be included in a standard definition of a

SensorI When the sensor operatesI How frequently the sensor produces a new measurementI They are timing attributes

I Other features are specific for the providerI ...they are defined as mixins for the sensorI How data are aggregated (low pass, patterns etc.)I How data are published (archive, email, streaming etc.)

I There is no limit to the semantic of the mixinsI however the hooks to connect a Sensor to a Collector

must be defined

OCCI monitoringextension

Augusto Ciuffoletti

Describing a Sensor

I Any Sensor has a few generic featuresI ...they can be included in a standard definition of a

SensorI When the sensor operatesI How frequently the sensor produces a new measurementI They are timing attributes

I Other features are specific for the providerI ...they are defined as mixins for the sensorI How data are aggregated (low pass, patterns etc.)I How data are published (archive, email, streaming etc.)

I There is no limit to the semantic of the mixinsI however the hooks to connect a Sensor to a Collector

must be defined

OCCI monitoringextension

Augusto Ciuffoletti

A Collector

I Represents a flow of measurements between a OCCIResource and a Sensor

I ... yes, the source can be a Sensor in its turn

I The provider has control on the available measurements

I The user has control on the selection and theconfiguration of the Collectors

I Cross provider measurements can be implementedI ... to accomodate the utilization of several providers

with a unique dashboard Sensor

OCCI monitoringextension

Augusto Ciuffoletti

A Collector

I Represents a flow of measurements between a OCCIResource and a Sensor

I ... yes, the source can be a Sensor in its turn

I The provider has control on the available measurements

I The user has control on the selection and theconfiguration of the Collectors

I Cross provider measurements can be implementedI ... to accomodate the utilization of several providers

with a unique dashboard Sensor

OCCI monitoringextension

Augusto Ciuffoletti

A Collector

I Represents a flow of measurements between a OCCIResource and a Sensor

I ... yes, the source can be a Sensor in its turn

I The provider has control on the available measurements

I The user has control on the selection and theconfiguration of the Collectors

I Cross provider measurements can be implementedI ... to accomodate the utilization of several providers

with a unique dashboard Sensor

OCCI monitoringextension

Augusto Ciuffoletti

A Collector

I Represents a flow of measurements between a OCCIResource and a Sensor

I ... yes, the source can be a Sensor in its turn

I The provider has control on the available measurements

I The user has control on the selection and theconfiguration of the Collectors

I Cross provider measurements can be implementedI ... to accomodate the utilization of several providers

with a unique dashboard Sensor

OCCI monitoringextension

Augusto Ciuffoletti

A Collector

I Represents a flow of measurements between a OCCIResource and a Sensor

I ... yes, the source can be a Sensor in its turn

I The provider has control on the available measurements

I The user has control on the selection and theconfiguration of the Collectors

I Cross provider measurements can be implementedI ... to accomodate the utilization of several providers

with a unique dashboard Sensor

OCCI monitoringextension

Augusto Ciuffoletti

A Collector

I Represents a flow of measurements between a OCCIResource and a Sensor

I ... yes, the source can be a Sensor in its turn

I The provider has control on the available measurements

I The user has control on the selection and theconfiguration of the Collectors

I Cross provider measurements can be implementedI ... to accomodate the utilization of several providers

with a unique dashboard Sensor

OCCI monitoringextension

Augusto Ciuffoletti

Describing a Collector

I As in the case of the Sensor there are generic attributesof a collector:

I The sampling periodI The accuracy of the sampling periodI ... again, just timing

I Other attributes are defined by provider-specific mixinswith an arbitrary semantic

I ...the metric that is measured (throughput, free space,temperature etc.)

OCCI monitoringextension

Augusto Ciuffoletti

Describing a Collector

I As in the case of the Sensor there are generic attributesof a collector:

I The sampling periodI The accuracy of the sampling periodI ... again, just timing

I Other attributes are defined by provider-specific mixinswith an arbitrary semantic

I ...the metric that is measured (throughput, free space,temperature etc.)

OCCI monitoringextension

Augusto Ciuffoletti

Describing a Collector

I As in the case of the Sensor there are generic attributesof a collector:

I The sampling periodI The accuracy of the sampling periodI ... again, just timing

I Other attributes are defined by provider-specific mixinswith an arbitrary semantic

I ...the metric that is measured (throughput, free space,temperature etc.)

OCCI monitoringextension

Augusto Ciuffoletti

Describing a Collector

I As in the case of the Sensor there are generic attributesof a collector:

I The sampling periodI The accuracy of the sampling periodI ... again, just timing

I Other attributes are defined by provider-specific mixinswith an arbitrary semantic

I ...the metric that is measured (throughput, free space,temperature etc.)

OCCI monitoringextension

Augusto Ciuffoletti

Describing a Collector

I As in the case of the Sensor there are generic attributesof a collector:

I The sampling periodI The accuracy of the sampling periodI ... again, just timing

I Other attributes are defined by provider-specific mixinswith an arbitrary semantic

I ...the metric that is measured (throughput, free space,temperature etc.)

OCCI monitoringextension

Augusto Ciuffoletti

Describing a Collector

I As in the case of the Sensor there are generic attributesof a collector:

I The sampling periodI The accuracy of the sampling periodI ... again, just timing

I Other attributes are defined by provider-specific mixinswith an arbitrary semantic

I ...the metric that is measured (throughput, free space,temperature etc.)

OCCI monitoringextension

Augusto Ciuffoletti

A monitoring-aware Resource

I A Resource that is the target of a monitoring activitymay be explicitely characterized with a CollectorEnd-Point mixin

I Such a mixin contains the description of the monitoringmodality for that resource

I for instance, the location of a log file

I The presence of this mixin allows cross-providerinteroperability

I As an alternative, the modality can be left implicit(default)

OCCI monitoringextension

Augusto Ciuffoletti

A monitoring-aware Resource

I A Resource that is the target of a monitoring activitymay be explicitely characterized with a CollectorEnd-Point mixin

I Such a mixin contains the description of the monitoringmodality for that resource

I for instance, the location of a log file

I The presence of this mixin allows cross-providerinteroperability

I As an alternative, the modality can be left implicit(default)

OCCI monitoringextension

Augusto Ciuffoletti

A monitoring-aware Resource

I A Resource that is the target of a monitoring activitymay be explicitely characterized with a CollectorEnd-Point mixin

I Such a mixin contains the description of the monitoringmodality for that resource

I for instance, the location of a log file

I The presence of this mixin allows cross-providerinteroperability

I As an alternative, the modality can be left implicit(default)

OCCI monitoringextension

Augusto Ciuffoletti

A monitoring-aware Resource

I A Resource that is the target of a monitoring activitymay be explicitely characterized with a CollectorEnd-Point mixin

I Such a mixin contains the description of the monitoringmodality for that resource

I for instance, the location of a log file

I The presence of this mixin allows cross-providerinteroperability

I As an alternative, the modality can be left implicit(default)

OCCI monitoringextension

Augusto Ciuffoletti

A monitoring-aware Resource

I A Resource that is the target of a monitoring activitymay be explicitely characterized with a CollectorEnd-Point mixin

I Such a mixin contains the description of the monitoringmodality for that resource

I for instance, the location of a log file

I The presence of this mixin allows cross-providerinteroperability

I As an alternative, the modality can be left implicit(default)

OCCI monitoringextension

Augusto Ciuffoletti

A monitoring-aware Resource

I A Resource that is the target of a monitoring activitymay be explicitely characterized with a CollectorEnd-Point mixin

I Such a mixin contains the description of the monitoringmodality for that resource

I for instance, the location of a log file

I The presence of this mixin allows cross-providerinteroperability

I As an alternative, the modality can be left implicit(default)

New! This feature is not included in the available revision ofthe document

OCCI monitoringextension

Augusto Ciuffoletti

The overall picture

I Two entity kindsI Sensor aggregates and delivers measurementsI Collector acquires measurements

I Four mixin typesI Aggregator mixins describe the aggregation activity of

a SensorI Publisher mixins describe the rendering activity of a

SensorI Metric mixins describe the measurement activity of a

CollectorI Collector Endpoint mixins describe the monitoring

access point of a target resource

I The two Kinds have a OCCI schema associatedI ...they are defined in the standard

I The Mixins may be associated with a provider specificschema

I ...but we do not exclude that some of them may be partof another standard

OCCI monitoringextension

Augusto Ciuffoletti

The overall picture

I Two entity kindsI Sensor aggregates and delivers measurementsI Collector acquires measurements

I Four mixin typesI Aggregator mixins describe the aggregation activity of

a SensorI Publisher mixins describe the rendering activity of a

SensorI Metric mixins describe the measurement activity of a

CollectorI Collector Endpoint mixins describe the monitoring

access point of a target resource

I The two Kinds have a OCCI schema associatedI ...they are defined in the standard

I The Mixins may be associated with a provider specificschema

I ...but we do not exclude that some of them may be partof another standard

OCCI monitoringextension

Augusto Ciuffoletti

The overall picture

I Two entity kindsI Sensor aggregates and delivers measurementsI Collector acquires measurements

I Four mixin typesI Aggregator mixins describe the aggregation activity of

a SensorI Publisher mixins describe the rendering activity of a

SensorI Metric mixins describe the measurement activity of a

CollectorI Collector Endpoint mixins describe the monitoring

access point of a target resource

I The two Kinds have a OCCI schema associatedI ...they are defined in the standard

I The Mixins may be associated with a provider specificschema

I ...but we do not exclude that some of them may be partof another standard

OCCI monitoringextension

Augusto Ciuffoletti

The overall picture

I Two entity kindsI Sensor aggregates and delivers measurementsI Collector acquires measurements

I Four mixin typesI Aggregator mixins describe the aggregation activity of

a SensorI Publisher mixins describe the rendering activity of a

SensorI Metric mixins describe the measurement activity of a

CollectorI Collector Endpoint mixins describe the monitoring

access point of a target resource

I The two Kinds have a OCCI schema associatedI ...they are defined in the standard

I The Mixins may be associated with a provider specificschema

I ...but we do not exclude that some of them may be partof another standard

OCCI monitoringextension

Augusto Ciuffoletti

The overall picture

I Two entity kindsI Sensor aggregates and delivers measurementsI Collector acquires measurements

I Four mixin typesI Aggregator mixins describe the aggregation activity of

a SensorI Publisher mixins describe the rendering activity of a

SensorI Metric mixins describe the measurement activity of a

CollectorI Collector Endpoint mixins describe the monitoring

access point of a target resource

I The two Kinds have a OCCI schema associatedI ...they are defined in the standard

I The Mixins may be associated with a provider specificschema

I ...but we do not exclude that some of them may be partof another standard

OCCI monitoringextension

Augusto Ciuffoletti

The overall picture

I Two entity kindsI Sensor aggregates and delivers measurementsI Collector acquires measurements

I Four mixin typesI Aggregator mixins describe the aggregation activity of

a SensorI Publisher mixins describe the rendering activity of a

SensorI Metric mixins describe the measurement activity of a

CollectorI Collector Endpoint mixins describe the monitoring

access point of a target resource

I The two Kinds have a OCCI schema associatedI ...they are defined in the standard

I The Mixins may be associated with a provider specificschema

I ...but we do not exclude that some of them may be partof another standard

OCCI monitoringextension

Augusto Ciuffoletti

The overall picture

I Two entity kindsI Sensor aggregates and delivers measurementsI Collector acquires measurements

I Four mixin typesI Aggregator mixins describe the aggregation activity of

a SensorI Publisher mixins describe the rendering activity of a

SensorI Metric mixins describe the measurement activity of a

CollectorI Collector Endpoint mixins describe the monitoring

access point of a target resource

I The two Kinds have a OCCI schema associatedI ...they are defined in the standard

I The Mixins may be associated with a provider specificschema

I ...but we do not exclude that some of them may be partof another standard

OCCI monitoringextension

Augusto Ciuffoletti

The overall picture

I Two entity kindsI Sensor aggregates and delivers measurementsI Collector acquires measurements

I Four mixin typesI Aggregator mixins describe the aggregation activity of

a SensorI Publisher mixins describe the rendering activity of a

SensorI Metric mixins describe the measurement activity of a

CollectorI Collector Endpoint mixins describe the monitoring

access point of a target resource

I The two Kinds have a OCCI schema associatedI ...they are defined in the standard

I The Mixins may be associated with a provider specificschema

I ...but we do not exclude that some of them may be partof another standard

OCCI monitoringextension

Augusto Ciuffoletti

The overall picture

I Two entity kindsI Sensor aggregates and delivers measurementsI Collector acquires measurements

I Four mixin typesI Aggregator mixins describe the aggregation activity of

a SensorI Publisher mixins describe the rendering activity of a

SensorI Metric mixins describe the measurement activity of a

CollectorI Collector Endpoint mixins describe the monitoring

access point of a target resource

I The two Kinds have a OCCI schema associatedI ...they are defined in the standard

I The Mixins may be associated with a provider specificschema

I ...but we do not exclude that some of them may be partof another standard

OCCI monitoringextension

Augusto Ciuffoletti

The overall picture

I Two entity kindsI Sensor aggregates and delivers measurementsI Collector acquires measurements

I Four mixin typesI Aggregator mixins describe the aggregation activity of

a SensorI Publisher mixins describe the rendering activity of a

SensorI Metric mixins describe the measurement activity of a

CollectorI Collector Endpoint mixins describe the monitoring

access point of a target resource

I The two Kinds have a OCCI schema associatedI ...they are defined in the standard

I The Mixins may be associated with a provider specificschema

I ...but we do not exclude that some of them may be partof another standard

OCCI monitoringextension

Augusto Ciuffoletti

The overall picture

I Two entity kindsI Sensor aggregates and delivers measurementsI Collector acquires measurements

I Four mixin typesI Aggregator mixins describe the aggregation activity of

a SensorI Publisher mixins describe the rendering activity of a

SensorI Metric mixins describe the measurement activity of a

CollectorI Collector Endpoint mixins describe the monitoring

access point of a target resource

I The two Kinds have a OCCI schema associatedI ...they are defined in the standard

I The Mixins may be associated with a provider specificschema

I ...but we do not exclude that some of them may be partof another standard

OCCI monitoringextension

Augusto Ciuffoletti

The overall picture

I Two entity kindsI Sensor aggregates and delivers measurementsI Collector acquires measurements

I Four mixin typesI Aggregator mixins describe the aggregation activity of

a SensorI Publisher mixins describe the rendering activity of a

SensorI Metric mixins describe the measurement activity of a

CollectorI Collector Endpoint mixins describe the monitoring

access point of a target resource

I The two Kinds have a OCCI schema associatedI ...they are defined in the standard

I The Mixins may be associated with a provider specificschema

I ...but we do not exclude that some of them may be partof another standard

OCCI monitoringextension

Augusto Ciuffoletti

Hold them together: input and output hooks

I The designer needs a tool to assemble a monitoringinfrastructure

I we introduce input and output attributes for the Mixins

I We introduce hook attributes (named attributes in thelast revision) for a mixin:

I their value corresponds to a labelI Input attributesI Output attributes

I Input and Output hooks with matching labels areconnected

I this may mean a data flow among them

I The scope of hook labels is limited to a sensor and itsadjacent collectors

I The provider indicates hook semantics in thespecifications of the mixin

OCCI monitoringextension

Augusto Ciuffoletti

Hold them together: input and output hooks

I The designer needs a tool to assemble a monitoringinfrastructure

I we introduce input and output attributes for the Mixins

I We introduce hook attributes (named attributes in thelast revision) for a mixin:

I their value corresponds to a labelI Input attributesI Output attributes

I Input and Output hooks with matching labels areconnected

I this may mean a data flow among them

I The scope of hook labels is limited to a sensor and itsadjacent collectors

I The provider indicates hook semantics in thespecifications of the mixin

OCCI monitoringextension

Augusto Ciuffoletti

Hold them together: input and output hooks

I The designer needs a tool to assemble a monitoringinfrastructure

I we introduce input and output attributes for the Mixins

I We introduce hook attributes (named attributes in thelast revision) for a mixin:

I their value corresponds to a labelI Input attributesI Output attributes

I Input and Output hooks with matching labels areconnected

I this may mean a data flow among them

I The scope of hook labels is limited to a sensor and itsadjacent collectors

I The provider indicates hook semantics in thespecifications of the mixin

OCCI monitoringextension

Augusto Ciuffoletti

Hold them together: input and output hooks

I The designer needs a tool to assemble a monitoringinfrastructure

I we introduce input and output attributes for the Mixins

I We introduce hook attributes (named attributes in thelast revision) for a mixin:

I their value corresponds to a labelI Input attributesI Output attributes

I Input and Output hooks with matching labels areconnected

I this may mean a data flow among them

I The scope of hook labels is limited to a sensor and itsadjacent collectors

I The provider indicates hook semantics in thespecifications of the mixin

OCCI monitoringextension

Augusto Ciuffoletti

Hold them together: input and output hooks

I The designer needs a tool to assemble a monitoringinfrastructure

I we introduce input and output attributes for the Mixins

I We introduce hook attributes (named attributes in thelast revision) for a mixin:

I their value corresponds to a labelI Input attributesI Output attributes

I Input and Output hooks with matching labels areconnected

I this may mean a data flow among them

I The scope of hook labels is limited to a sensor and itsadjacent collectors

I The provider indicates hook semantics in thespecifications of the mixin

OCCI monitoringextension

Augusto Ciuffoletti

Hold them together: input and output hooks

I The designer needs a tool to assemble a monitoringinfrastructure

I we introduce input and output attributes for the Mixins

I We introduce hook attributes (named attributes in thelast revision) for a mixin:

I their value corresponds to a labelI Input attributesI Output attributes

I Input and Output hooks with matching labels areconnected

I this may mean a data flow among them

I The scope of hook labels is limited to a sensor and itsadjacent collectors

I The provider indicates hook semantics in thespecifications of the mixin

OCCI monitoringextension

Augusto Ciuffoletti

Hold them together: input and output hooks

I The designer needs a tool to assemble a monitoringinfrastructure

I we introduce input and output attributes for the Mixins

I We introduce hook attributes (named attributes in thelast revision) for a mixin:

I their value corresponds to a labelI Input attributesI Output attributes

I Input and Output hooks with matching labels areconnected

I this may mean a data flow among them

I The scope of hook labels is limited to a sensor and itsadjacent collectors

I The provider indicates hook semantics in thespecifications of the mixin

OCCI monitoringextension

Augusto Ciuffoletti

Hold them together: input and output hooks

I The designer needs a tool to assemble a monitoringinfrastructure

I we introduce input and output attributes for the Mixins

I We introduce hook attributes (named attributes in thelast revision) for a mixin:

I their value corresponds to a labelI Input attributesI Output attributes

I Input and Output hooks with matching labels areconnected

I this may mean a data flow among them

I The scope of hook labels is limited to a sensor and itsadjacent collectors

I The provider indicates hook semantics in thespecifications of the mixin

OCCI monitoringextension

Augusto Ciuffoletti

Hold them together: input and output hooks

I The designer needs a tool to assemble a monitoringinfrastructure

I we introduce input and output attributes for the Mixins

I We introduce hook attributes (named attributes in thelast revision) for a mixin:

I their value corresponds to a labelI Input attributesI Output attributes

I Input and Output hooks with matching labels areconnected

I this may mean a data flow among them

I The scope of hook labels is limited to a sensor and itsadjacent collectors

I The provider indicates hook semantics in thespecifications of the mixin

OCCI monitoringextension

Augusto Ciuffoletti

Hold them together: input and output hooks

I The designer needs a tool to assemble a monitoringinfrastructure

I we introduce input and output attributes for the Mixins

I We introduce hook attributes (named attributes in thelast revision) for a mixin:

I their value corresponds to a labelI Input attributesI Output attributes

I Input and Output hooks with matching labels areconnected

I this may mean a data flow among them

I The scope of hook labels is limited to a sensor and itsadjacent collectors

I The provider indicates hook semantics in thespecifications of the mixin

OCCI monitoringextension

Augusto Ciuffoletti

Step by step design of a monitoring infrastructure

An example:

I One sensor collects measurementes from two resources

I Results are published through two different channels(e.g., streaming and database)

I Two distinct measurement tools are applied to each ofthe two resources (total four tools)

I We combine a metric from both resources (e.g., averageload)

OCCI monitoringextension

Augusto Ciuffoletti

Step by step design of a monitoring infrastructure

An example:

I One sensor collects measurementes from two resources

I Results are published through two different channels(e.g., streaming and database)

I Two distinct measurement tools are applied to each ofthe two resources (total four tools)

I We combine a metric from both resources (e.g., averageload)

OCCI monitoringextension

Augusto Ciuffoletti

Step by step design of a monitoring infrastructure

An example:

I One sensor collects measurementes from two resources

I Results are published through two different channels(e.g., streaming and database)

I Two distinct measurement tools are applied to each ofthe two resources (total four tools)

I We combine a metric from both resources (e.g., averageload)

OCCI monitoringextension

Augusto Ciuffoletti

Step by step design of a monitoring infrastructure

An example:

I One sensor collects measurementes from two resources

I Results are published through two different channels(e.g., streaming and database)

I Two distinct measurement tools are applied to each ofthe two resources (total four tools)

I We combine a metric from both resources (e.g., averageload)

OCCI monitoringextension

Augusto Ciuffoletti

Step by step design of a monitoring infrastructure

An example:

I One sensor collects measurementes from two resources

I Results are published through two different channels(e.g., streaming and database)

I Two distinct measurement tools are applied to each ofthe two resources (total four tools)

I We combine a metric from both resources (e.g., averageload)

OCCI monitoringextension

Augusto Ciuffoletti

Step by step design of a monitoring infrastructure

The resources we want to monitor: they have a CollectorEndpoint mixin associated

OCCI monitoringextension

Augusto Ciuffoletti

Step by step design of a monitoring infrastructure

Create one Sensor resource

OCCI monitoringextension

Augusto Ciuffoletti

Step by step design of a monitoring infrastructure

Use two collectors to define the measurement activiy

OCCI monitoringextension

Augusto Ciuffoletti

Step by step design of a monitoring infrastructure

Associate two metric mixins to the Collector X

OCCI monitoringextension

Augusto Ciuffoletti

Step by step design of a monitoring infrastructure

And another two metric mixins to the Collector Y

OCCI monitoringextension

Augusto Ciuffoletti

Step by step design of a monitoring infrastructure

Associate two aggregator mixins to the Sensor

OCCI monitoringextension

Augusto Ciuffoletti

Step by step design of a monitoring infrastructure

One publisher is going to use raw data from the collector

OCCI monitoringextension

Augusto Ciuffoletti

Step by step design of a monitoring infrastructure

Another is going to receive measurements from theaggregators

OCCI monitoringextension

Augusto Ciuffoletti

Step by step design of a monitoring infrastructure

A frame for Collector X and its mixins

OCCI monitoringextension

Augusto Ciuffoletti

Step by step design of a monitoring infrastructure

... one for Collector Y...

OCCI monitoringextension

Augusto Ciuffoletti

Step by step design of a monitoring infrastructure

... one for the sensor

OCCI monitoringextension

Augusto Ciuffoletti

Step by step design of a monitoring infrastructure

The scope of the Sensor (for hook labels)

OCCI monitoringextension

Augusto Ciuffoletti

Step by step design of a monitoring infrastructure

Feeding the aggregators: a,b,d are hook labels

OCCI monitoringextension

Augusto Ciuffoletti

Step by step design of a monitoring infrastructure

Feeding publisher 2: aggregated (f,g) and raw data (e)

OCCI monitoringextension

Augusto Ciuffoletti

Step by step design of a monitoring infrastructure

Feeding publisher 1: measurement stream b is multicast

OCCI monitoringextension

Augusto Ciuffoletti

ConclusionsI To manage cloud resource, we need to monitor them

I indeed many providers offer monitoring as a serviceI We establish a minimum common ground for

interoperabilityI a standard, aligned with the Open Cloud Computing

InterfaceI Two entities:

I Collector link to produce monitoring dataI Sensor resource to aggregate and deliver monitoring

dataI Finalized using mixins defined by the providerI Can be combined to form complex monitoring

infrastructuresI More... may be extended to any computational

infrastructure

OCCI monitoringextension

Augusto Ciuffoletti

ConclusionsI To manage cloud resource, we need to monitor them

I indeed many providers offer monitoring as a serviceI We establish a minimum common ground for

interoperabilityI a standard, aligned with the Open Cloud Computing

InterfaceI Two entities:

I Collector link to produce monitoring dataI Sensor resource to aggregate and deliver monitoring

dataI Finalized using mixins defined by the providerI Can be combined to form complex monitoring

infrastructuresI More... may be extended to any computational

infrastructure

OCCI monitoringextension

Augusto Ciuffoletti

ConclusionsI To manage cloud resource, we need to monitor them

I indeed many providers offer monitoring as a serviceI We establish a minimum common ground for

interoperabilityI a standard, aligned with the Open Cloud Computing

InterfaceI Two entities:

I Collector link to produce monitoring dataI Sensor resource to aggregate and deliver monitoring

dataI Finalized using mixins defined by the providerI Can be combined to form complex monitoring

infrastructuresI More... may be extended to any computational

infrastructure

OCCI monitoringextension

Augusto Ciuffoletti

ConclusionsI To manage cloud resource, we need to monitor them

I indeed many providers offer monitoring as a serviceI We establish a minimum common ground for

interoperabilityI a standard, aligned with the Open Cloud Computing

InterfaceI Two entities:

I Collector link to produce monitoring dataI Sensor resource to aggregate and deliver monitoring

dataI Finalized using mixins defined by the providerI Can be combined to form complex monitoring

infrastructuresI More... may be extended to any computational

infrastructure

OCCI monitoringextension

Augusto Ciuffoletti

ConclusionsI To manage cloud resource, we need to monitor them

I indeed many providers offer monitoring as a serviceI We establish a minimum common ground for

interoperabilityI a standard, aligned with the Open Cloud Computing

InterfaceI Two entities:

I Collector link to produce monitoring dataI Sensor resource to aggregate and deliver monitoring

dataI Finalized using mixins defined by the providerI Can be combined to form complex monitoring

infrastructuresI More... may be extended to any computational

infrastructure

OCCI monitoringextension

Augusto Ciuffoletti

ConclusionsI To manage cloud resource, we need to monitor them

I indeed many providers offer monitoring as a serviceI We establish a minimum common ground for

interoperabilityI a standard, aligned with the Open Cloud Computing

InterfaceI Two entities:

I Collector link to produce monitoring dataI Sensor resource to aggregate and deliver monitoring

dataI Finalized using mixins defined by the providerI Can be combined to form complex monitoring

infrastructuresI More... may be extended to any computational

infrastructure

OCCI monitoringextension

Augusto Ciuffoletti

ConclusionsI To manage cloud resource, we need to monitor them

I indeed many providers offer monitoring as a serviceI We establish a minimum common ground for

interoperabilityI a standard, aligned with the Open Cloud Computing

InterfaceI Two entities:

I Collector link to produce monitoring dataI Sensor resource to aggregate and deliver monitoring

dataI Finalized using mixins defined by the providerI Can be combined to form complex monitoring

infrastructuresI More... may be extended to any computational

infrastructure

OCCI monitoringextension

Augusto Ciuffoletti

ConclusionsI To manage cloud resource, we need to monitor them

I indeed many providers offer monitoring as a serviceI We establish a minimum common ground for

interoperabilityI a standard, aligned with the Open Cloud Computing

InterfaceI Two entities:

I Collector link to produce monitoring dataI Sensor resource to aggregate and deliver monitoring

dataI Finalized using mixins defined by the providerI Can be combined to form complex monitoring

infrastructuresI More... may be extended to any computational

infrastructure

OCCI monitoringextension

Augusto Ciuffoletti

ConclusionsI To manage cloud resource, we need to monitor them

I indeed many providers offer monitoring as a serviceI We establish a minimum common ground for

interoperabilityI a standard, aligned with the Open Cloud Computing

InterfaceI Two entities:

I Collector link to produce monitoring dataI Sensor resource to aggregate and deliver monitoring

dataI Finalized using mixins defined by the providerI Can be combined to form complex monitoring

infrastructuresI More... may be extended to any computational

infrastructure

OCCI monitoringextension

Augusto Ciuffoletti

ConclusionsI To manage cloud resource, we need to monitor them

I indeed many providers offer monitoring as a serviceI We establish a minimum common ground for

interoperabilityI a standard, aligned with the Open Cloud Computing

InterfaceI Two entities:

I Collector link to produce monitoring dataI Sensor resource to aggregate and deliver monitoring

dataI Finalized using mixins defined by the providerI Can be combined to form complex monitoring

infrastructuresI More... may be extended to any computational

infrastructure

OCCI monitoringextension

Augusto Ciuffoletti

ConclusionsI To manage cloud resource, we need to monitor them

I indeed many providers offer monitoring as a serviceI We establish a minimum common ground for

interoperabilityI a standard, aligned with the Open Cloud Computing

InterfaceI Two entities:

I Collector link to produce monitoring dataI Sensor resource to aggregate and deliver monitoring

dataI Finalized using mixins defined by the providerI Can be combined to form complex monitoring

infrastructuresI More... may be extended to any computational

infrastructure

End of part 1

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

From the OCCI to Java: unfolding theinfrastructure

A Java backend for OCCI monitoring

Augusto Ciuffoletti

Dept. of Computer Science - Univ. of Pisa

September 5, 2014

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

An experiment to verify an abstract specification

The framework

I Limited to the backend, in the perspective of theprovider that implements the monitoring service

I No user interface: OCCI-JSON documents are alreadyon the web server

I Written in Java, because it is widely understood

The question - Is the specification realistic?

I is the sensor+collector model sufficiently descriptive?

I are the attributes enough to describe a monitoringframework?

I are mixins modular with respect to the framework?

I is there a simple way to implement it efficiently?

The answers are basically positive, but something interestinghas been discovered...

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

An experiment to verify an abstract specification

The framework

I Limited to the backend, in the perspective of theprovider that implements the monitoring service

I No user interface: OCCI-JSON documents are alreadyon the web server

I Written in Java, because it is widely understood

The question - Is the specification realistic?

I is the sensor+collector model sufficiently descriptive?

I are the attributes enough to describe a monitoringframework?

I are mixins modular with respect to the framework?

I is there a simple way to implement it efficiently?

The answers are basically positive, but something interestinghas been discovered...

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

An experiment to verify an abstract specification

The framework

I Limited to the backend, in the perspective of theprovider that implements the monitoring service

I No user interface: OCCI-JSON documents are alreadyon the web server

I Written in Java, because it is widely understood

The question - Is the specification realistic?

I is the sensor+collector model sufficiently descriptive?

I are the attributes enough to describe a monitoringframework?

I are mixins modular with respect to the framework?

I is there a simple way to implement it efficiently?

The answers are basically positive, but something interestinghas been discovered...

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

An experiment to verify an abstract specification

The framework

I Limited to the backend, in the perspective of theprovider that implements the monitoring service

I No user interface: OCCI-JSON documents are alreadyon the web server

I Written in Java, because it is widely understood

The question - Is the specification realistic?

I is the sensor+collector model sufficiently descriptive?

I are the attributes enough to describe a monitoringframework?

I are mixins modular with respect to the framework?

I is there a simple way to implement it efficiently?

The answers are basically positive, but something interestinghas been discovered...

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

An experiment to verify an abstract specification

The framework

I Limited to the backend, in the perspective of theprovider that implements the monitoring service

I No user interface: OCCI-JSON documents are alreadyon the web server

I Written in Java, because it is widely understood

The question - Is the specification realistic?

I is the sensor+collector model sufficiently descriptive?

I are the attributes enough to describe a monitoringframework?

I are mixins modular with respect to the framework?

I is there a simple way to implement it efficiently?

The answers are basically positive, but something interestinghas been discovered...

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

An experiment to verify an abstract specification

The framework

I Limited to the backend, in the perspective of theprovider that implements the monitoring service

I No user interface: OCCI-JSON documents are alreadyon the web server

I Written in Java, because it is widely understood

The question - Is the specification realistic?

I is the sensor+collector model sufficiently descriptive?

I are the attributes enough to describe a monitoringframework?

I are mixins modular with respect to the framework?

I is there a simple way to implement it efficiently?

The answers are basically positive, but something interestinghas been discovered...

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

An experiment to verify an abstract specification

The framework

I Limited to the backend, in the perspective of theprovider that implements the monitoring service

I No user interface: OCCI-JSON documents are alreadyon the web server

I Written in Java, because it is widely understood

The question - Is the specification realistic?

I is the sensor+collector model sufficiently descriptive?

I are the attributes enough to describe a monitoringframework?

I are mixins modular with respect to the framework?

I is there a simple way to implement it efficiently?

The answers are basically positive, but something interestinghas been discovered...

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

An experiment to verify an abstract specification

The framework

I Limited to the backend, in the perspective of theprovider that implements the monitoring service

I No user interface: OCCI-JSON documents are alreadyon the web server

I Written in Java, because it is widely understood

The question - Is the specification realistic?

I is the sensor+collector model sufficiently descriptive?

I are the attributes enough to describe a monitoringframework?

I are mixins modular with respect to the framework?

I is there a simple way to implement it efficiently?

The answers are basically positive, but something interestinghas been discovered...

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

An experiment to verify an abstract specification

The framework

I Limited to the backend, in the perspective of theprovider that implements the monitoring service

I No user interface: OCCI-JSON documents are alreadyon the web server

I Written in Java, because it is widely understood

The question - Is the specification realistic?

I is the sensor+collector model sufficiently descriptive?

I are the attributes enough to describe a monitoringframework?

I are mixins modular with respect to the framework?

I is there a simple way to implement it efficiently?

The answers are basically positive, but something interestinghas been discovered...

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

An experiment to verify an abstract specification

The framework

I Limited to the backend, in the perspective of theprovider that implements the monitoring service

I No user interface: OCCI-JSON documents are alreadyon the web server

I Written in Java, because it is widely understood

The question - Is the specification realistic?

I is the sensor+collector model sufficiently descriptive?

I are the attributes enough to describe a monitoringframework?

I are mixins modular with respect to the framework?

I is there a simple way to implement it efficiently?

The answers are basically positive, but something interestinghas been discovered...

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

Basic design options

I The Collector Endpoint mixin is implemented on acompute resource as a daemon with an RMI interface

I Metric mixins are dynamically created threads (Javareflection)

I Metric classes are not dynamically loaded (todo)

I The Sensor runs on a distinct host, possibly sharedwith other Sensors

I Data flow from the Collector Endpoint to the Sensoruses a TCP channel with JSON encoding

I Aggregator and Publisher mixins are dynamicallycreated threads (as for Metrics)

I communication between Aggregators and Publishersuses internal pipes and JSON

I input and output hook attributes are respectivelyassociated with PipedInputStreams and PrintWriters

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

Basic design options

I The Collector Endpoint mixin is implemented on acompute resource as a daemon with an RMI interface

I Metric mixins are dynamically created threads (Javareflection)

I Metric classes are not dynamically loaded (todo)

I The Sensor runs on a distinct host, possibly sharedwith other Sensors

I Data flow from the Collector Endpoint to the Sensoruses a TCP channel with JSON encoding

I Aggregator and Publisher mixins are dynamicallycreated threads (as for Metrics)

I communication between Aggregators and Publishersuses internal pipes and JSON

I input and output hook attributes are respectivelyassociated with PipedInputStreams and PrintWriters

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

Basic design options

I The Collector Endpoint mixin is implemented on acompute resource as a daemon with an RMI interface

I Metric mixins are dynamically created threads (Javareflection)

I Metric classes are not dynamically loaded (todo)

I The Sensor runs on a distinct host, possibly sharedwith other Sensors

I Data flow from the Collector Endpoint to the Sensoruses a TCP channel with JSON encoding

I Aggregator and Publisher mixins are dynamicallycreated threads (as for Metrics)

I communication between Aggregators and Publishersuses internal pipes and JSON

I input and output hook attributes are respectivelyassociated with PipedInputStreams and PrintWriters

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

Basic design options

I The Collector Endpoint mixin is implemented on acompute resource as a daemon with an RMI interface

I Metric mixins are dynamically created threads (Javareflection)

I Metric classes are not dynamically loaded (todo)

I The Sensor runs on a distinct host, possibly sharedwith other Sensors

I Data flow from the Collector Endpoint to the Sensoruses a TCP channel with JSON encoding

I Aggregator and Publisher mixins are dynamicallycreated threads (as for Metrics)

I communication between Aggregators and Publishersuses internal pipes and JSON

I input and output hook attributes are respectivelyassociated with PipedInputStreams and PrintWriters

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

Basic design options

I The Collector Endpoint mixin is implemented on acompute resource as a daemon with an RMI interface

I Metric mixins are dynamically created threads (Javareflection)

I Metric classes are not dynamically loaded (todo)

I The Sensor runs on a distinct host, possibly sharedwith other Sensors

I Data flow from the Collector Endpoint to the Sensoruses a TCP channel with JSON encoding

I Aggregator and Publisher mixins are dynamicallycreated threads (as for Metrics)

I communication between Aggregators and Publishersuses internal pipes and JSON

I input and output hook attributes are respectivelyassociated with PipedInputStreams and PrintWriters

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

Basic design options

I The Collector Endpoint mixin is implemented on acompute resource as a daemon with an RMI interface

I Metric mixins are dynamically created threads (Javareflection)

I Metric classes are not dynamically loaded (todo)

I The Sensor runs on a distinct host, possibly sharedwith other Sensors

I Data flow from the Collector Endpoint to the Sensoruses a TCP channel with JSON encoding

I Aggregator and Publisher mixins are dynamicallycreated threads (as for Metrics)

I communication between Aggregators and Publishersuses internal pipes and JSON

I input and output hook attributes are respectivelyassociated with PipedInputStreams and PrintWriters

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

Basic design options

I The Collector Endpoint mixin is implemented on acompute resource as a daemon with an RMI interface

I Metric mixins are dynamically created threads (Javareflection)

I Metric classes are not dynamically loaded (todo)

I The Sensor runs on a distinct host, possibly sharedwith other Sensors

I Data flow from the Collector Endpoint to the Sensoruses a TCP channel with JSON encoding

I Aggregator and Publisher mixins are dynamicallycreated threads (as for Metrics)

I communication between Aggregators and Publishersuses internal pipes and JSON

I input and output hook attributes are respectivelyassociated with PipedInputStreams and PrintWriters

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

Basic design options

I The Collector Endpoint mixin is implemented on acompute resource as a daemon with an RMI interface

I Metric mixins are dynamically created threads (Javareflection)

I Metric classes are not dynamically loaded (todo)

I The Sensor runs on a distinct host, possibly sharedwith other Sensors

I Data flow from the Collector Endpoint to the Sensoruses a TCP channel with JSON encoding

I Aggregator and Publisher mixins are dynamicallycreated threads (as for Metrics)

I communication between Aggregators and Publishersuses internal pipes and JSON

I input and output hook attributes are respectivelyassociated with PipedInputStreams and PrintWriters

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

The tools

I Java 7: either Oracle or OpenJDK

I json-simple 1.1.1

JSON.simple is a simple Java toolkit forJSON. You can use JSON.simple to encode ordecode JSON text.

I jsoup 1.7.3

jsoup is a Java library for working withreal-world HTML. It provides a veryconvenient API for extracting andmanipulating data, using the best of DOM,CSS, and jquery-like methods.

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

The tools

I Java 7: either Oracle or OpenJDK

I json-simple 1.1.1

JSON.simple is a simple Java toolkit forJSON. You can use JSON.simple to encode ordecode JSON text.

I jsoup 1.7.3

jsoup is a Java library for working withreal-world HTML. It provides a veryconvenient API for extracting andmanipulating data, using the best of DOM,CSS, and jquery-like methods.

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

The tools

I Java 7: either Oracle or OpenJDK

I json-simple 1.1.1

JSON.simple is a simple Java toolkit forJSON. You can use JSON.simple to encode ordecode JSON text.

I jsoup 1.7.3

jsoup is a Java library for working withreal-world HTML. It provides a veryconvenient API for extracting andmanipulating data, using the best of DOM,CSS, and jquery-like methods.

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

The tools

I Java 7: either Oracle or OpenJDK

I json-simple 1.1.1

JSON.simple is a simple Java toolkit forJSON. You can use JSON.simple to encode ordecode JSON text.

I jsoup 1.7.3

jsoup is a Java library for working withreal-world HTML. It provides a veryconvenient API for extracting andmanipulating data, using the best of DOM,CSS, and jquery-like methods.

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

The tools

I Java 7: either Oracle or OpenJDK

I json-simple 1.1.1

JSON.simple is a simple Java toolkit forJSON. You can use JSON.simple to encode ordecode JSON text.

I jsoup 1.7.3

jsoup is a Java library for working withreal-world HTML. It provides a veryconvenient API for extracting andmanipulating data, using the best of DOM,CSS, and jquery-like methods.

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

An example: monitoring load and connectivity ofa Compute resource

I The measurement of the average CPU load is sentoutside the cloud as a UDP flow

I The connectivity with the gateway is collected in a logfile on the sensor.

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

An example: The Collector

{

"id": "urn:uuid:2345",

"kind": "http://schemas.ogf.org/occi/monitoring#collector",

"mixins": [

"http://example.com/occi/monitoring/metric#CPUPercent"

"http://example.com/occi/monitoring/metric#isReachable"

],

"attributes": {"occi": {"collector": {

"period": 60

}},

"com": {"example": {"occi": { "monitoring": {

"CPUPercent" : {"out": "a"},

"IsReachable" : {"hostname": "192.168.5.1","maxdelay": 1000,

"out":"b"}

}}}}},

"actions": [],

"target":"urn:uuid:s1111",

"source":"urn:uuid:c2222"

}

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

An example: The Sensor

{

"id": "urn:uuid:s1111",

"kind": "http://schemas.ogf.org/occi/monitoring#sensor",

"mixins": [

"http://example.com/occi/monitoring/publisher#SendUDP",

"http://example.com/occi/monitoring/aggregator#EWMA"

"http://example.com/occi/monitoring/publisher#Log

],

"attributes": { "occi": { "sensor": {

"period": 60, "timebase": 1386925386,

"timestart": 600, "timestop": 3600,

"networkInterface": "eth0"}

},

"com": {"example": {"occi": {"monitoring": {

"SendUDP" : {"udpAddr": "192.168.5.2:8888","input": "c"},

"EWMA" : {"gain": 16,"instream": "a","outstream": "c"},

"Log" : {"filename": "my/log/file","in_msg": "b"}

}}}}},

"links": ["urn:uuid:2345"]

}

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

An example: The target Resource

{

"id": "urn:uuid:c2222",

"kind": "http://schemas.ogf.org/occi/infrastructure#compute",

"mixins": [

"http.//schemas.ogf.org/infrastructure/compute#RMIMetricContainer"

],

"attributes": { "occi": { "compute":

{ "speed": 2, "memory": 4, "cores": 2,

"MetricContainerIPAddress": "192.168.5.3",

"MetricContainerPort": 12312 }}},

"actions": []

}

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

Unfolding the sensor

I The sensor starts as a tread in a thread pool

I It reads its specifications using an HTTP GET

I A TCP socket (server side) is allocated for input fromthe collectors

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

Unfolding the sensor

I The sensor launches a Collector Manager thread foreach collector in the scope

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

Unfolding the sensor

I The Collector Manager invokes (by RMI) themeasurement threads on the source

I Each of them opens a TCP connection with the sensorsocket

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

Unfolding the sensor

I The Collector Manager creates the pipes used forcommunication

I There is one pipe for each hook label in the scope

I Records from the socket are multiplexed to pipesaccording with hook identifiers

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

Unfolding the sensor

I Create the threads that implement the Aggregators

I Input and output hooks are bound to pipes

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

Unfolding the sensor

I Create the threads that implement the Publishers

I Input and output channels are bound as for Aggregators

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

Unfolding the sensor

I One publisher is going to use raw data from thecollector

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

Unfolding the Collector Endpoint

I The monitored resource runs a daemon with an RMIinterface (MetricContainer)

I The sensor has a TCP server-side port acceptingconnections

I The sensor learns the RMI interface from OCCIdocuments

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

Unfolding the Collector Endpoint

I The CollectorManager on the sensor calls a remoteLaunchMetric method on the metric container

I The parameters includeI the name of the metric mixinI the attributes of the mixin, encoded as a JSON object

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

Unfolding the Collector Endpoint

I The MetricContainer creates a metric thread (usingreflection)

I The metric thread opens a connection to the Collectorsocket on the Sensor

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

Unfolding the Collector Endpoint

I All metrics associated with a Collector share the sameTCP connection to the Sensor

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

Unfolding the Collector Endpoint

I The messages from the metric to the Sensor are JSONdocuments, tagged with the destination hook

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

Finally, the experiment

I A virtual network with guest + 3VM

I One VM acts as “coordinator”, in fact simply holdingthe OCCI specs as application/occi+json documents ina web server

I One VM acts as monitored resource

I One VM acts as sensor container

I The guest receives measurements through UDP

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

On the sensor

Launched by an external manager that allocates sensors todedicated hosts

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

On the monitored compute resource

Launched as a consequence of the presence of aMetricContainer mixin

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

On the web server

I the CollectorEndpoint starts first

I the Sensor downloads the documents that describe itsscope (caching!)

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

Conclusions of the experiment

I The proof of concept still needs some work to befinished (as a proof of concept)

I The part of the specifications concerning “named”attributes (now hooks) has been validated

I The Java implementation can be useful as a blueprintfor a real implementation

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

Overall conclusions (document update)

I The MetricContainer added as a SHOULD(recommended, not strictly needed)

I Change terminology for the “named attribute” (intohook, or channel)

From the OCCI toJava: unfolding

the infrastructure

Augusto Ciuffoletti

Overall conclusions (document update)

I The MetricContainer added as a SHOULD(recommended, not strictly needed)

I Change terminology for the “named attribute” (intohook, or channel)